AmateurRadio.com

Wow. 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!

This 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 100% duty cycle at full power. The radio ran cool, no significant heating.

A few months ago, a lightning strike took out my ham radio station. The antenna was NOT connected, but I did not unplug the power supply chain and my computer from the wall. The surge came in through the power mains, and fried my uninterruptable power supply, the interfaces between my PC and radio, and fried the radio. Thankfully, all of that was covered by my homeowner’s insurance policy, less the steep deductible. My insurance covered all of the blown items, and that provided me this chance to obtain a repack version of the Icom IC-7610. I bought an extended four-year warranty.

CAUTION: Check the documentation of your transceiver/transmitter. NEVER run your radio’s power out at a level that exceeds what it can handle in reference to the duty cycle of the mode you are using. Olivia, for instance, is a 100-percent duty cycle mode. Morse code is NOT quite 100% duty cycle. Nor is SSB, a mode that operates with a duty cycle much lower than 100%. Your radio’s manual should tell you the specifications regarding the duty cycle it can handle! If you run more power than your radio can handle with the given duty cycle of the mode in use, you will blow your radio’s finals or in some other way damage the radio! Beware! I’ve warned you!

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 bands!

Episode 50: A milestone!

Announcements:

• Russ talks about his California trip: attending the Large Installation Systems Administration conference (LISA).
• The 50th episode is a milestone – Richard explains why. See also The Internet Archive.
• Lord Drachenblut reminds us of the upcoming Indiana LinuxFest in Indianapolis, Indiana. If you’d like to register, use the promotional code LHSPODCAST50 (all capital letters) and you’ll get a $15.00 discount on the ticket.
• Music in this episode is from 20lb Sounds, fronted by Dan Lynch of Linux Outlaws fame.

Topics:

• Scott, AD7MI, posted an article on his blog about moving to an all-Linux ham shack. Richard and Russ discuss the article, including Shackbox Linux, Ham Radio Deluxe, CQRLog, and more. Ultimately, Fldigi and CQRLog resulted in “100% Linux Nirvana”.
• Scott also asks what we think would be the ideal Linux-based ham shack. Russ describes his shack, which he thinks IS ideal. Our hosts then discuss various soundcard interfaces:
  • RigBlaster
  • MicroHAM
  • Rascal
• Most sound cards work fine, and Russ recommends the SoundBlaster series over all, but suggests staying away from the SoundBlaster Audigy SE (model CA0106) sound cards as they don’t seem to work well (or at all) under Linux.
• Richard likes his Yaesu FT-897D. Most modern rigs allow a fixed-audio level connection to the computer sound card, as well as computer rig control. Russ has the Kenwood TS-570D, and it, too, is well-supported in the Linux ham libraries.
• Russ and Richard discuss the fact that most hams don’t log VHF/UHF contacts, other than in contests or toward an award.
• The FCC, created by the Communications Act of 1934, included the requirement to maintain a log book in the rules. Sometime between 1983 and 1986, this requirement was dropped as the FCC determined that the information was of little use to them. (If someone can point us to a reference that identifies when the exact rule change occurred, please let us know. I was unable to find the specific change online. -Ed.)

Feedback:

• Leif, KC8RWR, writes that Internet over EME (earth-moon-earth) isn’t likely to work due to the high latency involved. (This may be in reference to a comment in Episode 48.) NASA and DARPA are involved in a Deep-Space Internet project.
• Leif also asks “Isn’t Morse code dead?” and wasn’t it replaced by “Gerke Code”? Our hosts discuss.
• Craig, KB5UEJ, writes that he thinks Russ’ audio is louder and muddier than Richard’s in episodes 46 and 47. Russ agrees that the audio on a few of the recent episodes did suffer, but should be much improved now.
• Grant, KC9SJQ, comments that he doesn’t see a link to Russ’ screencast about SSL anywhere. Yes, it somehow disappeared, but Russ is working on it. He’ll either find the file or redo it.
• William, KB9TMP, sends his comments about Episode 48 where we discuss KE9V’s article that questioned the relevance of amateur radio.
• Craig, KB5UEJ, commenting about WSPR, says that you can run less than 5W on an FT-897 by reducing the audio drive from the computer to the radio. Richard points out that the reduction is often not uniform across the audio freqeuncies used, so some intelligibility may be lost. He had that problem with packet, but he’ll try it with WSPR.
• Matt wants to know the artist and title of a song in Episode 48. The song was “Endline (Choose Nothing)” by I Am Not Lefthanded from the album “Yes Means No”. Check out the show notes for Episode 48 for a link to the song.

Donations:

• Scott, AD7MI, sent a donation just before we recorded! Thanks, Scott.
• If you’d like to help the podcast, please consider making a donation. It’s easy! Just a click on the Donate button on the web site.

Contact Info:

• Contact Richard at [email protected], Russ at [email protected], or both at the same time at [email protected].
• Listen to the live stream every other Tuesday at 8:00pm Central time. Check the LHS web site for dates.
• Leave us a voice mail at 888-455-0305 or 417-200-4811, or record an introduction to the podcast.
• Sign up for the LHS mailing list.
• Sign up for the MAGNetcon mailing list.
• Thanks to Dave from Gamma Leonis for the theme music.

Music:

• Redemption Song performed by 20lb Sounds.
• Jimmy Carter, also by 20lb Sounds.