Envelope-to: dave@picks.force9.co.uk
Delivery-date: Sun, 24 Apr 2005 22:58:08 +0100
Message-ID: <00aa01c54910$32b5b240$0500a8c0@charter.net>
From: "John Andrews" <w1tag@w1tag.com>
To: rsgb_lf_group@blacksheep.org
References: <7b.43e60105.2f9d530b@aol.com> <001b01c54910$923cf520$a8048751@w4o8m9>
Date: Sun, 24 Apr 2005 21:57:15 +0100
MIME-Version: 1.0
Subject: Re: LF: Wolf qso
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Markus, et al,

Jim's comments are absolutely true, but there is one more grain of
information needed for transmitting! You must establish a separate sampling
rate on the transmit side. A starting point will be the mirror image of the
receive rate: if the receive is 8001 Hz, try 7999 for transmitting. The
relation in my sound card is not exact, so I advise doing some
experimentation. This is tricky if you are keying the transmitter phase
directly with the "old" WOLF. The sound card approach should be a little
simpler, as you can go by the frequency of your locally-monitored signal,
assuming that you are keying the transmitter from another computer, or one
with full duplex capability.

When properly set up, a locally-monitored signal should show steady "jm"
values, indicating no slips in framing, steadily increasing "pm" values, and
increasing "q" values. If the "pm" readings jump in steps of 4096, back off
the audio feed, as the detector is being overloaded.

John Andrews