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

[Bob Bruninga]

> I totally am against creating more 'specialized 
> objects' with 'specially parsed' features for 
> 'special icons' thrown into the comment section.

But, that is what the position/object comment section is there for.  It is
for the unique amplifying information about a particular station/object.

> It seems to me that flood and radiation data 
> belongs in telemetry, that's what telemetry is for.

No for several reasons.  Flood or Radiation data is of zero value unless it
is seen at a *place* and to have a place, position must be included.  That
is why an object has a position field (place) and a special symbol (to see
what it is), and the comment field (data).  And it must all be in one packet
or it violates the fundamental principle of APRS of single packet
completelness of data.

Second, the "telemetry" format is for multi-channel data specialized
applications.  And requires 5 other complete packets to tell any parser how
to use the data and where it is.  It makes no sense to send an entire packet
to contain a single 3 digit number from a water gage or a radiation sensor.
When a single packet (Object) can send *everything*.

> 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?

To summarize the reeasons:

1) Makes no sense to create a special telemetry format for a single 3 digit
value only

2) Makes no sense to send such single value telemetry without position and
symbol info

3) Makes no sense to clutter the channel with 5 additional packets before it
can be used.

4) Makes no sense to send incomplete information in multiple packets when
some of those packets will be lost, and then the incomplete data has no
value until both packets arrive, taking u p multiple cycles and delaying
delivery.

5) Makes no sense to require specialized software in ALL clients and ALL
radios to have to write special software to correlate multiple packets
containing separate pieces of info.

6) Makes a lot of sense to put radiation data included with Weather data
since wind direction is the most important parameter with respect to
radiation sensors.

> Every crazy additional condition you add to the comments 
> of a packet creates ten times more work for parsing.

But, one has to add a parser for the new sensor no matter what packet it is
in.  The effort is no different.  And adding Flood sensors and Radiation
sensors to APRS is a valid use of APRS and is exactly what APRS was designed
to do.  We are just trying to keep up with new needs.  And the object
comment field was designed just for that purpose.

Telemetry was designed for multiple channels (5) from things like satellites
or robots, or remote multifunction devices.  To properly decode ONE
telemetry format, there has to be a total of 5 other packets transmitted to
mke the information complete!  Very inefficient for single data sensors.

> ... someone post[ed] a telemetry station displaying 
> radiation data, that's where it belongs, along with 
> river height and other metrics.

But unless we know where the sensor is (in real time) and have received the
other 5 packetrs defining the particular telemetry format, they are useless
to a real-time tactical information system like APRS.  APRS was never
designed for shack-potato 24/7 monitoring where piecemeal data can be
collected and integrated after collision losses over long periods.  That is
what the internet, National Weather Service and hundreds of on-line internet
applications were designed for.

APRS was designed for immediate access to *complete* data in single packets
to the mobile/portable/emergency operator via RF.

We added the radiation sensor data to the *complete* Weather format (with
position), so on the front panel of any APRS radio we can see the instant
the first packet comes in:

1) An Alert that there is a high level reading (Radiation Hazard Object)
2) We can see where it is from me.  (distance and direction)
3) We can see what direction the wind is blowing from that sensor
4) As we drive, the distance and direction is updated in real time by the
radio.

All without any new firmware, parsing, or upgrades to all existing APRS
radios going back to 1998.

Hope that helps.
Bob, Wb4APR


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
> GROUP THAILAND
> 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
> MAN
> RAYONG BY 145.375MHZ
>
E27FHM-8>APGJW5-1,HS2SUD*,qAS,E27CUY:!1242.16NP10112.24EW000/000/A=000036EZ
> GROUP THAILAND
> 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
> GROUP THAILAND
>
HS2TAU-9>APGJW4-2,WIDE1-1,qAR,E27DRU-1:!1243.02NP10116.64EW000/000/A=000075R
> AYONG
> 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
> GROUP THAILAND
> 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
>



-- 
NV6G
OpenAPRS.Net
OpenAPRS iPhone Edition

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig