About EAS Station

Software-defined drop-in replacement for commercial EAS encoder/decoders built on Raspberry Pi-class hardware

Development-Only Notice: EAS Station is actively pursuing feature parity with commercial encoder/decoders but remains experimental. It is not yet FCC-certified, is not ready for production deployment, and must only be evaluated in controlled lab and training environments until certification paths are explored.

Legal Compliance Warning: EAS Station generates valid Emergency Alert System (EAS) SAME headers, attention tones, and audio. Broadcasting, transmitting, or otherwise leaking these signals on-air or over monitored paths without explicit authorization is a violation of FCC rules and may trigger Primary Entry Points, Local Primaries, and other downstream facilities. Always work inside shielded test environments and never connect experimental output to production RF, STL, or streaming chains.

Real-World Consequences: The FCC has repeatedly issued six-figure penalties for misusing EAS tones. In 2015, iHeartMedia paid a $1 million consent decree after The Bobby Bones Show triggered false alerts. The trailer for Olympus Has Fallen led to a combined $1.9 million settlement across multiple national networks. Misuse is traceable, and enforcement actions can include equipment seizure and license revocation.

Ethics & Accountability: This project exists to strengthen public warning readiness—not to be weaponized. If you intend to exploit the system for malicious purposes, understand that the maintainer disclaims responsibility for your actions and will cooperate with authorities to ensure accountability. Use this tool responsibly, document your lab safeguards, and treat every generated signal with the gravity of a live alert.

EAS Station is a comprehensive, open-source emergency alert processing system designed for broadcasters, emergency communications professionals, and public safety organizations. It integrates CAP (Common Alerting Protocol) feeds, SAME (Specific Area Message Encoding) audio generation, and multi-channel alert distribution to provide real-time emergency notifications—all with the explicit goal of replacing utilitarian hardware appliances with a disciplined software stack running on Raspberry Pi-class platforms, SDR receivers, and a handful of HATs.

Mission and Scope

Primary Goal

Provide emergency communications teams with automated CAP-to-EAS workflow, from alert ingestion through broadcast verification, with complete compliance documentation.

Drop-In Replacement Roadmap

Implement the nine requirement areas in the project roadmap—baseband capture, deterministic playout, hardware control, security, resilience, turnkey deployment, compliance analytics, unified documentation, and certification readiness—so the platform can mirror commercial decoder capabilities on commodity hardware.

Key Features

CAP Feed Aggregation
SAME Audio Generation
PostGIS Spatial Intelligence
SDR Verification
Automatic RWT Scheduling
LED Sign Integration
Custom Display Screens & VFD Graphics

Software Stack

Application Framework

Flask: Web application framework with Werkzeug server
Bootstrap 5: Mobile-first responsive UI framework
PostgreSQL + PostGIS: Spatial database for geographic filtering
Redis: Real-time metrics cache and inter-service communication
Systemd: Native service orchestration and management

Data and Spatial Layer

SQLAlchemy: ORM with Alembic migrations
GeoAlchemy2: Spatial extensions and PostGIS functions
pyshp: ESRI Shapefile reader for boundary imports
Requests: HTTP client for CAP feed polling
BeautifulSoup4: XML/HTML parsing for CAP messages

Separated Service Architecture

EAS Station uses a separated service architecture with dedicated services for reliability and fault isolation:

app

Flask web UI, REST API, dashboards. No hardware access. Reads metrics from Redis.

sdr-service

SDR capture, FM demodulation, SAME decoding, Icecast streaming. USB access.

hardware-service

GPIO relay control, OLED/VFD displays, LED sign protocols. I2C/GPIO access.

noaa-poller / ipaws-poller

CAP feed polling, XML parsing, deduplication. Writes to PostgreSQL.

Redis

Real-time metrics, waveforms, command pub/sub. 5s TTL for live data.

PostgreSQL + PostGIS

Persistent storage: alerts, boundaries, configs, compliance logs.

Why separated? Service isolation means a web UI crash won't affect audio processing, and hardware failures won't bring down the dashboard. Each service can be restarted independently.

Core Capabilities

EAS Station provides four main capability areas that work together to deliver complete emergency alert processing:

Ingestion

CAP feed polling, message parsing, and validation

Processing

SAME encoding, audio generation, and content creation

Distribution

Multi-channel output, hardware control, and scheduling

Verification

SDR monitoring, compliance analytics, and audit trails

Maintainer Profile

Timothy Kramer / KR8MER

Project Lead — Putnam County, Ohio

Timothy Kramer is the sole maintainer of EAS Station, an amateur radio operator with deep roots in public safety and mission-critical communications. EAS Station reflects his goal of pairing disciplined engineering practices with experimental emergency communications research.

Amateur Radio Emergency Service

Amateur Radio

Licensed since 2004; upgraded to General Class in 2025. Active in Skywarn weather spotting and emergency communications nets.

Public Safety

17 years of service as a deputy sheriff, building first-hand familiarity with Motorola mission-critical infrastructure and public warning workflows.

Electrician

Currently a full-time electrical panel electrician, bringing hands-on hardware discipline and a methodical troubleshooting mindset to every layer of the stack.

Home Laboratory

Operates a lab of professional-grade radios, RTL-SDR capture nodes, digital paging decoders, and networking equipment used to validate every EAS Station release.

Data Sources & Acknowledgments

EAS Station relies on publicly available data from dedicated professionals and government agencies:

Geographic Data

Putnam County GIS Office
County and municipal boundary data
Greg Luersman, GIS Coordinator
putnamcountygis.com
U.S. Census Bureau
FIPS codes and TIGER/Line shapefiles (rivers, lakes, boundaries)
NOAA National Weather Service
Weather forecast zone definitions

Alert & Protocol Sources

NOAA/NWS
Weather alert data and CAP specifications
FEMA/IPAWS
National alert system integration

Open Source Community

PostGIS Team
Spatial database technology
Flask & Pallets Projects
Web application framework
RTL-SDR Project
Software-defined radio tools
Amateur Radio Community
Testing, feedback, and field validation

For complete dependency and data attribution details, see the dependency attribution documentation in the repository.

AMPR Network Notice

Non-Commercial Use Only — AMPR 44.0.0.0/8
This site may be accessible via the AMPRNet (IP address block 44.0.0.0/8), the globally routed IPv4 space allocated to the amateur radio community by the Amateur Radio Digital Communications (ARDC) foundation. In accordance with FCC Part 97, ARDC policy, and the terms of the AMPRNet allocation, this service is strictly NON-COMMERCIAL. No commercial activity, for-profit transactions, or commercial advertising of any kind is conducted through this AMPRNet-accessible endpoint.

If you are accessing this service via the 44.0.0.0/8 address space, please note:

This deployment is operated by a licensed amateur radio operator (KR8MER) for non-commercial research, experimentation, and emergency communications training.
Use of this service via AMPRNet must remain consistent with FCC Part 97 non-commercial requirements.
Commercial use of the 44.0.0.0/8 block is prohibited under ARDC allocation policy and FCC regulations.
Gateway registration and routing for this node is maintained in compliance with AMPRNet gateway policies.

For information on the AMPRNet allocation and policy, visit ampr.org. For FCC Part 97 regulations governing amateur radio, see 47 CFR Part 97.