Envelope-to: dave@picks.force9.co.uk Delivery-date: Sun, 24 Apr 2005 20:53:42 +0100 Received: from pih-spamcore04.plus.net ([192.168.71.8]) by pih-mxcore06.plus.net with esmtp (PlusNet MXCore v1.0) id 1DPnAk-0006f3-4g for dave@picks.force9.co.uk; Sun, 24 Apr 2005 20:53:42 +0100 Received: from Debian-exim by pih-spamcore04.plus.net with spam-scanned (Exim 4.50) id 1DPnAA-0005Oa-Pm for dave@picks.force9.co.uk; Sun, 24 Apr 2005 20:53:41 +0100 Received: from [192.168.101.74] (helo=pih-mxcore08.plus.net) by pih-spamcore04.plus.net with esmtp (Exim 4.50) id 1DPnAA-0005OR-I8 for dave@picks.force9.co.uk; Sun, 24 Apr 2005 20:53:06 +0100 Received: from post.thorcom.com ([193.82.116.20]) by pih-mxcore08.plus.net with esmtp (PlusNet MXCore v1.0) id 1DPnAA-0000E6-D2 for dave@picks.force9.co.uk; Sun, 24 Apr 2005 20:53:06 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1DPn9x-0005nW-B5 for rs_out_1@blacksheep.org; Sun, 24 Apr 2005 20:52:53 +0100 Received: from [193.82.116.30] (helo=relay.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1DPn9w-0005nN-Lj for rsgb_lf_group@blacksheep.org; Sun, 24 Apr 2005 20:52:52 +0100 Received: from imo-m15.mx.aol.com ([64.12.138.205]) by relay.thorcom.net with esmtp (Exim 4.43) id 1DPn9w-0008BS-4C for rsgb_lf_group@blacksheep.org; Sun, 24 Apr 2005 20:52:52 +0100 Received: from MarkusVester@aol.com by imo-m15.mx.aol.com (mail_out_v38.7.) id l.7b.43e60105 (18555) for ; Sun, 24 Apr 2005 15:52:44 -0400 (EDT) From: MarkusVester@aol.com Message-ID: <7b.43e60105.2f9d530b@aol.com> Date: Sun, 24 Apr 2005 15:52:43 EDT To: rsgb_lf_group@blacksheep.org MIME-Version: 1.0 X-Mailer: 8.0 for Windows sub 6104 X-SPF-Result: relay.thorcom.net: domain of aol.com designates 64.12.138.205 as permitted sender Subject: Re: LF: Wolf qso Content-Type: text/html; charset=windows-1252 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Filtered: by PlusNet SpamCORE (v4.00s) Content-transfer-encoding: 8bit Dear Wolfgang, Hartmut, Uwe and Dave,

there was quite bit of activity on the wolve's QRG 137441 this afternoon. After DL4YHF at DF0WD saw my low power test transmission, he replied, and we finally got engaged in our second WOLF QSO, four years after the first successful QSO on April 16th, 2001. Even though signals were excellent and audible, we had some difficulties decoding each other right away. Typically, WOLF-RX locked on the right frequency within 24 seconds, but the the first lines of output were garbage, and the true message was displayed only after about two minutes. In 2001 we had some difficulties to achieve bitclock synchronization, until we found out that the ADC and DAC samplerates at 8000 Hz nominal were actually different on the notebook PCs used at the time. So we suspected to be victims of a similar problem again.

Later I could see G3YXM calling, a good signal visible on the spectrogram display. Again I could read Dave every time after 96 seconds delay, but he said he had severe problems to copy me. Only after I extended the duration of my transmissions to about 4 minutes, we could finally complete a short QSO.

This made me suspect that my local oscillator reference, a homebrew temperature-stabilized crystal near 21.4 MHz, might have some frequency drift after keying the TX on and off. I checked it by feeding an external signal on the image frequency (42.923 MHz) into the second RX channel, which could be tracked on Argo during a test transmission. The result showed an exponentially decaying post-keying transient of 0.037 ppm (i.e. 5 mHz at 137 kHz), coupled into the temperature controller by a small supply voltage change, and lasting for about 100 seconds. This would result in an absolute phase shift of nearly 180deg during the first part of both the TX and RX intervals, which could possibly explain the decoding problems. Sorry if it was that which caused the difficulties for my partners - I will try to fix it by feeding an external reference signal to my circuit before transmitting WOLF again.

Unrelated to this, I also observed the effect mentioned by Dave, that a strong message is "held" by the decoder for a long time, effectively blocking the aquisition of a subsequent weaker message. I'm not sure wheather this is a bug or actually a feature of the averaging techniques in use. Is this what is meant to be controlled by the -L option? A practical workaround of course is to simply restart the receiver by pressing F11 and F9.

Thanks again to all players in this enjoyable game.

73 and all the best

Markus, DF6NM