Hello everyone,
It has long been recognized that establishing bit-sync and frame-sync
is difficult with current implementations of BPSK whenever there is
marginal copy and the signal only comes up out of the noise for a few
seconds at a time. We have to look at the signal for a long time to
synchronize and by then it may be too late to copy any actual data
because the signal has faded out. Clearly it would be a major advantage
if we could obtain the clocking and framing information by other means.
If both the Tx and Rx know precisely what time it is and can agree on a
suitable standard transmitting schedule the problem is solved.
I propose to use GPS and the following transmission protocol:
Regardless of where a station is in the world, he will transmit his
BPSK frames synchronously according to a UTC time reference grid. This
will work for all speeds and encoding modes. The rule I'm using is
to simply assume the transmissions started with the first bit of a
frame at midnight UTC and have continued uninterrupted since that time.
If the Rx knows the speed and mode (i.e. ET1, ET2, ET3) - he can calculate
where the Tx is in its frame, when each bit starts and stops, etc. based
only on his knowledge of the present UTC instant. Given an estimate of
the distance the signal has to travel the Rx can then expect to receive
synchronous phase transitions at precisely-known instants in time.
The transmitter's job is to put out his signal according to the above
rule. For example, at MS1875 (1.875 seconds per bit), and ET3 (32 bits
per transmitted frame), each frame will take exactly 1 minute to send,
and the first bit of every frame will start exactly on the minute boundary.
The receiver's job is to know the time, know the distance from the
station he's trying to receive, and to expect the first bit of each
frame to arrive starting a few milliseconds after it was transmitted.
With this arrangement multiple receivers at various distances can concurrently
monitor the same transmitter. I am presently testing a GPS-disciplined version
of AFRICAM that uses this protocol.
The only real requirement is a GPS receiver with a 1-PPS output good to
within a few microseconds of UTC. This output is inverted and fed
into the "Ring Indicator" input of a serial port. The serial port has
something called a TERI (Trailing Edge Ring Indicator) interrupt, which
gets our 1 PPS signal into the PC with good time accuracy. If you are
using Sound Card audio input, you *may* connect the GPS receiver's
standard 4800-baud NMEA-sentence output to AFRICAM's serial port; that
way the UTC gets set automatically. If you're using a Sigma-Delta board
for audio digitization, it must have the serial port. But you can still
input the 1PPS GPS signal on the RI pin. Then you'll have to synchronize
AFRICAM's UTC clock by listening to WWV's ticks. It's quite easy.
Ring Indicator (RI) is on pin 9 of a DB9 connector, pin 22 of a DB25.
If AFRICAM detects a 1 PPS input it automatically calibrates the CPU's
internal Timer-0 clock continuously against the GPS reference and uses it
for timing. It will also tell you the exact sampling rate of your sound
card if you're interested.
There is an extra position for the AUTOTRACK switch: EXT (external sync).
That's for bit-synchronization. And you may specify a SYNC time of "-1"
which means we calculate where the startbit is based on absolute time
instead of trying to extract it from the incoming data. All the old
functions of AFRICAM are still available and you can use them for copying
GPS-disciplined BPSK if you don't have a GPS receiver handy.
The new AFRICAM also has the means to *transmit* short (1 line) test
messages over and over until a certain time of day is reached. These
transmissions use the RTS line to BPSK-modulate a carrier and the DTR
line as a push-to-talk to key up the transmitter, same as COHERENT/AFRICA.
Transmission only works in GPS-disciplined mode however.
There are separate user-set parameters for transmit advance and receive
delay time. Resolution is to the nearest millisecond. Transmit advance
causes keying to occur a few milliseconds earlier than the correct time
to allow for delay through transmitter circuits (which can be quite a
few milliseconds) so the signal gets "launched" at just the right time.
The receive delay accounts for delays in the receiver and of course the
propagation delay. Estimate 5 microseconds per mile or 1 millisecond for
every 200 miles.
Initial results look very promising but I want to run some tests before
posting the program to my website. If anyone out there is already set up
with a 1 PPS GPS signal and wishes to participate in these tests, please
let me know by e-mail.
Best,
Bill VE2IQ
|
