I am attempting to communicate with a Yaesu FT5DR radio via USB.
When the cable is plugged in, the device is recognized, but no TTYUSBx or TTYACMx
device is created.
The LSUSB command produces:
*Bus 001 Device 004: ID 26aa:0001 Yaesu Musen FT-1D*
According to YAESU support, they only provide drivers for Windows.
I saw this.
In essence in order to program this radio I need to buy a third party cable & software
I also suspect that this cable will ONLY work with Chirp.
I have my own software that I would like to make use of, but it DOES require a usable USB or ACM port.
Thanx for the pointer.
It may be that this radio will go back to the vendor…
CHIRP is a free, open-source tool for programming your radio. It supports a large number of manufacturers and models, as well as provides a way to interface with multiple data sources and formats.
ILL Yaesu FT5DR is using UART RS-232. You can use USB to RS-232 cable.
So I should just be able to connect a serial to USB adapter (with appropriate gender changers) to this?
I shall give that a try (I have a couple of these hanging around).
I think I misread the info. It looks like the cable is made by RT systems (not the Chirp developers). Best price for cable (and RT software) is around $50-$60. I’d think I’d be more likely to obtain a different radio than layout this kind of $$ on yet ANOTHER USB cable to add to my LARGE collection
I did get Chirp to work with my FT5DR using the FT3 driver in Chirp-Next via the RTSystems cable, which is ~$25 at my local HRO. The caveat to getting this work on Chirp-next is a udev rule to apply to the custom USB-id that the RTSystems cable generates. Although I did this on another distro, I morphed the instructions from Ubuntu and Mint to my system rather easily.
My notes I made for both myself and a non-techie friend are here (https://www.schotty.com/Amateur_Radio/Yaesu_FT5DR_Notes/). Hollar if I have something unclear. It works on aforementioned distro just fine, and I see no reason to think SLE/OpenSUSE would be any different. Just make sure that your udev rule has correct path for the two commands. That literally was my only issue.