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.
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.
I've searched around, but I cannot find an answer.
Can I use my Raspberry Pi as an NTP server (independently).
I want to synchronize 4 devices on a LAN for logging. They will be on a LAN with no WAN access... one is a Cisco Switch, one is the Pi and the other two are conversion boxes I want to log things on (they will be NTP client).
I just need them all to sysnc to 1 clock source (the Pi) is there a way to do this? All the answers I find are either to setup the Pi with a GPS module (which I can't do here) or sync it to external NTP servers for cascading the clock down (which I can't do here)... can I use NTP just to send out the Pi's system time ?
You could but best with a time source.
You would need to edit the code for a NTP server, as there isn't much cause to do this.
Best idea is to use a GPS hat on the RPi
http://www.reeve.com/Documents/Articles%20Papers/Reeve_GpsNtp-Pi.pdf
DEAR PEOPLE FROM THE FUTURE: Here's what we've figured out so far...
On your Raspberry Pi, run the following commands:
sudo apt update
sudo apt install ntp
sudo ufw allow ntp # if your firewall is enabled
sudo ufw allow 123
sudo sed --in-place --expression "\$aserver 127.127.1.0" /etc/ntp.conf
sudo systemctl start ntpd
On your Cisco switch, run the following commands:
NOTE - If you are using Cisco IOS, do not forget to force the NTP synchronization using clock read-calendar.
configure terminal
ntp server <the IPv4 address of your Raspberry Pi>
end
clock read-calendar
PS - If you want to shut everything down...
On your Raspberry Pi, run the following commands:
sudo ufw delete allow ntp
sudo ufw delete allow 123
sudo systemctl stop ntpd
sudo sed -i "/server 127.127.1.0/d" /etc/ntp.conf
On your Cisco switch, run the following commands:
configure terminal
no ntp server <the IPv4 address of your Raspberry Pi>
end
I bought a Raspberry Pi 3 Model B, a microstack baseboard and a microstack GPS.
I followed the instructions written in the official documentation but I can't connect to the GPS.
Basically, the GPS led flashes so it means it has find a gps fix, but I can't see any data from the PI.
For example, if I try
cat /dev/ttyAMA0
I get always nothing. I already used raspi-config to disable kernel serial and to enable i2c and spi.
Also if I try
stty -F /dev/ttyAMA0 ispeed 4800 && cat </dev/ttyAMA0"
I get an error.
Anyone has any advice, please?
Or maybe these modules are not compatible with Pi 3?
Thanks a lot!
It's hard telling what has been done, or not done. The 'official' documentation from Microstack provides two methods of setting up the serial port. It then continues with
Automatically Starting gpsd
To automatically start the gps service when the Raspberry Pi® boots, reconfigure the GPS
daemon by typing into a terminal
sudo dpkg-reconfigure gpsd
● Choose <yes> when asked if you want to start gpsd automatically.
● Choose <no> when asked “should gpsd handle attached USB GPS
receivers automatically” .
● When asked which “Device the GPS receiver is attached to” , enter
/dev/ttyAMA0 .
● Accept the defaults for other options.
If you have configured your serial port as per instructions and configured gpsd to automagically start and pick up the device you have just setup, ...then, since the gpsd is handling the device (right?), the device will be busy and the command cat /dev/ttyAMA0 should return cat: /dev/ttyAMA0: Device or resource busy...but, it did not.
Either the serial is not configured as per instructions, or the gpsd is not running and picking up the device, or both.
The goal is not to cat your gps data, but the cat not returning an error indicates something is amiss.
Typically, it's just a typo. But it can be from skipping a step in the process, or mixing instructions from various sources so that the left hand doesn't know what the right hand has done.
Try:
sudo killall gpsd if it returns gpsd: no process found that answers one question.
If it returns with no error, follow it up with cat /dev/ttyAMA0. If it returns nothing, the direction you should look is your serial port configuration.
If sudo dpkg-reconfigure gpsd is not allowing you to reconfigure (I thought it was just me) you can modify the configuration of gpsd by using your favourite editor, e.g. sudo nano /etc/default/gpsd and entering something like:
# Default settings for the gpsd init script and the hotplug wrapper.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="false"
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyAMA0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n -G"
You may find the -n and -G useful. Save and restart.
I finally found a solution:
On the Pi 3, there are more steps to use serial, you have to disable the BT.
Edit config file:
sudo nano /boot/config.txt
Add this at the bottom:
dtoverlay=pi3-disable-bt-overlay
Then run this:
sudo systemctl disable hciuart
This article was very usefull for me
http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/#comment-67160
and i recommand you to read it
Now on RPI3 the Serial port
ttyAMA0 is used by BlueTooth
ttySO refers to the GPIO
The Alias Serial0 refers to the GPIO both on RPI2 and RPI3.
So :
after a reinstallation of Jessie with a recent version to be sure all is clean
as usual
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo raspi-config
go to Advanced options : Would you like a login shell to be accessible over serial? response "yes" (not as in the microstack datasheet )
$ sudo apt-get install python3-microstacknode
To install the gpsd standard tools
$ sudo apt-get install gpsd gpsd-clients python-gps
edit GPSD by
$ sudo nano /etc/default/gpsd
and put the options :
START_DAEMON="true"
USBAUTO="false"
DEVICES="/dev/serial0"
GPSD_OPTIONS="-n -G"
equally
$ sudo nano /boot/cmdline.txt
remove
console=serial0,115200
and save
$ sudo nano /boot/config.txt
you must have at the end
enable_uart=1
Disable the console by
$ sudo systemctl stop serial-getty#ttyS0.service
$ sudo systemctl disable serial-getty#ttyS0.service
i have equally done $ sudo chmod 775 ../../dev/ttySO ( i dont know if it is really necessary )
and obviously a reboot
and miracle the gps works with
cgps -s
NB: you must have a fix on the GPS ( the red led flashes )
jpherrenknecht
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!
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