[aprssig] Generating Weather Alerts from NWR

[wa7skg]

The EAS is designed for both radio and TV. As such, there are already 
decoders which generate a crawl for TV that will go across the bottom of 
the screen on a TV channel. So, nothing new about the philosophy. They 
basically decode the duck farts into a text string and feed it into a 
character generator for the video. It seems to me a similar thing should 
be doable for an APRS bulletin. However, there has been much debate 
regarding the "retransmission" of EAS alerts over ham radio. Not sure if 
this actually falls into the same category as hooking up a receiver to 
an EAS decoder and feeding it into a local repeater. This seems more 
like feeding the data from your own weather station into the system.

I'd be interested in seeing such a system in an affordable package for 
this purpose. It would entail a software modem able to decode the duck 
farts and a little logic to parse the data to utilize your desired 
products. Good use of an RPi0.

Michael WA7SKG


Eric H. Christensen via aprssig wrote on 6/8/20 10:08 PM:
> 
> I've wanted a way to transmit weather alert packets on APRS, locally, without the need for an Internet connection (think disaster conditions or other situations where having an Internet connection is just too hard) or if/when the WXSVR is unavailable.  I really like the idea of using APRS as a common operating picture of what's happening around you and seeing real-time weather alerts on your screen is a great safety feature.  After talking it over with a friend of mine, I think I've come up with an idea that might just work (again, specifically for local use).
> 
> If a station had some sort of receiver listening to the local NOAA Weather Radio (NWR)[0] then they would receive the Specific Area Message Encoding (SAME)[1] alert for many (most, all?) of the advisories that we care about in real-time, over the air.  Decoding the SAME packet looks something like this:
> 
> ZCZC-ORG-EEE-PSSCCC+TTT-JJJHHMM-LLLLLLLL
> 
> Where:
> ZCZC is the header
> ORG is the type of originator of the message (EAS, CIV, WXR, PEP)
> EEE is the event type
> PSSCCCC is the geographic code (FIPS) (up to (and including?) 31 FIPS codes can be included)
> TTT is the purge time
> JJJHHMM is the origination time of the advisory
> LLLLLLLL is the originator of the message
> 
> Parsing all that information (omitting the header and originator type) we have all the information needed to create our alert message[2][3].
> 
> CWAPID:NWS-TTTTT:DDHHMMz,ADVISETYPE,zes{seq#
> 
> Where:
> CWAPID is the NWS office and product code (LLLLLLLL and EEE)
> TTTTT is the type of message (ADVIS,WARN ,WATCH) (EEE)
> DDHHMMz is the expiration date-time group (factored based on JJJHHMM and TTT)
> ADVISETYPE is the advisory type (SVRTSM, etc) (EEE)
> zes is the geographic code used to identify the county/area (PSSCCC)
> seq# is the sequence number (factored based on JJJHHMM)
> 
> We can even generate bulletins that can be transmitted using plain language for people to read (think "NWS has issued a Tornado Warning for Orange Co until 19:30.").
> 
> I'm not sure if anyone has worked on or thought of doing this but it doesn't seem too difficult to do.  My friend Kevin, N8VNR, has started a project[4] that decodes the SAME alert once it has been received using Multimon-ng.  Using this code, all that would need to be done would be to map the FIPS codes to the county (and marine) codes and create a table that defines what each event code (EEE) should be (TTTTT and ADVISETYPE).  Of course, there would need to be some sort of method for transmitting these packets onto RF as well as checking their validity prior to their release (lint anyone?).
> 
> Again, this is in keeping APRS local, so with NWR broadcasts only covering a few counties at a time, each station would be self-limiting and full control over what areas and event types should be given.
> 
> Thoughts?
> 
> 73,
> Eric WG3K
> 
> [0] https://www.weather.gov/nwr/
> [1] https://web.archive.org/web/20190621022301/https://www.nws.noaa.gov/directives/sym/pd01017012curr.pdf
> [2] http://www.aprs.org/doc/APRS101.PDF (Page 74)
> [3] http://www.aprs-is.net/wx/
> [4] https://github.com/nivex/dsame
>