Skip to main content


Anyone know why #DireWolf is hellbent on using /dev/ttyS0 with hamlib? I have this in direwolf.conf, which should force it to use /dev/ttyUSB1:

PTT RIG 1035 /dev/ttyUSB1 38400

But it refuses:
Dire Wolf version 1.7
Includes optional support for:  gpsd hamlib cm108-ptt

Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:0,0  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate.
Hamlib determined CAT control serial port rate of 38400.
User configuration overriding hamlib CAT control speed to 38400.
Retrying Hamlib Rig open...
Retrying Hamlib Rig open...
^C
QRT
Hamlib Error: rig_set_ptt command for channel 0 PTT
rig.c(947):rig_open entered
rig_settings_get_path: path=.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=0
serial_open: /dev/ttyS0
serial_open(335): open failed#1 No such file or directory
serial_open: Unable to open /dev/ttyS0 - No such file or directory
port_open: serial_open(/dev/ttyS0) status=-6, err=No such file or directory
rig.c(1178):rig_open returning2(-6) IO error

rig.c(947):rig_open entered
rig_settings_get_path: path=.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=0
serial_open: /dev/ttyS0
serial_open(335): open failed#1 No such file or directory
serial_open: Unable to open /dev/ttyS0 - No such file or directory
port_open: serial_open(/dev/ttyS0) status=-6, err=No such file or directory
rig.c(1178):rig_open returning2(-6) IO error

rig_set_ptt: rig or rig->caps is null
Invalid parameter

?WATCH={"enable":false,"json":false};

If I make /dev/ttyS0 a symlink to /dev/ttyUSB1, it works flawlessly. What gives? :/

#AmateurRadio #HamRadio #PacketRadio

irrational method reshared this.

in reply to Neil E. Hodges

I've not run into this in the past, but not currently running direwolf this way either.

I've got direwolf set up with rigctld to handle the radio control, so direwolf just gets:
`PTT RIG 2 localhost:4533` (note that's not the standard rigctld port)

This entry was edited (1 month ago)

Neil E. Hodges reshared this.

in reply to Neil E. Hodges

Glad you can make it work that way -- I'm not saying it's the right choice, but it makes a lot of things easier.

I'm sure others involved with #FARPN @farpn might have a guess about your original issue. We've also been able to get `udev` to assign names to the serial ports for radios (like /dev/ic706 instead of /dev/ttyUSBS0), which can help with the issue of inconsistent serial port device names.

in reply to Neil E. Hodges

Old version of hamlib? https://github.com/Hamlib/Hamlib/issues/1454
in reply to edgetriggered

Looks like I'm using a newer version than anything mentioned in that thread:
$ rigctl --version
rigctl Hamlib 4.6.2 2025-02-09T21:03:50Z SHA=870364 64-bit