Re: [gpsd-dev] RC for DRIFT message

[Eric S. Raymond]

Hal Murray <address@hidden>:
> 
> > 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.)

What you've actually nudged me into thinking about writing is a practical
guide to IPC that examines the functional tradeoffs among IPC methods.

> > 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?

Internal issue.  There's already an exposed TIME_SET status flag for
valid time.  The way the naming conventions in the code work it 
would be perverse to have that not be associated with a "TIME" JSON.

But you have a point about the timing. TOFF, maybe?

> > 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.

I have all those logs. :-) I should have said "GPMRC *or* GPGGA"; my
point was the normal pattern is for some fix-plus-timestamp sentence
to ship early and the skyview stuff to ship late.  Yes, the GGA time
is incomplete but that's OK as after the first cycle the NME0183
driver latches the date and fills it in, handling rollovers
intelligently.

"The GPRMC gets pushed over over the boundary into the next second." 
Interesting.  I can believe this at 4800bps; have you observed it at 9600?

> > 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.

Yes. Conveniently, the stripchart library does stacked stripcharts. 
It's easy to imagine a display with stacked stripcharts, one for 
each active NTP segment.

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

Where are you proposing I get temperature from?  The temp readout from
a fish sounder doesn't seem very relevant...
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>