This is something I typed in another topic before but may have been missed. So a new topic.
I do have an issue with my radio control (TS-850, 2009 from the list) I never had before.
At first I got a pop-up telling me the radio did not respond in time. And the radio control showed 0000000.
So I changed the time-out setting to 15000 instead of 15 milliseconds. That works to some extend.
This problem is most prevalent when I tune up and down the band (any band) in a fairly rapid pace.
I also changed the poll to 200 and even 500 where I used to use 100 for a long time without that problem at all.
Then I changed some of the settings on the right side of the radio screen. Unticked some boxes.
I even tried more settings but to no avail.
As mentioned in the title: it was perfect in 128. Not in 138 nor 139.
It used to run perfectly and Hamlib was not changed. So what did?
Any suggestions?
Tjalling
Hi Tjalling!
There are major changes in rig control between 128 and 139 as you can except when jumping over 10 versions.
Rapid band tuning causing problems looks like TS850 is slow to handle CAT requests when it has "other things to do" I.E.
driving local things.
TIme-out is not directly milliseconds. It is a count how many poll rounds can be passed while waiting response to sent command from rig.
I must check the counting method as it seems this is not working as expected your poll 500mS x 15000 results 750000ms = 750s = 12minutes
and that indicates there is something wrong with counting.
Pity that I can not see that with my IC7300 that makes it "blind fixing" that is always harder.
--
Saku
OH1KH
Hi!
Just tested does the timeout X poll really work as should.
I did set polling to 1000 (1sec) and timeout to 15. That should cut of after 15secs of trying.
Enabled "Show communication with TRX in console" at preferences/TRXControl and after my IC7300 was up and running properly with Cqrlog
I manually switched off it's power.
Here is the debug out put result that shows the timeout really being 1000ms x 15 = 15sec:
Poll Sending:+f currVFO +m currVFO
Sent :22 TRUE
Polling - allowcommand:-1
Response waited: 1sec
Polling - allowcommand:-1
Response waited: 2sec
Msg from rig:GET_FREQ: CURRVFO|RPRT -5
a[0]:GET_FREQ: CURRVFO
a[1]:RPRT -5
Hamlib: Communication timed out
Polling - allowcommand:1
Queue has:
+\get_ptt currVFO
+\get_level currVFO RFPOWER
Queue Sending[0]:+\get_ptt currVFO
Queue left:
+\get_level currVFO RFPOWER
Sent :18 TRUE
Polling - allowcommand:-1
Response waited: 1sec
Polling - allowcommand:-1
Response waited: 2sec
Polling - allowcommand:-1
Response waited: 3sec
Polling - allowcommand:-1
Response waited: 4sec
Polling - allowcommand:-1
Response waited: 5sec
Polling - allowcommand:-1
Response waited: 6sec
Polling - allowcommand:-1
Response waited: 7sec
Polling - allowcommand:-1
Response waited: 8sec
Polling - allowcommand:-1
Response waited: 9sec
Polling - allowcommand:-1
Response waited: 10sec
Polling - allowcommand:-1
Response waited: 11sec
Polling - allowcommand:-1
Response waited: 12sec
Polling - allowcommand:-1
Response waited: 13sec
Polling - allowcommand:-1
Response waited: 14sec
Polling - allowcommand:-1
Rig/rigctld did not respond to command within timeout!
Response waited: 15sec
Destroy rigctld
1
2
3
Error with rigctld: Shutdown error [107]: Transport endpoint is not connected
4
5
6
Done!
So the problem with your TS-850 must appear outside of poll timeout somehow.
Could you set "Show communication with TRX in console" at preferences/TRXControl and start Cqrlog from command terminal as:
cqrlog > /tmp/debug.txt
See that everything works, then start making fast changes to vfo so that error appears and then close Cqrlog.
Send /tmp/debug.txt to me as email, or attach it to your message here.
Thank you!
--
Saku
OH1KH
Hi Saku,
Thanks for taking the time and effort to investigate my problem.
I did as you asked me to do and will attach debug.txt here.
Mind you, I unticked the lowest box in preferences so polls are done one by one.
It doesn't help but I forgot to re-tick it for this run.
The way it was in Alpha 128 was that CQRlog would stop showing changes in frequencies until the vfo came to a stop or was slowed down considerably.
Never a problem as such.
Of course, my TS-850 is now an older radio (which I bought new in 1994) with only a 4800 baud rate.
Still, it's a very good radio and I don't want to part with it. :)
Thanks again,
Tjalling
Somehow the file seems not attached.
Second attempt...
File:
Hi !
At least I found one bug from there.
-------------------------------------------------------
Rig init sending: +\set_func ?
Sent :13 TRUE
Msg from rig:SET_FUNC: ?|AIP LOCK |RPRT 0
Set functions: AIP LOCK
-------------------------------------------------------
How ever Cqrlog tries to reset XIT and RIT with "SET_FUNC" command.
I have no check are those supported by rig, that should be added.
I think that messes up the communication.
XIT and RIT are zeroed when band changes.
Changelog of version 137:
"TRXControl:Fix: 'change of band clears XitRit' was always on regardless checkbox"
That has happened between versions from 128 to 138.
I will fix this. Then we can try again.
Thanks for your support!
P.S.
Meanwhile you can try to uncheck "preferences/NewQSO/Clear RIT after saving qso" if it is checked.
This does not help for band change problem, but may help when saving a qso because there might be s problem also.
--
Saku
OH1KH
Hi Saku,
Thank you again for taking the time and effort to investigate my problem.
This could be the culprit indeed. The TS-850's RIT/XIT can only be switched on or off.
Not sure if it can be done remotely. There are just two potentiometers one can set. I rarely use them at all.
For now, I just switched the whole station down to get some sleep. Tomorrow I will give it a try.
My workaround for now is to have just selected one radio in preferences. So, when the frequency is not read, I quickly choose the none-existing radio.
CQRlog then switches back to the TS-850 and reads the frequency. That's quicker than restarting rigctld from preferences.
I'll report back tomorrow.
Tjalling
Hi Tjalling!
I have now rewritten some parts of RigControl. If you can compile by yourself you will find source from devel branch of git.
I you can/will not, send me an email and I will compile it for you. I'm ok at qrz.
--
Saku
OH1KH
Hello Saku,
First of all, Happy New Year 2026 and good health for a long time to come.
I just compiled your latest version, Ver.Alpha_140_Gtk2,
and everything is working perfectly. The minor issues with Cat control have disappeared! Well done on fixing those bugs. Here's the configuration:
IC7700 via serial port
IC7610 via USB port
FT897D via USB port
SunSDR2DX via network + TCI adapter for TCI support
Again, congratulations and thank you for everything you do for us!
73 Yves F5JQF
73 Yves, F5JQF
[ CQRlog Ver.Alpha_(140)_Gtk2 ]
...
Hi Yves!
Nice to hear!
Thanks for reporting.
--
Saku
OH1KH
Thank you Saku,
I sent you an email.
Tjalling
Hi Saku,
I have been looking at devel branch of git but I can't figure it out.
I am just a slightly above average user so it's all a bit "Chinese" to me.
Although I like learning, this seems one step too far for me.
Just to let you know. 73,
Tjalling
Hi,
So far I haven't (been able to) change anything.
I remember from years ago, we established that all I need when polling is F and M.
V is not important to me. Saves time during polling too I think. Makes it less complicated.
Band and/or frequency changes including mode, from within CQRlog, I.E. from cluster or band change, work the other way around right?
All other features like AIP and RIT switching from computer are things I personally don't use.
In fact, I rarely use them on the radio either.
Other amateurs however, may love these features. Perhaps in a future release, those settings could be custom "settable" ?
Tjalling PA3GOS
HI!
This could be an idea for old tranceivers or simple emulators that can not do any special "bells and whistles".
With Icoms it is known that most of them can not answer to VFO question via CAT. They, how ever can switch the vfo via cat command.
Very strange property.
--
Saku
OH1KH
Hi,
Indeed. My Kenwood TS-850 can only hande a baudrate of 4800 and that's probably too low to keep track of the "bells and whistles".
And yes, weird property of Icom radio's. The more recent ones have a high enough baudrate to do that. Beats me.
I use a true serial port by the way.
Tjalling
Hi!
Added checkbox.
Does not make check for \dump_caps and \chk_vfo when rig is initialized.
That leads to situation where only "+f +m"
or "+f" and "+m" in their own lines (if compound poll unchecked) are sent.
Tried to block out most other commands, too. Set PTT (for hamlib tune) and set(but not get) VFO are still working. I think there are some others too (not tested yet all possible situations).
May be good for old rigs and poor rigctld emulators.
--
Saku
OH1KH
Hi!
That looks very promising Saku! Thank you very much for your relentless effort to help me and many others.
It sounds exactly what I need for my TS-850.
I will keep track of this thread (get email notifications too). As soon as there is an easy way to install this I will.
I may be many things but I'm not a programming wizzard so I will wait patiently.
Thanks again,
Tjalling PA3GOS
Hi!
I installed Alpha 140 with the new "Simple radio" option.
For some reason, and very unfortunately, the behavior is hardly better.
I tried several settings but to no avail.
The problem arises when I just tune over a band, listening for stations.
At that time the frequency is changing continuously of course.
As much as I hate to be the bearer of bad news, I will add a log.
It's a bit large because i held the radio at, I believe, 14.240 for awhile.
By the way, I copied the contents of the terminal instead of using debug.txt. The outcome is the same anyway.
A big thank you anyway Saku,
Tjalling PA3GOS
File:
Hi Tjalling!
You seem to have poll rate 500.
Have you tried to increase it 10x to 5000?
It seems that your 850 can not follow high poll rate if VFO is changing at same time. I assume slow CPU that has to handle VFO lock and CAT at same time and VFO has the 1st priority.
Have you 3 wire serial connection, or do you have handshake lines also connected?
In case of RTS/CTS it might be that if TS850 turns CTS off while doing something else serial buffer may be filled and once CTS is released there are several commands queued that slip all together to rig.
Or if there is no handshake then rig is just so slow that it does not follow.
For either reason there are those long "Msg from rig" lines in debug file.
During normal operation when command is sent to rig there is wait (Allowcommand=-1 "do not send more until get answer")
And that should follow "Msg to rig" only for that one command.
Have you tried to uncheck "compound poll". Does it make any change?
You should also try "Extra command line arguments" in preferences/TRXControl. Specially three of them may help:
-C post_write_delay=100,write_delay=2,timeout=300
Those are just guess values, and if you try to play with them you should set Cqrlog's poll rate from 500 to somewhere between 1000-5000
I had once TS-50 and it was rather slow to response and needed those delays (using 4800bps, too) . I just do not remember any more what were values I did use.
See command console:
man rigctld
for explanations of
-C, --set-conf=parm=val[,parm=val]
Set configuration parameter(s).
Those are just ones you should put to "Extra command line arguments" of preferences/TRXControl
--
Saku
OH1KH
When I wrote " The frequency is changing continuously" I meant on the radio.
CQRlog keeps showing the last frequency it could poll.
Hi Saku!
I tried all kinds of settings this afternoon. Tomorrow I'll give it another go.
As long as I stop turning the VFO quite often, CQRlog will pick up the new frequency.
Sometimes with a "beep" from the transceiver.
I will try again tomorrow after learning about the "Extra parameters".
The computer I use for CQRlog is purely for HAM radio purposes.
Apart from the programs that came with Linux Mint, only CQRlog is installed as per your script (newupdate).
So far not much feedback but I used this setup since 2024 and it was always fine.
I realize my radio is slow compared to newer rigs. So if I can't improve it any further I can live with it.
By the way, I set the poll to 2500 now. Well enough to get the frequency in time. I may go even higher.
You saw I had it on 500 yesterday. That's correct. I used to have it at just 100 without any problem.
Could it be that older versions of CQRlog just stopped polling when the radio was too busy? And continue when it wasn't?
Just thinking out loud... I am better with a soldering iron HI.
Thank you once again for helping me Saku,
Tjalling PA3GOS