Issue with K3 rig control

jmeloranta commented 2 months ago

When trying to work a DX station in a pileup, I often use the Rev button (reverse temporarily VFO A and B) on my K3, to see what is going on where I transmit. Looks like the radio does not respond to frequency read requests while the Rev button is pressed and this gives error message in qlog (can't read frequency). Then this requires hitting OK and then the rig control falls off. Somewhat annoying behavior in the middle of trying to work through a pileup. Of course, it is probably the radio's fault but I wonder if qlog could be a bit more lenient towards missed frequency reads? Like it could notify about it but keep going. Or maybe add a quirk for K3 that this could happen and ignore it? Increasing the radio read delay helps a little but then it affects everything going on between the computer and the radio.

dl2ki commented 2 months ago

Hi,

I can confirm the behavior. The warning appears after approx. 3 seconds when the “REV” button is held down. At the same time, the connection to the K3 is disconnected.

Screenshot_20240928_153751

When you press the “REV” button, the K3 switches temporarily to VFO-B, but the display in QLog "Frequency" and "Mode" remains.

Screenshot_20240928_154150 Screenshot_20240928_154430

foldynl commented 2 months ago

Does this occur since a specific version? Reading from Hamlib hasn't changed in a very long time. I have no idea where the issue could be in QLog.

I don't think we should take the approach of ignoring errors when reading from the Rig. Hamlib is full of peculiarities, and this could be one of them. It’s possible to implement something like showing the error only after the third consecutive failure, but honestly, I’m not sure if this change will help you, and more importantly, it will delay error detection for everyone else.

I would try to connect K3 via rigctld and QLog also to rigctld and see if the error is still present.

jmeloranta commented 2 months ago

I am using rigctld. I think it is K3's fault for not responding and hamlib probably does nothing about it, just returns an error. We can't fix the k3 firmware but hamlib or qlog could account for this silly behavior. Perhaps the error code is different when the rev button is pressed than normal read failure? I recall never having this problem with cqrlog, so they somehow fixed that.

This has happened as long as I have been using qlog (couple of months).

dl2ki commented 2 months ago

The same behavior occurs when using “rigctl”.

Screenshot_20240929_080035

However, the “ELECRAFT K3S/K3/KX3/KX2 PROGRAMMER'S REFERENCE” document contains the following information.

Busy/Limited Access Indication (?;)

Some commands cannot be safely handled when the K3 is in a busy state, such as transmit, or in a limited-access state, such as BSET or VFO A/B reverse (REV switch). If a command cannot respond due to such a condition, the K3 will return “?;”. Future firmware releases will gradually become less restrictive in this regard.

You can use the TQ command to see if the K3 is in transmit mode, and the icon/status command (IC) to check for BSET mode (byte a, bit 6).

foldynl commented 2 months ago

thanks Wolfgang for your test. It seems to me that there is no possible solution from the QLog side. CQRLog uses a different technique to communicate with the Rig. CQRLog actually runs rigctld in the background and then communicates with this rigctld. QLog uses a direct access to the Rig. Both of these techniques have their pros and cons. It is possible that CQRLog uses a longer poll interval and this error will not appear

dl2ki commented 2 months ago

Personally, I don't see this as a major problem or limitation, as I can always adjust to these things, which generally exist in some form in all software.

A short press (approx. 2 seconds) of the REV button is possible. If you need a longer toggle, you can also use the "A/B" button.

I just checked this with CQRLOG.

With CQRLOG, the frequency display also does not change when the REV button is pressed. However, CQLOG does not respond with an error message even if the button is pressed for a longer time.

You would have to check what the K3 returns when the REV button is pressed. It might be possible to increase the response time of QLog in these cases, if this does not affect other commands. However, this would not be an urgent solution.

foldynl commented 2 months ago

there are limits related to rigctld, but that is for a longer discussion and is not related to this issue.

Otherwise, I looked at the CQRLog source code and found out why there is no error. It seems that errors are simply not checked. CQRLog only focuses on successful responses. CQRLog expects that there will be some String in the response. If it is not in it, the message is ignored. And it is the case of error response. There is no the "expected" String.

And that is the reason why CQRLog "ignores" your "error". QLog checks for errors and reacts to them.

How to compensate this issue on the QLog side? To be honest I don't know. How long should QLog ignore the error? How long do you hold the REV button down? I don't know.

I think that the question should rather be: Should this be compensated on the QLog side? In my opinion, the answer is NO. This should be resolved in K3 Firmware or Hamlib (if it hasn't already been fixed in Hamlib 4.6, which officially doesn't exist yet, and based on the author's response, it seems like it won't exist for a long long time).

However, if you know of any workaround that doesn't affect other rigs, it might be worth implementing.

jmeloranta commented 2 months ago

The right fix probably would be in hamlib: if the read returns busy then return the last known frequency. Of course, qlog could do the same as cqrlog. Not a great fix but would work.

dl2ki commented 2 months ago

The answers given by the author of Hamlib do not suggest that support is coming from there. He obviously has a clear strategy, which has to be accepted.

That is why I am of the opinion that QLog should not compensate here, more out of fundamental considerations. At least not for relatively minor problems. Personally, I can adapt to both variants. But that is up to the QLog author to decide.

The fact that the FT710 (and possibly other rigs) does not work with QLog is of course a bigger problem that limits the use of QLog considerably.

One would probably have to decide to use a current development version of Hamlib in QLog as well. However, I cannot judge whether this is possible and useful in QLog.

foldynl commented 2 months ago

The question is whether to start distributing Hamlib with the current version, just as WSJTX does. There are arguments pros and cons this approach.

Pros:

Modern hardware will be supported.
Possibly older hardware will be fixed to work better.

Cons:

It's still the DEV branch, which in my opinion, hasn't been declared stable.
There could be situations where a specific rig in the current branch has a bug, and it takes a long time to fix, even though everything worked before the commit introducing the issue – this has already happened to me.
I would have to link QLog statically with Hamlib, which is not a recommended practice for software distribution across different distributions.
I am not in a position to test each version of Hamlib to ensure it hasn’t broken anything or that at least a basic set of commands works. In this regard, I have no idea how WSJTX manages to be so confident while using Hamlib directly from the Git repo.

All of this has led me to the conclusion that for now, I won't be linking Hamlib statically and will stick with the official 'stable' version of Hamlib.

dl2ki commented 2 months ago

The reasoning is understandable to me. Perhaps a neutral reference to the current use of the stable version of Hamlib and its possible limitations would be useful.

aa5sh commented 2 months ago

I have experienced weird rig errors as well. Myine typically stem from change bands/modes from my radio (software) and not in QLog. If I change bands in SmartSDR I get an error like this or one about mode and it thendisconnects the radio. So I have click ok then Equipment/Rig.

Also one other oddity on Rig Control when I connect to my rig (Equipment/Rig menu option) it changes the mode to CW quite often from whatever it is on. - I think this is due to it starting the CW Keyer widget.

So not sure if maybe there could be an option to ignore errors other than intial connection errors or something?

aa5sh commented 2 months ago

One thought, not sure how hard it would be to implement, but could it be added with a limited error count say 3 or 5 before it displays the message/disconnects radio. But when a successful entry is processed it resets the counter? Because if I read what dl2ki posted above in relation to my message the '?;' is a valid response, in that it can't send the frequency at that moment due to processing something else. So the message is valid but not a show stopping error.

foldynl commented 2 months ago

Perhaps a neutral reference to the current use of the stable version of Hamlib and its possible limitations would be useful.

each version is prepared for specific environments. We have here Ubuntu 20.04 with Hamlib 4.3, and Ubuntu 24.04 with Hamlib 4.5; Windows version use Hamlib 4.5 and MacOS use 4.6. An ABI is incompatible when changing between Hamlib's versions. So it is not possible to use newer hamlib with QLog which is prepared for Hamlib 4.3. So a simple Hamlib upgrade is not possible. WSJTX solved it by linking Hamlib statically - this means that Hamlib is a part of the WSJTX binary.

If I were to start distributing with the latest Hamlib, I wouldn’t be able to keep track of all the changes and describe them as potential issues that might arise. It's already a nightmare for me to deal with problems related to controlling Hamlib. I don’t have the capability to test all your Rigs to be able to tell where the issue lies — whether it’s in QLog or Hamlib. Hamlib itself is a rather problematic piece of code. There are many things that are undocumented, and you have to resolve them directly from the Hamlib code, which can sometimes lead to big surprises, making you wonder if the author really intended it that way.

Let me give you an example. The rotator interface is written in such a way that the function for rotation accepts an azimuth. One would expect that the azimuth could be specified in the range of 0-360 or -180 to 180. Unfortunately, the input value depends on the type of rotator. So, for some, you need to enter 0-360, for others -180 to 180, and for some, only 0-359.9 is acceptable, and sometimes even 0-450.

So, believe me, anything involving Hamlib might not have a simple solution. I apologize to the author of Hamlib for these words, but it really bothers me that this single library for controlling Rig is so poorly documented and designed. On the other hand, the rig interfaces themselves are full of peculiarities, so I understand that compensating for this in the library might not be an easy task.

Also one other oddity on Rig Control when I connect to my rig (Equipment/Rig menu option) it changes the mode to CW quite often from whatever it is on. - I think this is due to it starting the CW Keyer widget.

this is a QLog error. I've been looking for it for months because it happens to me too, but I can't figure it out. It seems it is a problem of the sequence of signal emission from different QLog GUI parts.

One thought, not sure how hard it would be to implement, but could it be added with a limited error count say 3 or 5 before it displays the message/disconnects radio. But when a successful entry is processed it resets the counter? Because if I read what dl2ki posted above in relation to my message the '?;' is a valid response, in that it can't send the frequency at that moment due to processing something else. So the message is valid but not a show stopping error.

It’s important to realize that rigs can be of various types. So, it’s not possible to fine-tune error handling only for 'Kenwood'-type rigs. Waiting for the rig to be ready and making repeated attempts is a solution, but it complicates rig control. For example, between "reading the frequency" commands, a "set frequency" command might come in. Should it be delayed? This implies the creation of a request queue. This queue has to be managed because sometimes one command can affect another. The queue could grow — what then? Delays in commands could increase — what should be done in that case in the GUI?

This isn’t a task for a general logging application. The application should query the library and receive a response. It shouldn’t actively participate in communication with the rig. A library should be the responsibility of the solving rig errors and their compensation.

jmeloranta commented 1 month ago

Perhaps qlog could have an option in the rig setup to ignore read errors?

By the way, some times it gives Get Mode Error (rig_flush: called for network device)