Re: [gpsd-dev] AIS NMEA TAG Blocks

[Ed W]

On 29/08/2014 03:36, Roy Barkas wrote:
> 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.

I'm not disagreeing with that secondary goal to import TAGs, however, 
it's much wider than my requirement which is to add TAGs to the output 
of the WATCH when requesting vanilla NMEA output.

As such I don't really see it's terribly related to parsing inbound 
TAGs?  However, whether it is or isn't a sensible disagreement I think

It would be great if the output really were millisec accurate, but I 
think there are a whole bunch of problems with doing that accurately, 
not least that some of the output is going to be manufactured from 
binary gps input.  My goals are purely:

1) Be able to replay the sentences back at a later time (ie I need 
timestamps to second ish accuracy)
2) Be able to filter the various inputs post gpsd. Most important use 
case for that is to be able to filter multiple GPS outputs (this saves a 
lot of complexity from having to filter them on the input side...)

At present I have a small daemon which sits between gpsd and my 
application and adds TAG block timestamps to the output. Obviously these 
timestamps are the time I *get* the data, not the original input time, 
but it's good enough for now.  However, what I can't currently do is get 
details of the original input source for each sentence and this makes it 
tricky to filter duplicate sources that are merged through gpsd.

Note, it's fairly trivial to (completely) strip TAG blocks from NMEA 
sentences, so I see that adding these as a simple and standards 
compliant way to add timestamps and source information which can easily 
be reverted for listeners which don't understand such things

Thanks

Ed W