[aprssig] APRS symbols 1.3? FLOOD Gages and Radiation

Thu Mar 24 11:46:12 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.

Also, the capital-W is in use by stations that aren't currently weather 
stations (see below for a short list of packets).

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

If you've got 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.

I'm just struggling to see what the 4 weather-data-containing symbols 
gets us as opposed to extending the existing 2.

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=000029BATMAN 
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=000036EZ 
GROUP THAILAND
HS2TAU-9>APGJW4-2,WIDE1-1,qAR,E27DRU-1:!1243.02NP10116.64EW000/000/A=000075RAYONG  
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.org  
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
>>
>
>