APRS still not working?

Byron Butterfield

Enthusiast
Joined
Feb 8, 2021
Messages
4
Location
Richardson TX
I am a new SN person. I am a ham and am trying to use APRS to get on the map. It is not working.

I have seen the old thread(s) from a year or two ago. It did seem APRS was problematic and that seems to be the last I have seen in the forums. Rather than post to an old thread, I am asking the question fresh - "does APRS reporting work?".

I have set up APRS per the setup as best I can. I have used W2YY-9 for an actual radio, and have also tried W2YY-ios for a "cheat" from a phone app. Both reliably appear on aprs.fi (next to my weather station FW9229). I do have !SN! in the comment field.

So, are my attempts to get this to work futile? Does APRS work for getting on the map? (using the RadarScope beacon does work fine).

Byron W2YY
 
I'm a avid user of APRS, but even if the SN APRS interface is fixed, I'm not sure it is a reliable way to report position when chasing. I used to run APRS all the time will chasing so I could see where I had chased, but don't do it as much anymore because there are a ton of places I chase with no APRS digipeater coverage. I would have whole blocks of an hour our more with no points. Your millage might differ based on where you chase.
 
I figure it this way, If it is a reporting option, it should work. I have had situations in my (limited) chasing where one phone service did not work but another did and vice versa. This was true in otherwise populated areas where APRS might be expected to be received. If I could only afford to carry one phone brand, APRS would be a reasonable backup for reporting. In the College of Dupage storm chasing vans, both Verizon and AT&T equipment was carried, but at one point only my T-mobile phone worked (yes, I did scrap T-mobile soon thereafter).

In my RACES work, I always try to make sure all my options work. Yes, Radarscope will be primary. Due to my backcountry Airstream travels, storm chasing and RACES work I have begun to carry both Firstnet (the AT&T first responder phone network) and Verizon. And I carry a SPOT satellite transmitter for my worst case emergencies. I just wanted to prove that APRS is also functional. I don't understand why it would not work when the rest of the world can see my APRS broadcast.
 
APRS isn't a "report" reporting option - only a "position" reporting option, so it really isn't that helpful unless a NWS Met is looking for a report in an area and uses your contact info to call you and ask for it. In my experience I have never been called and my chase partner only got called once and it was an out of area EM who was calling just to see what was going on. In retrospect we should have reported him for abuse of his privs - he had no reason to be calling us. Your mileage may vary - you may chase in an area where an office regularly calls folks.

The rest of the world only sees your APRS broadcast when the RF makes it to a gateway that has an internet connection and sends it to the APRS-IS system. The Spotter Network then has code that queries the APRS-IS looking for comments with !SN! in it. While I have no affiliation with Spotter Network other than a user, and no knowledge of their code, when this problem first came up I did research the issue some and I will say that parsing comments at scale is not a simple task given the APRS-IS does not appear to have a API that allows one to directly query for parts of a comment string. Given that APRS is only a "position" reporting method and not a "report" reporting method, I can understand why fixing this isn't supper high on the priority list of the volunteers for graciously donate their time to run Spotter Network.
 
Au contraire. APRS is specifically a message reporting system. Position reporting is a by-product. Per Wikipedia: "Automatic Packet Reporting System (APRS) is an amateur radio-based system for real time digital communications of information of immediate value in the local area. Data can include object Global Positioning System (GPS) coordinates, weather station telemetry, text messages, announcements, queries, and other telemetry." There is also an email capability.

If all spotters had APRS radio capability, with a few mobile digipeaters, all spotting could continue even with phone systems down. I know this is a stretch, but it is a rational capability. I have participated in our local MS150 (150km) bike rides where we are using an alternate APRS frequency to monitor all SAG vans, ambulances, police, race lead, tail and aid stations. Spotters, as I have learned, do tend to congregate leading to this being a practical use of APRS (I don't really expect this to happen, it is only an example).

VHF communications over a 5-mile radius area is practical, especially in the plains. With the mobile digipeaters, the range of and all-radio APRS (no internet APRS-IS), can easily cover a much larger area.

I used to have my home weather system broadcasting on APRS. No position reporting per se, only the weather data at my house (yes, a fixed lat/long in this case).

Also, data from APRS-IS are just ASCII strings. No query is performed, you receive all the data or a filtered subset. Server-side filters are used to limit the data that is received from the APRS-IS servers so any traffic volume issues can be managed. The filters can be geographic or data oriented. Parsing strings is not particularly challenging.

If all spotters used the same symbol (e.g. Skywarn, an existing APRS symbol), then the data received from APRS-IS can be filtered to only receive the "spotter" symbol. (I did not realize, until finding the Skywarn symbol, that there is also a tornado symbol). Off the cuff, this sounds like a better filtering option than using !SN!.

In my previous life, before retirement, I was a senior systems engineer of a world-wide informational interactive broadcast that transmitted and received 2400 bps data 24/7. That system was not unlike APRS. I have written parsers for the data myself and that system was more difficult because it was bit-oriented messages, not just an ASCII strings. Data frame synchronization within the continual bit-stream was the most challenging aspect to the parsing problem.

In the near future, I intend to expand my SPOT message capabilities for forwarding my position/data to APRS and to other services. There is a service to forward my SPOT reports to APRS (APRS pro SE for $13.99/yr). I currently only have the "fixed message" SPOT option, but a full text message terminal is available. Because SPOT is a LEO satellite system, I can be assured to always be tracked on APRS, send emails and perform spotter reports.

Satellite data is relatively expensive but imagine only one or two mobile satellite uplinks to APRS-IS for a concentration of storm spotters. No need for phone service to work. (Sorry, I am getting excited. It is the techie in me.)

If a volunteer is needed to help get APRS running, I am available.

Byron W2YY
 
I will correct myself on one item. I now read Randy's comment as APRS is not a reporting option on the Spotter network. For this application it is only a position application. My mind jumped to the normal APRS application in general. Sorry for my poor reading.
 
Correct. While APRS has in the past been transferable to reporting position as an SN dot, it has never been a viable means to actually send in reports. In areas with decent APRS coverage, some net controllers on Skywarn nets will keep an eye on it, particularly if you mention when checking in that you have your beacon running. But there's a good chunk of chase territory with no i-gates or digipeaters, which can be a limiting factor.
 
I will correct myself on one item. I now read Randy's comment as APRS is not a reporting option on the Spotter network. For this application it is only a position application. My mind jumped to the normal APRS application in general. Sorry for my poor reading.
No worries. Yes, APRS messaging is really cool and I have used it over the years. Unfortunately SN was never setup to take real reports from APRS. Next time I talk to AE5PL, I will ask him about the possibility of a SN report interface like he has for WHO-IS. I was just in an ARES zoom meeting with him this weekend, and I wish I would have thought to ask him.
 
So I actually have something of a solution for this. I've written an individual APRS-IS parser. It works pretty much like Byron is talking about. The user sets up their callsign and SpotterNet information. As the program runs, it's listening to the filtered APRS-IS stream for your callsign. Any time it receives a position packet, it checks for a user-defined comment (like !SN!) and if that exists (or none has been configured so all position packets are sent) it uses the SpotterNet API to update the user's position. It's on GitHub, but I currently have it set to private while I finish tinkering and making sure all i's are dotted and t's are crossed. Now this only works on an individual level and via the internet. Meaning the intent is for a user to leave this running on a home computer with dedicated internet while going into the field. Using it in the field would just be adding an extra step, if you already have internet, just use another app.

But my stance is like Byron's, the more streams of communication, the better. Now I chase primarily in Georgia where we have hills and some of those hills have APRS Digipeaters/iGates so frequently, those can see up to 70 miles away (maybe further?). My cell service might get 5-10 miles if I'm lucky, and due to the different propagation, is more likely to go in and out than APRS. So my intent is to use both. I use a RaspberryPi running GPSd in my truck with a GPS puck mounted behind the cab so I get good GPS signal. From there, it feeds not only Direwolf which goes to my radio, but I also have a Python script to send the position information to SpotterNet over my 4g network.
 
To add to the above, I have released the APRS solution I wrote, see this topic: Three new software utilities for chasers

Excellent stuff. This appears to be a client that sends to APRS and if the "!SN!" is present, use the SN REST API, is that correct?

I've been working really hard to try to get APRS data ingested properly but with there being no clear-cut firehose server it's been difficult.
 
Excellent stuff. This appears to be a client that sends to APRS and if the "!SN!" is present, use the SN REST API, is that correct?

I've been working really hard to try to get APRS data ingested properly but with there being no clear-cut firehose server it's been difficult.
!SN! is optional and configurable, but essentially, yes, that's what it does.
 
I am a new SN person. I am a ham and am trying to use APRS to get on the map. It is not working.

I have seen the old thread(s) from a year or two ago. It did seem APRS was problematic and that seems to be the last I have seen in the forums. Rather than post to an old thread, I am asking the question fresh - "does APRS reporting work?".

I have set up APRS per the setup as best I can. I have used W2YY-9 for an actual radio, and have also tried W2YY-ios for a "cheat" from a phone app. Both reliably appear on aprs.fi (next to my weather station FW9229). I do have !SN! in the comment field.

So, are my attempts to get this to work futile? Does APRS work for getting on the map? (using the RadarScope beacon does work fine).

Byron W2YY

Byron, if your issue is that you’re not showing up, try removing your SSID (-9). IIRC, the APRS servers won’t pass the !SN! with an SSID call sign. As others note, real-time apps are more efficient, but I still include it, & run APRS most of the time.
Joe
 
Byron, if your issue is that you’re not showing up, try removing your SSID (-9). IIRC, the APRS servers won’t pass the !SN! with an SSID call sign. As others note, real-time apps are more efficient, but I still include it, & run APRS most of the time.
Joe


Unfortunately, the SSID is a requirement to broadcast a beacon on some radios. With that being the case, using a mobile device based app or the Windows client is still the best viable option.
 
Back
Top