[aprssig] symbols 1.2.1? FLOOD Gages and Radiation (summary)

Gregory A. Carter gcarter at openaprs.net
Thu Mar 24 22:04:30 EDT 2011

I totally am against creating more 'specialized objects' with
'specially parsed' features for 'special icons' thrown into the
comment section.  The protocol is already convoluted  with special
cases it doesn't need more.  It seems to me that flood and radiation
data belongs in telemetry, that's what telemetry is for.  Why do we
need to create sub formats for telemetry just to toss them into
position reports rather than sending telemetry with complementing
object/positions that can be cross referenced?

Every crazy additional condition you add to the comments of a packet
creates ten times more work for parsing.  We just recently had someone
post a telemetry station displaying radiation data, that's where it
belongs, along with river height and other metrics.


On Thu, Mar 24, 2011 at 3:46 PM, Bob Bruninga <bruninga at usna.edu> wrote:
>> You need to connect to the firenet.us feed to see
>> the water stations. There's LOTS of them!
> Thanks! The format I have seen in the past is this:
> ;09428508 *061713z3401.40N/11424.75Ww3.57gh/82cfs
> Which is a standard OBJECT report with the text "3.57gh/82cfs".  This means
> water gage number 09428508 with a reading of 3.57 GageHeight and 82 cubic
> feet per second.
> If this is how they are using the water gage symbol, then I think we are ok
> with the new plan. And can deprecate the sending of the watergage in the
> stand-alone Fxxxx format in a non-WX packet.  This makes the new idea
> possible.
> Also, I see you are right, the APRS1.01 spec never included the parsing of
> Weather in the /W NWS weather station packets even though it was part of the
> original APRSdos format.  So these facts seem to support the following
> conclusions.
> 1) Add the Xnnn format for radiation to existing weather formats.
> 2) Retain the 2006 Fxxxx flood gage format for existing weather formats
> 3) Encourage use of R_ or F_ for weather stations indicating Radiation or
> Flood activity above normal.
> 4) Add the RH hazard Radiation Hazard symbol
> 5) Add the FH hazard Flood Hazard symbol
> 6) Add weather parsing to all the *H symbols for all hazards
> 7) Parse only the *_ and *H symbol groups for weather data
> 8) All existing /w Flood gages use the above X.XXgh/XXcfs format
> 9) No existing Flood /w gages use the stand-alone Fxxxx format
> 10) The stand-alone Fxxx format and parsing of /w for weather is deprecated.
> Can this work?  Anyone impacted?
> Bob, Wb4APR
>> Also, the capital-W is in use by stations that aren't
>> currently weather stations (see below for a short list of packets).
> True, but they were all originally allowed to send weather.  It was thought
> that if there was an APRS weather reporting station at an NWS site, that it
> would use the /W symbol instead of the /_ symbol.  So that is a legacy
> issue.
>> I'm still asking myself "why change what's working"
>> (_ and w with weather) instead of just extending
>> it to include the new features (add defined overlays).
> I thought that is what I am trying to do.  That is *_, *W for weather (and
> including *w for the 2006 water gages legacy).  But then nailing it down so
> that is where all future new sensors will also go.
>> a station that can detect a change in measured value to
>> change its symbol to a hazard, it's probably smart enough
>> to keep transmitting the existing weather data and ADD
>> an appropriate area object to indicate the hazardous
>> condition which actually makes it more easily noticed than
>> a morphing station symbol.
> But we don’t want to have a hazard symbol alternately transmitting with a WX
> symbol since at any instance half the users will see a WX symbol and half
> will see the Hazard symbol and it will always be changing. I agree, the
> ultimate is an AREA AFFECTED symbol, but that is a very smart station and
> should not be a requirement.
>> I'm just struggling to see what the 4 weather-data-containing
>> symbols gets us as opposed to extending the existing 2.
> By adding *H to the parseable weather group (*_, *W and *w) We are
> categorically establishing a system of "sensor" symbols and "hazard" symbols
> that are extensible to up to 36 new sensors and 36 new resulting hazards
> that will not then require incremental changes to future code each time we
> add a sensor to the WX format.
> Thanks for the tip on FIRENET.  Can someone tell us the ORIGIN of all those
> water gages (software, firmware or hardware) and if there is any potential
> to eventually merge them with this new approach?
> Bob, Wb4aPR
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> PS. Here's the s/W/W filter for the past 3 minutes or so manually edited
> to eliminate duplicate packets.
> AA5JM-1>APOT21,WIDE1,WIDE2-1,qAR,KC5EZZ-11:!3109.44N\09917.13WW12.9V
> 70F iGate/WX Station - 4 mi E of Brady. Midnight repeater org.
> DB0OTV-6>APOT2A,DB0KX-2*,ON0DAS-4*,WIDE2-1,qAR,ON0LN-10:!5115.69N/00637.45EW
> OT2m+WS2300 by www.R20.de  Sysop DO7DPóy
> DL1HDL-5>APOT21,WIDE1-1,WIDE2-1,qAR,DD3TF-10:!5337.00N/01009.14EW 10.7V
> 33C WX Station in Hmb-Oldenfelde
> E27ADV-8>APGJW5-1,qAR,HS2QFW:!1241.57NP10111.83EW000/000/A=000118
> E27ADV-8>APGJW5-1,WIDE1-1,qAR,HS2QFW:!1241.57NP10111.83EW000/000/A=000118EZ
> E27CTN-9>APGJW6,qAR,E27DRU-1:!1241.02NP10116.62EW089/003STOP at IRPC  GROUP
> RAYONG 144.950 MHz
> E27CTN-9>APGJW6,qAS,E27CUY:!1241.01NP10116.62EW278/001/A=000201
> E27EEC-9>APOT21,WIDE1-1,qAR,E27DRU-1:!1240.43NP10120.65EW131/000/A=000029BAT
> RAYONG BY 145.375MHZ
> E27FHM-8>APGJW5-1,HS2SUD*,qAS,E27CUY:!1242.16NP10112.24EW000/000/A=000036EZ
> E27FHM-8>APGJW5-1,qAR,HS2QFW:!1242.16NP10112.24EW000/000/A=000036
> E27FHM-8>APGJW5-1,WIDE1-1,qAR,E27DRU-1:!1242.16NP10112.24EW000/000/A=000036E
> Z
> HS2TAU-9>APGJW4-2,WIDE1-1,qAR,E27DRU-1:!1243.02NP10116.64EW000/000/A=000075R
> PS.
> HS7WCT-9>APGJW5-1,qAR,HS7AT:!1341.70NP10020.06EW000/000/A=000023
> HS7WCT-9>APGJW5-1,WIDE1-1,qAR,HS4QOW:!1341.70NP10020.06EW000/000/A=000023EZ
> IV3ONZ>APU25N,WIDE3-3,qAR,IQ3MF-15:=4550.64N/01329.36EWCWOP / APRSWXNET
> AT165 {UIV32}
> KB1FDA-1>BEACON,qAR,K9UDX:;145.330-R*111111z4403.55N/07215.46WWrT100 R25m
> KQ5S-13>APWW07,TCPIP*,qAC,Firenet:=/=61(:%;bW sT  APRS-IS for Win32
> SV3CYL-1>S8QQ24,J41VAB*,WIDE2-1,qAR,SV1UY-10:'1FBl!vW/
> SV6EXB>APU25N,TCPIP*,qAC,T2FRANCE:=3938.45N/02226.12EWhttp://sv6exb.no-ip.or
> g
> Davis VP2 {UIV32N}
> VE3EYR>APW250,VE3KSR*,WIDE2-1,qAR,VA3XTO:=4259.63N/08019.03WWPHG3290/e-MAIL
> va3eti at rac.ca -250-<630>
> W5MAF>APN382,WIDE3-3,qAS,N5MXE-11:!3156.55N110211.29WW/APRS for West
> Texas & Eastern NM SKYWARN b2
> WX4TOR>BEACON,NI4CE-12*,WIDE2-1,qAR,KG4YZY-11:=2742.33N/08224.04WW==>NWS
> Ruskin Florida (TNC Only)
> On 3/24/2011 11:34 AM, Bob Bruninga wrote:
>> Lynn,
>> Yes, we are thinking the same but emails passed at the same time.
>> Yes, that is my proposal.  Im using "*" now as a WILDCARD to include /, \,
>> #.
>> Only *_ and *W would be parsed for WX and any other sensor data in the WX
>> format.
>> But then we would also want to parse all *H (hazard objects) too, since
> once
>> the given weather or sensor station detected a threshold, it would switch
> to
>> an appropriate hazard symbol.
>> But then we have the backwards compatibility issue with the 2007 flood
>> gages.  I see 8 of them on the air right now (/w).  I don't see any
>> "flooding right now either (\w).  None of them appear to be sending water
>> level info in the Weather format, so I think we can implement the above
>> WEATHER/SENSOR Parsing rule without impact?
>> Bob, Wb4APR
>> -----Original Message-----
>> From: Lynn W. Deffenbaugh (Mr) [mailto:ldeffenb at homeside.to]
>> Sent: Thursday, March 24, 2011 11:22 AM
>> To: TAPR APRS Mailing List
>> Cc: Bob Bruninga
>> Subject: Re: [aprssig] APRS symbols 1.3? FLOOD Gages and Radiation
>> I'm not a flood-guage person, but hopefully you'll take my (squawking)
>> feedback.
>> Did you really mean capital-W?  They are NOT currently weather data and
>> are not parsed as such.  They are Weather Stations.  The Underscore and
>> lower-case w are all that are currently parsed for weather that I'm
>> aware of.
>> So, with what I read below, we go from TWO underscore and lower-case w
>> to FOUR underscore, lower-case w, upper-case W, and upper-case H
>> possibly base symbols, ALL of which MIGHT contain weather-formatted
>> sensor data?
>> Is that really your intent?  Why not just keep it underscore and
>> lower-case w with overlays on the w to pick up the new "weather" sources?
>> Why parse Hazards for weather data?  They, as you mentioned earlier,
>> should be objects, possibly area objects, showing the hazard and the
>> extent of the hazard, not measurements all the time.
>> And I don't know who, if anyone, uses Weather Stations (capital-W), but
>> to my knowledge it has never had measurements being parsed from it before.
>> Lynn (D) - KJ4ERJ - Author of APRISCE for Windows Mobile and Win32
>> On 3/24/2011 11:06 AM, Bob Bruninga wrote:
>>> OK, How this!?
>>> Flood Gauge people please give us feedback!
>>> This proposal is a continuation of the great symbol set expansion
> proposed
>>> under aprs 1.2 back in 2007.  That is, that Overlay characters could be
>>> added to ANY symbol, thus increasing the combined combination of symbol
>>> indicators by hundereds.  Both Kenwood and Yaesu now already support
>>> universal overlays in their radios.
>>> This discussion of Radiation Hazards and Radiation Sensors has caused a
>>> thorough re-look at where we stand.  We simply need to expand the
> overlays
>>> for WX stations.  Currently /W and \W should be parsed for Weather.  So
>>> shouldn't also #W with any overlay?  In that case, I propose the
> following
>>> overlays for the WX symbol so they are backwards compatible to existing
>>> symbol sets:
>>> 1) RW is a weather station highlighting its Radiation Sensor (#W)
>>> 2) FW is a weather station highlighting its Flood Gauge (was /w or \w)
>>> These stations can automatically change their symbol depending on what is
>>> going on.  If either the Radiation sensor or Flood gage is showing BENIGN
>>> readings, then it can simply show the WX symbol (/W) but when elevated
>>> readings of either sensor begin to rise, the station can change its
>> symbol.
>>> When a SERIOUS threshold is exceeded, these same stations can then change
>>> their symbol to either of the following HAZARD symbols
>>> 3) RH is a Radiation Hazard OBJECT to HIGHLIGHT a radiation Hazard
>>> 4) FH is a FLOODING HAZARD to highlight a flooding hazard
>>> 5) WH is a WIND HAZARD
>>> The result to client code is that only #W (weather) and #H (hazards) need
>> to
>>> be scanned for all Weather and other SENSOR data, not an ever incremental
>>> change to code for each new symbol added.  Here is the impact on CODE?:
>>> That is, now, only /W, \W and #W symbols need to be parsed for weather
>> data
>>> (which can include FLOOD data and Radiation data).. plus since 2007, /w
>> and
>>> \w for floods.
>>> This seems like the most simplest and consistent approach.  BUT The
>> problem
>>> is that in 2007 we suggested /w for flood gages and \w for FLOODING
>> events.
>>> Has this made it into any NON-CHANGEABLE hardware or software?  Probably
>> so.
>>> Therefore, we still need to allow for legacy checking of /w and \w
> symbols
>>> for weather and flood info.  But can we phase this out in the long term?
>>> Flood gauge people, please comment.
>>> Bob, wb4apr
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

OpenAPRS iPhone Edition

More information about the aprssig mailing list