I have a couple of questions about Boron (ANT+ bike sensors and working without cloud)

  1. Is it possible to work with the device without using the cloud? Install an external SIM card and write your own code to work with your own servers.

  2. Is it possible to use the ANT + protocol to connect sports sensors? (speed, cadence, etc.)

Yes, it is possible to use a Boron without a cloud connection.

The Boron support BLE 5 but does not support ANT or ANT+, so it can only interoperate with BLE sports sensors, not ANT+ sensors.

1 Like

The nRF52840 support BLE 5 but does not support ANT or ANT+, so it can only interoperate with BLE sports sensors, not ANT+ sensors.

nRF52840 specification lists ANT support. And I used it without any problems, for example, on this device nRF52840 Dongle - nordicsemi.com

What is the reason for the lack of ANT support in the Boron device? This function is not implemented in the firmware?

Correct. There are a lot of protocols that can be used on the nRF52840, but most of them are not enabled in Device OS, so they effectively cannot be used from Particle firmware.

Also the Boron is not certified as a wearable device.

1 Like

Thanks. Does the device have the ability to change the firmware? If I implement my firmware with ANT support, can I flash it seamlessly?

No. For all practical purposes, in order to be able to enable other features in the nRF52 SDK, you need to go all the way back to bare metal nRF52 and won’t be able to use any Particle tools or features, or the cellular modem.

But theoretically, I can write my own firmware for nRF52840 and modem, and flash the device?

I see that Device OS is open source. What can prevent me from adding ANT support there?

You can program the device standalone. There are instructions for the Xenon but the process is the same for all devices. But the main caveat is that there is no cellular modem support without Device OS.

You could, in theory, modify Device OS to add the new features. Among the things you’d need to resolve:

  • There’s an abstraction layer between Device OS and user firmware. This is a pain to work with, so the easiest solution is probably to build a monolithic binary. In Particle Workbench, this is a Debug binary. Without the abstraction layer it’s way easier because you can more easily call nRF52 SDK functions.
  • You may need to change the SoftDevice binary. If the one you need is significantly larger, this will probably run into the load address of the system or monolithic binary, which would be a problem.
  • If you’re going to scale, you can’t make a product fleet with monolithic firmware. And it’s difficult to update Device OS OTA with a custom fork.
1 Like

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