I have seen several reports here of instability, mainly with Yaesu rigs. My problem is with Kenwood but the symptoms are nearly identical. Let me also state right here that FLDIGI operates flawlessly with my rigs. I have
* TS-140S with IF-10C and IF-232C
* TS-440SAT with IC-10 and IF-232C
* Computer is i5 with 8GB RAM
* OS is Xubuntu 16.04.03LTS
* CQRLOG version 2.2.0 (001)
* Hamlib v3.1
Both rigs exhibit the exact same problem. The TRX control works fine when launched but as soon as I start to manually tune around CQRLOG becomes very unstable.
I started out by using a smaller i3 Dell Optiplex 390. My initial thought was something wrong with my USB-Serial adapter. I tried two types, Prolific and FTDI. Both behaved identically. The 390 does not have a native RS-232 port so I replaced the computer with the i5. Using a native RS-232 port made no difference.
I was also using hamlib 1.2.x from the PPA and after some reading here I decided to compile 3.1 and try that solution. Rigctl -V reports that I am actually now on hamlib 3.1. The only benefit is I can now control the rig from TRC Control whereas I was only able to monitor the rig status and frequency using hamlib 1.2.x. Instability continued.
I finally ran CQRLOG with "Show communication" enabled from a terminal session and observed the data stream. With the TS-440 it echoed "MSG from rig: RPRT -9". With the TS-140 it echoed a mixed bag of "MSG from rig: RPRT -8" and "MSG from rig: RPRT -5".
What became painfully evident is that as I spin the VFO, communication stumbles. CQRLOG sends out "fmv" commands but nothing returns. When I stop spinning the dial this continues. Sometimes CQRLOG will resync, sometimes not. What happens when it does resync is it spits out a large number of stored frequencies in rapid succession, much faster than the normal poll rate setting, then settles down to the normal poll rate without the RPRT messages.
What seems to be happening is some sort of buffer filling up and overflowing such that the program cannot keep up. If I tune very slowly the problem does not occur. Lengthening the poll rate to 1000 mS helps a little too but not much.
As someone who has donated generously to your project in the past, I sincerely hope you will correct this problem very soon.
Mark Brasche, W1MM