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

Le mardi 21 juin 2022 à 23:45:35 UTC+2, chris a écrit :
> 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

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!

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

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

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

Le jeudi 23 juin 2022 à 17:04:12 UTC+2, David Taylor a écrit :
> 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" rel="nofollow" target="_blank">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

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.

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-taylor@blueyonder.co.uk
Twitter: @gm8arv
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

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 <stenn@nwtime.org>
http://networktimefoundation.org - be a member!
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

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-taylor@blueyonder.co.uk
Twitter: @gm8arv
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org