I have added myself to the groups but not sure if the USB Ports are part of the groups I added myself to, see photo of groups:
When I perform the command rigctld -m 237 -r /dev/ttyUSB0 -s 9600 -vvvvv, I get the following results:
A shot in the dark here but what are the permissions set to for /dev/ttyUSB0? Try
ls -l /dev/ttyUSB0
To set it so all can read/write to it, try
chmod 666 /dev/ttyUSB0
and see if that helps.
1 Like
I agree with @satcolintel5 , first check with
ls -l /dev/ttyUSB0
for the user and group permissions of the serial port device file /dev/ttyUSB0. If it is something like user: root, group: dialout, you can add yourself to the group dialout with:
sudo adduser jimgar dialout
The dialout group is documented here for debian, linux mint being a related distribution.
After this you need to logout and login again (to update the groups for the current session) and your user will have access.
Thanks for everyone’s assistance I appreciate your efforts. Here is the commands that were recommended and the results:
I then logged out and back in and tried the rigctld command and here is the results:
Do I need to make it dialout 188 ?
In your last screenshot the wrong serial port was used: /dev/tty0 instead of /dev/ttyUSB0.
Please try again using the following command:
rigctld -m 237 -r /dev/ttyUSB0 -s 9600 -v
Thanks Fabian, for noticing that error; I corrected the command to rigctld -m 237 -r /dev/ttyUSB0 -s 9600 -v and it ended stating communications timed out, so I added 4 more v so you to see what was happening. see photos below it is actually one output to large to get in one photo. Thanks!
Ok it’s not the group dialout permission problem however…
Did I read rite, you are using one of those RS232 to USB converter cable with a Windows system?
In that case…
If it’s not the genuine expensive cable Windows installs the driver and immediately updates the driver which will reject the clone non genuine cable. This is old news. May not be relevant any more. I’m a Linux user now and don’t have these problems.
From memory to get around this problem was to install the driver which came with the clone cable then prevent Windows from updating the driver automatically and it all works.
I may be wrong here as this info is many years old.
I am using an FTDI USB to 8 pin mini round cable. I can successful program my radio using it with windows 10. If I remove it while Linux is loaded it shows it recognizes it and it has been removed. This cable was purchased for m Kenwood TM- V71a about 2 years ago and I use it regularly.
Could the problem be related to having Linux Mint installed on an external Serial ATA 1TB Drive, 7200 RPM / 32 MB cache. I have the ATA Drive enclosed in a case with a USB 3.0 cable connected to my laptop. It all appears to be running normally, but I thought I would let everyone know the configuration.
After reviewing this entire thread, I see once the permission issues in Linux were resolved, I end up with the same issue that I had with windows, no reply from the rig - communications time out. I have stated before I believe the driver does not work with a Kenwood TM- V71a. If anyone has had success using the Kenwood TM- D710(G) driver and Kenwood TM-V71a, I would like to know. I really appreciate everyone’s inputs and efforts to resolve the problem, but I’m not sure this configuration has ever worked.
Linux plays nice, but Widows is different. If you have been programming with that cable in Windows then that is not the problem. I’m assuming you are not running Linux and Windows at the same time but select one or the other with a boot loader.
I assume you have selected the correct COM port, that only leaves the driver.
I found in Linux sometimes you have to switch between /dev/ttyUSB0 and USB1 after unplugging and re plugging a USB device.
1 Like
ok, so now Hamlib can connect to the serial port and send commands, but doesn’t get the expected (or any answer?) back from the radio, thus running into the timeout. This might be caused by:
-
incorrect serial port: Maybe
/dev/ttyUSB0is not the radio but something else? Test by runningsudo dmesg -w, then pull the usb device out and put back in. You sould see a lot of messages appear, one of them metioning the correctdev/tty{USB0 | ACM0 | xxx}device. - incorrect baud rate
-
incorrect radio model selected: According to this post the TM-V71a is supported by the TM-D710 driver in Hamlib. To check which model number to use, run
rigctl --list.
Can you please post the output from terminals by using copy-and-paste into the posts here, and then guard the pasted text with three backticks (like this: ```)? This way your posts will be much easier to read.
I also recommend to check which Hamlib version is installed with
rigctl --version
The supported radios and the required model number differ between the Hamlib versions.
I am still confident that the TM-V71a might work, based on this post.
edit: 2021-11-04
I ran sudo dmesg -w, I then pulled out the cable for the radio and then replaced it , I truncated the results to the just show what was removed and what was replaces.
‘’’
279.101348] usb 1-1.3: USB disconnect, device number 4
[ 279.102073] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 279.102132] ftdi_sio 1-1.3:1.0: device disconnected
[ 289.819513] usb 1-1.3: new full-speed USB device number 13 using xhci_hcd
[ 289.928288] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 289.928293] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 289.928296] usb 1-1.3: Product: FT232R USB UART
[ 289.928299] usb 1-1.3: Manufacturer: FTDI
[ 289.928301] usb 1-1.3: SerialNumber: A106Y9KJ
[ 289.938118] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[ 289.938208] usb 1-1.3: Detected FT232RL
[ 289.939036] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
‘’’
I verified the radio is set for 9600 baud rate
HamLib 3.3 is the version I am using in Linux.
I hope this helps, Thanks!
I forgot to mention that I verified the port is correct and I only run one operating system at a time. Thanks
Ok, so correct port, correct baudrate.
Hamlib 3.3 (commited 2018-05-08), so this riglist.h is used. For the 3.x Hamlib version I susepct the current radio model number to use is 234. Check with
rigctl -l | grep -i "TM-D710"
So, the following is required for TM-D710-compatible devices in Hamlib 3.3:
rigtcl -m 234 -r /dev/ttyUSB0 -s 9600 -v
If this still produces timeouts, it is very very likely that it is not a software/config problem on the host running Hamlib, but either
- error in the physical connection
- USB serial adapter doesn’t work?
- error in the radio?
Hi Kerel , looks like we have made some headway as I am not getting time outs. I may have been using the wrong radio number. I was using 237 instead of 234. Here is the output from the rigctl entries I made as you suggested:
‘’’
234 Kenwood TM-D710(G) 1.0.1 Beta
jimgar@jimgar-UX305UA:~$ rigctl -m 234 -r /dev/ttyUSB0 -s 9600 -v
Opened rig model 234, ‘TM-D710(G)’
Rig command: ^C
jimgar@jimgar-UX305UA:~$ rigctld -m 234 -r /dev/ttyUSB0 -s 9600 -v
Opened rig model 234, ‘TM-D710(G)’
Closed rig model 234, ‘TM-D710(G) - will reopen for clients’
^C
Much Appreciated
1 Like
Good afternoon,
@jimgar I am sorry I missed your reply but it seems others where also very helpful and you now have a working interface and whole lot of extra Linux knowledge.
Hi Jan, not a problem, I appreciate all the support I received from everyone who was engaged in the resolution. I learned something from each individual that replied and I am very thankful.
Much Appreciated.
Jim
1 Like