[aprssig] Beacon parsing help

Andrew Pavlin spam8mybrain at yahoo.com
Fri Mar 22 18:01:09 EDT 2019

 See embedded comments below

    On Friday, March 22, 2019, 5:14:50 PM EDT, Jim (List) <jim.list at stuckinthemud.org> wrote:  >Looking for help from someone experienced in parsing ARPS beacons to assist
>in understanding differences in the position beacons I'm seeing from various
>Are these differences recent changes to the APRS spec, or are they clients
>that are just sending bad data?

>From looking at your examples (and similar ones I have seen), they all look liketypos from hand-creating beacon messages.
>Monitored beacons are listed below, with a note of what I'm seeing wrong.
>K3NAL-1>BEACON,qAR,KK4ZWW-1:!146.64-000000z3812.05n/07623.07WrT146 R25 NetTu
>1930 Mtg 4th Th
>*** Appears to have a frequency, a dash and a time inserted before the Lat,
>plus the Lat letter is in lower case 

This looks like someone is trying to send an Item (timestamped non-station Object) for a repeaterrather than a self-beacon, but they used the prefix character "!" for a self-beacon rather than
")" for an Item, and they're missing the "!" between the Item name and the latitude to indicatethis is a live Item (or an "_" to indicate it's a dead Item).

>W9GO-3>BEACON,qAR,KC9MWQ-1:!146.91-4028.82N/08609.33W# Kokomo Repeater Club
>*** Another with what looks like a frequency and a dash before the Lat

Same as above, except they should have used ";" instead of "!" to indicate a non-timestampedObject. Also the Object name (between the ";" and the latitude digits) is missing the extra space characters to pad the Object name out to 9 characters, plus the "*" character to indicate a liveObject or "_" to indicate a dead (out-of-service) Object.
>#QTH T=18.5C, U=13.2V, WX3in1Plus2.0
>*** Has "222024S" inserted before Lat
Looks like a timestamped Position Report for a digipeater, but they used the wrong prefixcharacter (should have been "@" or "/" for a timestamped position) and didn't use a standard time zone character on the end of the 6-digit timestamp; the allowed characters are 'z' or 'Z' (for UTC time in day-of-month, 24-hour, minute) or "/" or "l" (for site-local time, same format)or "h" (for UTC time in hours/minutes/seconds).

>71304/ 13.0V
>*** Too many digits after the decimal in both Lat and Long

Indeed. There is a different format where the extra digits of precision go in an encoding in thefree-text comment, but they aren't supported here.
>W3EPE-3>APTT4,WIDE1-1,WIDE2-1,qAO,BEARCK:!4048.31N07531.34W#PHG51304/ W1 
>*** No symbol table ID

Correct analysis; the symbol table ID character (after the "N") is missing.
>POINT6>APN382,qAR,N6MLD-1:!4702.46NS11359.W#PHG5860/ 11,22,21,33 harc's pt6
>thanks mso wx.
>*** No digits after the Long decimal

Correct analysis; the digits need to either be present or replaced with blanks for positionambiguity.
>*** Lat N/S and Long E/W duplicated

Never seen the APRS-IS backbone report _all_ the servers the packet was relayed through before.Analysis correct; why they doubled those characters, who knows?
>N/01117.042E`Radiosonde Tracker - Based on kxyTrack 1.0-1805
>*** Too many digits after the decimal in both Lat and Long

Again, correct analysis; they should use compressed-mode position or the extended-precisiontoken in the free-text comment if they want more digits of precision.
>DO2ATR-10>APGW1K,TCPIP*,qAC,T2KA:!5005.05N/007 0.07E#DO2ATR iGate APRS
>432.500 JO30MU
>*** Spaces in the Long that don't conform to position ambiguity

Correct analysis.
>Jim, G1HUL

Amazing, the amount of bends you need to put into parsing code to handle the non-standardformats.
Andrew, KA2DDOauthor of YAAC ("Yet Another APRS Client"), which has to do all of that parsing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20190322/ed4f333b/attachment.html>

More information about the aprssig mailing list