At 4:30 in the afternoon on November 15, 1989, an F4 tornado ripped through Huntsville, Alabama killing 21 people. It could have been much worse save for the quick thinking of the people running the after-school program at Jones Valley Elementary. They took the children under the stairs as soon as the power went out. They survived, though the top floor was torn from the building. A mother out front who had come to pick up her child was among the 21 casualties.
That was my brother's school. My church and several others were destroyed. My route to school changed for months while they rebuilt and cleared the area. These are the sorts of stories you collect living in the No. 1 place for tornadoes per capita. And it is these stories that instill a healthy respect for tornadoes, and heeding tornado warnings.
This respect for tornado warnings has led me to consider in detail how they work. Important aspects are how notifications arrive, how to understand if the warning applies to your particular location, and the urgency of the warning. This led me to learn to how to build and code an Internet of Things (IoT) device to alert for tornado warnings.
How do you get the warning? In the late 1990s I splurged $50 for a weather radio that alerted for only my county, unlike my old one that alerted for any county in the station's range. It told me of tornado warnings, severe thunderstorm warnings, and other weather events. That was super. But then in 2007, the National Weather Service started issuing storm-based warnings which included polygons to more precisely match the area threatened by the storm, irrespective of political boundaries. It was nice to know if the warning was in our county, but we still had to figure out if we were in the warned area, so it took more time to process the warning and take shelter. The weather radio broadcast this information using the names of geographic areas with which I was familiar, but it still left room for uncertainty.
The uncertainty is tolerable at my house, where it takes 10 seconds to check the radar and take cover. But in a workplace it's quite reasonable to require more precision. You don't want to halt production unless the warning is for your area, and you don't want to miss a warning since you need to keep people safe. Lawyers don't give much credence to armchair meteorologists.
Cell phone carriers now deliver tornado warnings on their networks to phones within the range of towers in warned areas, but these systems tend to over-warn, including possibly reaching everyone in the county when there is an alert in just one area of the county.
Then came the Raspberry Pi, with computing capabilities and a third-party weather radio board. The National Weather Service publishes the polygons for the storm-based warnings on the Internet, and not on the weather radio. The next step is obvious: Alert me when I need to know when there is a tornado warning in my area, and not for anything else.
(There are some other interesting things for which an immediate alert could be useful. Mexico has an earthquake warning system using this same technology, and California is developing a similar system. On rare occasions, severe thunderstorms are accompanied by straight-line winds strong enough to warrant sheltering in place, but not often. Tornado warnings are frequent enough and objective enough to take automated action.)
To make a weather radio for yourself, follow the instructions on GitHub.
How to build prototype 1
First, let me recommend getting buy-in from other family member(s) who may be impacted by your distraction while working on the project. Then make a list of parts. I consulted a friend who has done more IoT than I have to figure out this part. You'll need:
- a Raspberry Pi 3 B+
- the AIWIndustries weather radio board and accessories
- a power supply
- a micro SD card
Load up the SD card with Raspbian while you wait for the other parts to arrive. When the parts arrive throw them together in short order, and run sample code. Start cleaning up the sample code like Pi_4707, then rewrite it almost from scratch because it's not sufficiently robust for your application.
Testing
Next, figure out how to receive and process messages from the National Weather Service: text messages, CAP messages, and the various sources. Capture a battery of messages from various sources during a storm system, and use those to evaluate storm system processing. Various libraries might be able to help with processing NWS messages, but all of them seem to be inextricably tied to their particular use cases.
Test everything. Create a mock of the radio chip to use with your code—because you can't legally simulate messages coming into the chip—and you don't really want to test the chip itself that way. Write tests for every challenge. You can set the mock to run faster than the real radio and get your test suite to finish earlier. Make sure your code can run for a long time. Write unit tests and integration tests.
Test collecting messages and assessing what's in effect for a particular location. Use those captured messages and replay storm systems to make sure that it works correctly. Find edge conditions, or invent some.
Code repository
Put the project on GitHub or other code repository. I have mine at Raspberry Pi NOAA Weather Radio (NWR). Because various companies want to support open source development, you can release your code and use tools like Travis.ci to run your builds in several environments, and coveralls.io to check code coverage of your tests. They're very simple to set up.
Using your device
Then you get to the sticky parts: integrating messages from radio and Internet, and resolving what to do in various situations.
Enter a component and eventing library. Consider Zope and Circuits Framework, the former being established but also a full-fledged web application server, and the latter an event framework which also supports web I/O. I want small and simple, so I chose Circuits. Write acceptance tests to make sure it behaves the way you want it to, because your system is only as reliable as its framework.
At this point, I spent some time trying to retrofit the radio code with Circuits but discovered that wouldn't be trivial because there were some subtly different ways of thinking about the various commands to be issued to the chip and the chosen framework. I'll have to come back to that later.
Wrap the radio code in an adapter for Circuits, and set up the framework to generate net messages from the simplest Internet feed, like the National Weather Service.
Finally, build out a mechanism for simulating events from radio and Internet, and the alerting code to trigger a relay and play an audio alert.
Voilà! We now have a usable alerting machine. Hook up a speaker and it's ready to warn.
Final thoughts
There's more work to be done: server-side monitoring and alerting, establishing an update process, adding a visual display for a SOHO model to show weather and the alert state, and additional Internet feeds for additional reliability and the potential of faster alerting. One more option is to connect to a fire alarm public address system, which requires a UL 2572 certification.
If you'd rather not have any of the hassle but have just the notifications, contact me for more information.
3 Comments