I can run an App called "Bluetooth File Transfer" and it can allow one Pi to be connected to the Android device at one time. I'm looking for a way that can connect 4 or 5 Pi's simultaneously.
----------------------------------------------------------------------------------------------------
I am wondering if there is a simple method to maintain the Bluetooth data / file transfer "port / gateway" open continuously so the RSSI value can be obtained between a Raspberry Pi and an Android device.
A bit of a background...
I have a team project taking place for my Engineering study, and we are attempting to create a triangulation / tracking system with the use of multiple Raspberry Pi's through the RSSI values of a user device (i.e. smartphone, laptop, tablet). We've decided to use WiFi and/or Bluetooth, but after extensive testing, we believe Bluetooth is the more suitable technology - as the power requirement is much lower compared to WiFi, and our system is being designed to function in a household environment.
Example, we have a RPi located on each of the four corners of a home, constantly obtaining the RSSI of one user device. The four values are then compared to a table of pre-set values to determine where the individual is, within the perimeter of the home.
Say...the RSSI values are -7, -15, -20, -30. According to the table, the person is in the kitchen.
0, -10, - 25, -25. The person is in the bedroom.
We are using the latest version of Debian Wheezy available as of now, and the wireless USB Bluetooth dongle that we are using is the IOGear GBU521 Bluetooth 4.0 (Broadcom BCM20702A0).
Our testing shows pairing the RPi with Apple devices, and continuously obtaining the RSSI value until the device is out of range (or disconnect) is very successful.
How we did it:
1) install bluetooth package
Code: Select all
sudo apt-get install --no-install-recommends bluetooth3) Obtain BT MAC address
Code: Select all
hcitool scanCode: Select all
sudo rfcomm connect 0 [MAC Address] 10>/dev/null &a) continuously obtain RSSI value via
Code: Select all
hcitool rssi [MAC Address]Code: Select all
watch -n 0.25 hcitool rssi [MAC Address]Code: Select all
#!/bin/bash
echo "testing rssi /n"> logs1
while (true)
do
hcitool rssi [MAC Address]>> logs1
date +%S
date +%S>> logs1
sleep 0.25
done
After a bit more research, we tried another approach by using Bluez and blueman.
Installed Bluez and blueman...and any other useful packages...and connect
Code: Select all
sudo apt-get install bluetooth bluez-utils blueman
sudo apt-get install bluetooth bluez-utils bluez-compat
sudo bluez-simple-agent hci0 [MAC Address]
sudo bluez-test-device list
sudo bluez-test-device trusted [MAC Address] yes
sudo bluez-test-device trusted [MAC Address] (to ensure the device is trusted)
sudo bluez-test-input connect [MAC Address]
Code: Select all
iface bnep0 inet dhcpCode: Select all
sudo bluez-test-input connect 00:00:00:00:0B:9DA fellow student of ours suggested that the RPi and the Android device are actually paired (as it indicates this on the Android device), but the "port / gate" between the two are not "open" until there is data being transferred between the two. So, we bit the bullet and tried to see if that was the cause of the issue. Sure enough, we sent a file from the Android to RPi via bluetooth, and we were able to get the RSSI value while the file was being transferred by usingTraceback (most recent call last):
File " /usr/bin/bluez-test-input", line 40, in <module>
input.Connect()
File " /usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70 in _call_
return self._proxy_method(*args, **keyworsds)
File " usr/lib/python2.7/dist-package/dbus/proxies.py" , line 145, in _call_
**keywords)
File " usr/lib/python2.7/dist-package/dbus/connection.py" , line 651, in call_
blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method
"Connect" with signature " " on interface "org.bluez.Input" doesn't exist
Code: Select all
hcitool rssi [MAC Address]We've discovered that either the RPi or the Android device can be the initiator for the file transfer. Furthermore, RSSI can be obtained via "hcitool rssi" even if the Android device DOES NOT accept the file transfer. To elaborate, it can be sitting there, waiting for the Android device to Accept the transfer and the RSSI can still be obtained. Once the response request times-out, the "port" is again closed.
So the question:
What is a simple (doesn't necessary need to be efficient) way to keep the port open so the RSSI value can be retrieved continuously until the Android device is out or range (or until disconnected)?
Is there a way to continuously ping the Android device or send a small data file (i.e a few bytes or KB) so the "port" is kept open?
** Apple products don't run into the above problem (for some reason) as it seems that the "port" is always open - even if there is no data transfer. This is odd as we assumed Apple devices have more security procedures (less open) than Android devices.
. And as long as I can consider, I think they appear when they are moved in a peiod of time. For example if you dont move any BLE device, they only appear one time, if they are continiously in movement they apper in a period of 10 15 sseconds I dont know.