From: "Mike Dennison" <mike.dennison@ntlworld.com>
To: rsgb_lf_group@blacksheep.org
Date: Tue, 12 Apr 2005 15:08:32 +0100
MIME-Version: 1.0
Message-ID: <425BE470.11467.1CE4090@localhost>
In-reply-to: <5.1.0.14.0.20050412154826.02288930@u0019445.kuleuven.be>
References: <425BCF3E.11650.17B7688@localhost>
Content-description: Mail message body
Subject: LF: Pseudo-synch QRSS
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

> "TX/RX synchronisation" would reduce the time occupied by FFT by 100
> or more (from several FFT/sec to 1 FFT/min). The "calculation power"
> that becomes available could be used to improve SNR. But How ? Here we
> need some smart guys. I think you are even a bit pessimistic about the
> synchronisation error. It can be reduced to 1/10 of a second or even
> better, if the PC clock is locked to a GPS source, DCF or similar.
> 73, Rik ON7YD

Rik,

My point is that there has been a lot of discussion about locking to 
GPS, or Loran, or some other standard, and it has failed to attract 
any practical interest because it is more complex than most amateurs 
would like.

An improvement could be made by simply making sure that the computers 
at both ends are within a few seconds of each other (for QRSS 60 or 
120), and ensuring that the FFT software knows roughly when the dot 
period starts. As I understand it (and I know very little about FFT), 
this would allow integration over a longer period and remove the need 
for the sliding window that takes care of the randomly timed signals 
(ie we could have nice square edges to the Morse). 

Your 'QRS' software can already deal with transmission times locked 
to the computer.

Perhaps there is someone out there who can comment on the receive 
side,

Mike, G3XDV
http://lf.apersonalguide.co.uk
======================