So tickled to finally get the package working (somewhat) as of the latest version, but having a problem with TRX control window losing connection with the rig after about 20 seconds, (time varies). Running Linux Mint Cinnamon 17.3 (64 bit) in a virtual machine. Connected to rig via FTDI USB-serial cable.
Installed using terminal:
sudo add-apt-repository ppa:ok2cqr/ppa;sudo apt-get update;sudo apt-get install cqrlog
Everything appeared to go perfectly well, including all dependencies.
Configured preferences - current TRX control tab is as follows:
Set “Path to rigctl binary” to /usr/bin/rigctld
Set “Radio one Desc.” to IC-718 (Radio two is set to Dummy)
Set “Host” to localhost
Set “Rig Model” to 313 ICOM IC-718 (using the drop-down menu - also Radio two is dummy)
Set “Device” to /dev/ttyUSB0 (that last character is a zero – need to verify yours may be 1, 2, 3, etc.)
Set “Poll Rate” to 1500
Set “Port Number” to 4532
Current command line arguments set to -m 313 -r /dev/ttyUSB0
Click to “X” Run rigctld when program starts
Serial speed currently set to 9600 (same set in rig's initial settings - have tried 4800 in past)
For now, have left the rest at their default settings
When loaded, initially TRX Control window shows whatever the rig is currently on, (eureka!), and double-clicking a line in DXCluster will take the radio to the appropriate band/frequency/mode - after a second or two that data is now displayed properly in the TRX control window. But it only works for 20 seconds or so, (again time varies), and the frequency in the TRX control window displays zeros. Have discovered it I click on Radio two (dummy), then back to Radio one (IC-718), it will re-establish comms with the rig for another short while, operate normally, then lose communications. Clicking on "New QSO | File | Refresh TRX/ROT control" will also cause the temporary re-connection sometimes, not always.
Have been chasing this problem for several days, trying various settings/arguments and initial settings in the rig, but all have resulted in no change or total loss of control on the rig. Any and all ideas/help will be deeply appreciated!
73, dave W6TUX
Using system monitor, just noticed that switching to Radio two actually kills the rigctld process - then switching back will reload the rigctld process, which explains why that will re-establish comms with the rig. Will be investigating all rigctld arguments available while waiting on suggestions to my post. In the mean time, thanks for reading it! dave
Ran cqrlog from console, (terminal window) after checking "Show communication with TRX in console" in TRX control preferences:
Ran "cqrlog" without debug argument from terminal so I could focus on communication only.
Copied from terminal window - everything ran fine at start - then upon loss of comms with rig, saw RPRT-13 start appearing. That continues until/unless rigctld killed/reloaded:
---------
Msg from rig: 14017100
Msg from rig: CW
2100
RPRT -11
Sending: fmv
Msg from rig: 14017100
Msg from rig: RPRT -13
RPRT -11
Sending: fmv
-----------
Hope this helps, have this haunting feeling I am overlooking something very obvious.
Hi Dave,
please leave the "Extra command line arguments" blank. It's useful only when you want to set something specific that is not in the preferences.
RPRT -11 error from rig means "Feature not available", RPRT -13 means "Communication bus error"
https://sourceforge.net/p/hamlib/code/ci/master/tree/src/rig.c#l146
Please go to Preferences -> Modes and set all bandwidth options to 0. It could help.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Thank you Petr! Both info and link much appreciated!
Preferences | Modes were already all set to 0 per your FAQ note on ICOM radios. Since yesterday morning have done a ton of reading and testing. All rigctld command line arguments were cleared late last night and same problem continued as I tried walking through various baud rates/poll settings, (each time changing the rig's initial settings). All seemed to work the same between 1200 and current 19600, but only for about 20 seconds or so).
Very late last night, came to the conclusion that I have some other process running, either on this virtual machine or the Windows 10 "host" machine, that is getting in the way of proper communication - more than likely on the "Windows Host" and that is a very easy to fix.
Currently intend to simply dedicate that machine solely to Linux | Ham radio, and blow away the current host OS with a fresh install of Linux Mint Cinnamon 17.3, then re-install CQRLOG, re-configure, and bet the problem simply goes away. If it persists, at least that itchy feeling on the back of my neck will be gone.
Will post results and all pertinent current settings for the IC-718 in this thread if it works, (for the next ham with this rig). If I want to run Windows on that machine later on, IT can go into a virtual machine. (Smiling here).
Before I get started, simply want to say "thank you" again for CQRLOG and all your work!
73, dave W6TUX
Have no idea what process was interfering with my previous installation - but that *has* to be what was getting in the way.
After an "emergency Honey Do", (had to install a new garbage disposal under our sink), installed Linux Mint 17.3 Cinnamon - told it to take the whole computer, wiping out the Windows 10, Virtual box and all virtual machines, (after I got a FULL, verified, backup.
Added several related PPAs, packages, including xplanet, fldigi, TrustedQSL, xdx, hamlib (ppa:kamalmostafa/hamlib), wsjtx, finally added PPA for kvasd-installer, installed and ran it.
Finally installed CQRLOG using terminal commands provided by this site:
sudo add-apt-repository ppa:ok2cqr/ppa;sudo apt-get update;sudo apt-get install cqrlog
Ran it, configured all of the preferences I could, and EUREKA! The TRX control window has now been up and operating just fine for over 50 minutes so far. I still need to add a few items unrelated to rig control, like my HamQTH account name and password - but can't tell you how good it is to see and exercise TRX control over and over without a problem!
As promised, will come back later to this thread and list my, (now minimal), settings for TRX control > IC-718. For now, will continue testing.
Man I am *LOVING* CQRLOG!
73, dave W6TUX
These are the settings that have been working well for me for over 24 hours now - operating system is Linux Mint 17.3 Cinnamon, using CQRLOG 2.0.1-1.
We need to access the IC-718 initial start menus - turn the radio off, press and hold the "Set" button on the radio while turning it back on. You should now see the menu - use the "Up | Down" buttons to navigate through the menu, and turn the main knob to change a parameter setting on the selected menu item. I most strongly recommend you do *NOT* change anything else at this point - just use the "Up | Down" buttons to find the:
CIV 731 set to "of" (off).
CIV TRN - set to "of" (off).
CIV ADD - the default address should be "5E" (if it is not, there may be reason for that - but the default load of rigctld, (the rig control daemon) will expect to find this radio with an address of "5E").
CIV BAUD - set to "Hi" (I don't remember if that is default, but this works well for me).
You should now be able to turn the radio off and those settings will be remembered by your rig.
-----
New QSO | File | Preferences
TRX control tab:
Set "Path to rigctl binary" to /usr/bin/rigctld
Set "Radio one Desc." to IC-718
Set "Host" to localhost
Set "Rig Model" to 313 ICOM IC-718 (using the drop-down menu)
Set "Device" to /dev/ttyUSB0 (that last character is a zero - need to verify yours may be 1, 2, 3, etc.)
Set "Poll Rate" to 500 (current default)
Set "Port Number" to 4532 (current default)
Click to "X" Run rigctld when program starts <-- this is *very* important for rig control
For now, I recommend leaving the rest of the items at their default settings
You should not need any additional arguments added for rigctld. CQRLOG will start it with the rig model number, (mine is -m 313), and that automatically sets it up for that specific radio.
Hope this helps the next Ham struggling with the IC-718 and this superb package!
73, de dave W6TUX
Hi Dave,
Thanks for the very useful post which should help a lot of people as it is a good general guide for most radios with appropriate rigs and ports substituted of course.
Your "Click to "X" Run rigctld when program starts <-- this is *very* important for rig control" statement raises an issue for radios which start rigctld like my SDR does. In my case of course I shouldn't start rigctld from CQRLog as it is already running if my radio has been started. However if I start CQRLog first then it does not see rigctld and when I start the radio the connection fails. Similarly if I shut down CQRLog then it appears to shutdown rigctld and a restart will not give me a connection either. I need to do some more research before posting this as a bug or enhancement request but it looks like rigs like mine still have problems although I am glad that yours is sorted.
73, Graeme ZL2APV