[time-nuts] DCF77 & PPS
Bob Camp
lists at rtty.us
Sat Mar 16 01:49:38 UTC 2013
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
More information about the Time-nuts_lists.febo.com
mailing list