Message-Id: <3.0.6.32.20041127170259.00c35f18@magma.ca>
Date: Sat, 27 Nov 2004 17:02:59 -0500
To: rsgb_lf_group@blacksheep.org
From: Bill de Carle <ve2iq@magma.ca>
In-Reply-To: <41A8C202.2090100@usa.net>
References: <3.0.6.32.20041127113429.00c39b50@magma.ca>
 <000b01c4d3fc$f0716880$6507a8c0@Main>
 <000b01c4d3fc$f0716880$6507a8c0@Main>
 <3.0.6.32.20041127113429.00c39b50@magma.ca>
Mime-Version: 1.0
Subject: Re: LF: Re: MSK etc and stability
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Content-transfer-encoding: 8bit

At 07:05 PM 11/27/2004 +0100, Alberto wrote:
>Bill de Carle wrote:
>
>>This is basically how the "PSKL" mode in COHERENT/AFRICA  was done.
>>  
>>
>Hmmm Bill,
>  this mean I cannot patent it, being yours a "prior art" ?  :-)
>Seriously talking, bad performance under weak signal conditions apart, 
>did you see in your tests
>that tolerance of a few Hz in tuning ?  TNX.

Well, I did it a little differently, so maybe on a technicality
you could patent it :-)

I only feed one channel of audio into the computer (let's call it the
real component).  Then I multiply it with a phasor rotating at, nominally,
800 Hz, which gives me the IP, Q components.  If my locally generated
carrier is at precisely the same frequency as the incoming BPSK audio
carrier, the beat note is essentially DC, and the I,Q components
should not change over the course of the bit time.  That means I can
integrate them over the entire bit time which reduces the bandwidth
accordingly.  Now, assume there is a slight difference between my
locally generated 800 Hz and the incoming BPSK's frequency.  There
will now be a slowly varying beat note in the I/Q values (always,
of course, less than the 1/Tb bandwidth of the effective lowpass
filter implemented by adding up what were assumed to have been DC
components).

At the end of each bit time I compute the phase angle (averaged
over the bit time) by taking arctan(y/x) - and from one bit time
to the next ("averaged" with the regression line I previously
mentioned) I can calculate the sign and magnitude of the frequency
error.  Then I use that in a feedback loop to change the frequency
of my locally-generated oscillator, seeking always to reduce the
resulting I/Q components to DC.

It's similar to a phase-locked loop, but implemented computationally.
Now, assuming the initial tuning is accurate enough (i.e. the
difference in Hz between the incoming 800 Hz audio and my locally
generated 800 Hz reference phasor is less than +/- one-quarter the
bitrate) - in theory, once locked on, the receiver will track
a *slowly* varying BPSK signal all over the band because it keeps
adjusting the local oscillator to track the incoming signal.  To
demodulate the BPSK we just apply the rule: if the phase of current
bit is more than +/- 90 degrees away from the phase of the previous
bit, a "1" was transmitted (differential mark), or if the phase was
more than +/- 90 degrees from my reference phase (established by
long-term averaging) - then it was an absolute "1".

The tracking range is not limited to a few Hz unless we restrict
the local oscillator such that it is not allowed to go outside
some range.  Of course, if the incoming audio frequency changes
too fast it will result in an incorrectly computed frequency offset,
equivalent to a PLL going unlocked.

My experience with this system is that it works fine when the SNR
is good, but degrades quickly when the signal starts to get close
to the noise.  When we really need to decode a weak signal it always
pays to turn off the tracking loop and rely on the last known good
received frequency.  I could have improved the system by estimating
the SNR and trying to track an incoming signal less agressively
when the SNR was poor.  The operator can do that manually in AFRICAM
but it would still be nice to have it all happen without operator
intervention.

Bill
VE2IQ