[ntp:questions] help with setting up NTP on windows with a USB GPS

Jakob Bohm jb-usenet at wisemo.com.invalid
Tue Jul 30 02:48:27 UTC 2019

On 29/07/2019 09:21, Maze wrote:
> On Friday, November 27, 2009 at 7:39:06 PM UTC+3:30, jack wrote:
>> Hi all,
>> After reading Dave Hart's message, I realized that I didn't configure
>> the GPS device to only emit $GPRMC messages. After doing this, the NTP
>> software starts to function. So that's big progress for me.
>> Right now, I am using:
>> server minpoll 4 prefer
>> server minpoll 4
>> NTPStatus shows that it's syncing to PPS(1) although the offset and
>> jitter are still quite big (-3ms and 0.2ms respectively).
>> I tried the following combination but the offset actually increased.
>> server minpoll 4 prefer
>> fudge flag1 1
>> Right now I am trying to figure out how to switch to kernel mode. I
>> have
>> 1) serialpps.sys
>> 2) the correspond DLL
>> 3) the environment variable that points to the DLL
>> I am unclear as to what should be done to switch to kernel mode.
>> Thanks to all for the help.
>> Jack
>> On Nov 27, 9:12 am, jack <j.jack.w... at gmail.com> wrote:
>>> David,
>>> You assumed right. I did start with a USB emulated port. The GPS I
>>> bought is from U-Blox and it has both USB and serial output. The
>>> serial output has the 1PPS signal (with an LED indicator). I thought I
>>> would start with the USB output since it's rather hard to find a
>>> computer with a serial port. Also I would like to see the accuracy by
>>> using the USB port only. I later switched to a machine with a serial
>>> port and started using the serial output of the U-Blox GPS device and
>>> 1PPS. My objective is to use two of these devices to sync two separate
>>> computers to within ms so they can share time-sensitive data (time
>>> stamped).
>>> I left the device running overnight and I noticed it computed an
>>> offset at one time. It's currently not updating (everything is zero
>>> now). I will read carefully what Dave Hart said and follow his advice.
>>> Thanks to everyone for your help.
>>> Jack
>>> On Nov 27, 1:51 am, "David J Taylor" <david-tay... at blueyonder.not-this-
>>> bit.nor-this-part.co.uk.invalid> wrote:
>>>> "jack" <> wrote in message
>>>> news:9db25657-9837-4ebe-ab32-ce15ae968af8 at j35g2000vbl.googlegroups.com...
>>>>> David,
>>>>> I only have the following in the configure file:
>>>>> server minpoll 4 prefer
>>>>> I found the following entry in the log file:
>>>>> Using user-mode PPS timestamp
>>>>> Does it mean NTP reads the GPS strings and sees the 1PPS signal?
>>>>> All the values are still 0 including reach. At one point for about 10
>>>>> minutes, I saw some values after rebooting the machine but they
>>>>> disappeared quickly.
>>>>> Thanks.
>>>>> jack
>>>>> ps: I am using the latest NTP from Dave Hart's website. I also
>>>>> installed serialpps.sys.
>>>> Jack,
>>>> As Dave Hart has answered you are talking to the expert in this area!
>>>> I had assumed in my first response that you had a GPS receiver with a
>>>> serial output connected to a serial-USB convertor, but I see now that this
>>>> may not be the case.  How well the PPS output is emulated in the
>>>> USB-serial port software you will need to check.  You need somehow to
>>>> "connect" the PPS output from the GPS to the virtual DCD line of the
>>>> emulated COM1 port.  Not quite sure how you do that.  What GPS and
>>>> software are you using
>>>> Cheers,
>>>> David
> Dear Jack.
> I am doing the same as you do with ubloc evaluation kit(neo-m8t). but i still have problem. I see in u-center that there are lots of ubx messages which I'm not sure whether make any problem in ntp or not. i configured ublox chip to just send $GPRMC among NMEA messages but i couldn't disable sending ubx messages.
> i am in a hurry .could you please help  me make this working??
> Thanks.
> Maze

USB-to-RS-232 converters generally completely loose the precision timing
abilities of traditional serial port circuits (a 16550 or equivalent
chip connected to the main CPU bus like in the serial adapters for the
original 1981 IBM PC).

This is because the standard for USB-to-RS-232 is all about transferring 
the data over an essentially "polled" USB 1.1/2.0 bus that polls once 
per ms, with the conversion chip buffering stuff until the next 
available 1ms USB frame.  This is sufficient for talking to stuff like 
modems and machine control serial ports.

Wiring GPS PPS signals to the modem control line inputs on a serial port
was a trick to get access to the near-instantaneous CPU interrupt line
that was indirectly wired to those lines on the old IBM PC serial ports.

To transfer precision time over USB would be much better done by a
special specification where the USB device reports when the PPS instant
happened relative to the USB frame pulses from the computer, such as a
special NMEA message stating "Time was 2019-07-30 01:35:36.12345678 at
the USB frame marker right before the first char of this message was
sent on the USB BUS", combined with a USB driver extension reporting the
exact computer HPET time of the frame containing a "serial" character
bundle.  An NTP driver for USB could then tell the ntp daemon that
"time was 2019-07-30 01:35:36.12345678 at local time 2019-07-30
01:25:36.12345876" .  Each of these messages would of cause be encoded
in protocol-appropriate ways.

As a transitional solution for such a technique, one could use an
enhanced USB-to-RS-232 adapter including a timestamp in its reporting of
"modem-control" inputs, such as "CD line went high 2.3456ms before the
start of this USB frame" (because it happened 0.3456ms before a frame,
but 2 frames were busy).  An appropriate USB protocol format would be a
20 bit count of 48MHz USB "full speed" typical USB interface clocks
between the reported event and the leading edge SOF of the frame
containing the report, internally an adapter can do this with a 16 bit
hardware timer and software adding 48000 for each frame of additional
delay.  A host-side driver could combine this with the USB frame number
reported by the USB host controller to get time relative to the USB host
controllers clocking, and an extensions to the USB controller driver
could report the local clock time of every 1000th USB frame as a
queryable statistic.

Incorporating these things into a variation of the USB Communications
Class protocol and drivers is left as an exercise for the maker
community, for example some MicroChip inc microcontrollers have the
hardware to implement the proposed timestamping.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

More information about the questions mailing list