Topics

IC-7000 Control via FLRig and Hamlib for all Digital Modes

Keith Kaiser
 

I broke it! I broke FLRig. Here’s what happened.

My goal is to give WSJTX control of my rig via Hamlib.

First a little background. I’m running MacOS Mojave V10.14.1, my rig is a Icom IC-7000 which I connect to with a CAT cable from RT Systems and a SignaLink. IC-7000 important settings are Baud rate: 19200, CI-V Transceive: OFF

For a couple of years I’ve been running WSJT-X without any issues except that WSJT-X would not control my rig. In fact the only way WSJTX would work for me was to have ‘NONE’ in the rig settings. Turns out I had a really old v1. Version of Hamlib on my Mac. With help from Mike, W9MDB we hunted it down and deleted it from my machine. 

But the old version of Hamlib was not causing the problem. Again with Mike’s help we searched out the Hamlib that comes with WSJTX and then tested and tweaked that to make things work. And it did, sort of. The dreaded “Rig Control Error” comes up frequently. My settings in the Radio tab of WSJTX, Rig: Icom IC-7000, Serial Port: /dev/tty.usbserial-RT19XE27, PTT Method: CAT, Mode: USB, Split Operation: Rig. Yes, we tried ‘Fake It’.

The errors were:
Hamlib error: Communication bus error while getting current VFO frequency
Another one that shows up is:
Hamlib error: Communication bus error while getting PTT state

So Mike suggested we try using FLRig as the interface instead of going direct to the radio.  This caused just as many issues as before but then I discovered that if FLRig is on the desktop, not hidden (Mac) and not behind another window, things worked. Also, FLRig causes the external monitor I use with my laptop to shake and and sometime roll, other times go black then come back, in short it reacted negatively to FLRig being on that desktop.

Mike and I thought maybe the problem was do to an App Nap issues, the suggest was to turn it off for FLRig. Unfortunately FLRig does not support App Nap, so I looked for another solution. MacOS does give me the ability using Terminal to turn it off for ALL applications. While I didn’t want to do that I figured I'd try it for now and see if it helps FLRig. So I turned it off for all apps with this Terminal entry.

defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

It didn’t work. So I tried an idea from a blog to turn off just FLRig. First I ran the above with NO instead of YES. Using ‘Activity Monitor’ I could see that App Nap was set to NO for everything, including FLRig. Running it with NO did not change anythings… Ooops!

Damn the torpedoes full speed ahead I set App Net for FLRig directly like this using Terminal.

defaults write flrig NSAppSleepDisabled -bool YES

For the first time Activity Monitor now says ‘Yes’ in App Nap and FLRig. Which means it is preventing sleep, a little counter intuitive if you ask me.

Unfortunately if FLRig is behind another window or hidden from view the radio does not respond, implying that FLRig is asleep on the job. Additionally if I put it on the second monitor that monitor quite literally goes nuts, and can not be used. 

Mike thought and I agreed I should ask the more general user group…. You guys.  Thoughts are welcome, I’m open to phone calls, remote control via TeamViewer, ideas to try. Anything

Keith, WA0̷TJT


Joseph Vilardo
 

Keith

The IC7000 are notorious for the CI-V port to become intermittent or fail completely. Icom used a really cheap 3.5 mm jack directly soldered to the main pc board and they can't tolerate any torque on the jack. The solder joint fails.  I have owned 2 IC7000 and had this failure on both radios. After the last repair I use a short 10" 90 degree 3.5 mm extension cable which I leave plugged in and secured to the rig with a zip tye so that there is no torque or movement on the plug that goes into the ci-v port on the 7000. The other end of the cable is terminated in a 3.5 mm female jack that I use to plug in any cable I want connected to the ci-v port. 

Check you CI-V port and make sure it is reliably communicating through the CI-V port.

73's

Joe

On 11/12/2018 12:59 PM, Keith Kaiser wrote:
I broke it! I broke FLRig. Here’s what happened.

My goal is to give WSJTX control of my rig via Hamlib.

First a little background. I’m running MacOS Mojave V10.14.1, my rig is a Icom IC-7000 which I connect to with a CAT cable from RT Systems and a SignaLink. IC-7000 important settings are Baud rate: 19200, CI-V Transceive: OFF

For a couple of years I’ve been running WSJT-X without any issues except that WSJT-X would not control my rig. In fact the only way WSJTX would work for me was to have ‘NONE’ in the rig settings. Turns out I had a really old v1. Version of Hamlib on my Mac. With help from Mike, W9MDB we hunted it down and deleted it from my machine. 

But the old version of Hamlib was not causing the problem. Again with Mike’s help we searched out the Hamlib that comes with WSJTX and then tested and tweaked that to make things work. And it did, sort of. The dreaded “Rig Control Error” comes up frequently. My settings in the Radio tab of WSJTX, Rig: Icom IC-7000, Serial Port: /dev/tty.usbserial-RT19XE27, PTT Method: CAT, Mode: USB, Split Operation: Rig. Yes, we tried ‘Fake It’.

The errors were:
Hamlib error: Communication bus error while getting current VFO frequency
Another one that shows up is:
Hamlib error: Communication bus error while getting PTT state

So Mike suggested we try using FLRig as the interface instead of going direct to the radio.  This caused just as many issues as before but then I discovered that if FLRig is on the desktop, not hidden (Mac) and not behind another window, things worked. Also, FLRig causes the external monitor I use with my laptop to shake and and sometime roll, other times go black then come back, in short it reacted negatively to FLRig being on that desktop.

Mike and I thought maybe the problem was do to an App Nap issues, the suggest was to turn it off for FLRig. Unfortunately FLRig does not support App Nap, so I looked for another solution. MacOS does give me the ability using Terminal to turn it off for ALL applications. While I didn’t want to do that I figured I'd try it for now and see if it helps FLRig. So I turned it off for all apps with this Terminal entry.

defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

It didn’t work. So I tried an idea from a blog to turn off just FLRig. First I ran the above with NO instead of YES. Using ‘Activity Monitor’ I could see that App Nap was set to NO for everything, including FLRig. Running it with NO did not change anythings… Ooops!

Damn the torpedoes full speed ahead I set App Net for FLRig directly like this using Terminal.

defaults write flrig NSAppSleepDisabled -bool YES

For the first time Activity Monitor now says ‘Yes’ in App Nap and FLRig. Which means it is preventing sleep, a little counter intuitive if you ask me.

Unfortunately if FLRig is behind another window or hidden from view the radio does not respond, implying that FLRig is asleep on the job. Additionally if I put it on the second monitor that monitor quite literally goes nuts, and can not be used. 

Mike thought and I agreed I should ask the more general user group…. You guys.  Thoughts are welcome, I’m open to phone calls, remote control via TeamViewer, ideas to try. Anything

Keith, WA0̷TJT


Keith Kaiser
 

Thanks Joe,
I had not heard of this issue before but since I have an issue with the audio jack I should have known. In my case this is not the problem but your idea is good to keep in mind.

So I did however solve the issue with the second monitor. When I was putting the FLRig on it all hell would break loose. I switched out the VGA connection for a HDMI and its been rock solid ever since. 

I still have to keep FLRig visible for it to continue working but thats not to hard now that I can put it on the second monitor. My MacBook Pro is just a 13in and WSJT-X and fldigi don't like giving up there real-estate.