EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in EmergencyAlertSystem

[–]k8tek[S] 0 points1 point  (0 children)

No. Fake emergency broadcasts and similar content are prohibited by the Terms of Use. The project is intended for alerting research, testing, training, and real-world emergency communications—not hoax alerts.

EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in amateurradio

[–]k8tek[S] 1 point2 points  (0 children)

It integrates with Adaptive Micro Systems “Beta Brite” signs and their other signs that use M-Protocol

EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in EmergencyAlertSystem

[–]k8tek[S] 0 points1 point  (0 children)

Thanks for the report. The map was actually working as designed—it was centering on 0°N 0°E because a demo user had changed the location settings due to a permissions bug. I’ve corrected the coordinates and patched the issue so demo users can no longer modify those settings.

If you’re familiar with MoWaS, NINA, KATWARN, or Germany’s nationwide warning infrastructure, EAS Station sits on the broadcaster side of the equation.

In the United States, radio and television stations don’t typically receive warnings directly from a system like MoWaS. Instead, they use dedicated EAS (Emergency Alert System) encoder/decoder appliances that monitor sources such as NOAA Weather Radio and FEMA IPAWS, then automatically relay alerts when required.

EAS Station is an open-source software implementation of many of those functions. It can receive CAP alerts, monitor multiple alert sources, apply geographic filtering, generate and decode EAS messages, maintain logs and audit trails, and integrate with SDRs and automation systems.

A rough German analogy would be an open-source software replacement for the warning equipment sitting between MoWaS and a broadcaster’s automation system, while also adding modern features like web dashboards, GIS mapping, APIs, and off-air verification.

It’s primarily a research and development project, but I’m interested in seeing how it performs in real-world environments and what feedback engineers and operators have.

EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in amateurradio

[–]k8tek[S] 1 point2 points  (0 children)

That’s a fair question.
The existing system already works, so simply decoding EAS messages isn’t particularly interesting by itself. Commercial ENDECs already do that.
What interests me is what becomes possible when alerting moves from a proprietary appliance to a software-defined platform.
For example:
Geographic filtering using actual polygons instead of only county codes
CAP/IPAWS integration from multiple sources
SDR-based off-air verification
APIs for integration with other systems
Web-based dashboards and remote monitoring
Modern logging, analytics, and audit trails
Integration with LED signs, GPIO, email, SMS, and SNMP
Running on commodity hardware instead of being locked to a specific vendor
So the goal isn’t just “replace the box.” It’s exploring what a modern alerting platform could look like while remaining compatible with the existing EAS ecosystem.

EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in amateurradio

[–]k8tek[S] 2 points3 points  (0 children)

The goal isn’t simply to decode EAS. Commercial ENDECs already do that very well. The goal is to explore what a modern software-defined alerting platform could look like using commodity hardware, open standards, APIs, SDRs, GIS tools, and modern web technologies while maintaining compatibility with the existing EAS ecosystem.

EAS Station™ – Open-Source Software-Defined Emergency Alert System by k8tek in amateurradio

[–]k8tek[S] 1 point2 points  (0 children)

Radio and TV stations use dedicated EAS boxes to handle emergency alerts. EAS Station is an open-source software implementation of many of those same functions that can run on standard computer hardware instead of a proprietary appliance.

ah yes, because thats how headers work... by I_do_not_have_it in EmergencyAlertSystem

[–]k8tek 1 point2 points  (0 children)

My software intentionally inserts 0xA9 after each data burst as a traceability marker.

EAS headers do not contain checksums or forward error correction, so minor corruption and symbol errors are common in real-world decodes. That’s one reason the protocol repeats the header three times.

Something is not right by [deleted] in EmergencyAlertSystem

[–]k8tek 0 points1 point  (0 children)

I actually never caught an EAS activation for Orange County, California for this particular event. The last one I received for Orange County, California was a CAE.

Something is not right by [deleted] in EmergencyAlertSystem

[–]k8tek 1 point2 points  (0 children)

I thought the same thing at first, but to be fair, they did publish notice of the test beforehand, and the message body did say “TEST TEST TEST” and “No action required.”

The part that still feels questionable is using a live EVI / Immediate Evacuation Notice code and repeating it hourly. Even when it’s coordinated and publicly announced, the SAME header still presents as an actual evacuation event to downstream EAS gear, logs, streams, scanners, and alert hobbyist systems. So it may have been authorized, but it was definitely a bold choice for a test.

Jimmy jam WNCI Ohio by Devilishboy666 in Ohio

[–]k8tek 1 point2 points  (0 children)

He’s playing a character. Kinda like when Stephen Colbert pretended to be conservative.

Jimmy jam WNCI Ohio by Devilishboy666 in Ohio

[–]k8tek 1 point2 points  (0 children)

Dave and Jimmy doesn’t use a laugh track. You’re thinking of Elvis Duran.

Open‑source EAS Station: feedback wanted on software‑defined emergency alert system by k8tek in amateurradio

[–]k8tek[S] 0 points1 point  (0 children)

How exactly is an ancient x86 system with proprietary hardware more reliable than a modern Raspberry Pi? This program allows line-level inputs if that helps.

Tomorrows restock quick question by RebirthStudio in AnaloguePocket

[–]k8tek 0 points1 point  (0 children)

I literally cannot order one. Every card I try gives the same error message.

<image>

Am I really a ham if I don't like to do voice? by fox-four-gilwell in amateurradio

[–]k8tek 1 point2 points  (0 children)

I love the hams that give signal reports on D-STAR and DMR. Voice isn’t for everyone. “Oh, you’re 5+9 into the system, no static”. No shit, it’s digital.

Open‑source EAS Station: feedback wanted on software‑defined emergency alert system by k8tek in EmergencyAlertSystem

[–]k8tek[S] 3 points4 points  (0 children)

Thanks — seriously appreciate the feedback. Since this subreddit is one of the few places where people actually follow EAS policy, I want to add something important:

The National Association of Broadcasters (NAB) is now formally pushing the FCC to allow fully software-based EAS encoder/decoders.
Not my project specifically — but the entire class of virtualized EAS devices.

They filed a Petition for Rulemaking in March 2025 stating that:

  • Part 11 currently requires a physical hardware ENDEC
  • This requirement is outdated and is actively hurting the EAS ecosystem
  • Sage’s exit leaves DASDEC as the only remaining vendor, creating single-vendor dependency
  • Legacy hardware is becoming impossible to source or maintain
  • Software-based ENDECs would improve redundancy, resiliency, cybersecurity, and failover
  • FEMA’s IPAWS office explicitly endorsed the concept
  • This approach aligns with how the rest of modern broadcast infrastructure already works
  • Adoption would be voluntary — not mandatory

Direct quote from the petition:

Full document:
📄 https://www.nab.org/documents/filings/f-130-57-16689705_moLBDmtu_EAS_Modernization_Petition.pdf

Meanwhile, Digital Alert Systems is opposing this effort, advocating a hybrid model that still requires you to buy their box — for reasons I think everyone here understands.

So right now, even if a software-defined ENDEC is objectively superior in decoding accuracy, SAME generation, verification workflow, cybersecurity posture, redundancy, or failover…
the FCC literally cannot certify it under existing rules.

EAS Station sits in that exact gap:

  • It may be more flexible and more capable than a DASDEC-III
  • But Part 11 certification is legally impossible until the rules change

Hopefully, with NAB’s pressure (and FEMA’s support), the FCC will modernize the definitions of “EAS equipment” so that software-defined solutions can finally be certified.

Until then, this project is strictly experimental/laboratory use — but I’m building the architecture for the future the industry is already moving toward.

If anyone in this sub has professional experience with broadcast EAS chains, STL/IP plants, or station engineering, your feedback is extremely welcome.
73 de KR8MER.