I tried looking everywhere to understand how BLE pairing works but unable to find answers. Lets say I have a small device, like a raspberry pi with a BLE dongle. What I'd like to do is to allow BLE pairing and then subsequent communication with a BLE peripheral (such as a BLE temperature sensor) using software only.
My aim is to try and see if I can control the pairing and then getting the temperature, without touching the sensor at all, so that in future, I can just remotely log into the raspberry pi, turn on bluetooth, obtain the temperature reading and then afterwards turn it off again. And in future if I need to obtain the reading again, I'll repeat the process.
So:
Can this "simple" scenario be achieved using some software based control?
If not, then which parts require manual input and then which don't?
The BLE sensor should not be in advertisement mode or broadcasting the information. It should only send the data to paired devices.
Any and all answers appreciated! :-)
Most Bluetooth low energy devices do not require pairing at all so check first that your sensors do have this requirement. If they do then you need to determine which specific pairing procedure is required. Bluetooth defines various ways to authenticate during pairing and these generally relate to the I/O capabilities of the two devices and are called Association Models. In some cases, pairing "just works" (the name of the simplest association model) and no user interaction is required. In others, say if one device has a keyboard but the other has a display and no keyboard, the second device will display a random 6 digit number and the user must key that number into the first device. All of this is defined in the Bluetooth Core specification.
In your case the pairing procedure will be defined for your sesnors in the manufacturer documentation so check there first. Not that you should only have to do this once per device, not every time you want to read the sensor.
Accessing sensor data remotely needs a gateway which I guess is what your Pi will do. The Bluetooth SIG defined a set of RESTFul HTTP APIs for exactly this purpose. See https://www.bluetooth.com/develop-with-bluetooth/white-papers
The SIG also provides a gateway developer resource for Raspberry Pi which you can download including source code which is written in node.js. See https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools
Good luck
Related
I am working on a BLE interface to setup wifi on a device. I need to send a list of available networks back from the device. Should I have 10 characteristics (one for each available SSID) or just one characteristic which I send 10 notifies on.
What is the risk of using one option vs. the other? How reliable are the notifications of the values? I assume repeated notifications on one characteristic are likely as reliable as a single notification on multiple characteristics?
My recommendation is to use one characteristic for this purpose. It's not really about the risk as option 1 and option 2 should work fine, but it is more about the architecture of your code; i.e. If a new network is found, it is relatively easier and more logical to send data on one characteristic than associate the found SSID with a new characteristic. Moreover, you would have unutilized characteristics if you end up finding less than 10 SSIDs. Finally, if you wanted to expand the functionality of your device, you can than start using other characteristics for new features which will make things more modular for the remote device.
As both you and Emil have said, having a single characteristic firing notifications should not be an issue on any platform.
I bought one of these:
https://www.aliexpress.com/item/Smart-finder-Key-finder-Wireless-Bluetooth-Tracker-Anti-lost-alarm-Smart-Tag-Child-Bag-Pet-GPS/32806261079.html
As far as I can tell it is a BLE (Bluetooth Low Energy) location tag.
I downloaded the app for it onto my iphone, and the app instantly recognised it and connected to it. The iPhone app seems to know how far away the tag is - it has a little map of the local area and says how many feet away. I was able to set the device name via the app, but I'm not sure if that set it locally or on the tag itself. The iPhone app also has a "find" button - when you press it, the tag beeps.
So I want to know how I can program this thing myself. I want to be able to identify it when it is nearby, connect to it and make it beep. I've searched for quite a while but not come up with much.
I'm assuming (wrongly/rightly?) that there is some general standard or approach for talking to these BLE location devices and carrying out the basic functions with them - but what is that standard - where is the documentation?
Does anyone have any idea how to program these BLE location tag devices?
BLE devices typically communicate using GATT, either using standard GATT services, or custom ones. The command to make it beep is probably implemented using a custom GATT service.
For finding out the distance to the beacon, typically the RSSI is used. This is a measure of the received power. It needs to be compared to the output power at the emitter. Usually beacons will put their output power in advertisement data, so it can be used without connecting to them. Here since the app is also able to send commands to the beacon, chances are it keeps a connection to it and has a custom GATT protocol to retrieve the output power.
Here is what I would suggest:
Read up on BLE, especially advertising and GATT. For instance read this for advertising and this for GATT. The full BLE spec is available here but should be used for reference and not introduction
Sniff the communication between your device and your phone. You can see this other answer of mine to get started
Replicate the communication protocol in you own app. For that you'll need to use your target platform's BLE libraries. For instance for iOS it is CoreBluetooth
I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
To test bluetooth scalability, I want the same device (a Raspberry Pi or a laptop) to emit several BLE advertisements. So far, I have tried using bleno (NodeJS), hcitool and CoreBluetooth for OSX, but I can not setup more than one.
Is this a hardware/system/bluetooth limitation? Has somebody managed to do this?
Different bluetooth devices have different maximum advertising rates. These typically range from 10Hz to 40Hz. Some bluetooth devices have the ability to spoof their MAC address so different advertisements appear to come from different physical devices. This is often important for scalability testing, because some receivers keep track of unique devices by MAC address.
As #Emil says in his answer, it is possible to "interleave" advertisements such that you change the advertisement (and ideally the MAC address) every few hundred milliseconds so it appears by receiving devices that there are multiple advertisers around. I have done this with both Raspberry Pi and iOS transmitters, but in neither case could I alter the MAC address.
It is important to understand, though, that the actual number of packets received when you do this does not change. So while you may be testing scalability of unique advertisements detected, you will not be doing the same thing as testing with multiple physical advertisers.
That's not possible by the Bluetooth specification. However you can start off with one data then set a timer in your app that stops advertising. Then you start off again with the next data. And so on.
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.