GPS+PPS vs NTP server, why a huge offset ?

[Thibaut HUMBERT]

Hello,
I post this message because I have a huge offset (+110ms) on a PPS source compared to NTP internet servers.

My 10$ hardware :
I use a USB<>TTL adapter (CH341A) connected to a NEO-6M in +5V, RX, TX, GND. I soldered pin 3 of the u-blox chip to have the PPS on the DCD/CLK pin of the CH341A.

My software:
I am using ntp 4.2.8p15 on windows with loopback-ppsapi-provider.dll drivers

Here is my ntp.conf:

server ntp.lothaire.net minpoll 4 maxpoll 6
server ntp-p1.obspm.fr minpoll 4 maxpoll 6
server 127.127.20.14 minpoll 4 maxpoll 4 mode 16 prefer
fudge 127.127.20.14 refid NMEA
server 127.127.22.14 minpoll 4 maxpoll 4 true
fudge 127.127.22.14 refid PPS
tos mindist 0.5


I let it run for a while, and this is what I get:

C:\Users\toto>ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(14) .NMEA. 0 l 3 16 377 0.000 -62.580 2.642
oPPS(14) .PPS. 0 l 11 16 377 0.000 -0.252 0.539
+arcturus.ciril. 193.50.27.139 2 u 15 16 377 37.707 +110.85 0.195
+ntp-p1.obspm.fr .MRS. 1 u 14 16 377 33.250 +110.44 11.592

The offset "-62.580ms" for the GPS seems normal to me, i guess it's the processing time of the NMEA frames by the U-Blox NEO-6M.

But, I don't understand why my PPS clock has an offset of "+110ms" compared to Internet NTP servers?

[Thibaut HUMBERT]

Can be a track:
When I modify the PPS pulse length in u-center, the offset varies:
pulse length 100ms (value by default): offset +110ms
pulse length 10ms: offset +30ms
pulse length 200ms to do like Meinberg (https://www.meinbergglobal.com/english/glossary/pulse-per-second.htm): offset +211ms
So, can we put a pulse lenght of 1ms and indicate in ntp.conf to remove these 1ms?
Even if we subtract the pulse length, I have the impression that there is still a 10ms lag?

[David Woolley]

On 16/06/2022 09:01, Thibaut HUMBERT wrote:
> When I modify the PPS pulse length in u-center, the offset varies:

I would suggest you are detecting the wrong edge of the pulse. You may
need to add an inverter.

[Thibaut HUMBERT]

To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
The offset induced by the "pulse length" has disappeared.
But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)

[Daniel O'Connor]

You can configure the ref clock to capture on the other edge, eg flag2 for PPS and NMEA drivers.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
--
This is ques...@lists.ntp.org
Subscribe: questions...@lists.ntp.org
Unsubscribe: questions+...@lists.ntp.org

[David Taylor]

On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
> The offset induced by the "pulse length" has disappeared.
> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)

Yes, Thiebaud, USB is not good enough for PPS signals!

See if your motherboard has a true serial port - perhaps just as a header but
not a back connector. If not, just set the offset of the PPS to ~10.3
milliseconds (10.3 - IIRC the offsets are in milliseconds but please check).
Plus or minus 10.3, try it and see! Not perfect, but better than nothing.

You might find better results using that GPS/PPS with a Raspberry Pi as a
stratum-1 server and offering that as a server on your LAN.

Cheers,
David
--
Cheers,
David
Web: http://www.satsignal.eu

[Thibaut HUMBERT]

I have a serial port, but I don't know how to convert the PPS output (0 / 3.3V) to RS232 (-5V / +5V).

[Jim Pennino]

You go to amazon.com and search for "level converter 3.3 to 5".

[David Woolley]

On 16/06/2022 15:54, Thibaut HUMBERT wrote:
> I have a serial port, but I don't know how to convert the PPS output (0 / 3.3V) to RS232 (-5V / +5V).

RS232 is +/-12V, although, input values of +/-3V are unequivocal. In
practice line receivers have both positive and negative going thresholds
> 0V, and various things rely on this to put lines into the right state
when the plug is removed (false for control lines and marking(?) for data).

[chris]

You need a ttl to rs232 converter. That will introduce almost zero
delay to the data carrier detect (dcd) line on the serial port.
Then edit the ntp.conf file to take account of the pps source,
polarity (which edge) and you should be good to go.

Iirc, the converter was less than 10 ukp from Ebay and the only
fly in the ointment, don't remember, if the converter needs +/-
12 volt rails, or if it runs from a single 5 volts. Either way,
you will need to find power for it from the host. Been using
that setup for over a year now, typical delay = 0
microseconds on pps...

Chris

[Jim Pennino]

chris <chris-...@tridac.net> wrote:
> On 06/16/22 16:20, Jim Pennino wrote:
>> Thibaut HUMBERT<plan...@gmail.com> wrote:
>>> Le jeudi 16 juin 2022 à 16:37:33 UTC+2, David Taylor a écrit :
>>>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
>>>>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
>>>>> The offset induced by the "pulse length" has disappeared.
>>>>> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
>>>> Yes, Thiebaud, USB is not good enough for PPS signals!
>>>>
>>>> See if your motherboard has a true serial port - perhaps just as a header but
>>>> not a back connector. If not, just set the offset of the PPS to ~10.3
>>>> milliseconds (10.3 - IIRC the offsets are in milliseconds but please check).
>>>> Plus or minus 10.3, try it and see! Not perfect, but better than nothing.
>>>>
>>>> You might find better results using that GPS/PPS with a Raspberry Pi as a
>>>> stratum-1 server and offering that as a server on your LAN.
>>>>
>>>> Cheers,
>>>> David
>>>> --
>>>> Cheers,
>>>> David
>>>> Web: http://www.satsignal.eu
>>>
>>>
>>> I have a serial port, but I don't know how to convert the PPS output (0 / 3.3V) to RS232 (-5V / +5V).
>>
>> You go to amazon.com and search for "level converter 3.3 to 5".
>>
>>
>
> You need a ttl to rs232 converter.

That is what a level converter 3.3 to 5 is.

The RS-232 standard mark is +3 to +15 V and space is -15 to -3 V, which
means a 0/3v level converter to -5/+5V meets the RS-232 standard.

[chris]

No argument with that, but some have tried to bypass a converter,
feeding the ttl pps into the rs232 port, which may work in some
cases. TLL pps low level, in particular, won't guarantee the rs232
input line to switch, whereas, of course, the ttl high will switch.
The rs232 ip needs zero or a minus level to properly work and avoid
jitter...

Chris

[Daniel O'Connor]

> On 17 Jun 2022, at 00:07, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
>
> On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
>> The offset induced by the "pulse length" has disappeared.
>> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
>
> Yes, Thiebaud, USB is not good enough for PPS signals!

This is absolutely false.

If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).

Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did a bunch of tests on a PPS over USB setup and found it more than
acceptable for keeping a PC in (good) time. Here's the thread: https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html

> See if your motherboard has a true serial port - perhaps just as a header but not a back connector. If not, just set the offset of the PPS to ~10.3 milliseconds (10.3 - IIRC the offsets are in milliseconds but please check). Plus or minus 10.3, try it and see! Not perfect, but better than nothing.
>
> You might find better results using that GPS/PPS with a Raspberry Pi as a stratum-1 server and offering that as a server on your LAN.

The next level would be something where you can do an input capture on the PPS I don't think there are any pre canned solutions. I made one with a Beagle Bone Black and a uBox GPS module but it's not exactly turn key. Or for a server then you would need a fancy (ie $$$$) internal card.

The Raspberry Pi does not have an input capture timer, but I believe you can do better with DMA hackery (I haven't tried though).

[Dan Drown]

Quoting Daniel O'Connor <dar...@dons.net.au>:
> If you are using it for NTP then GPS+PPS over USB is quite adequate
> (from personal experience).
>
> Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did
> a bunch of tests on a PPS over USB setup and found it more than
> acceptable for keeping a PC in (good) time. Here's the thread:
> https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html

That ntpq snapshot is a little bit misleading, the latency added by
USB will vary depending on the offset between when the PPS happens and
the next USB poll. The USB polls are relatively stable in the short
term, depending on the host frequency driving USB. So the snapshot
will only tell you the offset between all the PPS sources in that
short timeframe, not how they wander over time.

Here's a measurement of that wandering from the USB device's perspective:
https://blog.dan.drown.org/content/images/2017/07/usb-cdc-latency-zoom3.png

As long as you are ok with your time having an offset between ~0ms and
~1ms, PPS over USB (USB fullspeed) is acceptable. There are plenty of
uses where that would be "good enough".

I have more info on my blog post: https://blog.dan.drown.org/pps-over-usb/

[Jim Pennino]

Daniel O'Connor <dar...@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 00:07, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
>>
>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
>>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
>>> The offset induced by the "pulse length" has disappeared.
>>> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
>>
>> Yes, Thiebaud, USB is not good enough for PPS signals!
>
> This is absolutely false.
>
> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).

As USB is a two wire interface, there is no such thing as PPS over USB.

You of course can get the ASCII data over USB, but to get a PPS signal
you in general have to hack a USB GPS and add a signal wire for PPS then
hack some interface on the computer to accept PPS.

If all you need is accuracy in the 2 millisecond range, most recent USB
GNSS dongles will achieve that without PPS.

[Daniel O'Connor]

> On 17 Jun 2022, at 12:05, Dan Drown <dan...@drown.org> wrote:
>
> Quoting Daniel O'Connor <dar...@dons.net.au>:
>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>>
>> Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did a bunch of tests on a PPS over USB setup and found it more than
>> acceptable for keeping a PC in (good) time. Here's the thread: https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html
>
> That ntpq snapshot is a little bit misleading, the latency added by USB will vary depending on the offset between when the PPS happens and the next USB poll. The USB polls are relatively stable in the short term, depending on the host frequency driving USB. So the snapshot will only tell you the offset between all the PPS sources in that short timeframe, not how they wander over time.
>
> Here's a measurement of that wandering from the USB device's perspective:
> https://blog.dan.drown.org/content/images/2017/07/usb-cdc-latency-zoom3.png
>
> As long as you are ok with your time having an offset between ~0ms and ~1ms, PPS over USB (USB fullspeed) is acceptable. There are plenty of uses where that would be "good enough".

I would say it is good enough for the vast majority of cases. It unfortunately seems to be "received wisdom" that it's not great and people avoid it, when the fact is that it works exceptionally well for use cases where NTP is in use.

> I have more info on my blog post: https://blog.dan.drown.org/pps-over-usb/

Interesting reading thanks.

Personally I think to get significantly better than the simple GPS over USB case you need an input capture timer, but annoyingly it seems to be quite a rare feature in large SoCs (especially annoying since input capture timers are dime a dozen on microcontrollers).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

[Daniel O'Connor]

> On 17 Jun 2022, at 12:52, Jim Pennino <ji...@gonzo.specsol.net> wrote:
> Daniel O'Connor <dar...@dons.net.au> wrote:
>>
>>
>>> On 17 Jun 2022, at 00:07, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
>>>
>>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
>>>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
>>>> The offset induced by the "pulse length" has disappeared.
>>>> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
>>>
>>> Yes, Thiebaud, USB is not good enough for PPS signals!
>>
>> This is absolutely false.
>>
>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>
> As USB is a two wire interface, there is no such thing as PPS over USB.

The fact USB only has 2 data lines is irrelevant to wether you can send PPS over USB.

> You of course can get the ASCII data over USB, but to get a PPS signal
> you in general have to hack a USB GPS and add a signal wire for PPS then
> hack some interface on the computer to accept PPS.

This is absolutely not true in any meaningful sense.

> If all you need is accuracy in the 2 millisecond range, most recent USB
> GNSS dongles will achieve that without PPS.

You can easily do better than that with GPS/PPS over USB.

It is very easy to setup, readily accessible and cheaply done.

[David Woolley]

On 17/06/2022 00:55, chris wrote:
> No argument with that, but some have tried to bypass a converter,
> feeding the ttl pps into the rs232 port, which may work in some
> cases. TLL pps low level, in particular, won't guarantee the rs232
> input line to switch, whereas, of course, the ttl high will switch.
> The rs232 ip needs zero or a minus level to properly work and avoid
> jitter...
>

In practice, RS232 line receivers will emulate the characteristics of
the 1489 or 1489A ICs (which are still available). In the simplest
configuration for those, the input low threshold voltage is no less than
+0.75 volts and the input high threshold voltage is no more than +2.25
volts, which makes nearly all real life true RS232 line receivers TTL
compatible. (The A variant has a larger hysteresis, and results in a
higher high threshold.)

The main reason for not using TTL are that is isn't designed for driving
more than a few inches of wire, and it doesn't have the huge noise
margins of true RS232 drivers.

In terms of level converting to TTL, the decades old 1488 line drivers
are also still available, although they need +/- 12V supplies, as are
the newer, but still decades old, MAX232 devices, that have charge pumps
to derive the 12 volts from a 5 volt supply. As such, there is no
really sensible reason to re-purpose device intended for shifting
between 3.3 an 5 volt CMOS levels.

[David Taylor]

On 17/06/2022 03:03, Daniel O'Connor wrote:
>> Yes, Thiebaud, USB is not good enough for PPS signals!
> This is absolutely false.
>
> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>
> Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did a bunch of tests on a PPS over USB setup and found it more than
> acceptable for keeping a PC in (good) time. Here's the thread:https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html
>
>> See if your motherboard has a true serial port - perhaps just as a header but not a back connector. If not, just set the offset of the PPS to ~10.3 milliseconds (10.3 - IIRC the offsets are in milliseconds but please check). Plus or minus 10.3, try it and see! Not perfect, but better than nothing.
>>
>> You might find better results using that GPS/PPS with a Raspberry Pi as a stratum-1 server and offering that as a server on your LAN.
> The next level would be something where you can do an input capture on the PPS I don't think there are any pre canned solutions. I made one with a Beagle Bone Black and a uBox GPS module but it's not exactly turn key. Or for a server then you would need a fancy (ie $$$$) internal card.
>
> The Raspberry Pi does not have an input capture timer, but I believe you can do better with DMA hackery (I haven't tried though).

If a 125 us uncertainty in the PPS is something you can tolerate, so be it. If
you are bothering with PPS then presumably you want better accuracy than can be
achieved without it.

No need for DMA hackery. Standard NTP with the Raspberry Pi can handle PPS on
a GPIO signal with a couple of edits to allow the PPS support already built
into the kernel to be attached to the appropriate GPIO pin. Not out of the
box, but very little effort required.

The Raspberry Pi can act as a server for hundreds of clients. If you mean a
PC-based Windows server, that's not something I would immediately recommend,
but if you must a £20 serial card may be all you need to add.

[Jim Pennino]

Daniel O'Connor <dar...@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 12:52, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>> Daniel O'Connor <dar...@dons.net.au> wrote:
>>>
>>>
>>>> On 17 Jun 2022, at 00:07, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
>>>>
>>>> On 16/06/2022 10:00, Thiebaud HUMBERT wrote:
>>>>> To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" from "Rising edge".
>>>>> The offset induced by the "pulse length" has disappeared.
>>>>> But there is still an offset of around 10.3ms, which I think is induced by USB as explained in this article about other chipsets (https://lists.freebsd.org/pipermail/freebsd-usb/2019- August/016078.html)
>>>>
>>>> Yes, Thiebaud, USB is not good enough for PPS signals!
>>>
>>> This is absolutely false.
>>>
>>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>>
>> As USB is a two wire interface, there is no such thing as PPS over USB.
>
> The fact USB only has 2 data lines is irrelevant to wether you can send PPS over USB.
>
>> You of course can get the ASCII data over USB, but to get a PPS signal
>> you in general have to hack a USB GPS and add a signal wire for PPS then
>> hack some interface on the computer to accept PPS.
>
> This is absolutely not true in any meaningful sense.

OK, then to which of the USB connector pins do you connect the PPS
signal to get "PPS over USB"?

[Ralph Blach]

I have complete instructions on how to use a raspberry pi as an NTP server.

Ping me if you want them

Chip Blach

[Jim Pennino]

The Pi4 with a current GNSS model $29.95 Adafruit Ultimate GPS HAT will
provide an accuracy of about 1 to 2 microseconds.

If you plot loopstats you can see the offset vary with the heat/AC going
on and off and the error varying by about .5 microseconds.

If you want better than that, you need a GNSS receiver with a managed
oscillator such as an OCXO or rubidium.

However actually achieving in NTP anywhere near the +/- 1 nanosecond
accuracy of an OCXO will require careful selection of both hardware
and software.

[chris]

Over year ago and the converter just got wrapped in heatshrink and
tie wrapped inside the mini pc box. I think the version I used did use
the max232, which meant I just had to pick up 3.3 or 5v, one of the two.

As for compatibility, while a mismatched connection may work, it's bad
practice to do that, where you are dealing with microsecond timing
and want to avoid jitter. Use the correct interfaces and do the job
right, then you can fit and forget:-)...

Chris

[David Woolley]

On 17/06/2022 16:34, chris wrote:
> As for compatibility, while a mismatched connection may work, it's bad
> practice to do that, where you are dealing with microsecond timing
> and want to avoid jitter. Use the correct interfaces and do the job
> right, then you can fit and forget:-)...

RS232 isn't optimal for PPS as it is slew rate limited to 30V/µs, which
means it will take at least 0.5µs from a resting level until it has
fully cleared the transition region, if implemented to standard.

TTL is the more natural logic family for high accuracy PPS.

GPS should be able of achieving time transfer accuracies of better than
.03µs.

[David Woolley]

On 17/06/2022 15:01, Jim Pennino wrote:
> OK, then to which of the USB connector pins do you connect the PPS
> signal to get "PPS over USB"?

D+ and D-, using for example a Communications Device Class module to
encode it for transmission. I guess HID would be more appropriate, for
an isolated digital signal, but HID often uses low rates.

[Terje Mathisen]

GPS, even at the $80 Shure evaluation board level, have been directly
measured at the ~25 ns level, which is pretty much what you claim here. :-)

The key idea is of course that in order to know where a GPS is located
with better than 3 m precision, the unit by implication also knows what
time it is, to within 10 ns of UTC(USNO). The only problem is to be able
to convey that info to a connected NTP server.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Jim Pennino]

Have fun writting the necessary device driver...

[Ralph Blach]

I like the adafruit gps hat

Chip Blach

[David Woolley]

On 17/06/2022 20:16, Terje Mathisen wrote:
> The key idea is of course that in order to know where a GPS is located
> with better than 3 m precision, the unit by implication also knows what
> time it is, to within 10 ns of UTC(USNO). The only problem is to be able
> to convey that info to a connected NTP server.

It only needs the time relative to the visible constellation, as the
ultimate position accuracy depends on time differences not absolute
time. Absolute time errors affect position at about 7.5mm/µs.

<https://www.gps.gov/systems/gps/performance/accuracy/> quotes ≤30
nanoseconds, 95% of the time. That probably includes uplink allowances.
Also, I'm not sure if UTC(xxxx) exists in real time. UTC proper only
exists some weeks after the event. There might have to be an allowance
for the difference between the instantaneous estimate of UTC(USNO) and
the final value.

[David Woolley]

On 17/06/2022 20:45, Jim Pennino wrote:
> Have fun writting the necessary device driver...

You can buy chips preloaded with the relevant code for the encode side,
for single figure sums and most OSes already include the decode side code.

[chris]

On 06/17/22 19:50, David Woolley wrote:
> On 17/06/2022 16:34, chris wrote:
>> As for compatibility, while a mismatched connection may work, it's bad
>> practice to do that, where you are dealing with microsecond timing
>> and want to avoid jitter. Use the correct interfaces and do the job
>> right, then you can fit and forget:-)...
>
> RS232 isn't optimal for PPS as it is slew rate limited to 30V/µs, which
> means it will take at least 0.5µs from a resting level until it has
> fully cleared the transition region, if implemented to standard.
>
> TTL is the more natural logic family for high accuracy PPS.

Agreed, and many gpsdo / ntp boxes do have a pps signal as ttl. The
problem is that the most common supported method of getting the pps
signal into ntpd is via the rs232 data carrier detect line. I believe
there is another supported input option, but when I queried that with
PHK, he thought that it had not been tested in years and not sure if
it even worked, so I had no choice but to use the dcd line for input.
Afaics, there are no other options for getting pps into the system,
but perhaps there have been later developments ?.

Since ntpq -pn resolution is only down to the nearest microsecond,
i'm not concerned if the level shifting introduces a few 10's of
nanoseconds offset, as that will be lost in the noise anyway. It
works well here and typically get 0 or 1 uS offset and usually zero
uS jitter. Good enough in fact...

>
> GPS should be able of achieving time transfer accuracies of better than
> .03µs.
>

The old HP GPS DO ex telco boxes used here as a lab frequency standards
typically show 10-30 ns uncertainty referenced to UTC. Pretty impressive
really, but overkill for ntp over unreliable udp paths...

Chris

[chris]

Checking notes, the other supported option for pps input is one of
the parallel printer port interface lines, which is at ttl. Would
have been the preferred option here, but could not find a way to
make it work under FreeBSD 12 and no one seemed to know if the code
works at all, so a dead end. Perhaps you know someone who has made it
work ?...

Chris

[William Unruh]

On 2022-06-16, Thibaut HUMBERT <plan...@gmail.com> wrote:
>
> I have a serial port, but I don't know how to convert the PPS output (0 / 3.3V) to RS232 (-5V / +5V).

Don't bothere since almost all serial ports will handle the 3 V just
fine. The 5 V standard is still there in the specs, but ignored by
almost all manufacturers.

Anyway, just try it. Nothing lost if you do.

[Daniel O'Connor]

You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.

It works very well in practise, especially for the cost & effort required.

[Daniel O'Connor]

> On 17 Jun 2022, at 17:12, Martin Burnicki <martin....@meinberg.de> wrote:

>
> Daniel O'Connor wrote:
>>> On 17 Jun 2022, at 12:52, Jim Pennino <ji...@gonzo.specsol.net> wrote:

>>> If all you need is accuracy in the 2 millisecond range, most recent USB
>>> GNSS dongles will achieve that without PPS.

>> You can easily do better than that with GPS/PPS over USB.
>

> Hm, USB v1 has only 1 ms timing frames, so if some USB v1 device (e.g. an USB hub) is involved, the accuracy may indeed be only in the range of ms.

Finding a USB 1 hub in this day and age would be an achievement in and of itself.

I do not think it is useful to claim it "might" be so poor when you would have to try very hard to make it that bad.

The basic case of "buy USB GPS interface, connect to PC" would be vastly better.

[David Woolley]

On 19/06/2022 07:38, Daniel O'Connor wrote:
>> OK, then to which of the USB connector pins do you connect the PPS
>> signal to get "PPS over USB"?

> You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.
>
> It works very well in practise, especially for the cost & effort required.

Taking the other side for this one, which of Ground, D+, D-, and VBus
have alternative names of CTS and RTS? (I guess I should add StdA_SSRX-,
StdA_SSRX+, StdA_SSTX+, and StdA_SSTX-, for USB 3.0, compatibility.)

[Daniel O'Connor]

None of course, but how do you think the CPU gets to know when a PPS edge appears on a 16550?

It is not magically wired into it, an IRQ is generated and has to be serviced before a timestamp can be taken. The bus it is on (LPC) is not designed for low latency and is not directly connected to the CPU..

[Daniel O'Connor]

> On 17 Jun 2022, at 23:38, David Taylor <david-...@blueyonder.co.uk.invalid> wrote:
>
> On 17/06/2022 03:03, Daniel O'Connor wrote:
>>> Yes, Thiebaud, USB is not good enough for PPS signals!
>> This is absolutely false.
>> If you are using it for NTP then GPS+PPS over USB is quite adequate (from personal experience).
>> Ian Lepore (RIP) who worked for Micro Semi and worked on FreeBSD did a bunch of tests on a PPS over USB setup and found it more than
>> acceptable for keeping a PC in (good) time. Here's the thread:https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html
>>> See if your motherboard has a true serial port - perhaps just as a header but not a back connector. If not, just set the offset of the PPS to ~10.3 milliseconds (10.3 - IIRC the offsets are in milliseconds but please check). Plus or minus 10.3, try it and see! Not perfect, but better than nothing.
>>>
>>> You might find better results using that GPS/PPS with a Raspberry Pi as a stratum-1 server and offering that as a server on your LAN.
>> The next level would be something where you can do an input capture on the PPS I don't think there are any pre canned solutions. I made one with a Beagle Bone Black and a uBox GPS module but it's not exactly turn key. Or for a server then you would need a fancy (ie $$$$) internal card.
>> The Raspberry Pi does not have an input capture timer, but I believe you can do better with DMA hackery (I haven't tried though).
>
> If a 125 us uncertainty in the PPS is something you can tolerate, so be it. If you are bothering with PPS then presumably you want better accuracy than can be achieved without it.

I think for standard PC timing in a network it is more than adequate.
Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.

> No need for DMA hackery. Standard NTP with the Raspberry Pi can handle PPS on a GPIO signal with a couple of edits to allow the PPS support already built into the kernel to be attached to the appropriate GPIO pin. Not out of the box, but very little effort required.
>
> The Raspberry Pi can act as a server for hundreds of clients. If you mean a PC-based Windows server, that's not something I would immediately recommend, but if you must a £20 serial card may be all you need to add.

Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.

[Jim Pennino]

Daniel O'Connor <dar...@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 23:31, Jim Pennino <ji...@gonzo.specsol.net> wrote:
>>
>> Daniel O'Connor <dar...@dons.net.au> wrote:
>>>
>>>> You of course can get the ASCII data over USB, but to get a PPS signal
>>>> you in general have to hack a USB GPS and add a signal wire for PPS then
>>>> hack some interface on the computer to accept PPS.
>>>
>>> This is absolutely not true in any meaningful sense.
>>
>> OK, then to which of the USB connector pins do you connect the PPS
>> signal to get "PPS over USB"?
>
> You can connect them to CTS or RTS, on FreeBSD these can then hook into the kernel PPS API.

Them? There is only one PPS signal line out of a GPS.

CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?

FYI while the Linux PPSAPI says it supports either RTS/CTS or CD, in
reality only CD (pin 1) is supported in the kernel code.

I know this to be true for at least Ubuntu (bug report filed) and likely
many others.

How do I know this?

Because when I got my commercial GNSS receiver with a high prescision,
managed oscillator with a guaranteed PPS accuracy of +/- 1 nanosecond
with PPS on pin 8 on the connector, I had to dig into the kernel code to
figure out why it did not work and had to build a cross over cable.

Also FYI, some of the pps-tools for Linux look directly at the RS-232
port and do not use the kernel PPSAPIi, so they will report a PPS signal
on RTS/CTS.

[Daniel O'Connor]

> On 19 Jun 2022, at 17:43, David Taylor <david-...@blueyonder.co.uk> wrote:

>
> On 19/06/2022 07:30, Daniel O'Connor wrote:
>> I think for standard PC timing in a network it is more than adequate.
>> Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.
>

>> Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.
>

> If PPS over USB is all you have, of course use it. But if you have a local stratum-1 server it's likely to produce much better results, just using a LAN connection.

I am not sure this is true, but the difference if probably negligible.

However.. if you had a local stratum 1 server then using a GPS receiver seems pointless unless you want redundancy..

> Probably on the RPi using an input capture timer wouldn't produce much better results than simply using the GPIO pins and the the built-in kernel PPS support and reference NTP. I tend to think of the RPi alone as "tens of microseconds or better", and capture

Input capture is nice because it means interrupt latency is no longer a problem.

The PPS edge is captured by the clock and so it doesn't matter how long the CPU takes to read it (until the next edge anyway..) there is no loss of accuracy.

> timer (PTP) as sub-microsecond level. Both are quite adequate for "standard PC timing".

Sure, but NMEA (even without PPS) is fine for "standard PC timing".

[David Woolley]

On 19/06/2022 13:46, Jim Pennino wrote:
> CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?

CTS is on pin 5, and RTS on pin 4, on an RS232 connector, which should
be a DB-25 one.

The DE-9 connector, used on PCs, is a TIA-574 connector, not an RS232
one, and RTS is on pin 7 (although not useful in this context, as it is
output from the PC).

[Jim Pennino]

David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 13:46, Jim Pennino wrote:
>> CTS/RTS is pin 8 on a RS-232 connector, so how is that "PPS over USB"?
>
> CTS is on pin 5, and RTS on pin 4, on an RS232 connector, which should
> be a DB-25 one.

You will be hard pressed to find a serial interface with a DB-25
connector these days but signals don't care about what connector you
use, which is why I would question your "which should be a DB-25".

> The DE-9 connector, used on PCs, is a TIA-574 connector, not an RS232
> one, and RTS is on pin 7 (although not useful in this context, as it is
> output from the PC).

While the 9 pin connector is not formally part of the RS-232 standard,
it has been the defacto standard connector for decades now.

Actually, RTS/CTS is on both pins 7 and 8.

Many commercial GPS boxes output the PPS signal on pin 8.

Which pin that goes to on the computer end depends on the cable used,
but for Linux the PPS signal needs to go to pin 1.

[David Woolley]

On 19/06/2022 16:17, Jim Pennino wrote:
> which is why I would question your "which should be a DB-25".

It's RS232's should be. Actually, Wikipedia seems to say that the D
version says must be. A lot of this thread is about RS232 compliance,
and part of that compliance is using the correct connector.

[Jim Pennino]

The signals don't care if the connector is DB-9, DB-25 or RJ-45.

The defacto standard for RS-232 has been DB-9 for decades.

As you said, current hardware usually far exceeds the performance
requirements of the 80 year old standard.

[Ralph Blach]

I use the Raspberry pi with GPS hat and it works great.  100 dollars and you have a great NTP server

Chip

--
This is ques...@lists.ntp.org
Subscribe: questions...@lists.ntp.org
Unsubscribe: questions+...@lists.ntp.org

--

Ralph "Chip" Blach
(919) 260-0097

[chris]

On 06/19/22 15:03, Daniel O'Connor wrote:
>
>
>> On 19 Jun 2022, at 17:43, David Taylor<david-...@blueyonder.co.uk> wrote:
>>
>> On 19/06/2022 07:30, Daniel O'Connor wrote:
>>> I think for standard PC timing in a network it is more than adequate.
>>> Using PPS over USB does give you an improvement over just serial traffic so why not use it since it's free.
>>
>>> Sure, but I would think something with an input capture timer will produce a better result again. It is just unfortunate the RPi can't do it.
>>
>> If PPS over USB is all you have, of course use it. But if you have a local stratum-1 server it's likely to produce much better results, just using a LAN connection.
>
> I am not sure this is true, but the difference if probably negligible.
>
> However.. if you had a local stratum 1 server then using a GPS receiver seems pointless unless you want redundancy..
>
>> Probably on the RPi using an input capture timer wouldn't produce much better results than simply using the GPIO pins and the the built-in kernel PPS support and reference NTP. I tend to think of the RPi alone as "tens of microseconds or better", and capture
>
> Input capture is nice because it means interrupt latency is no longer a problem.
>
> The PPS edge is captured by the clock and so it doesn't matter how long the CPU takes to read it (until the next edge anyway..) there is no loss of accuracy.
>
>> timer (PTP) as sub-microsecond level. Both are quite adequate for "standard PC timing".
>
> Sure, but NMEA (even without PPS) is fine for "standard PC timing".
>

The problem with that is that the system granularity can never be better
than one second, since its not known where within that second the timing
is, related to the utc tick.

Might be good enough for some, but properly setup ntp with pps sync can
can have an accuracy in microseconds, that's 6 orders of magnitude
better accuracy. In some cases, that doesn't matter, but some systems
worldwide need precision timing that ntp can provide.

Don't really understand what's meant by "input capture timer" ?. Is
that related to some polling method, or what ?...

Chris

[David Woolley]

On 20/06/2022 00:32, chris wrote:
> Don't really understand what's meant by "input capture timer" ?. Is
> that related to some polling method, or what ?...

I believe they mean a hardware clock, that can be read directly by the
software, and is also latched into a register when the PPS signal
arrives. A variation might be to start a hardware timer when the PPS
arrives, again making it directly readable.

Also, whilst NMEA is low priority, I suspect it is not uncommon to have
its generation scheduled at the PPS time, making it much closer to the
last PPS than the next.

[chris]

On 06/20/22 11:39, David Woolley wrote:
> On 20/06/2022 00:32, chris wrote:
>> Don't really understand what's meant by "input capture timer" ?. Is
>> that related to some polling method, or what ?...
>
> I believe they mean a hardware clock, that can be read directly by the
> software, and is also latched into a register when the PPS signal
> arrives. A variation might be to start a hardware timer when the PPS
> arrives, again making it directly readable.

Still doesn't explain how the pps state change gets into the
system at hardware level. Devil in the detail, as usual.
It sounds like a polled system, not an interrupt driven one,
which can never be as accurate as the latter. Assuming a poll
rate of say, 1mS, not unreasonable for a modern cpu, Then if
the pps state change is not seen at one poll, but is seen at
the next, then the uncertainty can never be better than that
1mS, since it cannot be known when during that 1 mS the state
transition occurred. Best results for ntp really need a true
real time os, but it's far more common to use general purpose
os's because of the out of the box functionality., but not
ideal.

>
> Also, whilst NMEA is low priority, I suspect it is not uncommon to have
> its generation scheduled at the PPS time, making it much closer to the
> last PPS than the next.

Working through the path, would expect the nmea sentence to be
synchronised to the pps, but that's not the end of the story.
GPS engines, ones seen here, typically run at 2400 or 4800 bauds,
or ~200uS per bit. Assume the sentence is 6 bytes, 10 bits per
byte, that's 12.5mS to end of message. The host must then decode
that, say 20mS total processing time. Depending on the host, that
could be fairly deterministic and the delay corrected for, but
the overall system is still limited to a 1 second bounded
uncertainty, not good at all for a public ntp server.

Sorry, but interrupt driven systems are the only way to get it
right...

Chris

[David Woolley]

On 20/06/2022 15:54, chris wrote:
> Still doesn't explain how the pps state change gets into the
> system at hardware level. Devil in the detail, as usual.
> It sounds like a polled system, not an interrupt driven one,

Interrupt system are I think pretty much always polled at the hardware
level.

> which can never be as accurate as the latter. Assuming a poll
> rate of say, 1mS, not unreasonable for a modern cpu, Then if
> the pps state change is not seen at one poll, but is seen at
> the next, then the uncertainty can never be better than that

The uncertainty is the clock period in the capture hardware, because the
hardware counts and returns the the number of its clock cycles, so you
know very precisely how long it was from the the PPS to when you polled.
Actually I think something like that is pretty standard for most
microcontrollers.

I believe there are Ethernet cards that do this to support, I think,
Precision Time Protocol, which I suspect is what high frequency traders use.

[David Woolley]

On 20/06/2022 21:32, David Woolley wrote:
> Actually I think something like that is pretty standard for most
> microcontrollers.

E.g. see <https://www.electronicwings.com/pic/pic18f4550-timer-capture>

[chris]

On 06/20/22 21:32, David Woolley wrote:
> On 20/06/2022 15:54, chris wrote:
>> Still doesn't explain how the pps state change gets into the
>> system at hardware level. Devil in the detail, as usual.
>> It sounds like a polled system, not an interrupt driven one,
>
> Interrupt system are I think pretty much always polled at the hardware
> level.
>
>> which can never be as accurate as the latter. Assuming a poll
>> rate of say, 1mS, not unreasonable for a modern cpu, Then if
>> the pps state change is not seen at one poll, but is seen at
>> the next, then the uncertainty can never be better than that
>
> The uncertainty is the clock period in the capture hardware, because the
> hardware counts and returns the the number of its clock cycles, so you
> know very precisely how long it was from the the PPS to when you polled.
> Actually I think something like that is pretty standard for most
> microcontrollers.

Sorry David, but that is incorrect. If you look at the app note you
posted, input capture section, quite clearly states that:

> When the rising or falling edge is detected at the CCP1 pin,
> the interrupt flag CCP1IF bit is set.

So it is a interrupt driven method, which is the only way
to guarantee synchronisation between an input event and
the system, at micro or even nanosecond accuracy.

In practice, there will be delays in the process between
the pps interrupt and ntpd. If the pps arrival time is
logged within the interrupt handler early and a counter
also started from zero, then the real arrival time can be
determined within ntp, irrespective of delays, by adding
the counter value to the pps event time. Not sure if ntp
does that at present, but it would need driver and kernel
support.

>
> I believe there are Ethernet cards that do this to support, I think,
> Precision Time Protocol, which I suspect is what high frequency traders
> use.

Not sure, but would expect that they use GPS clocks, which
can give nS timing sync anywhere on the planet. Well, just about
anywhere. A commonly used tech by millions with no understanding
needed of haw it works. Even working in tech, i'm still amazed by
what GPS achieves...

Chris

[David Woolley]

On 21/06/2022 01:31, chris wrote:
> Sorry David, but that is incorrect. If you look at the app note you
> posted, input capture section, quite clearly states that:
>
> > When the rising or falling edge is detected at the CCP1 pin,
> > the interrupt flag CCP1IF bit is set.
>

If you go to a more primary source
<https://ww1.microchip.com/downloads/en/DeviceDoc/60001122G.pdf>, you
will see, in the diagram on page 15-3, that the logic path for raising
interrupts diverges from that for doing the capture, after the event
detection, so the capture is not dependent on the interrupt occurring.

Also, on page 15-4, that the actual interrupt can be selectively disabled.

In my original response, I did meant to add that there would typically
be an interrupt, but that the interrupt could be handled with low
priority (you will get a good result any time until the timer actually
wraps round. Even then, the use of an interrupt is not a fundamental
requirement.

For a dedicated appliance, interrupts can actually be a liability, as
they can introduce race conditions. Nonetheless, I think all current
microcontrollers support them.

With precision time, over Ethernet, one would expect the normal Ethernet
device driver interrupt handling, but, for example, the device driver
might well service several incoming messages on one interrupt. However
capturing the event time still means that nano-second accuracy is possible.

[chris]

On 06/21/22 11:57, David Woolley wrote:
> On 21/06/2022 01:31, chris wrote:
>> Sorry David, but that is incorrect. If you look at the app note you
>> posted, input capture section, quite clearly states that:
>>
>> > When the rising or falling edge is detected at the CCP1 pin,
>> > the interrupt flag CCP1IF bit is set.
>>
>
> If you go to a more primary source
> <https://ww1.microchip.com/downloads/en/DeviceDoc/60001122G.pdf>, you
> will see, in the diagram on page 15-3, that the logic path for raising
> interrupts diverges from that for doing the capture, after the event
> detection, so the capture is not dependent on the interrupt occurring.
>
> Also, on page 15-4, that the actual interrupt can be selectively disabled.
>
> In my original response, I did meant to add that there would typically
> be an interrupt, but that the interrupt could be handled with low
> priority (you will get a good result any time until the timer actually
> wraps round. Even then, the use of an interrupt is not a fundamental
> requirement.

It's the only way to get nS sync with an incoming event and is the
standard way to do that in embedded work. The only alternative to an
interrupt driven model is polling, which is wasteful of cpu time and
more so as the poll interval becomes smaller. I guess you could use
a sliding window timer to lock on to the incoming pps event, but that
is so much more complex and wasteful than an interrupt driven solution.

>
> For a dedicated appliance, interrupts can actually be a liability, as
> they can introduce race conditions. Nonetheless, I think all current
> microcontrollers support them.

Both minis and micros have included interrupt capability for decades,
as that's the only way to efficiently process real time events.

>
> With precision time, over Ethernet, one would expect the normal Ethernet
> device driver interrupt handling, but, for example, the device driver
> might well service several incoming messages on one interrupt. However
> capturing the event time still means that nano-second accuracy is possible.

I would expect an interrupt per ethernet frame, as that's how the
controller chips are designed to be used. The frame crc and transfer is
offloaded from the host, with transfer via dma into host buffers.

Chris

[Thibaut HUMBERT]

I continued my tests with the NMEA+PPS on a CH341A in USB, and comparing over one night with several NTP sources: I am at +/- 1ms on average.
I tried with an ESP8266: without success.
I tried a Raspberry PI 1B: ok, but always an 10ms offset. And the solution is difficult to transport in the middle of nowhere for a night with the telescope.

Now, I use an another desktop computer (with RS232) with the CH341A for the NMEA on USB and the pin PPS directly connected on the RS232 CD.
The PPS signal is well detected by the software https://www.satsignal.eu/software/net.htm#SerialPortLEDs

However, I can't find the zip for using the PPS DLL on the real serial interface:
http://people.ntp.org/burnicki/windows/serialpps-20120321-signed.zip
The link is down, and nothing on Google....

Do you know where I can find the zip serialpps-20120321-signed.zip?
Thanks everyone!

[David Taylor]

On 22/06/2022 22:42, Thibaut HUMBERT wrote:
> I continued my tests with the NMEA+PPS on a CH341A in USB, and comparing over one night with several NTP sources: I am at ± 1ms on average.

> I tried with an ESP8266: without success.
> I tried a Raspberry PI 1B: ok, but always an 10ms offset. And the solution is difficult to transport in the middle of nowhere for a night with the telescope.
>
> Now, I use an another desktop computer (with RS232) with the CH341A for the NMEA on USB and the pin PPS directly connected on the RS232 CD.

> The PPS signal is well detected by the softwarehttps://www.satsignal.eu/software/net.htm#SerialPortLEDs

>
> However, I can't find the zip for using the PPS DLL on the real serial interface:
> http://people.ntp.org/burnicki/windows/serialpps-20120321-signed.zip
> The link is down, and nothing on Google....
>
> Do you know where I can find the zip serialpps-20120321-signed.zip?
> Thanks everyone!

Thibaut,

The original serial driver hack doesn't work on Windows-10, IIRC. Instead use
the PPS API Loopback Provider.


https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_for_windows/using_pps_signals_on_windows

As I don't see that for download, I have put my copy on my Web page.

https://www.satsignal.eu/ntp/x86/index.html
https://www.satsignal.eu/ntp/x86/loopback-ppsapi-provider.zip

Please let Martin Burnicki know about the errors on his Web page.
--
Cheers,
David
Web: http://www.satsignal.eu

[Thibaut HUMBERT]

Le jeudi 23 juin 2022 à 06:36:51 UTC+2, David Taylor a écrit :
> On 22/06/2022 22:42, Thibaut HUMBERT wrote:
> > I continued my tests with the NMEA+PPS on a CH341A in USB, and comparing over one night with several NTP sources: I am at ± 1ms on average.
> > I tried with an ESP8266: without success.
> > I tried a Raspberry PI 1B: ok, but always an 10ms offset. And the solution is difficult to transport in the middle of nowhere for a night with the telescope.
> >
> > Now, I use an another desktop computer (with RS232) with the CH341A for the NMEA on USB and the pin PPS directly connected on the RS232 CD.

> > The PPS signal is well detected by the software https://www.satsignal.eu/software/net.htm#SerialPortLEDs

> >
> > However, I can't find the zip for using the PPS DLL on the real serial interface:
> > http://people.ntp.org/burnicki/windows/serialpps-20120321-signed.zip
> > The link is down, and nothing on Google....
> >
> > Do you know where I can find the zip serialpps-20120321-signed.zip?
> > Thanks everyone!
> Thibaut,
>
> The original serial driver hack doesn't work on Windows-10, IIRC. Instead use
> the PPS API Loopback Provider.
>
>
> https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_for_windows/using_pps_signals_on_windows
>
> As I don't see that for download, I have put my copy on my Web page.
>
> https://www.satsignal.eu/ntp/x86/index.html
> https://www.satsignal.eu/ntp/x86/loopback-ppsapi-provider.zip
>
> Please let Martin Burnicki know about the errors on his Web page.
> --
> Cheers,
> David
> Web: http://www.satsignal.eu

Hi David!
I tested with your dll:
https://www.satsignal.eu/ntp/x86/loopback-ppsapi-provider.zip

The PPS was not detected, I don't know what I did wrong.
Here is the content of my ntp.conf:

server 127.127.20.3 minpoll 2 maxpoll 2 mode 89 prefer
fudge 127.127.20.3 time2 0.125 refid NMEA
server 127.127.22.1 minpoll 2 maxpoll 2 true
fudge 127.127.22.1 refid uPPS


FYI, the page https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_for_windows/using_pps_signals_on_windows was updated today, there is a new link to "serialpps-20120321-signed.zip".

[David Taylor]

On 23/06/2022 15:33, Thibaut HUMBERT wrote:
> Hi David!
> I tested with your dll:
> https://www.satsignal.eu/ntp/x86/loopback-ppsapi-provider.zip
>
> The PPS was not detected, I don't know what I did wrong.
> Here is the content of my ntp.conf:
>
> server 127.127.20.3 minpoll 2 maxpoll 2 mode 89 prefer
> fudge 127.127.20.3 time2 0.125 refid NMEA
> server 127.127.22.1 minpoll 2 maxpoll 2 true
> fudge 127.127.22.1 refid uPPS
>
>

> FYI, the pagehttps://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_for_windows/using_pps_signals_on_windows was updated today, there is a new link to "serialpps-20120321-signed.zip".

Thibaut,

It's not "my" DLL, but one provided by Meinberg IIRC.

If you use the PPS you /must/ mark one of your other sources as "prefer".
Without that any PPS doesn't work.

I take it that my Serial Port LEDs program shows a flashing DCD (when NTPd is
stopped)?

Good to hear that there is an updated link.
--
Cheers,
David
Web: https://www.satsignal.eu

[Thibaut HUMBERT]

David,
The extract from my ntp.conf shows that I have the "prefer" option on the nmea source from my USB<>CH341A<>RX/TX TTL GPS on the COM3 port.
I indicated it in a previous message, the DCD flashes well in SerialPortLEDs program at the same time as the pps connected to the CD pin of my RS232 COM1.

[David Taylor]

On 23/06/2022 22:03, Martin Burnicki wrote:
> It was not provided by Meinberg, either. The whole stuff was put
> together by a guy who actively participated on the NTP development.
>
> As described on the KB page, I had signed the binaries with Meinberg's
> key only to be able to use the driver on 64-bit systems.
>
> I have to admit, though, that I've personally never used a PPS on Windows.
>
>
> Martin

Thanks for the updates and correction, Martin! Who wrote it - was it Dave Hart
(not heard of him since he moved?) or someone else? I don't recall now.

PPS on Windows works well here on Win-64.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-...@blueyonder.co.uk
Twitter: @gm8arv

[Harlan Stenn]

On 6/24/2022 12:24 AM, Martin Burnicki wrote:

> David Taylor wrote:
>> On 23/06/2022 22:03, Martin Burnicki wrote:
>>> It was not provided by Meinberg, either. The whole stuff was put
>>> together by a guy who actively participated on the NTP development.
>>>
>>> As described on the KB page, I had signed the binaries with Meinberg's
>>> key only to be able to use the driver on 64-bit systems.
>>>
>>> I have to admit, though, that I've personally never used a PPS on
>>> Windows.
>>>
>>>
>>> Martin
>>
>> Thanks for the updates and correction, Martin!  Who wrote it - was it
>> Dave Hart (not heard of him since he moved?) or someone else?  I don't
>> recall now.
>

> Yes, it was Dave Hart, as mentioned on my KB page. ;-)
>
> Sadly I haven't heard from him for a very long time, either.

I chatted with him a couple of months' ago. He's doing OK.

>> PPS on Windows works well here on Win-64.
>

> Happy to hear this!
>
> Martin

--
Harlan Stenn <st...@nwtime.org>
http://networktimefoundation.org - be a member!

[David Taylor]

On 24/06/2022 11:26, Harlan Stenn wrote:
> I chatted with him a couple of months' ago. He's doing OK.

Thanks, that's good to hear. He did a lot of work, which was much appreciated.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-...@blueyonder.co.uk
Twitter: @gm8arv