I have a 1 x USB to 8 x serial ports hub. I have connected 8 devices to the hub (ttyUSB0...7). I need a way to identify which device is at each ttyUSBx port.
I have tried the following command:
udevadm info -a -n /dev/ttyUSB1 | grep '{serial}' | head -n1
and looked at the log in:
/var/log/messages
as advised here:
http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/
But what I get is the serial number and VendorID:ProductID of the USBtoSerial hub for all the ttyUSBx ports.
Any ideas?
Thanks in advance
Use as this>>
sudo lshw |grep serial
You can find all details about device by type only sudo lshw
Related
I have a pci address for a device, and need to find the pci address of its hostbridge. In FreeBSD 11 it is very easy to do that using "devinfo -v" as you can grep the pci address of the device and then you can find its parent in the tree which is the hostbridge. Now in FreeBSD 10 there is no any pci address in the output of the "devinfo -v". Example of "devinfo -v" output in FreeBSD 11:
pcib4 pnpinfo vendor=0x8086 device=0x2f08 subvendor=0x15d9 subdevice=0x0833 class=0x060400 at pci0:0:3:0 handle=\_SB_.PCI0.BR3A
pci4
mlx5_core1 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700 at pci0:3:0:0 handle=\_SB_.PCI0.BR3A.H000
mlx5_core2 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700 at pci0:3:0:1 handle=\_SB_.PCI0.BR3A.H001
Example of "devinfo -v" output in FreeBSD 10:
pcib4 pnpinfo vendor=0x8086 device=0x2f08 subvendor=0x15d9 subdevice=0x0833 class=0x060400
pci4
mlx5_core1 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700
mlx5_core2 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700
So You can see that the pci addresses are not appearing in output of FreeBSD10
There is 2-step workaround. At first find device name:
pciconf -l -v | grep "pci0:2:0:0" | cut -f 1 -d #
In my case it's sdhci_pci0.
Then find location in devinfo:
$ devinfo | grep -B 5 sdhci_pci0
pcm2
pcm3
pcm4
pcib1
pci2
sdhci_pci0
Note:
On FreeBSD10.2-STABLE I can see PCI info in output of devinfo.
Another possibility is to walk through the dev sysctl tree:
You can grep for the PCI address you have in the %location OID:
$ sysctl dev | grep %location
dev.hdac.1.%location: pci0:0:27:0 handle=\_SB_.PCI0.HDEF
dev.hdac.0.%location: pci0:2:0:1
dev.vgapci.0.%location: pci0:2:0:0 handle=\_SB_.PCI0.PEG3.MXM3
dev.hostb.15.%location: pci0:255:5:3
dev.hostb.14.%location: pci0:255:5:2
You can then find the parent using the %parent OID. For instance, the parent of pci0:2:0:0 (listed in the example above) is pci1:
$ sysctl dev.vgapci.0.%parent
dev.vgapci.0.%parent: pci1
The parent has its own sysctl tree:
$ sysctl dev.pcib.1.%location
dev.pcib.1.%location: pci0:0:3:0 handle=\_SB_.PCI0.PEG3
Not the most straightforward approach, but it should work accross different versions of FreeBSD (and probably DragonFlyBSD FWIW).
Try devinfo -rv.
A snippet of output on FreeBSD 10.3:
atapci1 pnpinfo vendor=0x8086 device=0x27c0 subvendor=0x1043 subdevice=0x8179 class=0x01018f at p
ci0:0:31:2 handle=\_SB_.PCI0.IDE1
Interrupt request lines:
0x13
I/O ports:
0xb880-0xb88f
0xbc00-0xbc03
0xc000-0xc007
0xc080-0xc083
0xc400-0xc407
ata2 at channel=0
ata3 at channel=1
Getting status of serial ports (ttyS*) via linux terminal is simple:
sudo cat /proc/tty/driver/serial
Then it shows serinfo with list of all uarts with info about status and buffers. When I call
sudo cat /proc/tty/drivers
then I can see that rfcomm drivers are available:
rfcomm /dev/rfcomm 216 0-255 serial
And, of course, reading data comming from paired bluetooth device is not a problem.
The question is: how to get status of rfcomm serial ports (e.g. Blueotooth SPP devices)? Is this information available somewhere in the /proc directory like for ttyS* or could I use totally different way?
It depends what status you are looking for. The "rfcomm" command that comes with bluez does have some status info. It depends if that is adequate for you.
% rfcomm -h
RFCOMM configuration utility ver 4.101
Usage:
rfcomm [options] <command> <dev>
Options:
-i [hciX|bdaddr] Local HCI device or BD Address
-h, --help Display help
-r, --raw Switch TTY into raw mode
-A, --auth Enable authentication
-E, --encrypt Enable encryption
-S, --secure Secure connection
-M, --master Become the master of a piconet
-f, --config [file] Specify alternate config file
-a Show all devices (default)
Commands:
bind <dev> <bdaddr> [channel] Bind device
release <dev> Release device
show <dev> Show device
connect <dev> <bdaddr> [channel] Connect device
listen <dev> [channel [cmd]] Listen
watch <dev> [channel [cmd]] Watch
Hello is there any way to get the signal strength of near by bluetooth le devises in linux? Or any good libraries for nodejs, php or mono (I do know some c++ or python but would prefer to say away from them) if a tool does not exisst but would be fairly easy to write.
On Linux, the way to do this is with the hcitool command. However, you have to be connected to get the rssi of a device. If you want to achieve this from the command line, try:
#hcitool rssi AA:BB:CC:DD:EE:FF
If you want to see the actual C code to achieve this, take a look at the bluez tools/hcitool.c file, under the cmd_rssi function.
static void cmd_rssi(int dev_id, int argc, char **argv)
{
...
}
For Bluetooth Low Energy, I only know one way to do this, and that is using the #btmon command. Run btmon in the background then scan for Bluetooth Low Energy devices:
#./btmon &
# hcitool lescan
The results displayed on the monitor should be similar to this:
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Public (0x00)
Address: AA:BB:CC:DD:EE:FF (<Vendor Name>)
Data length: 0
***RSSI: -34 dBm (0xde)***
AA:BB:CC:DD:EE:FF <Device Name>
Note that when using btmon you do not have to connect to get the rssi of a BLE device.
No need to connect when using btmgmt
$ sudo btmgmt find
Discovery started
hci0 type 7 discovering on
hci0 dev_found: 50:8C:FD:99:0A:EC type LE Random rssi -80 flags 0x0000
AD flags 0x06
eir_len 23
…
The relative signal strength indicator is rssi -80, but the list is much longer containing more information about this and other devices.
To spy on your Bluetooth neighbourhood showing only unique MAC addresses with their strongest RSSI, run the following command:
$ sudo btmgmt find |grep rssi |sort -n |uniq -w 33
hci0 dev_found: 40:43:42:B3:71:11 type LE Random rssi -53 flags 0x0000
hci0 dev_found: 44:DA:5F:EA:C6:CF type LE Random rssi -78 flags 0x0000
hci0 dev_found: 7F:7D:08:6B:E0:37 type LE Random rssi -74 flags 0x0000
hci0 dev_found: A4:58:0F:21:A1:8C type BR/EDR rssi -79 flags 0x0000
You can use a combination of:
sudo hcitool lescan --duplicates & ;
sudo hcidump --raw
that will provide you the raw dump of all the bluetooth packets which contain all relevant information you must be interested in such as : UUID, Major, Minor, RSSI, TxPower. You will have to run some kind of script to parse and filter LE packets and make them into readable form.
One of the scripts written with Bash and S editor was provided by jjnebaker here with the problem and solution discussed here
The Other option is to use PyBluez using the example code here
But you might find the solution provided by Switchdoc labs useful according to your needs as well. here
This works for c language, but has an error when casting the bytes that have the information about de rssi signal.
https://github.com/glock45/intel-edison-playground/blob/master/scan.c
this line 121:
printf("%s - RSSI %d\n", addr, (**char**)info->data[info->length]);
should be:
printf("%s - RSSI %d\n", addr, (**int8_t**)info->data[info->length]);
I found these by looking inside bluez-version/monitor/*.c, where btmon program is. You can see the data types and structs, hcidump.c is very useful and packets.c, and main.c too, but there are many to learn about the hci sockets.
I also found a program I was able to edit to do what I wanted as well
I through it up on my github account
https://github.com/tholum/bluez/blob/master/blue.py
i found several solutions, but most were too slow for my needs to use as a tracking function.
check out https://github.com/abandonware/noble containing some examples.
my standalone scanner is also based on abandonware's module and can be found here:
https://github.com/efeuentertainment/BLE-continuous-RSSI-scan
node index.js BLEMAC
continuously lists the RSSI with an update frequency of about 2 per second / depending on BLE device.
also fast updates based on bash is:
sudo hcitool lescan --duplicates &
combined with one of the following lines:
continuous updates
sudo hcidump | grep "E6:4E:57:09:74:E4" -A 4
sudo btmon | grep "E6:4E:57:09:74:E4" -A 7
only the next received update
sudo hcidump | grep -m 1 "E6:4E:57:09:74:E4" -A 4 | grep "RSSI"
sudo btmon | grep -m 1 "E6:4E:57:09:74:E4" -A 7 | grep "RSSI"
hope that helps. it's an old thread but my search engine lead me here anyway.
try :
$ bluez-test-discovery
output :
[ 18:7A:93:05:E4:B1 ]
Name = AMIYJ_E4B1
Paired = 0
LegacyPairing = 0
Alias = AMIYJ_E4B1
Broadcaster = 0
UUIDs = dbus.Array([dbus.String(u'0000fff0-0000-1000-8000-00805f9b34fb')], signature=dbus.Signature('s'), variant_level=1)
Address = 18:7A:93:05:E4:B1
RSSI = -65
Class = 0x000000
gives you : RSSI = -65
For connected devices you can use btmgmt conn-info
e.g.
$ sudo btmgmt conn-info -t 2 E4:0C:E6:59:B6:FC
Connection Information for E4:0C:E6:59:B6:FC (LE Random)
RSSI -78 TX power 0 maximum TX power 0
(You have the code for that command at https://github.com/bluez/bluez/blob/150bbff449c787f26b7de3e6006bdb2ea6365b08/tools/btmgmt.c#L3984-L4030 ).
I think you may also be able to use BlueZ's DBus RSSI property of the org.bluez.Device1 interface :
int16 RSSI [readonly, optional]
Received Signal Strength Indicator of the remote
device (inquiry or advertising).
but that didn't work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"RSSI"
Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'RSSI'
Maybe because the property is optional. Some other properties did work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"Name"
variant eono BTC 01
Trying to solve this problem (ttyUSB0 that works properly than stop working after about 1hr)I'm thinking on if disconnecting and reconnecting the usb device could be a good fix.
So, it is possibile to cut down power to the USB device and repower it programmatically (bash)?
# lsusb -t
1-1:1.0: No such file or directory
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=vend., Driver=, 12M
|__ Port 1: Dev 2, If 1, Class=vend., Driver=cp210x, 12M
On am335x, kernel 3.2.0, ubuntu core armhf.
[ 1.784332] usb 1-1: cp210x converter now attached to ttyUSB0
At the moment I need a complete power cycle to have ttyUSB0 back.
This is the solution:
Find the identity of your usb device.
# tree /sys/bus/usb/drivers/cp210x/
/sys/bus/usb/drivers/cp210x/
|-- 1-1:1.1 -> ../../../../devices/platform/omap/musb-ti81xx/musb-hdrc.1/usb1/1-1/1-1:1.1
|-- bind
|-- module -> ../../../../module/cp210x
|-- remove_id
|-- uevent
-- unbind
So 1-1:1.1 is the identifier of my ttyUSB0(it can be discovered also via dmesg).
Then, disconnect the device (as root):
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/unbind
reconnect it
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/bind
At this point I had the same device but with a different name, it was now ttyUSB1 instead of ttyUSB0.
- To avoid this I added a new rule in /etc/udev/rules.d/ by creating a new file named 99-usb-serial.rules with this line:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea70", ATTRS{serial}=="002DCFAF", SYMLINK+="sameName", MODE:="0666"
where idVendor, idProduct and serial must be the values of your device. This rule will create a new device called sameName linked to the ttyUSB* device normally generated from the OS.
As #Robert Harvey Said,
You first need to find our driver that will help you 'unplug and plug' the usb. Type: ls /sys/bus/usb/drivers which should print something like this: btusb ftdi_sio hub usb usbfs usbhid usbserial_generic uvcvideo. These, are all the drivers for each usb device. Now, lets say mine is ftdi_sio, which is a device i use to program my arduino (atmega328p chip). I am not sure how Your/other usb devices name themselves there. Like, i dont know which of these is my mouse.
Now, you can see the driver's commands using:
ls /sys/bus/usb/drivers/ftdi_sio/, which will print something like: 1-4:1.0 bind module uevent unbind, Where 1-4:1.0 is the device's characteristic code, and the bind and unbind command, which are the 'plug' and 'unplug' command respectively.
Now, if i want to unplug programatically the ftdi usb port, i will type:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind
and, to plug it again:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
Now, we can combine all the commands together, with a ';':
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind ; echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
I need to deal with two pieces of custom hardware which both send debugging data over two serial connections. Those serial connections go through two serial-to-USB converters. The serial-to-USB devices have the same vendor numbers, device numbers, and, apparently, the same serial numbers.
Here's the issue: I want to log the two serial ports separately. The custom hardware needs to be rebooted constantly, and whether they attach to the same /dev/ttyUSB* is completely random. How can I make them pick the same device path every time? I could make it dependent on what port it is plugged into, but that seems kind of hacky.
So, I ran a diff against the output of udevadm, like so:
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB1` > usb1
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB2` > usb2
$ diff usb1 usb2
The output of the diff is long; you can see it here
Grepping for serial (same for both):
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB2` | grep serial
SUBSYSTEMS=="usb-serial"
ATTRS{serial}=="0001"
ATTRS{serial}=="0000:00:1d.7"
Other info:
I'm using PuTTY to read from the serial ports.
OS:
$ uname -a
Linux xxxxxxxx.localdomain 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Please check if the usb-serial converter is based on a ftdi chip?
(You can check driver filenames)
If so; you have a chance to change serial number,or even the manufacturer info.
http://www.ftdichip.com/Support/Utilities.htm
Check the tools; MProg and FT_PROG utility tools.