Content-Transfer-Encoding: 8bit
Message-ID: <3.0.1.16.19991115162050.2eefc5da@mail.cc.kuleuven.ac.be>
Date: Mon, 15 Nov 1999 16:20:50
To: rsgb_lf_group@blacksheep.org
From: "Rik Strobbe" <rik.strobbe@fys.kuleuven.ac.be>
Subject: Re: LF: new visual-CW techniques
In-reply-to: <E11nLyg-0000y5-00@mserv1a.u-net.net>
References: <3.0.1.16.19991115132605.22071bd8@mail.cc.kuleuven.ac.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

At 12:57 15/11/99 -0000, Mike, G3XDV wrote:
>Rik, ON7YD wrote:
>
>> Thanks to all who responded to my previous mail, it seems that others had
>> similar ideas to increase the transmission speed for visual-CW.
>> 
>> For those who also appreciate the 'therapeutic' value of visual-CW and are
>> not interested in speeding up things there is the possibility to increase
>> the 'dot-length' by a certain factor (+/- 3). This will ensure that the
>> duration of the QSO will not be too short and has the advantage that you
>> can make the QSO with less power or cover a bigger distance with the same
>> power.
>
>Yes, that's a good point. The length of the dot is the limitting factor in 
>signal to noise calculations. I often can copy dashes much more 
>easily than dots, partly because the averaging can be done over a 
>longer period, and partly because dashes are less easily destroyed 
>by impulse noise such as QRN (and there's lots of that at LF).
>
>Mike, G3XDV (IO91VT)
>http://www.dennison.demon.co.uk/activity.htm
>

To take full advantage of a certain dotlength it is important that
transmitter and receiver are synchronized.
An example : if you have a 5.5kHz sample rate (soundcard) and you calculate
your FFT over 16384 points that you will produce one FFT each 3 seconds
(2.979 seconds to be exact). Assume that the TX transmits a series of dots
(at 3 sec. dotlength) and the RX is exactly synchronized (so each FFT takes
either a 3 sec. period with 'key down' or 'key up') then you will have the
optimal result. But if the RX has a 1.5 sec. 'delay' on the TX then all
FFT's will have 8192 points with 'key up' and 8192 points with 'key down'
and you will see nothing but a continious line on the screen, all 'data' is
gone.
So in case TX and RX are not synchronized (as it is now on 136kHz) your FFT
period at the RX side needs to be remarkable shorter than the dot length at
the TX side.
Some FFT software will use a 'trick' and instead of taking a complete new
sample-set for each FFT it will shift a part of the old samples and take
only a part new samples (eg. if you it performs a 16384 point FFT it will
remove point 1 - 4096, replace the points 4097 - 16384 to positions 1 -
12288 and place 4096 new points in position 12289 to 16384), but that takes
much more calculation power (quadruple in the case described here) and only
partly solve the problem.

So for optimal use of FFT software the TX-keying and RX-FFT should be
synchronized. With modern techniques (DCF77 etc.) and within Europe it
should be rather easy to obtain a synchronisation od 0.1 sec. and maintain
this during at least 30 minutes. With a 3 sec. dot lengths should be good
enough to take advantage of synchronized FTT.

73, Rik  ON7YD