[time-nuts] DCF77 & PPS

[folkert]

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
here).
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
-192.168.64.1    .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    129.70.132.36    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 <---
-194.109.22.18   193.79.237.14    2 u   18   64  377   17.321   -3.490   0.468
-194.109.20.18   193.79.237.14    2 u   12   64  377   17.292   -3.296   0.776
*193.79.237.14   .PPS.            1 u   20   64  377   19.607   -2.342   0.294
+192.87.36.4     .GPS.            1 u   64   64  377   21.556   -2.370   0.730
+134.221.205.12  .PPS.            1 u   40   64  377   20.372   -2.363   0.441
-172.29.0.11     134.221.205.12   2 u   42   64  377   18.350   -2.479   6.184

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

Allan deviation plot:
http://keetweej.vanheusden.com/~folkert/SHM0-peerstats.2013w10.png

Offset plot:
http://keetweej.vanheusden.com/~folkert/SHM0-offset.png
last 800 measurements:
http://keetweej.vanheusden.com/~folkert/SHM0-offset-last800.png

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

> > 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.
E.g.:
	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