Weather data does not decode when position is compressed

[kd7lxl]

Complete Weather Report Format — with Compressed Lat/Long position (APRS101.PDF, pg 66) is not interpreted as a weather packet, and the weather data is not decoded.

Here is one example of the failure: !/:_z:6\'MX_22Kg...t029P000h46b10322

$ ./parse-aprs-packet.pl 
Parsing succesful:
Position: latitude 39.1743 longitude -96.6309

$VAR1 = {
          'symboltable' => '/',
          'messaging' => 0,
          'dstcallsign' => 'APRS',
          'posresolution' => '0.291',
          'header' => 'NW5W-13>APRS,TCPIP*,qAC,T2NL',
          'symbolcode' => '_',
          'digipeaters' => [
                             {
                               'wasdigied' => 1,
                               'call' => 'TCPIP'
                             },
                             {
                               'wasdigied' => 0,
                               'call' => 'qAC'
                             },
                             {
                               'call' => 'T2NL',
                               'wasdigied' => 0
                             }
                           ],
          'type' => 'location',
          'format' => 'compressed',
          'body' => '!/:_z:6\'MX_22Kg...t029P000h46b10322',
          'origpacket' => 'NW5W-13>APRS,TCPIP*,qAC,T2NL:!/:_z:6\'MX_22Kg...t029P000h46b10322',
          'gpsfixstatus' => 1,
          'speed' => '5.0004334374912',
          'longitude' => '-96.6308626872411',
          'srccallsign' => 'NW5W-13',
          'latitude' => '39.1743251970199',
          'course' => 68
        };

Substituting an uncompressed position allows the packet to decode. Example of correct decode:

$ ./examples/parse-aprs-packet.pl 
Parsing succesful:
Position: latitude 47.2188 longitude -121.8435
Comment: 

$VAR1 = {
          'symbolcode' => '_',
          'posresolution' => '18.52',
          'srccallsign' => 'NW5W-13',
          'posambiguity' => 0,
          'dstcallsign' => 'APRS',
          'wx' => {
                    'humidity' => 46,
                    'rain_midnight' => '0.0',
                    'pressure' => '1032.2',
                    'temp' => '-1.7',
                    'wind_speed' => '3.1',
                    'wind_direction' => '180'
                  },
          'symboltable' => '/',
          'longitude' => '-121.8435',
          'body' => '!4713.13N/12150.61W_180/007g...t029P000h46b10322',
          'format' => 'uncompressed',
          'messaging' => 0,
          'header' => 'NW5W-13>APRS,TCPIP*,qAC,T2NL',
          'comment' => '',
          'type' => 'location',
          'digipeaters' => [
                             {
                               'call' => 'TCPIP',
                               'wasdigied' => 1
                             },
                             {
                               'call' => 'qAC',
                               'wasdigied' => 0
                             },
                             {
                               'wasdigied' => 0,
                               'call' => 'T2NL'
                             }
                           ],
          'latitude' => '47.2188333333333',
          'origpacket' => 'NW5W-13>APRS,TCPIP*,qAC,T2NL:!4713.13N/12150.61W_180/007g...t029P000h46b10322'
        };

Note that the example given in the spec for Complete Weather Report Format — with Compressed Lat/Long position, no Timestamp (pg 66) =/5L!!<*e7> _7P[g005t077r000p000P000h50b09900wRSW does not decode for two reasons: this compressed position bug, and the symbol /> is not treated as weather.

[hessu]

Thanks for the report. Seems like a missing feature. When I added weather parsing, no-one was sending these packets, so I probably didn't even notice that it would be valid according to the spec. The priority has been on currently used packet formats. But yes, sure, can be implemented.

[chrissnell]

It looks like the code should parse it if the symbol code is _:

https://github.com/hessu/perl-aprs-fap/blob/master/FAP.pm#L2621-L2626

I wonder what's going on here.

[chrissnell]

I just fixed it. Will submit a PR in a minute.

[chrissnell]

PR waiting for your review. I'm also tempted to submit one that allows symbol code W in addition to _ because the two symbols look nearly identical. Thoughts?

[kd7lxl]

I'm also tempted to submit one that allows symbol code W in addition to _ because the two symbols look nearly identical. Thoughts?

Is there any justification for that in the spec?

[chrissnell]

No, there is not. Scrap that idea.