Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: AFRICAM 5.0

To: [email protected]
Subject: Re: LF: AFRICAM 5.0
From: Bill de Carle <[email protected]>
Date: Fri, 17 Dec 2004 10:09:12 -0500
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
At 02:26 PM 12/17/2004 +0100, you wrote:
Thanks Bill for the new AFRICAM - I will try later to run it in a DOS box under WinXP, or reanimate my stoneage notebook.

AFRICAM doesn't run well under Windows, even in a "DOS" box -
I find it makes errors when it measures the internal CPU clock
speed, and when it measures the sound card (and possibly even
the Sigma-Delta interface?) sampling rate.  Looks like Windoze is
taking a lot of machine cycles in long enough blocks that I can't
service all interrupts in the usual time.  It runs properly if
you boot to DOS and avoid Windows altogether.

As I am playing with a faster version of MSK for keyboard-to-keyboard communications, I appreciate your work as a nice test suit. On this occasion: Do you use one of the "classic" MSK demodulators/decoders like "de Buda" or "Massey/Hodgart", or is it the same basic approach as for other PSK modes (chain of decimators+low pass filters, and observe the phase of the complex output signal) ?

The way I do it is to multiply the incoming audio with a phasor rotating
at the nominal carrier frequency (800 Hz).  The result has sum and difference
components.  Let's say, for example, we are running at MS100 (10 bits per
second).
The difference component will be either +2.5 Hz or -2.5 Hz.  The sum will be
around 1600 Hz.  The basic idea is to measure the difference frequency.
Unfortunately the high freq component in the mixer output causes problems so I
take it (mostly) out by basically adding up 10 samples (at 8200 samples per
second)
- which makes an effective and cheap lowpass filter.  I just use a 10-slot
running average accumulator and sum the complex values into it as they appear,
subtracting the reading from 10 samples ago each time as well.  Then I measure
the low frequency component by taking the phase at each sample point,
seeing how
much the phase increased or decreased from the previous sample point, then
fitting
a regression line to the increasing or decreasing phase values.  The slope
of the
line is how many degrees (radians) the phase increased per sample averaged
over
the bit time.  That is easily translated into the frequency of the mixer's
output,
but all I really care about is the polarity.  Plus slope means a "1" was
received,
minus slope means a "0".  I use the actual numerical slopes to estimate how
far off
the carrier we are tuned, but that is secondary to the detection process.
The linear
regression works better than a straight average over the bit time because
it does a
better job of making the answer independent of the jitter (noise) at each
sample point.

A better way is to break it up into two channels staggered one with respect
to the
other by one bit time.  Then you can multiply each channel by a 2.5 Hz
phasor to
reduce the difference freq to DC, and simply add them up over two consecutive
bit times to get the phase.  The original bitstream can then be
reconstructed from
the two polarities in the two staggered channels.  The problem is that way
works only
when we have a good phase for the local oscillator clock at 800 Hz - and it
is difficult
to get it from the signal when the SNR is poor.  Also, it depends strongly
on the Tx
sending pure MSK, which most people will not be able to do.  I think the
FSK approach
is a good compromise to start testing with.

You might want to download the latest version of MSKGEN.COM from my
website.  It uses
a soundcard to make pure MSK, but if you invoke it with "NOMOD" it outputs
a pure
800-Hz carrier.  Run that through *the same* soundcard for calibration.  I
tried sending
MSK from one soundcard to another at 800 Hz - it doesn't work well at low
baudrates because
the darned soundcards are *way* off in their sampling rates.  The stability
is OK, but
the absolute errors are unacceptable and it would be too much trouble to
trim them.

73,
Bill VE2IQ



<Prev in Thread] Current Thread [Next in Thread>