During some circumstances the frequency and mode from a connected radio is not being updated in CQRLOG.
This might be related to Hamlib and specific radios. In my case it is a IC-7100 connected to CQRLOG and WSJT-X using Hamlib NET rigcl.
What happens is that after e.g. a external log has been updated the polling of the connected radio stops. The reason is that the program waits for an answer which, in my case, is not coming. Because of this the polling is stopped until a separate uncorrelated event is happening, like changing the frequency manually using the "TRX control" window in CQRLOG.
The dead-lock more specifically happens when there is a low priority queue being worked on in uRigControl.pas. The code sets the
853: AllowCommand:=-1;
meaning that no command might be sent to the radio. The expected way out of it is to receive a message in
534: TRigControl.OnReceivedRigctldConnect
and set the sending back to OK at like
569: AllowCommand:=1;
or
587: AllowCommand:=1;
But from what I can see this is not happening in my case.
A mitigation which I have been trying with a good result, is to set the value to 99 in the low priority queue handler
853: AllowCommand:=99;
instead and thus use the implemented delay for instances like this in
804: TRigControl.OnRigPollTimer
This is handling the problem, but still remains whether a reply is supposed to be the trigger or if this is a true dead-lock?
Hej!
Interesting.
Do you have latest (121) or (122) from source?
I have feeling that some time ago I did something for that. I just cannot remember when, and what.
My rigctdl version is not the very latest. It is:
[saku@hamtpad ~]$ rigctld --version
rigctld Hamlib 4.6~git 2023-12-15T14:40:08Z SHA=e1b3ac 64-bit
And I start rigcld from script before any other program and then use Net Hamlib rigctld in all programs.
Rig is ic7300 and I have not noticed stuck for long time.
AllowCommand is set to -1 for waiting the reply and not sending any commands before get it.
And most of all if PoverOff command is issued then polling must stop as rig does not response any more.
--
Saku
OH1KH
Hi,
thanks for your answer!
Strange, my version is 119 which I grab with:
git pull upstream master
and upstream is
https://github.com/ok2cqr/cqrlog.git
and my rigctld is
rigctl Hamlib 4.5.5 Apr 05 11:43:08Z 2023 SHA=6eecd3
(It is a Mint VERSION="21.3 (Virginia)")
So maybe I need to do some updates here first... Anyhow what is the repository for 121 or 122? Is it your repro instead to use?
BR
/Thomas, SM0KBD
---
Thomas
SM0KBD
Hej!
You find my alpha version from https://github.com/OH1KH/cqrlog/tree/loc_testing
That has version (122) as source.
There is also folder compiled that has at the moment ready compiled
version (121).
I'm going to release (122) soon as ready compiled one.
Official source (119) is almost identical as my folders (119) was. Lot of improvements and fixes has added since that. See the changelog.html
--
Saku
OH1KH
Thanks for the links to your repository!
After a quick check with 122 I can confirm that that doesn't have the problem mentioned above!
Thanks!
73 de
/Thomas, SM0KBD
---
Thomas
SM0KBD
I believe I have the same problem. Kenwood TS-440SAT, IF-232 interface. When I start CQRLOG, frequency is updated in real time. However, if I spin the frequency dial too fast, CQRLOG loses sync with the radio and cannot reacquire. Frequency can only be changed manually unless I completely restart the program. This is actually a long standing problem. I've also seen this with a Kenwood TS-140 with IF-10C that I no longer own. Current condition is...
OS: Xubuntu 22.04.4 LTS
Rig model: 2002 Kenwood TS-440S
Device: /dev/ttyS0
Poll rate: 500
Port number: 4532
I've tried using all "Default" settings as well as forcing 4800,8,2,E. Ive tried changing poll rates.
Is there some magical setting that I'm missing, or maybe an extra command line argument I can add to keep it in sync? Very frustrating.
73,
Mark, W1MM
Hi Mark!
I think the serial speed is so low that it causes troubles with high change rates.
I use 19200 speed with my icom and poll rate 200 and never noticed lost sync. I could use faster serial speed, but have not seen any need for that.
You can "reset" situation using NewQso/File/Refresh TRX/ROT control, or change rig from TRXcontrol Make dummy rig (#1) as second rig if you do not have any.
There is no need to restart whole program.
The root reason is, I think, that when when cqrlog polls rig it expects something on return from rigctld. If result is broken it may mess up system.
Check that your rig does not send anything to serial port when you turn vfo knob.
I.E. start minicom serial terminal program and give same serial settings as for rigctld. Then turn vfo and see if anything comes to terninal.
Should not. With Icoms this is caused by rig parameter TRANCEIVE ON/OFF
Another thing is echo. If Rig has parameter echo ON and it sends back all what rigctld does send to it. It must be also set to OFF.
I have never had other Kenwoods than TS50. With it the slow serial speed and slow radio cpu caused some problems that setting rigctld special parameters did fix.
I do not remember those but they were related to timing with serial communications. See rigctld man page.
Something like delay between characters and/or after newline.
--
Saku
OH1KH
Saku,
Thanks for all the effort you're putting into this. Lawn mower pull cord gave me a chuckle. I did try Refresh TRX/ROT control. No joy. The TS440 is TTL data, needs the IF-232C interface to convert to serial, and is 4800 baud only. Not in the market for a new rig just to get 19200. If I recall correctly, I had the same problem with fldigi which is why I'm more focused on "Extra command line arguments" to hopefully resolve the issue.
Xubuntu 22.04LTS so
Cqrlog 2.5.2
rigctl Hamlib 4.3.1 Mon Sep 13 23:12:03 2021 +0000 SHA=c2ed3d
I have a very busy schedule the next few days. I will try some of your other suggestions and report if I make any progress. Maybe even try the alpha versions.
73,
Mark, W1MM
HI Mark!
Tested IC7300 with poll rates 100 and 1000. Cat serial speed 19200.
If I wrap string around vfo knob and then pull it like starting lawn mower vfo readings change very fast.
After vfo change has stopped same reading comes to Cqrlog's TRXControl than rig has.
If poll rate is 100 it happens very fast, with 1000 a little bit slower.
Tested several times with rig steps 1kHz and 10Hz. No problems.
Hamlib version used is from GitHub source:
rigctld Hamlib 4.6~git 2024-02-07T18:27:12Z SHA=59e4ba 64-bit
Cqrlog version is:
2.6.0(125)_QT5
--
Saku
OH1KH
Hej Thomas!
Latest Alpha version source (date 2024-03-14) has now timeout counter for "AllowCommand:=-1"
After 15 poll tries (time of that depends setting of "poll" time) Cqrlog will give up and allow next command from queue.
It may help in some situations.
It has shown up that some version(s) of rigctld do not response in any way for command +\stop_voice_mem even they report that rig is able to send it's voice memories via CAT commands.
If I remember right there was a time with rigctld versions when send voice was implemented, but stop voice was not (yet).
Situation may happen when rig is in SSB, preferences/TRXControl has "Send rig voice" checked and started qso is cancelled with 2x ESC key press. See :https://www.cqrlog.com/comment/12007#comment-12007
--
Saku
OH1KH
Hi,
thank you for the update. I will compile the latest alpha and see how it behaves. But as I wrote above, my problem seems to have been solved with your earlier patch(es).
/Thomas
---
Thomas
SM0KBD