Calling CQ with APRS: Discovering APRS On The Air

How APRS OTA turned packet messaging into real operating—and gave me the APRS practice I needed

Most amateur-radio operators who experiment with APRS begin in roughly the same place: we configure a callsign and SSID, beacon our position, and then open a map to see whether our little dot appeared.

That moment is satisfying. It proves that the radio transmitted a packet, that an iGate heard it, and that the APRS network carried it where it needed to go.

But then what?

I had already begun discovering that APRS could be much more than a dot moving across a map. It is a two-way tactical communications system capable of carrying messages, weather information, bulletins, objects, telemetry, and other useful information. Still, knowing what APRS can do is not the same as having a reason to use those capabilities regularly.

Then I discovered APRS On The Air.

Something to Do with APRS

APRS On The Air—usually shortened to APRS OTA—combines elements of an operating event with an APRS messaging bot and a live website. One operator hosts an operation, other operators chase that host, and the OTA bot relays the messages and records the resulting contacts.

The idea came from Jared, K0TFU, who saw the same problem I had encountered.

“I think APRS is really cool,” Jared told me. “But most people who get interested in APRS figure out how to send a position report and then don’t know what to do after that.”

He wanted to create something that would connect operators who were ready to get on the air, encourage newcomers to do more with APRS, challenge experienced operators to expand their skills, and add some friendly competition through points, achievements, and leaderboards.

The result has some of the flavor of a Parks on the Air activation, but the operating takes place through APRS messages.

There is no account to create and no special APRS OTA application to install. If you can send an APRS message to the station OTA, you can interact with the system.

Hosting and Chasing—One Packet at a Time

An APRS OTA operation has three participants: a host, a chaser, and the OTA bot sitting between them.

A host sends the HOST command to OTA, followed by a brief description of the operation, and then transmits a position report. The operation appears on the APRS OTA website, where other operators can find it.

A chaser sends a message addressed through the bot to the host and also submits a recent position report. The bot forwards the message and the chaser’s grid square to the host. If the host replies with QSL, the contact is recorded and both stations receive a digital QSL card.

When the host is ready to close the operation, a QRT or DONE command tells the bot that the station is leaving the air.

That sounds simple when condensed into a few paragraphs. On the air, every step requires an actual APRS packet to make the trip.

A packet may get through on the first transmission. It may take a second attempt. It may be heard and forwarded more than once, or it may disappear into the ether. Sometimes I had to wait for a response before knowing whether the command had been received. At least once, aprs.fi identified one of my transmissions as an invalid message packet while APRS OTA understood it and responded anyway.

That is packet radio. Either the frame decodes or it does not—and sometimes different systems disagree about exactly what they received.

My APRS Training Ground

One of the greatest benefits of APRS OTA has been the sheer amount of APRS practice it has given me.

Before this, I could transmit position reports and perform basic APRS operations. APRS OTA gave me a reason to work with messaging repeatedly and with a purpose.

I have practiced addressing messages correctly, working within APRS message-length limits, sending position reports when requested, reading acknowledgments, watching the raw packets on aprs.fi, and determining when to wait and when to retransmit.

I have used PING to test whether the OTA bot can hear me. I have hosted operations, chased other hosts, confirmed contacts with QSL, and successfully closed operations with QRT. I have even chased another operator while hosting an operation of my own.

These are not exercises performed once from a checklist and then forgotten. They are operating skills reinforced through repetition.

Every operation teaches me a little more about how APRS actually behaves—not how it is supposed to behave in a manual, but how it behaves when packets are moving through radios, digipeaters, iGates, APRS-IS, and automated services.

APRS OTA has made me a better APRS operator because it gives me something meaningful to accomplish with each packet.

The Phone Is the Interface—The Radio Is the Path

My favorite way to use APRS OTA combines the ease of a smartphone application with a legitimate radio-frequency path.

I connect the aprs.fi Android app to the Bluetooth KISS TNC in my BridgeCom Maverick. The phone gives me a familiar touchscreen interface for composing and reading APRS messages. Typing a message on my Galaxy S25 Ultra is far easier than entering it one character at a time through a handheld radio’s keypad.

The phone, however, is not replacing the radio.

With the application connected to the Maverick’s KISS TNC, the message travels from the phone to the radio over Bluetooth. The Maverick turns that data into an APRS packet and transmits it over the air on 144.390 MHz. Incoming APRS packets travel in the other direction: they are received by the Maverick over RF, decoded by its TNC, and passed over Bluetooth to the phone.

The smartphone provides the convenient human interface. The Maverick still performs the radio work.

After an iGate receives my transmission, APRS-IS can transport the packet across the internet to the OTA bot. A reply can cross APRS-IS before an iGate returns it to the RF network. APRS OTA’s hosting rule recognizes this reality: APRS-IS may carry traffic through the middle, but a host’s outgoing first leg and incoming last leg must occur over radio. The full rule is explained in the APRS OTA Handbook.

That combination appeals to me. I do not have to choose between a convenient modern interface and traditional radio operation. I can use the phone to make packet messaging comfortable while the actual station continues to transmit and receive over amateur-radio frequencies.

Exploring Other Paths

I have also experimented with reaching APRS OTA through DMR messaging.

Using my Maverick and HamSpot, I successfully sent APRS messages through the BrandMeister network to the OTA bot. The bot’s reply indicated that it recognized my message as having arrived via RF. In one sense, that makes sense: my radio transmitted RF to the hotspot, the network carried the message, and the reply returned over RF from the hotspot to my radio.

It is a different route from conventional analog APRS on 144.390 MHz, but it demonstrates something important about APRS OTA: operators are already finding unexpected ways to reach it.

Jared has seen operators use APRS over HF, JS8Call, and other nontraditional paths. He has watched operations conducted during road trips, pizza-delivery runs, visits to Costco parking lots, and from high in the Alps.

APRS OTA is not tied to one kind of expedition or one ideal station. An operation can begin wherever an operator happens to be.

Making Messy Radio Traffic Work

Jared is an experienced web developer, but building APRS OTA required him to confront the untidy realities of radio.

A single transmission can be heard by several digipeaters and iGates. Multiple copies may then arrive through different routes. APRS OTA must recognize that those packets represent the same original message, remove the duplicates, standardize the information, and preserve the correct exchange so that a QSL confirms the intended contact.

From the operator’s side, the process appears simple: send the message, receive the reply, and complete the contact.

That simplicity is the product of a considerable amount of work behind the scenes.

My experiments have occasionally uncovered behavior for Jared to examine. That is part of the fun of using a new system while it is still being actively developed. I am not just learning how APRS OTA works; real operators are helping show its developer how APRS behaves across different radios, applications, networks, and operating paths.

Is It a QSO?

Then there is the question certain to produce a lively discussion among amateur-radio operators:

Does an APRS OTA exchange count as a QSO?

World Radio League offers PACKET as a mode. QRZ provides PKT. Other digital contacts involving very limited exchanges are routinely logged, and DMR and EchoLink contacts have increasingly found homes in modern logbooks.

An APRS OTA contact involves two licensed amateur operators exchanging callsigns and messages through an amateur digital mode. The host confirms the exchange, the service records it, and a QSL card is generated.

On the other hand, the OTA bot participates in the exchange, APRS-IS may transport part of the traffic over the internet, and chasers are not always required to use RF. Some operators will consider those distinctions important.

I have my own thoughts, but I do not believe the discussion is settled—and perhaps it should not be settled too quickly. Amateur radio has always evolved by experimenting first and debating definitions afterward.

If FT8, DMR, EchoLink, and other network-assisted or highly automated modes can produce recognized contacts, where should APRS messaging fit?

That is a question worth leaving open.

What Comes Next

APRS OTA is still new, and Jared has no shortage of ideas.

Leaderboards are being developed to recognize operators who earn the most points or host the most operations. Other application developers have expressed interest in integrating APRS OTA information into their own software.

Jared also envisions more ways to earn bonus points. One idea is an “Elmer stamp” awarded for making contact with someone during their first few APRS OTA operations. Other stamps could recognize international contacts, operators on the water, Summits on the Air locations, and perhaps eventually Parks on the Air.

The recently added BLAST command already allows hosts and chasers participating in an operation to exchange group messages. Instead of the bot merely arranging one contact at a time, an operation can begin to feel like a small community gathering on the APRS network.

Where this will lead remains to be seen. That is part of what makes it interesting.

There Is a Person Behind the Packet

APRS OTA has not replaced the things I already enjoyed about APRS. It has added a new reason to use them.

My position report is no longer only a dot proving that my beacon reached an iGate. It may be the packet that qualifies me to chase an operator, begins an operation of my own, places a contact on a map, or helps another ham discover what APRS can do beyond position tracking.

The technology is layered: a phone application, Bluetooth, a KISS TNC, a handheld radio, 144.390 MHz, digipeaters, iGates, APRS-IS, a messaging bot, and a website.

But behind all those layers are two amateur-radio operators trying to make contact.

Once again, all that technology ultimately serves a wonderfully simple human purpose:

“Hi. I’m Eric.”