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

[Hal V. Engel]

On Thursday 23 July 2009 05:58:40 pm K. Connolly wrote:
> On Thu, 23 Jul 2009, Hal V. Engel wrote:
> > > 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.
>
> I believe you are right. I cleared my ldattach and re-attached, then ran
> ppstest from the beginning and after about three minutes they de-synced
> by one, with the assert sequence repeating once (which I guess means the
> assert was missed):
>
>
> source 0 - assert 1248396147.993355583, sequence: 179 - clear
> 1248396147.993379275, sequence: 179
> source 0 - assert 1248396148.993357325, sequence: 180 - clear
> 1248396148.993386715, sequence: 180
> source 0 - assert 1248396149.993354740, sequence: 181 - clear
> 1248396149.993381368, sequence: 181
> source 0 - assert 1248396150.993354868, sequence: 182 - clear
> 1248396150.993384696, sequence: 182
> source 0 - assert 1248396150.993354868, sequence: 182 - clear
> 1248396151.993375486, sequence: 183
> source 0 - assert 1248396152.993353129, sequence: 183 - clear
> 1248396152.993381570, sequence: 184
> source 0 - assert 1248396153.993350123, sequence: 184 - clear
> 1248396153.993381650, sequence: 185
>
>
> I will look into the pulse lengthening (we have enough electronics in this
> lab to set that up relatively easily, I think), thank you for your
> thoughts/information on that topic. But, just for the sake of commenting:
> -somewhere- out there I did come across a forum with a person that had a
> 20us PPS signal that got it working, but, as things go, they gave no
> comments beyond "you guys were wrong, it wasn't my pulse width, I've got
> it working now" and then evaporated into the abyss that is the internet.
> They made a vague mention of "hardpps" but I couldn't find more
> information on that topic.

"hardpps" would mean that it was a FreeBSD system or a system derived from 
FreeBSD.  So it is a different set of device drivers being used for the serial 
port.  I think that this could also be very dependent on the hardware (IE. the 
specifics of the computer hardware like the serial port hardware).  So a very 
short pulse width might work on some machines but not others.  In any case 
there is a significant amount of evidence that short pulse widths are an issue 
at least on some setups and there does appear to be some issues with lost 
assert events on your machine that could be explained by this issue.

One thing that might bare on this is that using hardpps on a FeeBSD system 
cuts out some of the ntp code path.  Not sure if that is significant.  In any 
case if you have access to facilities that will allow you to lengthen the 
pulse then this should be fairly easy to test.  Either a longer pulse fixes 
the problem or is does not. 

>
> Furthermore, despite there being some apparent problem with the asserts
> being captured 100%, ppstest still does show -some- (a lot, actually) of
> assert/clear events quite nicely, so shouldn't NTPd have an iota of
> functionality? i.e., keeping the problem of my PPS source not being polled
> at all in mind, does this assert/pulse width issue seem like a likely
> candidate for a solution?

I don't know how likely it is.  When I boot my machine over to Windows I use a 
newer version of ntp that will use the Atom driver (the Oncore driver does not 
work at this point in Windows otherwise I would use it) and it takes a long 
time (7 to 8 minutes most of the time) to decide that the PPS from my Oncore 
is good to go where as when I use the Oncore driver when booted to Linux it 
syncs up in perhaps 30 seconds or so and that includes the overhead of 
initializing the Oncore which is something that does not happen on Windows.  
So the Atom driver does appear to be very picky about the PPS signal and about 
when it will start working.  Clearly much more so than the Oncore driver.

>
> It's Friday here (Japan) and I've got some other work this afternoon, so
> I'll send an update in a few days!
>
> Cheers,
>
> -Kevin
>
> > > 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