[aprssig] APRS Object & Weather format
hessu at hes.iki.fi
Mon Oct 25 18:40:42 EDT 2021
The "Complete Weather Format -- With Lat/Long position, No Timestamp"
table on page 66 of APRS101.PDF indeed does contain an example packet,
which starts with object syntax, but does not have a timestamp.
On the other hand the table header in the very same table does have a
"Time DHM / HMS" field of 7 bytes (fixed length). The example packet does
not match the specification in the table.
Also, it starts with a ";BRENDA *" so it is initially parsed as an object.
Object Report Format on page 58 says "An Object always has a timestamp"
and also specifies the fixed-length 7-byte timestamp.
So I'd suspect the packet example in that table is a little buggy and that
the object will need a timestamp, even if it happens to have weather data
in the end.
By the way, the parser in question was originally written by Tapio,
OH2KKU. I did a few fixes and improvements later on.
On Sat, 23 Oct 2021, John Gorkos wrote:
> APRS Spec 1.01: 29 AUG 2000, bottom of page 65 (curse the editor that didn't put Table #s), "Complete Weather Format -- With Lat/Long
> position, No Timestamp" indicates that it should be valid. HOWEVER, on the previous page, under the "Positionless Weather Data"
> heading, you'll see:
> "NOTE: The weather report must include at least the MDHM date/timestamp, wind direction, wind speed, gust and temperature..."
> Ambiguity aside (I think a "Positionless Weather Report" requires the timestamp), it is valid to have a weather report without
> timestamp. Just assume time=now().
> John Gorkos
> On 10/23/21 10:48 AM, Matthew Adair wrote:
> I've been going over the APRS 101 specification and teasing it apart using Heikki's excellent Ham::APRS::FAP library.
> Page 66 of the APRS101 document gives two example weather report formats as objects:
> # Complete Weather Report Format — with Object and Lat/Long position
> ;BRENDA *4903.50N/07201.75W_220/004g005t077r000p000P000h50b09900wRSW
> ;BRENDA *092345z4903.50N/07201.75W_220/004g005b0990
> The second object parses correctly. The first one does not.
> From what I can figure out, the reason is because the first object doesn't have a valid time stamp. The 101 spec seems to
> indicate that Objects require a time stamp. So, is the first object truly invalid, or is a weather object without a timestamp a
> valid exception?
> - Matt, N8SHA
More information about the aprssig