[aprssig] APRS symbols 1.3? FLOOD Gages and Radiation

Thu Mar 24 12:31:20 EDT 2011

> You need to connect to the firenet.us feed to see the water stations.
> There's LOTS of them!  They may not be sending weather-formatted data,
> but there's a bunch of stations.

Can you send me an example of the format they are using?  Thanks

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