Rigctl_server timeout

[frspin]

WARNING: Filling out the template below is NOT optional. Issues not filling out this template will be closed without review.

FIRST: Before reporting any bug, make sure that the bug you are reporting has not been reported before. Also, try to use the nightly version if possible in case I've already fixed the bug.

Hardware

• CPU: I5 4440
• RAM: 16 Gb
• GPU:
• SDR: (Remote or local? If remote, what protocol?) Hermes Lite 2 local

Software

• Operating System: Name + Exact version (eg. Windows 10 x64, Ubuntu 22.04, MacOS 10.15) Ubuntu 24.04.01
• SDR++: Version + Build date (available either in the window title or in the credits menu which you can access by clicking on the SDR++ icon in the top right corner of the software). Version 1.2.0 from GitHub compiled today

Bug Description
A clear description of the bug.

Rigctl_server running on localhost:4532 crash at "m" command and return nothing at "\get_mode" command.
Sdrpp is set to USB with a BW of 3000

Steps To Reproduce

1. start sdrpp
2. in another terminal window start rigctl -m 2 -r localhost:4532
3. issue "\get_mode" or "m" command at rigctl prompt

Screenshots
Add any screenshot that is relevant to the bug (GUI error messages, strange behavior, graphics glitch, etc...).

Additional info
Add any other relevant information.

Messages on terminal window:

`Rig command: f
Frequency: 14128450

Rig command: F 14080000

Rig command: \get_mode

Rig command: m
get_mode: error = rig_get_mode(2528): freqMainA=14080000, modeMainA=, widthMainA=0
rig_get_mode(2528): freqMainB=14128450, modeMainB=, widthMainB=0
rig_get_mode(2578): debug
3:rig.c(2607):rig_passband_normal entered
3:rig_passband_normal: return filter#6, width=2700
3:rig.c(2628):rig_passband_normal returning(2700)
3:cache.c(35):rig_set_cache_mode entered
rig_set_cache_mode(37): freqMainA=14080000, modeMainA=, widthMainA=0
rig_set_cache_mode(37): freqMainB=14128450, modeMainB=, widthMainB=0
rig_set_cache_mode(107): freqMainA=14080000, modeMainA=USB, widthMainA=2700
rig_set_cache_mode(107): freqMainB=14128450, modeMainB=, widthMainB=0
3:cache.c(108):rig_set_cache_mode returning(0)
rig_get_mode(2583): freqMainA=14080000, modeMainA=USB, widthMainA=2700
rig_get_mode(2583): freqMainB=14128450, modeMainB=, widthMainB=0
2:rig_get_mode: elapsed=10010ms
2:rig.c(2586):rig_get_mode returning(-5) Communication timed out

1:rigctl_parse.c(2246):rigctl_get_mode returning(-5) Communication timed out

Communication timed out

Rig command: q
????????????????�������`

Regards

Franco Spinelli
IW2DHW

[speedbug78]

Also seeing this (and other) compatibility issues with rigctl.
I'm running:
13th Gen Intel® Core™ i7-13620H × 16
Ubuntu 24.04.1 LTS
rigctl Hamlib 4.5.5 Apr 05 11:43:08Z 2023 SHA=6eecd3
SDR++ v1.2.1 built today (12-7-24)

For the "m" command I am able to get it working by responding with mode and passband (bandwidth). Concatinating these two into one send with a space between them doesn't seem to work, but making 2 writes to the client does. A newline may work, but I didn't test. The example in hamlib's docs clued me in. My changes aren't likely the way you'd do it but here's what I tested:

           else if (parts[0] == "m" || parts[0] == "\\get_mode") {
            std::string resp_mode = "";
            std::string resp_freq = "";
            std::lock_guard lck(vfoMtx);
            resp_mode = "RAW\n";
            resp_freq = "0";

            if (!selectedVfo.empty() && core::modComManager.getModuleName(selectedVfo) == "radio") {
                int mode;
                float bandwidth;
                core::modComManager.callInterface(selectedVfo, RADIO_IFACE_CMD_GET_MODE, NULL, &mode);
                core::modComManager.callInterface(selectedVfo, RADIO_IFACE_CMD_GET_BANDWIDTH, NULL, &bandwidth);
                resp_mode = std::string(radioModeToString[mode]) + "\n";
                resp_freq = std::to_string((int)bandwidth) + "\n";
            }
            else if (!selectedVfo.empty()) {
                resp_freq += std::to_string((int)sigpath::vfoManager.getBandwidth(selectedVfo)) + "\n";
            }
            else {
                resp_mode += "0\n";
            }
            
            client->write(resp_mode.size(), (uint8_t*)resp_mode.c_str());
            client->write(resp_freq.size(), (uint8_t*)resp_freq.c_str());
            flog::info("Finished 'm' command: {}", resp.c_str());
        }

The "F" command also didn't work for me with wsjtx 2.7.0-rc3 or JS8call. Both of these add the VFO (VFOA or VFOB) to the "F" command [07/12/2024 21:44:02.000] [INFO] Rigctl command: 'F VFOA 7074000.000000'. I wasn't able to find a setting for either of these (they're based on the same code) that removed the VFO part. wsjtx states that it is using my installed hamlib version. This fails the number of arguments check in the rigctl_server module.
`// if number of arguments isn't correct, return error

        if (parts.size() != 2) {`

Changing the number of arguments to 3 and changing the "parts" index to 2 allows wjstx to work (stays connected and is able to changed frequency). However, this would likely break other clients.

// if number of arguments isn't correct, return error
            if (parts.size() != 3) {
                flog::error("Args not correct {}", parts.size());
                resp = "RPRT 1\n";
                client->write(resp.size(), (uint8_t*)resp.c_str());
                return;
            }

            // If not controlling the VFO, return
            if (!tuningEnabled) {
                flog::error("Tuning not enabled");
                resp = "RPRT 0\n";
                client->write(resp.size(), (uint8_t*)resp.c_str());
                return;
            }

            // Parse frequency and assign it to the VFO
            long long freq = std::stoll(parts[2]);

I suspect wsjtx and others like it aren't able to transmit as "t" and "T" commands aren't implemented. wsjtx repeatedly sends the "t" command.

Hope this is helpful

[speedbug78]

Just tested wsjtx 2.6.1 and it also sends the VFO with "F", but version 2.7.0-rc7 doesn't!
2.7.0-rc7=> [07/12/2024 23:34:10.000] [INFO] Rigctl command: 'F 99133655.000000'