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 . 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 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) 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. VE2IQ, Nov. 11th 1995 -----------------------------------------------------------------------