I'm experiencing an issue when using Bluetooth on a Raspberry Pi:
The Pi crashes and restarts automatically when using Bluetooth. I can reproduce this behaviour when running the following commands:
Screen #1 /usr/bin/hcitool -i hci0 lescan --duplicates
Screen #2 /usr/bin/hcidump -i hci0 --raw
These two commands are using the Bluetooth interface. Now, when the Pi is experiencing more work load, it will randomly crash and restart after a short time. To emulate this, I can simply run the yes command in another screen to get the Pi working. In practice I want to run a Java Spring application that uses the Bluetooth interface. In that case the crashes appear less frequent, but are still common.
In /var/log/syslog you can see the following error messages:
May 30 12:28:19 pi kernel: [ 1529.456782] bt_err_ratelimited: 83 callbacks suppressed
May 30 12:28:19 pi kernel: [ 1529.456794] Bluetooth: hci0 advertising data length corrected
May 30 12:28:19 pi kernel: [ 1529.508220] Bluetooth: hci0 advertising data length corrected
May 30 12:28:19 pi kernel: [ 1529.557408] Bluetooth: hci0 advertising data length corrected
May 30 12:28:19 pi kernel: [ 1529.606791] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.707340] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.756778] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.808184] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.857370] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.906751] Bluetooth: hci0 advertising data length corrected
May 30 12:28:20 pi kernel: [ 1529.958166] Bluetooth: hci0 advertising data length corrected
These messages appear repeatedly, as long as Bluetooth is in use. When the Pi finally crashes, there is no additional error message. So far I have not been able to find either the origin or fix for these messages. Also, I am not entirely sure wether these errors show the cause of my problem or wether they are a side effect of what's happening somewhere else.
I appreciate any responses and thank you for your help!
That sounds a bit like your power supply isn't capable enough. What Amps (A) or milliAmps (mA) are written on your power supply?
Related
I have an AV Receiver that I want to turn on from standby using cec-client on raspberry pi. The physicall setup is as follows:
RPI --HDMI--> AV Receiver
TV <--ARC_HDMI--> AV Receiver
Scanning my HDMI devices with echo "scan" | cec-client -s -d 1 I get following output:
opening a connection to the CEC adapter...
requesting CEC bus information ...
CEC bus information
===================
device #0: TV
address: 0.0.0.0
active source: no
vendor: Samsung
osd string: TV
CEC version: unknown
power status: standby
language: ger
device #1: Recorder 1
address: 1.0.0.0
active source: no
vendor: Pulse Eight
osd string: CECTester
CEC version: 1.4
power status: on
language: eng
device #5: Audio
address: 3.0.0.0
active source: no
vendor: Harman/Kardon
osd string: H/K AVR
CEC version: 1.4
power status: standby
language: ???
As you can see, my AV Receiver has the device number #5 and physical address 3.0.0.0
I tried following already, using cec-o-matic as reference:
echo "on 3.0.0.0" | cec-client -s -d 0
echo "on 5" | cec-client -s -d 0
echo "tx 15:04" | cec-client -s -d 0
But neither command turns on the AV Receiver. The same commands addressing the TV work without an issue.
After a lot of trial and error, I found out that rebooting my Raspberry Pi actually turns on the receiver! Nice, at least something. Investigating further I found out that in /boot/config.txt one can add/set the hdmi_ignore_cec_init=1 parameter to indicate whether the Raspberry Pi should send an active source message while rebooting. Depending on whether this is set to 0 or 1 my AV receiver turns on when I boot/reboot my RPI.
Now, I obviously don't want to reboot my RPI whenever I want to turn on my AV Receiver. So my question is what is the specific CEC-message the Raspberry sends on boot, so I can replicate it with the cec-client with something along the lines of echo "tx <specific-cec-message>" | cec-client -s -d 1
I already tried monitoring cec traffic on boot with cec-client -f cec.log, but monitoring starts too late and misses the send signal from RPI on boot.
The easiest way to find this out would probably to have a second Raspberry Pi monitoring the bus while the other one boots, but I only have 1 RPI, so I can not test it myself.
Does anyone have an idea, or at least a source for me? Big Thanks for taking the time!
In case it matters here also the specific device models.
TV: Samsung ue55f8090
AVR: Harman Kardon AVR 156
RPI: Raspberry Pi 4 Model B Rev 1.4
RPI_OS: Raspbian GNU/Linux 10 (buster) armv
RPI_KERNEL: Kernel: 5.10.103-v7l+
After more digging, I finally found a solution to my specific problem.
For my setup, as described in my question, one can turn on the Harman Kardon AVR 156 by broadcasting an active source message with the physical address of the TV.
echo "tx 1f:82:00:00" | cec-client -s -d 1
A breakdown of the CEC Frame:
1 = Recording 1 (Raspberry Pi)
F = Broadcast
82 = Active Source
00 00 = ID (TV)
I hope this helps anyone stumbling on this in the future!
I need to get distances from multiple bluetooth beacons for triangulation so that I can do indoor positioning.
I have tried to give as many relevant details as possible. This project is for an RPi, but I am currently trying to test it through my laptop first. I have tried most of what I can find on the internet about this:
The best way I could find to get the rssi values was hcitool rssi <address of beacon>
From here Bluetooth LE Signal Strength Linux
To test this, I tried to get it for my mobile first. It showed "Not Connected". I thought I need to connect first, so I tried many ways to connect my mobile:
a) hcittol cc <address of mobile>
b) gatttool -b <address of mobile> -t random --interactive
c) rfcomm connect 0 <address of mobile> 10
In each case, when I clicked pair in my mobile, connection terminated.
Then, I paired my mobile the usual way from bluetooth menu, and then tried hcitool rssi <Address of mobile> which then finally returned a value -8.
Now that I had it for my mobile, I now moved to beacons.
Then, I tried the same for my beacons. This time I had to
first do hcitool lescan to get addresses of available beacons
then connect to one of the beacons using the command hcitool lecc <address of beacon> which returned the error Could not create connection: Connection timed out
So next, I again tried connecting with the other two ways:
rfcomm connect 0 <address of beacon> 10 which returned the error Can't connect RFCOMM socket: Host is down when I can be sure hci0 was up.
Then I tried with sudo gatttool -b F1:15:A7:E3:17:63 --interactive after which interactive mode opened up and I gave the command connect. This gave different errors after Attempting to connect to <address of beacon>,
mainly connect error : Connection timed out
and Error: connect error: Connection refused (111)
Then I read I need to use -t random from Bluetooth LE on Raspbian , https://ubuntuforums.org/showthread.php?t=2204808 and one another source which I can't find right now.
So I entered sudo gatttool -b F1:15:A7:E3:17:63 -t random --interactive in which when I gave the connect command, I got error Error: connect error: Device or resource busy (16) and also sometimes Error: connect error: Input/Output Error
then I read that I perhaps need to restart my hci0 by hciconfig hci0 down and then hciconfig hci0 up which did the trick, the beacon now got connected.
But then, it quickly got disconnected after saying `GLib-WARNING **: Invalid file descriptor.
`
I read here https://raspberrypi.stackexchange.com/questions/53982/how-to-fix-gatttools-glib-warning-invalid-file-descriptor that this is because of poor connections. I tried keeping the beacons closer, but it did the same.
So I tried to anyway at least get one rssi value during the short duration it is connected. But, even when it was thus connected, I did hcitool rssi <address of beacon> the error came like this:
hcitool rssi F1:15:A7:E3:17:63
Get connection info failed: No such file or directory
To which I haven't yet found a proper solution.
I tried another way of reading the rssi value, which gave the following :
hcidump -R
HCI sniffer - Bluetooth packet analyzer ver 5.37
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> 04 0E 04 01 0B 20 00
> 04 0E 04 01 0C 20 00
> 04 0E 04 01 0C 20 00
> 04 0F 04 00 01 0D 20
> 04 0F 04 00 01 16 20
> 04 0F 04 00 01 13 20
This was before it got disconnected.
I read here Obtain RSSI with hcidump which said to read the 14th byte. since all these seemed to be hex numbers, this would mean that each number is 1 byte. But this way, I only have 7 numbers per line, how can I read the 14th byte?
Getting distance from beacons has been troubling me a lot, and has used up a a lot of my time. Please help me out on this issue. If you can help me find a resource to help me do so, I'd appreciate the help.
You don't need to connect to a device to get the signal strength RSSI values, just use the following code and pipe that to a script that extracts values from the devices you are after:
btmon &
hcitool lescan --duplicates
Still asking about BLE devices and gatttool.
I'm able to send a char-write-cmd in interactive mode, but I'm not able to do the same in non-interactive.
This is what I send in interactive mode :
gatttool -I
[]> connect BTADDR
[BTADDR]> char-write-cmd 0x0040 01
[BTADDR]> exit
In this way I start the Alert service, which in my case makes the buzzer sounds.
In theory, the non-interactive mode should be:
gatttool -b BTADDR --char-write -a 0x0040 -n 01
But this do not send the request command event to the board, I'm checking it using a dev board.
The manual (non-interactive) way to read or write to your BLE peripheral:
To write and receive reply once: (depending on how you configure your BLE device)
sudo gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-write-req -a 0x0025 -n ff
To write and receive reply indefinitely: (Until you disconnect from BLE device or stop your Bluetooth client)
sudo gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-write-req -a 0x0025 -n ff --listen
Notice I only added the --listen option at the end. This mechanism only works if you configure your BLE node (sensor or actuator) to read and reply.
sources::
How to use gatttool non-interactive mode
Bluetooth Low Energy: listening for notifications/indications in linux
All that said, I still do not think it is best to control or get values from a BLE device. My direction is to move forward and use an API (maybe in python) to do the job for you.
https://github.com/peplin/pygatt
This API has been proven to work with Raspberry Pi Jessie destro.
Good day,
I am currently working on a project where PCIe SSDs are constantly being swapped out and tested through benchmark programs such as VDBench and Iometer. The problem I face right now, which is only on the Linux side (got it working fine on windows), is that if the drives were not on at initial boot-up, they never appear under GParted or Disks. Here's what I have done:
Cold boot, PCIe Add-in-card SSD is off. It is then powered on through a pass through card that is logically controlled to make sure power and shorts are not an issue.
I turn the device on, then run:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
Performing a
lspci -tv
The device shows with no issues in the tree. When I check under Disks however, it is not there.
I have tried a bunch of different commands with none of them seeming to help me. I have tried
partprobe
Which did not do anything. and:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/remove"
Followed up another rescan:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
As well as:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/enable"
Still nothing. Also ran:
dmesg
Which shows, amongst other things:
[ 68.128778] pci 0000:82:00.0: [8086:0953] type 00 class 0x010802
[ 68.128797] pci 0000:82:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[ 68.128820] pci 0000:82:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[ 68.133398] pci 0000:84:00.0: [1c58:0003] type 00 class 0x010802
..............................
[ 68.141751] nvme 0000:82:00.0: enabling device (0100 -> 0102)
..............................
I do see a lot of fails in dmesg for other addresses, such as:
[ 1264.718446] pcieport 0000:03:04.0: BAR 14: no space for [mem size 0x00400000]
[ 1264.718448] pcieport 0000:03:04.0: BAR 14: failed to assign [mem size 0x00400000]
[ 1264.718451] pcieport 0000:03:04.0: BAR 13: no space for [io size 0x1000]
[ 1264.718453] pcieport 0000:03:04.0: BAR 13: failed to assign [io size 0x1000]
Although I have a feeling that those are unrelated to what I am doing, although I'd be happy for someone to prove me wrong.
So, after all of these attempts, does anyone know if there is a way (or if it is even possible) to scan for this PCIe Add-in NVMe SSD and be able to use it without rebooting? I also took a look at some of the threads for other HDDs that reference a rescan for sata based drives, but this is NOT that, so referencing that won't help either.
Thanks in advance.
I ran into the same issue benchmarking nvme PCIE passthrough with QEMU / Proxmox.
First take note of the driver in use:
lspci -nnk -s '0000:82:00.0'
It should say
Kernel driver in use: vfio-pci
Now unbind the driver, then reprobe:
echo '0000:82:00.0' > /sys/bus/pci/drivers/vfio-pci/unbind
echo '0000:82:00.0' > /sys/bus/pci/drivers_probe
Check the driver again with:
lspci -nnk -s '0000:82:00.0'
Kernel driver in use: nvme
lsblk should now show the drive. Found the procedure here
I tried doing that to save time which is used by rebooting. The PCI device driver at that time was dodgy at best about successfully rescanning and getting all its ducks in a row. The device was an FPGA presenting a proprietary interface device for a device driver I was developing. That was with kernel 2.6.30-something tried around March 2014. My (substandard, but acceptable) solution was to reboot the system.
I'm trying to communicate with a Di245 through its Virtual COM driver (VCD) in Linux (pdf) and I'm having a strange issue. Internally, an FTDI chipset is used by this device (FT232BL).
Attaching the device by itself isn't registered as a VCD, so I do the following:
sudo modprobe usbserial vendor=0x0683 product=0x2450
which results in the following dmesg message:
usbserial: USB Serial support registered for generic
usbserial_generic 3-3:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
usbserial_generic 3-3:1.0: Tell linux-usb#vger.kernel.org to add your device to a proper driver.
usbserial_generic 3-3:1.0: generic converter detected
usb 3-3: generic converter now attached to ttyUSB0
and I get the /dev/ttyUSB0 device as promised. So far, everything seems ok.
However, if I open the port in my code, I get a bunch of 1` from it (alternating 1 and `). Trying with screen:
screen /dev/ttyUSB0 115200
I continuously receive 1`. This is definitely not something the device is sending and oddly enough, if I put a random baudrate, I keep getting the same thing.
Is this a way some error is being reported? What could be triggering this behavior and how can I address it?
The solution was the following:
# modprobe usbserial vendor=0x0683 product=0x2450
# modprobe ftdi_sio
# echo "0683 2450" >> /sys/bus/usb-serial/drivers/ftdi_sio/new_id
This way, the ftdi_sio driver knows which vendor/product to provide VCD for. The following udev rule (say, 99-di245.rules) can automate this:
ACTION=="add", ATTRS{idVendor}=="0683", ATTRS{idProduct}=="2450", RUN+="/sbin/modprobe ftdi_sio" RUN+="/sbin/modprobe usbserial vendor=0x0683 product=0x2450" RUN+="/bin/sh -c 'echo 0683 2450 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"
It is installed with:
$ sudo cp 99-di245.rules /etc/udev/rules.d
$ sudo udevadm control --reload