[ntp:questions] Re: radioclk DCF doubling

Jonathan Buzzard jonathan at uk.me.buzzard
Sun Jul 10 09:59:54 UTC 2005


On Sat, 09 Jul 2005 12:04:23 +0200, Serge Bets wrote:

> Hello David,
> 
>  On Wednesday, July 6, 2005 at 7:32:47 AM +0100, David Woolley wrote:
> 
>     [fudge time1 0.020]
>> Serge Bets <serge.bets at NOSPAM.laposte.invalid> wrote:
>>> The LW propagation delay at 430 km given by propdelay is between
>>> 2.219 and 2.762 ms. I wonder what are the 17.xxx remaining ms...
>> Receiver filter group delay, or more simply described, half the filter
>> rise time, in this case.

There is also the response of the serial port to consider. This is the
delay between the receiver detecting the pulse edge, and this resulting
in the RS232 port raising an interrupt.

On top of that there is the delay between the interrupt being raised and
the radioclkd software getting around to taking a timing.

> Thanks for your reply. I'm not sure to have enough background knowledge
> to understand it fully. You mean the filter removing 77.5 kHz carrier to
> keep 1 Hz pulses needs 17 ms to recognise the lower amplitude during the
> pulse? Does it need the same time to recognise the end of the pulse,
> when carrier comes back to full power?

The filter should be symmetric as far as I am aware, but the serial port
is *not* symmetric . Depending on your serial port it will be going from
ground to something close to 10V, but the switch point between a zero and
one is around 1.5V. Hence the leading edge of the pulse is detected
quicker than the trailing edge.

> There is something strange: These pulses that should be in theory 100 ms
> (or 200 ms), when seen by "radioclk -t" are always shorter, around
> 92.9 ms (or 190 ms). What could explain that?

See above, it is as far as I am aware due to the serial port
characteristics. In the end I considered it basically unimportant,
as it is pretty much constant. For meaningful statistics in addition to 
the min/max/mean you need to know what the standard deviation of the
pulse lengths is.

I also thing that it is important not to loose sight of the design goals
of the project. That is the idea is to make a cheap, *SIMPLE TO
CONSTRUCT*, reliable device that provides performance that at least
matches other radio clocks. In my opinion all design goals have been
met, and performance of the device outstrips almost all other radioclocks.

There is some room for improvement, you could use kernel based PPS timing
of the pulse edges for starters. This would reduce the delay and jitter
of the time. Though if you are running with a preemptable Linux kernel, I
suspect that you will not see much improvement.

You could use some statistical filtering of the pulse times to improve
immunity to noise. Once we know what signal we are receiving and what the
time currently is, then we have a good a prior knowledge of what the
signal should be, and a simple application of Bayesian statistics would
yield a substantial improvement in performance with a poor signal. I have
done some basic testing with data sets to confirm this, but have never
gotten round to implementing it in radioclkd. Historically I have had
good MSF and DCF77 signals so that this would not be worth while. However
now I have a HBG receiver which even after an antenna upgrade is still
marginal it would be worth while. Though no promises.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195




More information about the questions mailing list