Successful device detection and the assigned device.
The necessary Linux driver to access USB BitScopes is included as standard with the kernel in all modern distributions. If you want to check the kernel has created a device for BitScope when you plug it in, run the following command (as root) and then plug in your USB BitScope. You should see output like this:
root@fermi:~# tail -f /var/log/syslog
kernel: [ 2008.848139] usb 1-6.1.3: new full-speed USB device number 9 using ehci_hcd
kernel: [ 2008.948383] usb 1-6.1.3: New USB device found, idVendor=0403, idProduct=6001
kernel: [ 2008.948389] usb 1-6.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [ 2008.948393] usb 1-6.1.3: Product: BA10U BitScope BS10
kernel: [ 2008.948396] usb 1-6.1.3: Manufacturer: METACHIP
kernel: [ 2008.948398] usb 1-6.1.3: SerialNumber: BSVI53TJ
kernel: [ 2008.952660] ftdi_sio 1-6.1.3:1.0: FTDI USB Serial Device converter detected
kernel: [ 2008.952690] usb 1-6.1.3: Detected FT232RL
kernel: [ 2008.952692] usb 1-6.1.3: Number of endpoints 2
kernel: [ 2008.952694] usb 1-6.1.3: Endpoint 1 MaxPacketSize 64
kernel: [ 2008.952696] usb 1-6.1.3: Endpoint 2 MaxPacketSize 64
kernel: [ 2008.952697] usb 1-6.1.3: Setting MaxPacketSize 64
kernel: [ 2008.953036] usb 1-6.1.3: FTDI USB Serial Device converter now attached to ttyUSB0
root@fermi:~#
The important line is the last one reporting ttyUSB0 (or ttyUSB<N> where N is some other number). This is the device (i.e. /dev/ttyUSB<N>) to use to connect with BitScope. Note: there may be other lines reported as other daemons on your system (like mtp-probe) probe the new device to see if it belongs to them. You can ignore these.
Check the USB Driver exists on your system.
If nothing happens when you plug in your BitScope the driver may not be installed. This is very rare these days but you can check (while BitScope is plugged in) with the following command:
root@fermi:~# lsmod | grep ftdi_sio
ftdi_sio 38270 0
usbserial 32061 1 ftdi_sio
usbcore 128741 7 ehci_hcd,uhci_hcd,usb_storage,usbhid,usbserial,ftdi_sio
root@fermi:~#
If these three modules (ftdi_sio, usbserial and usbcore) are not loaded on your system you may need to upgrade your kernel or configure your system to install the ftdi_sio driver. See the driver home page for full details.
Check there are no conflicting packages.
There are some broken packages in the Linux ecosystem which can cause problems. One we know of is brltty.
When you connect your BitScope if the log reports something like this:
root@fermi:~# tail -f /var/log/syslog
[ 1674.671935] usb 3-1: new full-speed USB device number 6 using xhci_hcd
[ 1674.693273] usb 3-1: New USB device found, idVendor=0403, idProduct=6001
[ 1674.693289] usb 3-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 1674.693291] usb 3-1: Product: BS120U
[ 1674.693292] usb 3-1: Manufacturer: METACHIP
[ 1674.693293] usb 3-1: SerialNumber: FTUAYI44
[ 1674.694650] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
[ 1674.694671] usb 3-1: Detected FT232RL
[ 1674.694673] usb 3-1: Number of endpoints 2
[ 1674.694674] usb 3-1: Endpoint 1 MaxPacketSize 64
[ 1674.694676] usb 3-1: Endpoint 2 MaxPacketSize 64
[ 1674.694677] usb 3-1: Setting MaxPacketSize 64
[ 1674.694877] usb 3-1: FTDI USB Serial Device converter now attached to
ttyUSB0
[ 1676.495341] usb 3-1: usbfs: interface 0 claimed by ftdi_sio while
'brltty' sets config #1
[ 1676.495926] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now
disconnected from ttyUSB0
[ 1676.495951] ftdi_sio 3-1:1.0: device disconnected
there is a conflict, in this case with the brltty package per the last three lines of this log excerpt. In our view it's incorrect that any package preemptively claims ownership of a generic serial device so we recommend removing the offending package if you don't need it.
Check you have permission to access the device.
With some distributions you may need to add your user to the dialout group if this is not done automatically. This applies to some recent linux distributions including Ubuntu which have changed the permissions for ordinary users (i.e. only the adminstrator user has access by default).
Assuming your BitScope appears at /dev/ttyUSB0 you can check the permissions from a terminal as follows:
root@fermi:~# ls -l /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 0 Sep 3 21:31 /dev/ttyUSB0
That is, the group permissions should be dialout. Check your login permissions include dialout, type:
$ groups
If dialout is not listed you will need to add it to your login which can be done at the command line as:
$ sudo adduser $USER dialout
where $USER is your user name. You will then need to logout and login again (for the new group to apply) and you should be good to go.
Check there are no stale lock files.
The lock file is a mechanism that restricts access to BitScope to one application at a time. The lock file is created by the app when the app starts and deleted when it terminates. If an app terminates abnormally or is manually killed the lock file may remain in place preventing further access to the device. You can check this as follows:
root@fermi:~# ls /var/lock
LCK..ttyUSB0
In this case the /dev/ttyUSB0 device is locked. Simply delete this file if it exists (when no application has the device open). Note: if you want to share one USB BitScope between multiple applications, or even multiple users on different computers you can; see BitScope Server for details.
The Local Probe File (details)
If you still have problems, especially if you are upgrading from older software versions, the configuration files used by the application software may have been corrupted. The file most likely to cause problems (if corrupt) is the probe file.
The local probe file is located at:
~/.config/bitscope/bitscope.prb
Delete this file to force the software to recreate it with correct information.
The Global Probe File (details)
There is another globally configurable probe file:
/etc/bitscope/bitscope.prb
This is unlikely to be corrupt but if you suspect it is, and you have adminstrator privileges on your PC to modify it, you can delete (or comment out) its contents (don't delete the file itself). It is highly unlikely you will need to do this but we mention it here as a last resort.
