Re: [gpsd-dev] RC for DRIFT message

[Hal Murray]

> The idea of writing a HOWTO is an excellent one, thank you.  I believe I am
> well equipped to do it, and it would be good battlespace preparation for
> redesigning the reporting mechanism to NTP. 

Please don't limit yourself to NTP.  That's all the current SHM 
implementation supports, but there is no reason that all the navigation info 
currently sent via JSON/TCP can't be passed via SHM, Pipes, or IPC queues.  
(There might be practical size limits I don't know about.)


> You're right.  I think it's going to be TOS (top of second).

No big deal, but when I see TOS, I think Terms of Service.  Besides, lots of 
GPS devices provide their info about halfway through the second so "top" will 
probably be misleading.

What's wrong with TIME?

-------

> In NMEA devices it is usually the case that GPMRC and GPGGA are emitted
> early and GPGSV/GPGSA late. 

For some value of usually.  :)

>From a BU-353/SiRF-III...  The GPGGA comes first and the GPRMC comes last.  
Every 5 seconds, when the GPGSV gets dumped, the GPRMC gets pushed over over 
the boundary into the next second.  The GPGGA doesn't include the date.

I'll send a chunk of log file if anybody wants the details.

-----

> One of the possibilities I'm contemplating for the next cycle is a real-time
> strip-chart visualizer that reads from the NTP shared-memory segment and
> plots the PPS offset over time.  There's a Python library called
> stripchart.py that works with my favorit graphics toolkit, pygtk; the only
> mildly grotty part will be writing the C Python extension to read from the
> segment. 

I assume you will have an option to plot the non-PPS slot too.

You might think about ways to plot other stuff, say temperature.  Maybe a 
plugin or other SHM?


-- 
These are my opinions.  I hate spam.