gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] AIVDM decoding of split 24A and 24B each


From: Roy Barkas
Subject: Re: [gpsd-users] AIVDM decoding of split 24A and 24B each
Date: Mon, 5 Mar 2012 22:37:52 +1100

Thanks Eric, as soon as I figure out how to get and build the driver I'll give it a try.  (I develop in PHP and _javascript_, dabbling in Python and Java...  so building this will be a bit of a challenge for me but I'll muddle through).

There may still be a problem, I've been working through the messages that come in and I'm finding that I often receive 24B's with no apparent associated 24A within any reasonable timeframe.  (and vice versa).
I think this is a "feature" of satellite sourced class B AIS.  The class B transponders are so weak (RF wise) that it's entirely possible, maybe probable, that the associated type 24 message may never arrive.

I've noticed that gpsdecode handles the case of 24B's arriving without a preceding 24A quite gracefully.  It just returns the data that is contained in the 24B without complaint.  It would seem to me that the 24A's could be handled in the same way.  If we just conceptually view the 24A's and B's as sort of virtual different message types without any requirement for both to arrive then we could extract whatever data does manage to worm it's way through the Satellite delivered systems.  shipnames (with associated mmsi's) and static data without shipnames are all valuable.  The software that I've written didn't anticipate the relationship between A's and B's and just takes what it can get.  So if 35 24B's come in from a ship and then a single 24A I've then got a complete data set.  If the 24A never arrives, so it goes, I've still got the mmsi and other static data and I just identify the vessel as 'Unknown type B AIS 56722349 or whatever.  The class B static data is really quite static.  The ship dimensions, callsign, shiptype etc will rarely if ever change.  There is no 'dynamic' static data for type 24 like there is for type 5 (like destination or ETA).  

I understand that you're probably trying to ensure compliance with the published AIS standard by requiring associated 24A and B's.  But from where I'm sitting and from the data I'm seeing I suspect that the real world of Sat AIS will fall somewhat short of full compliance.  I'm starting to think that the NMEA AIS protocols are fairly messy, even though I understand that when they were conceived no one envisioned global satellite coverage.

Thanks again for the mod to the driver - I'll give it a  try but I fear that this change, while evidently compliant, may not solve the problem.

Cheers;

Roy
in beautiful downtown Tasmania

On Mon, Mar 5, 2012 at 9:25 PM, Eric S. Raymond <address@hidden> wrote:
The driver in the git head version should now handle up to 8 pending
24As on each channel.  The whole report comes out when the matching
24B arrives.

Do you need that limit raised?  It's just a C #define in one spot.
--
               <a href="" href="http://www.catb.org/~esr/" target="_blank">http://www.catb.org/~esr/">Eric S. Raymond</a>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]