I am a new contributor to this site so please cut me some slack if this question sounds too simple. I have been using to Pi devices as iBeacon readers for a few weeks and i was able to find my LE beacons with no problem using hcitool lescan and hcidump. The problem i am facing now is that for some reason when i run hcitool lescan i see my devices, but hcidump doesn't see to be working - it doesn't even seem to run.
Since hcitool lescan works i know that the devices are working and that my Pi can find them.. but i need the hcidump to work as my code pulls from this output for my programs to run properly.
Any thoughts on what could be causing this? What information can I provide to help you understand the situation better?
This is a known bug with bluez.
To rectify it you simply need to shut down the Bluetooth interface and re-enable it.
sudo hciconfig hci0 down
sudo hciconfig hci0 up
hci0 being the interface of your Bluetooth dongle.
You can then run the dump simultaneously with the scan:
sudo hcitool lescan --duplicates & sudo hcidump -w file.txt
Related
I have Raspberry Pi Zero W and this hat.
I did the following things:
disabled login shell through serial in rasp-config
enabled serial port hardware in rasp-config
removed console=serial0 in /boot/cmdline.txt
added lines to /boot/config.txt:
enable_uart=1
dtoverlay=pi-miniuart-bt
Then I restart the RPI.
Problem...
But when I do sudo minicom -D /dev/serial0 (serial1, ttyS0, and ttyAMA0 doesnt work either), it says its offline...
Am I missing something?
Here are all the files that might be interesting:
cmdline.txt
config.txt
To switch the bluetooth controller to the mini-UART so you can use the PL011 UART to communicate with your HAT, you should specify
dtoverlay=miniuart-bt
Alternatively you can use
dtoverlay=pi3-miniuart-bt
which was kept around for backwards compatibility.
EDIT: This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I'm currently following this tutorial to connect my Raspberry Pi Zero W running Jessie Lite to the RTC DS1307.
The rtc is being recognized when running sudo i2cdetect -y 1 with "UU", so everything fine until this point.
But when entering sudo hwclock -D -r I'm getting an error:
Does anybody have any experience or hints with this error? I was researching for 1 1/2 day now, but could not find a working solution. Any help is appreciated.
Back then I was not able to answer my own question. I have already edited the main post, but to close this question:
This problem is solved! the problem was a script running on the pi, which occupied the SCL pin (in my case a script listening for a shutdown button). So it was not able to read the rtc.
I'm trying to set up a FONA 808 to connect to the internet to a Raspberry Pi 3, but when I run the serial console "sudo screen / dev / serial0 115200" I'm sometimes answered with "OK" and in others the console displays the message as if it were electromagnetic noise, and at other times the console simply crashes Is this normal? How can I solve that?
I am using a Fona 808 Arduino Shield connected to 5V and the TX and RX ports pass through a level logic shifter to convert the logic of 5V of the fona to logic of 3.3V of the raspberry
I am following this tutorial:
https://learn.adafruit.com/fona-tethering-to-raspberry-pi-or-beaglebone-black/setup
Blocked console:
Electric noise display:
Check your /boot/cmdline.txt file.
This is how I solve my pi with the same error.
nano /boot/cmdline.txt or sudo nano /boot/cmdline.txt
copy the script below and paste this in your cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
make sure "console=ttyAMA0,115200" is not on the script.
Make sure you have your original script. Test your pi if it reboot correctly. If it doesn't you can change back the cmdline.txt directly on your sd card and paste your original script.
This command should work with the response back
sudo screen /dev/serial0 115200
AT
ok
This should be a comment but I don't have the reputation to comment so...
Couple of things to try that might help.
1) You shouldn't need the level logic shifter. I don't know exactly what FOAN board you are using but they normally have a Vio pin that sets the voltage of the logic. So in this case you just connect the Vio pin to 3.3V on the Raspberry Pi and the RX and TX will be working at 3.3V.
2) Check your wire connections. Might just be a case of a bad connection.
3) I had better luck with minicom than screen So a command like this should work to connect the bard. sudo minicom -b 115200 -o -D /dev/ttyS0
I am trying to establish a communication b/w raspberrypi(Raspbian) and PC(Microsoft XP) through GPIO PINS 14(Tx) and 15(Rx) for sending/receiving data... , RS-232 level converter is using for connection of GPIO to PC serial COM port and Voltage conversion from 3.3V to 12V...
I install minicom (Echo ON) at raspberry side and install Teraterm(ECHO OFF) at PC side.
Whatever I typed on minicom, it successfully appear on Minicom and Teraterm but when I tried same thing on Teraterm, it only appears on Teraterm not on minicom and also blocked by minicom (/dev/ttyAMA0). After that I am not able to send data from minicom to Teraterm.
But I just check one thing more and very surprise that, when shorting GPIO PIN 14& 15 together and starting typing on minicom... it just show me one character and stop after that...
Again I repeat whole process by closing/opening minicom, again it just show character and then stop.
Can you plz guide me why it happening and how do I resolve it?
I just read from this link that someone was also facing your kind of problem but not exactly what you are facing.
It is happened because Kernel takeover the control on console so It is good and very important to disconnect the connect of console and kernal from the startup.
Now you can follow these step, I am sure you will get rid from this trouble...
Start editing this file by this command
sudo vi /boot/cmdline.txt
Originally it contained:
dwc_otg.lpm_enable=0 rpitestmode=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
deleted the two parameters involving the serial port (ttyAMA0) to get the following:
dwc_otg.lpm_enable=0 rpitestmode=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
rebooted (sudo reboot) to confirm that kernel output was no longer going to the serial port. But the serial console was still available. So edited /etc/inittab:
sudo vi /etc/inittab
commented out the following line:
2:23:respawn:/sbin/getty -L ttyAMA0 9600 vt100
Finally, rebooted again and confirmed that nothing was touching the serial port anymore. Then, to test it out installed minicom on the Raspberry Pi:
sudo apt-get install minicom
And ran it:
minicom -b 9600 -o -D /dev/ttyAMA0
After, it is able to send data in both directions!
We are unclear about the functionality of the leadv command in bluez5.
After connecting to a device and disconnecting again it is impossible to reconnect to the same device. Only after calling leadv again it is possible to reconnect.
We have reproduced this behaviour with various platforms (raspberrypi, x86) and various versions of bluez5 (5.15, 5.16, 5.18, 5.21) and bt dongles from broadcom and csr.
Is it possible to reconnect multiple times without readvertising?
bluetoothd with gatt server is running
We issued the following commands
hciconfig hci0 up
hciconfig hci0 noscan
hciconfig hci0 name foo
hciconfig hci0 leadv 0
I am having the exact same issue.
Interesting is that during a disconnect 'hcidump' doesn't show any commands issued by bluez to the bluetooth controller which would indicate that it turned off the advertising.
I am using this workaround to re-enable advertising as soon as a device disconnected:
sudo dbus-monitor --system --profile | grep --line-buffered --only-matching InterfacesRemoved | xargs -n1 -I % sudo /home/pi/bluez/bluez-5.25/tools/hciconfig hci0 leadv 0
Explanations:
'--line-buffered' is needed as dbus-monitor does not flush its output
'-I %' makes xargs not appending the grep'd "InterfaceRemoved" to the executed command
It turned out that it is actually possible to reenable advertising automatically, but it only seems to work with selected bluez/kernel combinations. We finally had it working with bluez 5.21 and a raspberry pi kernel 3.16 for both broadcom and csr dongles. We haven't tried since with other combinations because we switched to custom hardware (TI CC2451) shortly afterwards.