Not sure if you know what udev rules are but it might help to create a rule for this device. From what I’ve found googling, the FTDI devices have been a pain to quite a few people. I’ve never run across this problem but I generally create udev rules for all my plug/n/play hardware.
Put the following line in this file: /etc/udev/49-ftdi.rules
My FTDI cable just works but I do remember removing the brltty process from my system quite some time ago. Here’s what happens when I plug in the FTDI cable:
[ 2012.638984] usb 1-1: new full-speed USB device number 5 using xhci_hcd
[ 2012.792188] usb 1-1: New USB device found, idVendor=0403, idProduct=6001
[ 2012.792194] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2012.792198] usb 1-1: Product: TTL232R
[ 2012.792201] usb 1-1: Manufacturer: FTDI
[ 2012.792203] usb 1-1: SerialNumber: FTE3RR1N
[ 2013.328753] usbcore: registered new interface driver usbserial_generic
[ 2013.328821] usbserial: USB Serial support registered for generic
[ 2013.332741] usbcore: registered new interface driver ftdi_sio
[ 2013.332813] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 2013.332877] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
[ 2013.332968] usb 1-1: Detected FT232RL
[ 2013.333164] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
(base) dlarue@Lenovo-Z70-80:~/Projects/NXT-Robotics/ROS$ ls -l /dev/ttyUSB0
crw-rw-rw-+ 1 root plugdev 188, 0 Jan 4 15:04 /dev/ttyUSB0
Did you remove brltty by first stopping the process and then removing it from the system using apt?
I generally use the process list command( ps -fe ) to first show it is running, stop it, then check again to make sure it stopped and then remove it.
Removing it with apt and then rebooting also works but I don’t like rebooting my computer so I always do it the controlled way.
Did you check to see if /dev/ttyUSB1 is there? You can see that the Ruida/FTDI device driver is attaching to ttyUSB1 this time so please see if that device is there.
You just showed output which showed that it was connecting to ttyUSB1…
What we are trying to do is see if the Ruida device is getting created so when you look at dmesg output and it shows the device then that is what you are wanting to look for. it showed ttyUSB1 so that is the device in the /dev directory you should have looked for.
The reason why we’ve been messing with the brltty application is because others( Please read the forum post I linked above ) found that the brltty application is attaching to the ttyUSB0 device and for whatever reason removing it.
also, for the 3rd time will you please run the 4 steps, I’ll list them again but this time, unplug your Ruida cable and turn it off, shutdown your computer, restart both the Ruida and the computer, log in, then
sudo modprobe ftdi_sio
echo 0403 6001 | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id
when you don’t tell me what you got from doing the steps I can’t tell you did them… It’s also important to look and read the output shown after commands are run. Sometimes there’s information things didn’t go well and that’s important to know both if the ommands worked and if the device still doesn’t show up.
I only saw you show a picture of you running dmesg and grep’ing for brltty.
I have one last thing to try… that is to create a device rule which will cause the device name to be ttyLASER instead of ttyUSBx. Run this command sequence: Notice after the echo word there is a single quote character and all the stuff in side should be there with matching double quotes around things and finally a single quote before the pipe symbol. The pipe symbol is “|” one.
you are trying to list the same “wrong” file… Try listing the correct file.
FYI, you can start typing the command “ls -l /etc/udev/ru”
and along the way you can hit the tab key on the keyboard and it will try to auto-complete the path and file. If the characters shown are unique, it will auto complete to the next directory. If not you can hit tat twice and it will list all the things which match those characters