APEX stands for “APrs EXtended”; It’s a new protocol which enhances the older APRS protocol and attempts to deliver on many of the features the original APRS promised to deliver one day. All while still remaining backwards compatible with older APRS nodes.

APEX defines both a new protocol and a new paradigm. Since much of the new protocol will not run on existing hardware APEX also includes a Python reference implementation that will provide a full APEX application out of the box. Since APEX is backwards compatible with APRS it can fully utilize existing APRS hardware to route APEX packets across the network. Though only APEX capable stations would be able to make full use of the information in an APEX packet.

The software for the project can currently be found at the APEX GitHub page or go to the APEX download page.

Why something new?

The older APRS network relies heavily on internet connectivity. The only way you can get a packet to a distant destination, when local internet is down, is to get the packet to a station with an internet gateway. Older APRS packets are incapable of being routed long distances without the use of internet gateways. This opens the APRS network up to all sorts of vulnerability in a disaster scenario where area wide internet access may be lost.

One way APEX addresses this is by providing path aliases that are capable of cross-band repeating, combined with a mechanism for identifying which ports a digipeater provides. The VHF-to-HF cross-band path aliases would never be used for routine traffic, due to congestion concerns, but during an emergency even legacy APRS devices can benefit from the APEX paradigm by being able to get emergency messages out across HF channels efficiently.

Part of the effort is to bring the United States up to date with Europe’s infrastructure as well as produce an international standard for global radio networks. Across Europe there is a multi-band Robust Packet Radio and APRS network in place across 4 HF bands and one or more VHF/UHF bands. The European system also includes a backbone of repeaters with standardized digipeating configurations. However the same multi-band coverage has yet to be seen consistently across the USA.

APEX allows for multiple HF networks, and allows for paths that can cross between them; APEX will prioritize short-distance traffic over HF bands such as 160m or 80m, as well as long distance traffic over 30m dynamically. Of course the original transmitter of the packet may also explicitly specify the desired bands to use in the packet’s path.

In the end we hope to provide a standard which supports the current APRS network and paradigm while still expanding and improving it to make the network more resilient for emergency use as well as during normal operation.


It is important that we build APEX from the lessons we learned from APRS. This means where possible we will use existing standards, or try to resolve any differences between regional standards. Any standards introduced must be considerate of, and backwards compatible to, the existing networks.

The final network envisioned, once APEX reaches pervasive coverage, would be an efficient, self-reflective network. Stations would announce its cross-port capabilities and wide path packets will be rate limited to reduce congestion.

The APEX reference implementation can be used as a full stack reference implementation; it is a fully functional Python 3 application, completely configurable, and ready to be run as a digipeater station capable of interfacing with any number of TNC across any number of bands.