Filtering DX Cluster Live using both a single callsign & mode(s) cause the spots to disappear from the DX Cluster panel

[mikeynags]

Description: When selecting a DX Cluster Filter of Watch-listed calls, when also selecting an Operating Mode Filter, it causes the DX Cluster window to show no spots at all

To Reproduce

Steps to reproduce the behavior:

1. Go to DX Cluster Filter and select a call to filter on. (preferably one that is active)

3. Click on 'Modes' and select a mode, FT8 for example ( again -- the station should be active in this mode)

5. As soon as the mode is selected, you will see the spots disappear:

Before:

After:

Expected Behavior

Spots for active callsign along with their modes should remain in the DX Cluster Live pane

Screenshots

Environment

• OS: Windows 11 Client
• Browser: Brave/Chromium 145.0.7632.120, Firefox 148.0
• Node.js Version: v18.19.1
• OpenHamClock Version: 15.6.3
• Running As: Node.js install via NPM on Ubuntu 24.04

Console Errors

---

WJ1X
73!

[ceotjoe]

@mikeynags hmm, logically this is AND currently and you think it should be OR? Do I understand that correctly?

I'm not seeing this as a bug currently. It's expected that all filters are AND and not OR.

[mikeynags]

It should be an AND I would think. For example I want this callsign AND this mode. Adding in modes from what I was seeing on the cluster that were definitely FT8, made the spots disappear completely.

[ceotjoe]

@mikeynags yes but logical AND means all selected filters need to be true to be displayed. Means if you filter callsigns you get (with the check like in your screen) only the call signs you want. But adding only FT8 means if nobody has FT8 currently of your selected callsigns then the list will be empty because there is nobody doing FT8 of all callsigns. That is logically correct. No bug.

You want to do something different. This would be more like an enhancement request.

[tedszypulski-ui]

When 3Y0K was transmitting they were in FT8 mode. Perhaps the posted spot at the time had the wrong mode?

[mikeynags]

@mikeynags yes but logical AND means all selected filters need to be true to be displayed. Means if you filter callsigns you get (with the check like in your screen) only the call signs you want. But adding only FT8 means if nobody has FT8 currently of your selected callsigns then the list will be empty because there is nobody doing FT8 of all callsigns. That is logically correct. No bug.

You want to do something different. This would be more like an enhancement request.

I would be happy with an OR function. Right now if you limit to show only watchlist callsigns, the DX Cluster pane should not be blank unless none of the parameters are met.

[ceotjoe]

When 3Y0K was transmitting they were in FT8 mode. Perhaps the posted spot at the time had the wrong mode?

Hard to say.

I would be happy with an OR function. Right now if you limit to show only watchlist callsigns, the DX Cluster pane should not be blank unless none of the parameters are met.

Let's see what the other devs say about changing that logic. I'm not convinced yet if that's a good idea.

[mikeynags]

Understood, the only thing I could say is that the DX Cluster Live pane had several posts for 24.911 that all went away when I selected FT8. I'm hoping that others test this and see if they see the same result.

[accius]

This is a confirmed bug — nice catch @mikeynags.
@ceotjoe the AND logic is correct and working as intended — that's not the issue. The problem is in detectMode() in src/utils/callsign.js.
Root cause: When a mode filter is active, we detect the mode of each spot using detectMode(comment, freq). It first checks the comment text for keywords like "FT8", and if that fails, it falls back to matching the frequency against known digital calling frequencies with a ±3 kHz tolerance window.
The 12m FT8 calling frequency is 24.915 MHz, so the detection window was 24.912–24.918. The reporter's spots at 24.911 are just 1 kHz outside that window. detectMode returns null, and the mode filter (dxClusterFilters.js line 174) drops any spot where !mode — so the spot disappears.
DX cluster spotters routinely report frequencies that are slightly off the exact dial frequency depending on their rig readout, the audio offset of the specific signal they clicked, etc. 3 kHz was too tight for real-world cluster data.
Fix: Widened the tolerance from ±3 kHz to ±5 kHz. This covers 24.910–24.920 for 12m FT8 and similar edge cases on other bands without being wide enough to cause false positives between adjacent mode allocations.