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.
Related
I am planning to develop a small project with a NRF52 (or other BLE chip if that'd matter). Preliminary, I would like to know, if I can broadcast data without "abusing" the advertising bytes?
Scenario: Two smartphones connect with my device and they enable some notify-characteristic over which i would like to receive data with a potentially high frequency (up to 100Hz maybe) on both devices. (I know 100Hz is already close to the minimum 7,5ms or so that ble supports... just to say i wanna reach that limit basically and be as fast as possible with receiving)
So: if I connect two central devices, will they receive the same notify signal or will I have to send one for each central device, essentially lowering the max frequency at which i can receive data?
In the latter case, is the best way to broadcast ble data to multiple devices via the advertising bytes?
Kind regards, have a good one
When you use GATT notifications over BLE, the notifications are individual per connection. So if you want to send the same notification to two connected clients, the data is duplicated over the air. In general, all GATT traffic is individual per connection.
If you send one packet per 10 ms to two devices, that should be fine. Note though if one packet is lost, it will be resent during the next connection event and hence then two packes will be sent to that device (assuming you produce an additional packet after 10 ms as usual).
You can use advertising instead to broadcast data. Every device that scans can see your data. Data you send in ADV_IND can be seen by an unlimited amount of scanners.
If it's better to use advertisements or GATT to send data to multiple devices depends on a lot of factors. You should experiment what works best for you.
Im trying to develop a ble application, where a peripheral device (a Ti CC2650LP) reads sensor data via UART and writes them to a characteristic. The central device (a Win 10 PC) reads this characteristic via notification and outputs it in a special software.
My problem is: when I use my test pc everything works fine, but when ich use a different pc with my software i always get the same readings. It seems i cant access the characteristic. Everytime i reconnect the peripheral as a bluetooth device, the reading changes, but the software still only shows this one reading. I can see in my software, that the characteristic gets read but the value doesnt change. I'm pretty sure its a connection issue.
Has anyone had this kind of issue before?
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.
I am developing a BLE android application where I have used RxAndroidBLe for BLE communication.
Everything working fine except one issue that the application is not receiving every scan response broadcasted by the BLE device (I am not sure whether it is an issue or not). The BLE device is set to broadcast it in every 1 second. It broadcasts the scan response on all the three channels 37,38,39 in round robin fashion. The application is intend to scan continuously until the application gets closed. But I observed that the application is not receiving all the scan response. Means it is not receiving scan response from the devices in every 1 second. Sometimes there is a gap of 2,3 seconds or more. I want to know is there any solution to overcome this issue or this is a valid behavior?
Any suggestion would be appreciated. Thanks in advance.
Due to nature of BLE scanning it is not certain that you will receive each scan response broadcast. At basic, it depend mostly on scan interval and scan window parameters (host side) and the interval you are broadcasting responses.
You can try low latency scan mode to improve your results.
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.