SAME Codes

[Matt Tottle]

Might be better to wait until they can be programmed for their location, otherwise they'll just get unplugged after the first 2am warning for the other side of the county...

They already can be programmed for tighter than county wide alerting based on the polygon. Thats what the first digit in the FIPS/SAME code is for. NWS just doesnt bother to use it, they just use the 0 identifier (countywide), even if the polygon only touches a tiny corner of the county.

They could already prevent the vast majority of false alarms if they would just activate partial counties based on the polygon by utilizing the first digit.

Sent from my Samsung Galaxy S II using Tapatalk

 

[rdale]

Well, that may sound good in theory but unless you live in a square county that won't really work on a grand scale. It would be a very minimal investment ($1 or so per radio) to enable a position-specific feed and be done with it. When NWS starts taking NWR seriously - then maybe we should. But by the time that happens, smartphone apps, PLAN/CMAS etc will all be predominant.

 

[Matt Tottle]

I think I went through this already with you. Why would it need to be a square county? Regardless of the shape, any county can be subdivided into up to 9 smaller parts, can they not? They do that already and call these subdivisions 'towns', and they seem to work just fine on a grand scale.

I'm not trying to be a dick, I'm just saying the framework is already there to reduce the false alarms, and it would cost NOTHING to implement. So why would they need to invest money into 'position specific' feeds (I'm not even sure where you're going with this, and I can't see it being $1 per radio to implement if you're saying what I think you're saying) when all they have to do is change which numerical code they send over the air?

 

[rdale]

They can, but how does Joe Public know if they are in SE Lucas County or NE Lucas Co or EC Lucas Co?

http://upload.wikimedia.org/wikiped...y_Ohio_With_Municipal_and_Township_Labels.PNG

If you think it'd cost nothing to implement, you've not dealt with modifying protocols and software used by the NWS in any fashion

Where I'm going with is allowing people to enter a zipcode, or lat long, or something else that would be able to decode a set of polygon lat/longs. The processing power and programming needed to do that couldn't cost more than a buck a radio max. But NWS says no - and until they say "yes" none of the above matters.

 

[rdale]

This is from the TRAC report last week:

WEATHER RADIOS

Push for the development of technology to transmit localized warnings through weather radios. Promote their use and upkeep, and develop a system to purchase and distribute them, with a priority focus on Alabama’s special-needs population. Weather radios are useful in alerting people to an approaching storm, but the technology needs to be improved. National Weather Service warnings are transmitted to the radios with a countywide code, and thus the radios sound on a countywide basis, not just in the area under threat. The Weather Service should develop the technology to send area- specific warnings to weather radios. The state and counties should work with nonprofits and others to promote the use of weather radios and distribute them to the homebound and other special-needs populations.

 

[Matt Tottle]

The same way Joe Public knows what the SAME code for Lucas county is. He looks it up. Enter the zip code and the database will spit out the exact SAME code for that town.

Here. Try this out.. I picked this area specifically because the counties have irregular shapes..

Say this TOR goes up. It is centered in Wabaunsee County, but it just touches several others. As the system works now, weather radios go off in the entirety of Riley, Pottawatomie, Jackson, Geary, Wabaunsee, Shawnee, Morris, Lyon, and Osage counties. This is roughly 5200 square miles being warned for a polygon that is a fraction of that size.

The red indicates the actual TOR, and the pink line indicates the actual area that is warned.

With the exception of the rest of Jackson and Shawnee counties, toward which the storm is actually moving, nobody in any of the other counties care about it. You already know this is the problem.

But with the capability of the technology that is already IN PLACE, the counties can be subdivided such that only the areas closest to the polygon receive the activation, and those who are nowhere near the storm can go about their business.

In this example, red indicates the TOR, yellow indicates county subdivisions, pink indicates the area that would be warned under the current system, and blue indicates the area that would be warned if the subdivision code were used in the SAME code.

See where I'm going here? It cuts the false alarmed area by 80%, and it's nothing that would require any sort of major overhaul to the system because the framework is already there and the radios already have the technology. All the public would have to do is reprogram their radios if they don't want countywide warnings. You're also forgetting that if the radio is programmed with "0" as the first digit in a SAME code, it will respond to an alert coded to ANY subdivision, so it doesn't affect existing radios at all.

For example, if a radio is coded to 516234, it will ONLY respond to 516234 or 016234. But if it is coded to 016234, it will respond to 016234, 116234, 216234, 316234, 416234, etc, etc. It's just another level of filtering.

 

[rdale]

As I mentioned, the warning issuance software would require a MAJOR rewrite to add all that. Not cheap, and certainly not to be done in less than 3-5 years. It would be much easier to send the polygon as part of the data stream, something that was pushed hard when polygons came along but was soundly rejected by NWS.

 

[Matt Tottle]

Considering that the subdivision digit was added to accommodate the polygon based warning vs. the county based warning, I highly doubt its as involved a process as you're making it out to be.

Sending the polygon within the data stream will require Joe Public to buy an entirely new radio that is capable of decoding it, similar to what happened when the expanded event codes were added. That move obsoleted every radio manufactured before 1998, because support for the new codes could not be added to existing radios. They will also have to find a way to get the polygon into the datastream without breaking support for the millions of legacy radios already out there - which is not easy, and they will have to get the manufacturers onboard with the idea. Not only from a production standpoint to get it implemented, but they'll basically be telling the manufacturers that the new technology will obsolete everything that they are currently making - including millions of pieces of unsold inventory. If I were a manufacturer, I would strongly oppose such a notion.

From an upgrade rollout standpoint, an improvement that allows compatibility with 100% of product in the wild is ALWAYS preferable to one that has incompatibilities. Seeing as the subdivision code is already implemented in 100% of SAME radios sold in the last 15 years, it's not a giant leap to support it at the back end. Certainly not a major rewrite with a 5+ year timeframe.

 

[rdale]

I understand all your issues, and have agreed that your idea could have merit. I just question your conclusion that this is a quick fix for NWS to implement.

Any polygon addition doesn't need to hurt any existing radio, just like the expanded event codes didn't obsolete existing radios. Those radios just ignored the other events, and most offices don't even use those events in the first place so not a major issue.

 

[Matt Tottle]

Exactly - the older radios completely ignore codes they don't understand, which makes them obsolete, regardless if the codes are used locally or not... So if you have an older one and you see all your neighbors hightail it out of town, maybe it's because theirs alerted to the Nuclear Power Plant Warning and yours didn't.. At least with the new event code set there was a provision added that will still make the radio go off for an unrecognized event code.

As for the polygon being transmitted seamlessly within the current datastream, I'm not convinced it can be done without breaking things related to the current technology. The SAME header comes in a very specific format, and it does not have any 'reserved space' in it. The only reasonable way that I can see to do it (if current radios can tolerate it) is to shoehorn an extra data burst in right after each SAME header burst that a new technology radio can look for.

The unreasonable way is to change the system over to digital transmission like they did with TV and radio. Simulcast the digital signal over the analog one, and you can include anything you want within the digital signal. But that's bookoo bucks, and it would light the fuse on a sunset mandate for analog just like it did with TV - eventually forcing everyone to go out and buy new radios.

 

[rdale]

Good discussion. In any case Jack Hayes said at October's IAEM conference that they would be making progress on this push. Given the TRAC and Service Assessment notes on the problem - if they don't have some sort of progress as this year's conference then it'd be safe to assume they aren't going to ever do it.

 

[Jeff Duda]

I've been thinking about issues like this lately as I've been reading through Mike Smith's book. It makes some sense that NOAA/NWS would write themselves into code oblivion to prevent simple upgrades to keep with the times given the NWS's (old Weather Bureau's) long-standing fear of issuing warnings to the public in fear of causing a panic. The warnings they issue still conform to 1950s and 1970s standards as far as the codes and symbolism in the warnings. It just shocks me how unwilling NOAA/NWS is to make simple changes to an outdated and underperforming warning system. I guess bureaucracy is really that powerful.

 

[rdale]

Oh, the first part might be taking the conspiracy theory a bit too far I think it's just the impact of a bureaucracy plain and simple. Plus with AWIPS II coming along as horribly as everyone outside of Silver Spring expected - they don't have resources to be messing with existing software that "does the job."