It was late in the evening as I sat on the bed. All lights were off, and the room was nearly dark with only a small digital clock glowing. My wife was already retired under covers when suddenly the house shook as if a mortar shell went off. At the very same moment, I was blinded by a flash of intense white light. And, the sound was deafening. Oh, no! A lightning strike! At our house! My heart sank and then raced. Our house electronics… MY HAM STATION! Is it all toast? Is anything on fire? I raced from the bedroom, glancing into other rooms as I made my way to the living room. No smoke. I clicked on the TV. It came on, fine. Then, Internet-based streaming services came to life. Good. Our Internet connection is live. That’s positive. I made my way down into the lower level of the house, into my radio shack. Because there was a storm approaching, I had already disconnected the antenna coax to my HF (shortwave) antenna system. I had played it safe. But, I was concerned about any damage through the power line--damage to my computer. I could see right away that my computer was still up and running. Both monitors had screen saver images. Good. Things looked like they were okay. I went back to bed, thinking that everything was fine. I did not want to test my radio, because, first, why? It was disconnected from the antenna. Second, why connected it back up to the antenna while there’s still a storm raging? The next morning, after the storm had passed, I did go back to the radio room, and I hooked up the antenna. Turning on the radio, I also fired up the Ham Radio Deluxe program so I could check things out. The radio did not respond. The radio did not show up as available for the software. The USB-Communications bridge also did not show up in the devices. Bad sign. Long story short: I discovered that the uninterruptable power supply and its battery were shot. And, the USB interface and Icom radio control interface both blown. And, the transceiver? Yes, that too was blown. Five electronic components of my radio setup for HF no longer functioned: My station was dead. I filed an insurance claim, having a rider on my homeowner's insurance policy. They did their investigating and estimating and what not. After I paid a hefty deductible, and scraped together a bit more than they offered to cover the loss, I obtained a new transceiver. Because the new rig had built-in USB ports with sound card technology, I did not need to replace the USB interface hardware. And, I have re-worked how I power the radio so that I can disconnect easily during a storm. Enter the story, a repacked Icom IC-7610! My radio room is starting to look like a station, again. I've successfully paired my new Icom IC-7610 with Win4IcomSuite and HRD/DM780. I'm adding more, from various different areas of interest, like WSJT software, and so on. In the short while that I’ve had to operate this rig, I’ve become highly impressed and quite pleased! What a radio! One of the most useful (and, to me, amazing) features of this Icom IC-7610, is the IP+ function, which, when turned on, improves the Intermodulation Distortion (IMD) quality by optimizing the direct sampling system performance. This function optimizes the Analog/Digital Converter (ADC) against distortion when you receive a strong input signal. It also improves the Third-order Intercept Point (IP3) while minimizing the reduction of the receiver sensitivity. In short: I was listening to an s-0 (i.e., no strength-meter movement) weak signal of a DX station, when right adjacent to the frequency came an s-7 signal, wiping out my ability to copy that weak signal. I turned on the IP+ and the distortion of the adjacent signal disappeared, and once again, I heard the weak signal IN THE CLEAR! WOW! See it in action: The following video is a quick capture of my running the Olivia Digital Mode on HF, on the 30-Meter band. The transmissions are of a two-way Olivia digital-mode radio conversation between station K8CJM and station NW7US on 12 November 2019 (UTC date). K8CJM is located in Dayton, Ohio, and I am located in Lincoln, Nebraska. I’m running the radio at full power. The radio is rated as being able to handle a 100% duty cycle at full power. The radio ran cool, with no significant heating. Compression and ALC!? Some have noted that it appears that I’ve left on the compression of the transmitted audio. However, the truth is that compression was not being used (as is proof by carefully taking note of the zero meter movement of the Compression activity). I had the radio set for 20-Meter USB operation on the Sub VFO. Compression was set for standard USB operation. Note also that the radio was transmitting USB-D1, which means the first data/soundcard input to the radio. Also, some people complain about my use of ALC, because, in their view, ALC (automatic level control) is a no-no for data modes. The notion that one must NEVER use ALC when transmitting digital modes is not accurate. Multi-frequency shift keyed (MFSK) modes with low symbol rate–such as the Olivia digital modes–use a single carrier of constant amplitude, which is stepped (between 4, 8, 16 or 32 tone frequencies respectively) in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier (including a transmitter’s final stage) linearity requirements are necessary. Whether the use of ALC matters or not depends on the transmitted digital mode. For example, FSK (Frequency-Shift Keying; i.e., RTTY) is a constant-amplitude mode (frequency shift only). In such a case, the use of ALC will NOT distort the signal waveform. PSK31 does contain amplitude shifts, as an example, therefore you don’t want any ALC action that could result in distortion of the amplitude changes in the waveform. On the other hand, the WSJT manual says that its output is a constant-amplitude signal, meaning that good linearity is not necessary. In that case, the use of ALC will NOT distort the transmitted signal-amplitude waveform. You can use ALC or not, as you choose when you run WSJT modes, or Olivia (MFSK). Clarification Nowhere in this am I advocating running your audio really high, thinking that the ALC will take care of it. I am not saying that. I am saying that some ALC is not going to be an issue. You MUST not overdrive any part of the audio chain going into the transmitter! Transmit audio out of the sound card remains at a constant amplitude, so there will be no significant change in power output if you adjust your input into the radio so that the ALC just stops moving the meter, or, you can have some ALC meter movement. You can adjust your audio to the transmitter either way. If the transmitter filters have a significant degree of ripple in the passband then you may find that RF power output changes with the selected frequency in the waterfall when there is no ALC action. Allowing some ALC action can permit the ALC to act as an automatic gain adjustment to keep the output power level as you change frequencies. Linear and Non-Linear Regarding linear and non-linear operation (amplifiers, final stages): While a Class-C amplifier circuit has far higher efficiency than a linear circuit, a Class-C amplifier is not linear and is only suitable for the amplification of constant-envelope signals. Such signals include FM, FSK, MFSK, and CW (Morse code). If Joe Taylor’s various modes (in WSJT software) are constant-envelope signals, than class-C works, right? At least, in theory. Some Additional Cool History The digital mode, Thor, came out of DominoEX when FEC was added. Here is an interesting history of FSQ that seems to confirm that FSQ is like MFSK, so no problem with a bit of ALC. The following is from https://www.qsl.net/zl1bpu/MFSK/FSQweb.htm History – Let’s review the general history of Amateur MFSK modes. The first Amateur MFSK mode developed anywhere was MFSK16, specified by Murray Greenman ZL1BPU, then first developed and coded by Nino Porcino IZ8BLY in 1999. Before MFSK16 arrived, long-distance (DX) QSOs using digital modes were very unreliable: reliant, as they were, on RTTY and later PSK31. MFSK16 changed all that, using 16 tones and strong error correction. Great for long path DX, but nobody could ever say it was easy to use, never mind slick (quick and agile)! Over the next few years, many MFSK modes appeared, in fact too many! Most of these were aimed at improving performance on bands with QRM. Most used very strong error correction, some types a poor match for MFSK, and these were very clumsy in QSO, because of long delays. The next major development, aimed at easy QSOs with a slick turnaround, was DominoEX, designed by Murray Greenman ZL1BPU and coded by Con Wassilieff ZL2AFP, which was released in 2009. Rather than using error correction as a brute-force approach, DominoEX was based on sound research and achieved its performance through carefully crafted modulation techniques that required no error correction. The result was a simpler, easier to tune, easily identified mode with a fast turn-around. DominoEX is widely used and available in many software packages. A later development by Patrick F6CTE and then Dave W1HKJ added FEC to this mode (THOR) but did not add greatly to performance, and at the same time eroded the fast turn-around. The final DominoEX- related development was EXChat, a version of DominoEX designed specifically for text-message style chatting. While completely compatible with DominoEx, it operates in ‘Sentence Mode’, sending each short over when the operator presses ENTER. EXChat was developed by Con ZL2AFP and released in 2014. Back in 2013, Con ZL2AFP developed an MFSK mode for LF and MF which used an unusual decoding method pioneered by Alberto I2PHD: a ‘syncless’ decoder, which used a voting system to decide when one tone finished and another began. The first use of this idea was in JASON (2002), which proved to be very sensitive, but very slow, partly because it was based on the ASCII alphabet. The new mode, WSQ2 (Weak Signal QSO, 2 baud) combined the syncless decoder with more tones, 33 in total, and an alphabet specially developed by Murray ZL1BPU, which could send each lower case letter (and common punctuation) in just one symbol, resulting in a very sensitive (-30 dB SNR) mode with a 5 WPM typing speed. In the subsequent discussion in late 2014, between the developers ZL2AFP and ZL1BPU, it was realized that if the computer had enough processing power to handle it, WSQ2 could be ‘sped up’ to become a useful HF chat mode. This required a large amount of development and retuning of the software to achieve adequate speed was involved, along with much ionospheric simulator and on-air testing used to select the most appropriate parameters. Tests proved that the idea not only worked well, but it also had marked advantages over existing HF MFSK modes, even DominoEX. As expected, the new mode was found to have superior tolerance of signal timing variation, typically caused by multi-path reception, and would also receive with no change of settings over a wide range of signaling speeds. So this is how FSQ came about. It uses the highly efficient WSQ character alphabet, IFK+ coding, the same number of tones as WSQ (33), but runs a whole lot faster, up to 60 WPM, and uses different tone spacing. The symbol rate (signaling speed) is modest (six tones per second or less), but each individual tone transmitted carries a surprising amount of information, resulting in a high text transmission speed. And it operates in ‘Chat’ (sentence) mode, which allows the user to type as fast as possible since they type only while receiving. The ability to send messages and commands selectively has opened a huge array of communications possibilities. What Makes FSQ Different Incremental Keying – FSQ uses Offset Incremental Frequency Keying (IFK+), a type of differential Multi-Frequency Shift Keying (MFSK) with properties that make it moderately drift-proof and easy to tune. IFK+ also has excellent tolerance of multi-path reception. IFK was developed by Steve Olney VK2XV. IFK+ (with code rotation) was proposed by Murray Greenman ZL1BPU and first used in DominoEX. IFK+ prevents repeated same tones without complex coding and provides improved rejection of propagation-related inter-symbol interference. In the context of sync-less decoding, the IFK+ code rotation also prevents repeated identical tones, which could not have been detected by this method. Efficient Alphabet – In FSQ, a relatively high typing speed at a modest baud rate comes about because the alphabet coding is very efficient. All lower case letters and the most common punctuation can be sent in just one symbol and all other characters (the total alphabet contains 104 characters) in just two symbols. (The alphabet is listed below). This is a simple example of a Varicode, where it takes less time to send the more common characters. The character rate is close to six per second (60 WPM), the same as RTTY, but at only 1/8th of the baud rate. (RTTY has only one bit of information per symbol, 7.5 symbols per character, and wastes a third of its information on synchronization, and despite this, works poorly on HF). No Sync – Another important factor in the design of FSQ is that no synchronizing process is required to locate and decode the received characters. Lack of sync means that reception is much less influenced by propagation timing changes that affect almost all other modes since timing is quite unimportant to FSQ; it almost completely eliminates impulse noise disruption, and it also contributes to very fast acquisition of the signal (decoding reliably within one symbol of the start of reception). Fast acquisition removes the need for the addition of extra idle characters at the start of transmission, and this leads to a very slick system. Add high resistance to QRM and QRN, thanks to the low baud rate, and you have a system so robust that it does not need error correction. Cool! See you on the air... with Olivia!