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.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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.