I am working on CC2541 BLE controller. I am using SimpleBLEPeripheral from TI BLE stack which is available on TI's website. I have interfaced the controller with a sensor whose state changes at an interval of 3 seconds. This means that event is generated at every 3 seconds. I am using custom profile's UUID whose length is 128 bits. I have also developed an app to get the sensor's data on my app. All is working good but device is getting disconnected with the app after establishing a connection.
I also tried changing the Connection Parameter in firmware but the issue is not resolved yet.
What should I try to make this connection flawless? I want that device should not get disconnected when it is in range and also if the device is out of range for sometime, it should auto reconnect with the app when it comes in the range of the mobile phone.
Related
I am trying to implement a Bluetooth Low Energy Host on a system with SAM E54 with FreeRTOS. The bluetooth stack I am using is Nimble (Mynewt-NimBLE from Apache). I am trying to connect the SAM E54 to a nRF52840 Dongle (driven with nRF Connect Desktop application).
When I set my device as Central (as a 4.x device, with no 5.x capabilities), the device can connect to another device without error.
But when I switch on the 5.x capabilities, (basically by changing a define's value and calling another API function), and try to connect to the same peripheral, it fails 9 out of 10 times, triggering a "connection supervisor timeout" on both the server and the client.
I tried changing the supervisor timeout value, but it won't fix the problems. When a connection is bound to be successful, the central's information is displayed immediately on nRF Connect. When connection establishment is going to fail, I know it right away (before the connection supervisor timeout is triggered) because no information about the central is displayed on nRF Connect.
Once the connection is established, it can stay on for hours, so I don't think this is an RF noise issue.
I know NimBLE is not initially designed for SAM E54 and FreeRTOS, and surely the problem comes from a wrong implementation or configuration of the stack. But right now I feel like I've tested everything, and I don't know where to dig for solutions.
The actual questions are :
To start a connection using 4.x BLE capabilities, some HCI commands packets are sent. Should these packets be any different than the packets sent when I enable the 5.x capabilities ? In both cases, I am connecting to a 4.x device.
What step of the connection establishment process fails when both server & client "think' they are connected, yet don't exchange information?
I have been using CSR1010 Module to trigger a test of the luminary. I Am getting connected to the BLE module using the Android App by the name BLE-Scanner.
Using this app I am able to get connected to the device for all the time possible. But when I trigger the test in the device, after sometime the application gets disconnected from the device .
Any solutions to keep the Bluetooth connection intact when test is executing for some standard time interval like 30 or 60 min?
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 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.
I'm trying to establish a bluetooth low energy link between a custom pcb and a mobile device. The application requires a tablet device and a BLE link that operates as fast as possible.
Since the BLE Speed is main defined by the allowed number of packages per connection interval and the minimal connection interval I'm trying to find a tablet with those capabilitys.
I have been searching a lot and just found the following information:
IOS device are stuck with a minimal connection interval of 30ms
Android devices are technically able to deliver 6 packets each 7.5ms, but usually it wont settle for anything below 20ms.
I find it very hard to get solid information on that topic. I found nothing about Windows Tablets and Tizen Tablets.
Does anyone have information about that topic?
You see, the standard Android bluetooth code is (with sometimes small adjustments by each manufacturers) the same on every device and the bluetooth controllers available on the market tend to only send 3-6 packets each connection event if the min/max connection event length is set to 0, which it is by default in Android's code.
Is it possible for you to work with AOSP, i.e. modify the Android source code? If so you could change the HCI call where a connection is created or connection parameters are updated. Change the min/max connection event length (Minimum_CE_Length and Maximum_CE_Length) to some large value and you will then be able to write many many packets in one connection event regardless of connection interval.
The relevant places in the code are https://android.googlesource.com/platform/system/bt/+/d35bb40dd563e7f37df0a2fa9c0f61d0958b9601/stack/l2cap/l2c_ble.c#945 and https://android.googlesource.com/platform/system/bt/+/488005b16bd2552ce7e5f9c1e1b3d4072397fc26/stack/btm/btm_ble_bgconn.cc#394.