[SOLVED] ble.sendData question


Hi!, i’m connecting a red bear duo to a bluzdk, and i have a doubt. 'im sorry if it makes nonsense. when the command BLE.senData is called from bluzdk, as i undertand, data is written on the characteristic 871e0224-… from custom service … is that correct?. in that case, in order for the red bear duo, acting as Central device, to receive that data, it must perform a read on that characteristic of the BluzDK … is this correct? thanks, and sorry again.


When the RedBear Duo connects, it should enable notifications on the characteristic. You can see how we do this in our gateway code here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/platform/MCU/NRF51/SPARK_Firmware_Driver/src/client_handling.c#L118

I am not familiar with the RedBear SDK, so you would have to find the analog to this function. Once you enable notifications, the central device should get updated when the connected bluz DK sends data.


Hi @eric, as i undestood, my assumptions are right, aren’t they? … so if i could enable notifications from custom characteristic 871e0224-… by writing accordingly its CCCD, each time bluzdk send data, it will send a notification to the central device? which will be the notification value? … additionally, i’m trying to write that CCCD descriptor from red bear duo, but, y now, without success … do i have to take into account any consideration about the value to write? (i mean, any specific format/header to perform this operation)? thanks


Yes, it sounds like you are doing the right thing. You can look to our code as to what we do, but ultimately you should follow the RedBear documentation. We don’t do anything special, so you don’t need to worry about the format of the data. You just need to enable notifications on that characteristic and it should work.

I have not worked with the Duo much, so I can’t provide a lot of details. However, I know there are a few other people here who have, so maybe someone else has some more insight?


Hi @eric,
I’ve been trying to detect the problem i found enabling the notifications on a BluzDK device from a Red Bear Duo as Central role … in this sense, I’ve seen that when the services/characteristics/descriptors from BluzDK are discovered, the following information is reported by Red Bear Duo:

* Service found successfully
   - Service start handle: 1
   - Service end handle: 7
   - Service uuid16: 1800
   - Service uuid128 : 0 0 18 0 0 0 10 0 80 0 0 80 5F 9B 34 FB

* Service found successfully
   - Service start handle: 8
   - Service end handle: 8
   - Service uuid16: 1801
   - Service uuid128 : 0 0 18 1 0 0 10 0 80 0 0 80 5F 9B 34 FB

* Service found successfully
   - Service start handle: 9
   - Service end handle: FFFF
   - Service uuid16: 0
   - Service uuid128 : 87 1E 2 23 38 FF 77 B1 ED 41 9F B3 AA 14 2D B2
   - User defined Service uuid128 found successfully

* Discover all services completed

* Characteristic found successfully 0 :
   - Characteristic start handle: A
   - Characteristic end handle: C
   - Characteristic value handle: B
   - Characteristic properties: 12
   - Characteristic uuid16: 0
   - Characteristic uuid128 : 87 1E 2 24 38 FF 77 B1 ED 41 9F B3 AA 14 2D B2

* Characteristic found successfully 1 :
   - Characteristic start handle: D
   - Characteristic end handle: FFFF
   - Characteristic value handle: E
   - Characteristic properties: E
   - Characteristic uuid16: 0
   - Characteristic uuid128 : 87 1E 2 25 38 FF 77 B1 ED 41 9F B3 AA 14 2D B2

* Discover all characteristics completed

* Descriptor found successfully 0 - Characteristic 0 :
   - Descriptor handle: C
   - Descriptor uuid16: 2902
   - Descriptor uuid128 : 0 0 29 2 0 0 10 0 80 0 0 80 5F 9B 34 FB

* Discover all descriptors from characteristic 0 completed

* Discover all descriptors from characteristic 1 completed

However, when I try to read the descriptor value with handle 0x0C from Characteristic 0, which as I understand, it is the only descriptor from this characteristics, and it corresponds to CCCD, I found that, apparently, BluzDK/Duo gets stuck … but:

  1. when I read the descriptor value with handle 0x0A from Red Bear Duo, I obtain the following report:

    • Read descriptor value successfully:
      • Connection handle: 40
      • Descriptor value attribute handle: A
      • Descriptor value : 12 B 0 B2 2D 14 AA B3 9F 41 ED B1 77 FF 38 24 2 1E 87
  2. when I read the descriptor value with handle 0x0B from Red Bear Duo, I obtain the following report:

    • Read descriptor value successfully:
      • Connection handle: 40
      • Descriptor value attribute handle: B
      • Descriptor value : 20
  3. when I read the descriptor value with handle 0x0D from Red Bear Duo, I obtain the following report:

    • Read descriptor value successfully:
      • Connection handle: 40
      • Descriptor value attribute handle: D
      • Descriptor value : E E 0 B2 2D 14 AA B3 9F 41 ED B1 77 FF 38 25 2 1E 87

… Does this information makes any sense from you in order to detect which could be the problem when I try to read/write the CCCD value (as I understand, with Descriptor handle 0x0C) on BluzDK from Red Bear Duo?. Thanks. I need to solve this issue asap.


Hi @eric? … any clue from my last question? … after some tests, i realized that when i try to read the CCCD value (descriptor handle 0x0C), i obtain an error from BluzDK related to the status GATT_CLIENT_IN_WRONG_STATE … however, as i reported you, when reading other values from my Red Bear Duo with different descriptors, it works ok. any help will be appreciated. thanks


Sorry for the delay. I was hoping to get my Duo out and try a few things before I replied, I will get back to you soon.


… i really appreciate your help @eric . hope to hear from you soon
best regards


Hi @eric … in the meantime while waiting for the Duo to arrive :wink: , just a basic question regarding ble.sendData() … suppose in the following code, the rsp[] array that i need to send as response is bigger than 19 bytes (taking into account that Bluz will add the 0x04 header) … i assume that if the length value in ble.sendData() command is bigger than 19 bytes, it will truncate the array values … so, could you please tell me how to modify the code in order to optimally send that array into, for example, two 20-byte chunks the fastest way?. Thanks again

#include "application.h"

bool sendData = false;

void dataCallbackHandler(uint8_t *data, uint16_t length) {
    sendData = true;

void setup() {

void loop() {
    if (sendData)
        uint8_t rsp[2] = {'H', 'i'};
        BLE.sendData(rsp, 2);
        sendData = false;


The ble.sendData will take an array of any (practical) size, it breaks up the data into the 20-byte chunks for you. So you really don’t need to worry about that, it will take your data, split it up and send it, and then it gets reconstructed on the other side.


Hi @eric, yes, you’re right, and it works great! … i checked sending a 30-byte sav_data[] array with decreasing values from 0x1D to 0x00 with BLE.sendData(sav_data, 30); and thats what i receive. thanks


Sorry for the delays on the RedBear questions. I went through some of their doc as I hadn’t checked it before, and I came across your thread in their forums: http://discuss.redbear.cc/t/data-transfer-between-red-bear-duo-and-bluzdk/1355/19

It seems the RedBear team is able to help. I am not terribly familiar with the Duo, so they may be able to help better than I can. From looking through the code you had posted, I don’t see anything glaringly wrong, you are definitely on the correct track. It looks like the RedBear team may post back, so perhaps it is best to wait on them at this point


Hi @eric … does bluzdk supports reading its cccd value from a central device? It seems that the problem can be related to that issue. Could you please check if it is possible? Thanks a lot


What you want to do is write to the CCCD to enable notifications.

Is there a specific question or problem the RedBear team has identified? Enabling notifications should be very straight forward as we have done this now with iOS, Android, the Nordic SDK and Linux. It should be pretty straight forward to do from the Duo.


Hi @eric, you are right, but actual duo’s firmware first read the current CCCD in order to determine its actual value before writing it in case it is necessary … not received any conculsive answer by now :wink: … i’ve also successfully enabled notifications from Android, but from Duo it seems that BLuzDK doesn’t answer the ATT Request for reading CCCD value (as i reported you, maybe there is a problem with this in BluzDK, since by my side i could successfully read any descriptor value, excepting CCCD), and as a consequence, the CCCD writing fails … that’s why i asked you about any possilbe problem/restriction for reading CCCD value on BLuzDK …

  1. could you please check if it is possible to read the actual CCCD value from BLuzDK? …
  2. in addition, could there be any incompatibility between BTstack and BLuzDK on this?.
    … any help will be appreciated. thanks

FYI: here’s an excerpt from the last comment from RedBear team abot this issue: “… In the log with BTstack, it looks like it is not answering an ATT Request. The next question now would be if it got that request, and if yes, if it answered + again, if that answer reaches BTstack (the log indicates it didn’t get a response).”


I am trying to find an answer for you. I can’t imagine there would be an incompatibility since they are both based on the Bluetooth spec, but I will try and find out.


Hi @eric, i’ve used BLEScanner app (android) in order to read the CCCD value, both from a BluzDK device and an HM-10 device as Peripheral. The results i obtained are shown in the following figures:

a) when connecting to BluzDK, and trying to read de CCCD value by pressing the signaled R button, no info is aparently read, and no additional info is shown.

b) when connecting to HM10, and following the same procedure in order to read the CCCD value, it appears to be successfully read and the “Notifications or indcations disabled” info is shown.

… so it reinforces the fact that maybe BluzDK doesn’t support the CCCD value to be read … could you please verify it following this procedure, or any other you consider, in order to conclude if it is possible or not, and make it possible? thanks

Edit: I’ve sucessfully written the CCCD value from a Red Bear Duo acting as Central to a HM10 device acting as Peripheral, so the problem seems to be on the BluzDK device.


I’ve discovered the source of the issue. It is checked in and will be part of the GA release that happens (hopefully) this week


Yuppiieeeee! … sorry. thanks a lot! … it is possible to get some additional info about the problem found?. i’ll be expecting that release.


No need to be sorry, glad we can fix more issues along the way!

The issue had to do with reading the CCCD value that wasn’t set yet, it is very Nordic stack specific. Basically, the CCCD value wasn’t set when the connection is opened (since the central didn’t write to it yet) and when you tried to read it, a specific error case was raised in the Nordic stack. The bluz firmware had the code to handle the case, but for some stupid reason it was erroneously commented out. So it was simply a matter of uncommenting the code to properly handle the case.

You can see more details about it here if you would like: https://devzone.nordicsemi.com/question/20908/disconnecting-on-generic-attribute-primaryservice0x1801-discovery/

Actually, if you could test this before we release, I would really appreciate it. I already made the release, you can see it here: https://github.com/bluzDK/bluzDK-firmware/releases/tag/v2.1.50

So all you need to do is download the system-part1.bin file and flash it to bluz using the Particle CLI like this:

particle flash {device name or ID} {path to file}/system-part1.bin

That will send down the release version with the fix to your device. You should do this when connected through the iOS or Android app as it is a system update and will be much faster with the app.

I am planning to release the GA tomorrow, if all goes according to plan, so let me know if you can test and if it fixes the issue, I believe this will. Thanks