After a bit of  'codebreaking' to identify the character boundaries I
managed to get perfect copy of Brian's 1 Bit per Second GPS locked PSK
transmission.   Starting at the two minute marker the text read     "1drp
ct1drp [nul] ct"      where [nul] is the ASCII zero code.

So the transmission obviously wasn't started on the even minute marker (was
this deliberate Brian ;-)

The attached file is a plot of phase accumulated over each second, plotted
vertically from -180 to +180 degrees, with time horizontally.   Each change
in colour which occurs every 8 bits corresponds to a new ASCII character,
and in hexadecimal the bits making up each colour are :
0x31 0x64 0x72 0x70 0x20 0x63 0x74 0x31 0x64 0x72 0x70 0x20 0x00 0x63 which
equate to the letters above.   Also shown is the phasor diagram for an
entire 10 minutes worth of transmission indicating Brians signal clearly
drifting around the phase circle - the S/N appears to be about 10 - 15dB in
the 1Hz bandwidth; this sort of S/N  is consistent with 100% BPSK decoding.

The initial polarity had to be inferred by assuming all 8 bit characters
were plain ASCII, and therefore the most significant bit (the first sent)
would always be zero;  the rest making up each character follow from that.
It gets a bit confusing when the phase changes from +180 to -180, but it is
obvious enough when this happens.

The frequency error between us can be read off by looking at the slope of
average phase over several seconds which is something like 90 degrees in 25
seconds approximately, so 1 cycle in 100 seconds = .01Hz.   Which is almost
exactly the frequency setting resolution of my LF receiver.

The signal was inaudible, and viewing on Argo showed a barely detectable
signal in 20s dot mode.

My decoder is hardware based. The Rx output, at 1kHz centre freq exactly, is
bandpass filtered to 60Hz bandwidth in an opamp circuit, multiplied with two
90 degree phase shifted square waves driven from the divided down frequency
standard again using opamps.  The output from these are low pass filtered to
a few Hz (in more opamps!) then sent to a PIC microcontroller for A/D
conversion.   The PIC is triggered by the pulse from a GPS receiver and
makes 250 measurements of both I and Q channels each second.   The 250 pairs
of measurements are summed and output as two numbers over the RS232 port to
a PC for subsequent plotting.   The PIC also reads the time from the NMEA
string sent by the GPS and translates this to a time code included with the
data sent to the PC.   Later, now we have proved the technique, automatic
decoding of the bit pattern can replace the colour plot.

The frequency error remains a problem - it is quite unreasonable to expect
stations to hold phase within better than 90 degrees over the duration of a
QSO - although not impossible, just difficult - so it looks as if
differential coding is required.   In this scheme a binary one is
represented by the phase CHANGING from one bit to the next, a binary zero by
it remaining as is.  In one go, differential coding removes the phase
ambiguity and copes with slow relative frequency drift, but inherently
doubles the error rate.  If one bit is decoded in error then the next will
also be wrong as it will be compared with the previous faulty one.  A small
price to pay for the simplicity and reliability of not having to generate
carrier tracking.

BTW, on a different subject, the graphics plots generated were several tens
of K in size as .JPGs but only a few K in .PCX format  Shows the value of
run length compression for this type of plot where most of the image
consists of just one colour.

Andy  G4JNT

Phaseplt.pcx
Description: Binary data

Gpslkpsk.pcx
Description: Binary data