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?

Le jeudi 16 juin 2022 à 09:26:07 UTC+2, Thibaut HUMBERT a écrit :
> 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?

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?

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.

Le jeudi 16 juin 2022 à 10:28:00 UTC+2, David Woolley a écrit :
> 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.

To do the inversion, I just changed the "Pulse Mode" parameter to "Falling edge" to "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)

Le jeudi 16 juin 2022 à 10:28:00 UTC+2, David Woolley a écrit :
> 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.

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)

> On 16 Jun 2022, at 17:57, David Woolley <david@ex.djwhome.demon.invalid> wrote:
>
> 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.

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 questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

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

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

Thibaut HUMBERT <planetibo@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".

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

On 06/16/22 16:20, Jim Pennino wrote:
> Thibaut HUMBERT<planetibo@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 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

chris <chris-nospam@tridac.net> wrote:
> On 06/16/22 16:20, Jim Pennino wrote:
>> Thibaut HUMBERT<planetibo@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.

On 06/17/22 00:34, Jim Pennino wrote:
> chris<chris-nospam@tridac.net> wrote:
>> On 06/16/22 16:20, Jim Pennino wrote:
>>> Thibaut HUMBERT<planetibo@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.
>

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

> On 17 Jun 2022, at 00:07, David Taylor <david-taylor@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).

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

Quoting Daniel O'Connor <darius@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/
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

Daniel O'Connor <darius@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 00:07, David Taylor <david-taylor@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.

> On 17 Jun 2022, at 12:05, Dan Drown <dan-ntp@drown.org> wrote:
>
> Quoting Daniel O'Connor <darius@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
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

> On 17 Jun 2022, at 12:52, Jim Pennino <jimp@gonzo.specsol.net> wrote:
> Daniel O'Connor <darius@dons.net.au> wrote:
>>
>>
>>> On 17 Jun 2022, at 00:07, David Taylor <david-taylor@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.

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

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.

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.

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

Daniel O'Connor <darius@dons.net.au> wrote:
>
>
>> On 17 Jun 2022, at 12:52, Jim Pennino <jimp@gonzo.specsol.net> wrote:
>> Daniel O'Connor <darius@dons.net.au> wrote:
>>>
>>>
>>>> On 17 Jun 2022, at 00:07, David Taylor <david-taylor@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"?

David Taylor <david-taylor@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.
>
> 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.

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.

On 06/17/22 12:32, David Woolley wrote:
> 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.

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

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.

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.