Is it possible to follow folks who use APRS with just the android app on a phone or tablet and not have a radio with APRS? I was just asking because I just bought a new Yaesu FT-3100 single band radio with no frills or thrills for just simplex communications but would be interested if I could still track folks with the application with APRS? Not sure if that makes sense?
I use aprs.fi for this. If you pull up that map it will show you all the objects in the area and over time, or you can filter for exact call signs.
Yup, online APRS feeds are an option.
https://aprs.fi/
https://www.aprsdirect.com/
But as a network architecture APRS is intended primarily about over-the-air RF and hardware requirements, the Internet traffic runs in parallel and at a lower priority as it's not a core network function.
In fact the whole point of APRS is to be a data network that is fault tolerant independent of normal networks like the Internet primarily so that you can run without normal infrastructure, whether that's an emergency or just supporting a marathon where cell coverage is spotty.
Soooo.....
i've been having issues with aprs.fi and tracking fat bastard. originally, i was thinking it was an issue with aprs.fi, but now i'm thinking it might be my tiny tracker crapping out. is everyone else still getting good tracking info on aprs? mine is hit or miss on tracking....on a trip to new mexico, it got a five mile stretch outside of tres piedras and none of the rest of the trip that day. maybe i need to get my 710 pushing my signal and pull the tiny tracker out
Problems like this arise if you're using an Internet service such as aprs.fi as your primary display interface. All the stations will have had to traverse a lot more connections to show up on a map.
What TinyTracker and radio are you using?
Lots of technical stuff below...
If someone's technically curious APRS is essentially a Bell 202 AFSK X.25 packet switched network that functions like the telecom PTSN did, if you made it completely wireless, until about 25 or so years ago.
Like any communication network there's fundamental things that have to work. There's not tuning your modem for the correct levels, RF interference and packet collisions (more than one station talking at once) need to be addressed.
The most simple network is two vehicles talking. So you have data sources (e.g. GPS) or clients (APRSdroid) each talking directly to their TNC (semi-intelligent modem) and their radios over the air. This requires a fair amount of magic to happen but we're lucky that APRS is
highly tolerant at 1200 baud so for the most part we can plug-and-go without much effort and have things at least sort of work.
So as not to rehash even more technical mumbo jumbo, these dudes have great analysis of Bell 202 and how it relates to drive levels, twist and time delay parameters in your configurations.
https://owenduffy.net/blog/?p=2035
https://www.febo.com/packet/layer-one/transmit.html
Beyond this mix in a digipeater and complexity increases. A digipeater is kind of like a repeater most people understand conceptually. They operate on a single frequency instead of two, which means they aren't as simple as connecting a receiver to a transmitter, though. They have to temporarily store the packet and re-transmit it a moment later.
But that's OK since a digi has to actually perform a little bit of processing anyway. They have to add their call sign to the packet (every station has to annouce itself and a digipeater is no different) and decrement the path counter (e.g. make WIDE2-2 into WIDE2-1) to decide if it should repeat or not (the number in the path variable tells a digipeater if it has anything to do).
It's not a great deal of processing so the hardware is very modest. It's not attempting to understand the whole packet. It's just reading and writing a handful of bits in the routing fields so turn-around delay is very short. It's probably already got the new packet ready to transmit as soon as you unkey the tail tone on your radio. So the total air time is nearly just twice your original packet length (e.g. the digi has consumed the least amount of air time theoretically possible).
Now to get the Internet (which is called APRS-IS, APRS-Internet System) you add to this network the concept of a gateways, which are a special client that fully decodes your APRS packets (which are formatted as AX.25, e.g.
Amateur X.25) and reformats the data into IP (Internet Protocol) packets. It puts these newly made packets on the APRS-IS network where other applications such as aprs.fi can do their work with them.
Now this is already at least one layer of added complexity, thus decreased reliability. The problems that can occur are that a gateway doesn't hear you or not well enough to decode or it mangles the decode for whatever reason (collision, receive errors or packet formatting errors). A gateway can be more prone to missing packets than a simple digipeater, especially if the gateway is trying to act like a digipeater as well. Most high level digis don't attempt trying to be gateways and rather focus on turning around packets ASAP with minimal delay.
A gateway runs usually on a computer. It has to do all the radio and modem stuff like any other APRS station but also has to have an Ethernet or WiFi stack and do the actual packet translation. Any packets that might come in while the gateway is working will either have to be buffered and processed later or get ignored. So the total processing time is longer and it might not be ready to process a packet that is jammed too soon right in behind the one it's working on. If the gateway is using an old Raspberry Pi 2 it's going to be less responsive than a RPi4 or repurposed Windows/Linux/macOS computer.
And even if worked it still only
maybe gets it to the Internet. The gateway had to work and have a good connection to its ISP before it goes to a core of APRS-IS servers that hold
all APRS objects from every station on the planet. It could be thousands of updates every second. The APRS-IS servers are good at fault tolerance and load balancing and the admins are good at what they do.
http://aprs-is.net/
But it's all done by volunteers on donated equipment through ISP either donated or paid for by donations. So there is no guarantee of 100% reliability or uptime. I can't honestly say I've ever seen a problem that I could attribute to the APRS-IS itself but then again from the perspective of a user there's no way I could ever know 100% of my packets actually make it to the Internet either.
And consider that a gateway may be bidirectional, so it has to know when a packet intended for you shows up on APRS-IS. It then must process and transmit it. It only knows this if you have transmitted a position packet previously so now you have a geographic location tagged. This function is necessary otherwise whenever a message is sent it would be transmitted by all the thousands of gateways around the world, which is impossible. For this reason many gateways are one-way from RF-to-Internet only and won't listen for Internet-to-RF traffic at all. In totality a gateway might actually be doing a lot of tasks and like you know from your desktop or laptop the more applications you're running the more processor you need, risk of crashing or conflict (e.g. you get the equivalent of a spinning ball if the gateway is doing something else when you want it to get putting your position packet on APRS-IS).
If you missed one packet, the probability that it's due to an intermittent APRS-IS issue is small but plausible. OTOH, it's very safe to assume that if you miss
more than one random packet or you see a repeatable pattern it's very likely
not APRS-IS but either the gateway you're trying to use or the end client such as aprs.fi. And the website such as aprs.fi are also running on donated servers put together and maintained by a volunteer with a day job. They are not infallible. There again, though, if it's a random missed packet it's possible but if you can repeat the problem then it's almost definitely not on the aprs.fi or aprsdirect.com side.
Now if you're doing this afield with your cell phone your carrier will have had to put another bridge from the regular Internet to their cellular data network for IP traffic and you of course have to actually have decent enough cell service for it to work at all.
FWIW, this is why when asked I highly recommend that you do not rely solely on aprs.fi or other Internet service as your APRS client. If you want to really use APRS then figure out a way to talk directly to your TNC using a Win/Linux/macOS client (Pinpoint APRS, APRSIS32, YAAC, QTH app, etc) or APRSdroid for Android or the actual aprs.fi app for iOS (which does open a can of worms) for local (e.g. direct or digipeater'd) RF traffic. At the moment you can use serial-to-Bluetooth for Android device but if you have an iPhone you are basically limited to a Mobilinkd TNC3 and aprs.fi app (not the web, the actual app from the App Store). With a TM-D710 or TM-V71 you can dedicate one side to be a full time APRS radio. With the Yaesu radios only the FTM-350 and FTM-400 can operate fully independent APRS on one side.
None-the-less, to use cell-based aprs.fi it's a convoluted path. To hear an RF APRS station you have to have the initial packet transmit, be heard over the air by a gateway (with maybe a digipeater or two). That gateway has to correctly translate and send it on to APRS-IS, which then requires whatever Internet client to see it show up in the database and display it over a cell data connection.
Point being here is that hearing stations directly vs seeing them on APRS-IS at home on a browser vs on your cell phone using LTE is each a significant reduction in your chances for having a true picture of your local and regional networks.
Digipeaters and gateways only work as well as they can but if the signaling is too far off they can't work miracles. The high level digis are generally very good and are generally coordinated so that they work together. The lower level fill-in digipeaters people set up are a coin toss whether they help or hurt overall network throughput. But regardless going though a digipeater subjects your packet to collisions and the more hops you have increases the risk of a collision.
Now gateways can be sent up with almost no coordination, which means one might work excellently while another is dodgy. If you have a lot of them around the good ones will handle more traffic by their nature. If you don't have a ton then the reliability is completely dependent on how good it works and how well you've tuned your system. If for whatever reason they don't play nice then you simply get nothing showing up on APRS-IS even if it works locally with other stations or sounds OK on the air.