[time-nuts] DCF77 & PPS

[Hal Murray]

folkert at vanheusden.com said:
> So my guestimate is that 259 and 263 are the values to look for and I should
> ignore the others so that I don't confuse ntpd. 

That doesn't make sense to me, probably because I don't understand your data 
collection environment and/or maybe it's dong something strange.

I see several things that I don't understand.  One is the big offset.  The 
second is the 4 ms steps between sample buckets.

Do you have a scope?  The simplest way to see what's going on would be to 
trigger on the PPS from the GPS unit and look at the DCF77 signal.

> The result was neither! From visual inspection it looked as if only 3 or 4
> different offsets were registered. So I ran 3 tests where I took 120
> offset-samples, masked of the microseconds ...

How did you mask off the microseconds?  Did you do that in binary or drop the 
right part of an ascii string?  If you masked in binary, maybe you got 2 
extra bits.


There are 2 parts to decoding something like the DCF77 signal.  One is to get 
an accurate marker for the PPS signal.  The other is to figure out the time 
for each PPS by decoding the pattern of pulse widths.  You should be able to 
see the pulse widths if you capture both sides of the PPS signal.

One common way to get a large/strange offset is to use the wrong edge of the 
PPS signal.  If that's what was happening, I'd expect to see several clumps 
of offsets corresponding to the different pulse widths.  I only see one broad 
clump.

I wouldn't worry about confusing ntpd, at least not at this level.  It has a 
noise reduction mechanism.  It puts all the samples into a fifo.  When the 
driver (PPS/Atom or SHM or ...) gets polled, ntpd sorts the buffer then 
discards 1/3 of the samples as (potentially crazy) outliers.

Other things to try:
  Unplug and/or turn off GPS.
  Unplug and/or turn off DCF77.
  


-- 
These are my opinions.  I hate spam.