I see that other people are having problems too. I have several, probably related and I have tried to list them below.
1. The connection parameters for my FTDX-1200 were changed (such as setting 3 stop bits). Other params were changed too, but I don't recall which)
2. Once I had re-entered the correct parameters - 38400, 8,2,no parity, I could get rigctl to start but there are still problems
3. When double clicking an entry in the RBN Monitor, the call and frequency transfer to the New QSO dialog, but the transceiver is only updated after 20-30 seconds if at all.
4. Frequency of TRX randomly changes. I thought this was something to do with the RBN Monitor but it still happens when it is closed.
5. Flrig and wsjtx still function correctly.
6. Subsequent to all these problems I configured TLF and that appears to communicate with the TRX okay.
7. Somewhere in trying to make this work I had to remove the braille library as that was taking precedence over my FTDI dongle.
It seems to be a timing issue between CQRLog and the TRX
Any ideas what could be causing this?
Thanks,
Leo M0NNQ
Hi Leo!
Yes. It unfortunately seems that Ubuntu and it's variants are the base of problems. (Says fedora user, hi )
Slow frequency updating may have several reasons.
First I would look at preferences/TRXControl's Poll rate. If it is big frequency appears very slow, but is not random.
That's why I guess your Poll value is under 5000.
If Poll value is small 500 or under it may stress your rig (inside) even when serial baud rate is high 38400 and you get random readings.
If Poll value is around 500-1500 it should be normal.
Then you must study what rigctld says.
First step is to check preferences/TRXControl "Show communication with TRX in console", close preferences and Cqrlog and start it from command line terminal by typing:
cqrlog
Then you see the TRX traffic on console. If that does not show "random", but all the time same you can make deeper study by setting prferences/TRXControl/Rig model to #2 Hamlib rigctld and unchecking "Run rigctld at program start"
Before starting Cqrlog again open command console and start rigctld there with your rig model number, serial port, and "-vvvvv"
Something like:
rigctld -m1034 -r/dev/ttyUSB0 -vvvvv
If tour serial settings are not Yaesu defaults you need to set them too. See "man rigctld" in command console for details.
After you have entered rigctld command with parameters you will see lot of debug text in console and the command prompt does not return.
If no fatal error texts at that point start Cqrlog.
Now when it has TRXControl Rig model as #2 Hamlib rigctld it should get connect to your console's rigctld and it should talk with your rig.
Every time Cqrlog polls you can see debug texts running in console. Then you need to catch errors from there to see why TRX frequency does not appear ok.
Are you sure that no other program(s) try to access the serial port where your rig is?
Linux let's it happen unlike Windoze that says "serial port is in use".
--
Saku
OH1KH
Thanks Saku,
It took the #2 TRX setting to (eventually) spot the problem. It was working perfectly with #2 but not with #1.
I did which rigctld and discovered that the one configured in CQRLog was not the one I was using at the command line. CQRLog was /usr/bin/rigctld but the command line version was /usr/local/bin/rigctld
So something had changed between Ubuntu and CQRLog with the OS upgrade. Perhaps both.
Anyway it’s all working now and hopefully this information will help someone else.
Many thanks for your help.
Leo
m0nnq