			Bill de Carle   VE2IQ
			29 Sommet Vert
			St-Adolphe d'Howard, PQ  J0T 2B0
			Canada.
			(514) 226-8999 [voice]
			(514) 226-7796 [fax, 24-hr BBS]

Revised:	November, 1995.

COHERENT 4.4 with CCW, BPSK, PSK, PSKL modes

BPSK mode notes...
------------------
There are various ways to do Phase-Shift Keying.
BPSK is a "differential-MARK" mode.  A phase shift represents a mark (1),
no phase shift represents a space (0).  PSK is a straight PSK mode.  After
perusing the chapter on Coherent PSK in a textbook, it became clearer to me
that the better bit-error-rate performance one expects to achieve with
straight PSK depends entirely on the fact that the receiver "knows" a-priori
what the "correct" values of the phase are for MARK and SPACE.  Basically, the
machine measures the received phase angle, then compares it to the MARK and
SPACE phase angles (stored internally) - then chooses the one that's closest.
Unfortunately, when transmitting the signals over a radio link, this knowledge
is not so easy to come by.  The incoming phase will depend on the distance
from the transmitter, the propagation path, etc. etc.  And there is no easy
way to establish that reference.  What I have in mind is to accumulate stats
on the incoming signal over a long time period (e.g. several minutes) - and
thus build up a "most-likely" value for the reference phase.  Of course, this
would be unworkable if the receiver were located in a moving vehicle, etc.  It
will require some more thought.  There is also the ambiguity about which of
the two phase angles being received is MARK, which is SPACE.  There seems to
be a 50 percent chance of getting all the bits inverted.  We could probably
use Mark Mallory's correlation technique to decide this automatically, as long
as the actual data pattern being transmitted wasn't too confusing.

Sigma-Delta board

The board is pretty easy to hook up.  The audio input is nominally around 400
millivolts RMS.  If necessary, the 20K series input resistor on the S-D board
(R01) can be adjusted to vary the front-end gain.  Halving the value to 10K
would double the gain, etc.  The best way seems to be to start with more audio
than you need, then attenuate it with a potentiometer until the red CLIPPING
message just disappears from the top right corner of the screen.  The board
samples the incoming audio 7,200 times each second, converting the analog sig-
nal to an 8-bit digital value (7 bits plus sign).  These digitized samples are
then whipped into the computer via a serial port (preferably COM1) at 115.2
kilobauds.  Everything else is done in software.

The COHERENT program assumes an audio carrier frequency of 800 Hz.  Assembly
language DSP code computes the amplitude (to a part in 20,000) and the phase
angle (to the nearest tenth of a degree) after each 100 msec window.  The
Pascal program then uses this data to figure out what Morse code bit is
being received (CCW) or what ASCII character (BPSK).  Regenerated Morse code
is sounded through the PC's internal speaker; regenerated ASCII is displayed
on the computer screen.

The operator can enter certain keywords on the same DOS line as the name of
the program.  These parameters are held for the duration of the session.  The
only ones you need are:

	Which serial port is used: COM1 (default), COM2, COM3, COM4.

	Which speed is used: MS100 (default), MS200, MS300
		(i.e. 100 msec per bit, 200 msec per bit, 300 msec per bit)

	Which mode is used: BPSK

For example, to start a COHERENT session for BPSK at the standard 10 bauds,
with the sigma-delta board sending data to the COM1 serial port, you would
type:
       "COHERENT BPSK"

Example 2:  To start a COHERENT session for BPSK at 5 bauds, using COM2, you
would type:

	"COHERENT BPSK MS200 COM2"

Once the program loads, it makes a single screen, divided into four sections.

The top part contains indicators for the various software switch settings in
use, some statistics (e.g. the amplitudes of the MARK/SPACE carriers, etc) -
and a time of day clock (from the PC's internal DOS real-time clock) which
updates on the second.

The next window down the screen is called "BUFFER" - this is used to flash
help messages to the operator, and also to enter text which is to be sent
at a later time, saved to disk, used as a BEACON message, etc.

The next window down screen is called "CHAT" - any incoming ASCII characters
received and decoded by the system will appear in this screen.  Likewise, any
thing you type in this screen will be transmitted.

The last window, at the bottom of the screen (labelled "ESC") is for commands.
You can get to this window by hitting the Escape key.  A list of command key-
words will be shown.  You respond with a recognizable command, and whatever
arguments are expected, followed by <return>.  Not all recognizable commands
are mentioned in the prompt line; the only 'hidden' command you might need is
RCV (which enables receiving after it has been suspended with a MUTE command).
You will probably need to read the documentation to figure out
how to use the various commands.  On-line help is available for most of them.
Just enter the HELP command, followed by the name of another command if you
need more specific help. Commands may be entered in upper or lower case, and
may be abbreviated to the first few keystrokes to save typing effort.

DSP philosophy for BPSK
-----------------------

Essentially, we follow the same route as Mark Mallory's receiver described
in the Lowdown.  The only difference is that instead of a dedicated
microprocessor to perform the number crunching, we use a standard IBM
or compatible computer of the kind you'd find in most hamshacks these days.
At least an AT (286-based) machine is strongly recommended.  The program might
run on slower XT-type systems, but some problems would likely arise.  A math
co-processor is not necessary (or even helpful).  The PC's internal clock is
used for timing only during SEND.  You can set it or phase-lock it to an
external standard if you want to, but the whole point of COHERENT is to avoid
all this precision.  On receive, COHERENT uses software tracking loops to com-
pensate for small differences between the transmitted and received timing.
The actual window timing for received signals is obtained from the 1.8432 Mhz
crystal oscillator on the Sigma-Delta board.  Again, you can tweak it to get
right on frequency if you want to be a perfectionist.  I don't bother to set
them up accurately because the software is quite tolerant of these things, and
you have to be a long way off at 1.8432 Mhz in order to make a noticeable
difference at 800 Hz, hi!

After speaking with Max Carter the other day, I implemented a correl-
ator to find the character placement in the incoming bitstream.
It is invoked with the SYNC command; in contrast to the CCW
case where the transmitter must send a specific synchronization pattern to
lock onto, in the BPSK case, SYNC works by looking at the actual received
bitstream, presumably containing properly-framed ASCII characters.  I run a
correlation on the pattern "110" and pick the best fit.  This does, of course,
impose a requirement that there be no dead time between the end of one char-
acter and the start of the next, but I understand we adhere to this anyway.
I spent a day and a half this week wiring up a little test box with an Eprom,
etc.  This box sends a BPSK bitstream at 800 Hz nominal carrier frequency, and
COHERENT can SYNC on it just fine, and then will copy it faithfully for hours.
I also put a switch on the box with a position to select straight PSK.
If the automatic correlator doesn't work well enough in a noisy environment,
you can override its selection by using the UP/DOWN arrow keys on the PC
keyboard.  Or you can position the mouse cursor over the asterisk for any
field and step up with the left mouse button, down with the right.  Using
the mouse is always preferable to using the keyboard.

When receiving CCW, the window phase tracking loop works by
maximizing the difference in amplitudes between adjacent MARK (key down) and
SPACE (key up) frames.  The resolution is in steps of one audio cycle (1.25
msec at 800 Hz).  The system has some smoothing filtering to take out jitter,
and works fine for CCW.   In the case of BPSK, the carrier is there all the
time.  I modified the algorithm slightly to seek to maximize the amplitude
in a MARK frame which is going to be followed by another MARK frame, i.e.
for a single frame with frames of opposite phase on either side.  Any slip-
page in the correct timing will cause the amplitude to appear to decrease,
because we would then be adding in SOME signal at same frequency but with
negative sign (180 phase shift).
You can manually override the phasing loop by using the left and right
buttons of your mouse to step up/down in 1-cycle increments.  If you want
to assume complete manual control over the phasing, set AUTOTRACK OFF.

How to get started.

1.  Connect S-D board to source of 800 Hz BPSK audio (limit the bandwidth to
3.6 Khz or less), and to the COM1 serial port of your PC.

2.  Bring up the program by typing: COHERENT BPSK

3.  Adjust the audio amplitude of the 800 Hz tone to the point where the red
CLIPPING message just disappears from the top right corner of the screen.

4.  When the program comes up, the default is for AUTOTRACK to be ON.  This
will cause the system to start hunting for a lock on the incoming signal.  You
will see the Phase cycle number at top left of the screen changing slowly.
You will also notice a large difference initially between the MARK and SPACE
amplitudes.  The system should lock by itself, eventually stabilizing the
phase cycle number somewhere between 0 and 79.  The amplitudes at this point
should be essentially the same for MARK and SPACE.  If you like, you can help
the tracking loop with the mouse buttons if it is obvious which way it needs
to go.

5.  Now you can try to synchronize the start bit detection.  There is a field
in the top screen called STARTBIT Phase: - it shows a value between 0 and 9.
You can manually change this startbit position by using the mouse buttons, or
you can let the system have a go at it automatically.  To do an automatic
start bit detect by correlation, hit the ESCape key, then when cursor drops
to the command window (bottom of screen) - enter a SYNC command.
You will now be in the SYNC mode.  The system will choose the best value for
the STARTBIT phase, based on accumulated statistics to date.  This number will
appear at top of the screen.  If it seems to be quite stable, you can leave
SYNC mode by hitting ESCape one more time.  If the number is jumping around,
give it a few more seconds.  It should stabilize quite quickly, especially if
the SNR is good.  When you leave SYNC mode, the BPSK receiver is automatically
enabled.  This means any received ASCII characters will be decoded and shown
on the CHAT screen.  If all went well, you should start seeing MAX MAX MAX ...

How'd it go?  If you are getting garbled characters, try stepping through the
10 STARTBIT phase positions.

Sending data with COHERENT

You can disable the incoming traffic with a MUTE command, but this should
never be necessary since the program can run full duplex.
Whatever you type in the CHAT screen will be transmitted as BPSK.  The
program uses the RTS line (pin 4 of a 25-pin DB25 connector on the PC's serial
port) to key the transmitter for CCW.  It uses this same RS232 output line to
modulate a PSK transmitter.  For DPSK, it doesn't matter which level (-12 v or
+12) corresponds to MARK phase and which to SPACE phase.  The initial value
when the program starts up is -12 Volts, and you will see a 100 msec pulse to
+12 volts once each second. (This transition to +12 is for the first stop bit,
and the second stop bit switches it back to -12 volts).  Initially, the prog-
ram will be sending idle characters (all zeros in the 7 data bits).  Anything
you type for transmission will be slotted in at the first available start bit
time.

You can also enter a message into the BUFFER (use the BUFFER command).  The
counter at top of screen tells you how many seconds the message will run for
both CCW (Morse code) and BPSK (ASCII code).  The BPSK case at 10 bauds is
particularly easy, because each transmitted character takes exactly 1.0 second
at that speed.  When finished typing in your message (Carriage returns are not
stored) - get out with the ESCape key.

Now, you can use the SEND command to transmit that buffer.  You can also SAVE
the buffer contents to a disk file if you like, for later LOADing.

You can also schedule the buffer contents for periodic transmission using the
BEACON command.  (Try HELP BEACON for on-line help on this).  Of course, the
accuracy of the timing will be only as good as the PC's internal real-time
clock, which appears at the top of the screen.  If you need super accuracy in
this, you will have to phase lock the PC's crystal oscillator to something
more suitable.  Some PC's are excellent in this regard, others are lousy.
[See CLOCKSET.TXT for a way to compensate for PC oscillator errors.]

For now, disregard the frequency readout at the top of the screen.  I am sure
that whatever LOWFER receiver you use will be tuned in to better than a Hz
anyway.  I see the BPSK phase transitions screw up the measurement somewhat,
and the indicated frequency jumps around a bit, even with my test box, which
produces a perfect 800 Hz  BPSK signal.  If you need to use the frequency
readout as a tuning aid, disable the PSK modulation at the transmitter,
sending just a constant-phase carrier, and temporarily bring up COHERENT
in the CCW mode, using it to tune your receiver for precisely 800 Hz.  When
you have it properly tuned in, QUIT, bring up the program in the BPSK mode,
and start modulating the transmitter with BPSK.

I took a spectrum of the output of my test box.  The box sends messages like
The quick brown fox jumped over the lazy dog's back... etc.  There are several
such messages, then it all repeats.  It should be pretty much random ASCII
code.  The spectral plot looks about right.  I used the FFTZ program, with
an 8192-point FFT, integrated over a few minutes and displayed from 701 Hz to
901 Hz.  You can do it as well if you like.  If you have an Epson or IBM
compatible printer available, hit P <enter> to get a hardcopy of the screen.

Notes on COHERENT v2.5b
-----------------------
There is now a TC field displayed in the status screen for both CCW and BPSK.
This is the time-constant of the loop-tracking filter which follows the
transmitted bit frames.  The default value is 4.  If your S-D board osc.
is in good agreement with your transmitter timing, you can afford to leng-
then this TC value once lock has been acquired.  This will help it to track
better by making it more immune to jitter caused by noise.  If there is
an offset between your TX timing and the S-D board timing so that the
phase number systematically increments or decrements (always in the same
direction) - then of course you cannot set TC too slow or else the system
will not be able to move fast enough to keep up with the drift.  You can
adjust the TC field by clicking your mouse on the TC field's asterisk.

FRAME-GRABBER - this is useful for (B)PSK(L).  The idea is some stations
transmit the same short message over and over.  The GRAB command allows the
message to "build-up" gradually, and the value of each bit in the ASCII
character is determined by the number of 1's and 0's historically found in
that particular bit position.  The GRAB command has two arguments: runlength
and depth.  The runlength = number of bytes in the transmitted message before
it repeats.  Example: MAX MAX MAX would have a runlength of 4, including the
space character after the X.  The depth is how many historical readings go
into each decision.  It is best to use an odd number for the depth, because
then there is always a majority vote, never a tie.

How the Grabber works...
Whenever the system is receiving (normally after you've done a successful
sync) - all decoded bits are stored into a large historical archive.  The
size of this archive is 16384 bits, or about 1638 bytes worth.  In other
words, the last 1638 seconds' worth of data should always be available
(at 10 baud).  The frame-grabber logic looks back over this historical
database to "line up" decoded bits corresponding to the same relative
bit position in the repeating message.  When specifying a grab, you may
enter just about any values for runlength and depth, but the product of
these parameters must always be less than or equal to 1638.  For example,
with a run length of 4 bytes, you could use a depth of up to 1638 / 4
or 409 levels.  In this case, each bit decision would be based on the
last 1636 seconds' worth of received data.  Needless to say, if your
message changes regularly, choosing a depth value greater than "the
number of times the message actually repeats before changing" would be
counterproductive.  If you are going to use this scheme to transmit
information, it would be a good idea to keep all messages the same
length.  You can set runlength to 1 byte, and transmit each byte
in your message n times before going on to the next.  There is
no provision in COHERENT for synchronizing the grabber to when
your transmitter starts sending a new byte value, but since all
the decoded bytes appear on the screen, you can probably eyeball
this, as the displayed bytes should converge on a same-value-repeating
near the end of each interval.
Choosing a depth value of 1 (the default) - will only use the
current (most recent) decoded bits, and not take into account any
"back data".

When running BPSK, it is very important to maintain the input frequency
at 800 Hz.  For instance, a frequency error of only 1 Hz will result in
a phase error of 36 degrees over one bit time at 10 baud.  This is
serious, because in differential-mark BPSK any phase shift greater
than plus or minus 90 degrees from one bit to the next is taken as
evidence of a MARK.  Eating into our margins by 36 degrees out of the
90 will degrade the bit error rate appreciably.  And the problem only
gets worse at slower baudrates.  Every effort should be made to keep
the received audio carrier at 800 Hz by external means and not rely on
COHERENT's Autotune system, which has a MINIMUM step of 1 HZ.

When running BPSK, it is a good idea to set the frequency of the crystal
oscillator on the Sigma-Delta board to precisely 1.8432 Mhz.  I have not
played around with this much, but I tried replacing C05 (the 47 pF cap
between pin 11 of the 74HC4060 and ground) - with a 47 pF trimmer cap
in parallel with a 22 pF fixed ceramic.  This seems to work well, and
should permit the 1.8432 Mhz frequency to be trimmed easily.  If you
calibrate your amateur receiver carefully against WWV, you can then
use it to pick up the 1.8432 Mhz signal in the 160 M band, and set the
crystal frequency accordingly.  Oscillator drift on the S-D board should
not be a problem.  Once you set the board right on frequency, you will
be able to use a longer time constant in the autotrack loop, which
should permit copy of BPSK well down in the noise.

What's New in COHERENT - 1995.
------------------------------

Version 3.1 of COHERENT (January '95) - has a line in the Status Window
(the "control panel" at top of screen), allowing it to interface with the
new Max Carter / John West lowfer receiver (converter) board.  This board
will be equally useful for receiving CCW and Coherent BPSK signals.

Instead of using six thumbwheel switches in hardware, the user can
select an operating frequency directly on the computer display.  The PC
running COHERENT downloads the frequency to the board as a serial bit
stream sent to a parallel port (LPT1), which is then clocked into a
24-bit shift register on the receiver/converter board.  The LSB of the
least significant BCD digit is transmitted first.

The user also gets up to 100 memories in which to store the frequencies
and IDents of his favorite lowfer stations.

If you do not yet have one of these new converter boards, just ignore the
Receiver (VFO:) line in COHERENT's status window.

Although a mouse is still not absolutely required, it becomes increasingly
desirable to have one on your system.  With version 3.1, we have changed
the way the mouse is used.  Mouse operation has been standardized so that
it works the same way with all parameters.  We no longer "drag" the mouse
to set parameter values; instead we use a more familiar "point-and-click"
technique.

There is now a rectangular "mouse cursor" that can roam anywhere in the
status window - (after bringing up COHERENT, just move your mouse around
a bit and you'll see it).  All parameters which can be altered using the
mouse now have an asterisk (*) after them.  To change a setting, just
position the mouse cursor directly over the asterisk and click either of
the left or right mouse buttons.  In general, clicking the left button
will increase a value, clicking the right button will decrease it.  Most
of the system switches can also be turned on/off with the mouse now.
If you get bugged by seeing the mouse cursor in the status window, you
can "hide" it by moving it into the position occupied by the least
significant digit of the time-of-day display.  This digit changes once
each second, and if the mouse cursor was there it disappears as soon as
the next second arrives.  Just move the mouse to bring it back.

Using the system with the new Lowfer Receiver/Converter board...
----------------------------------------------------------------

There are 100 "VFO's" available.  For the time being, I am calling them
VFO's instead of memories; if people have trouble with this, maybe it
will change.  These VFO's are numbered from 00 thru 99 inclusive.  Each
VFO can store a frequency for a lowfer station (6 BCD digits, specifying
the frequency down to the 1-Hz resolution level).  The VFO may also have
an optional station IDENT (up to 6 Alphanumeric characters).  The VFO
contents are initially defined with the VFO command, from the main
command menu.  You can enter just the command (VFO) by itself and follow
the prompts for the information required.  After you get to know what
info is requested, you can speed up the process by specifying the
necessary information all on the same line as the VFO command itself.
This follows the same convention as the other commands in COHERENT.
To enter (write) a new station into a VFO memory, you would enter the
command (VFO) followed by the VFO number (between 00 and 99), then the
operating (published) frequency in kilohertz, then the callsign (IDENT)
of the station.  Once stations are written into the VFO memory, they
should stay there even when power is turned off.  COHERENT creates a
special disk file (VFO.TAB) on your hard disk to retain this info.

You may also READ any VFO by typing (in the CMD window) "VFO xx" -where
xx is the number of the VFO you want to select.  Selecting a VFO means
its stored frequency becomes your operating frequency, and both the
frequency and stored IDENT (if any) will be displayed on the Receiver
control line in the status window.

Normally, once all the stations you are interested in have been written
into the VFO memories, you will use the mouse to select the station you
want to listen for, as it is much quicker.  To select a VFO frequency
from memory, place the mouse cursor over the asterisk next to the VFO
number and click up or down as needed to bring the station you want
into the operating register.  This automatically downloads the new
frequency into the converter, as its shift register is updated or
reloaded whenever the operating frequency is changed.

In version 3.1, the AUTOTUNE switch defaults to OFF.  If you click it ON,
whenever AUTOTUNE senses that the received signal deviates from 800.0 Hz
by more than half a Hz, it will send the usual pulse out on the RS232
line as before, but now it will also change the operating frequency shown
on the screen and re-load the shift register via the printer port.  If you
are not using the new Receiver/Converter board, this should be of no
consequence.  You can leave your printer connected to the LPT1 parallel
port without any problems.

It occasionally happens that for whatever reason the lowfer station you
want to receive is not transmitting EXACTLY on his published frequency.
For this, we have made an exception to the "asterisk" rule for the
6-digit operating frequency only.  You may use your mouse to manually
change individual digits of the frequency.  Just position the mouse
cursor over the digit you wish to change and click up (left) or down
(right) buttons to change the receive frequency.  This is just like
using your fingers to change the thumbwheel switch settings if the
switches were implemented in hardware.  Note however that the VFO
contents memorized for this station are NOT altered on disk, and the
very next time you reselect this guy your receiver will revert to his
published frequency.  If you know the station is always operating on
a slightly wrong frequency, you can re-write the frequency info for
that particular station with the VFO command.  Notwithstanding that the
Lowfer band is from 160.000 to 189.999 Khz, we have placed no restric-
tions on the content of the 6 BCD digits downloaded to the converter
board's shift register.  If your converter board's hardware synthesizer
can lock on a frequency outside the lowfer band (e.g. 194.0 Khz) - you
will still be able to enter this frequency from the computer.

The hardware switches for RF-Amp (in/out) and IF-Gain (hi/lo) are also
emulated in software here.  If your converter board supports remote
activation of these switches (seems like a pretty good idea) - then
you will not need to physically install switches for these functions,
you can just use the computer "control panel" to operate them.  These
switches have been assigned unique control bits in the parallel port
connector.  Changing the IF-gain or switching IN/OUT the RF-Amp will
NOT reload the shift register - the shift register is only reloaded
when the operating frequency changes.

Here are the bit assignments in the LPT1 parallel port connector
  (LPT1 is assumed to be on address $378).
PIN
 2  bit 0 - A high here turns the RF-Amp ON.
 3  bit 1 - A high here sets the IF-Gain to HI.
 4  bit 2 - Shift register clock (data bit clocked in on rising edge)
 5  bit 3 - Data bit for shift register (clocked by bit 3)
 6  bit 4 - STROBE signal for shift register. Goes low while changing
		 contents to avoid garbaging shift register outputs.
 7  bit 5 - PTT (goes high when transmitting non-idle characters)
 8  bit 6 - RTS=PHASE-MODULATE, goes high while mode=BPSK,PSK,PSKL.

Pins 18-25 of this connector are supposed to be digital grounds.
Same pin numbers appear on the printer-end of a standard IBM cable,
except ground wires are on 19..30.  This output port is TTL-level,
so you will need level-shifters to go to the +/- 7.5-volt signals used
by the converter board.  Some people recommend inserting opto-isolators
into the path to eliminate any direct connection between receiver ground
and computer ground.  This circuitry may already be included on your
Receiver/Converter board  If you go this route, you should also couple the
analog signal to the sigma-delta board with a small audio transformer.

Changes in v3.2	(Feb. 5th, 1995)
--------------------------------
1.  The command window is now cleared after the command is done.
2.  The STROBE line (bit 4 of parallel port), goes high for a short
time after new frequency is shifted in, to load the shift register outputs.
Then it goes low and stays low until the frequency needs to be changed.
This is to reduce chance of noise clocking unwanted bits into the shift
register, inadvertently changing the operating frequency.
3.  It has been pointed out that there was no way to change the setting
of the TC (filter time constant) parameter without a mouse.  You may
now use the "PageUP" and "PageDN" keys to adjust this parameter in lieu
of with the mouse.

Changes in v3.3 (October 1995)
------------------------------
Only change is the MS50 parameter is now accepted on the command line when
program is invoked.  MS50 specifies 50 milliseconds per signaling element
(default is still the old standard 100 msec).   Using MS50, the CCW speed
works out to 24.0 words per minute, and the BPSK speed is 2 chars per sec.

Changes in v3.4 (October 1995)
------------------------------
A slight improvement in the program's ability to copy differential BPSK
signals under poor conditions.  In any PSK mode, the effect of minor
mistuning can be horrendous.  Yes, the program has the means to keep a
signal tuned in to within more or less half a Hertz, but there are some
problems with the technique used.  First of all, you need a radio that can
tune in 1-Hz steps.  Secondly, whenever the program issues a pulse to go
up or down a Hz, most radios will go completely crazy for a short time as
their synthesizer's PLLs try to stabilize after a step change in freq.
This is murder on the phase accuracy of our received 800-Hz PSK tone,
and there is a real tendency to lose data for a few bits after any step
change in freq.  What I have been looking at in v3.4 is some way to correct
the phase error that must inevitably arise over any two consecutive bit
times purely as a result of the residual [< 1Hz] frequency offset between
transmitter and receiver.  Let us consider a frequency error of just
one Hertz, which can occur easily in practice.  Let's say the received
tone is actually at 801.0 Hz instead of 800.0 Hz.  At standard MS100 rate,
over a 10-bit ASCII character (one second to receive) - the phase angle
will advance by 360 degrees!  This is 36 degrees every bit time, totally
due to frequency offset, even if there were no PSK modulation on the
carrier whatsoever!  Each bit time the demodulator asks, "was this phase
the same as that during the previous bit time?"  The question is answered
by comparing the current measured phase with one stored from the previous
bit, and if the two angles differ by more than +/- 90 degrees, we deem a
transition to have occurred.  In the presence of noise it becomes
increasingly difficult to measure these phase angles accurately and if we
don't know for sure what the phase angles are we wind up having to guess
whether the phase is the same as last time or not.  It's like using a
balance with two pans - we put all the information that's available onto the
scale and it tips one way or the other.  Obviously if one of the pans has
something extra on it that does not depend on the data we are trying to
decode, it will introduce an arbitrary bias into our guesses, causing us to
make more errors than otherwise.  Another way of looking at this is to see
that the received signal energy must be strong enough to overcome the
built-in bias and tilt the pans the right way in spite of it, or we'll
surely get garbage copy as soon as the signal fades to nearly the same
strength as the background noise.

So I looked for a way to cancel out this error, to even up the scales once
again.  My basic assumption was that the frequency error will be more or
less constant, at least over the short term.  It is likely to arise because
of calibration errors in various crystal oscillators: transmitter carrier,
receiver L.O., Sigma-Delta board sampling rate.  Even if these oscillators
aren't perfectly on frequency, over a short term (a second or so) - the
resulting beat frequency is probably going to remain pretty much the same.
Any error in frequency will translate into an error in phase as soon as
some time passes.  And the phase error keeps getting worse as more and
more time passes.  In COHERENT v3.4, we first remove the phase modulation
(put on intentionally at the transmitter) by taking the measured angle modulo
180 degrees at the end of each bit time.  Then we fit a least-squares
regression line over the last eight (8) measured phase angles.  The slope of
this regression line tells us how many degrees per bit time (100 msec at
the standard rate) our measured phase can be EXPECTED to advance (or retard
if the slope is negative) solely on account of mis-tuning.  Fitting the line
with the least squares technique tends to remove most of the jitter in the
individual samples and gives us the best possible estimate of the drift
value based on available information.  We could fit over more than the last
8 bits to get an even better answer, but then we may begin to challenge our
assumption that the frequency offset is unchanging.  Computationally it is
easier just to average the phase advances over the last 8 bits, but the
regression line method does a better job of rejecting the noise error
contributions of individual measurements.  The regression analysis is
performed at the end of each bit time.  The cost is one extra multiply for
every two historical samples processed plus an extra divide and some minor
housekeeping.  Once we know with considerable accuracy how much that pesky
bias is going to be, we simply add the same amount to the opposite pan of
our balance in order to cancel it out.  Neat, eh?

V3.4 can be thought of as the weak signal version of COHERENT.  It does a
a lot more calculation than previous versions for a small improvement in
weak signal performance.  It may not run on 286 computers -  we'll just
have to see.  Don't throw away your older versions of the program until
you're sure your computer can handle the added workload.  This whole affair
is a prelude to supporting straight PSK (which carries a 3 dB advantage
over differential PSK).  To decode PSK properly it is essential to have
an absolutely reliable reference phase, and this is what the above math
exercise gets for us.

You might notice there is an extra parameter displayed at the top of the
screen now.  It is labelled with Greek letters delta, phi.  It is the
value of the regression line slope: the (signed) number of degrees that
the measured phase angle was found to have advanced during each bit time.
Needless to say, the optimum value is 0.0 - anything over +/- 20.0 degrees
indicates a level of deterioration demanding attention from the operator.
This is a more accurate indicator of frequency error than the 800.0 Hz
freq measurement that appears elsewhere at the top of the screen.  A
phase advance of +1.0 degree per bit time (at MS100) means we are receiving
a frequency which is 0.028 Hz high of nominal, or 800.028 Hz.  For even
more resolution go to MS300 and each degree of error per bit time then
works out to around 9.26 milli-Hertz of offset.  Since the phase error
is reported to the nearest tenth of a degree, if everything is stable as
a rock this indicator is fine enough to tune an 800 Hz carrier to within
one milli-Hertz.

Changes in v3.5 (October 1995)
------------------------------
The PSK command line parameter is accepted.
PSK is straight Phase-Shift-Keying, not Differential PSK (our "BPSK").
PSK carries a 3 dB advantage over BPSK in theory.
Do not use PSK unless your timebases are rock-stable.
On transmit, PSK-SPACE = RTS line unasserted, PSK-MARK = RTS asserted.
Note that SYNC command tests all bits in character (0-9) PLUS all of them
again but with inverted (i) phase.  Since PSK is an absolute reference
phase system, we have no way to know which of the 2 phases we are receiving
stands for SPACE and which stands for MARK.  SYNC will try all the ways
and report the best fit, but you may need to manually sync for certain
bit patterns.  Before doing a SYNC you should make sure the AUTOTRACK
system has locked onto the keying waveform and is recovering the clock
properly.  If you like you can assist this manually by adjusting the CYCLE
count until Space and Mark amplitudes are more or less equal.  This was
always true, applies for both PSK and BPSK, but is more important in PSK.

The angle shown under the heading phi (just below the delta-phi) is our
synthesized reference phase in degrees.  If everything is absolutely
stable it should not change.  If there is a slight tuning error, it can
be expected to vary slowly between 0 and 179.9 degrees.

With v3.4 and higher, when COHERENT comes up it looks for a disk file
called divisor.clk.  If it exists, this file must contain one line of
ASCII text, namely a number between 59600 and 60000.  The nominal value
is 59659, which is used if COHERENT can't find the divisor.clk file.
See writeup: CLOCKSET.TXT for an explanation of this parameter.

Changes in v4.0 (October 1995)
------------------------------

Ok, this is the BIG one!   With Version 4.0, COHERENT adds an exotic
new mode: PSKL.  This is straight PSK as far as the physical interface is
concerned, but the transmitted data format is changed to take advantage
of a lattice coding technique.  This is what you use for DEEP FRINGE work.
The lattice system sends more bits than we would need to represent the
128 ASCII characters, but there is a big advantage: corrupting data bits
in transmission does not usually corrupt the text printed on the screen.
Lattice is not an error-correcting system, it is an error-tolerant system.
This version of COHERENT starts nice and easy: we are not using (yet) the
full-blown Leech lattice which has 24-bit frames.  Instead we use a 16-bit
frame for each ASCII character.  Instead of taking 10 bit times to send
a character, we now take 16, so the data rate is a little slower than
before, but the performance improvement under rough copy conditions will
be amazing.  I have been running some Monte Carlo simulations of this
system with various values of p (probability of bit-error).  The results
are astonishing.  For example, with the old PSK, if p = 0.05 (one bit in
20 gets corrupted on the average) - about 1 in every 3 characters appearing
on the screen will be junk.  The message might very well be unreadable,
depending how good a guesser you are.  But with the lattice (PSKL) method,
the SAME physical bit error rate will screw up only 1 in 30 displayed
characters, the other 29 will be perfect!  Things get much better as the
value of p decreases: at p=0.02 for example, the old method junked about
1 in every 6.7 characters on the average; with PSKL this drops to only
1 in 500!  That's about a 75-fold reduction in the message error rate,
with a speed penalty of only 1.6.  In terms of SNR, this lattice coding
scheme lets us work about 4 dB deeper into the noise before degrading
the message integrity.  Well worth it, I'd say.

Technical details: I will be writing an article on this new method
because I believe it has not previously been used in amateur radio.  For
now, all you need know is that of the 65,536 possible values a 16-bit
frame can have, we select (very carefully) some 128 of them such that
each of those 128 is as different as we can make it from the other 127.
The receiver uses a maximum-likelihood decoder (we compare the received
frame to all possible valid frames and choose the one that is the closest
match).  The PSK/BPSK formats both use a start bit and 2 stop bits in
order to facilitate automatic character synchronization.  In PSKL this
was abandoned in favor of a more sophisticated correlator: the decoder
tries all possible rotations of the 16-bit frames and settles on that
particular framing which minimizes the "distance" between the incoming
bitstream and the table of valid lattice values.  We eliminate those 3 bits
which did not carry any information in the old system anyway.  But there
is a slight hitch: by definition there is manyfold symmetry in the lattice
set we have chosen, so the automatic SYNC cannot resolve whether the data
should be inverted or not.  It easily determines which of the 16 possible
startbit phases is correct, but then it's a coin toss whether to use inverted
or non-inverted.  You must look at the message stream after returning
from sync and if it looks crazy, press the middle mouse button once to
invert the whole thing.  That should clean it up.  If your mouse does not
have 3 buttons, you can step through 16 startbit phases till you come back
to the same phase found by automatic sync, but using the middle button if
you have it will be much faster.  Oops!  If your message consists of the
same character sent over and over the PSKL Sync has a chance of settling
on the wrong phase.  This doesn't happen if the message you are synching
on has some variety in it, containing several different letters.  Moral:
when choosing an ID for your PSKL beacon use 3 or 4 different letters.
The longer a stream of random letters before the message repeats, the
better PSKL Sync will work.

COHERENT v4.2 notes.
--------------------
The only intended change was to install a "buffer empty" indicator
for WB6RIJ, although there may be some unintended changes, hi!
Please let me know of any problems that surface.

The parallel port, LPT1, 3F8h, was used already for downloading the freq
to the shift register on the MAX800 board.  Not all the bits were used.

Bit 5 (which is pin 7 on the DB25 connector for the parallel port) will go
high whenever there are non-idle characters being sent in BPSK, PSK, PSKL
modes and whenever there is Morse Code being sent in the CCW mode.

We can call this signal "PTT" for convenience.

The parallel port connector should have TTL ground on pins 18..25.
Some printer ports are CMOS, which give nice clean 0 or 5 volt signals,
some are not.  You will have to check your parallel port for this.

Note that COHERENT is a full-duplex system.  Normally it expects to be sending
and receiving at the same time.  The bit 5 "PTT" signal is provided only
as an aid if you really must switch external equipment between transmit
and receive.

Note also: PTT goes true the instant a Morse Code character starts being
sent, or the instant the START bit appears in BPSK, PSK, or the instant
the first bit of a PSKL frame starts to go out.  There is no built-in
delay to let the XMTR come up before we start sending out non-idle chars.
If this will be a problem (probably will) - then the first character you
send should be a spacer (space bar or something like that which is not
crucial for understanding the message).  I.e. send junk for first second
until xmtr gets up to speed.  The PTT signal should go low as soon as the
last bit of the last character has been sent.  I hope I didn't cut it short.
This should be ok because a transmitter won't shut down instantly anyway,
so you should have enough time to finish sending the last bit.

The PTT signal works just like a VOX on a radio.  It may clip the first part
of the first syllable, but it usually hangs in there long enough to get the
last part of the last syllable.

Note also: COHERENT will continue to key BPSK, PSK, PSKL idle characters
on the RTS line even while PTT is false.  I don't know what will happen
to the receiver if it is unable to track these characters.  Those idle
characters are in BPSK, PSK, PSKL modes for a reason: the receiver uses
them to "keep time" to keep track of where it is in the framing cycle, and
to track the keying windows (autotrack ON).  Without anything coming in,
COHERENT's tracking loops will drift, and it will probably be necessary
to re-establish lock on the keying waveform and maybe also the STARTBIT
phase.  Of course, if everything is rock solid stable and does not drift
during a period when no characters are being received to track, then
it should come back up still in sync even after a prolonged outage, but
this is a long shot, really.  Bottom line here is that for the tracking
loops to work properly the program must receive continuous Morse in CCW
mode or continuous frames in BPSK, PSK, PSKL modes.  If you aren't going
to allow this, then you must provide external stabilization - locking
everything to WWV would work, e.g.

COHERENT v4.3 notes
-------------------
Most changes in 4.3 should be transparent to the user; they relate to
making the system more robust.

It has been observed that it was all too easy to lose sync and start printing
garbage on the screen, especially in PSK and PSKL modes.  This has been
traced to 8250 UART overruns and also to multitasking overruns internal to
COHERENT.

As far as I can see, ALL UART overruns are caused by typing on the keyboard.
You can do almost anything you want in DOS (including disk transfers!)
without causing an overrun, but just hit a key and bingo - perhaps one in
10 keystrokes will produce a UART overrun.  And these overruns are very
hard on us: each missed sample introduces a 40-degree phase shift in
everything that follows.  A missed sample is much more serious in PSK and
PSKL modes because we are deciding each bit based on its absolute phase, not
based on whether or not it changed by 180 degrees compared to the last bit.
It takes 8 bit times before such an overrun washes through the least squares
algorithm which calculates the reference phase.  As of this writing, I still
have no fix for this; apparently the BIOS must disable interrupts for quite
a long time while it scans all the keys on the keyboard to see which one was
hit; a faster computer might be able to get away with it without ever causing
any overruns.  I know my 386 lets me get away with a lot more keystrokes
before an overrun occurs (on the average) than my XT!  I will keep looking
into this; maybe I can rewrite the BIOS keyboard scan routine - but if there
is some hardware reason why the interrupts MUST be disabled (like a one-shot
in the keyboard timing out, maybe) - then there won't be much I can do about
it.  If you have one of those newer serial ports with the 16-byte FIFO built
in, there will never be any problems with overruns.

For now, I have added a red warning message OVERRUN! at top of screen in same
place the CLIPPING message appears.  So you will see a red flash whenever
an overrun occurs.  There is no easy way to be certain that we missed only
one sample, not two or three.  I am assuming we lose only one sample.  The
overruns are counted and displayed on the third line of the STAT screen in
the ORs: field (next to the TC field).  If you get overruns when you are not
typing on the keyboard, then your computer is either doing something in the
background you are not aware of (like a TSR for example) - or you need a
faster machine to run COHERENT!

The other thing I noticed was that apart from overruns, if I typed too fast
the COHERENT calculations could not be completed in time before the next bit
came in.  AT MS50 all calculations (and there are lots to do, including
updating all the stats on the top of the screen, etc) MUST be finished in
less than 50 milliseconds or else real big trouble!  For example, if I
save a buffer to disk, the disk transfer takes much more than 50 msec, and
screws things up every time.  Also, just typing very fast was enough to
overload the program; the program must look at every keystroke and decide
what to do with it - if I typed very fast there were not enough cycles left
over in each 50 msec timeslot to complete all the DSP calculations before
the next bit came along.

I think I have now solved this one.  I built in a 32-level FIFO to hold all
the accumulators (there are 27 of them) that must be processed each bit time.
So even if the program is busy doing something lengthy like a disk transfer
and it gets behind, it can still catch up again after the transfer providing
the extent of the FIFO (1.6 seconds' worth of data at MS50) isn't exceeded.
This seems to work well.  I can now do disk transfers without losing any
data.  Which is nice, because it opens up the possibility of logging incoming
messages to disk....

You will notice there is an extra clickable ON/OFF switch at lower right
corner of stat window called TRACE.  When TRACE is turned on, all received
characters (BPSK, PSK, PSKL) are logged to disk for later viewing.  In CCW
mode this is moot as we do not decode Morse code soundings.
Trace can be turned on and off any number of times in a session,
and each time trace is turned on a new file will be created.  The trace
files are named, "TRACE.xxx"  where xxx is a number that increments with
each new filename.  Be sure to delete trace.* after you have finished with
them or they will mount up. I see that SOMETIMES clicking on the TRACE
switch will cause a UART overrun.  This is when files are opened, etc, and
evidently DOS turns interrupts off for a while.  I have yet to see any
actual loss of data recovery due to this overrun, so hopefully we can live
with it.  If your computer is faster than mine and your hard disk is well
tuned, probably you won't see any overrun from this disk activity.  If it
causes loss of sync, then don't use trace.  Or try tracing to RAM-disk.

Oh yes.  I have found that the automatic SYNC in PSKL is a whole lot more
finicky than at first believed.  It looks like a 4-way ambiguity will be
common.  After sync, if text is crazy, use mouse middle button to invert.
If still crazy, advance startbit phase thru 8 steps.  If still crazy, use
the middle mouse button again.  One of these 4 possibilities should hit.
(Famous last words, hi!)

COHERENT v4.4 notes
-------------------

Good news, folks.  Finally I figured out how to beat those keyboard-caused
UART overruns!  At least on my 386 it works fine.  I went into the 8259A
PIC on the motherboard and reprogrammed the interrupt priorities so that
com port interrupt IRQ3 or IRQ4 (whichever one we want to use) will have the
highest priority.  Usually the keyboard (IRQ1) has higher priority.  Not
any more, hi!  Now I can type as much as I like, use the arrow keys instead
of the mouse, etc. etc. with not one overrun.  Yes I did remember to put
things back the way I found them when COHERENT exits and has finished with
the interrupt system so DOS won't get too upset.  As far as I can see though,
DOS can continue to run just fine with its interrupt priorities rearranged -
but it might be important for some programs so I restore IRQ0 to highest
priority just before exiting.

Version 4.7
-----------

Bit 6 in the parallel port goes high to indicate BPSK,PSK,PSKL modes.

Bit 5 (the PTT bit) is now conditioned by command line parameter: CURRY.
With the CURRY param set, PTT is inhibited while in CCW mode.

Version 4.8
-----------

Only change is addition of TRACE command to turn trace mode on and off
when there is no mouse on a system.

VE2IQ, Jan 21st, 1997.
-----------------------------------------------------------------------
