[aprssig] Beacon parsing help

[Jim (List)]

Very many thanks Andrew, the help is much appreciated.

 

 

Jim

 

 

From: Andrew Pavlin <spam8mybrain at yahoo.com> 
Sent: 22 March 2019 22:01
To: aprssig at lists.tapr.org; Jim (List) <jim.list at stuckinthemud.org>
Subject: Re: [aprssig] Beacon parsing help

 

See embedded comments below

 

On Friday, March 22, 2019, 5:14:50 PM EDT, Jim (List) <jim.list at stuckinthemud.org <mailto: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

>stations.

> 

>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 like

typos 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 repeater

rather 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 indicate

this 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-timestamped

Object. 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 live

Object or "_" to indicate a dead (out-of-service) Object.

 

>SV1GCB-3>APMI06,SV3ISZ-11*,SOUTH2-1,qAR,SV3IRM-10:!222024S3704.18N/02225.79E

>#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 prefix

character (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).

 

>WB5OER-2>APTT4,WX5II-3,WIDE1*,WIDE2-1,qAO,KG5YOV:!2847.0333N/09729.2666W#PHG

>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 the

free-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 position

ambiguity.

 

>OE3FRE-15>APNL51,TCPIP*,qAI,OE3FRE-15,SQ6KXY-2,T2DENMARK,T2HUB5,T2CAEAST:!48

>04.66NN/01618.46EE`Radiosondetracker

>*** 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?

 

>DC1SK-15>APNL51,TCPIP*,qAI,DC1SK-15,SQ6KXY-1,T2BIO,T2HUB5,T2CAEAST:!5112.018

>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-precision

token 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-standard

formats.

 

Andrew, KA2DDO

author 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/20190323/d31d2335/attachment.html>