[Lowfer] New AFRICAM for GPS

[Bill de Carle]

I have loaded the latest version (4.1) of AFRICAM to my website.
At this time, the only site that has it is:

www.nrtco.net/~ve2iq

I'll get it on my old site at magma.ca soon.

AFRICAM 4.1 - 2003.

This program now supports GPS-disciplined timing.  To make it work you
must have a GPS 1-PPS (one pulse per second) output from your GPS Rx.
This is usually a positive-going pulse lasting about 200 msec.  The leading
edge (rising edge) of this positive-going pulse is synchronized to the
start of each UTC second to within 1 microsecond or better. To connect this
signal to the computer running AFRICAM, we must invert it.  The best way
is to run it through an inverting RS232 driver/level-converter, but you
can probably get away with just a simple transistor switch to invert the
pulse and make it go from 12V or so to ground.  If you keep the lead short
you don't absolutely have to have the RS232 signal go negative, but it is
always better to do that (e.g. with an RS232 driver running +/- 12V) for noise
immunity.  We feed the inverted pulse into the designated serial port
(default is COM1) on the /RI pin.  If your serial port has a 25-pin connector,
/RI is input on pin 22, if it's a 9-pin connector, /RI is on pin 9.  This
makes a signal called TERI (trailing edge ring indicator).  It shows up in
bit 2 of the Modem Status Register.  "Bit 2 indicates that the /RI input
to the chip has changed from an on (logical 1) to an off (logical 0)
condition".   AFRICAM gets an interrupt on TERI to coincide with the
rising edge of the original 1-pps pulse out of your GPS receiver.  I know
this all works with the Garmin 20 and 25 receivers, your mileage may vary
with other makes.

Now, if you are *not* using a Sigma-Delta interface, you can use the available
serial port's input in another way.  Just run the NEMA sentences output from
the GPS Rx each second into that port.  The default baudrate on power up is
4800 baud for the Garmin GPS units, so that's what the port is set for.  If
someone really needs a different baudrate, let me know.  Feeding the NEMA
sentences into the program AS WELL AS THE 1-PPS timing pulse is advantageous
because it eliminates a certain ambiguity.  If connected, AFRICAM looks for
the $GPRMC sentence, which gives exact UTC time.  It also allows AFRICAM to
warn the user if GPS coverage is poor and the 1-pps timing cannot be trusted.

Basically, AFRICAM needs to know exactly what time it is.  If you use only the
1-PPS input on the /RI pin the rule is that you must set up the internal DOS
clock on your computer so that it is well within 1-second of the correct UTC
time when the AFRICAM is first invoked.  Once it is running, AFRICAM will keep
its own time-of day clock by counting the 1-PPS interrupts.  If you don't
have any way to set your DOS clock that accurately, AFRICAM won't know the
time of day and it won't work properly.  About the only reason I can see you
would not want to feed the GPS Rx's NEMA ASCII sentences into a serial port
would be if you needed that serial port for Sigma-Delta input.  I have written
a little utility program called SETDOS - it doesn't need SD input, just the
1-PPS and the NEMA sentences from your GPS Rx.  You run SETDOS to set the
Time in your computer with GPS accuracy, then switch the serial port over
to the SD board input, and start AFRICAM.  You have to do this quickly because
some computer clocks drift quite a bit and can be more than half a second
off the correct time after a few minutes.

Software-wise, when using GPS-disciplined communication, AFRICAM synchronizes
each transmitted (and received) BPSK bit to exact multiples of the bit time,
assuming we started transmitting our message at midnight GMT.  For example,
at MS1000, each bit will start exactly on the second, at MS2000 each bit
will start only at the beginning of even seconds, etc.  Frame sync works the
same way - the assumption is that the first bit of each frame was transmitted
starting exactly at midnight GMT.  Outgoing keying for BPSK is via the RTS
pin of the selected serial port.  The program allows a small offset adjustment
in timing (a few msec) to compensate for delays.  The program also allows a
small adjustment in receive timing to compensate for propagation time and
receiver delays.  When using GPS timing, we do not need (or want) the usual
bit and frame tracking loops in AFRICAM to work.  Normally these loops try to
acquire, lock on and track the timing transitions in the incoming audio.  If
we are running with GPS we know a-priori the exact timing, so we don't need
to search for it.  To implement this, notice that in the top right corner of
the screen there is a switch to enable AUTOTRACK.  Toggle this switch until it
shows the "EXT" position.  That means exterial bit-sync.  And for frame sync
using GPS, you must enter a sync command with a parameter of -1.  We used to
say, e.g. "sync 20" meaning, "sync using the last 20 running seconds of data"
but now we say "sync -1" which means "synch using absolute timing as set
by the GPS system".

Note: at this time, if you change modes or speeds you will have to cycle the
AUTOTRACK and come back to EXT again, and also re-issue the SYNC -1 command
because all the timing calculations are done once and the times depend on
what mode you're using and what speed.

Needless to say, if you use GPS-disciplined receive the station you are trying
to copy *MUST* be using GPS-disciplined transmit, otherwise you will get
garbage forever (unless the clock at the Tx end is amazingly good and you
just happen to get very lucky and hit the bit and frame timing right on the
money by coincidence, hi!).

There is no waiting for the Rx to sync-up with GPS.  Once you set AUTOTRACK
to EXT and issue the SYNC -1 command, that's it.  You are instantly in sync.
You should either start getting good copy right away or it isn't going to
work.
You can use the GRAB mode if necessary to pull very weak signals out.

Good luck,
Bill