---------- Forwarded message ----------
From:
Roy Barkas <address@hidden>Date: Mon, Mar 5, 2012 at 3:43 PM
Subject: Re: [gpsd-users] problem decoding type 24A AIS packets
To: address@hidden
That's not good news (for me and I suspect for others) Eric.
The AIS messages that I am collecting and trying to decode and archive are satellite collected. The satellite system vendor doesn't deliver type 24 messages in pairs. They send 24A's or 24B's more or less randomly and not usually together or adjacent in their data flow. There are multiple satellites receiving AIS data and their output is combined in a data centre in sort of FIFO way, so I might get a 24A from someone near Newfoundland, followed by a 24B from someone in the med, followed by a 24A from New Zealand, followed by the long-lost 24B from Newfoundland, all interleaved with many type 1,2,3,5,18 and 19 messages. I suspect that I wouldn't succeed if I told the satellite provider that they need to change their code to store 24A's until the related 24B arrived.
Interestingly they do manage to send both parts of a type 5 message sequentially, but that's a different message architecture - appending the payload from the second AIVDM to the payload of the first one.
Looking at the content of 24A and 24B I don't see any reason why they can't be treated as if they were separate and independent types.
It's pretty clear whether a 24A or B has been received without any reference to the data missing because it's in the other half of the message.
In my case, once I can receive decoded 24A's from gpsdecode... I'll treat this simply -
I'll handle this (once I can get decoded 24A data) by just checking to see if the json returned from gpsdecode contains a shipname that is non-blank. If one exists it's a 24A, if no shipname then if any of vendorid, shiptype,callsign,to_bow, to_stern, to_port, to_starboard or mothership_mmsi are set then it must be a type B. If both shipname and any of the type B items are present then it must be an assembled pair.
So, in a nutshell - my recommendation is for gpsd/gpsdecode to return a decoded entity unconditionally for each / both type 24A/24B messages and let the user of the returned data sort out whether it was A or B or both.
If it won't be possible for gpsDecode to do something with the 24A messages independent of 24B's then I guess I'll have to write a special case handler to use instead of gpsdecode if a type 24 message that I submit returns a blank response. But that would be an ugly hack.
Cheers;
Roy
On Mon, Mar 5, 2012 at 12:48 PM, Eric S. Raymond
<address@hidden> wrote:
Roy Barkas <address@hidden>:
> The version of gpsdecode that I'm using returns nothing when it is
> presented with a AIS type 24A message. It does decodes type 24B just fine.
I think what's actually going on is that a 24A is invalid without a following
24B. gpsdecode is refusing to pass along data that is invalid because parts
of it are missing.
--
<a href="" href="http://www.catb.org/~esr/" target="_blank">http://www.catb.org/~esr/">Eric S. Raymond</a>