Boron migration (from Nordic SDK)

Firmware
#1

Hello All,

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?

#2

Not sure what device should be - there is on no Neon.
Did you mean one of the other inert gases Argon or Xenon?

1 Like
#3

Sorry, should have been Xenon - no longer in production. But a great product nonetheless!

#4

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.

1 Like
#5

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.)

#6

To answer your questions you may want to have a look at the docs here
https://docs.particle.io/reference/device-os/firmware/boron/#bluetooth-le-ble-

And the tutorial and examples here
https://docs.particle.io/tutorials/device-os/bluetooth-le/

#7

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.

#8

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.

#9

Just for reference, here is the sequence of steps in the nRF code:

  1. Initiate scan
  2. Callback for each advertisement seen, manually filter looking for one that offers a particular service (by short UUID)
  3. Upon finding desired service, connect
  4. Idle until event of ATT MTU exchange completed
  5. Initiate discovery (just to enumerate uuids of characteristics)
  6. Upon event of discovery complete, record characteristic and cccd handle values for subsequent steps
  7. Write “indication” into cccd handle, wait for response
  8. Repeat step 7 (because there are two handles with indication)
  9. Idle until event of GATTC callback for HVX (indicate reception)
  10. Save data that comes with indicate, send confirmation on the indicate.
  11. Write to one of the data handles (what the peripheral expects), wait for response
  12. Repeat step 11 for another command to the peripheral
  13. Idle until another event of GATTC callback for HVX (indicate reception on another handle), then send confirmation of indicate.
  14. Repeat step 11 for the final command, wait for response
  15. Disconnect
#10

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.