gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] AIS NMEA TAG Blocks


From: Roy Barkas
Subject: Re: [gpsd-dev] AIS NMEA TAG Blocks
Date: Fri, 29 Aug 2014 12:36:55 +1000

Really, it's necessary to handle tag blocks from upstream providers if tag blocks are to be produced for the gpsd output..  
People who need a tag block when none is available from upstream could prepend one to an incoming AIVDM/AIVDO sentence or
(as I think you are suggesting) where no tag block source is seen by gpsd, it could generate one one using current utc time and some default info for other tag block fields.

The reason that handling upstream tag blocks is necessary is that sometimes (particularly satellite feeds) there can be considerable latency between when the message was observed and when it is sent downstream by the provider.  Also, some satellite data providers have a query facility where you can ask for all messages from a certain time range in the past.  When you ask for these, they arrive with a tag block timestamp that represents the time when the message was observed, not when it was sent downstream..


On Fri, Aug 29, 2014 at 8:39 AM, Ed W <address@hidden> wrote:
Hi

 From my personal experience, the way to know if a TAGblocked timestamp is in
seconds or milliseconds is ask the people in charge of setting up the
device/service. Perhaps some devices output only secs/msecs, and some other
accept the NMEA 4.00 TAGblock configuration sentences.

I, for one, would like to see the secs/msecs problem solved before GPSD
embarks on the enterprise of writing TAGblocks.

It might be too obvious, but observations of data suggest that you just count the number of digits?

- 10 digits = seconds
- 13 digits = millisecs

Note that I'm suggesting that we *add* these, not *consume* them from an upstream.  As such you are free to make your own definition.

My request would be 13 digit millisecs.  My requirement is to be
a) able to play the stream back with moderate precision at some later time.
b) Filter multiple GPS units from the resulting mux'ed output NMEA stream

The use of a TAG block would work perfectly for my requirements... As long as we document what format WE use, I don't see a problem.

I found this interesting
    http://www.nmea.org/Assets/may%2009%20rtcm%200183_v400.pdf

Kind regards

Ed W



reply via email to

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