aprs.fi for Android is here!

For 10 years, every time a new version of the aprs.fi iPhone app came out, the first question was always the same: "when can we have it on Android?" For a long time I was pretty sure the answer would be "never" — but here we are! The aprs.fi app for Android is now available on the Google Play Store.

Despite being brand new, the Android app is remarkably complete. I believe it has full feature parity with the iPhone and iPad app — and then a few extras on top. It can talk to USB and classic Bluetooth TNCs (Kenwood TH-D74/D75 and friends!), and it can draw KML and GeoJSON overlay files directly on the map. Admittedly I also added the KML & GeoJSON overlay support in the most recent iPhone app version, too, I hope you don't mind.

The app gives you immediate, real-time access to current APRS position information, weather reports, telemetry graphs, and more. Zoom and browse around the world and see stations instantly — no waiting. It runs directly on top of the same reliable and fast aprs.fi database that powers the web site — just like the iPhone app has been doing for 10 years!

Here are some of the main features:

• Search callsigns and addresses, with quick search-as-you-type and search history, showing APRS data and maps instantly
• Track multiple stations at the same time
• Filter the information shown on the map (weather stations, AIS, powerful custom filters)
• View weather, telemetry, and statistic graphs
• Beacon your position on aprs.fi
• Attach to a transceiver over a wireless connection to a Bluetooth, BLE, WiFi, or USB-attached TNC, and receive and transmit position beacons without the Internet
• Dark Mode support for an ergonomic viewing experience in low-light environments
• High-resolution graphics for high-DPI displays, with the full APRS symbol set
• KML and GeoJSON overlay files on the map
• Views designed for both Tablet and Phone layouts

Buy the app — get the web site for free!

A quick word on pricing and subscriptions, because this is important to understand before purchasing. The pricing model is the same as on iOS: the application itself is paid, but it is not expensive — cheaper than a pint of beer in Helsinki, it lasts much longer and is 80% more healthy, and you get the web site on top for free. Basic features and many new future features are available without a subscription fee.

Some features additionally require the Extra Features subscription (also not expensive — about 0.58 €/month with the yearly plan). It sometimes comes as a surprise to people who didn't read the application description, so please read the full description before purchasing. These features are currently included in the Extra Features package:

• APRS text messaging
• High-performance software DSP modem (1200/300 bit/s) with GPU hardware accelerated oscilloscope and waterfall views
• APRS-IS beaconing, with up to 10 callsign profiles
• RX iGate functionality
• Long time ranges in map and graph views

Why subscriptions? In-app subscriptions provide a sustainable business model. They ensure continuous interest in developing and maintaining the application and its backend service, even after the finite number of interested APRS users have already purchased the app. I intend to implement subscription sharing between Android and iOS via the aprs.fi user account, but it's a bit complex and not there yet.

A few notes on requirements and availability: the app uses some modern functions of the Android platform and requires Android 11 or newer. On some older devices you might need to upgrade Play services to their current versions — Android 11 without updates installed probably will not work. The app is currently only available on the Play Store, and it's not possible to run it on de-googled devices. I might look at other stores later.

The new Android APRS app is available here!

The user guide is available online and inside the app.

Have fun! 

RX-only igates considered beneficial to the network

As probably most of you know by now, besides running the aprs.fi web site, I'm also one of the two main authors of the aprsc server software. aprsc runs on most of the APRS-IS servers where iGates usually connect.

There have been recent and strong claims saying that receive-only (rx-only) iGates destroy the two-way messaging feature of APRS. This has been claimed in blog posts and facebook threads. Some people ask me if this is true.

No, it is not true. Receive-only iGates do not break messaging if there are transmit-capable igates nearby, and those transmit-capable iGates are connected to an APRS-IS server which has a full APRS feed. All aprs.net and aprs2.net servers, where iGates normally connect, do have a full feed. No problem!

Messaging would work from 1650m / 5400 ft above Vihti, even in the presence of
RX-only iGates, as long as there is at least one TX-capable iGate.

If there are no transmit-capable (TX) iGates around, two-way messaging will not work, of course. Having a transmit-capable iGate would therefore be better, but receive-only iGates are easier to set up technically, they are cheaper (receivers are practically free now), and licensing for automatic transmitters is difficult in many countries. Where transmit-capable (TX) iGates are present, receive-only iGates do not break the TX iGates, they just improve reception coverage. For messages, too.

Just to make it perfectly clear: If there are TX iGates present, additional RX-only iGates improve messaging performance. For the RF-to-IS direction (and ACKs for the IS-to-RF messages).

The common incorrect claim is that the APRS-IS server sends the message only to the latest iGate which heard a station. In fact, the APRS-IS servers (both javaprssrvr and aprsc) send the messages to all iGates which heard the station recently. In aprsc, "recently" means "within 3 hours", and I believe javaprssrvr uses something similar.

The server maintains a list of recently heard callsigns independently for each iGate client. There's a separate list of heard stations for each iGate client. When the server has a packet to pass on, it will look at all connected clients, and for each client, if the recipient of the message is found from the list of recently heard stations, the message will be sent. The scanning will not stop; the message will be given to all clients which heard the station.

I can confirm that we have written the software to do it like this, and since it is open source, you can see the code yourself. The automatic test case also validates that the server keeps working that way, so that there won't be a bug creeping in the future to break it accidentally. I've also tested that javaprssrvr behaves like this – I've run the test cases against it to confirm compatibility.

There may be problems when there is a server with a filtered feed involved (possibly a server software running at the "client" without having a full feed), but those are rare and known to be problematic. All Tier2 servers have a full feed (aprs2.net ones), and so do the core servers.

The real problem is that a user, seeing one-way beaconing to the APRS-IS works, may well expect two-way messaging to work too. And when it doesn't work, there's only a timeout, no immediate feedback saying "sorry, this won't work now", which is what a sensible system would do today.

Even in that case, an rx-only igate is better than nothing! I wouldn't be so harsh against them, since the step from RX-only to TX-capable may be a bit difficult for many.

Bottom line:

In each area, there should be one TX igate, maybe two. More may create QRM as the same messages will be transmitted from APRS-IS to RF many times. RX igates will not break messaging if there are TX igates around – they just improve RX coverage.

This picture may at first seem irrelevant, but it does show me working VHF in AM (122.825 MHz),
and Flarm on 868 MHz to OGN (which runs aprsc). Flarm antenna visible in top left corner.