Hello!

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

Hi there


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

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

MfG marc-Andre Alpers

Hi there


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?


Regards,
Rob
-- 
Nowadays people know the price of everything, and the value of nothing
Oscar Wilde

Es schrieb Rob van der Putten:

> 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

Ok. I have open the cover:

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

Here some pictures from the dcf77 decoder on Win 2000 with the clock:

Befor sync:
http://666kb.com/i/bf7hgd6exsvtpuf2p.bmp

After sync:
http://666kb.com/i/bf7hia21x28co76j5.bmp

MfG Marc-Andre Alpers

On 12/23/2009 8:50 AM, Marc-Andre Alpers wrote:
> 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 <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

Es schrieb :

> 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

On Dec 23, 20:52=A0UTC, Marc-Andre Alpers <m-a.alp...@web.de> wrote:
> > Looks like a SURE RPC modul DCF 77 Funkuhr ?
> > <http://www.linum.com/de/produkte/hardware/funkuhr/dcf77/sure/seriell/.=
...>
>
> 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

"Dave Hart" <davehart@gmail.com> wrote:

>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 

"Dave Hart" <davehart@gmail.com> wrote:

>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

Es schrieb Dave Hart:

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

Marc-Andre Alpers wrote:
> Es schrieb Dave Hart:
> 
> 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

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!

Marc-Andre Alpers wrote:
> "Dave Hart" <davehart@gmail.com> wrote:
> 
>> 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.

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

Marc-Andre Alpers wrote:
> Es schrieb Dave Hart:
> 
> 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

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

On Wed, 23 Dec 2009 17:50:23 +0100, Marc-Andre Alpers wrote:

> 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 wrote:

.......


> 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

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

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
>> 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!

Es schrieb David Lord:

> 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

On Dec 24, 10:08=A0UTC, Marc-Andre Alpers wrote:
> ntp_loopfilter.c:520: error: =A1MOD_NANO=A2 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

Es schrieb Dave Hart:

> 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

Hi there

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.


Regards,
Rob
-- 
Nowadays people know the price of everything, and the value of nothing
Oscar Wilde

Es schrieb Rob van der Putten:

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

Rob van der Putten wrote:
> Hi there
> 
> 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

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

Es schrieb David Lord:

> 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

I looks very good.

     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

Hi there


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
Rob
-- 
Nowadays people know the price of everything, and the value of nothing
Oscar Wilde

Marc-Andre Alpers wrote:
> I looks very good.
> 
>      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

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

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?

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

Marc-Andre Alpers <m-a.alpers@web.de> wrote:
> 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.

Marc-Andre Alpers wrote:
> 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?
> 
> 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
> 

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

Es schrieb Rob:

> 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

Marc-Andre Alpers <m-a.alpers@web.de> wrote:
> Es schrieb Rob:
>
>> 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

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.

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

MfG Marc-Andre Alpers

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

-- 
These are my opinions, not necessarily my employer's.  I hate spam.