Tobit LAN!Time DCF77 receiver not working
Marc-Andre Alpers
I have buy an Tobit LAN!Time DCF-77 serial port receiver but this device
will not work with ntp as referenc clock.
I have found this site http://www.woody.ch/tobit_ntp.php and have the same
configuration.
# Local Clock
server 127.127.8.0 mode 16 prefer
The symlink have i set.
Wenn i start the ntpd the LED on the device beginns flashing. But the ntpd
does not receive any time data.
23 Dec 14:37:31 ntpd[19799]: NTP PARSE support: Copyright (c) 1989-2006, Frank Kardel
23 Dec 14:37:31 ntpd[19799]: PARSE receiver #0: reference clock "RAW DCF77 CODE (DTR CLR/RTS SET)" (I/O device /dev/refclock-0, PPS device /dev/refclock-0) added
23 Dec 14:37:31 ntpd[19799]: PARSE receiver #0: Stratum 0, trust time 00:00:00, precision -20
23 Dec 14:37:31 ntpd[19799]: PARSE receiver #0: rootdelay 0.000000 s, phase adjustment 0.258000 s, PPS phase adjustment 0.000000 s, normal IO handling
23 Dec 14:37:31 ntpd[19799]: PARSE receiver #0: Format recognition: RAW DCF77 Timecode
23 Dec 14:37:31 ntpd[19799]: PARSE receiver #0: NO PPS support
23 Dec 14:37:31 ntpd[19799]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
23 Dec 14:40:45 ntpd[19799]: clock GENERIC(0) event 'clk_noreply' (0x01)
23 Dec 14:40:45 ntpd[19799]: peer GENERIC(0) event 'event_peer_clock' (0x85) status 'unreach, conf, 1 event, event_peer_clock' (0x8015)
23 Dec 14:40:45 ntpd[19799]: PARSE receiver #0: interval for following error message class is at least 00:01:00
23 Dec 14:40:45 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
23 Dec 14:41:51 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
23 Dec 14:45:04 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
23 Dec 14:47:14 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
23 Dec 14:48:20 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
23 Dec 14:50:29 ntpd[19799]: PARSE receiver #0: interval for following error message class is at least 01:00:00
23 Dec 14:50:29 ntpd[19799]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
The Clock works correctly on windows with the programm DCF77_32.exe provided
on this site: http://www.rrs-web.net/in3her/dcf77_32.html
I use Debian Lenny and ntpd 4.2.4p4
I have test the clock with mode 14 and mode 5 but nothing works.
MfG Marc-Andre Alpers
Rob van der Putten
Marc-Andre Alpers wrote:
> The Clock works correctly on windows with the programm DCF77_32.exe provided
> on this site: http://www.rrs-web.net/in3her/dcf77_32.html
This is about a Conrad DCF77 receiver. A Conrad DCF77 receiver doesn't
have a LED.
And NTPD usually receives data on RXD.
Maybe you can post a link to the receiver you're using.
<Cut>
Regards,
Rob
--
Nowadays people know the price of everything, and the value of nothing
Oscar Wilde
Marc-Andre Alpers
> Maybe you can post a link to the receiver you're using.
I can give you a Picture:
http://666kb.com/i/bf7er4kfwd3feibip.jpg
MfG marc-Andre Alpers
Rob van der Putten
Marc-Andre Alpers wrote:
> I can give you a Picture:
> http://666kb.com/i/bf7er4kfwd3feibip.jpg
Definitly not a a Conrad.
Anyway, some specs would be nice. Lacking those a bit of reverse
engineering.
Have you tried a RS232 tester? Which LEDs are on? Which colour? Which
one blinks?
Marc-Andre Alpers
> Have you tried a RS232 tester? Which LEDs are on? Which colour? Which
> one blinks?
I have no RS232 tester. The cover of the receiver is sealed. No screws.
http://666kb.com/i/bf7g1grgo1sbus2c1.jpg
The connector inside:
http://666kb.com/i/bf7fxqd8cr17q7d8x.jpg
http://666kb.com/i/bf7g2xelg4xqppx3l.jpg
The transistor type is:
MC78L
05ACP
M535
MfG Marc-Andre Alpers
Marc-Andre Alpers
http://666kb.com/i/bf7gu30cuwvtkayfl.jpg
http://666kb.com/i/bf7gswr7gmq48o4i9.jpg
The ICs are one MAX350 and one 74HC14D.
The red wire is ground.
The black wire is +5V DC
On brown an orange wire i have puls voltage up to 12 volt every second. But
i only have a cheap digi multimeter. The numbers on the display are flashing
crazy.
Sorry for my bad english.
MfG Marc-Andre Alpers
Marc-Andre Alpers
Befor sync:
http://666kb.com/i/bf7hgd6exsvtpuf2p.bmp
After sync:
http://666kb.com/i/bf7hia21x28co76j5.bmp
MfG Marc-Andre Alpers
E-Mail Sent to this address will be added to the BlackLists
> Es schrieb Rob van der Putten:
>> Maybe you can post a link to the receiver you're using.
> I can give you a Picture:
> http://666kb.com/i/bf7er4kfwd3feibip.jpg
(Shrug)
Looks like a SURE RPC modul DCF 77 Funkuhr ?
<http://www.linum.com/de/produkte/hardware/funkuhr/dcf77/sure/seriell/fotos.htm>
Pinouts
<http://www.linum.com/de/support/funkuhr/verlaengerungskabel.htm>
Install
<http://www.linum.com/FTPDIR/SUPPORT/SURE/AUSRICHT.PDF>
Linux Support
<http://www.linum.com/FTPDIR/SUPPORT/XNTP/XNTP.PDF>
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Marc-Andre Alpers
> Looks like a SURE RPC modul DCF 77 Funkuhr ?
> <http://www.linum.com/de/produkte/hardware/funkuhr/dcf77/sure/seriell/fotos.htm>
Yes this is the Clock. With this name i found this thread:
http://lists.ntp.isc.org/pipermail/questions/2006-January/008689.html
But it looks that i have an other problem. I receive nothing. The LED
flashes well and ntpd parse nothing.
MfG Marc-Andre Alpers
Dave Hart
> > Looks like a SURE RPC modul DCF 77 Funkuhr ?
>
> Yes this is the Clock. With this name i found this thread:
>
> http://lists.ntp.isc.org/pipermail/questions/2006-January/008689.html
>
> But it looks that i have an other problem. I receive nothing. The LED
> flashes well and ntpd parse nothing.
The same poster who referred you to the linum.com URL above also
provided a link to a "Linux Support" PDF. I do not read German
particularly well, but I did see a reference to parse mode 5, have you
tried that?
Cheers,
Dave Hart
Marc-Andre Alpers
>The same poster who referred you to the linum.com URL above also
>provided a link to a "Linux Support" PDF. I do not read German
>particularly well, but I did see a reference to parse mode 5, have you
>tried that?
Yes i have tried mode 5, but then the LED does not flashing. Only in mode
16 the LED flashes.
The paper is realy old it refers to xntp and for Suse Linux 6.3 up to 7.3.
In this paper they say that after xntp 4.1.0 the mode 16 is the correct
mode for this clock. XNTP bevor 4.1.0 must be patched with code form
linum.
The serial port is ok. I have on the same maschine WinXP installed,
and the clocks works correct with other software. I try to use
Meinberg NTPD with this clock, but 127.127.8.1 mode 16 does
not work on windows.
MfG Marc-Andre Alpers
Marc-Andre Alpers
>The same poster who referred you to the linum.com URL above also
>provided a link to a "Linux Support" PDF. I do not read German
>particularly well, but I did see a reference to parse mode 5, have you
>tried that?
Yes i have tried mode 5, but then the LED does not flashing. Only in mode
16 the LED flashes.
The paper is realy old it refers to xntp and for Suse Linux 6.3 up to 7.3.
In this paper they say that after xntp 4.1.0 the mode 16 is the correct
mode for this clock. XNTP bevor 4.1.0 must be patched with code form
linum.
The serial port is ok. I have on the same maschine WinXP installed,
and the clocks works correct with other software. I try to use
Meinberg NTPD with this clock, but 127.127.8.1 mode 16 does
not work.
MfG Marc-Andre Alpers
Marc-Andre Alpers
On my search i have found this:
http://www.buzzard.me.uk/jonathan/radioclock.html
I installed the programm and start the test mode. After a few seconds this
output scrolls over my screen:
lanserver:~# radioclkd -t ttyS0
DCD: 1 0 0 CTS: 2 4 490096 DSR: 1 0 0
DCD: 1 0 0 CTS: 3 5 794094 DSR: 1 0 0
DCD: 1 0 0 CTS: 4 5 805523 DSR: 1 0 0
DCD: 1 0 0 CTS: 4 3 879915 DSR: 1 0 0
DCD: 1 0 0 CTS: 4 3 880329 DSR: 1 0 0
DCD: 1 0 0 CTS: 5 5 805992 DSR: 1 0 0
DCD: 1 0 0 CTS: 5 3 880654 DSR: 1 0 0
DCD: 1 0 0 CTS: 5 3 881583 DSR: 1 0 0
DCD: 1 0 0 CTS: 5 3 879032 DSR: 1 0 0
DCD: 1 0 0 CTS: 5 3 880905 DSR: 1 0 0
DCD: 1 0 0 CTS: 6 5 803103 DSR: 1 0 0
DCD: 1 0 0 CTS: 6 3 885579 DSR: 1 0 0
DCD: 1 0 0 CTS: 6 3 881039 DSR: 1 0 0
DCD: 1 0 0 CTS: 7 5 808076 DSR: 1 0 0
DCD: 1 0 0 CTS: 7 3 884093 DSR: 1 0 0
DCD: 1 0 0 CTS: 7 3 882836 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 5 807985 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 3 883080 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 3 882115 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 3 884173 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 3 882561 DSR: 1 0 0
DCD: 1 0 0 CTS: 8 3 879534 DSR: 1 0 0
^Cradioclkd: Exiting...
lanserver:~#
But i don't know is this a good sign?
If everybody knows an other programm for testing Radioclocks on Linux?
MfG Marc-Andre
Richard B. Gilbert
Does the software include any documentation explaining what this output
means? It certainly does not seem to be in any way useful unless there
is some explanation of the output.
If there is none, I'd drop it in the garbage and use something else!
David Lord
You may want to try radioclkd2 which decodes DCF ok and uses
the SHM refclock driver. Radioclkd2 supports signals of either
polarity on DCD, CTS, DSR or RNG, also there is debug mode that
gives time between pulse edges. From pictures of connector I
can't see any connection to RxD which is used as input by
PARSE driver, nor does there appear to be a connection to DCD.
<http://www.buzzard.org.uk/jonathan/radioclock.html>
<http://www.jonatkins.com/page/software/radioclkd2>
David
David Lord
I can't remember if I tried radioclkd before using radioclkd2.
With radioclkd2 it needs 2 - 3 minutes before getting into
sync, there being status displayed at each minute. I'm not
sure if WWVB mode works but you may see failure to decode
that before it finds DCF.
David
Johan Swenker
> Es schrieb Rob van der Putten:
>
>> Maybe you can post a link to the receiver you're using.
>
> I can give you a Picture:
> http://666kb.com/i/bf7er4kfwd3feibip.jpg
This device looks very much like a DCF77 receiver I have.
The standard way to read these devices is with a baudrate of 50.
The DCF pulses of 100 and 200 msec give a distinct character
on the serial line.
There used to be a program dcfd.c in the xntpd sources (yes long ago)
that could handle such a dcf77 receiver.
For "just a clock", this works great. For an accurate clock (ntp)
this works lousy. Two problems:
1) how to get a time stamp at the moment the pulse arrives in the PC
2) jitter will be large (about 1 msec) as the uart samples the signal
with 16*baudrate.
Regards Johan
David Lord
......
> I can't remember if I tried radioclkd before using radioclkd2.
>
> With radioclkd2 it needs 2 - 3 minutes before getting into
> sync, there being status displayed at each minute. I'm not
> sure if WWVB mode works but you may see failure to decode
> that before it finds DCF.
These are results from April 2009 using Conrad module:
Parse driver used mode 16 but my notes indicate mode 5 can be
used if power isn't being taken from serial port although it
looks as if you don't have any signal on RxD anyway in which
case parse driver isn't suitable.
I'm around 1000km from Frankfurt.
DCF77 + serial tty00:
Driver(s)
(11) 8 me6000g(C3-600), NetBSD 5.0_RC4, Conrad DCF77 module
(12) 8 me6000g(C3-600), NetBSD 5.0.0_PPS, Conrad DCF77 module
"server 127.127.8.0 mode 133 # PARSE Conrad DCF77+PPS"
(13) 28 me6000g(C3-600), NetBSD 5.0.0_PPS, Conrad DCF77 module,
"radioclkd2 -s timepps tty00:-dcd"
Source Polls % offset jitter % offset jitter % offset jitter reach
(ms) (ms) (ms) (ms) (ms) (ms) !=377
(11) 110 50 1.746 0.921 95 5.113 bad 99.5 12.07 bad 7
(12) 160 50 1.911 0.854 95 9.162 5.186 99.5 87.49 466.4 12
(13) 152 50 0.825 0.433 95 3.789 2.648 99.5 7.095 6.047 14
David
Hal Murray
>means? It certainly does not seem to be in any way useful unless there
>is some explanation of the output.
>
>If there is none, I'd drop it in the garbage and use something else!
Or look at the source code.
--
These are my opinions, not necessarily my employer's. I hate spam.
Richard B. Gilbert
>> Does the software include any documentation explaining what this output
>> means? It certainly does not seem to be in any way useful unless there
>> is some explanation of the output.
>>
>> If there is none, I'd drop it in the garbage and use something else!
>
> Or look at the source code.
>
Over the years I've come to the conclusion that it's easier to rewrite
from scratch than to reverse engineer someone else's code. Especially
so when no effort is made to document what the code is doing, the
algorithms used, what the variables represent, etc. Far too many people
code in just this way!
Marc-Andre Alpers
> You may want to try radioclkd2 which decodes DCF ok and uses
> the SHM refclock driver.
Yes radioclkd2 does the job.
marc-andre@lanserver:~/radioclkd2-0.06$ sudo ./radioclkd2 -d ttyS0:-cts
version 0.06
Added clock unit 0 on line 'ttyS0:-cts'
pid 8421 for device /dev/ttyS0
Warning: failed to decode DCF77
DCF77 time: 2009-11-24 (day 4) 11:01 CET main ant
clock: radio time 1261648860.000000, pc time 1261648859.494195
DCF77 time: 2009-11-24 (day 4) 11:02 CET main ant
clock: radio time 1261648920.000000, pc time 1261648919.481707
Signal come on the cts line inverted.
I have try to compile ntp with SHM support on my Linux Box but i have a
error:
ntp_loopfilter.c: In function οΏ½local_clockοΏ½:
ntp_loopfilter.c:520: error: οΏ½MOD_NANOοΏ½ undeclared (first use in this function)
ntp_loopfilter.c:520: error: (Each undeclared identifier is reported only once
ntp_loopfilter.c:520: error: for each function it appears in.)
make[3]: *** [ntp_loopfilter.o] Error 1
make[3]: Leaving directory `/home/marc-andre/ntp-4.2.6/ntpd'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/marc-andre/ntp-4.2.6/ntpd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/marc-andre/ntp-4.2.6'
make: *** [all] Error 2
marc-andre@lanserver:~/ntp-4.2.6$
I use Ubuntu 9.10 32 Bit.
MfG Marc-Andre
Dave Hart
> ntp_loopfilter.c:520: error: ¡MOD_NANO¢ undeclared (first use in this function)
Please see http://bugs.ntp.org/1219
You will probably want to add
#define MOD_NANO ADJ_NANO
to either timex.h or ntp_loopfilter.c. If you then see another
undeclared MOD_*, add a similar #define to ADJ_*
Cheers,
Dave Hart
Marc-Andre Alpers
> You will probably want to add
>
> #define MOD_NANO ADJ_NANO
It works!
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 25 64 377 0.000 0.000 0.001
*SHM(0) .DCF. 0 l 25 64 377 0.000 62.868 4.102
Background of all. The PC go to a remote site with no internet connection.
The PC works as a CB Packet Radio AX25 Mailbox and NetRom Node. The local
clock has in a few days an offset within some minutes. With the DCF receiver
i have a good time source for this case.
Thank you.
Merry christmas and a happy new year!
Best regards Marc-Andre Alpers
Rob van der Putten
Marc-Andre Alpers wrote:
> I have no RS232 tester. The cover of the receiver is sealed. No screws.
> http://666kb.com/i/bf7g1grgo1sbus2c1.jpg
>
> The connector inside:
> http://666kb.com/i/bf7fxqd8cr17q7d8x.jpg
That's female on the left and male on the right?
> http://666kb.com/i/bf7g2xelg4xqppx3l.jpg
That's male on the left and female on the right?
> The transistor type is:
> MC78L
> 05ACP
> M535
That's a 78L05; A 100 mA +5 V stabilizer IC.
The circuit appears to be as follows;
M F
DCD 1 ----- 1
RXD 2 ----- 2
TXD 3 ----- 3
DTR 4 ----- 4
GND 5 --+-- 5
|
|
+----------+-----> Red GND
|
+-+-+
+--------+ S +---> Black +5V
F | M +---+
DSR 6 | 78L05
RTS 7 --+-- 7
CTS 8 --------------------> Orange
RI 9 --------------------> Brown
The circuit 'expects' NTPD to raise RTS and read from CTS or RI.
As far as I can tell NTPD does raize RTS but does not read from CTS or RI.
Marc-Andre Alpers
>> The connector inside:
>> http://666kb.com/i/bf7fxqd8cr17q7d8x.jpg
>
> That's female on the left and male on the right?
Yes.
>> http://666kb.com/i/bf7g2xelg4xqppx3l.jpg
>
> That's male on the left and female on the right?
Yes.
> The circuit 'expects' NTPD to raise RTS and read from CTS or RI.
> As far as I can tell NTPD does raize RTS but does not read from CTS or RI.
But why can other users this receiver use with ntp without problems?
MfG Marc-Andre Alpers
David Lord
I saw it as CTS on brown and RI on Orange
>
> The circuit 'expects' NTPD to raise RTS and read from CTS or RI.
> As far as I can tell NTPD does raize RTS but does not read from CTS or RI.
>
All refclocks docs I've checked, by no means all, expect serial
data on RxD.
Merry xmas to all
David
Marc-Andre Alpers
> All refclocks docs I've checked, by no means all, expect serial
> data on RxD.
Look at Message-ID: <hgvejq$gc9$1...@news.eternal-september.org>
Radioclkd2 read the data on cts signal line. Perhaps someone has rebuilt the
plug?
Merry xmas!
MfG Marc-Andre Alpers
Marc-Andre Alpers
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 12 64 377 0.000 0.000 0.001
*SHM(0) .DCF. 0 l 10 64 377 0.000 9.029 1.039
europium.canoni 193.79.237.14 2 u 18 64 377 44.718 -10.546 2.068
s1.uruz.org 82.96.64.2 2 u 26 64 377 40.036 -4.958 3.274
sun.raveisking. 248.28.159.255 2 u 30 64 377 32.395 27.763 3.149
simbx01.sixxs.n 8.44.164.161 3 u 22 64 377 53.903 -32.008 3.638
MfG Marc-Andre Alpers
Rob van der Putten
David Lord wrote:
> I saw it as CTS on brown and RI on Orange
Correct.
> All refclocks docs I've checked, by no means all, expect serial
> data on RxD.
Rewiring the plug might help;
Brown and Orange probably have opposite polarity;
+-+ +-+ + 12 V
| | | |
---+ +-------+ +--- - 12 V
---+ +-------+ +--- + 12 V
| | | |
+-+ +-+ - 12 V
> < 0.1 or 0.2 seconds
<--------> 1 or 2 seconds
So the thing to do is to connect the positive going pulse to RXD (2).
This will probably work with the following NTPD setting;
server 127.127.8.0 mode 5
fudge 127.127.8.0 time1 0.220 refid DCF77
After a few minutes 'ntpq -p' should yield something like;
remote refid st t when poll reach delay offset jitter
=====================================================================
+GENERIC(0) .DCF7. 0 l 61 64 377 0.000 0.151 0.002
Regards
David Lord
You might want to adjust the flag for refclockd2 or SHM
timings to allow for latency from the average rs232 timing
error and propogation delay.
It's very hit and miss from the servers you list above but
here I just chose to be about midway between my best
internet sources which are within 1ms or so on a good day.
Using a GPS is best but I've only a single serial port
usable (m/b has 1x backpanel + 3x headers but I don't want
to shutdown just to add the extra port connectors).
I've fudged the SHM with
"fudge 127.127.28.0 time1 0.024550 refid MSFa"
"ntpq -p" just now shows -1.834 and +1.180 for
two servers and -11.955 for another, with two local
peers as +0.167 and -0.208.
The local peers show their internet servers as:
(1) +0.098, -0.063, +0.148 and -79.556 :-)
(2) +0.053, +0.173, -0.592 and -8.639
There is a definite drift with both temperature change
and weather conditions but I don't have anything setup
to log temperature, never mind cloud cover, RH etc.
Yesterday the valley was clear with a few high clouds
but today it's 100% cloud cover down to ground level.
David
Marc-Andre Alpers
> I've fudged the SHM with
> "fudge 127.127.28.0 time1 0.024550 refid MSFa"
I'm about 400km away from DCF77. What a fudge should I use?
Actuell ntpq -p from over night running PC.
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 56 64 377 0.000 0.000 0.001
*SHM(0) .DCF. 0 l 19 64 377 0.000 0.390 0.264
europium.canoni 193.79.237.14 2 u 901 1024 377 52.403 -24.525 1.784
s1.uruz.org 82.96.64.2 2 u 886 1024 377 41.949 -7.581 1.797
sun.raveisking. 244.194.111.255 3 u 899 1024 377 32.239 16.241 13.018
simbx01.sixxs.n 5.60.127.116 2 u 913 1024 377 53.695 -66.847 19.488
MfG Marc-Andre Alpers
Rob
> Es schrieb David Lord:
>
>> I've fudged the SHM with
>> "fudge 127.127.28.0 time1 0.024550 refid MSFa"
>
> I'm about 400km away from DCF77. What a fudge should I use?
The fudge is determined by the way the clock interfaces to the computer
(via RXS introduces a large delay compared to a handshake line), the
delay in your receiver, and the delay of the radio signal. There is
no single formula to get it correct, I'm afraid.
> Actuell ntpq -p from over night running PC.
>
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> LOCAL(0) .LOCL. 10 l 56 64 377 0.000 0.000 0.001
> *SHM(0) .DCF. 0 l 19 64 377 0.000 0.390 0.264
> europium.canoni 193.79.237.14 2 u 901 1024 377 52.403 -24.525 1.784
> s1.uruz.org 82.96.64.2 2 u 886 1024 377 41.949 -7.581 1.797
> sun.raveisking. 244.194.111.255 3 u 899 1024 377 32.239 16.241 13.018
> simbx01.sixxs.n 5.60.127.116 2 u 913 1024 377 53.695 -66.847 19.488
>
> MfG Marc-Andre Alpers
Get a better set of time references on the network (that a referenced
off a GPS or similar clock) and that agree to eachother.
With this set, there is no way to tell where you are.
David Lord
Unfortunately those sources don't give you a meaningful
indication as all too far away from each other. As I said
before a GPS to serial port is easiest for calibration.
Propagation delay is short compared to other hardware
factors which aren't easy to estimate. Either bring a
reference in or take your kit to where there's a better
reference or accept what you have now (which looks more
likely to be consistent than your network sources).
David
Marc-Andre Alpers
> Get a better set of time references on the network (that a referenced
> off a GPS or similar clock) and that agree to eachother.
> With this set, there is no way to tell where you are.
And now?
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 6 64 377 0.000 0.000 0.001
*SHM(0) .DCFa. 0 l 54 64 377 0.000 1.898 0.478
ntp1.sda.t-onli .PPS. 1 u 22 128 377 32.013 32.997 2.745
ntp1.sul.t-onli .PPS. 1 u 7 128 377 37.546 32.421 5.332
metasweb01.admi .HBGi. 1 u 7 128 377 38.800 32.678 1.276
chronos.zedat.f .PPS. 1 u 20 128 377 39.441 30.029 1.489
ntp1.rrze.uni-e .DCFp. 1 u 10 128 377 35.681 33.177 3.585
It seems i have an offset of round about 31 ms. Right?
In remembrance, I do not need a hundred percent right time. Just as close as
possible with this setup. The computer will not work in a temperature
controlled environment.
MfG Marc-Andre Alpers
Rob
Yes this looks good.
Now you tweak the offset until your external sources are near zero offset.
It is always difficult to predict in which direction you have to move,
so just add 31 ms and if this worsens it, subtract 62.
Also, during this operation you will be affected by the bad startup
characteristics of ntpd. Tweaking the file and restarting ntpd a couple
of times can make it very unstable. Sometimes it steers away from
correct time, loses lock, jumps back, attempts again, steers away again,
etc.
This problem does not exist in the labs of the creators of the software,
so nothing is being done about it.
Be patient. After a while things will stabilize and you can make another
judgement about the accuracy of your offset.
Marc-Andre Alpers
> Be patient. After a while things will stabilize and you can make another
> judgement about the accuracy of your offset.
I think that's good enough for me. Time1 0.0315
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 59 64 377 0.000 0.000 0.001
*SHM(0) .DCFa. 0 l 30 64 377 0.000 -0.296 0.194
ntp1.sda.t-onli .PPS. 1 u 89 128 377 32.622 -0.116 2.408
ntp1.sul.t-onli .PPS. 1 u 78 128 377 38.116 -0.156 4.512
metasweb01.admi .HBGi. 1 u 80 128 377 39.068 0.323 0.559
chronos.zedat.f .PPS. 1 u 84 128 377 40.878 -2.532 20.878
ntp1.rrze.uni-e .DCFp. 1 u 76 128 377 36.008 0.583 0.930
MfG Marc-Andre Alpers
Hal Murray
>Over the years I've come to the conclusion that it's easier to rewrite
>from scratch than to reverse engineer someone else's code. Especially
>so when no effort is made to document what the code is doing, the
>algorithms used, what the variables represent, etc. Far too many people
>code in just this way!
Yes there is a lot of shitty code out there, but sometimes it's
the only documentation you can get. If nothing else, you may
want to scan it to extract some key ideas needed to write your
own version.
Personally, I don't want comments that tell me stuff I can
figure out by glancing at the code. What I want is clues
about the strange things like feature X doesn't work on OS Y,
or watch out for overflows.
Steve Kostecke
> Es schrieb Rob:
>
>> Be patient. After a while things will stabilize and you can make another
>> judgement about the accuracy of your offset.
>
> I think that's good enough for me. Time1 0.0315
>
> remote refid st t when poll reach delay offset jitter
>===================================================================
>*SHM(0) .DCFa. 0 l 30 64 377 0.000 -0.296 0.194
> ntp1.sda.t-onli .PPS. 1 u 89 128 377 32.622 -0.116 2.408
> ntp1.sul.t-onli .PPS. 1 u 78 128 377 38.116 -0.156 4.512
> metasweb01.admi .HBGi. 1 u 80 128 377 39.068 0.323 0.559
> chronos.zedat.f .PPS. 1 u 84 128 377 40.878 -2.532 20.878
> ntp1.rrze.uni-e .DCFp. 1 u 76 128 377 36.008 0.583 0.930
Please keep in mind that this data is only an snapshot.
Comparing peer offsets over a long period of time (e.g. at least a day)
will give you a better value for time1.
First enable statistics collection; specifically for the peerstats file.
Then, after you collect a suitable amount of data, use peer.awk from the
Distribution tarball scripts directory to process the data. The
summarized statistics will include mean, maximum, and rms offset for
each time source.
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
Rob
> On 2009-12-25, Marc-Andre Alpers <m-a.a...@web.de> wrote:
>> Es schrieb Rob:
>>
>>> Be patient. After a while things will stabilize and you can make another
>>> judgement about the accuracy of your offset.
>>
>> I think that's good enough for me. Time1 0.0315
>>
>> remote refid st t when poll reach delay offset jitter
>>===================================================================
>> LOCAL(0) .LOCL. 10 l 59 64 377 0.000 0.000 0.001
>>*SHM(0) .DCFa. 0 l 30 64 377 0.000 -0.296 0.194
>> ntp1.sda.t-onli .PPS. 1 u 89 128 377 32.622 -0.116 2.408
>> ntp1.sul.t-onli .PPS. 1 u 78 128 377 38.116 -0.156 4.512
>> metasweb01.admi .HBGi. 1 u 80 128 377 39.068 0.323 0.559
>> chronos.zedat.f .PPS. 1 u 84 128 377 40.878 -2.532 20.878
>> ntp1.rrze.uni-e .DCFp. 1 u 76 128 377 36.008 0.583 0.930
>
> Please keep in mind that this data is only an snapshot.
>
> Comparing peer offsets over a long period of time (e.g. at least a day)
> will give you a better value for time1.
I think he said "that's good enough for me".
Not everyone needs microsecond accuracy. Or even millisecond.
And if you do, it is not a good idea to use DCF77 anyway.
David Lord
I'm about 1000km away and propagation effects give me a
complete loss of signal twice a day on most days
depending on weather conditions etc so even ms accuracy
is difficult to maintain.
I'm pretty sure us accuracy is available at closer range
since it is possible to sync to exact cycle of carrier
with period of around 13us, ie to within a fraction of
that so 1us shouldn't be a problem.
The TDF transmission might be usable from here as a lot
closer and at higher frequency than DCF77 and provides
similar capability.
David
John Hasler
> I'm about 1000km away and propagation effects give me a complete loss
> of signal twice a day on most days depending on weather conditions etc
> so even ms accuracy is difficult to maintain.
What sort of antenna do you have? That's the most important component
of a VLF receiver.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Rob
> I'm pretty sure us accuracy is available at closer range
> since it is possible to sync to exact cycle of carrier
> with period of around 13us, ie to within a fraction of
> that so 1us shouldn't be a problem.
The problem is not in the accuracy of the transmitter or your
capability to receive it, but in the path between transmitter
and receiver.
I have both DCF77 and GPS receivers connected and there is a very
clearly visible change in the relative offsets between those
over a day/night cycle. This is of ms order of magnitude.
David Lord
> David Lord writes:
>> I'm about 1000km away and propagation effects give me a complete loss
>> of signal twice a day on most days depending on weather conditions etc
>> so even ms accuracy is difficult to maintain.
>
> What sort of antenna do you have? That's the most important component
> of a VLF receiver.
ferrite rod
I assume to get the phase info you need to pll to the signal,
demodulate the phase encoding and align your own encoded pll
to that either by some analogue method I can't work out, or
use a digital pll with correction. An analogue pll match might
work ok but I don't know the maths.
I doubt it would be worth any effort at my 1000km due to
variation in propagation delay but if within close range you
are locked to the transmitted signal and just correct for the
delay.
David
John Hasler
> I have both DCF77 and GPS receivers connected and there is a very
> clearly visible change in the relative offsets between those over a
> day/night cycle. This is of ms order of magnitude.
You might be able to improve that by orienting your antenna to better
reject skywave.
David Lord
Are you on a pps signal from DCF77 as well as GPS?
With DCF, I see complete loss of signal, I assume due to skywave
cancellation of groundwave, for a couple of periods most days, and
order of ms shift during period at night when signal comes back.
I did state "closer range" but I don't track propagation delays vs
frequency so don't know at what distance it becomes unreliable.
There must also be means to compensate to some degree for the
longer range as the disturbances are periodic.
MSF at 160km with PPS seems to be +/-165us and that's without
any attempt to lock to the carrier but there is no equivalent
to lock to a particular cycle as with DCF77 or TDF.
David