Danny, thank you for the reply.
There is a way to find the device, yes
Basically instead of using /dev/ttyUSB0 or 1 I'm targeting it by ID by using /dev/serial/by-id/............
I had not however tried /dev/ttyUSB* but just gave it a go and the results were the same. /dev/ttyUSB1 DTR gave a dead key
I am however going to give creating a link to each device a go so they are better sorted as found here () starting at 8:39.
Something I didn't realize you could do until I saw that.
Basically once I figure out exactly what is what I'm going to at least create a /dev/300PTT and a /dev/857PTT link with rules so that no matter how or when the system starts I will always know exactly where and what my /dev/PTT is.
I'm about 90% sure /dev/USB1 and /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if01-port0 is CAT/PTT control and I believe the problem is that PTT is controlled by CAT and not just a simple RTS DTR command.
The question is how to work with and/or around a CAT command for something so new that it's not listed in any libraries yet?
On the SCU-17 you have two devices per SCU-17. One is CAT control the other is a sound interface.
For instance I have /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2 and /dev/ttyUSB3 as I have two SCU-17's connected.
ls /dev/serial/by-id/ lists them as the following...
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00AC0110-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00AC0110-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if01-port0
The other SCU-17 is connected to a 857D and that is listed in hamlib, well the 857 is, not the 857D specifically though the commands should be the same.
FLRig has absolutely no problem controlling the 857D so for FLDigi, WSJTX and JS8Call I just point them to FLRig for control and it works great, plus it allows me control of my rig on my screen, pretty much just bling there but hey, whatever, could come in handy for remote stuff.
Anyhow, indeed a good thought about using another app to control it, it does have me thinking about other ways to achieve the same objective though not certain how at the moment.
