[time-nuts] DCF77 & PPS

[Bob Camp]

Hi

Ummm…. errrrr….. I think you slipped a decimal point...

On Mar 15, 2013, at 8:49 PM, folkert <folkert at vanheusden.com> wrote:

> Hi,
> 
> Now that my two servers have a garmin 18x lvc connected to them, their
> time keeping is nice.
> 
> E.g. this one:
> 
>     remote           refid      st t when poll reach   delay   offset  jitter
> o127.127.20.0    .GPS.            0 l    6   16  377    0.000   -0.006   0.003
> [ other clocks skipped for brievety ]
> 
> They can be reached from the internet at:
> - clock1.trustedtimestamping.com ipv4 & ipv6
> - clock2.trustedtimestamping.com ipv6 only  <- I had to restart ntpd on
>  that system 10 minutes ago because I confused ntpd by opening the
>  serial via which the gps is connected accidently with an other
>  program, so it has to settle
> 
> Both systems run Linux. Clock1 kernel 3.2 and clock2 runs 2.6.38.
> 
> Without ntpd + gps it looses minutes per day (altough when I checked
> minutes ago the drift was only 13.637 ppm?!).
> 
> I used to also have an MSF receiver but a couple of years the radio
> transmitter in England was replaced by a weaker one so I receive mostly
> noise now.
> 
> Now that it works, it is somewhat boring.
> So I got my DCF77 clock from the attic and decided to use it different
> then how I'm supposed to use it: as a PPS source! I figured (inspired by
> http://remco.org/index.php/2008/06/09/dcf77-pps-experiments-with-a-dcf77-radio-module-using-ntpd/
> ).
> As a quick test I hacked the testdcf.c to show the number of
> milliseconds the clock was at when it had received a bit. If I remember
> correctly DCF77 sends 60 bits per minute so each bit should be at a
> second edge. I expected either a small constant difference or values
> that would be over the whole -0.5s ... 0.5s band.
> 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 and checked how often each
> offset occured:
> 
> test run 1:
>      1 251
>     17 255
>     38 259
>     37 263
>     22 267
>      5 271
> 
> test run 2:
>      1 251
>     10 255
>      1 257
>     43 259
>      1 261
>     44 263
>     17 267
>      3 271
> 
> test run 3:
>      2 255
>     18 259
>     60 263
>     32 267
>      8 271
> 
> Column 1: number of occurences, column 2: the offset.
> 
> 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.
> 
> What do you guys think?
> 
> 
> (Regarding the 250+ ms offset: the distance of my house to Mainflingen
> in Germany (where the DCF77 atomic clock is located) is +/- 374.766km (I

Last time I checked the speed of light was right around 300,000 KM / second (299,792.xxx). More or less it should take DCF77 a bit over 1 milliseconds (not 1 second) to get to you.

> live in Gouda, the Netherlands), so that is an offset of +/- 1.25012s.)
> 
> 
> Folkert van Heusden
> 
> -- 
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

Bob