I'm using Android Things 1.0.4 in a prototype where it acts as BLE peripheral device: advertising services and running a GATT server.
I encounter an issue in the BLE pairing process when trying to bond the Android Things board (Raspberry Pi 3) and a smartphone.
Since the device has no display, I set using BluetoothConfigManager:
IoCapability = BluetoothConfigManager.IO_CAPABILITY_NONE
which results in the error AUTH_FAILED every time.
Instead,
IoCapability = BluetoothConfigManager.IO_CAPABILITY_OUT
logs the pairing key and prompts the smartphone to enter it during pairing, but it results in the REMOVED error.
Questions:
Is Android Things in peripheral role capable of handling BLE pairing or not yet?
Are there more things that need to be implemented in the app's code to replicate the full-fledged Android logic?
Here's the source code of the Android Things app to test BLE pairing and bonding
The same code stripped from Android Things specific elements completes BLE pairing and bonding successfully when running on an Android phone as Peripheral (server), and an Android device or iPhone as Central (client).
Generally speaking, if you attempt to read an encrypted GATT characteristic before pairing (which triggers the pairing logic automatically), this results in GATT error 137 returned from the read request (AUTH_FAIL). This is because the device doesn't have enough time to finish setting up the bond before a response is sent by the Bluetooth stack. Retying the read request again generally succeeds.
I have not tested this with an iOS client device, but it certainly holds true with an Android client connecting to an Android (Things) peripheral. As such, I would recommend a few things:
Have the client (mobile) device explicitly initiate pairing, and Android Things should simply react to these incoming requests in the BluetoothPairingCallback. This lets the mobile device decide the pairing type based on the reported capabilities of the IoT device.
Separate the pairing flow from the GATT flow. Pair to the discovered device separately from making any attempts to read the characteristics. This tends to be the best way to avoid timing problems.
Regarding capability choices, this depends on your device. In my experience, if you choose IO_CAPABILITY_NONE this results in PAIRING_VARIANT_CONSENT inside of onPairingInitiated() and the pairing operation succeeds once finishPairing() is called. If you adjust your capabilities, you should be prepared for any number of the variants requiring you to display a PIN for the mobile device to enter. I have not not personally tested these paths.
Related
I have to write a BLE application on an embedded device and there are some features where I'm not sure if BLE supports that or whether I've to create some wrapper around everything or if it's maybe not possible at all. The gerenal descriptions of Bluetooth and BLE I found around the internet usually only cover the overall functionality but don't go in too much detail. If this post gets too complex I'll split it up into different smaller ones.
I use the STM32 BlueNRG-MS chip
1. Discoverability (resolved)
The user has to be able to disable the BLE function in case there are several devices in reach. I see that there are functions aci_gap_set_discoverable() or aci_gap_set_non_discoverable() but altough I set it to not discoverable I can still see it in the LightBlue App on my mobile. How would I correctly disable the BLE functionality of a device to make sure no one can see it or connect to it?
Update: Okay that has been a mistake from my end, if I call the aci_gap_set_non_discoverable() function it is actually undiscoverable. So that's fine.
2. Only accept connections of paired devices
I'd like to achieve a behavior such that, if you have an unpaired phone you have to set the BLE device into a pairing mode in order to connect. If the phone has already been paired, the BLE device shall accept the connection request regardless of whether it's currently in pairing mode or not. Is this what the whitelist should be there for or do I have to do this manually by saving the address of the device after successful pairing? If whitelist is the right approach, I read that newer phones cause issues with whitelisting because they change their address on a regular basis, how can I handle this? That's actually where I thought I'm gonna work with the "discoverability".
3. Automatically reconnect
I'm not sure if this topic has to be handled on the BLE device or on the mobile phone. E.g. my phone is paired with my car's radio, so whenever the phone is in the car it automatically connects - how is this done? It's still the phone that acts as central device I assume?
After days of research and trial and error my colleagues and I have to hope that the StackOverflow community has a working solution.
We got an Android Smartwatch. We developed an app which acts as the BLE central. The App shows a QR-Code encoding an UUID which is unique for every Smartwatch. While showing that QR code it's actively scanning for a device advertising a service with that UUID.
We also developed an iOS app which can scan that QR code and start advertising with the service UUID it received. The Android Smartwatch then connects very quickly to the iOS device.
One purpose of the Smartwatch is to show push notifications from the iOS device. So when the connection is successfully established, the Smartwatch-App subscribes to the ANCS Data Source and Notification Source characteristics. This initiates "Just Works" pairing, so you just have to click on "Pair" on the iOS device. Afterwards you have to allow that iOS notifications are shared to the Smartwatch and then the Smartwatch successfully receives notifications.
ANCS is also the reason why the iOS device MUST BE in the peripheral role.
Until here everything works fine.
When the user leaves the bluetooth range or dis- and enables bluetooth on the iOS device, an automatic reconnect should be triggered. It DOES reconnect when the iOS app is in foreground. Unfortunately it DOES NOT work when the iOS-App is in background. This is probably related to the fact, that the iOS device is not advertising with the required UUID when the app is in background as described in the CoreBluetooth documentation:
All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
We tried many different ways to reconnect from the Android Smartwatch to iOS. From my understanding it should be working when making the first connectGatt with autoConnect=false and when the connection is lost, calling connectGatt on the lost device with autoConnect=true, but it never reconnects. At least not within 15 minutes. Scanning again also wouldn't work, as the UUID is not advertised in background anymore.
We also tried to additionally let the Android device act as peripheral, so the iOS can connect to it. After connecting we wrote data to an "INITIATE_ANCS"-characteristic and let the Android device call connectGatt on the device which was passed to onCharacteristicWrite. This led to interesting behavior:
- The connection was working, we could read a Smartwatch-Characteristic from iOS.
- When subscribing to the ANCS characteristics, it initiated pairing. But instead of "Just Works" pairing it showed a 6-digit code on the iOS device which we had to type onto the Smartwatch.
- The pairing was inititated on every new connect and it always created a new device in the systems device managers on both Android and iOS.
- The pairing WAS NOT inititated when the iOS app was in background.
We really did a thorough research and couldn't find a solution. Did we understand something wrong on how BLE for iOS and Android works? We really hope to find an expert here that has the knowledge what has to be done to make the reconnect work.
Edit:
The Android device is running on Android 5.1.1 and currently it's no option to update.
The iOS testing device is running iOS 13.3 and it should be compatible with iOS 13+
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 working on Android BLE as a peripheral connected to a custom device that runs Nordic NRF51 as a central. The project requires Android peripheral to connect to two NRF51 central devices.
Android is advertising two different Advertisement UUIDs one for left and other for right Nordic NRF51 devices. Ideally, I would like to have both Nordic Centrals to connect to the Android at the same time.
I have two main issues.
First issue. Android can get both connections fine. The problem occurs when Android sending notification or Android sending reply back as result of Write Request from the central. When both Centrals are connected, often notification nor the send reply works. I confirmed that the Nordic central does not receive the notification nor the reply. Does anyone have experiences in Android as a Peripheral supporting multiple connections at the same time? I have tried two BluetoothGattServer instances (one for each device) as well as one instance of BluetoothGattServer and based on the connected device, I can tell which Central the event if for and handle it correctly. It is sending notification or send reply to Write Request that at times it does not get sent from Android. I am using synchronized methods on the GattServerCallback event handlers.
Second Issue. Due to the first issue, I am now only advertising one UUID at a time. The idea is to switch between two advertising UUIDs, thus have only one connection at time. The problem now is switch advertising. About 1 out 3 times, when I start advertising with first UUID with its name (LFDroid), it appears that it is actually advertising second UUID with its name (RTDroid) briefly (1 or 2 seonds) and then advertises what was requested. Note that second UUID advertising was stopped on previous switching. It almost looks like when I ask to advertise, it starts to advertise with the last advertised UUID and name and then quickly advertises what is requested. This now causes problem because both Nordic Centrals sees the advertisement and connects.
Any suggestions would be appreciated.
How do I implement notification in BLE?
I have a smartphone, and every hour it will send notification to all nearby BLE devices (smartwatch, RFduino, etc) for time synchronization purpose.
Other devices are server now (since it provides data), and smartphone is the client that collect the data.
Could I piggyback into the advertisement packages? For example, the smartphone always broadcast an advertisement packet to annoucement its presence (that's how other devices can find it). Can I modify that packet to be a time sync?
In order to send notifications or advertisements, your smartphone has to act as a server, which also means that in order to be able to receive notifications or scan for advertisements, your peripheral devices must act as clients.
This can be a bit tricky, because if two devices act as client and server, they may not simultaneously fulfil the other role. You need to switch roles whenever needed, which is an open field for all kinds of problems.
Also, I am not convinced that it is really the optimal choice to let the smartphone regularly notify all devices in the vicinity. Each of the devices that wants to receive the notification has to be connected with the device in order to receive the notification, and this connection has to be already active when the notification is sent in order to really get the correct time. So all these devices need to connect in advance to the expected notification time, and hold up the connection until the notification has come.
It might be better to just advertise the current time, but remember that you can't connect to the smartphone as a server while it is advertising, because the link layer may not be in scanning and advertising mode at the same time, and you may also not be connected when advertising for a similar reason.
If you want to do it that way, you can include the time information in the advertising data. See the Supplement to the Bluetooth Core Specification v6, Part A for further information on the structure of the advertising data. You could put it in the manufacturer specific data.
However, another option would be to write the time directly to the device using a write request. You can define your own service and characteristics. You can include a "time synch necessary" information in the advertisement data of the servers, and when the smartphone evaluates the advertisement, it can connect to the corresponding device and send the time directly.
The advantage of this procedure is that time is only updated if you really need it on the device, and that you do not have to switch client/server roles, because the device in server role may advertise as normal, and the smartphone can always stay in client role.