gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] More on tag blocks


From: Jon Schlueter
Subject: Re: [gpsd-dev] More on tag blocks
Date: Sat, 2 Jan 2016 22:26:17 -0500

Roy,

Do you have sample data for this use case with some annotation?

That will be required before the functionality can be implemented either way.


Jon Schlueter



On Sun, Oct 18, 2015 at 5:05 PM, Roy Barkas <address@hidden> wrote:
There was a discussion many moons ago about incorporating tag blocks into gpsd.  As I recall there was concern about the lack of uniformity in the way that tag blocks were formed.  In particular one other person pointed out that the timestamp format varied between implementations.

I have a use case for tag blocks that just won't go away so I'm raising this again.

My servers receive AIS messages from satellite providers and also from aggregators of terrestrial AIS receivers and also from individual TCP feeds from individual AIS receivers.

The problem I need to solve is that the latency of the arriving messages varies wildly - mostly between all of the terrestrial receivers and the satellite systems.  The satellite messages have a tag block and the terrestrial messages don't.

While all of the terrestrial messages arrive more or less immediately (usually within a few seconds of receipt at the station), the satellite messages arrive with quite variable delays, up to 15-30 minutes in some cases.

I time stamp all received messages when they hit the server but the time stamp of the satellite messages is usually quite deceptive because of the latency.

When I need to assemble a time sequence of messages, i have no way to insert the satellite messages in the correct order and this causes all sorts of confusion.  

Couldn't GPSD optionally pass the tag block (if one is present) through, in the same way that it can currently pass undecoded messages through?  GPSD would not need to understand the tag block, or try to divine what kind of time stamp is used, it would simply pass it on unprocessed to the output. 

When developers need to use the tag block they would just enable the gpsd tag block pass through option at GPSD startup and pick the tag block up with the decoded data.  The individual developer can deal with understanding the tag block format and using it.

If a tag block is part of the incoming message gpsd would pass it through.  If no tag block then nothing to pass through so no tag block at output.

So in my case, with raw and tagblock options, the sequence of messages I would get from gpsd would be:
<tag block string>
<undecoded message string>
<decoded json>

or for multipart messages

<tag block string>
<undecoded message string>
<tag block string>
<undecoded message string>
<decoded json>

Cheers;

Roy Barkas


reply via email to

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