Latest COHERENT uses Lattice Coding ----------------------------------- First you improve the transmitter. Make sure you're putting exactly 1 watt DC into the most efficient final you can build. Use a 50-foot vertical with an enormous top-hat. Get the losses in your loading coil down to the absolute minimum: a Litz wire basket of just the right dimensions for the highest possible Q. And run hundreds of ground radials all over the place. Next you improve the receiver to the hilt. Wring every last ounce of per- formance out of it. Good. So you've done everything humanly possible at the hardware level and still you can't communicate with your friend who lives just a shade too far away for reliable copy? Well, don't give up yet. Have you tried BPSK? If you've got the time, the frequency stability and a computer at each end of the link, BPSK easily beats ordinary Morse code and will give you a few more miles of range. Still not making it? Then try PSK (another 3 dB over the differential BPSK in theory) or even PSKL. What is PSKL? ------------- PSKL = Phase-Shift-Keying-Lattice coding. The BPSK mode used traditionally on the lowfer band employs a 7-bit ASCII code with one start bit and two stop bits, for a total of 10 bits per character. At 100 milliseconds per bit this means each character takes one second (exactly) to send. There are 128 possible ASCII characters and a group of 7 binary bits has 2-to-the-power-7, or 128 possible patterns. Each key on your keyboard is assigned a code and the character is trans- mitted as some specific pattern of those 7 data bits. But if even one of those seven bits gets changed during transmission the receiver will display on the screen a different character from the one that was transmitted. Let's talk probabilities. Say the probability of any given bit getting corrupted is p. This is called the "bit error rate" by some people. By "corrupted" I mean changed - either from a 0 to a 1, or vice versa. Then the probability of a bit's NOT getting corrupted will be 1-p. (It's either corrupted or it isn't!) To receive an entire ASCII character without error we need to get all 7 of its data bits right. The probability of this is (1-p)^7 : in other words (1-p) raised to the 7th power. Talking concrete numbers, if p=0.05 (one bit in 20 on the average gets corrupted), then 1-p = 0.95 and (1-p)^7 = 0.698, which is the probability of receiving any particular ASCII character correctly. This means our character error rate (pc) is only (1.0 - 0.698) = 0.302. Wow! About one in every three received characters will be garbage even though our bit error rate was only 0.05. Even if reception is pretty good, every time a static crash comes along there is an excellent chance of corrupting at least one bit, and this can easily render the message unreadable, as we are only transmitting one character per second. What can we do about this? Well, all sorts of interesting things. We could try transmitting the same message three times, then use voting at the receiver. Example: if one position in the message showed A on the first pass, then X on the second, then A again on the third it would be reasonable to assume A was the character actually sent. This is basically how the "frame grabber" feature works in the COHERENT receive software. In our example, the probability of receiving at least two of the three characters correctly would be: 1 - 3.pc^2 + 2.pc^3, or 0.781. This is an improvement over 0.698 to be sure, but nothing to write home about after considering the price we had to pay: taking three times as long to send the same basic intelligence (which means we used three times as much transmitter energy) to improve the character error rate from one-in-three to one-in-five approximately. The general idea is useful though: we can trade off transmission speed to get an improvement in our ability to decode the message correctly. It turns out there are more intelligent ways to do this than just shouting the same thing over and over until it starts to sink in. We pointed out above that each of the 128 possible ASCII characters needs 7 binary bits to represent it, and that if one or more of these bits gets corrupted during transmission the whole character is lost. Is there any way to make the system less vulnerable to occasional hits from static crashes? You bet there is! Enter the lattice coding scheme. Say we transmit a 16-bit "frame" for each character instead of the 10-bit frame formerly used. Not hard to see it will take 1.6 seconds to send each character instead of 1.0 seconds. What can we buy with this? A 16-bit frame has 2^16 or 65,536 possible values. We only need 128 unique codes to transmit the ASCII character set. So we have to select a subset of 128 codes from the 65,536 available. But just which 128 to use? Ah, that is one very tough question. We want to find 128 symbols which are as different from one another as possible so that when the receiver gets one it will be easy to recognize, and there won't be much chance of confusing it with some other. Your author spent a lot of time on this and finally came up with a certain set of 128 codewords with the amazing property that if you pick out any two at random, you will find that they differ from each other in at least six (6) bit positions. There are over eight thousand possible pairings so if you want to check them out yourself to make sure I haven't slipped up somewhere, go to it. At the receiver we use a "maximum-likelihood" decoder to translate each received 16-bit frame back into its ASCII value. Essentially the receiver searches a pre-stored list of the 128 possible codewords and chooses the one which is closest to the received frame in the least squares sense. The program does an exclusive-or of the received frame with each codeword, then counts the number of 1's (representing bits which differ in those two words). After all codewords have been compared, the receiver selects the one having the minimum number of different bits. If two or more codewords are equally likely choices, the receiver tosses a coin. Now look at this: if one (1) of the 16 bits in our frame gets corrupted or even two (2) bits in the same frame get corrupted: no problem! We nontheless decode the right character. Even if three (3) bits get corrupted there is still a pretty good chance we will decode the character correctly. And it doesn't matter which bits get corrupted either, lattice can tolerate hits anywhere in the frame. What does this do for our character error rate? Using the lattice coding scheme in our example above with p=0.05 reduces the character error rate from 0.302 to 0.030. Instead of one in every 3.3 characters getting clobbered the error rate drops to only one in every 33! I like these numbers. We get a character error rate which is ten times lower while having to spend only 1.6 times as much energy. The improvements for lower bit error rates are even more astonishing. For example, at p=0.02, lattice reduces the character error rate from one in every 7.5 characters to one error in every 500! For bit error rates less than p=0.02, the lattice coding scheme will yield essentially perfect copy. And now for the best part... You don't have to go outside in the cold to work on your antenna to get these improvements. The latest version of COHERENT has the lattice (PSKL) mode built in. VE2IQ November 1995.