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
(formerly KB1FV)
Hi Mark!
You have done quite perfect tracing and testing, so there is not much to suggest any more.
Old Kenwoods are slow. They use same cpu for controlling rig and communication. The serial speed is fixed to 4800.
I have played some time with TS50S making a WiFi connection to it with ESP12e microcontroller. With that I have found that at least TS50 works best when only 3 wires are connected to serial communication.
CTS+RTS linked together, but not outside of the rig did give best response.
Additional parameter (preferences/trxcontrol/extra command line parameters) --set-conf=timeout=3000 may help. You can also try with other values than 3000 milliseconds.
Also dropping preferences/trxcontrol poll rate down from 1000 to 2000-3000 may help. You do not need so fast polling. Your qso will last more than 2 seconds and by time of saving your qso the right frequency is there.
I use poll rate of 2000 and it works fine. You just have to get used to wait a small time to see right frequency from cqrlog.
I did also dig out from source (could not find explanation from anywhere else!!) the error codes. List starts from 0 (zero). Accoriding to that, all your errors are referring to slow response of rig. ( communication timed out, Protocol error, Command rejected by the rig )
enum rig_errcode_e {
RIG_OK = 0, /*!< No error, operation completed successfully */
RIG_EINVAL, /*!< invalid parameter */
RIG_ECONF, /*!< invalid configuration (serial,..) */
RIG_ENOMEM, /*!< memory shortage */
RIG_ENIMPL, /*!< function not implemented, but will be */
RIG_ETIMEOUT, /*!< communication timed out */
RIG_EIO, /*!< IO error, including open failed */
RIG_EINTERNAL, /*!< Internal Hamlib error, huh! */
RIG_EPROTO, /*!< Protocol error */
RIG_ERJCTED, /*!< Command rejected by the rig */
RIG_ETRUNC, /*!< Command performed, but arg truncated */
RIG_ENAVAIL, /*!< function not available */
RIG_ENTARGET, /*!< VFO not targetable */
RIG_BUSERROR, /*!< Error talking on the bus */
RIG_BUSBUSY, /*!< Collision on the bus */
RIG_EARG, /*!< NULL RIG handle or any invalid pointer parameter in get arg */
RIG_EVFO, /*!< Invalid VFO */
RIG_EDOM /*!< Argument out of domain of func */
};
That is just old rig syndrome. I have learned it with TS50s.
We have get used to so speedy life that nowadays everything must happen in a fraction of second .
--
Saku
OH1KH
Still some things to say:
You say that fldigi is working ok. Do you use hamlib with that also ? I guess not!
So it is not compareable untill you use Hamlib also there as Hamlib is the background program that cqrlog have to trust.
And if you are not using hamlib there I assume you are NOT using cqrlog at same time.
If you are, you have problems. That is for sure!
Same with wsjtx, if you happen to use it.
Please check this (poor) video that explains the proper usage of Hamlib, without confilcts, with all your programs at same time.
https://drive.google.com/open?id=1ZB1croPCZjquhkCpInub9PhT8xOAtxqS
--
Saku
OH1KH
{in my best old man voice} "You know, sonny, back in the day, when we had serial communications errors, the temporary fix was often to drop the speed, not the other way around." Just saying. ;-) I will try the command line arguments and rts/cts mod to see if they help.
You are correct, though. I tested FLDIGI using FLRIG. I have not yet figured out how to link the two programs yet and make them work correctly. I also want to play with FT8 so I will want to also link WSJTX. I plan to tinker with it again today so I will watch the video. Thanks so much for the quick replies.
73,
Mark, W1MM
Yep!
{with the same voice...} Those were the days. I remember when I made a serial interface (1982) to Sinclair ZX81 with 8250 UART. Nothing was ready. Shematic and pcb had to be designed (by hand) to fit the Z80 cpu bus. After that the program had to be done using Z80 assembler.
No Google, just some copies from data sheet books.
But how ever final result was well working RTTY machine. And also a terminal for working with land line BBSes using home made (with discrete components) 300baud telephone modem.
Those Kenwoods are not just so slow, but quite slow anyway compared to modern rigs.
We, and our rigs, just are old and slow... :)
After watching my video you know how to set up rigctld in proper way for all programs (I hope I was able to tell it in understandable way using foreign language).
--
Saku
OH1KH
Yes, your English is just fine and I always appreciate when others reach out to communicate in not their own native language. The video was really quite excellent. I tried clipping and jumpering RTS/CTS inside the IF-232C. That made no difference. The only thing that seems to help is increasing the poll rate delay. As soon as the rig receives too many "fmv" commands, loses sync and starts returning RPRT -9, it's game over.
I still feel it should be able to easily resync. FLRIG does it with no trouble at all. Why can't hamlib? I'm starting to think that maybe I should regress hamlib to something very old to match.
73,
Mark, W1MM
Okay, after a considerable amount more testing I have found that
The statement that fldigi must not be working with hamlib is incorrect. It works about the same as cqrlog with hamlib. If I try to spin the dial long enough and often enough, it does sometimes take 5-10 full seconds to resync but with hamlib 1.2.15.3 it always does resync eventually on its own. Clearly, the developers of hamlib with v3 and above are ignoring reverse compatibility with older rigs. That's a huge disappointment.
73,
Mark, W1MM
Hi
>/dev/rig does not work in cqrlog per the video and I still have not gotten it to play nice with fldigi.
It is just udev-symlink trick. As said Google is full of articles about that. If you get it working (it makes symlink at plugin phase) it works as reliable as using the /dev/ttyUSBXX itself.
it is like doing console command "ln -s /dev/ttyUSBXX /dev/rig" by hand.
It is just to help things out, as the name will be always same.
>The statement that fldigi must not be working with hamlib is incorrect.
Linux lets you use same serial port from 2 different programs (that Windoze does not).
At some point both programs access the port at same time and results are mixed in unexpected ways. It might work a long time, but as the accessing of port is not in sync with separate programs at some point comes the moment when both are doing access at same time. Bang.....
That's why only 1 hamlib/rigctld should be running and all programs should access it. It can hand le multiple clients via TCP. And then it is accessing rig alone via serial port.
Anyway. Fine that you have made some progress. Sad is that you have to roll back to old version of hanlib. But on the other hand as long as it works in current linux version and you do not have other rigs, why to update working concept as it is just background program and does not limit using new versions of cqrlog.
--
Saku
OH1KH