Topics

Hamlib error v2.3.0-rc3 on Mac OS #Cat_RigControl #BugReport #mac


Frank, DH4FR
 

I’m using v2.2.2 on Mac OS Mojave with IC-7300 and IC-9700. In this setup, the serial port names change with each power supply cycle. To fix this, I have created a small script that creates softlinks based on serial number in /tmp that point to the correct devices in /dev. In WSJT-X in serial port setup you type the filename of the softlink instead of selecting the device name. In my case, I use /tmp/IC-7300_0300xxxx and /tmp/IC-9700_0300xxxx_A. These names are fixed, and are re-created every time I run the script so they point to the correct “SLAB” devices in /dev. As said, this setup has been working perfect with v2.2.2. but with v2.3.0-rc3, I now get a Hamlib error. I don”t get this error when using the “SLAB” device directly, but this would mean I have to reconfigure every time I start WSJT-X. Hope this makes sense :-)
Best 73 Frank


Bill Somerville
 

On 14/01/2021 18:57, Frank, DH4FR wrote:
I’m using v2.2.2 on Mac OS Mojave with IC-7300 and IC-9700. In this setup, the serial port names change with each power supply cycle. To fix this, I have created a small script that creates softlinks based on serial number in /tmp that point to the correct devices in /dev. In WSJT-X in serial port setup you type the filename of the softlink instead of selecting the device name. In my case, I use /tmp/IC-7300_0300xxxx and /tmp/IC-9700_0300xxxx_A. These names are fixed, and are re-created every time I run the script so they point to the correct “SLAB” devices in /dev. As said, this setup has been working perfect with v2.2.2. but with v2.3.0-rc3, I now get a Hamlib error. I don”t get this error when using the “SLAB” device directly, but this would mean I have to reconfigure every time I start WSJT-X. Hope this makes sense:-)
Best 73 Frank
Hi Frank,

why would you have to reconfigure every time you start WSJT-X? Other users with Icom radios have not reported the device names changing. What are you power cycling to cause that?

73
Bill
G4WJS.


Frank, DH4FR
 

Hi Bill,

With both Icom radios connected, Mac OS creates 3 serial ports like this:

crw-rw-rw-  1 root  wheel   18,  30 Jan 15 06:48 /dev/tty.SLAB_USBtoUART
crw-rw-rw-  1 root  wheel   18,  32 Jan 15 06:48 /dev/tty.SLAB_USBtoUART16
crw-rw-rw-  1 root  wheel   18,  34 Jan 15 06:48 /dev/tty.SLAB_USBtoUART17

after a power cycle:

crw-rw-rw-  1 root  wheel   18,  36 Jan 15 06:50 /dev/tty.SLAB_USBtoUART
crw-rw-rw-  1 root  wheel   18,  38 Jan 15 06:50 /dev/tty.SLAB_USBtoUART19
crw-rw-rw-  1 root  wheel   18,  40 Jan 15 06:50 /dev/tty.SLAB_USBtoUART20

This is a known problem with SiLabs drivers on Mac OS, and according to SiLabs, expected behaviour, see here:


Best 73 Frank


Bill Somerville
 

On 15/01/2021 05:56, Frank, DH4FR wrote:
Hi Bill,

With both Icom radios connected, Mac OS creates 3 serial ports like this:

crw-rw-rw-  1 root  wheel   18,  30 Jan 15 06:48 /dev/tty.SLAB_USBtoUART
crw-rw-rw-  1 root  wheel   18,  32 Jan 15 06:48 /dev/tty.SLAB_USBtoUART16
crw-rw-rw-  1 root  wheel   18,  34 Jan 15 06:48 /dev/tty.SLAB_USBtoUART17

after a power cycle:

crw-rw-rw-  1 root  wheel   18,  36 Jan 15 06:50 /dev/tty.SLAB_USBtoUART
crw-rw-rw-  1 root  wheel   18,  38 Jan 15 06:50 /dev/tty.SLAB_USBtoUART19
crw-rw-rw-  1 root  wheel   18,  40 Jan 15 06:50 /dev/tty.SLAB_USBtoUART20

This is a known problem with SiLabs drivers on Mac OS, and according to SiLabs, expected behaviour, see here:


Best 73 Frank

Hi Frank,

OK, so this is mostly an Icom issue because they did not bother to get their SI Labs USB hub programmed with a custom Id for each rig model. Even then if you had two of the same rig there would be an issue.

WSJT-X defers serial port enumeration to the Qt framework on macOS, as it does on other platforms. That framework looks for all serial port devices and then looks up their BSD name which will give the device name in the /dev filesystem. Because it works this way around it will not show symlinks in the list of available serial ports, but that should not be an issue for you since you can put any string you wish in the "Settings->Radio->Serial Port" field. It will work if that string resolves to a real serial port device that is available, whether it be the actual device name in the /dev filesystem or a symbolic link to it.

BTW, you should be using the cu. version of the serial port device rather than the tty. version. The cu. name is intended for applications to connect to, the tty. name is used by the login daemon for incoming terminal connections.

73
Bill
G4WJS.


Frank, DH4FR
 

Hi Bill,

Thanks for the in-depth reply and confirming that my ‘workaround’ with symlinks is valid.
However, this would imply that the Hamlib error I’m getting on v2.3.0-rc3 is a bug? After all, the same setup on v2.2.2 works fine.

(I did some testing with linking to the ‘cu’ device instead of ‘tty’ and I get the same error)

Best 73 Frank


Bill Somerville
 

On 15/01/2021 15:21, Frank, DH4FR wrote:
Hi Bill,

Thanks for the in-depth reply and confirming that my ‘workaround’ with symlinks is valid.
However, this would imply that the Hamlib error I’m getting on v2.3.0-rc3 is a bug? After all, the same setup on v2.2.2 works fine.

(I did some testing with linking to the ‘cu’ device instead of ‘tty’ and I get the same error)

Best 73 Frank
Hi Frank,

sorry for the delay, I'm rather busy at the moment.

So I can see what is going on please put the attached file into ~/Library/Preferences/ . That will cause WSJT-X to write a log file with detailed rig control trace information to the Desktop called WSJT-X_RigControl.log . Run a minimal test starting WSJT-X that fails to connect to your CAT serial device using the symlink, then quit WSJT-X. Send me the WSJT-X_RigControl.log file for analysis please?

73
Bill
G4WJS.


Frank, DH4FR
 

Hi Bill,

Attached the log file. Failed scenario first, then I changed the serial port via drop-down menu and you’ll get an OK scenario.

With the symlink, I can see that the function network_open is called:

[2021-01-16 16:32:32.688564][00:00:03.349221][RIGCTRL:debug] rig_set_conf: rig_pathname='/tmp/IC-7300_03003333'
[2021-01-16 16:32:32.688575][00:00:03.349232][RIGCTRL:debug] rig_token_lookup called
[2021-01-16 16:32:32.688581][00:00:03.349239][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:32.688590][00:00:03.349247][RIGCTRL:debug] rig_set_conf called
[2021-01-16 16:32:32.688596][00:00:03.349254][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:32.688605][00:00:03.349262][RIGCTRL:debug] rig_set_conf: serial_speed='115200'
[2021-01-16 16:32:32.688615][00:00:03.349273][RIGCTRL:debug] rig_token_lookup called
[2021-01-16 16:32:32.688622][00:00:03.349280][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:32.688629][00:00:03.349287][RIGCTRL:debug] rig_set_conf called
[2021-01-16 16:32:32.688636][00:00:03.349294][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:32.688644][00:00:03.349301][RIGCTRL:debug] rig_set_conf: no_xchg='1'
[2021-01-16 16:32:32.688651][00:00:03.349309][RIGCTRL:debug] icom_set_conf called
[2021-01-16 16:32:32.688829][00:00:03.349488][RIGCTRL:trace] starting: Icom: IC-7300
[2021-01-16 16:32:32.688860][00:00:03.349518][RIGCTRL:debug] rig_open called
[2021-01-16 16:32:32.688880][00:00:03.349538][RIGCTRL:trace] rig_open: using network address /tmp/IC-7300_03003333
[2021-01-16 16:32:32.688894][00:00:03.349552][RIGCTRL:debug] port_open called
[2021-01-16 16:32:32.688908][00:00:03.349566][RIGCTRL:debug] network_open called
[2021-01-16 16:32:32.688920][00:00:03.349578][RIGCTRL:debug] network_open version 1.0
[2021-01-16 16:32:32.688937][00:00:03.349595][RIGCTRL:error] network_open: hoststr=/tmp/IC-7300_03003333, portstr=
[2021-01-16 16:32:32.690374][00:00:03.351035][RIGCTRL:error] network_open: cannot get host "/tmp/IC-7300_03003333": Unknown error
[2021-01-16 16:32:32.690408][00:00:03.351067][RIGCTRL:error] error: Invalid configuration


With the SLAB device file, the function serial_open is called.

[2021-01-16 16:32:46.816346][00:00:17.477004][RIGCTRL:debug] rig_set_conf: rig_pathname='/dev/cu.SLAB_USBtoUART29'
[2021-01-16 16:32:46.816357][00:00:17.477015][RIGCTRL:debug] rig_token_lookup called
[2021-01-16 16:32:46.816364][00:00:17.477021][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:46.816372][00:00:17.477030][RIGCTRL:debug] rig_set_conf called
[2021-01-16 16:32:46.816425][00:00:17.477084][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:46.816445][00:00:17.477103][RIGCTRL:debug] rig_set_conf: serial_speed='115200'
[2021-01-16 16:32:46.816465][00:00:17.477123][RIGCTRL:debug] rig_token_lookup called
[2021-01-16 16:32:46.816477][00:00:17.477136][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:46.816490][00:00:17.477148][RIGCTRL:debug] rig_set_conf called
[2021-01-16 16:32:46.816502][00:00:17.477160][RIGCTRL:debug] rig_confparam_lookup called
[2021-01-16 16:32:46.816511][00:00:17.477169][RIGCTRL:debug] rig_set_conf: no_xchg='1'
[2021-01-16 16:32:46.816519][00:00:17.477176][RIGCTRL:debug] icom_set_conf called
[2021-01-16 16:32:46.816591][00:00:17.477250][RIGCTRL:trace] starting: Icom: IC-7300
[2021-01-16 16:32:46.816614][00:00:17.477272][RIGCTRL:debug] rig_open called
[2021-01-16 16:32:46.816629][00:00:17.477287][RIGCTRL:debug] port_open called
[2021-01-16 16:32:46.816652][00:00:17.477311][RIGCTRL:debug] serial_open called
[2021-01-16 16:32:46.820497][00:00:17.481158][RIGCTRL:debug] serial_setup called
[2021-01-16 16:32:46.820527][00:00:17.481185][RIGCTRL:trace] serial_setup: tcgetattr
[2021-01-16 16:32:46.820577][00:00:17.481235][RIGCTRL:trace] serial_setup: cfmakeraw
[2021-01-16 16:32:46.820605][00:00:17.481263][RIGCTRL:trace] serial_setup: cfsetispeed=115200,0x1c200
[2021-01-16 16:32:46.820629][00:00:17.481287][RIGCTRL:trace] serial_setup: cfsetospeed=115200,0x1c200
[2021-01-16 16:32:46.820649][00:00:17.481307][RIGCTRL:trace] serial_setup: data_bits=8
[2021-01-16 16:32:46.820663][00:00:17.481321][RIGCTRL:trace] serial_setup: parity=0
[2021-01-16 16:32:46.821262][00:00:17.481920][RIGCTRL:trace] serial_setup: tcsetattr TCSANOW
[2021-01-16 16:32:46.822825][00:00:17.483486][RIGCTRL:debug] serial_flush called

So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.


NewMini:~ Frank$ ls -la /tmp/IC-7300*
lrwxr-xr-x  1 Frank  wheel  25 Jan 16 15:35 /tmp/IC-7300_03003333 -> /dev/tty.SLAB_USBtoUART29
NewMini:~ Frank$ 


Best 73 Frank







Bill Somerville
 

On 16/01/2021 16:53, Frank, DH4FR wrote:
So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.
Hi Frank,

exactly right. Looks like a regression in Hamlib, it certainly should not be treating a filesystem path as a network address. I'll have a look and sort out a patch to send upstream to Hamlib.

73
Bill
G4WJS.


Bill Somerville
 

On 16/01/2021 19:26, Bill Somerville wrote:
On 16/01/2021 16:53, Frank, DH4FR wrote:
So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.

Hi Frank,

exactly right. Looks like a regression in Hamlib, it certainly should not be treating a filesystem path as a network address. I'll have a look and sort out a patch to send upstream to Hamlib.

73
Bill
G4WJS.

Hi Frank,

it looks like the regression is already fixed in the Hamlib master branch (https://github.com/Hamlib/Hamlib/commit/0ebdaee747a0b15477d62c4b4a4ecf55ad3710b9). If we can get some other issues resolved in time we should be able to pick up that for the next release.

73
Bill
G4WJS.


Frank, DH4FR
 

Hi Bill,

That’s good news. Many thanks for the support !
Looking forward to the new build.

Best regards and 73
Frank

On 16. Jan 2021, at 20:36, Bill Somerville <g4wjs@...> wrote:

On 16/01/2021 19:26, Bill Somerville wrote:
On 16/01/2021 16:53, Frank, DH4FR wrote:
So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.

Hi Frank,

exactly right. Looks like a regression in Hamlib, it certainly should not be treating a filesystem path as a network address. I'll have a look and sort out a patch to send upstream to Hamlib.

73
Bill
G4WJS.

Hi Frank,

it looks like the regression is already fixed in the Hamlib master branch (https://github.com/Hamlib/Hamlib/commit/0ebdaee747a0b15477d62c4b4a4ecf55ad3710b9). If we can get some other issues resolved in time we should be able to pick up that for the next release.

73
Bill
G4WJS.






Frank, DH4FR
 

Hi Bill,

Just a final update after looking at the Hamlib code on github.

Since the strstr() function looks for substrings, I updated my script and added /dev to the path to the symlink-file.
Then I entered /tmp/dev/IC-7300_03003333 in the serial port setting und guess what, works!
(well not really guessing here…)

Thanks again for your support and best 73,
Frank


On 17. Jan 2021, at 07:36, Frank Klop <frank.klop@...> wrote:

Hi Bill,

That’s good news. Many thanks for the support !
Looking forward to the new build.

Best regards and 73
Frank

On 16. Jan 2021, at 20:36, Bill Somerville <g4wjs@...> wrote:

On 16/01/2021 19:26, Bill Somerville wrote:
On 16/01/2021 16:53, Frank, DH4FR wrote:
So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.

Hi Frank,

exactly right. Looks like a regression in Hamlib, it certainly should not be treating a filesystem path as a network address. I'll have a look and sort out a patch to send upstream to Hamlib.

73
Bill
G4WJS.

Hi Frank,

it looks like the regression is already fixed in the Hamlib master branch (https://github.com/Hamlib/Hamlib/commit/0ebdaee747a0b15477d62c4b4a4ecf55ad3710b9). If we can get some other issues resolved in time we should be able to pick up that for the next release.

73
Bill
G4WJS.







Bill Somerville
 

Hi Frank,

that's a good hack, hi!

Unfortunately it also shows that code to do those checks is garbage!! It certainly does not do what was intended, at least it allows your hack workaround to succeed. An unusual case of "two wrongs make a right!"

73
Bill
G4WJS.

On 17/01/2021 11:13, Frank, DH4FR wrote:
Hi Bill,

Just a final update after looking at the Hamlib code on github.

Since the strstr() function looks for substrings, I updated my script and added /dev to the path to the symlink-file.
Then I entered /tmp/dev/IC-7300_03003333 in the serial port setting und guess what, works!
(well not really guessing here…)

Thanks again for your support and best 73,
Frank


On 17. Jan 2021, at 07:36, Frank Klop <frank.klop@...> wrote:

Hi Bill,

That’s good news. Many thanks for the support !
Looking forward to the new build.

Best regards and 73
Frank

On 16. Jan 2021, at 20:36, Bill Somerville <g4wjs@...> wrote:

On 16/01/2021 19:26, Bill Somerville wrote:
On 16/01/2021 16:53, Frank, DH4FR wrote:
So, my ‘outsider’ analysis, is that the symlink is interpreted as network connection, i.e. host:port and this fails.

Hi Frank,

exactly right. Looks like a regression in Hamlib, it certainly should not be treating a filesystem path as a network address. I'll have a look and sort out a patch to send upstream to Hamlib.

73
Bill
G4WJS.

Hi Frank,

it looks like the regression is already fixed in the Hamlib master branch (https://github.com/Hamlib/Hamlib/commit/0ebdaee747a0b15477d62c4b4a4ecf55ad3710b9). If we can get some other issues resolved in time we should be able to pick up that for the next release.

73
Bill
G4WJS.



Rob Freedman
 

I have also been struggling mightily with Mac OS Big Sur, USB interface III. and ICOM 7000. Worked perfectly (WSTJ-X FT-8 and WSPR) before upgrade to Big Sur. I also loaded the latest version of WSTJ-X and reloaded the FTLI drivers. I get audio and decodes, but no CAT control and get the HamLib IO error when I test CAT or hit the transmit button on WSTJ-X. I have poured through all the documentation for WSTJ-X, the MicroHam USB interface (primarily an external sound card), but have not found a solution. Has anyone run across this and solved it?
73s,
Rob WC0R