Most recent activity
-
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. -
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 -
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 :)
-
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]#
-
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
-
-
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. -
Hi, I think you are correct in that it's a limitation of tinyB. The format you mention is exactly what I'm seeing with the xxxx's replaced with the 16bit UUID value.
Thanks for that link, that's exactly what I wanted so at least I know there is no fudging happening when I try to identify the correct service and characteristic.
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!