I have a working application using a Particle Neon. It communicates with a blood pressure monitor. All development was done using a Nordic SDK (Softdevice S140) and directly programmed onto the Neon using a Segger.
The blood pressure monitor has a constrained bluetooth interface - things must be done in the right order, and with correct timing or the connection drops. Briefly, the application scans, connects, discovers, write indication to some handles, receives HVX and confirms – all these are done through Nordic’s SDK. I also needed to attach an RTC (using I2C aka “TWI”) because the blood pressure monitor expects its clock to be set.
Now I would like to upload blood pressure readings to the cloud, using cellular - I plan to use a Boron to do this.
What is the advice to migrate this working application to the Boron?
It’s hard to say as we don’t know your Xenon code, but when you want to use the Particle cloud features I’d not use bare-metal nRF code but use the APIs provided by the Particle Device OS framework.
One concern that I have is how comprehensively does the Particle Device OS expose BLE functionality. Details such as setting up connection parameters, getting indication callbacks, and many other things now in the working code on the Xenon. Does the Particle Device OS just support “simple” cases of BLE, or does is do most everything that is possible with the Nordic SDK?
If the answer is that Particle’s BLE API is too simplified, then one possibility might be to use the Particle Boron just for cellular, use the Xenon with nRF, and have these two communicate over a UART. (Seems wasteful when one knows that just the Boron could do it all.)
Yes, I had looked a bit at this before, but did not see specifically how a BLE indicate event (callback) would look in this API. I do see mention of the possibility
BleCharacteristicProperty::INDICATE (0x20) The value can be indicated, basically publish with acknowledgement.
though there’s no follow up. In fact, the discussion then covers the related BLE concept of notification (in the peripheral role, which seems to be the emphasis of the Particle API for BLE).
The Heart Rate Central example comes closer to what I would need. It and the other central examples (UART) only have simple characteristic scenarios of read/write, not indication operations. Plus I would guess that BLE security, pairing, and bonding are out of scope.
Maybe @rickkas7 can also come up with a tutorial example to illustrate how to do implement an INDICATE characteristic properly (as BLE peripheral and BLE central).
For the time being security, pairing and bonding is not yet implemented but that doesn’t mean it’s not on the ToDos.