Andreas Mattheiss <please.post@publicly.invalid> wrote:
> Hi,
>
> Am Fri, 30 Jan 2015 21:01:43 +0000 schrieb Rob:
>
>>
>> Note than an RS232 port usually works fine with just the 0 and +3..5v
>> levels so you can directly connect the output to the RS232 line without
>> MAX232.
>>
>
> Nice try, but in my case it didn't work, the voltage was a bit too anemic,
> both from the DCF module and the DCF alarm clock.
>
> Actually - I've got it working now! I realized that the MAX232 has two
> CMOS-to-RS-232 channels, both inverting - I just connected the output of
> the first channel to the input of the second one, so that the signal just
> gets inverted. I threw a two-resistor voltage divider in between,
> since the RS-232 level would be a bit too high for the CMOS input. I now
Note that the CMOS input also doesn't like negative voltages.
It is a good idea to put a diode in the circuit as well, to clamp the
negative voltage.
> get the right polarity, and after throwing a (surprisingly high) time1
> fudge of 0.21 in I get a nice sync:
This is normal. The second is defined by the leading edge of the pulse,
and the interrupt from the UART comes in after the entire "character" has
been received at 50 baud, which takes 10 bits or 10/50 second.
The receiver circuit may introduce some delay as well.
In my system the fudge is 0.222
> highscreen [19:57] [~] <# 8> ntpq -pn
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> 127.127.1.0 .LOCL. 5 l 1148 64 0 0.000 0.000 0.000
> -178.209.53.202 196.80.165.212 3 u 98 128 377 69.804 -0.024 113.184
> -157.161.57.2 212.51.144.44 2 u 97 128 377 67.917 11.403 30.932
> *82.197.188.130 162.23.41.10 2 u 94 128 377 68.959 1.265 2.198
> -130.60.204.10 130.60.205.7 4 u 101 128 377 50.795 7.875 2.321
> -127.127.8.0 .DCFa. 0 l 55 64 377 0.000 -3.433 498.390
> -217.147.223.78 194.242.34.149 2 u 4 128 377 113.500 -20.066 3.497
> +5.148.175.134 131.188.3.222 2 u 1 128 377 69.642 -0.008 0.728
> +94.23.99.154 94.23.99.153 3 u 96 128 377 60.134 11.205 2.849
> -94.23.99.155 94.23.99.153 3 u 97 128 377 59.191 12.619 1.441
>
> All other references are from the ntp pools.
>
> Only remaining thing that bugs me is that the testdcf tool still won't
> give me a correct time code:
>
> highscreen [19:58] [/nonraid/build/ntp-4.2.8/parseutil] <# 19> testdcf
> /dev/refclock-0
> DCF77 monitor 4.10 - Copyright (C) 1993-2005, Frank Kardel
>
> RADMLSMin....PHour..PMDay..DayMonthYear....P
> RADMLS1248124P124812P1248121241248112481248P
> - #############################............... *** INCOMPLETE
> / ############################################ *** BAD FORMAT (invalid/parity)
>
>
> Maybe a matter of bitrot?
It looks like you still have some missing pulses, probably due to local
interference. This is a problem here as well, as you saw from my logfile
posting. You also need to tweak the fudge a bit more so the DCF time is
within a millisecond and is considered a candidate. Of course then you
first need to find some really accurate references to tune it to.
When doing that, please make sure you don't restart the ntp server more
than once or twice a day, and let it stabilize. Otherwise you will end
up hunting pending corrections and the time offsets will drift in all
directions.
I have a DCF-77 receiver and two different GPS receivers, that both output
serial messages and PPS pulses. The result:
remote refid st t when poll reach delay offset jitter
==============================================================================
+GENERIC(0) .DCFa. 0 l 54 64 377 0.000 -0.042 0.276
oPPS(0) .PPS. 0 l 6 16 377 0.000 -0.001 0.002
xSHM(0) .GPS. 0 l 5 16 377 0.000 9.342 0.212
*SHM(1) .PPS. 0 l 4 16 377 0.000 0.003 0.001
xSHM(2) .DATM. 0 l 3 16 377 0.000 -2.483 1.646
(I also have a couple of network NTP sources that are not relevant to this
topic)
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
