feat(filters): add ft2 mode to filtering options#1122
Conversation
- Add 'FT2' to MODES arrays in PSKFilterManager and ActivateFilterManager - Add FT2 to callsign.js MODES, detectMode comment detection, and DIGITAL_ISLANDS frequencies - Add FT2 to VOACAP heatmap mode selector
Use the official FT2 calling frequencies: 160m: 1.843, 80m: 3.578, 60m: 5.360, 40m: 7.052, 30m: 10.144, 20m: 14.084, 17m: 18.108, 15m: 21.144, 12m: 24.923, 10m: 28.184
accius
left a comment
accius
left a comment
There was a problem hiding this comment.
Thanks for this — FT2 support is absolutely something we want, and the filter/band-plan/rig-mapping parts of this PR are exactly right. One correctness problem in the frequency islands needs fixing before merge, though:
FT4 spots get re-labeled FT2
detectMode() in src/utils/callsign.js matches DIGITAL_ISLANDS with a ±5 kHz tolerance, first match wins, and this PR inserts the FT2 islands before the FT4 block. FT2 dials sit only 4 kHz above FT4 dials on nearly every band:
| Band | FT4 dial | FT2 dial (this PR) | gap |
|---|---|---|---|
| 40m | 7.0475 | 7.052 | 4.5 kHz |
| 30m | 10.140 | 10.144 | 4 kHz |
| 20m | 14.080 | 14.084 | 4 kHz |
| 17m | 18.104 | 18.108 | 4 kHz |
| 15m | 21.140 | 21.144 | 4 kHz |
| 12m | 24.919 | 24.923 | 4 kHz |
| 10m | 28.180 | 28.184 | 4 kHz |
Every one of those gaps is inside the ±5 kHz window, and FT2 is checked first — so effectively all FT4 spots would be detected as FT2. On 80m the FT2 dial (3.578) is also exactly 5 kHz from the FT8 dial (3.573), so FT2 spots there would match FT8 (which is checked first).
useBandHealth.js has the same structure with ±3 kHz (ISLAND_TOL_MHZ); there the 80m pair (3.575 vs 3.578) collides.
Suggested fix
Because spotted frequencies sit 0–3 kHz above the dial (audio offset), a symmetric window can't separate two dials 4 kHz apart no matter the ordering. The clean fix is an asymmetric window for the island check:
// signals are always above dial: match [dial, dial + 3.1 kHz]
const offset = mhz - island.mhz;
if (offset >= -0.0005 && offset <= 0.0031) return island.mode;applied to both callsign.js and useBandHealth.js (keeping a small negative allowance for rounded-down spot freqs). That separates FT4 (dial…dial+3.1) from FT2 (dial+4…) cleanly and also tightens the existing FT8/FT4 boundary. If you'd rather keep the symmetric-tolerance style, ordering FT4 before FT2 with tolerance ≤ 2 kHz for those two modes also works, but the asymmetric window matches the physics better.
A couple of detectMode unit tests around the boundaries (e.g. 14.081 → FT4, 14.085 → FT2) would lock this in — src/utils/dxClusterFilters.test.js shows the test setup.
Happy to help if any of this is unclear. Note for us on the maintainer side: the new spot-window balancing regexes (/\bFT[84]\b/ in server/routes/dxcluster.js and the FT8/FT4 cap in src/utils/dxClusterFilters.js) should learn FT2 when this lands — we'll handle that in a follow-up.
|
I've made the fix to callsign.js, but in |
2 participants
What does this PR do?
This PR adds FT2 support to existing filters in the DX Cluster and PSKReporter Panels
It also adds FT2 and the currently used test dial frequencies to the bandplan hook/utils (so clicking FT2 spots sets the radio to a DIGI mode)
Type of change
How to test
Checklist
Screenshots (if visual change)