Return-Path: 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 ; 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" 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: 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