How to create custom service and characteristics

Hi,

I've read the various tutorials and examples about how this should work, but I just don't seem to be able to get it right.

If I use the nrF Connect app on my iPad, connect to the Puck it shows the expected UART service with TX/RX.

If I connect via TinyB, BLE command line I see two services listed:
1) The expected one for UART: 6e400001-b5a3-f393-e0a9-e50e24dcca9e
2) Another one: 00001801-0000-1000-8000-00805f9b34fb (what is this one?)

If I try to add my own service and specify UART:false on the options then the iPad won't connect to the puck at all and the code version still either sees 1 or both of the previously mentioned service uuids.

I'm trying to use the sample code like this:

RF.setServices({
  "0000bcde-0000-0000-0000-000000000000" : {
    "0000abcd-0000-0000-0000-000000000000" : {
      value : "Hello", // optional
      maxLen : 5, // optional (otherwise is length of initial value)
      broadcast : false, // optional, default is false
      readable : true,   // optional, default is false
      writable : true,   // optional, default is false
      notify : true,   // optional, default is false
      indicate : true,   // optional, default is false
      description: "My Characteristic",  // optional, default is null
      onWrite : function(evt) { // optional
        console.log("Got ", evt.data);
      }
    }
    // more characteristics allowed
  }
  // more services allowed
},{advertise:['0000bcde-0000-0000-0000-000000000000'], uart:false});

I would expect to only see the one service listed and connection from iPad should work too.
Also are then any more details about what the various attributes mean ie:

  broadcast : false, // optional, default is false
  notify : true,   // optional, default is false
  indicate : true,   // optional, default is false
  description: "My Characteristic",  // optional, default is null

I also don't see any way to retrieve the description detail via TinyB,
http://iotdk.intel.com/docs/master/tinyb/classtinyb_1_1BluetoothGattCharacteristic.html

Quite often I also find that the Puck vanishes or won't connect and I constantly need to either reset it AND or run /etc/init.d/bluetooth restart to keep things running. I've ensured all the libraries are up to date.

Another note is that in the console of the WebIDE I get the message:

BLE Connected, queueing BLE restart for later

If I try to put the setService in a timer then that message is written out every time it fires.

As an example of the output I get from the tinyB / C++ code.. It also seems as if the Puck appears as 2 devices with an almost identical UUID:

Bluetooth manager started...

Device discovery..

Discovered devices: 
Class = BluetoothDevice Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CF Name = DfuTarg Connected = 0 

Class = BluetoothDevice Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE Name = Puck.js b3ce Connected = 0 

Connecting to device..0xcf0b70

Fetch services..

Class = BluetoothGattService Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b UUID = 6e400001-b5a3-f393-e0a9-e50e24dcca9e Device = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE 

Class = BluetoothGattService Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000a UUID = 00001801-0000-1000-8000-00805f9b34fb Device = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE 

DfuTarg Will be use daily for flashing new firmware.

Name = Puck.js Is the one you want to use.

Thanks, that makes sense. I will just include a filter then on devices like Puck.js*
Now to sort out the service issue. The end objective here is that I need the Raspberry PI to be talking to at least 3 or 4 Puck.JS tags (approximately simultaneously), I say approximately in that they could be probed sequentially as long as there isn't a significant delay. For example 4xPuck.JS with sensors which need to be aggregated at 20-30hz OR when the sensor values changes if it can be a push rather than polling.

Is the issue just that you're still connected to the Puck with one device? It can only accept one connection at a time so won't even advertise while it's connected. If you want to debug things you can always wire up a serial connection (details on the Puck.js page).

I think 00001801-0000-1000-8000-00805f9b34fb (which is actually just a 16 bit UUID 1801) is a standard Bluetooth way of flagging up when the services advertised by a device have changed.

Other things that might help:

• I'm not sure, but using 00000... as the UUID could be causing problems - it's extremely likely it's reserved (it's not a 16 bit UUID if that's what you had intended). I'd either use a normal 16 bit UUID, or use a totally random 128 bit UUID as a base and just vary the 16 bits in the middle like you do currently.
  
• The Nordic devices can't change the services that they advertise on the fly, so Espruino has to actually restart the whole Bluetooth stack if items (like UART) are to be removed - hence the message. Obviously if it does that it'll disconnect any connected devices, so it waits until you disconnect. If you just want to update the content data in services then just use NRF.updateServices
  

Hi,
After making the changes and going back to the 16bit UUIDs and restarting nRF Connect app I can now connect to the Puck and see the single new service with characteristic 0xabcd so that is moving in the right direction!
However from the tinyB C++ code on the PI I still only see the original two services listed:
6e400001-b5a3-f393-e0a9-e50e24dcca9e
00001801-0000-1000-8000-00805f9b34fb
and not the new one. My guess here is that it looks like bluez must be caching details about the BLE device, given that tinyB is just a wrapper on top of hci/bluez stack. I'm trying to see how to clear the device cache from bluez to see if that helps.

I tried deleting /var/lib/bluetooth contents and restarting bluetooth with sudo hciconfig hci0 reset
Now the C++ code shows only the service: 00001801-0000-1000-8000-00805f9b34fb

Do you have to do something like initiate a scan for services? Usually when you connect on BLE you don't know what any of the services are - you have to enumerate them separately.

BluetoothDevice::get_services_resolved looks like a good start: http://iotdk.intel.com/docs/master/tinyb/classtinyb_1_1BluetoothDevice.html#a8f13d552098d6549a44cbea62d82796c

Hi,

I initiate a scan for a list of services like this:

controller->connect();
		std::cout << "Fetch services.." << std::endl;
		std::vector<std::unique_ptr<BluetoothGattService> > service_list;
		while(!controller->get_services_resolved()) {
			service_list = controller->get_services();
			std::this_thread::sleep_for(std::chrono::seconds(1));
		}

controller is valid and pointing at the puck.js device, but still just the original 2 listed services as opposed to the new one

Just to verify this isn't a tinyB issue, I tried the same using bluetoothctl, and here is it's output

[Puck.js b3ce]# list-attributes
Primary Service
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b
	6e400001-b5a3-f393-e0a9-e50e24dcca9e
	Nordic UART Service
Characteristic
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000f
	6e400002-b5a3-f393-e0a9-e50e24dcca9e
	Nordic UART TX
Characteristic
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c
	6e400003-b5a3-f393-e0a9-e50e24dcca9e
	Nordic UART RX
Descriptor
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c/desc000e
	00002902-0000-1000-8000-00805f9b34fb
	Client Characteristic Configuration
Primary Service
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000a
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[Puck.js b3ce]# 

Ok, so after a few changes, bluetoothctl is showing:

[bluetooth]# list-attributes F1:F9:F8:7F:B3:CE
Primary Service
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b
	0000bcde-0000-1000-8000-00805f9b34fb
	Unknown
Characteristic
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c
	0000abcd-0000-1000-8000-00805f9b34fb
	Unknown
Descriptor
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c/desc0010
	00002903-0000-1000-8000-00805f9b34fb
	Server Characteristic Configuration
Descriptor
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c/desc000f
	00002901-0000-1000-8000-00805f9b34fb
	Characteristic User Description
Descriptor
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000b/char000c/desc000e
	00002902-0000-1000-8000-00805f9b34fb
	Client Characteristic Configuration
Primary Service
	/org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000a
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[bluetooth]# 

The puck.js code is

function SetupServices() {
  NRF.setServices({
    0xbcde : {
      0xabcd : {
        value : "Hello", // optional
        maxLen : 5, // optional (otherwise is length of initial value)
        broadcast : true, // optional, default is false
        readable : true,   // optional, default is false
        writable : true,   // optional, default is false
        notify : true,   // optional, default is false
        indicate : true,   // optional, default is false
        description: "My Characteristic",  // optional, default is null
        onWrite : function(evt) { // optional
          console.log("Got ", evt.data);
        }
      }
      // more characteristics allowed
    }
    // more services allowed
  },{advertise:['bcde'], uart:false});
}

//setInterval(SetupServices,1000);
SetupServices();

but the bluez/tinyB is showing me:

Bluetooth manager started...
Device discovery..
Discovered devices: 
Class = BluetoothDevice Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE Name = Puck.js b3ce Connected = 0 
Connecting to device..0x1aaeff8
Fetch services..
Class = BluetoothGattService Path = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE/service000a UUID = 00001801-0000-1000-8000-00805f9b34fb Device = /org/bluez/hci0/dev_F1_F9_F8_7F_B3_CE 

So confused now :)

As another test, using this code on the puck

function SetupServices() {
  NRF.setServices({
    0xBCDE: {
      0xABCD : {
        value : "Hello", // optional
        maxLen : 25, // optional (otherwise is length of initial value)
        broadcast : true, // optional, default is false
        readable : true,   // optional, default is false
        writable : true,   // optional, default is false
        notify : true,   // optional, default is false
        indicate : true,   // optional, default is false
        description: "My Characteristic",  // optional, default is null
        onWrite : function(evt) { // optional
          console.log("Got ", evt.data);
        }
      }
      // more characteristics allowed
    }
    // more services allowed
  });
}

SetupServices();

var cnt = 0;
setWatch(function() {
  if(cnt++ % 2 === 0)
    LED1.set();
  else
    LED1.reset();
  NRF.updateServices({
    0xBCDE : {
      0xABCD : {
        value : [cnt],
        notify: true
      }
    }
  });
}, BTN, { repeat:true, edge:"rising", debounce: 50 });

Connecting via nRF Connect iPad app, I can see the service and Characteristic ABCD..
It's default value however shows as 0x0D and pressing the puck button (which does toggle the led) is not updating that value

Are you sure you're subscribing to notifications in the nRF Connect app? It doesn't do it automatically when you look at the service, you have to click the icon by the side of it.

Just a thought, but maybe try not including the description - i think that'll be responsible for the 0x2901 descriptor at the very least.

Ok, I've removed the description, still get a 0x2901 descriptor. Definitely have the app subscribed to notifications. What I have noticed is perhaps it's the way the value is being interpreted, if I specify it as an integer in the updateServices with value : cnt
it seems to be coming through as a string representation of the value of cnt.

Looks like I've gotten it working now, it's all been a bit flaky, but I'll keep trying to make sure it's 100% then I'll share the code here for both the Puck and the C++ tinyB, it's a good base to start from.
Thanks for the help!