[aprssig] Sensor (weather-formatted) Symbol (was: APRS Radiation sensor)

Thu Mar 24 10:58:24 EDT 2011

> So I guess we do need a new symbol just for SENSORS.  And Radiation is one
> of them.  And it can contain WX.

I'd rather see a new base symbol for "weather-formatting" stations and 
the overlay (or lack thereof) declares what kind of object it actually 
is as described in the following.

Underscore (_) is already weather data in both the primary and alternate 
tables and does not have any defined "special" overlays at 
http://aprs.org/symbols/symbols-new.txt, but given how long it has been 
just weather, I wouldn't be surprised that stations may be overlaying it 
already.

Water (w) is already defined as allowed to contain weather-type data in 
both primary and alternate tables (flooding), but is not as widely used 
as weather, so I'd like to think that other overlays may not yet be in 
use for this one.  We probably need to scan a full feed for a while to 
confirm or deny this assumption.

Rather than allocate a whole new base symbol to be "sensors", can I 
propose that we extend w with specific overlays to qualify what type of 
"weather" data being measured?  That might make it more difficult for 
people to filter out the water stations from a FireNet.us feed though, 
as I've been suggesting people use -s/w to eliminate them.  But then 
again, that will only eliminate the primary table, but flooding and 
other overlays would still come through, so maybe that's not so bad.  
And if they just want the new ones, -s/w/w would eliminate water and 
flooding while still returning all other overlays.

By extending w with special overlays to include radiation-sensing, 
weather-type-reporting sensors, the parsers can simply look at all '_' 
and 'w' base symbols in either table and all overlays for weather-type 
data.  '_' has been weather, and 'w' is conveniently the first letter of 
weather and water.  It doesn't say sensors, but it does carry the APRS 
weather format implication and only requires a slight modification to 
http://aprs.org/aprs12/weather-new.txt to cover that ALL instances of 
'_' and 'w' should be checked for weather-formatted information, not 
just the primary and alternate tables.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 3/24/2011 10:28 AM, Bob Bruninga wrote:
> Geeze, you were right.  We did allow WX to be included in Flood gage
> symbols.  Was that a good idea?  Following that logic, we'd also need to
> parse Radiation hazards for WX.  Seems to me if a stations is transmitting
> the "weather format" which includes floods and radiation, then it should be
> a WX symbol.  Any s0oftware that wants to highlight those stations with
> special sensors can "search and display" by selection.
>
> On the other hand, all old software will not easily see these new
> capabilityies since they cannot search for the special fields.  In that
> sense, new code, parsing the NEW symbols allows for OLD software to see NEW
> capabilities (symbols) but not recognize the weather?  Now I'm leaning back
> to that.  Yes, because that gives a measure of backwards compatibility to
> all existing users to SEE new sensors and capabilities with their existing
> software (if they want to actually see the data, they can see it manually or
> upgrade their software, but at least they know it is there..
>
> But new software can do it all.  Yes, I think that is the correct approach.
> So I guess we do need a new symbol just for SENSORS.  And Radiation is one
> of them.  And it can contain WX.
>
> Bob, WB4APR
>
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Bob Bruninga
> Sent: Thursday, March 24, 2011 10:16 AM
> To: 'Lynn W. Deffenbaugh (Mr)'; 'TAPR APRS Mailing List'
> Subject: Re: [aprssig] [ui-view] APRS Radiation sensor
>
> Good points...
>
>> From: Lynn W. Deffenbaugh (Mr) [mailto:ldeffenb at homeside.to]
>> Ok, I've seen the new Xnns weather parameter for radiation,
>> and I've noted the previously existing requirement that not
>> only weather station symbols be checked for weather, but
>> also water and flooding symbols may contain weather.
>>
>> I've also noted discussion elsewhere in the thread that
>> overlay R on symbol H be used for a "Radiation Detector".
>>
>> Merging these two things together, should an RH symbol also
>> be checked for the presence of weather data, possibly to
>> include the X, or is the RH for something completely different.
>> If RH symbol packets should be scanned for weather data,
>> then should it be specified in weather-new.txt for completeness?
> You have raised good points, and I think it was Julian also raised this
> point.
>
> OK, how about this.  We have defined Xnnn as a field in weather reports.
> Thus a WX symbol is required according to the spec.  Thus, this is a sensor.
> On the map it looks just like any other weather station but its radiation
> sensor can be found and parsed.
>
> The RH hazard symbol is mostly for an OBJECT to highlight the location of a
> "Hazardous condition".
>
> Bob, Wb4APR
>
> On 3/23/2011 3:27 PM, Bob Bruninga wrote:
>> I  updated the APRS12 addendum to this standard for Radiation.
>> http://aprs.org/aprs12/weather-new.txt
>>
>> Bob, Wb4APR
>>
>> -----Original Message-----
>> From: ui-view at yahoogroups.com [mailto:ui-view at yahoogroups.com] On Behalf
> Of
>> Bob Bruninga
>> Sent: Tuesday, March 22, 2011 3:28 PM
>> To: 'TAPR APRS Mailing List'
>> Cc: 'IZ6RDB'; 'Guido Trentalancia'; jjesson at voyager.net; 'sylvainfaust';
>> ui-view at yahoogroups.com
>> Subject: [ui-view] APRS Radiation sensor
>>
>> How about this for Radiation Telemetry:
>>
>> - 3 digits.  Either in a WX report or in a Telemetry channel.
>> - In a weather report the identifying byte would be "X".
>> - So X123 would be 12 times 10^3rd nanoseverts
>>
>> Using Tapio's idea (below) of 2 digits of precision and one digit of
> decade.
>> Bob, WB4APR
>>
>> -----Original Message-----
>> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
>> Of Tapio Sokura
>> Sent: Thursday, March 17, 2011 4:40 PM
>> To: TAPR APRS Mailing List
>> Subject: Re: [aprssig] Clarification of APRS weather station data flow.
>>
>> Hi,
>>
>> On 03/17/2011 05:29 AM, Scott Miller wrote:
>>> Also, unsurprisingly, there's been a big surge of interest in Geiger
>>> counter interfacing.  Bob, can we get a standard for sending ionizing
>>> radiation levels in weather reports?
>> I'm not Bob, but I'm sticking my spoon into the soup anyway after a
>> little IRC chatting.. so here goes: Anyone who's familiar with radiation
>> levels knows they can hugely vary in scale. So using a plain, say
>> three-digit, number isn't going to scale very well (i.e. 001 = 1 uSv/h,
>> 999 = 999 uSv/h).
>>
>> I'm suggesting the following: three digits, where the first two are the
>> significant digits (mantissa) and the last one is an exponent. Base unit
>> could be nSv/h, nanosieverts per hour (Sievert is the SI-unit for
>> ionizing radiation dose equivalent).
>>
>> If abc represents the digits, the resulting radiation level would be
>> calculated using the formula ab * 10^c nSv/h. A few examples:
>>
>> 000 = special case for "reading unavailable"
>> 010 = special (theoretical) case of 1 nSv/h or under
>> 020 = 2 nSv/h
>> 150 = 15 nSv/h
>> 990 = 99 nSv/h
>> 321 = 320 nSv/h
>> 123 = 12 uSv/h
>> 654 = 650 uSv/h
>> 456 = 45 mSv/h
>> 987 = 980 mSv/h
>> 989 = 98 Sv/h
>> 999 = special case for 99 Sv/h or over
>>
>> So that's the digit part sorted out, now we just need a letter
>> identifier/tag for it..
>>
>>      Tapio
>>
>> _______________________________________________
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>