Feasibility of an APRS (+ RTL-SDR) plugin for OsmAnd?

[Supermagnum]

Ive been thinking about what it would take to support APRS (Automatic Packet Reporting System) tracking in OsmAnd and wanted to gauge feasibility and interest before going further.
The basic idea would be two parts:

A core APRS plugin — decodes APRS packets (Bell 202 / AX.25 framing), stores station data locally, and renders moving/stationary stations on the map using the standard APRS symbol set (the hessu/aprs-symbols set, Rev H compatible — two-character symbol table + code, e.g. /> for a vehicle).

A lot of aprs transmitters transmission intervals depends on how fast the thing that they are attached to is moving. So It can vary from 3000 seconds to 20 seconds as a example.
A example is this station, it only transmits every 2700 sec.
https://aprs.fi/info/a/LD2GB
Setting a reasonable long timeout on the database, say minimum hardcoded 60 minutes will also prevent moving stations that has stopped from disappearing. That makes it possible to create a route to it. If the station has timed out, it gets automatically removed.

An RTL-SDR companion — talks directly to RTL-SDR hardware over USB (Android USB Host API), tunes slightly off the APRS channel to avoid the DC spike, and does the IF downconversion/DC blocking/FM discrimination/Bell 202 demodulation in software — no external tools like rtl_fm or direwolf required on-device.

Questions for the maintainers/community:

Is there any existing interest or prior discussion about APRS support in OsmAnd? (I couldn't find one, but wanted to check before assuming.)

Would this be better suited as a full native plugin (RTL-SDR access via USB Host API + an in-app Bell 202/AX.25 decoder), or would it make more sense to keep decoding external (e.g. a separate rtl_fm + direwolf/multimon-ng chain on the device or a paired device) and just have OsmAnd consume the decoded station positions via GPX import or a live-tracking API?

Does OsmAnd's plugin architecture currently expose hooks for: (a) live-updating map markers from an external/streaming data source, and (b) custom point symbol sets, so APRS icons could be rendered properly rather than falling back to generic markers?

Happy to contribute if this is something the project would consider, but wanted to check feasibility and interest first rather than open a PR cold.

APRS decoding itself is lightweight. The actual DSP load for Bell 202 (1200 baud AFSK) is tiny compared to other digital modes. People run the equivalent decode chain (rtl_fm + multimon-ng) on a Raspberry Pi to decode APRS packets from an RTL-SDR dongle, and one user specifically noted that because rtl_fm and multimon-ng are so low overhead, they could run this on a Raspberry Pi Zero board for a compact battery-powered handheld solution. A Pi Zero has roughly the same single-core ARM performance as a low-end Android phone from several years ago, so this is a strong signal that a modern Android device's CPU won't struggle.

Android already runs comparable or heavier SDR decoders. SDRangel — a full-featured SDR application — ships an Android version that includes AM, FM, SSB, broadcast FM, DAB, AIS, ADS-B, digital voice, POCSAG, APRS, and RS41 radiosonde decoders, requiring only Android 6 or newer with armeabi-v7a or arm64-v8a CPUs. That's notable because ADS-B and AIS decoding involve significantly higher data rates and more demanding signal processing than APRS's 1200 baud AFSK. If those run acceptably on phone-class hardware, an APRS-only decoder is comfortably within reach.

There's already a working precedent for RTL-SDR + Android + APRS, just via USB OTG cable to a handheld radio rather than direct SDR demodulation — Android users can attach an APRS cable to a handheld transceiver and decode using the APRSdroid app. This confirms the USB Host API path and Android-side AX.25/APRS parsing are both proven and low-friction; the only added complexity in the proposed plugin is doing the FM discrimination and Bell 202 demod in software instead of relying on the radio's onboard demodulator.

APRS's narrow bandwidth (~6 kHz signal inside a ~192 kHz RF capture) and low symbol rate make it one of the lighter SDR decode tasks, well below what Android SDR apps already handle in production. The harder parts of the project are more likely to be USB Host API plumbing/permissions reliability across device manufacturers, battery drain from sustained RF sampling ( not a big issue with a car mounted unit), and UI/plugin architecture — not raw decode CPU load.

The best data one can use to check if things decodes without having any actual hardware is:

SDRangel has an official IQ files page at sdrangel.org/iq-files/. The IQ files there contain examples of the different kinds of signals that can be demodulated in SDRangel, including APRS, and are replayed using the File Input device. These would be actual RF-domain IQ recordings covering the full pipeline from antenna to decoded packet.
There is also one at:
https://www.sigidwiki.com/wiki/APRS

WAV files are included in the gr-APRS/WAV directory specifically for testing purposes — these are AFSK audio files for decoding Bell 202/APRS, used to validate the demodulator and find optimal parameters. That's at github.com/handiko/gr-APRS. These are audio-domain test files (post FM-discriminator), not raw IQ, but they exercise the Bell 202 and AX.25 layer directly.

For those who don't know the frequencies:
APRS Frequency Reference

Complete worldwide list of common APRS frequencies for 2-meter (VHF) operations.
Primary Frequencies by Region
144.390 MHz

North America: United States, Canada
South America: Colombia, Chile
Asia: Indonesia, Malaysia, Singapore, Thailand

144.575 MHz

Oceania: New Zealand

144.640 MHz

Asia: China, Taiwan, Japan (main island)

144.660 MHz

Asia: Japan (Kyushu area)

144.800 MHz

Europe (IARU Region 1 unified APRS frequency), including:
    Austria
    Belgium
    Denmark
    Finland
    France
    Greece
    Hungary
    Italy
    The Netherlands
    Norway
    Portugal
    Slovenia
    Spain
    Sweden
    Switzerland
    Turkey
    United Kingdom
Africa: South Africa
Asia: Russia

144.930 MHz

South America: Argentina, Uruguay
Central America: Panama

144.990 MHz

North America: Vancouver, Canada (secondary frequency for handhelds)

145.175 MHz

Oceania: Australia (nationwide)

145.570 MHz

South America: Brazil

Usage Notes

Primary vs Secondary – Most regions have a primary APRS frequency. Secondary frequencies may exist for specific use cases (for example, handheld operations or local coordination).
IARU Regions:
    Region 1: Europe, Africa, Middle East.
    Region 2: Americas.
    Region 3: Asia–Pacific.
Channel Spacing – Most regions use 12.5 kHz or 25 kHz channel spacing.
Modulation – APRS uses Bell 202 / 2FSK modulation at 1200 bps on these VHF channels.
Bandwidth – APRS signals typically occupy approximately 6 kHz of bandwidth.

PS: I use AI assisted programming because I have a neurological condition related to dyscalculia.
If more than tree people ( Including me ) are interested in this I will start porting from my Navit branch at https://github.com/Supermagnum/navit/tree/feature/aprs-clean/navit/plugin .
It will also include working tests and test results.

[sstriano]

I would love to see this! Mix two of my favorite things!

[Supermagnum]

If one more joins the request list, I will make it happen.

[mariush444]

About your question
https://www.reddit.com/r/OsmAnd/comments/1ukvcuu/map_markers_from_a_external_source/
markers are stored in itinerary.gpx in main osmnd's directory

[Supermagnum]

I have made attempts here:
https://github.com/Supermagnum/OsmAnd/tree/aprs-core
https://github.com/Supermagnum/OsmAnd/tree/aprs-driver
Please be aware of this for both branches:
Supermagnum@679e1e8

[Supermagnum]

Related PR's:
#25364
#25363