[ntp:questions] Standalone PPS
unruh at invalid.ca
Mon Jun 10 18:33:03 UTC 2013
On 2013-06-10, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> On 10/06/2013 15:34, patrick200075011 at gmail.com wrote:
>> I would like to get some points of view before starting to write some code.
>> I am trying run an electronic board I designed.
>> A super stable OXCO generates pulse per second.
>> I don't have any absolute reference time. The pulse has a constant but unpredictable phase due to the state of the electronics a power up.
>> My goal is to keep a set of machine with a relative time between each other of 1mS and an absolute time of 1 second. I have a way to set the system clock at start up (before ntp)
>> I can not use the driver 22 alone as I don't have an absolute reference. If I use both the drivers 22 and 1 the phase of the PPS make this channel rejected.
>> I plan to write a driver that is a merge between 1 and 22, let's call it sapps.
>> * Sapps_start sapps_time sapps_poll are copied from the driver 22 (if they are really needed)
>> * sapps_init fetches the current_time, fetches the assert in /sys/class/pps<u>/assert, keeps the digits after the decimal point, substracts them from the current time and set it as the reference
>> PS Also people who would like to design simplified electronics for radio control can be interested by this. As an example, the DFC77 is a data encoded by pulses per second of 100 or 200 mS (with a drop at the second 59)
> For a stand-alone set of PCs, take a look at "orphan mode" NTP. I don't
> know whether you can combine this with sending a common PPS signal to
> all the PCs, though. You may be able to get 1 ms just with NTP alone,
> though, if the loading is light and you use a short local polling interval.
> There may be an additional difficulty with Windows PCs in that PPS works
> by having the NMEA driver timestamp the first received packet of serial
> data with the time of the PPS transition on the DCD line, so if there is
> no serial data the PPS may not be registered. Again I am not
> sufficiently expert to give a definitive answer on that - just a
> warning. As you mention a UNIX-like file name this may not be a problem
> for you, but someone else has mentioned a similar issue to me just
> recently and may be reading this group.
IF you disable interrupt coalescing it should be easy to get 10micro
(not milli) second on the machines (assuming they are Linux machines.
Windows may be a whole other thing.)
More information about the questions