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

Fri Jul 24 02:58:40 CEST 2009

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.

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?

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