Rig: Raw CAT command after tuning to a spot (rig profile)

[oh2gba]

Why

Some rigs have two receivers, for example the Yaesu FTDX101 (MAIN and SUB). An operator with two antennas can listen to the same DX station on both at once, which is a real help on a weak signal: different antenna, different fading, different noise. For that both receivers must sit on the DX frequency in the DX mode, each with its own antenna.

Today a click on a spot tunes the main receiver only. Getting the second receiver there means reaching for the rig after every click.

The obvious CAT shortcuts do not do the right thing:

• A=B copy (AB;, Hamlib RIG_OP_CPY) copies the whole receiver setup, including the antenna selection, so both receivers end up on the same antenna. That defeats the purpose.
• Tuning VFO B frequency and mode individually works, but only over a VFO-addressed connection. Behind rigctld that means switching the connection into VFO mode, which changes every command QLog sends, and it costs three more commands per click.
• The rig has exactly the right command: SY2; (SYNC on + copy frequency and mode to the sub). Antenna, filters and everything else on the sub stay as they are. It is the CAT form of holding the SYNC key.

A command like that is rig specific, so QLog should not know it. Instead the rig profile gets a free field for it.

What

• Rig profile: a text field CAT after spot tuning, next to DX Spots to Rig, empty by default. Whatever is in it is sent to the rig as a raw CAT command at the end of a spot tune, from the DX cluster, the alert window and the bandmap double-click. The tooltip names the FTDX101 example.
• GenericRigDrv::sendRawCommand() with a no-op default. HamlibRigDrv sends the bytes with rig_send_raw() on a direct link. Behind rigctld that socket speaks the rigctld protocol, so the driver opens a short second connection to rigctld and forwards the command with rigctld's send_cmd_rx and 0 reply bytes; it returns in about 10 ms and the Hamlib link is not touched. (Using rig_send_raw() on the rigctld link itself blocked the rig thread for 20 s per command, found in testing.)
• Rig::sendRawCommand() queues it like every other rig command, so it runs after frequency and mode.
• Migration 042 adds rig_profiles.spot_tune_command.

Text CAT protocols are covered (Yaesu, Kenwood, Elecraft and the like). Icom's binary CI-V is not: the field is plain text and nothing is sent unless the operator fills it in.

Verification

• Builds on Linux (Qt 6.8, Hamlib 4.6.2). MigrationTest passes with the new migration (44 tests).
• Used for an evening on a Yaesu FTDX-101D via rigctld with SY2; in the profile: after a spot click both receivers sit on the spot in the spot's mode, each on its own antenna. The command returns in about 10 ms and does not block the polling.
• Not tested: direct serial connection (same rig_send_raw() call without the rigctld wrapper), other rig families, Windows, macOS.

[foldynl]

I think it’s better to discuss the idea first rather than spend tokens on implementing it. There is a similar PR, #953 , which I’m having trouble accepting because I don’t think sending raw commands at startup is really the right thing to implement in QLog anymore.

Now there is a proposal to send raw commands when clicking on a spot. What will come next? It’s better to discuss the problem first and implement it afterwards. Otherwise, we could easily end up with QLog having thousands of settings for every possible use case. I’m always open to discussion ;-)

[oh2gba]

Thanks, and I understand the worry about QLog growing a setting for every operator's habit.

On "discuss first", I have to disagree, from experience. I have been trying to describe the "alert me until it is confirmed" idea in words since October 2024, in #488, #726, #871 and #913, and it never landed. The moment there was something to click on, #1174, it was understood in a day. So for me a small working example is the better start for a discussion, not a replacement for it. Code is cheap now, good ideas are sparse. And it is always easier to look at something that exists and say what is wrong with it than to build the first version, so I am glad to take that part.

These ideas are not just for fun, they solve a problem. If one person takes the time to explain it, it is quite likely that many more are facing the same thing and just never wrote it down. What I can bring is what I have learned on the air over the years, the things that work for a DXer in practice, and I would like that to end up useful for others too.

This PR is meant as exactly that, a concrete thing to test and argue about. The 'problem' behind it: the FTDX101 has two receivers, I have two antennas, and after a spot click I want both receivers on the DX, each on its own antenna. A=B copies the antenna too. The rig's SYNC command does the right thing, but it is Yaesu only, so I put it behind a free text field rather than hard-code it. With #953 there are now two working examples of a raw command reaching the rig, one at startup and one after a spot. Easy to try, easy to think about, easy to improve or to throw away. If you feel "second receiver follows the spot" belongs in Hamlib terms, with no raw commands at all, then go ahead and send that in as a PR, and let those who care test it and improve it. That is how the better version will show up, not in a thread.

Last, and I mean this warmly: I appreciate the work you put into QLog. It matters a lot to me, and I guess to many others, there is nothing like it on Linux at the moment. For me the quirks that stood between me and my goals are now solved, in a build I run every day on top of your branch, and I am confident these things solve problems for others too. When one operator takes the trouble to write a problem down, there are usually quite a few more who have it and stay quiet. So I can get on with my goals now, and I hope you pick out the good ideas, improve them, argue with them, and keep making QLog the best logger we have.

73, John

[foldynl]

Thanks for the explanation. I think our main difference is really about where the discussion should happen.

I am not against new features, but I try to avoid solving one operator's specific problem by adding another checkbox, text field or special case. I have already rejected several PRs like this because I do not want QLog to slowly become one of those ham radio applications where the GUI is full of accumulated options nobody can really understand anymore.

QLog is also primarily a logging application, not a rig control application. Rig-related features can absolutely make sense, but they should support the logging workflow, not gradually turn QLog into a general rig controller.

I am not against prototypes or AI-generated development either — I use AI-generated code myself. But precisely because of that, I still review these PRs manually and try to understand not only whether the code works, but what accepting it means for the architecture and future maintenance.

For discussion, I actually prefer something simple: a GUI prototype and a few bullet points describing the intended behaviour. I do not need long AI-generated PR descriptions or detailed call graphs that may look completely different after the discussion anyway.

For this particular feature, the question is also broader than whether SYNC works on one Yaesu rig. QLog supports Hamlib, OmniRig, FLRig and TCI. What is the equivalent behaviour there? And is the real feature "send a raw command after clicking a spot", or rather something more general like "make the second receiver follow the selected DX"?

Once we accept one generic raw-command hook, similar requests will naturally follow. That is why I prefer to first understand the real feature and whether it can be generalized.

That is what I mean by "discuss first": not endless discussion instead of code, but agreeing on what problem QLog should solve and at what level. As you wrote, the implementation is usually the easier part today.

[oh2gba]

You have answered your own question, better than I did: "make the second receiver follow the selected DX." That is the feature.

So let me turn it around, with a smile. You know QLog's architecture and all four backends far better than I do. If you see how that should look in QLog, sketch it, the GUI and a few bullets, exactly the way you asked me to. I will build it, test it on the Yeasu, and others can test it on theirs.

Tokens are cheap, TTL is irreplaceable.

73, John