AmateurRadio.com

The following footprints are of my CW signals on 2021-March-14 at about 04:00 to 04:20 UTC.

Click on this image to see a larger version of this image:

Location: EM89ad – Ohio
Antenna: OCD (Off-center Dipole)

Description of Antenna:

This is an off-center dipole, with the two legs running East-East-South (approximately 125 degrees of North), and West-West-North (about 306 degrees on the compass). The westward wire (leg) is approximately 107 feet in length, while the eastward leg is about 95 feet in length.

These legs (an off-center-fed dipole) is directly connected to about 90 feet of 450-ohm ladder line, which is hanging directly below, vertically, the feed point. The feed point is 50 feet above the ground.

The ladder line terminates (at the 12-feet-above-ground point) to a 4:1 current balun. This current balun then connects to a 100-foot LMR 50-ohm coax, which is running into the radio shack. It is connected via an antenna switch to my Icom IC-7610 transceiver. I am transmitting a 100-watt CW signal using an Icom IC-7610, in the following format:

TEST TEST TEST DE NW7US NW7US NW7US

The Reverse Beacon Network reports any spotting of this test transmission. The beta mapping interface, at http://beta.reversebeacon.net/main.php, then maps the resulting spots. To learn more about the RBN, visit http://beta.reversebeacon.net/index.php, or, http://reversebeacon.net/index.php.

I show the 20-, 30-, 40-, 60-, 80-, and 160-Meter band footprints.

I’ve been capturing these CW transmission spots, at different times of the day, today. I’ll get data from several days, at regular intervals, and create a overview of how the antenna appears to be working during this month and under these propagation conditions.

73 de NW7US dit dit

..

About a month ago, I asked,

“What is going on with you during this challenging situation?” and, “How do you use amateur radio, now that we are all stuck at home?  Are you using ham radio more, now?  Less?“

I am moved to say, “Thank you, to each of you who commented and even those who made a video response. I sure appreciate it!“

During that video blog (or, Vlog), back a month ago (link: Chat From a Quarantined Software Engineer – Welfare Check!), I mentioned my need for dental surgery. 

I did have to have the tooth removed.  It was completely split down the middle (top to bottom), down to the root.  There was no justifiable way to save the tooth. 

I now am missing two bottom back-most teeth, and one bottom, back-most tooth.  I can report that I have healed up nicely.  I am starting to enjoy a hamburger or two.

Through all of this, I’ve still been working. Also, I’ve been involved with a LOT more ham radio–especially with Morse code activities.

How has the last month treated you?  After watching this new video (below), please leave a comment or two, or three; let hear from you, okay?

More than anything, please leave a comment to let me know how you are doing.  I hope to hear from you.

Here’s the video:

[embedyt]https://www.youtube.com/watch?v=vFGbw7d91GA[/embedyt]

73 de NW7US dit dit

I was first introduced to D-Star some twelve years or so ago.  I purchased the ICOM IC-92AD hand-held and managed to get setup on one of the local D-Star repeaters.  Being one who (at the time) preferred all things HF, my D-Star activities were almost non-existent.  But it was fun to tinker and learn.

Some time passed and I experimented with various DVAP type devices that came onto the market.  I preferred using these to the local repeater, since I could connect into reflectors around the world and share in all the fun of digital radio.

Around the early 2016 timeframe, I purchased the Hardened Power DHAP Mini Mega Self Powered Enclosure along with a Raspberry Pi 3 and the DVMEGA Dualband add-on for the Pi.  The DHAP case is a 3-D printed plastic.

Inside there’s plenty of room for the Raspberry Pi, the DVMEGA and four rechargeable batteries.

I setup the Raspberry Pi with a popular image at the time from the Maryland D-Star group.  As I have never claimed to be a Raspberry Pi expert, even though I do own three devices.  One being an ADS-B aircraft tracker and second which has been running SETI@home and then the third running the Maryland D-Star setup.

Anyway, the Maryland D-Star image was easy to setup and at the time (2016) the group was active.  They had a website which contained more knowledge needed to setup the Pi and a very helpful forum community.  I could fire up my DHAP and via my radio connect/disconnect reflectors all around the world, reboot or shutdown the Pi.  It was all very cool.

Burnout

When the burnout occurred in late 2016, I wasn’t doing any form of operating and as a result I shut down the D-Star Pi and placed it (along with the IC-92) in a closet.  It sat there until just about two weeks ago when (like many of you) found myself bored out of my skull from the self-isolation COVID-19 routine.  I decided this was a project that might take my mind off the events of the world and might even help rekindle some of my amateur radio interests.

Power Up

After being sat idle for over three years, everything needed a good charge.  Surprisingly my ICOM batteries all came back to life and even the DHAP powered on just fine.  Everything worked (just as it did when I shut it down) but I figured at the very least I needed to update the software.  That’s when I realized the Maryland D-Star Pi was no more.

Pi-Star

While everything worked (best I could tell), in my hunt for what happened to the Maryland group, I discovered Pi-Star.  The Pi-Star group is an active group and appears to be the best thing since sliced bread when it comes to all things D-Star hotspots.  So I downloaded their latest and greatest image (4.1.0), installed it onto an empty SD card and began noodling around.

Of course “Noodling” around is much like driving around trying to find something without actually stopping to ask for directions.  The end result left me sort of frustrated and wondering if I should just go back to using the old Maryland setup.  At least it worked…for now.  But it’s not like I don’t have time or the mental capacity to figure this out.  So, diving head first into the forums I began to find the answers I needed and more importantly, I knew once I had everything working…it would be a much better setup.

All the Pre-requisites

As my DVMEGA was several years old, one of the first things required was to update the firmware so it could take advantage of all the features in Pi-Star.  This wasn’t as straight forward as I had hoped it would be.  It required some risky soldering of a short wire so the firmware of the DVMEGA could be updated.  I found all the documentation required for performing this risky step located here.  Well…almost!

With soldering iron, wire and some solder in hand, I completed the risky step and proceeded to update the firmware.  However, each time I attempted to perform the update it failed.  What have I done?  Did I ruin the DVMEGA?  I decided to go to bed and then take another stab at it the next day.

With a strong cup of coffee in hand, I proceeded to double-check all my work.  I felt confident in the soldering job, so hardware was all GO!  I then looked at it from the software perspective.  I decided to try using an older version of Pi-Star to rule out some issue with the latest version.

BINGO!

Once I rolled back to version 3.4.17 (from earlier this year), the process of updating the DVMEGA firmware worked just as it should.  In just a few minutes I had managed to update the firmware of my DVMEGA board from 2.19 to the latest 3.26.

More Frustration

With the DVMEGA updated to 3.26 and my Pi running Pi-Star 4.1.0, I began digging into the programming requirements of my radio.  For the life of me, I couldn’t figure  out how I needed to setup the radio so I could still control the system from my handheld.  After a bit of swearing and more digging in the forums, I discovered a fairly significant difference between how the radio needed to be setup from what was required with the Maryland D-Star setup.

I got there in the end

Yep, all appears to be working perfect.  I can easily connect and disconnect from any reflector I have programmed into my IC-92 from anywhere in the house.  While I tend to leave the setup in my shack (basement man cave) connected via Ethernet cable, I also can move the device around the house and use wi-fi.

From within my QTH the device is fully self-contained.  I can run it off the batteries and wi-fi and have coverage anywhere within the house (or even from back deck) should I choose.

Next Steps

I do have a few additional setup steps which I plan to experiment with in the coming days.  With the old Maryland setup I had my smartphone hotspot configured which would allow me to take this mobile.  Pending I had good broadband coverage, I could activate my hotspot, turn on the DHAP and place it all in the car for mobile ops.

Want more info on Pi-Star?

Your first stop needs to be the Pi-Star homepage.  From there you can join the forums, download the software and learn everything you need to know about Pi-Star.  I also found another great source of information on the Amateur Radio Notes blog site which is managed by Toshen, KEOFHS.  He’s a fellow Coloradoan living in Lyons.

Well I think that just about does it for this posting.  I wish you and your family a very Blessed Easter weekend (if you celebrate).  I’ll return soon with another update.

73 de KDØBIK (Jerry)

I was first introduced to D-Star some twelve years or so ago.  I purchased the ICOM IC-92AD hand-held and managed to get setup on one of the local D-Star repeaters.  Being one who (at the time) preferred all things HF, my D-Star activities were almost non-existent.  But it was fun to tinker and learn.

Some time passed and I experimented with various DVAP type devices that came onto the market.  I preferred using these to the local repeater, since I could connect into reflectors around the world and share in all the fun of digital radio.

Around the early 2016 timeframe, I purchased the Hardened Power DHAP Mini Mega Self Powered Enclosure along with a Raspberry Pi 3 and the DVMEGA Dualband add-on for the Pi.  The DHAP case is a 3-D printed plastic.

Inside there’s plenty of room for the Raspberry Pi, the DVMEGA and four rechargeable batteries.

I setup the Raspberry Pi with a popular image at the time from the Maryland D-Star group.  As I have never claimed to be a Raspberry Pi expert, even though I do own three devices.  One being an ADS-B aircraft tracker and second which has been running SETI@home and then the third running the Maryland D-Star setup.

Anyway, the Maryland D-Star image was easy to setup and at the time (2016) the group was active.  They had a website which contained more knowledge needed to setup the Pi and a very helpful forum community.  I could fire up my DHAP and via my radio connect/disconnect reflectors all around the world, reboot or shutdown the Pi.  It was all very cool.

Burnout

When the burnout occurred in late 2016, I wasn’t doing any form of operating and as a result I shut down the D-Star Pi and placed it (along with the IC-92) in a closet.  It sat there until just about two weeks ago when (like many of you) found myself bored out of my skull from the self-isolation COVID-19 routine.  I decided this was a project that might take my mind off the events of the world and might even help rekindle some of my amateur radio interests.

Power Up

After being sat idle for over three years, everything needed a good charge.  Surprisingly my ICOM batteries all came back to life and even the DHAP powered on just fine.  Everything worked (just as it did when I shut it down) but I figured at the very least I needed to update the software.  That’s when I realized the Maryland D-Star Pi was no more.

Pi-Star

While everything worked (best I could tell), in my hunt for what happened to the Maryland group, I discovered Pi-Star.  The Pi-Star group is an active group and appears to be the best thing since sliced bread when it comes to all things D-Star hotspots.  So I downloaded their latest and greatest image (4.1.0), installed it onto an empty SD card and began noodling around.

Of course “Noodling” around is much like driving around trying to find something without actually stopping to ask for directions.  The end result left me sort of frustrated and wondering if I should just go back to using the old Maryland setup.  At least it worked…for now.  But it’s not like I don’t have time or the mental capacity to figure this out.  So, diving head first into the forums I began to find the answers I needed and more importantly, I knew once I had everything working…it would be a much better setup.

All the Pre-requisites

As my DVMEGA was several years old, one of the first things required was to update the firmware so it could take advantage of all the features in Pi-Star.  This wasn’t as straight forward as I had hoped it would be.  It required some risky soldering of a short wire so the firmware of the DVMEGA could be updated.  I found all the documentation required for performing this risky step located here.  Well…almost!

With soldering iron, wire and some solder in hand, I completed the risky step and proceeded to update the firmware.  However, each time I attempted to perform the update it failed.  What have I done?  Did I ruin the DVMEGA?  I decided to go to bed and then take another stab at it the next day.

With a strong cup of coffee in hand, I proceeded to double-check all my work.  I felt confident in the soldering job, so hardware was all GO!  I then looked at it from the software perspective.  I decided to try using an older version of Pi-Star to rule out some issue with the latest version.

BINGO!

Once I rolled back to version 3.4.17 (from earlier this year), the process of updating the DVMEGA firmware worked just as it should.  In just a few minutes I had managed to update the firmware of my DVMEGA board from 2.19 to the latest 3.26.

More Frustration

With the DVMEGA updated to 3.26 and my Pi running Pi-Star 4.1.0, I began digging into the programming requirements of my radio.  For the life of me, I couldn’t figure  out how I needed to setup the radio so I could still control the system from my handheld.  After a bit of swearing and more digging in the forums, I discovered a fairly significant difference between how the radio needed to be setup from what was required with the Maryland D-Star setup.

I got there in the end

Yep, all appears to be working perfect.  I can easily connect and disconnect from any reflector I have programmed into my IC-92 from anywhere in the house.  While I tend to leave the setup in my shack (basement man cave) connected via Ethernet cable, I also can move the device around the house and use wi-fi.

From within my QTH the device is fully self-contained.  I can run it off the batteries and wi-fi and have coverage anywhere within the house (or even from back deck) should I choose.

Next Steps

I do have a few additional setup steps which I plan to experiment with in the coming days.  With the old Maryland setup I had my smartphone hotspot configured which would allow me to take this mobile.  Pending I had good broadband coverage, I could activate my hotspot, turn on the DHAP and place it all in the car for mobile ops.

Want more info on Pi-Star?

Your first stop needs to be the Pi-Star homepage.  From there you can join the forums, download the software and learn everything you need to know about Pi-Star.  I also found another great source of information on the Amateur Radio Notes blog site which is managed by Toshen, KEOFHS.  He’s a fellow Coloradoan living in Lyons.

Well I think that just about does it for this posting.  I wish you and your family a very Blessed Easter weekend (if you celebrate).  I’ll return soon with another update.

73 de KDØBIK (Jerry)

This past weekend (third full weekend in February, February 15-16, 2020) is the ARRL International CW Contest (ARRL DX CW link: http://www.arrl.org/arrl-dx ). This is interesting to my study of radio signal propagation as a columnist and as an amateur radio operator​ because of the contest objective: “To encourage W/VE stations to expand knowledge of DX propagation on the HF and MF bands…” This contest is a good way to get a feel for current propagation–though there are caveats.

Speaking of Morse code and the CW mode on our amateur bands: those of you using CW during contests, do you send by hand or by computer?  Do you copy the code by head, or do you use a computer for decoding?

Just curious about those of you who use CW. Do you send by hand or computer? Receive by head or computer?

In most contests like the ARRL DX CW contest, I copy by ear, and send mostly by rig keyer. If needed, I use a single paddle key with the Icom rig’s internal keyer to answer unique questions and so on.

Below is a quick demo of using the internal Morse code keyer in my Icom IC-7610 transceiver.

V47T, in the Saint Kitts and Nevis Island in the Caribbean, is calling CQ TEST in the ARRL DX CW contest.

Using the programmable virtual buttons, in which I programmed my callsign, NW7US, and other info, I answer and make a complete contest QSO.

In activity like the Straight Key Century Club (SKCC – https://SKCCGroup.com) K3Y special event, it is all manual. I send my Morse code using a WWII Navy Flameproof Signal Key, and decode with my ears.  It is contextual for me.

[embedyt] https://www.youtube.com/watch?v=vm8UJst6umA[/embedyt]

How do you do contesting Morse code?  Bonus question: How do you do logging while doing contest operation?

73 es best dx = de NW7US dit dit

Man, lots and lots of Morse code on the ham bands, this weekend. The CQ Worldwide CW Contest weekend was hopping with signals!

How did you do this weekend? How were conditions on the various contest bands?

Comment here and your report may make it into the propagation column in an upcoming edition of the Radio Propagation column in CQ Amateur Radio Magazine.

Here are a few moments as heard at the station of the CQ Amateur Radio Magazine propagation columnist, in Lincoln, Nebraska (yeah, that’s me, NW7US).

[embedyt]https://www.youtube.com/watch?v=eWCbtIOJmLI[/embedyt]

Here are the results of my dabbling with the Icom rig and this contest:

 NW7US's Contest Summary Report for CQ-WW
 Created by N3FJP's CQ WW DX Contest Log
 Version 5.7  www.n3fjp.com

 Total Contacts = 55
 Total Points = 8,979

 Operating Period: 2019/11/24 10:23 - 2019/11/24 22:51

 Total op time (breaks > 30 min deducted): 3:58:46
 Total op time (breaks > 60 min deducted): 4:45:17

 Avg Qs/Hr (breaks > 30 min deducted): 13.8


 Total Contacts by Band and Mode:

 Band       CW   Phone     Dig   Total       %
 ----       --   -----     ---   -----     ---
   80        8       0       0       8      15
   40        7       0       0       7      13
   20       25       0       0      25      45
   15       15       0       0      15      27
            --   -----     ---   -----     ---
 Total      55       0       0      55     100

 Total Contacts by State \ Prov:

 State       Total     %
 -----       -----   ---
                52    95
 HI              3     5

 Total = 1


 Total Contacts by Country:

 Country                      Total     %
 -------                      -----   ---
 Canada                           6    11
 Brazil                           5     9
 USA                              5     9
 Argentina                        3     5
 Costa Rica                       3     5
 Hawaii                           3     5
 Bonaire                          2     4
 Cayman Is.                       2     4
 Chile                            2     4
 Cuba                             2     4
 Japan                            2     4
 Mexico                           2     4
 Aruba                            1     2
 Bahamas                          1     2
 Barbados                         1     2
 Belize                           1     2
 Curacao                          1     2
 Dominican Republic               1     2
 French Guiana                    1     2
 Haiti                            1     2
 Honduras                         1     2
 Martinique                       1     2
 Montserrat                       1     2
 Nicaragua                        1     2
 Senegal                          1     2
 St. Kitts & Nevis                1     2
 St. Lucia                        1     2
 Suriname                         1     2
 US Virgin Is.                    1     2
 Venezuela                        1     2

 Total = 30


 Total DX Miles (QSOs in USA not counted) = 151,407
 Average miles per DX QSO = 3,028


 Average bearing to the entities worked in each continent.
 QSOs in USA not counted.

 AF =  83
 AS = 318
 NA = 124
 OC = 268
 SA = 137


 Total Contacts by Continent:

 Continent   Total     %
 ---------   -----   ---
 NA             32    58
 SA             17    31
 OC              3     5
 AS              2     4
 AF              1     2

 Total = 5


 Total Contacts by CQ Zone:

 CQ Zone   Total     %
 -------   -----   ---
 08           13    24
 03            7    13
 09            7    13
 07            6    11
 11            5     9
 13            3     5
 31            3     5
 04            2     4
 05            2     4
 06            2     4
 12            2     4
 25            2     4
 35            1     2

 Total = 13

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!