ませ１りすか

In 2026, the amateur radio world was shaken.

3Y0K — Bouvet Island.

Located at the southern tip of Africa, surrounded by the perpetually stormy South Atlantic, this remote island has long been regarded as one of the most wanted DXCC entities in the world. Numerous expeditions have been attempted over the years, only to be thwarted by violent weather and failed landings. Time and again, the dream slipped away.

This time, the signals finally came through.

Amateur radio operators around the world flooded the pileup. FT8 waterfalls were wall-to-wall with signals, social media overflowed with reports, and ChronoGPS downloads spiked dramatically (personal note, sorry).

While participating in the pileup myself, I kept an eye on social media. Two opinions kept appearing over and over:

"I called below 1000Hz and got a callback. So it must be MSHV."

"It should have been 3 strikes and out, but I got a response anyway. So it must be MSHV."

Both conclusions landed on "therefore MSHV" — which I find interesting. MSHV is excellent software that enables multi-stream FT8/FT4 operation, but it's not the explanation for either of these observations.

And I'll be honest: regarding the second point — the "3 strikes" issue — I myself had the wrong understanding until very recently.

Let me go through this carefully.

Before diving into the debate, let's confirm the premise.

The official 3Y0K website stated they were using F/H (Fox & Hound) mode. That's the simplest and most authoritative piece of evidence. The expedition team themselves said "we're using F/H" — that should be our starting point.

So where does the "it looked like MSHV" impression come from? To understand that, we need to know exactly how F/H mode works.

WSJT-X's Fox & Hound mode was developed by K1JT (Joe Taylor) in 2018, designed to allow DXpedition stations (Fox) to complete QSOs at very high rates with multiple stations simultaneously.

The frequency arrangement works like this:

Fox transmits at audio frequencies between 300 and 900 Hz. When transmitting multiple simultaneous signals, they are spaced at 60 Hz intervals.

Hounds make their initial calls anywhere in the range 1000 – 4000 Hz.

This separation is the foundation of F/H mode.

Two critical points about Fox's behavior:

"Does not decode" and "ignores" are completely different things. This distinction becomes important shortly.

This is the most common misconception I saw on social media.

Let's break it down.

In F/H mode, Fox does decode signals below 1000Hz. It just doesn't respond to them. If you look at Fox's waterfall display, Hound signals below 1000Hz are highlighted in red — Fox can see them, it's just choosing to ignore them. That's the design.

So how do we explain "I called below 1000Hz and still got a callback"?

The answer is the queue.

Fox maintains a queue of Hound callsigns decoded in recent sequences. If you called above 1000Hz with Tx1 (grid square included) even once in the past few sequences, your callsign remains in Fox's queue. Even if you subsequently drifted below 1000Hz, Fox can still select you from the queue and call you back.

"I called below 1000Hz and got a response" does NOT equal "therefore MSHV." It most likely means "I had previously called correctly above 1000Hz, and my callsign was still in the queue."

Think back carefully from the very beginning. Are you absolutely certain you never called above 1000Hz even once? 😅

In most cases, I suspect the memory of "I only called below 1000Hz" is inaccurate, and there was at least one transmission above 1000Hz somewhere along the way.

There's another possible source of confusion worth mentioning. In Hound mode, WSJT-X has automatic frequency control. After Fox calls you, Hound automatically moves to near Fox's DF to send R+report — which may place it below 1000Hz. This is a mid-QSO frequency change, not an initial call below 1000Hz. The memory of "I was below 1000Hz" may be conflating this automatic move with the initial call.

This is the heart of today's post. And as I mentioned at the beginning, I had the same misconception myself.

The official F/H mode User Guide written by K1JT (2018) states the following about Fox's behavior:

"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."

Reading this, most people concluded: 3 failures means game over, start over from scratch. I did too.

"3 strikes and you're out" — it's baseball. Clear, intuitive, easy to remember.

But then—

While discussing this on Facebook, I received a tip from Michael Flensted Möller (Top Contributor): "Read the release notes."

In the WSJT-X 2.6.0-rc5 release notes (November 29, 2022), there is this entry:

"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."

Let me spell out what this means:

1. Fox calls a Hound up to 3 times, waiting for R+report

2. After 3 failures, Fox drops that Hound from the queue (3 strikes)

4. If R+report arrives during that window, Fox still sends RR73

In other words, there are effectively 5 chances.

It was NOT 3 strikes and out. 😄

I was genuinely surprised when I read this. It's not in the manual. It's only in the release notes. And of course it's not in the 2018 manual — this was a change made in 2022.

"Got a response after what should have been 3 strikes" is not because of MSHV. It's because of the behavior change introduced in WSJT-X 2.6.0-rc5.

The intent behind this change is clear: to increase the success rate for difficult QSOs. Propagation fluctuations and momentary interference can cause you to miss the 3-cycle window. Adding 2 more cycles as a buffer is a thoughtful design decision — very much in the spirit of K1JT's careful engineering.

What this whole experience reinforced for me is that thinking you understand something just because you read the manual can be dangerous.

WSJT-X has been continuously refined since the introduction of F/H mode in 2018. The manual is a snapshot of that point in time. To accurately understand current behavior, you need to follow the release notes as well.

Yes, the WSJT-X release notes are long. Keeping up with every version is genuinely tedious. But there are discoveries waiting in there — the accumulated history of careful improvements by K1JT and the development team. Things like the SuperFox mode introduction (2.7.0-rc5), improvements for handling MSHV multi-stream signals in Hound mode (2.7.0-rc1), and Fox queue management enhancements (2.6.0-rc5) — all of these directly affect real-world operation.

When something seems off, or the software behaves differently than you remember, the release notes often have the answer.

Think of the manual as the entrance, and the release notes as the map to where you are now.

I want to be clear: I'm not criticizing MSHV. It's excellent software developed by LZ2HV (Christo), enabling multi-stream FT8/FT4 QSOs with multiple stations simultaneously. Many DXpeditions use it effectively.

When calling a DX station running MSHV multi-stream, Hound operators need no special settings. It's the same as normal FT8 operation. No frequency restrictions. You can call with a grid square, or start with R+report — whatever works. MSHV's multi-stream capability is entirely on the host side; it's transparent to the calling station.

The confusion between F/H mode and MSHV matters precisely because of this difference: F/H mode places real constraints on the calling side (above 1000Hz, Tx1 with grid). MSHV does not. Understanding which mode is in use changes how you should operate.

Personal experience matters. "This worked" and "this didn't work" — the lessons from actual operating are at the heart of what makes amateur radio enjoyable.

But it's worth pausing before jumping from experience to conclusion. The question "why did that happen?" deserves an answer, and the answers are often in the manual and release notes.

"Called below 1000Hz and got a callback" → don't conclude "therefore MSHV." Ask "why did I get a callback?" Knowing about the queue explains it within F/H mode.

"Should have been 3 strikes but got a response" → don't conclude "therefore MSHV." Check whether the release notes have something relevant. The answer was in 2.6.0-rc5.

Understanding how your software actually works makes the hobby more interesting. When things go right, you know why. When things go wrong, you know why. And that understanding also helps reduce QRM — operators who know that parking below 1000Hz causes problems for everyone are less likely to do it.

Amateur radio is a hobby built around technology. If you enjoy the technology, understanding what's happening under the hood is part of the fun.

Please read the release notes. 📖

Feel free to share.