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

Chris xxx.syseng.yyy at gfsys.co.uk
Tue Jul 30 15:36:07 UTC 2019

On 07/30/19 03:48, Jakob Bohm wrote:
> 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.
> Enjoy
> Jakob

I would not expect real time performance from any usb device, especially
with the wide range of usb to serial devices on the market, none of
which were designed for this class of precision work and none of which
are likely have specified delays.

Seems to me a better plan would be to find a gps module or receiver
with a serial interface and interface to that. New GPS modules are cheap
as chips on Ebay and elsewhere and so are s/h gps boxes, so why make
life difficult ?...


More information about the questions mailing list