Would you be OK with an external app using /api/cat/* as its radio-control interface?

[iu1teu]

Hi Colin,

Following up on #76 — the ATU support in pre8 works great, thank you again.

Since that landed I started looking at whether I could go further and drop my own CAT bridge entirely, so let me explain the current setup properly this time.

What I'm running today: a custom desktop app for my own shack (logbook/cluster/FT8 automation/dxpedition tracking ecc) that talks to the radio through a small Python TCP bridge I wrote myself (cat_server.py), running on the same Windows PC as YWC. It translates a simple TCP protocol into raw Yaesu CAT over a virtual serial port. My app, YWC, and WSJT-X all share that one physical CAT link concurrently via VSPE virtual serial ports — no port contention, that part's solved.

What I tried next: with ATU now covered, I went looking at whether rigctld alone could replace my bridge entirely. It can't, quite — I found (and tested directly against my running instance) that get_vfo/set_vfo always forces VFOA, get_level SWR isn't implemented, set_level/set_powerstat are no-ops or missing, and split/RIT/XIT are local stub fields that never touch the radio. None of that is a complaint — rigctld is clearly scoped for what WSJT-X/Log4OM need, and it does that well.

What I found instead: poking around the repo, Controllers/CatController.cs — the REST API your own web UI runs on — already covers everything my app needs in one place. GET /api/cat/status gives me both VFOs (freq/mode/S-meter) plus real SWR/power/ALC/compression/temperature in one call, and the POST endpoints for frequency, mode, split, ATU and radio power-on all go straight to ICatClient.SendCommandAsync — real CAT, not stubs. I tested GET /api/cat/status against my running instance from my Mac and it came back with live, correct data for both VFOs.

The actual ask: that API obviously wasn't built or documented as a public integration surface — it's what your own frontend uses internally. Before I build anything real on top of it, I wanted to check: are you comfortable with an external program depending on /api/cat/* the way WSJT-X depends on rigctld? If it's likely to move around or change shape as you keep developing the UI, I'd rather know that now than find out via a broken app after an update. If you'd rather I stick to rigctld and eventually file requests for the specific gaps instead (VFO B, real SWR, real set_level/set_powerstat), that's completely fine too — just want to build on whichever surface you're actually willing to keep stable for outside consumers, rather than assume.

Either way, happy to report back anything I find useful along the way.

Giovanni

[mm5agm]

Hi Giovanni,

Thanks for the thorough write-up again — testing get_vfo/get_level/set_powerstat directly against a running instance before asking is exactly the kind of diligence that makes this easy to answer properly rather than just guessing.

Your instinct is right, and so is mine apparently: /api/cat/* is not something I can honestly promise to hold stable. It's the same code the front-end runs on, the responses are anonymous objects, not fixed DTOs, and it's already reshaped itself several times in just the last couple of weeks — roofing filter fields, the new ATU wiring, the rigctld PTT fix. None of that was designed with an external consumer in mind, so if you built directly on it today, a UI change next month could break you with no warning.

Rather than either leave you exposed to that or freeze the whole controller (which would tie my hands on the actual UI), I think the right move is to give you something narrower and genuinely committed: a small separate endpoint surface — something like /api/external/v1/* — that wraps the same underlying CAT/state services CatController already uses, but with its own hand-written response types and its own documented stability promise: it only changes if you (or another integrator) ask for a change, and anything breaking gets a v2 alongside it rather than an in-place edit. I'd scope it to exactly what you've described needing — both-VFO status with real SWR/power/ALC/compression/temp, set frequency, set mode, split, ATU, radio power — nothing speculative beyond that.

The other option, which you already half-offered: extend rigctld itself to close the specific gaps you found — proper VFO B addressing (Hamlib's --vfo mode supports this), a real get_level SWR, and working set_powerstat/split. rigctld is already a standards-based protocol other tools speak too, so closing gaps there means one stable surface to maintain long-term instead of two, and any future integrator gets the fixes for free. The trade-off is it's Hamlib's command shape, not a REST API, so it may or may not fit how your app is structured internally.

Both are buildable — I don't have a strong preference either way, so I'd rather build the one you'll actually get long-term value from. Which fits your app better: a small dedicated REST surface, or closing the rigctld gaps?

73, Colin

[iu1teu]

Hi Colin,

Thanks for laying it out that clearly — genuinely appreciate you thinking through the maintenance trade-off rather than just picking one for me.

I'll go with the dedicated REST surface. The shape you described already matches what I need, so no changes to your proposed scope:

Status (both VFOs: frequency, mode, S-meter; plus real SWR, power, ALC, compression, temperature) — this is a direct swap for the whole polling loop my current bridge runs today (FA;/FB;/IF;/MD0;/SM0;/RM6;/PC;), so one GET replacing seven round-trips is a nice bonus on top of everything else.
Set frequency and set mode, both VFOs independently.
Split — one thing worth flagging since I don't know how you've scoped it internally: my app treats "which VFO is receiving" and "which VFO is transmitting" as two independent selections (a user can pick RX-VFO-A + TX-VFO-B without it being a single on/off toggle), so if your existing split concept is a simple boolean rather than independent RX/TX VFO selection, that's the one place I'd ask you to double check against what I actually need rather than assume.
ATU — on/off + tune trigger, exactly as pre8/pre9 already expose over rigctld.
Radio power on/off — this is the one I'd flag as worth testing thoroughly on your end too if you can: my current bridge does a DTR-toggle plus repeated PS1; sends because a single one isn't always received by a powered-off FTDX3000. If SetRadioPower's existing double-PS1;-with-delay approach already handles that reliably for you, great — just didn't want it to be a surprise if it turns out to need more retries on some units.
No rush on my end — happy to wait for whatever release cycle this naturally fits into, and to test against a pre-release the same way as the ATU work.

Thanks again,
Giovanni

[mm5agm]

Hi Giovanni,

Went and checked the actual CAT command tables for both radios rather than assume, and it turned up something more specific than I expected.

The FTdx101 has the ST command I described (P1 0/1/2: off/on/quick-split), and separately has FR/FT (Function RX / Function TX) — FR there is a MAIN/SUB mute pair, FT says explicitly which band's transmitter is live. So on the FTdx101 there's actually a second, more general mechanism sitting alongside the simple split toggle.

The FTDX3000's documented command table doesn't have ST at all — I went through the full alphabetical index and it just isn't there; the only split-related entry is QS (Quick Split), which is Set-only with no Read/Answer, so more of a one-shot trigger than a queryable mode. What it does have is FR/FT too — FR picks which single band receives (VFO-A or VFO-B, since it's single-receiver), FT picks which band transmits, including explicit "band X is TX" values, not just a toggle. That's actually a closer match to what you described needing (independent RX-band/TX-band selection) than ST would have been anyway.

Here's the thing I want to flag rather than just quietly note: our own web UI's Split button sends ST{mode}; to every radio model the same way, with no per-radio branching. If the FTDX3000 genuinely has no ST command, that button may not do anything at all on your radio — and if so, it's a real bug on our side, unrelated to your external API question. I'd rather not assume the manual's still accurate, though — Yaesu has changed CAT behaviour between firmware revisions without always updating the doc, so "not in this printing of the manual" isn't the same as "the radio doesn't respond to it." Could you do me a favour and just try the Split button in the web UI against your FTDX3000 and tell me whether it visibly does anything (VFO B frequency changing, split indicator, TX actually moving to the other VFO)? Costs you nothing to check and tells me whether this is worth fixing on my end regardless of what we build for you.

For your external API split endpoint, I'm now leaning toward building it on FR/FT directly rather than ST, since that's the one mechanism that actually generalises to independent RX/TX band selection — but I want to think through what that means for the rest of the app (the internal split concept, the web UI's own Split button, state tracking) before locking anything down, so no design commitment yet. I'll come back to you once I've worked through it.

No action needed from you beyond that one quick Split-button check whenever it's convenient — no rush.

73, Colin

[mm5agm]

Hi Giovanni,

I've worked through the split question I parked, and there's a nice outcome: your independent RX-VFO / TX-VFO model is basically already how YWC thinks internally.

Going through the code, YWC already tracks two separate things live from the radio: which VFO is transmitting (from the FT command) and which VFO is receiving (from VS), plus the older simple split flag (from ST). So "RX on A, TX on B" isn't a foreign concept I'd have to bolt on — it's already the shape of the internal state, just not exposed or independently settable yet. That makes your ask the natural fit rather than the awkward one, which is the opposite of what I feared when I said I wanted to think it through.

So here's where I've landed for the external API split:

• I'll model it exactly as you described — independent rxVfo and txVfo — and build it on FT/VS rather than the old ST toggle, since those generalise across models where ST doesn't. Split-on is simply "TX VFO ≠ RX VFO," reported as a derived value rather than a separate on/off you'd have to keep in sync.
• For v1 I'm scoping this to the single-receiver radios (your FTDX3000, and the FTdx10/FT-710), where "which VFO" is unambiguous. The FTdx101 is genuinely more complex — it's a true dual-receiver, and its RX-side command (FR) is a MAIN/SUB mute pair rather than a simple A/B selector — so I'd rather do that properly in a later revision than half-do it in v1. It doesn't affect you, but I'd rather say so up front than surprise you later.

On the two things you flagged:

Split button on the FTDX3000. Your instinct to have me double-check was well placed — the more I look, the more I think our own web UI Split button currently does nothing on your radio, because it only ever sends ST, which (per the manual) your FTDX3000 doesn't have. If your quick test confirms that, I'm treating it as a real bug on our side and folding the fix into this same work — the fix is to drive split via FT on the FTDX3000, which is exactly the mechanism the external API will use anyway. So the two efforts converge rather than compete. Still value that one-line "does the button visibly do anything?" check whenever it's convenient.

Radio power-on. Honest answer here: YWC does send PS1; twice with about a 1.5-second gap, which helps a sleeping radio, but it does not do the DTR-line toggle your bridge does — YWC holds DTR high for the whole session rather than pulsing it. So I can't promise our current approach wakes every powered-off FTDX3000 the way your DTR toggle does. If the external API's power-on turns out flaky on your unit, adding a DTR pulse is a known lever I can pull. Out of interest: in your experience, is the double-PS1; alone ever enough on your radio, or is the DTR toggle the thing that actually does it? That'd tell me whether I need to build the pulse in from the start.

One implementation detail I may come back to you on: when it's time to set which VFO receives on the FTDX3000, there are two candidate commands (VS and FR), and I'd rather confirm which one your radio actually acts on than guess from the manual — likely a small test against your rig when I've got a pre-release ready.

No rush on any of this — same relaxed pace as the ATU work, and I'll point you at a pre-release to test when it's built.

73, Colin

[mm5agm]

Hi Giovanni — separate from the external-API discussion, but while I have you: v2.4.2-pre12 includes a fix to the FTDX3000 roofing-filter read-back. The radio reports its roofing filter in a different code space than the one used to set it, which was mislabelling 600 Hz / 300 Hz and desyncing the dropdown in AUTO — that's now corrected (verified against the CAT manual and Hamlib). If you get a chance to check the roofing dropdown behaves correctly on your FTDX3000, I'd appreciate the confirmation, since I can only test it on my FTdx101.

https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre12

73, Colin

[mm5agm]

Quick correction on the version, Giovanni — please grab v2.4.2-pre13 rather than pre12. A settings-save bug slipped into pre12 (the Settings page could silently fail to save if the new TX-toggle key was left blank, which it is by default) — that's now fixed in pre13. The FTDX3000 roofing-filter fix I mentioned is in pre13 as well, so it's the one to test.

https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre13

Thanks, and sorry for the version shuffle!
73, Colin

[iu1teu]

Hi Colin,

Tested all three, here's what I found:

Split button — confirmed, it does nothing at all on my FTDX3000. No VFO B frequency change, no split indicator, TX stays put. So your suspicion was right: it's a real no-op on this radio, not just me missing something subtle. Good that the fix (driving it via FT instead of ST) is the same mechanism you're already building for the external API split — one piece of work covering both.

Radio power-on — good news here: the double-PS1; approach already works reliably on my FTDX3000 as-is, no DTR pulse needed. My own bridge does the DTR toggle mostly out of caution from earlier, flakier attempts — it's not evidence that YWC's simpler approach is insufficient. I'd say don't add the DTR pulse preemptively; if it turns out to matter for some other unit/model down the line, that's the moment to reach for it.

Roofing filter (pre13) — confirmed correct now, AUTO mode shows the right 600Hz/300Hz labeling on the FTDX3000. Thanks for the fast turnaround on that one, and for flagging the pre12→pre13 mixup before I grabbed the wrong build.

73, Giovanni

[mm5agm]

Hi Giovanni,

Thanks for testing all three so thoroughly — exactly what I needed.

• Roofing (pre13): confirmed correct on your FTDX3000 — that closes it out.
• Power-on: taking your advice — I'll leave YWC's double-PS1; as-is and not add a DTR pulse preemptively. Good to know the simpler approach is reliable on your unit.
• Split button: you were right, it was a real no-op — the FTDX3000 has no ST command, which is all the button was sending. I've fixed it to drive split through FT instead (which VFO transmits) — the same mechanism we'll use for the external-API split, so one piece of work covers both, just as you noted.

That fix is in v2.4.2-pre14: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre14 — since I can only test on my FTdx101, I'd appreciate you confirming the Split button now actually does something on your FTDX3000 (VFO B becomes the TX VFO, split indicator shows, TX moves to the other VFO).

Thanks again — your testing keeps the FTDX3000 side honest.

73, Colin

[iu1teu]

Hi Colin,

Confirmed on my end too — the Split button now works correctly on the FTDX3000: VFO B becomes the TX VFO, the split indicator shows, and TX properly moves to the other VFO. pre14 closes that out, thanks for the fast turnaround.

One separate bug I noticed while retesting: the +5k button doesn't do anything at all — no frequency change, no visible effect of any kind.

While we're on the split topic, one more thing worth raising — about the web UI itself this time, not the external API. Right now pressing Split only ever sets VFO B as the TX VFO; there's no way to do the reverse (TX on A, RX on B) or to run both RX and TX on VFO B. My own app already treats RX-VFO and TX-VFO as two fully independent selections, so a user isn't limited to "A receives, B transmits" as the only shape split can take. Since YWC's internal state already tracks FT and VS separately for the external-API work, it sounds like the web UI's Split button could expose that same independent RX/TX selection rather than just the one fixed direction — figured it's worth flagging in case it's a small lift on top of what you're already building.

73, Giovanni

[mm5agm]

Hi Giovanni,

Thanks for confirming the Split button now works properly on your FTDX3000 in pre14 — good to have that closed out.

On the +5k button — you were right, it was doing nothing, and I found the cause. The Quick Split code was formatting the VFO B frequency with too many digits (11 instead of 9), so the radio rejected the command outright and VFO B never moved. On your FTDX3000 that bad command ran just before the split-enable step, which is why you saw no effect at all rather than just a missing offset. It turned out to affect every model, not only yours — I confirmed +5k was broken on my own FtdX101MP too, it had just never been exercised. It's fixed now and will be in the next build I put out; I'd appreciate you confirming it on the FTDX3000 when it lands.

On your independent RX/TX split idea — yes, I want to do this, and I agree it's the right shape. The plan is to add two independent selectors to the web UI — one for the RX VFO and one for the TX VFO — so split isn't locked to "A receives, B transmits." Split then simply means RX and TX are on different VFOs, and you get the reverse (B-RX / A-TX) and both-on-one-VFO cases for free. It's built on the same FT/VS work as the external API, so the two land together. I'm scoping it to the single-receiver radios first (FTDX3000, FTdx10, FT-710); the dual-receiver FtdX101 comes later, since its FR behaves differently (a MAIN/SUB mute pair rather than a simple A/B receive select).

One thing I need from your radio before I wire up the RX side. The TX half is settled — FT already drives it, as your working Split button shows. But I'm not certain which command actually moves the receive VFO on the FTDX3000, and I don't want to guess and have the RX selector silently do nothing. When you have a moment, could you try these directly through your own CAT tool and tell me what the radio does:

• FR0; then FR1; — does the receiver switch between VFO A and VFO B?
• VS0; then VS1; — does that switch it, or is it ignored?
• And do either of them answer a read query (FR; / VS;)?

Whichever one reliably changes the receive VFO is the one I'll build the RX selector on.

And — are you happy to keep testing this as I build it? Since it's single-receiver-only, I can't exercise it on my own dual-receiver '101, so your eyes on the FTDX3000 are what will make it solid.

73, Colin

[mm5agm]

One more thing, Giovanni — I've written up a concrete proposed shape for the dedicated external API (endpoints, response format, and a few questions on units/PTT) as its own discussion, so other folks building on YWC can weigh in too:

👉 #83 — External API v1 — proposed spec (feedback wanted)
#83

Since you're the one driving this, your feedback there is the one I most want before I build it. The VS/FR question above is separate (that's for the web-UI split) — no need to mix the two.

73, Colin

[iu1teu]

Hi Colin,

Nice catch on the +5k bug — makes sense it slipped through if nothing had exercised that code path before. Happy to confirm it on the FTDX3000 once the fix lands in a build.

On the RX-VFO command, I don't need to test blind: my own CAT bridge already drives exactly this against a real FTDX3000 in daily use, so I can give you a confirmed answer from working code rather than a one-off manual test.

FR is the right command, but not FR1;. Per the CAT manual and what I've had running reliably in production: FR0; = VFO-A RX (VFO-B off), and FR4; = VFO-B RX (VFO-A off) — the single-receiver FTDX3000 uses 0/4 as its RX-select values, not 0/1. FR1; isn't something I use, and I wouldn't assume it does what you want.

On TX: FT0;/FT1; is exactly what I use too, which lines up with what already fixed the Split button.

I've never used VS at all in my bridge, so I don't have a data point either way on VS0;/VS1; on this radio — can't confirm or rule it out from experience.

One thing worth flagging on the read-query side, since you asked specifically: my app doesn't actually poll FR; for confirmation. Instead it infers the active RX VFO indirectly — comparing MD0; (the mode of whichever VFO is currently active) against the VFO-A mode embedded in byte 20 of the IF; response; if they differ, VFO B must be the one in RX. I genuinely don't know if that's because FR; read-back turned out unreliable on this radio at some point, or just how the polling loop happened to get built that way — so take it as "here's a method that's known to work," not as evidence FR; itself doesn't answer a read query. If a definitive answer on that would help, I'm happy to test FR;/FR0;/FR4; directly against the radio and report back exactly what it does — just say the word.

Also saw #83 — I'll go read through the proposed external API spec and give you feedback there separately.

73, Giovanni

[mm5agm]

Hi Giovanni,

That's exactly what I needed — a confirmed answer from working code beats a one-off test every time. Thank you.

So I've built it to that: RX select via FR0; / FR4; (good catch on 0/4 — I'd have burned time on FR1; otherwise), TX via FT0; / FT1;, and split derived from "TX VFO ≠ RX VFO" rather than a separate toggle. For the other single-receiver radios (FTdx10/FT-710, which have no FR) I've kept the VS path.

It's the two RX/TX selectors we discussed, in the web UI, single-receiver radios only. It's on a branch now and builds cleanly, but since I can't exercise split on my own dual-receiver '101, you're the one who'll tell me whether it actually does the right thing on the FTDX3000 — I'll get it into a pre-release for you shortly.

On the read-back: I don't think I need FR; polling for this — YWC already tracks the active VFO as its own source of truth (thanks to your #81 work), and derives split from that, so the selectors follow the radio without me having to trust an FR; answer. I'll keep your offer to test it directly in reserve in case the derived state ever disagrees with the radio.

73, Colin

[mm5agm]

Hi Giovanni,

Both are now in v2.4.2-pre16: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre16

(pre16 is the one to grab — it's pre15 plus a small unrelated fix. The in-app updater ignores pre-releases, so you'll need the direct link.)

Two things to try on the FTDX3000 when you have a moment:

1. The +5k button. You said you'd confirm once it shipped — this is it. Press +5k and VFO B should jump to VFO A + 5 kHz with split engaging (and the button gives a brief flash).

2. The new independent RX/TX selectors. On the toolbar next to Split/+5k you'll now see two small button pairs — RX [A|B] and TX [A|B] (single-receiver radios only). These are built on exactly the commands you gave me:

• RX drives FR0; (A) / FR4; (B)
• TX drives FT0; (A) / FT1; (B)
• Split is derived — it's on whenever RX and TX are different VFOs.

The things I'd most like confirmed, since I can't exercise any of this on my dual-receiver '101:

• Does RX B actually move your receiver to VFO B (i.e. is FR4; right in practice, not just on paper)?
• Does reverse split — RX on B, TX on A — work the way you wanted?
• Does the selected RX button (filled) and TX button (red when split) match what the radio is actually doing?

This is completely untested on real hardware — it builds cleanly here and that's all I can vouch for — so your eyes on it are what will tell me whether it's right. Anything that behaves oddly, however small, is useful.

73, Colin

[iu1teu]

Hi Colin,

Tested both on the FTDX3000 with pre16.

RX/TX selectors — all three checks confirmed, fully working:

• RX B genuinely moves the receiver to VFO B — FR4; is correct in practice, not just on paper.
• Reverse split (RX on B, TX on A) works exactly as expected.
• The button states track the radio correctly — filled RX button and red TX button match what the radio is actually doing, in every combination I tried.

This is exactly the RX/TX-independent behavior my own app already does, so I can say with confidence it's right, not just "seems fine."

+5k — improved but not quite there yet. It's no longer a full no-op like before: pressing it now engages split correctly, but it doesn't actually add the 5 kHz offset to VFO B — VFO B stays wherever it already was rather than jumping to VFO A + 5 kHz. So the split-enable half of the fix landed, but the frequency-offset half didn't.

Separate issue, unrelated to either of the above: right now frequency doesn't sync in either direction. Changing frequency from the web UI doesn't move the radio at all, and turning the VFO knob on the radio itself doesn't update what the web UI shows. Not sure if this is a known gap or something that regressed recently, but flagging it since it's a pretty fundamental piece of the CAT link.

Let me know if there's anything else useful to check on my end for any of these.

73, Giovanni

[mm5agm]

Hi Giovanni,

Brilliant — thank you for confirming the RX/TX selectors so thoroughly, the FR4; RX-move and reverse split especially. That's exactly the hardware validation I needed.

On the frequency sync, one quick check before I dig in, because I suspect it's tied to the testing rather than a separate break. Selecting RX B leaves VFO A's receiver off (that's what FR4; does), but YWC's main frequency display and click-to-tune are still VFO-A-centric — so if the radio's now operating on B, changing "the frequency" in YWC touches A (which you're not hearing) and the knob on B doesn't update the A display. That would look exactly like total desync.

So: does normal frequency sync come back if you set RX back to A and turn split off — or after a power-cycle?

• If yes → it's that VFO mismatch, and the real fix is mine: YWC's frequency UI should follow the RX VFO, not assume A.
• If no (still dead with RX on A, split off, fresh start) → it's a genuine regression and I'll chase it properly; a log from that state would help.

I think +5k is the same root — its offset is a frequency write to VFO B, so if writes aren't landing it won't move. Let's settle the sync first and I expect +5k to follow.

73, Colin

[iu1teu]

Hi Colin,

No — it's not the VFO mismatch. I tested exactly that: RX left on A, split untouched (off), and I also closed and reopened YWC entirely to rule out any leftover state.

On a fresh open, YWC correctly reads and displays both VFO A and VFO B frequencies once. But after that, VFO A's frequency doesn't live-update in either direction — changing it in the web UI doesn't move the radio, and turning the knob doesn't move the web UI's display. No split, no RX-B involved at any point.

So this looks like a genuine regression in the live sync loop rather than the display-follows-wrong-VFO issue you suspected — sounds like it's worth chasing properly as you said.

Diagnostics from the About page:

YWC Version    2.4.2-pre16 (released 2026-07-20)
Radio model    FTDX3000
Band plan      Region1
Serial port    COM7 at 38400 baud
Connection     connected
SDR device     (none configured)
DX cluster     (off)
Cluster login  (blank)
Browser        Microsoft Edge 150
.NET runtime   10.0.9
Operating sys  Microsoft Windows 10.0.26200
CPU            Intel(R) Celeron(R) N5105 @ 2.00GHz, 4 logical cores
Memory         7,8 GB
Tested fw      FTdx101MP: Main=V01-28 Display=V01-51 MainDSP=V01-20 SubDSP=V01-20 MainSDR=V02-08 SubSDR=V02-08 AFDSP=V01-00

No errors in the F12 console.

73, Giovanni

[mm5agm]

Hi Giovanni,

That's the perfect test — restarting fresh with RX on A and split off rules out my theory completely. You're right, it's a genuine regression in the live sync loop, and thank you for being so precise about it.

Here's what's going on under the hood: YWC gets live frequency updates from the radio's auto-information (AI1;) broadcasts, not by polling — so "reads once at startup, then nothing" tells me the auto-info path has stopped flowing after the initial connect. I need to see it happen in a log to know why.

Could you grab a ywc-<date> log of exactly this sequence:

1. Start YWC fresh and let it connect (both VFOs read once, as you described)
2. Turn the VFO knob on the radio a few times
3. Change the frequency once from the web UI (click-to-tune or the keypad)

Then attach the log here. That'll show me whether the radio is auto-sending frequency frames at all, and whether YWC's commands are still going out after init — which will point straight at the cause. Your setup (real FTDX3000 on COM7 at 38400) is the first live-sync test on that path in a little while, so this is genuinely useful.

73, Colin

[mm5agm]

Hi Giovanni,

Found it — and it's a good one. The write side was failing because of a frequency format difference I hadn't accounted for: the FTDX3000 uses 8-digit FA/FB frequency values, but every other radio YWC supports uses 9, and YWC was sending 9 to all of them. So when you tuned from the browser, YWC sent the FTDX3000 a 9-digit FA command it couldn't parse, and it silently ignored it — which is exactly why the display and the knob worked but browser writes (and +5k) didn't. Reads were fine because YWC just parses whatever the radio sends back, and your radio reports 8 digits (FA14073310; in your log — that's what gave it away).

The fix: YWC now learns each radio's frequency width from its own responses and formats writes to match, so the FTDX3000 gets 8-digit commands. It's in v2.4.2-pre18: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre18

When you get a chance, could you confirm on the FTDX3000:

• web → radio: changing frequency in the browser should now move the radio — please confirm, and
• +5k: now sets VFO B to VFO A + 5 kHz and enables split (same write path, so I'd expect it to come right too).

Between the polling fallback in pre17 and this, both directions should finally be solid. Thanks again — your log had the answer sitting right in it.

73, Colin

[iu1teu]

Hi Colin,

No change on pre18, unfortunately — same as pre17. Web → radio still doesn't move the radio, and +5k still doesn't work either.

Grabbed a fresh log on pre18 with the same sequence as before (fresh start, knob turns, one frequency change from the web UI) — attached below.

73, Giovanni
ywc-20260720.log

[mm5agm]

Hi Giovanni,

Thanks for the quick turnaround — and sorry, pre18 clearly didn't do it. I've realised my [sent] log was misleading me: it records the command before the width fix is applied, so I genuinely can't tell from your log whether YWC put 8 or 9 digits on the wire. Rather than keep guessing, two things to nail it down:

1. A quick isolation test — no new build needed. Could you try changing frequency from the browser with only YWC connected to the radio — i.e. close your own CAT bridge and WSJT-X first, so nothing else is sharing the VSPE link? If the write suddenly works with YWC alone, it tells me this is a collision on the shared link (three apps writing to one port), which is a very different fix. If it still fails with YWC alone, it's the command itself.

2. A diagnostic build. I've put out v2.4.2-pre19, which logs the exact frequency command after the width fix — so we can finally see whether it goes out as 8 or 9 digits: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre19

If you grab a fresh log on pre19 (same sequence — fresh start, one frequency change from the browser), look for a line tagged [wire] freq write ->; it shows the actual command sent and the digit count YWC learned for your radio. That plus the isolation test should pin it down for certain.

Really appreciate your patience with this one — the read side is solid now, and this write path is the last piece. I'm giving up for today, but I'll be back at it tomorrow.

73, Colin

[iu1teu]

Hi Colin,

Went through the pre19 log carefully — no [wire] line anywhere in it, so that diagnostic doesn't seem to be firing at all on this path.

But the existing [sent] lines already answer the question on their own: they clearly show 9-digit frequency values still going out — FA021076300;, FA021076100;, FA021076000; from the browser test, and the same pattern on VFO B (FB014074250;, etc.). So the width fix doesn't appear to be applied on this write path even in pre19. And matching that: none of those [sent] FA... lines is followed by the radio echoing the new frequency back — just the usual TX0;/SM00xx;/AN010; telemetry, no FA confirmation — consistent with the radio silently rejecting a 9-digit command it can't parse.

Log attached again for reference.

73, Giovanni
ywc-20260720.log

[mm5agm]

Hi Giovanni,

Your "no [wire] line" catch was the whole answer — thank you. It told me the fix wasn't running on the write path at all, and here's why: I'd put the 8-digit fix (and that diagnostic) on YWC's command-queue path, but frequency writes go out through a different, direct path that bypasses the queue. So pre18 and pre19 never actually sent an 8-digit command — I was patching a path these writes don't use. Nicely spotted from the log.

I've moved it to the path the writes really take. v2.4.2-pre20: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre20 — this is the first build that genuinely sends 8-digit frequency commands to the FTDX3000.

Whenever you get to it (no rush — tomorrow's fine):

• Change frequency from the browser and see if the radio moves now, and check +5k.
• If you grab a log, the [wire] freq write -> line should finally appear this time — it'll show FA14…; (8 digits) if the fix is doing its job.

If it now sends 8 digits and the radio still ignores them, then we're into the shared-link theory and that only-YWC test becomes the next step — but let's see if the format fix alone does it first.

Thanks again for the sharp log-reading — that's what turned this around.

73, Colin

[iu1teu]

Hi Colin,

Tested pre20 — victory! Both directions of frequency sync work perfectly now (web ↔ radio, and radio → web via the knob), and +5k finally works too, setting VFO B to +5 kHz and engaging split correctly.

This one's fully resolved on my end. I did grab a log from the pre20 test just in case, but since everything's working I won't attach it unless you want it for confirmation.

Thanks for sticking with it through all the iterations — the log-reading back-and-forth paid off.

73, Giovanni

[mm5agm]

Hi Giovanni,

Brilliant — thank you. That's the write path sorted, and between pre17's polling and pre20's format fix the FTDX3000 frequency sync is solid both ways, plus +5k. No need for the log — "it all works" is exactly the result I wanted.

I owe you a real thank-you for this one. You carried the FTDX3000 through a long chain of pre-releases — the split fix, the +5k catch, the auto-info diagnosis, and then the frequency-width detective work that your log-reading cracked wide open. YWC's FTDX3000 support genuinely exists because of your testing, not my reading of the manual.

Which brings me to what I wanted to ask: from everything you've put it through, do you think we can now confidently say YWC works with the FTDX3000? You've exercised frequency (both directions), mode, split — including the independent RX/TX selectors and reverse split — +5k, ATU, roofing filters, meters, and the connection/power handling, so you've covered more of it than anyone. If you're happy it's solid, I'll gladly state the FTDX3000 is fully supported and tested. And if there's anything still on your "not quite right" list, now's the moment — I'll chase it.

Either way, these fixes will land in the next full release. Thanks again — this was a proper collaboration.

73, Colin

[iu1teu]

Hi Colin,

I've tested every control feature the panel exposes and they all work correctly at this point.

One thing still leaves me uncertain, though: the power meter. If I set max RF power to, say, 40W, the meter can still show the radio outputting something like 70W — well above the configured cap. That shouldn't be possible, so either the reading itself is wrong (a scaling/calibration issue, maybe similar to the VDD conversion mismatch we found back in #75) or something's off in how it relates to the power setting. Worth looking into before calling this fully buttoned up.

Apart from that one, I'd say we're there — frequency (both directions), mode, split (including independent RX/TX and reverse split), +5k, ATU, roofing filter, meters otherwise, and connection/power handling have all held up under real testing on the FTDX3000.

73, Giovanni

[mm5agm]

Hi Giovanni,

That's a great result — thank you for putting it through everything. And you were spot-on about the power meter: it's a calibration issue, not a functional one.

I dug into the cause: YWC's default power-meter calibration for the FTDX3000 is currently just a copy of the FtdX101MP's. The '101 is a 200W radio and its power-meter ADC scales differently from the FTDX3000's, so that borrowed curve reads high on your 100W rig — which is exactly your "40W showing as 70W." Same "borrowed scaling" story as the VDD mismatch on #75.

The good news: if you calibrate it, we can bake your numbers into YWC so every future FTDX3000 user starts correct. Could you do the Power meter on the Calibration page:

1. Open the Power (PWR) calibration — the page shows a live Current RM Value (the raw meter reading) at the top.
2. Key the radio at a few known output levels — against an external wattmeter, or your radio's own power reading if you trust it — say 5, 10, 25, 50, 75, 100 W.
3. For each, read the Current RM Value and add a row: Label = actual watts, Raw = that RM value. (The FTDX3000 is 100 W, so the top point should be 100, not 200.)
4. Save.

Then send me the result — either your calibration.user.json (in %APPDATA%\MM5AGM\Yaesu Web Control\) or just the watts/raw pairs you entered — and I'll fold them into YWC's FTDX3000 default. Once that's in, I'll cut the full v2.4.2 release, and the FTDX3000 will read correctly straight out of the box.

Thanks again — this has been a proper team effort. You've essentially made the FTDX3000 a first-class supported radio.

73, Colin

[mm5agm]

One extra bit of context, Giovanni — while I was in there I checked the rest of your FTDX3000's default calibration, and it turns out the whole set, not just power, is currently inherited from the FtdX101MP: every meter curve is identical. So the FTDX3000 has genuinely been running on the '101's numbers all along.

Power is the one that's clearly wrong, because of the 200 W vs 100 W difference — so that's the priority, and your calibration will sort it. The rest are a mixed bag: temperature, PA voltage and the SWR ratio may well be close enough between the two radios (probably why they looked fine to you), while the S-meter and IDD are more radio-specific.

The S-meter is actually the easiest of the lot to do — no signal generator needed. The RF/SQL control should let you produce a range of different S-meter readings as you move it, which you can capture as your calibration points straight off the Calibration page.

I don't want to send you down a rabbit hole calibrating everything — power alone makes the FTDX3000 solid for the release. But if you fancy knocking off the S-meter too while you're there (or SWR against a known load later), the same Calibration page handles it, and I'll gladly fold whatever you send into the FTDX3000 defaults. No pressure — power's the one that matters right now.

73, Colin

[iu1teu]

Hi Colin,

I'll get the power calibration readings done as soon as I can — I need to pick up a dummy load first before I key the radio at those levels, so it'll take a little while, but I'm on it.

73, Giovanni

[mm5agm]

Hi Giovanni,

You don't necessarily need to buy a dummy load for this — your normal antenna will do as long as it's a low SWR on the band you test on (through your tuner if need be). The only thing that really matters for the calibration is that the radio is genuinely putting out the power it's set to.

That's the catch with a mismatched antenna: on higher SWR the FTDX3000's ALC/protection folds the power back, so a "100 W" setting might only deliver 70 W — and you'd be pairing the wrong wattage against the raw reading. Into a good match (or a dummy load's clean 50 Ω) the radio delivers each level accurately, which is why the dummy load is the textbook choice — that, and it keeps your string of test carriers off-air.

So: if your antenna's a good match on a quiet frequency, just use it — set a few power levels, note the raw "Current RM Value" against each, and you're done. If the SWR's up where you'd transmit, or you'd rather not radiate a carrier while stepping through the levels, then a dummy load is the cleaner route. Either works fine.

73, Colin

[iu1teu]

Hi Colin,

Since we're already this deep into it, I'd rather do it properly. I'm going to borrow a dummy load from a ham friend and take accurate measurements, so we can get everything calibrated as well as possible — power for sure, and I'll knock out the S-meter too while I'm at it.

73, Giovanni

[mm5agm]

Perfect — I really appreciate you doing it properly. No rush at all; borrow the dummy load whenever suits. Send me the power and S-meter numbers when you've got them and I'll fold both into the FTDX3000 defaults. Getting a proper two-meter calibration out of this makes the radio genuinely first-class — thank you, Giovanni.

73, Colin

[mm5agm]

Hi Giovanni,

Quick follow-up so you're all set for when the dummy load turns up. I've put out a new test build, v2.4.2-pre21, that makes sending me your calibration painless -- no file-copying involved.

Download: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre21

Grab Yaesu_Web_Control_Setup.exe under Assets. It's a pre-release, so my in-app updater won't offer it automatically -- this direct link is the only way to get it.

When you're ready to calibrate:

1. Open Meter Calibration from the menu.
2. Key the radio at known power levels into the dummy load and set the calibration points so YWC matches your reference wattmeter. Do the same for the S-meter if you have a signal source.
3. Click the "Email calibration to developer" button. That opens an email to me with your calibration data filled in (it's also copied to your clipboard as a backup -- if the email looks empty, just paste before sending).

That's it. I'll fold your power and S-meter figures straight into the FTDX3000 defaults so every FTDX3000 owner gets accurate meters out of the box, with full credit to you. No rush at all -- whenever the dummy load is sorted.

73, Colin