MSK144 vs FSK441 Meteor Scatter Modes — My Scattered Compilation of Data Points

I’m delighted to see my fellow ham radio operators are having fun reintroducing an aged out software package. That would be the meteor scatter mode FSK441 from the original WSJT digital software suite introduced in 2001.

I suppose it’s no different than working many other digital modes; Hellschreiber is a favorite of mine. Or no different than resurrecting boat anchor rigs. Perhaps my Icom IC-910H could be considered a throw-back as it was introduced in 2000. And, after all this is a hobby.

But I also feel that it’s important to me at least to take some time to review the differences between the two modes. And in some small way better inform operators what mode to select that offers the best chance of success for making contacts.

Of course, a big part of the operating equation is finding stations on the other side of the QSO. The first choice at least for 2020 is almost any of the operating modes in the WSJT-X digital software suite. That starts with FT8, FT4, and MSK144.

I’ll note here Joe Taylor’s recent communication wondering why people aren’t operating FT4 in contests because it’s quite a bit faster than FT8. As he well knows, it first takes a critical mass of stations on that mode.

A similar lament is being expressed by those trying to resurrect FSK441. The latter seems to me like looking at the review mirror versus through the windshield with the former.

What is FSK441?

The operating mode FSK441 was introduced in QST magazine’s December 2001 issue “WSJT: New Software for VHF Meteor Scatter Communication,” by Joe Taylor, K1JT. It’s a good article that can be found on the ARRL website’s QST archive available for members. Also look at the bottom of this post for a full listing of references with links.

FSK441 uses 4-tone frequency-shift-keying and noncoherent demodulation. Its character transmission rate is 147 cps, and it provides reliable copy for signals a few dB above the noise in a 2500 Hz bandwidth. The messages sent are variable in length depending on the number of characters in call signs, etc.

From one of K1JT’s slide decks:

• Four-tone FSK: 882, 1323, 1764, 2205 Hz
• Three tones or “symbols” per character
• Keying rate 441 baud
• Transmission rate 147 cps
• Detection bandwidth 4 × 441 Hz
• Short messages sent repeatedly
• 30s T/R sequences

I feel it’s important to note that the sensitivity level is a “few dB above the noise.” Note too that each encoded character uses three tone intervals and therefore requires 3/441 seconds (approximately 2.3 ms) for transmission. And that it offers a 30 second transmit/receive sequence only.

FSK441 sensitivity level is a few dB above the noise.

Operators promoting the use of FSK441 are particularly pleased with the single tone operations that send a tone at a frequency that can be correlated to RRR, 73, etc. Of course, it can’t be readily determined who transmitted the tone. But it does help to complete the QSO once call signs have been exchanged.

What is MSK144?

There’s a detailed review of MSK144 in QEX magazine’s September/October 2017 issue titled, “The MSK144 Protocol for Meteor-Scatter Communication, “ by Steven Franke, K9AN, and Joe Taylor, K1JT. Again, see the links below.

Here’s an important quote: “Compared to FSK441, the mode widely used for digital meteor-scatter since its introduction in 2001, MSK144 has the advantages of strong error correction, an effective character transmission rate about 1.7 times faster, and significantly better sensitivity… Our MSK144 decoder measures a received signal frequency and phase with enough accuracy to maintain coherence over half a dozen or more of the protocol’s 72 ms frames. So, the out-of-phase noise power can be rejected and we gain 3 dB over non-coherent detection for single-frame decodes, and up to 7 dB for seven-frame averages.”

MSK144 provides strong error correction and sensitivity 3 to 7 dB below the noise level.

The authors go on to say: “On a given meteor-scatter path the duration of a ping is proportional to the inverse square of operating frequency. Pings at 144 MHz are therefore about 1/8 as long as those at 50 MHz. Most of a frame must be received in order to decode its message, so pings shorter than about 70 ms, common at 144 MHz and higher bands, are too short to convey a decodable standard MSK144 frame. To utilize even shorter pings, the protocol includes optional short messages that can be used to send signal reports and other necessary QSO information after call signs have been exchanged. Short frames are 20 ms long and consist of 40 bits: an 8-bit sync word, 4 bits to convey message information, 12 bits representing a hash of the string consisting of the DX call sign followed by the home call sign, and 16 parity bits for FEC. There are just 9 supported messages, namely R‑03, R+00, R+03, R+06, R+10, R+13, R+16, RRR, and 73. The 12-bit hash serves two purposes: it gives the receiving operator high confidence that a decoded frame was indeed intended for him, and it is used to reject most false decodes.”

Comparing MSK144 and FSK441

I feel that the best source of a detailed statistical comparison has been developed by Mike Hasselbeck, WB2FKO, titled “Meteor scatter communication with very short pings.” It’s available at http://www.sportscliche.com/wb2fko/pings_rev.pdf

Here’s his abstract that also includes his recommendation:

A simple statistical model is presented to compare the FSK441 and MSK144 high-speed digital communication protocols using meteor scatter pings in the range 20–120 ms. FSK441 has the ability to make partial decodes with pings shorter than the minimum ∼70 ms needed for an MSK144 message frame. Because many sequences may be required to assemble a complete message with FSK441 partial decodes, in most situations it is preferable to use MSK144 and wait for a single, sufficiently long (> 70 ms) ping.

The FSK441 resurrection first came to my attention around a 222 MHz grid roving effort where they decided to only use FSK441 due to its partial decodes for the expected very short pings at this frequency. That makes sense.

Here’s another quote from WB2FKO: “The MSK144 protocol was developed in 2017 to exploit… enhanced [computer] processor capability. The baud rate is 4.53 times higher and decodes can take place in nearly real-time. Messages are augmented with forward error correction, a cyclical redundancy check, and frame averaging for pings longer than 100 ms. This results in dramatically improved sensitivity and decode reliability.”

WB2FKO does a great deal of statistical comparison in his paper, showing very clearly that FSK441 can indeed provide partial decodes for very short pings. This can greatly help at 222 MHz and higher.

Here’s his conclusion:

Simulations were performed to compare the efficiency of FSK441 and MSK144 in conditions dominated by short, strong meteor scatter pings. FSK441 can obtain partial decodes of multi-tone pings in the range 20–70 ms, which are too short to convey general messages with MSK144. An accumulation of partial decodes can be used to reconstruct a message depending on its length and the presence of synchronization data. The statistical model presented here shows that – on average – it can take the same or less time to complete a QSO with MSK144. This was demonstrated with the conservative assumption that only 22% of the simulated pings are long enough to support an MSK144 message frame. Essentially the same result is obtained when the model is modified for a higher occurrence of slightly longer pings. The MSK144 protocol produces a complete message decode with single pings > 70 ms, which may not always happen with FSK441. Very important is that MSK144 may provide as much as 8 dB or more sensitivity due to forward error correction. FSK441 can, however, make decodes with a looser frequency tolerance between the communicating stations. Unless pings longer than 70 ms are anticipated to be very unlikely, MSK144 should be the preferred mode for VHF-UHF meteor scatter work.

Overall Thoughts

My first meteor scatter contacts were using FSK441 and were quite a blast. See my article “Meteor Scatter — A Burst of Excitement” from 2014. So I have used and like the mode.

But here in 2020 I also like Rob Hardenberg’s, PE1ITR, quote from his research: “FSK441 is decoding always something with a lot of garbage characters. With some imagination the original messages can be discovered. MSK144 is decoding all the cases correctly except the case of the 40ms ping. In my opinion the result is not bad in favour of MSK144.”

Likewise, Bill Somerville, G4WJS, from the WSJT development team states: “I also suspect that there is a general resistance from die-hard FSK441 operators who prefer to pick out a few relevant characters from a jumbled stream of uncorrected errors and decide that a QSO has been completed. Having the software do the legwork with FEC and other techniques like averaging across multiple received blocks maybe is not recognized as a more robust protocol.”

My own thoughts are that if you’re operating at 222 MHz and above, quite possibly FSK441 could be a good mode to try for those new grids. The additional challenges of activating nearly 20 year old software may well be worth the effort — as long as others are doing the same on the other side of the QSO.

For me, I’ll be using MSK144 for my infrequent efforts at meteor scatter, mostly from a VHF rover. Those will probably be restricted to 6 and 2 meters. Further I don’t find that lengthy long distance QSOs at higher frequencies are productive during a VHF contest when I could instead be making other QSOs.

Plus, keeping software relatively simple helps keep me operating during the contest instead of sorting through which software to use and solving the usual challenges of switching from one to the other.

I hope this review has helped offer some insight for your efforts or at least open up some dialog around the pros, cons, and personal preferences for each situation.

Please check out the references below for much better and more thorough analyses of the software packages. Good luck.

References

Here’s where you can download WSJT 10 to get started with or return to FSK441 http://physics.princeton.edu/pulsar/k1jt/wsjt.html

Full listing of references on the WSJT website. http://physics.princeton.edu/pulsar/k1jt/refs.html

QST Magazine December 2001 issue “WSJT: New Software for VHF Meteor Scatter Communication,” by Joe Taylor, K1JT. http://physics.princeton.edu/pulsar/K1JT/WSJT_QST_Dec2001.pdf

QEX July/August 2017 “The MSK144 Protocol for Meteor-Scatter Communication,” by Steven Franke, K9AN, and Joe Taylor, K1JT. http://physics.princeton.edu/pulsar/k1jt/MSK144_Protocol_QEX.pdf

QST Magazine October 2017 issue “Work the World with WSJT-X, Part 1: Operating Capabilities” by Joe Taylor, K1JT. http://physics.princeton.edu/pulsar/k1jt/Work_the_World_part1.pdf

QST Magazine November 2017 “Work the World with WSJT-X, Part 2: Codes, Modes, and Cooperative Software Development,” by Joe Taylor, K1JT http://physics.princeton.edu/pulsar/k1jt/Work_the_World_part2.pdf

“Meteor scatter communication with very short pings,” by Mike Hasselbeck, WB2FKO, comparing FSK144 and MSK144 http://www.sportscliche.com/wb2fko/pings_rev.pdf

Update 14-November-2020

I was pleased this week to hear from Mike Hasselbeck, WB2FKO, with some more insight into this discussion — focused primarily on 222 MHz meteor scatter. Not only that, but he provided a graph! I can’t resist that. Here’s my summary of our discussion.

Here’s Mike’s update on 222 investigations:

A group of west coast operators (primarily K7ULS) have been collecting data on 222 meteor scatter pings using FSK441. The GUI displays ping duration; MSK144 does not. Current results are displayed in the attached histogram. A total of 51 FSK441 decodes have been cataloged with average ping duration of 191 ms. Most important, a whopping 82 percent were long enough to decode with MSK144. The statistical model I used in my analysis assumed only 22 and 33 percent decodes. This assumption is so conservative that it does not represent reality! Upshot:The contention that pings are too short to use MSK144 on 222 MHz is demonstrably false.

In our discussion Mike goes on to recognize that actual practice on 222 and MSK144 is that pings are heard but not decoded. He has done further work to see if Doppler shift could be the issue, but didn’t find anything promising. However, he does offer that as is consistent with WSJT documentation phase equalization through the receiver passband may well be much more critical at 222. This would include the full receiver path: transceiver, transverter, and preamp. Yet another thread to chase in this very interesting review.

Thanks, Mike, for your continued work in this area.