Reply to \get_powerstat to fix wsjtx

[yarda]

Fixes #1277.

Maybe better to add alias to DSP ON/OFF, but this will fix wsjtx at least.

[AsciiWolf]

Nice! Thanks a lot for working on this! :-)

[AsciiWolf]

@argilo Would be great to make a minor Gqrx release with this fix included after it gets merged (so there is still time to get this into Ubuntu 24.04 and other distros released in Q1 / Q2 of 2024).

[argilo]

Sure, I can make a release with this. It seems like a reasonable stopgap, but in the longer term Gqrx should probably implement the full command set so that things don't continue breaking.

[yarda]

I have alternate version of the patch which maps powerstat to the DSP stat. I think it's more logically correct, but also less user friendly, because wsjtx outputs error if the DSP is off (it seems at the moment wsjtx cannot power the rig on). So with the alternate patch you need to switch the DSP on first and then it will work. Maybe it's a bit confusing. We could also implement the set_powerstat, but as wsjtx doesn't use it, it isn't currently critical. Please let me know whether I should force push the new version. The patch for the reference:

diff --git a/src/applications/gqrx/remote_control.cpp b/src/applications/gqrx/remote_control.cpp
index 4caa4b1..a2c528f 100644
--- a/src/applications/gqrx/remote_control.cpp
+++ b/src/applications/gqrx/remote_control.cpp
@@ -247,6 +247,8 @@ void RemoteControl::startRead()
         answer = cmd_lnb_lo(cmdlist);
     else if (cmd == "\\dump_state")
         answer = cmd_dump_state();
+    else if (cmd == "\\get_powerstat")
+        answer = cmd_get_powerstat();
     else if (cmd == "q" || cmd == "Q")
     {
         // FIXME: for now we assume 'close' command
@@ -973,3 +975,9 @@ QString RemoteControl::cmd_dump_state() const
         /* Bit field list of set parm */
         "0\n" /* RIG_PARM_NONE */);
 }
+
+/* Get powerstat */
+QString RemoteControl::cmd_get_powerstat() const
+{
+    return QString("%1\n").arg(receiver_running);
+}
diff --git a/src/applications/gqrx/remote_control.h b/src/applications/gqrx/remote_control.h
index 12d2619..804673d 100644
--- a/src/applications/gqrx/remote_control.h
+++ b/src/applications/gqrx/remote_control.h
@@ -165,6 +165,7 @@ private:
     QString     cmd_LOS();
     QString     cmd_lnb_lo(QStringList cmdlist);
     QString     cmd_dump_state() const;
+    QString     cmd_get_powerstat() const;
 };
 
 #endif // REMOTE_CONTROL_H

[argilo]

I think the current version is fine. It seems reasonable to consider Gqrx "powered on" whether DSP is running or not.

[argilo]

Coincidentally, a second PR was just opened for this, and there's some further discussion there: #1335.

There's also an open issue: #1277

[yarda]

Coincidentally, a second PR was just opened for this, and there's some further discussion there: #1335.

There's also an open issue: #1277

The issue is referenced in the commit and it should be linked. Personally, I don't care how it's fixed, especially if it's fixed. I think wsjtx could add auto power on support. But I also don't know whether I want it to work this way and toggle the DSP. I am also not sure whether DSP off means radio off. Because with DSP off gqrx reacts to set/get commands, frequency/mode can be changed and the new values are immediately displayed. This usually doesn't work if the radio is off.

Also I don't get why after cca. half a year now multiple PRs are opened on the same issue.

[argilo]

Would be great to make a minor Gqrx release with this fix included

2.17.4 is out: https://github.com/gqrx-sdr/gqrx/releases/tag/v2.17.4