I'm using an Elecraft KX-3 with an M1 MacBook Air. This is a dedicated ham radio computer with nothing other than a web browser operating in the background. (Lots of empty SSD space!)
I recently updated to Monterey 12.3 and RUMlogNG 5.7.
Here is my strange bug...
I have two TRX#1 Transceiver Set-ups.
One is CW/SSB. This is what I use for CW and SSB operation. It has CAT enabled for transceiver control.
The other is WSJT. This one is identical, except CAT is disabled. That's because WSJT-X controls the CAT system when operating WSJT-X. When in CW/SSB Set-up, I close WSJT-X.
This has worked fine for over a year. But, sometime in the last week or so when the software was updated I started to get these strange results.
If RUMlogNG is started and the last TRX Set-up was CW/SSB, control of the KX-3 works as usual. Almost instant.
If I switch to WSJT-X, that works fine. Control is normal.
BUT, if I close WSJT-X and switch back to CW/SSB in RUMlogNG, control either through the panel or by right clicking on a Spot to QSY takes about five seconds to complete. The famed beach ball of death appears, too. Restarting RUMlogNG seems to fix this each time.
What could this be? If there is a way for me to download and install the last version of RUMlogNG, I will do that to see if there is a new bug in RUMlogNG. Of course, it could also be some new feature of Monterey, too. Or, some new bug revealed in WSJT-X by upgrading either RUMlogNG or Monterey.
WSJT-X 5.7 Conflict
Re: WSJT-X 5.7 Conflict
Seems to be a driver issue. Try to disable CAT in WSJT-X before you quit the app.
73 and best dx de Tom, DL2RUM
Re: WSJT-X 5.7 Conflict
OK, makes sense. But, why the change? Monterey?
I tried using the Reset CAT1 button in RUMlogNG - no effect.
I tried using the Reset CAT1 button in RUMlogNG - no effect.
Re: WSJT-X 5.7 Conflict
OK...
I used AppCleaner and completely removed WSJT-X and RUMlogNG and components. Then did a clean install of both. That seems to have fixed the problem.
No idea why!
I used AppCleaner and completely removed WSJT-X and RUMlogNG and components. Then did a clean install of both. That seems to have fixed the problem.
No idea why!
Re: WSJT-X 5.7 Conflict
Here's a 2023 update.
It seems like the clean install didn't really work after all. After a while, whenever I tried to QSY using a spot from the spot window, it took close to 10 seconds before I could see activity on the Elecraft USB to serial adaptor and the radio would respond. I ran out of possible solutions, so I just lived with it.
Updates all the way through the latest version of Ventura and RUMlogNG had no effect on this behavior.
Inspired by DL2JML's post of a few weeks ago, I decided to reinvestigate the situation.
OSX 13.0 Ventura, Serial Interface
It appears that this is indeed a driver issue, as Tom suggested and DL2JML discovered. The Apple drivers partially work. Sort of. Or, perhaps, the way the Apple drivers respond isn't what a programmer might expect. After all, other control panel commands, like changing bands, work perfectly well with the native Apple drivers. It wouldn't be the first time that Apple documentation didn't exactly match the software behavior. I have no idea.
On the FTDI support site I found a somewhat new set of drivers for use with the USB-serial device used in the Elecraft adaptor.
FTDI VCP Drivers
I installed the version 1.5.0 drivers for the most recent version of macOS. This seems to have solved the problem. Now it takes about a second or so for the KX3 to QSY.
For anybody trying this, note that you have to move the FTDI VCP Installation app into your Application folder when you run the installation. From what I can tell, macOS or some extension looks there for the drivers at start up.
Hope this helps somebody out there.
It seems like the clean install didn't really work after all. After a while, whenever I tried to QSY using a spot from the spot window, it took close to 10 seconds before I could see activity on the Elecraft USB to serial adaptor and the radio would respond. I ran out of possible solutions, so I just lived with it.
Updates all the way through the latest version of Ventura and RUMlogNG had no effect on this behavior.
Inspired by DL2JML's post of a few weeks ago, I decided to reinvestigate the situation.
OSX 13.0 Ventura, Serial Interface
It appears that this is indeed a driver issue, as Tom suggested and DL2JML discovered. The Apple drivers partially work. Sort of. Or, perhaps, the way the Apple drivers respond isn't what a programmer might expect. After all, other control panel commands, like changing bands, work perfectly well with the native Apple drivers. It wouldn't be the first time that Apple documentation didn't exactly match the software behavior. I have no idea.
On the FTDI support site I found a somewhat new set of drivers for use with the USB-serial device used in the Elecraft adaptor.
FTDI VCP Drivers
I installed the version 1.5.0 drivers for the most recent version of macOS. This seems to have solved the problem. Now it takes about a second or so for the KX3 to QSY.
For anybody trying this, note that you have to move the FTDI VCP Installation app into your Application folder when you run the installation. From what I can tell, macOS or some extension looks there for the drivers at start up.
Hope this helps somebody out there.
Re: WSJT-X 5.7 Conflict
Further update...
I've been switching modes between CW and WSJT-X a lot of late, because of the various DXpeditions that have shown up.
I'm pretty convinced that the problem I described is not a driver problem. Here's why:
When using WSJT-X software, with the Transceiver Control disabled so that only one application is using the USB control (WSJT-X), the USB control of the transceiver is instant and reliable. It works fine for WSJT-X.
When WSJT-X is closed and the Transceiver Control is Enabled in RUMlogNG, the frequency window is constantly updated as I tune the the VFO on the radio. Changing modes, frequency or anything that can be controlled from the Transceiver Control window works instantly and mostly reliably. (For some reason, sending a CW message sometimes turns the receiver preamp off.) If I send a Macro from the window, it is sent without delay.
The only glitch is when I right click on an entry in the DX Spot window to QSY. When RUMlogNG is first run, it takes a second or two. The longer RUMlogNG is running, the slower it gets. It took 15 seconds to QSY today after being on all day.
So, the driver system seems to work as we want it to for WSJT-X and for most operations from RUMlogNG. It's only the QSY function that slows down.
That make sense?
I've been switching modes between CW and WSJT-X a lot of late, because of the various DXpeditions that have shown up.
I'm pretty convinced that the problem I described is not a driver problem. Here's why:
When using WSJT-X software, with the Transceiver Control disabled so that only one application is using the USB control (WSJT-X), the USB control of the transceiver is instant and reliable. It works fine for WSJT-X.
When WSJT-X is closed and the Transceiver Control is Enabled in RUMlogNG, the frequency window is constantly updated as I tune the the VFO on the radio. Changing modes, frequency or anything that can be controlled from the Transceiver Control window works instantly and mostly reliably. (For some reason, sending a CW message sometimes turns the receiver preamp off.) If I send a Macro from the window, it is sent without delay.
The only glitch is when I right click on an entry in the DX Spot window to QSY. When RUMlogNG is first run, it takes a second or two. The longer RUMlogNG is running, the slower it gets. It took 15 seconds to QSY today after being on all day.
So, the driver system seems to work as we want it to for WSJT-X and for most operations from RUMlogNG. It's only the QSY function that slows down.
That make sense?