[time-nuts] DCF77 & PPS

[Chris Albertson]

Something is wrong.  The delays you are seeing are NOT caused by
propagation delay unless you are living on the moon.

I think it is more likely your NTP server is misconfigured and is off
by one.    But then you'd notice that you do not track the Internet
pool servers.  Must be something else.  As for why there are only a
few fixed offsets, my guess is there are fixed delays in your
measurement system.  You'd have to tell us EXACTLY how you are
measuring.




On Fri, Mar 15, 2013 at 5: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
> 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.



-- 

Chris Albertson
Redondo Beach, California