[aprssig] APRS Object & Weather format

[Heikki Hannikainen]

Hi,

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

   - Hessu