Reinhold,

Are you using a DCF receiver with raw timecode output (one impulse per
second)
or a receiver with nicely formatted ASCII output messages?

For 'clocks' with raw timecode output, NTP sets the baud rate of the
serial port to
50. That's the way it works.

For clocks with ASCII output, NTP typically sets the baud rate of the
serial port to match
the default speed of the clock's serial output.

Can you tell us the brand and type of clock that you are using?

Paul

Hello Paul,

I'm using a modified Meinberg AW-02 receiver that outputs a raw
timecode with TTL-level.
NTP try to set a baud rate of 50 but my hardware does not support this

Reinhold

Hallo Reinhold,

At a baud rate of 50, one character (start bit, 8 data bits, stop bit)
at the serial
interface has a duration of 0.2 sec.

The 'pips' that DCF77 transmits have a duration of either 0.1sec or
0.2sec, and
therefore appear as characters either with all bits set or with the
first four data bits set.

If you try to set to serial interface to a baud rate other than 50, you
would have to do
significant re-engineering of the bit decoding algorithms. You might
want to look at
parseutil/dcfd.c, lines 512ff, for more information about how it's
done.

Grüße,
Paul

Hello Reinhold,

Reinhold wrote:
> Hello Paul,
>
> I'm using a modified Meinberg AW-02 receiver that outputs a raw
> timecode with TTL-level.
> NTP try to set a baud rate of 50 but my hardware does not support this

If I remember correctly we have already discussed this on the phone, and you
are using a RS-232-to-USB converter.

While this may work with a device which transmits an ASCII string (in spite
of the jitter introduced by the USB bus) I doubt NTP's RAW_DCF driver would
at all be able to decode the raw DCF77 time marks properly after they have
been transferred via USB.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hello Martin,

> If I remember correctly we have already discussed this on the phone, and you
> are using a RS-232-to-USB converter.

yes, we do

> While this may work with a device which transmits an ASCII string (in spite
> of the jitter introduced by the USB bus) I doubt NTP's RAW_DCF driver would
> at all be able to decode the raw DCF77 time marks properly after they have
> been transferred via USB.

I have to try this because we want to discuss all possibilities. The
jitter is no problem for our needs, if NTP accept this source

Reinhold

Just a suggestion as I don't have your device.
If you can dispense with the rs-232-> usb , then why not try
connecting to DCD and using the SHM driver in conjunction
with Jonathan Buzzards DCF radioclock daemon.
http://www.buzzard.me.uk/jonathan/radioclock.html
There is no needfor any particular baud rate to be set
as there is no host -> refclock comms. You would probably
need to check the polarity of the signal as it uses assert
to start the timing of interrupts and signal pulse length
on the DCD pin.

regards,
Mike

Reinhold wrote:
> Hello Martin,
>
>
>>If I remember correctly we have already discussed this on the phone, and you
>>are using a RS-232-to-USB converter.
>
>
> yes, we do
>
>
>>While this may work with a device which transmits an ASCII string (in spite
>>of the jitter introduced by the USB bus) I doubt NTP's RAW_DCF driver would
>>at all be able to decode the raw DCF77 time marks properly after they have
>>been transferred via USB.
>
>
> I have to try this because we want to discuss all possibilities. The
> jitter is no problem for our needs, if NTP accept this source
>
> Reinhold
>

Hello Mike,

> If you can dispense with the rs-232-> usb , then why not try
> connecting to DCD and using the SHM driver in conjunction
> with Jonathan Buzzards DCF radioclock daemon.
> http://www.buzzard.me.uk/jonathan/radioclock.html

thank you very much. Works great

> There is no needfor any particular baud rate to be set
> as there is no host -> refclock comms. You would probably
> need to check the polarity of the signal as it uses assert
> to start the timing of interrupts and signal pulse length
> on the DCD pin.

I've modified radioclock to invert DCD for a first test. Now our
hardware group have to do this right...

Thanks, Reinhold