Return-Path: <majordom@post.thorcom.com>
Received: (qmail 11045 invoked from network); 21 Mar 2001 08:43:38 -0000
Received: from unknown (HELO warrior-inbound.servers.plus.net) (212.159.14.227)  by 10.226.25.101 with SMTP; 21 Mar 2001 08:43:38 -0000
Received: (qmail 4052 invoked from network); 21 Mar 2001 08:43:39 -0000
Content-Transfer-Encoding: 8bit
Received: from unknown (HELO post.thorcom.com) (212.172.148.70)  by warrior with SMTP; 21 Mar 2001 08:43:39 -0000
Received: from majordom by post.thorcom.com with local (Exim 3.16 #2) id 14fe6G-0000ua-00 for rsgb_lf_group-outgoing@blacksheep.org; Wed, 21 Mar 2001 08:36:12 +0000
X-Priority: 3
X-MSMail-Priority: Normal
Received: from mail.cc.kuleuven.ac.be ([134.58.10.6]) by post.thorcom.com with esmtp (Exim 3.16 #2) id 14fe6F-0000uV-00 for rsgb_lf_group@blacksheep.org; Wed, 21 Mar 2001 08:36:12 +0000
Received: from LCBD15.fys.kuleuven.ac.be (LCBD15.fys.kuleuven.ac.be [134.58.80.15]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id JAA142930 for <rsgb_lf_group@blacksheep.org>; Wed, 21 Mar 2001 09:35:48 +0100
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <3.0.1.16.20010321093521.2dbffa84@mail.cc.kuleuven.ac.be>
X-Sender: pb623250@mail.cc.kuleuven.ac.be
X-Mailer: Windows Eudora Pro Version 3.0.1 (16)
Date: Wed, 21 Mar 2001 09:35:21
To: rsgb_lf_group@blacksheep.org
From: "Rik Strobbe" <rik.strobbe@fys.kuleuven.ac.be>
Subject: Re: LF: DFCW
In-reply-to: <72.8cd73c8.27e8f609@aol.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-Listname: rsgb_lf_group
Sender: <majordom@post.thorcom.com>

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