Issue with K3 rig control #472
Comments
|
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.
When you press the “REV” button, the K3 switches temporarily to VFO-B, but the display in QLog "Frequency" and "Mode" remains.
|
|
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. |
|
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). |
|
The same behavior occurs when using “rigctl”.
However, the “ELECRAFT K3S/K3/KX3/KX2 PROGRAMMER'S REFERENCE” document contains the following information.
|
|
thanks Wolfgang for your test. It seems to me that there is no possible solution from the QLog side. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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:
Cons:
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. |
|
The reasoning is understandable to me. |
|
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 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? |
|
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. |
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.
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.
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. |
|
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) |
I agree with you here. HamLib should handle this more gracefully. |
In some cases, the rig may be busy, which can lead to an error message and a disconnect event. However, this does not mean that communication has stopped. This commit implements postponed error handling with a delay of 15 seconds. If the same error does not occur during this time and there is a successful operation for this type of error, then the error message is not sent to the operator. Currently, error handling is performed this way only for 'Get Freq' and 'Get Mode'. QLog also recognizes two types of errors: hard and soft. The hard error is reported immediately. The soft error is postponed.
|
would it be possible to test the change in the HamlibErrorRedesign branch to see if it solves this problem? It is not possible to wait for Hamlib to fix this. |
Sorry just seeing this update. I will build and try it and let you know. |
|
Quick testing at lunch this looks like it is working a lot better. I bounced around a good bit and no issues whatsoever. I did then launch from command line and bounced around and saw where it was showing the soft errors there but no connections lost. Looks good so far Ladislav |
|
Thank you very much. That’s good news. I am only able to simulate a 'hard' error with my rig, which causes an immediate disconnection. I simulated a soft error with the help of a workaround, but I wanted to know if it works also with a real rig. |
|
Thanks for coming up with a solution for this. Would this same logic be
implemented in the rotor part of Hamlib as well? It is temperamental as
well.
…On Thu, Oct 3, 2024 at 1:06 PM Ladislav ***@***.***> wrote:
Thank you very much. That’s good news. I am only able to simulate a 'hard'
error with my rig, which causes an immediate disconnection. I simulated a
soft error with the help of a workaround, but I wanted to know if it works
also with a real rig.
—
Reply to this email directly, view it on GitHub
<#472 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUEEMXRJZSQ4COQP52DSUN3ZZWBR5AVCNFSM6AAAAABO6ESBOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJSGAYTQMBWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Well, I probably should implemented for rotator. I have to verify whether I can use the same logic for the rotator. But no one reported that there was a similar issue for rotators. Did you notice something? |
|
I would need to see if I can get the error but it is odd at times I got
HamLib errors for my rotor. Weird thing is it seemed to reference Kenwood
something if I remember correctly, which never made sense to me. I just
started using my old app for my rotor. I will enable it again this evening
and see if I can get the error message or replicate it.
…On Thu, Oct 3, 2024 at 1:20 PM Ladislav ***@***.***> wrote:
Well, I probably should implemented for rotator. I have to verify whether
I can use the same logic for the rotator. But no one reported that there
was a similar issue for rotators. Did you notice something?
—
Reply to this email directly, view it on GitHub
<#472 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUEEMXW72T5FE3HCLXDKHTLZZWDFJAVCNFSM6AAAAABO6ESBOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJSGA2DEMBVGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I just got this error: Odd it says ts2000.c and all. |
|
As a side note K4 does not seem to have this issue, only K3. |
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.
The text was updated successfully, but these errors were encountered: