Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Ralph Blach]

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

Chip

On Sun, Jun 19, 2022 at 8:33 AM David Woolley
 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.
>
> 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).
> --
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
>
>

-- 
Ralph "Chip" Blach
(919) 260-0097

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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


 quotes ≤30 
nanoseconds, 95% of the time.  That probably includes uplink allowances. 
 Also, I'm not sure if UTC() 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.

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Ralph Blach]

I like the adafruit gps hat

Chip Blach

On Fri, Jun 17, 2022, 1:16 PM Terje Mathisen  wrote:

> 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.
> >
> > GPS should be able of achieving time transfer accuracies of better than
> > .03µs.
>
> 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
>
> --
> - 
> "almost all programming can be viewed as an exercise in caching"
> --
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
>
>

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Terje Mathisen]

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.

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


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

--
- 
"almost all programming can be viewed as an exercise in caching"
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Jim Pennino]

Daniel O'Connor  wrote:
> 
> 
>> On 17 Jun 2022, at 12:52, Jim Pennino  wrote:
>> Daniel O'Connor  wrote:
>>> 
>>> 
 On 17 Jun 2022, at 00:07, David Taylor 
  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"?
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[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

On Fri, Jun 17, 2022, 8:08 AM David Taylor
 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.
>
> --
> Cheers,
> David
> Web: http://www.satsignal.eu
> --
> This is questions@lists.ntp.org
> Subscribe: questions+subscr...@lists.ntp.org
> Unsubscribe: questions+unsubscr...@lists.ntp.org
>
>
>
>
>

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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


--
Cheers,
David
Web: http://www.satsignal.eu
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Jim Pennino]

Daniel O'Connor  wrote:
> 
> 
>> On 17 Jun 2022, at 00:07, David Taylor 
>>  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.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

Re: [questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Dan Drown]

Quoting Daniel O'Connor :
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+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Jim Pennino]

chris  wrote:
> On 06/16/22 16:20, Jim Pennino wrote:
>> Thibaut HUMBERT  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.
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[Jim Pennino]

Thibaut HUMBERT  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".
-- 
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

[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
--
This is questions@lists.ntp.org
Subscribe: questions+subscr...@lists.ntp.org
Unsubscribe: questions+unsubscr...@lists.ntp.org

[questions] Re: GPS+PPS vs NTP server, why a huge offset ?

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

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