[Lf] GPS-Disciplined BPSK]

[Andre' Kesteloot]

Bill de Carle wrote:

> 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