Garmin's GPS 18x LVC manual notes: "The NMEA 0183 sentences that follow each rising edge of the PPS signal tell you when you were and where you were at that previous rising edge of the PPS signal, ..."
http://www8.garmin.com/manuals/GPS18x_TechnicalSpecifications.pdf That seems like an obvious choice of timing once per second pulses and once per second NMEA sentences, and it makes the software's job easy (when you receive a NMEA sentence, get the timestamp of the latest PPS rising edge) assuming a refclock driver that represents the GPS+PPS as a unit. Do you know of a serial timecode device with PPS on the carrier detect line and 1Hz timecode output that doesn't output sentences which correspond with the previous PPS rising edge? In other words do any implement "at the tone the time will be <beep>", so to speak? Do you know of any serial timecode device which does anything with the carrier detect line other than pulse per second? I'm assuming not, but worth asking. In getting the Windows ntpd serial I/O code working with a modern compiler to play with one of these lovely pucks, generic user-mode PPS support for serial refclocks sort of fell out. [tune out here if Windows makes you groan] The current ntpd Windows serial code attempts to emulate tty line discipline (wherein a read completes only at end of line) by setting a hardcoded 20 millisecond interbyte timeout, regardless of baud rate. Since serial timecodes generally come once per second with at least 20 msec of silence after each burst, this works, more or less. However if you have a GPS that is spitting multiple sentences per second, as this one defaults to, the scheme falls over and returns multiple lines together where one is expected. Grooming of control characters causes the lines to run together before they are displayed by any debug messages. I patched ntpd to use a different approach. While imperfect, I believe it's better by eliminating the jitter caused by waiting for that 20 msec timeout. I set the serial port to never block I/O, returning whatever is available now. I also configured an "event character" in the windows DCB structure of CR. Then instead of simply reading and waiting for the timeout, the code was changed to wait for the event character to be signalled, then read everything available. That's still a race, because other characters (like the LF following) might be picked up by that read. As mentioned, both the CR and LF will be filtered before the line is used by the refclock, so it doesn't matter if we pick up the LF, but we'd rather not pick up any character immediately following it.. Anyway, the likelihood of clustered sentences being returned as one line to the refclock driver is much lower with this approach, and the jitter compared to a 20 msec timeout likely serviced by a 15 msec system clock interrupt is reduced. I couldn't help noticing while working on this code that it would be easy to add carrier detect line state change detection, because the same WaitCommEvent interface that supports the CR event character also can report CD transitions. Given that I'm not holding my breath for Windows to include PPSAPI, this appealed to me, so I put it in. The approach is to simply grab a timestamp on CD rising edge and then issue another wait, using the same receive buffer. Then when a read is triggered by the event character, leave the existing PPS timestamp alone in the receive buffer if it is present. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
