AFRICA V 3.0

Version 3.0 has a new command: ALERT.

You may enter a test string via the ALERT command, then whenever that
string is matched by incoming characters AFRICA will sound an 800-Hz
alert through the PC's speaker.  It will also set parallel port bit 7
high for the duration of the match (usually 1 character time) so you can
activate an external circuit if you wish.  Bit 7 is TTL/CMOS level (0 to
5V) and is found on pin 9 of the standard 25-pin printer connector.
As with other commands, you may enter the command all on one line
(e.g. "ALERT VA3LK") or wait for the prompt and enter the string on
a second line.  Please note that if you must have imbedded spaces in
your text string you should enter it at the prompt only.  The comparison
is case-sensitive.

While ALERT is enabled, the RECEIVE header line on the screen will display
the alert-string you entered.  With ALERT enabled, the regular ASCII BEL
(07h) characters are not "displayed" - so if you get tired of hearing
those random beeps, you can enter some string that's near-impossible
to come up by chance alone, then you can sleep soundly.  To shut off
ALERT mode just enter a null string.

Version 2.7 supports a new command line parameter: fcar=xxx.
This allows AFRICA to run with carrier frequencies other than the standard
800 Hz.  We still have the rule that there must be an integral number of
audio cycles in each bit time.   Please note that output BPSK generated
with the SD-DAC system will still be at 800 Hz - the fcar parameter only
specifies the *receive* carrier frequency.  Relatively low audio freqs
are OK - for example, fcar=100 (100 Hz) is fine.  If you're using MS100,
you should be able to use a carrier all the way down to 10 Hz, although
I haven't actually tested that.  The main reason for this feature is to
accommodate those wishing to use ultra-low audio carrier frequencies in
laser communication experiments.

Version 2.6 allows the user to manually enter the exact frequency
being received.  This frequency must be within 50 Hz of the nominal
value which is 800.0 Hz.   You should leave AUTOFREQ *OFF* - and issue
the command "TF 8xx.xxxxxx" - you can enter a lot of places after
the decimal point.  The displayed tracking filter freq should
update in the STAT window; although it will only be shown to two
decimal places, it internally retains the precision you entered.
The main advantage of this is when you know very precisely the frequency
being received but your radio doesn't tune in fine enough steps.  You
set your receiver to the nearest available frequency, then enter the
expected BPSK baseband frequency with the TF command.  That way you
can enjoy all the advantages of being tuned to *exactly* the right freq.

Version 2.3 has a bug corrected and some minor improvements.
The AFR+GRAB still doesn't work as well as I would like and I'm
going to be looking at it some more, but I thought I'd post the
intermediate version here because it may be helpful to some people.

The "bug" was in the COH detector - it often resulted in a "free" one-bit
error (always the first bit in a frame, hi!) while using the ET modes.
ET1 tolerates 2 bit corruptions without any problems, but when you start
off with 1 bit corruption you didn't need it reduces the margin a lot.

The problem was that when the BitPhase tracking loop adjusted the BitPhase
parameter, one consequence was changing the measured phase of the 800-Hz
waveform.  It actually changes +/- 40 degrees for each step in the BitPhase
value (138 microseconds).  I wasn't compensating for the resampling phase
shift.  Fortunately BitPhase is only updated at the end of each frame.
Problem is fixed now.  Should see a small improvement in copy while using
the COH decoder, especially under marginal signal conditions.

The NF parameter has been re-introduced.  You can set it with the "NF nn"
command.  This is the number of consecutive bits over which the incoming
frequency is measured.  The result of the measurement drives the frequency
tracking filter.  When the SNR is good, almost any value for NF will always
give the correct measured frequency.  The default (e.g. 15 for ET1) is
just fine.  When the SNR deteriorates however, it becomes very difficult
to measure the incoming frequency accurately.  Cautiously increasing the
NF value may help.  (Watch the displayed freq readout, increase NF slowly
as long as it gets more stable.  A point will come where further increases
will make things worse.)  The problem here is that in order to measure the
frequency accurately under very difficult conditions, we have to look at
the signal for a long time.  That's fine if the frequency is absolutely
stable, but over these time periods it's difficult to keep the frequency
constant (even propagation can introduce changes in the received frequency),
and since the measuring algorithm assumes the freq is constant, looking
at the signal for a long time span gives it more opportunity to change and
hence screw things up.  There is probably an optimum value for NF, based
on the received SNR and the speed being used.  At this point if you don't
know what's going on it's best to just stick with the default values chosen
by the program.

You can now directly enter a value for the tracking filter's center frequency.
The command is "CF xxx.xx" - of course it only makes sense to do this when
the tracking filter is not being updated automatically - i.e. turn AUTOFREQ
OFF if you want to do this.  Essentially this gives us the ability to tune
in the incoming signal manually.  Usual problem: when the SNR is good the
tracking filter works beautifully.  But when the SNR is lousy the system
can't measure the incoming frequency very well and the center frequency tends
to jump around quite a lot.  When using the AFR decoder the signal *must* be
tuned in precisely.  If you cannot be sure of the received frequency and the
signal is too weak to hear (hence too weak to measure its freq accurately) -
then stick with the COH decoder.  I just did an experiment here while
receiving the SOLAR beacon.  Started out fine with AUTOFREQ enabled, AFR
decoder solid copy.  I noted the exact frequency as measured by AFRICA and
wrote it down.  Then I attenuated the signal so copy virtually disappeared.
The measured freq was jumping all over the place and the center freq of the
tracking filter was trying to follow it.  When I turned off AUTOFREQ and
manually dialled in the correct frequency (800.24 Hz in this case) the AFR
decoder started printing out perfect copy again.  So if you have external
means to establish the exact receive frequency to within 0.01 Hz or so,
by all means use it!

A "CW" ident capability has been added.
Thanks to Paul, pa0ocd for the suggestion.

You may issue the CW command at any time while operating, just like any
other command.  The short message following the command will be sent out
not in BPSK mode, but in standard Morse code.  You must have a space
between the "CW" and the message.

Example:  CW 73 de ve2iq #

Here are the characteristics:

1.  There is no frequency offset - the CW tone is exactly 800.0 Hz, so
it should get through any narrow filter at the Rx end.

2.  Pulse shaping is used to avoid splatter.  The attack and decay times
are 6.25 msec (equivalent to CPR=5).  CW speed is MS50, or 24 wpm.

3.  Concerning MUTE, HANG, etc - the rules are the same as for C-BPSK.
The CW message goes into the output buffer and will be sent in its course.
If the OP buffer was empty, PTT will be activated to key your Tx.  With
the default HANG setting, you will need to put a "#" as the last character
of your CW message if you want to unkey the Tx after the message.  The "#"
character sounds as di-dah-di-dah-dit (ar).  If you don't put the "#" at
the end of your CW message, the system will revert to sending idle frames
in C-BPSK at the same settings you had before the CW message was sent.

4.  Since Morse code doesn't support upper/lower case stuff, all entered
text is mapped to upper case by default.  Some keys have special sounds:

"@" = di-di-di-dah-dit (sn)
"*" = di-di-di-dah-di-dah (sk)
"!" = dah-di-dah-di-dah

5. It is recommended to keep CW messages short - i.e. just your callsign ID.
Of course all other stations will have to re-sync on you once you send some
CW.  Probably best to send a CW-ident only when signing off at the end of
a QSO.  I will look into what might be done to retain sync, but it's pretty
messy because the Rx tracking loops are looking for C-BPSK (with its embedded
idle characters, etc), not arbitrarily sent CW.

C-BPSK decoder, "AFRICA"  Version 1.0
-------------------------------------

A whole lot of things are different or new...

1.  This program needs a fast computer.  A Pentium is best, but maybe
it will run on something slower like a fast 486?  It absolutely needs
a math-coprocessor (486's and up have them built-in) - or it will bomb.
If it looks promising I will probably go through the code and try to
streamline it so it will run on slower machines.  You can tell if your
machine is fast enough easily - just hit the HOME key, and if you see
lots of overruns or maximum queue more than 100 or so, forget it.

2.  All soundblaster support has been removed.  AFRICA assumes you have
    a SD-DAC board for your output.  (Doesn't everyone?!)

3.  GRAB function works in COH mode only

4.  The ability to save/restore station parameters via the F1..F8
    keys has not been implemented yet.

5.  The OutBitPhase thing has been removed.  Nobody ever used it anyway.

6.  AFRICA uses the same modes and code-sets as COHERENT.  AFRICA can
talk to COHERENT and vice-versa.  ASCII, ET1 and ET2 are supported.

7.  The new program has two techniques available for decoding BPSK:

     1) The same algorithm previously used, called "COH"
     2) A fancier algorithm called "AFR"

There is a parameter up on the STAT screen called "DECO" - you can use
the mouse to click on its asterisk to toggle between the two decoders.
The actual switch is done immediately after a character has been decoded,
so there will be no glitches on the screen.

Here are some of the more obvious operator-visible changes....

1.  AFRICA has better bit-tracking.  The BitPhase number now equals the
sample number (7200 samples per second).  At MS25 for instance, there are
only 20 cycles of audio (at 800 Hz) in each bit time.  COHERENT chose the
end of the bit time only to the nearest complete audio cycle.  That is
pretty coarse, especially at the faster baudrates.  There were only 20
possible values to choose from.  In other words, there could well have been
a considerable error in where the integration window ended.  Any error in
the bit timing can hurt us like hell, because if a phase transition occurred
before the end of the current bit time, say, we would be integrating some
of the next bit's energy by mistake, which not only doesn't help us to find
the phase, it hurts us because it cancels out the same amount of energy
from what we had already integrated.  So it pays to get the bit edges as
well-defined as possible in time.  At MS25 there are still only 20 audio
cycles in each bit time, but there are 180 instantaneous voltage samples
from the ADC available, and AFRICA splits up the bit time into 180
increments instead of 20.  That translates into better recovery.  Of course
the old bit-tracking algorithm wouldn't work worth a damn with the much
finer resolution, because it could step only one cycle plus or minus at a
time, and that only at the end of each bit time.  At MS1000 for instance,
each transmitted bit has 7200 voltage samples in it, and if we had to step
only one sample at a time it could take about an hour to move to the right
point (if all went well and it always moved in the right direction!).

The algorithm used in AFRICA not only decides in which direction to move, it
also estimates "how much" to move.  If the SNR is good, it can acquire the
correct bit sync in only a few steps, starting from anywhere and at any
speed.  If you set TC to 1, it will acquire the final answer in only one
step (after the next bit time) - but it will be unstable and might jump
around a whole lot from bit to bit.  You can still disable it (i.e. turn
AUTOTRACK OFF)- and find the correct point by manually stepping through all
the possibilities, but it could take ages.  Probably best to leave AUTOTRACK
enabled all the time, and only adjust the TC parameter.  Once the BitPhase
number appears to have stabilized, if you know there is little drift between
the SD oscillator clocks at both ends, you can increase TC substantially to
prevent the bit tracking loop from jumping around.  Of course never set TC
so high that the loop cannot track out long term differences between the
1.8432 Mhz clocks at each end.

2.  The indicated frequency of the incoming wave should work better now.
    The frequency is measured more accurately and displayed to the nearest
    hundredth of one Hz.  If you see it jumping around more than 0.1 Hz,
    be sure to use only the COH decoder, not the AFR decoder.

3.  The amplitude has been normalized/corrected for speed, so the numbers
represent basically the incoming voltage in counts.  There is only one
amplitude reported, not separate amplitudes for MARK/SPACE.  And the new
amplitude is corrected for bit-time mismatch errors, so it should (?) stay
pretty much constant and reflect more accurately the actual amplitude of
the incoming signal.

4.  When the AFR decoder is in use (DECO:AFR), the bandwidth of the front
end filter is only one-sixteenth of what it is for (DECO:COH), one
twenty-seventh if ET2 is used!  It is only to be expected that a whole
lot more problems will be encountered due to frequency errors in the
800-Hz tone.  COHERENT works over a tuning range of plus or minus
10 Hz at MS25.  (That's when the SNR is perfect!)  With the new AFRICA
algorithm, you would have to tune the signal to well within plus/minus
0.625 Hz *even at MS25!* - which is nearly impossible at HF.

Fortunately, I think I have a solution.  The main lobe of the DSP filter
in COHERENT was *always* centered on exactly 800.0 Hz, and any mis-tuning
of the radio simply moved the signal down the skirt of the filter so the
response was degraded.  AFRICA has a filter with a variable center frequency,
and it can be adjusted automatically by the program.  When the AUTOFREQ
tracking loop is enabled, the program will find, lock onto and then track
the incoming BPSK signal, keeping it always centered in the DSP filter's
passband.  There is another time-constant, TCF, which sets the response
time of this tracking loop.  Large values of TCF slow down the loop, making
it reluctant to move very fast.  Small values of TCF make the filter follow
the incoming signal quickly, but are more unstable, and make the filter
more vulnerable to being "captured" by nearby strong carriers.  I am looking
at building in BPSK discrimination capability, but it isn't in the code yet.
A nearby steady carrier which is much stronger than the BPSK signal will look
awfully attractive to the tracking filter.  For this reason, once you have
the filter locked onto a BPSK signal and are getting good copy, it may pay
off handsomely to increase TCF to lesson the possibility of losing lock and
jumping to an adjacent carrier's frequency.

The new tracking filter can operate over a *wide* range of frequencies with
absolutely no degradation in performance.  There is an arbitrary software
limit of from 700 to 900 Hz.  You should always try to tune in an incoming
signal as closely as possible to 800.0 Hz before enabling the AUTOFREQ loop.
If you "lose" a signal, check to see where the center frequency of the
tracking filter is - it could have drifted way off.  If this is the case,
reset it to 800.00 Hz and let it re-acquire using the COH decoder.

There are two frequencies displayed (to the nearest hundredth of one Hz)
one right above the other.  The top frequency is that of the incoming signal
as measured by the program, the bottom frequency is that of the center of
the DSP filter's main lobe.  When AUTOFREQ is enabled, the bottom frequency
should track any gradual changes in the incoming BPSK signal's frequency,
and it will track even if the signal gradually drifts up or down by up to
100 Hz.  Even if the signal winds up at 701.00 Hz the data recovery should
be just as good as at 800.00 Hz.  Of course any narrow IF filters in your
radio might come into play if the signal drifts too far from 800 Hz.

You will note an asterisk (*) right next to the bottom frequency display.
Clicking on this asterisk will reset the center frequency of the tracking
filter to exactly 800.00 Hz.

Considerations on how the AFRICA program's performance should compare to
COHERENT.....

If the phase of the incoming signal is stable, then AFRICA will run
rings around COHERENT.

But by stable, I mean STABLE!  Any slight frequency offset between the 800 Hz
transmitted and the 800 Hz received will produce a cumulative phase error
over time.  Once this phase error reaches plus or minus 90 degrees, the
decoder is guaranteed to make an error.  At MS25 ET1 for instance, a 1-Hz
error will produce a phase shift of 9 degrees from one bit to the next.  Not
the end of the world, but it still hurts copy.

The AFRICA algorithm looks at all the bits in a frame simultaneously and
insists the phase remain constant over the longer time period.  At ET1 for
instance, that's 16 times longer.  So we must keep the frequency offset
down to one-sixteenth(!) what we could tolerate before.  And the phase
must not drift during the entire character (as opposed to during only one
bit-time using the COHERENT detector).  If there is almost *any* amount
of flutter (rapid variation in frequency/phase of the received signal),
then the COHERENT algorithm will perform better than the AFRICA algorithm.
If there is no flutter, then the AFRICA algorithm can copy a BPSK signal
buried more deeply in the noise.

The new AFRICA program V1.0 lets you choose either decoder.  All you have
to do is point your mouse at the (*) next to the DECO: field and click.
You will not need to re-sync, and you can do it while a station is sending
text to you so you can switch rapidly back and forth between the two
algorithms to see which gives the better copy.  Unless your 800 Hz trans-
mitter is phase-locked to the receiver's SD board sampling clocks, you must
use the tracking filter for AFR.  On HF it is hopelessly impossible to
keep a signal tuned in to better than plus or minus 0.625 Hz (at MS25 ET1).
Any error greater than that will degrade copy rapidly.

The improved features are available for both decoders.  Both use the finer
resolution Bitphase Tracking loop, and both can use the new tracking
filter which can compensate completely for a *constant* frequency offset.
The tracking filter is optional - you can shut it off if you want.  When
using COH decoder, the bandwidth of the new tracking filter is the same
as the filter used in the old COHERENT program, only difference is the
center frequency is not absolutely fixed at 800.0 Hz, it can follow slow
drifts in the received signal.  When using the AFR decoder the bandwidth
is n times narrower, where n=10 (ASCII), 16 (ET1) or 27 (ET2).  When you
shut it off the center frequency remains where it was at when you shut
it off.  If you want to reset it to 800.00 Hz, use the mouse to click on
the asterisk next to the displayed center frequency.

The SYNC function now works similarly to the one on the old program.
You hit END to start sync-ing and hit END again to quit.  You many now
specify a length of time in seconds.  E.G. Sync 10 will sync continuously
using only the last ten seconds worth of received information.

Bottom line:

The new program should work at least as well as the old program even under
difficult HF conditions, and it has the potential to work much better than
the old program if the signal is very stable phase-wise and you can use
the AFR decoder.  Even using the COH decoder, some improvements have been
made, so that should also work somewhat better than what we've had before.

In case you don't have a mouse...

left arrow	- adjusts BitPhase lower
right arrow - adjusts BitPhase higher
up arrow    - adjusts startbit higher
down arrow  - adjusts startbit lower
PageUP      - adjusts TC higher
PageDOWN    - adjusts TC lower
^PageUP     - adjusts TCF higher
^PageDOWN   - adjusts TCF lower
home        - some stats and diagnostic info
^home       - resets the tracking filter center freq to 800.00 Hz
end         - hotsync key
^end        - toggles freq tracking filter on/off
tab         - generates string of }}}} for sync purposes
Shift-tab   - toggles between DECO:AFR and DECO:COH modes
(^ = control key held down)

If there is something you can't find above, try typing the parameter name
in command mode; there are some commands which aren't shown on the menu.

73 de Bill VE2IQ
