[FEATURE] Expose ATU control (RIG_FUNC_TUNER) over the rigctld bridge

[iu1teu]

What would you like YWC to do?

Expose antenna tuner (ATU) control through the built-in rigctld server on port 4532, using the standard Hamlib get_func/set_func command pair with the conventional TUNER function name:

• get_func TUNER (and short form u TUNER) → report current ATU state
• set_func TUNER 1 (and short form U TUNER 1) → engage the tuner / start a tune cycle
• set_func TUNER 0 (and short form U TUNER 0) → disengage / bypass the tuner

I checked Services/RigctldServer.cs in the repo, and both the single-character and long-form command switches currently have no func/u/U case at all — anything not explicitly matched falls through to RPRT -1. So as far as I can tell this would be new functionality, not a bug.

For the actual radio behaviour to map to, YWC's own manual documents it precisely (§5.10, ATU button): a short tap toggles ATU on/off, a long press (≥500 ms) starts the auto-tune cycle. On the CAT side, on the FTDX3000 (and I believe the same family across the other supported Yaesu rigs) this is:

• AC; → query, response ACxxx; where the tuner-state digit is 0 = off, 1 = on, 2 = tuning in progress
• AC001; then AC002; → engage tuner (no-op if already on) then start the tune cycle

Since YWC's own UI already implements this exact sequence for the ATU button, the rigctld handler would presumably just need to call into the same internal service that button already calls, rather than talk to the radio directly.

One open design question I'll leave to you as the person who knows the internals: Hamlib's get_func model is a boolean (0/1), but the radio has a third "tuning in progress" state. Whatever's cleanest is fine on my end — e.g. set_func TUNER 1 triggering the full tune sequence and get_func TUNER just reporting on/off (1 while tuning too, since the tuner is "engaged" during that phase) would already cover my use case.

Why is this useful?

I run a custom desktop app for my own shack (Cluster/Digimode/Log automation for FT8 work) that currently talks to the radio through my own small CAT-server bridge, specifically because it needs ATU tune control, which no Hamlib-protocol path exposes. I already run that CAT server alongside YWC and WSJT-X concurrently — each on its own VSPE virtual serial port, all sharing the one physical CAT link — so serial contention isn't the issue.

The only thing still keeping my app on a separate raw-CAT connection instead of talking to YWC's rigctld bridge like WSJT-X and Log4OM already do is this one missing function. If TUNER were exposed over rigctld, I could drop my own CAT server entirely and consolidate everything through YWC, which would also mean one less thing polling the radio directly.

I'd guess any other rigctld client that wants remote ATU control (there's a handful of shack-automation and remote-op tools that use plain Hamlib NET rigctl) would benefit the same way, not just my app.

Are there any references?

-Standard Hamlib rigctl protocol: get_func/set_func with function name TUNER (RIG_FUNC_TUNER) is the conventional way rigctl clients request tuner engagement — this is what a generic Hamlib-aware client would try first.

• YWC's own front-end already implements the equivalent behaviour: USER_MANUAL.md §5.10, "ATU button" (short tap = toggle, long press = tune cycle).

Which radio(s) and operating mode(s) would benefit?

I'm specifically on an FTDX3000, but since ATU control is one of the four radios' shared feature set (per the support table in the README), exposing it generically over rigctld should benefit FTdx101MP/D, FTdx10, FT-710 and FTDX3000 alike — same CAT command family (AC) across the range, just gated by "only applies to radios fitted with an internal or external ATU" like the front-end button already is.

[mm5agm]

Hi iu1teu,

Thanks for such a thorough write-up — the command mapping and the RigctldServer.cs reference make this easy to act on. You'''re right that there'''s currently no func/u/U handling at all, and the good news is the ATU logic itself already exists and is tested (the front-end ATU button already does exactly the AC/AC002 sequence you described), so this is mostly wiring rigctld'''s handler to that existing logic rather than building something new.

Your suggested design (report "on" during tuning too, since the tuner is engaged either way) sounds right to me and avoids inventing a three-state Hamlib response that most clients would not expect anyway.

I have not started it yet, so no firm date, but it'''s a well-scoped addition and I'''d expect it to land in a normal release cycle rather than needing anything special — realistically sometime in the next couple of weeks. I'''ll update this discussion once it'''s in a pre-release for you to test.

[mm5agm]

Hi Giovanni,

v2.4.2-pre8 is out and adds ATU control over rigctld: https://github.com/mm5agm/Yaesu_Web_Control/releases/tag/v2.4.2-pre8

get_func/set_func TUNER (short forms u/U) are now implemented, wired to the same AC command the on-screen ATU button already uses. You can query and toggle the tuner over rigctld, and it stays in sync with the web UI'''s ATU indicator in both directions. Since Hamlib'''s get_func is boolean but the radio also has a "tuning in progress" state, get_func TUNER reports "on" throughout an active tune cycle too, rather than inventing a three-state response — matches what you suggested in the original discussion.

I'''ve tested it against my own FTdx101MP over raw rigctld commands and confirmed both the radio'''s physical TUNE LED and the web UI indicator track correctly. Could you give it a try with whatever you'''re driving it from and let me know if this meets what you were after?

Also — thank you for the coffee! That'''s now bought me a very nice bottle of Valpolicella Ripasso. Much appreciated.

Colin

[iu1teu]

Hi Colin,

Just to close the loop — updated to pre9 and tested u TUNER / U TUNER 1 against my FTDX3000 over rigctld: works exactly as expected, tracks the physical TUNE state correctly (including staying "on" through a tune cycle, not just after), and matches the web UI's ATU indicator throughout. Turnaround from request to working pre-release was one day — really appreciate it.

That's everything I needed from this one. Thanks again, and enjoy the Ripasso!

Giovanni

[mm5agm]

Glad it's working exactly as intended, Giovanni — thanks for confirming on real hardware, and for the FTDX3000 data point too. Closing this one out now.

73, Colin