[time-nuts] DCF77 & PPS

folkert folkert at vanheusden.com
Mon Mar 18 06:59:19 EDT 2013

Silly 1,2 instead of 0,0012 fudge: indeed a mistake.

How I measured when I wrote the first message:
 - I waited for a bit to be received
 - exact after the bit was received and "read" by my testprogram, I
   would check what the offset was to a second. e.g 13:45:12.456 would
   be an offset if 456ms
 - the linux system returns in microseconds, I would simple discard
   those 3 extra digits. eg. 13:45:12.456987 would become .456

Saturday night I "connected" the testprogram to NTP: when a bit was
received, I would check how many microseconds "after the second" the
system was and send that to NTPd (like above but doing microseconds
After a couple of days this gives:

     remote           refid      st t when poll reach   delay   offset  jitter
o127.127.20.1    .GPS.            0 l    1   16  377    0.000   -0.001   0.002
-    .GPS.            1 u   52   64  376    0.114   -0.021   0.021
x192.168.62.129  SHM(0)           2 u   49   64   37    2.080  154.251  82.784
x82.95.142.92    3 u   25   64  377   36.867   78.199   1.989
x127.127.28.0    .SHM0.           1 l    5    8  377    0.000  -263.48   3.437 <---
-    2 u   18   64  377   17.321   -3.490   0.468
-    2 u   12   64  377   17.292   -3.296   0.776
*   .PPS.            1 u   20   64  377   19.607   -2.342   0.294
+     .GPS.            1 u   64   64  377   21.556   -2.370   0.730
+  .PPS.            1 u   40   64  377   20.372   -2.363   0.441
-   2 u   42   64  377   18.350   -2.479   6.184

The (SHM0) source is the dcf77 pps source. does the same trick by the way using an MSF receiver but
lets ignore that for now.

Allan deviation plot:

Offset plot:
last 800 measurements:

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

Hopefully my explanation above makes it more clear.

While writing this I got an epiphany: I think I know what causes the
0.26s offset: the serial port is configured at 50Bps, 8, n, 1. So each
byte takes 10 bits (8 data-, 1 start- and 1 stop bit). So a maximum of 5
characters per second or 0,2s per character. Each DCF77 bit is signalled
as a byte to the system, so that explains 0,2s of the offset seen. Maybe
the receiver needs another 0,6s +/- to convert the received bits into
something it can transmit over the TX line of the serial port.

What I should do, is open the casing of the receiver and connect the
signal coming from the antenna to the DCD pin of that serial port.

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

I don't have one but in a couple of weeks it is my birthday so maybe

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

I did it the ascii way.
	value = floor(value * 1000.0) / 1000.0;

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

Yes, I read this weekend that 0 and 1 are 100ms versus 200ms.

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

It's probably the naive way of measuring (see my epiphany).

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

Thanks & regards,

Folkert van Heusden

www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg
ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of
HP/UX en win een vlaai naar keuze
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

More information about the time-nuts mailing list