[LinuxPPS] 1PPS Atom Ref Clock Not being Polled?

Thu Jul 23 20:12:41 CEST 2009

On Wednesday 22 July 2009 11:03:23 pm K. Connolly wrote:
> On Wed, 22 Jul 2009, Hal V. Engel wrote:
> > This looks really strange to me.  It appears that your machine is seeing
> > the clear events but NOT the assert events.
>
> Well, I had a vague memory of the ppstest results looking good, so after
> toying with unloading and reloading all the serial/pps-related modules and
> noticing different results, I decided to reboot the system. Whatever that
> did, it fixed things. Now I consistently get a "nice" looking ppstest
> result, with a clear and assert sequence 

> (Note, however, that the LinuxPPS
> wiki only shows an assert event... Whereas I have both, clear and
> assert?):

This is one of the things on the wiki that causes some confusion.  The wiki 
shows the ppstest results for the ktimer fake kernel PPS but it does not 
clearly document that it is not using a real PPS device for this.  The wiki 
should clarify this and should also show what a testpps looks like with at 
least one real world device so that people know what to expect.

>
> # ./ppstest /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1248328039.918108480, sequence: 14217 - clear
> 1248328039.918140245, sequence: 14225
> source 0 - assert 1248328040.918084706, sequence: 14218 - clear
> 1248328040.918109885, sequence: 14226
> source 0 - assert 1248328041.918062542, sequence: 14219 - clear
> 1248328041.918093635, sequence: 14227
> source 0 - assert 1248328042.918037012, sequence: 14220 - clear
> 1248328042.918063567, sequence: 14228
> source 0 - assert 1248328043.918015496, sequence: 14221 - clear
> 1248328043.918045888, sequence: 14229
> source 0 - assert 1248328044.917992022, sequence: 14222 - clear
> 1248328044.918016521, sequence: 14230

This looks better but I see a new difference from what I see on my machine in 
the above output.  On my machine the assert and clear events either have the 
same sequence number or are at most have a difference of 1.  Yours are 
different by 8 in the above example.  I don't know if this is significant but 
as a guess it appears that this might indicate that the OS is not catching all 
of the assert events on your machine.  If that is the case then the difference 
in the assert and clear sequence should increase as you let testpps run 
longer. 

>
>
> Despite this promising result, the behavior of my NTPd is still the same,
> and the PPS device is not being polled. And, for what it's worth, I tried
> switching the rising edge detection to falling edge, to no avail. UHG.
>
> -Kevin

You may be the first person to use a device with such a short PPS pulse with 
LinuxPPS.  I have seen stuff on the net where users have had GPS devices with 
very short PPS pulses where they used a conditioning circuit to get a longer 
pulse that they then used for their timing application.   

Virtually all of those using LinuxPPS have devices that have MUCH longer PPS 
pulses.  These will typically be 100ms to 200ms which is about 4 orders of 
magnitude longer.  For example there are a bunch of us that use Motorola 
Oncores and these have a 200ms PPS pulse.  The Garman 18 series is also 
popular and I think by default has a 200ms pulse.  So there is not much, if 
any, experience here with short pulse length devices like yours. 

From the above PPS test it appears that your PPS pulse is about 25us (0.025ms) 
long which is way shorter than the refclocks that most of us use.  I am not 
sure if this is related to what you are seeing but I am curious if anyone else 
here is using a refclock with a very short PPS pulse like your device.   If so 
did you have any issues with the device?

From http://www.febo.com/pages/soekris/

''The PPS signal driving the Elan timer must be a positive pulse (going from 0 
volts to 5 volts at the on-time point) and must be at least one timer tick 
long -- that means at least 1 millisecond (and preferably 2 or 3 ms to allow 
room for error) if the "HZ" value in the kernel is set to 1000 as recommended 
below. If your signal does not meet these requirements, a TAPR FatPPS can 
condition the signal to these values."

This web page is not about LinuxPPS since the machine being described is a 
FreeBSD derived machine.  So the above may not be valid for a LinuxPPS based 
machine (anyone know?).  

As you can see there is even a RS-232 converter available to lengthen the PPS 
pulse for devices like yours.  So it appears to be a known and fairly common 
issue.   The FatPPS device is $49 plus shipping (ouch!) so it is not cheap but 
it is also produced in very small numbers so this likely accounts for the high 
price.  There is a manual for the FatPPS device on-line and it has a 
schematic.  The TAPR folks are Ham radio types and Ham radio types almost 
always make schematics available since it is the nature of the beast.  You 
should be able to build the device based on the schematic for perhaps $10 to 
$15 if you are handy with a soldering iron since the circuit appears to be 
fairly simple and only involves a handful of components.  This circuit will 
lengthen the PPS pulse to at least 25ms but this can be adjusted by changing 
the values of some of the components. 

>
>
>    Could this be because of the short
>
> > length of the PPS pulse?  From my reading for this to be reliable the
> > pulse length has to be at least = 1/Hz rate of the kernel (IE. 100ms on a
> > 100Hz system or 10ms on a 1000Hz system).  

I was off by an order of magnitude with the above.  It should have read:

... 10ms on a 100Hz system or 1ms on a 1000Hz system ... 

> > But I don't know for sure that
> > this is really true but in any case your pulse is 20us (0.02ms) and this
> > is way faster.  So this is at least suspect.
> >
> > Also
> >
> >> server 127.127.22.0 minpoll 4 maxpoll 4
> >> fudge 127.127.22.0 flag3 1 flag2 0 time1 0.000 stratum 0
> >
> > You are telling ntp to use the assert edge (flag2 0) and since you are
> > not seeing the assert when you run ppstest I think this is why ntp is
> > failing since it never see an assert.  As a test try using the clear edge
> > (flag2 1). If that works then you know that the problem is that the
> > machine is not seeing the assert events.
> >
> > Hal
> >
> > _______________________________________________
> > LinuxPPS mailing list
> > LinuxPPS at ml.enneenne.com
> > http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> > Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20090723/1d2fcf40/attachment.html 