Message-ID: <001f01c3f1c8$81b3bfe0$1e478751@rogersservices>
From: "James Moritz" <james.moritz@btopenworld.com>
To: rsgb_lf_group@blacksheep.org
References: <20040210184134.KTHX20454.tomts35-srv.bellnexxia.net@smtp.bellnexxia.net> <402A6646.4030006@virgin.net> <1ArPAc-19FrkH0@fwd00.sul.t-online.com>
Date: Fri, 13 Feb 2004 00:29:55 -0000
MIME-Version: 1.0
Subject: Re: LF: Timing GPS
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: <owner-rsgb_lf_group@blacksheep.org>
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Dear Uwe, LF Group,

I don't think that the bit timing is really a great problem for the low
bit-rate modes we are using on LF. I guess that a timing error of 10% of the
bit period would result in about 1dB degradation of the recovered signal,
which would be relatively small compared to other variations. To stay within
10% of the bit period when using a 10 bit-per-second mode, this would
require the clocks at each of the stations to be maintained within 10ms of
each other.

Assume that the clock, either by adjusting the actual reference frequency,
or by calibration in software, can maintain 1ppm precision for periods of a
few hours - looking at the narrow-band spectrograms people routinely obtain,
this can be done even with ordinary crystal oscillators, provided the
temperature does not change too quickly. The time taken for such a clock to
drift by 10ms would be 10000 seconds, or nearly 3 hours. So you would only
have to check your clock against DCF77 or MSF once every couple of hours at
10 bits/s - at 0.1 bits/sec, once a week would be OK if similar accuracy
could be maintained over the longer period.

So it should be possible to transmit for quite long periods, and
re-calibrate the clock against a standard time broadcast in the receive
periods, even when using quite basic clock sources, and so avoid the problem
of blocking in the time receiver front end caused by the local transmission.
I think the more tricky part would be to get the initial calibration of the
clock to within a few ms, but no doubt this can be done by taking into
account the path delay to the standard time transmitter, and the delay
through the receiver. Again, reducing the bit rate to 10 bit/s would make
things easier - it is easy to synchronise 2 clocks to within 1 second.

BTW, I have a little MSF-synchronised clock in the shack - this seems to
work OK, even when I am transmitting beacon signals...

Cheers, Jim Moritz
73 de M0BMU

----- Original Message -----
From: jannsen <0482183881-0001@t-online.de>
To: <rsgb_lf_group@blacksheep.org>
Sent: Thursday, February 12, 2004 10:18 PM
Subject: Re: LF: Timing GPS
>
> there is a problem in synchronizing the PC clock by DCF77 (as with other
> standard time signal transmitters): During lf transmittings of your own
> station there will be no clocking because the DCF77 receiver will be
> overloaded (what is it in english "zugestopft"?).