-
• #2
As peripheral I am supposed to call NRF.updateServices() and set a new value.
Yes, that's right, and you specify
notify:true
: http://www.espruino.com/Reference#l_NRF_updateServicesBut how can I detect if this value was successfully read by the connected central?
Unfortunately I don't think there's any way of doing that at the moment. You could try just calling NRF.updateServices until you get an exception?
My current idea is a multipart API:
I think that's probably the best idea. On newer firmwares the device should have been able to negotiate a higher MTU so you can send 50 bytes each time (not 20) as well, which should make things easier.
I guess on your
onWrite
event you could have different message types:- request a packet of data
- acknowledge receipt of last packet of data, request a new one
- acknowledge receipt of last packet of data and request a new one
- request a packet of data
Let's say I have a Puck/Pixl/MDBT42Q collecting data in a queue.
Before any overflow happens this data should be polled via BLE by another system as BLE central.
So as BLE peripheral I use
NRF.setServices()
to create someService
/Characteristics
for pushing out data.The thing is: How can I know if the central actually read the data so I can remove it from my queue?
For the other direction
onWrite
is a synchronous API for writing data back, but for reading there is only:notify: true
and/orindicate: true
which is documented as notify + ACK.But how does it work?
As peripheral I am supposed to call
NRF.updateServices()
and set a newvalue
.But how can I detect if this value was successfully read by the connected central?
How often should I call
updateService()
in case the queue got filled up a bit and there areN
items waiting?My current idea is a multipart API:
onWrite
so the central can request the next itemupdateServices()
If the queue entries have some kind of timestamp or sequence number I can assume that all previous entries are read already and safely remove them.
What do you think?