Hello Wolf,
The problem is, PC clocks (though called 'Real Time Clocks') can be quite
bad, much worse than the cheapest wristwatch you can buy in a coffee-store.
So setting the clock for an accuracy of 0.1 sec or better only lasts for a
few MINUTES (!) on some nasty PCs (like the one I have to use sometimes).
When I was thinking of implementing 'time synchronisation' in QRS I did
some tests with 5 different PC's : I set the clock to DCF77, let them run
for 16 hours and checked the difference between the PC clock and DCF77.
The differences turned out to be between +10 and -8 seconds, so a 'drift'
of about 0.6 seconds/hour.
Taking into account that 5% error in the 'time synchronisation' equals a
0.2dB loss (seems acceptable to me) would mean that for 30 sec./dot a 1.5
second timing error is acceptable. Taking worst case (PC clocks drifting in
different directions) this would mean that the time for a QSO is about 70
minutes.
If there is some real interest in this 'time synchronized' stuff I will
have a closer look a the drift of the PC clock, if it tends to be a (more
or less) linear drift it could even be compensated in QRS.
What really helps would be a GPS (costly, only works if satellites visible)
or a cheap DCF receiver connected to the serial port (if not already
occupied
by mouse, modem, PIC, TRX control, DSP board etc etc).
You have to readjust the clock continously, if you want 'reliable' second
markers for recording intervals of an hour or so. A possible workaround
would
be using the soundcards "calibrated" sample rate as a timebase.
Using the soundcard may be more 'user friendly' that using a GPS. A good idea.
73, Rik ON7YD
|
