CurieBle gatt client api

Hey guys,

Has anyone had any luck expanding the CurieBle libraries to include gatt client capabilities?

Digging through the libraries, it looks like the api exists (in the ble_service_gattc_api.h header), but none of the functions are implemented.

Basically, I'm looking to discover and subscribe to services on the central device (iPhone) so that I can subscribe to ANCS notifications (ANCS is Apple's notification services).

I've been attempting to implement the functionality myself, but I've been unable to successfully receive the appropriate response message as defined in the ble_service_gatt.h file.

Thanks for the help!

Edit: I decided to provide the api with a specific service uuid instead of using NULL to search for all service handles and I'm able to get a response message. However it always contains an event timeout error. I saw in another post that the sandeepmistry BLE Peripheral libraries located here: GitHub - sandeepmistry/arduino-BLEPeripheral: An Arduino library for creating custom BLE peripherals with Nordic Semiconductor's nRF8001 or nR51822. are "99% compatible" with the 101, but attempting to build any of the examples results in an error that the hardware is not supported. Has anyone had any luck with these?

So I took another look and this and realized I'm actually getting a BLE_STATUS_NOT_SUPPORTED error code. Does this mean that the current Curie core does not support discovering primary services, or that something in my configuration is wrong, making this feature not supported?

If the Curie core currently doesn't support this feature, does anyone know if the next version will? I've seen on other posts that the new core version should be coming soon.

hi, I have been researching the same thing. Have you had any luck?

Same here, I'm interested.

chartle02: can you share your code? (A fork on github?)

I assume you implemented ble_service_gattc_api.c as well as the Arduino layers on top of it.

Does the BT standard define what the code should do (are the messages standard BT messages to the device at the HCI layer?) Is that error code defined by the BT standard?

Note that the new core 1.0.6 WAS released since your original post and doesn't seem to include the missing functionality or .c file.

Would a Curie SDK from Intel better document what is doable and needs to be done to interface to Arduino?

the way I interpret it is that there are no functions implemented for a GATT-client, however Intel has released the OS and firmware so that we can compile our own versions. So if you can't wait for a new release you can make your own. My idea is to look at the ANCS-template that Nordic Semiconductor has provided in their ble-sdk-arduino. There are also libraries like this GitHub - NordicPlayground/nrf51-ble-ancs-nus: Combination of ANCS and NUS service with iOS app that can be useful.


Intel has open sourced the RTOS they are using in the Curie. It is Zephyr.

Intel has NOT released a Curie SDK. It is due Summer 2016. I think you could expect the SDK to include all the pieces to program the Curie at the bare metal level (accessing peripheral registers), or at a higher level i.e. using the RTOS and any Bluetooth software stack components dealing with the Bluetooth device.

The Bluetooth stack (running on the x86 processor) communicates with Arduino (running on the ARC processor) via a UART serial link (or via the RTOS?) You can see the source code for that communication in the file ble_service_gatts_api.c (where gatts means server or peripheral.) The header file ble_service_gattc_api.h exists, but not the source code ble_service_gattc_api.c. Which means they have defined the API for a client, but not provided the implementation. One would also need the Arduino layer, the classes for things like Central.

(I think the Central class that exists already should really be called RemoteCentral. That is, it is a proxy for the Bluetooth device (in the Central role) on the other end of a connection? It doesn't support the NEAR end taking the role of Central.)

I am actually more interested in the Broadcaster and Observer roles, i.e. without a connection, without security, and without GATT and defined services.

Currently I am studying what the L2CAP API does, and whether that is exposed now, in the released Arduino Core.

I could be wrong. For now, such a project to use an Arduino101 as a Client (or Broadcaster/Observer) seems to have the nature of reverse engineering since there is so little documentation of the innards.

This thread is about the fact that the Arduino101 Bluetooth stack only supports a Peripheral, i.e. a device providing a Service, or a Server.

Links to read about more complete and open Bluetooth software stacks for embedded systems: (not exhaustive.)

Wiki entry for Bluetooth stack

Wiki entry for Java APIs for Bluetooth The API is object oriented and seems well documented.

Wiki entry List of Bluetooth Protocols

Oracle page for Java Bluetooth APIs. Oracle owns the remnants of Sun Microsystems which invented Java.

BlueZ the official Linux Bluetooth Protocol Stack Even if you're not using Linux, this might be instructive.

Arduino Primo and Primo Core Arduino boards with an SoC integrating a Bluetooth controller with an mcu.

Wiki page for Apache Mynewt a fledgling project: an open source RTOS and Bluetooth stack. It says they support the Arduino101 and the Arduino Primo.

mynewt project page

Many chip vendors supplying SoC Bluetooth chips supply Bluetooth stacks. They may be open, but might not be free as in liberty. Intel, Texas Instruments, Nordic Semiconductor, Microchip (now owns Atmel) etc. The vendors usually sell cheap development boards.

CSR now owned by Qualcomm.

Many chips are multi-protocol: supporting other network standards such as Zigbee.

Don't limit yourself. The software might be the hardest part.

Hey Guys,

I think it may be time to revive this topic. I gave up trying to get this to work over a year ago once I realized that the BLE_STATUS_NOT_SUPPORTED error indicated that the Bluetooth stack itself did not support this. However, with the new 2.0.2 core release, it looks like it now does.

I wrote a quick program last night to test out the setServiceSolicitationUuid() function with Apple’s ANCS service Uuid as specified here

Using that Uuid, I was able to see my device in Apple’s bluetooth menu, and I could connect. On the Arduino side, I got a connection to a central device.

Based on searching online, it looks like I now have to subscribe to the specific apple notification services, but the connection to my iPhone is with the iPhone being the client, not a peripheral, so calling peripheral functions like hasAdvertisedServiceUuid() or hasService() return false.

I have also tried connecting to the iPhone and then switching to scan mode to see if I can now discover a device with the same MAC as the client I just connected to. No luck there either.

Anyway, here’s the brief code snipped I wrote. The while(true) loop is where I’ve been trying various things to see if I can find the services.

#include <CurieBLE.h>

void setup() {

  //set solicited service UUID
  BLE.setLocalName("ARDUINO 101");

  // initialize the BLE hardware

  Serial.println("BLE ANCS Test Project");

  // start scanning for peripherals

void loop() {
  // listen for BLE peripherals to connect:
  BLEDevice central = BLE.central();

  // if a central is connected to peripheral:
  if (central) {
    Serial.print("Connected to central: ");

    bool a,b;
      //do random stuff in here to see if I can find the ANCS services
      a = central.hasAdvertisedServiceUuid();
      b = central.hasService("7905F431-B5CE-4E99-A40F-4B1E122D00D0");
      if(a || b) Serial.println("got something");

I haven’t had much time to look into this yet, but I was hoping I may be able to get it up and running without having to dig into the internals of the BLE library :confused:

At least is seems that the functionality is there to get this working.

Hi @chartle02,

Nice work!

Unfortunately, I don't think you'll be able to get ANCS working for now, as the CurieBLE library is missing support for pairing/bonding which is required for ANCS.

If there's enough demanding for pairing/bonding, the Intel team could add this to the roadmap.

There's an issue on Github to track this: IOS ANCS: How to add solicitedServiceUUID? · Issue #341 · arduino/ArduinoCore-arc32 · GitHub - it has been closed, but feel free to comment.

Thanks for the quick response. I probably would've wasted much time figuring out that it's not supported yet :slight_smile: