We really love the Particle HW, esp the ease of integration and the FCC certification ease, etc, and DeviceOS is nice, but with Mesh dead, we’re not really that swayed by it.
We’d like to explore the suggestion made by Particle to go straight to the OpenThread SDK and use the Boron as a Border Gateway for other devices in an OpenThread mesh, has anyone actually explored this route? Thoughts, experiences, etc on the endeavor? Yes, I know we “lose” all the DeviceOS, Particle Cloud, etc niceties, and likely will have to do a lot of the LTE handling ourselves, that doesn’t bother us, at this point, after chatting with our Particle Biz Dev rep it seems that Particle has little to no interest in any kind of mesh functionality, but, honestly, their hardware is pretty good. Especially when you pair it with a $30/yr unlimited ATT IoT SIM. We figured we’d prototype hanging our mesh of devices (all in the same room) off a Boron Gateway in an OpenThread mesh and hang it off of an IoT management platform that has a good Nordic SDK library.
Would love anyone’s experience in going down this road, or even just dealing directly with the LTE module, as the OpenThread stuff is available and I figure it’s easy enough to JLink the nRF52 bootloader and relevant firmware onto the device.
No experience with this to help you, but I’d be extremely interested in how you make out. I don’t see any reason the particle stuff shouldn’t be able to talk to and receive values from a mesh just like it would any locally connected sensor.
If you go your own way on building this I’d love to see the mesh stuff built so it could run in a Device OS firmware and connect to any Thread devices.
I’ll keep you up to date, at this point we are trying to bring up basic LTE under Zephyr and we’ll then run the OpenThread stuff. We’ll likely start with more of a “manual” proxy where we use the Boron to poll a local OpenThread mesh, summarize the data, and forward out via MQTT on the LTE interface, but we are also exploring implementing a full Border Gateway on the device under Zephyr to allow OpenThread nodes behind this to directly do this using the OpenThread BorderGateway. There is good Nordic-provided and supported code portions of this, a lot of the pieces are there and we’re sensing that the path of least resistance may actually be this rather than trying to get DeviceOS to do this through other ways (like BLE, which is totally insecure esp as the DeviceOS implementation has zero auth/pairing/encryption support, but BLE is also fundamentally useless beyond 3 devices as is in DeviceOS, and even changing the flag BLE’s protocol semantics scale memory use really poorly past that, and pretty much hits a hard limit at 20-32 in many implementations), not trying to criticize anything, but just illustrate that for us, that’s a really steep curve/path with a LOT of resistance, and using Zephyr doesn’t have any of those issues, avoids adding on another emitting device into our HW design (think: FCC, power, size, everything). It has its own challenges (much more work up front and DeviceOS), but once that leg work is done…it is much smoother and efficient sailing. Theoretically. Let’s see if that pans out :).
You might look at Jared Wolff’s nRF9160 if you want to fiddle with adding your own mesh. It has much of the LTE and Nordic SDK libraries already integrated.
Yup, we did evaluate the nRF9160 in the very similar Actinius board and Fanstel is making a really cool M.2 form factor that has the 91 and the 52 collocated with internally connected UART pins, etc.
Both options are still quite larger than the Boron’s nRF52840 + ublox SARA R4 integrated module it has but a non-Particle board with the two nRF processors working alongside each other as coprocessors is likely the route we will go as it’s really very well supported and let’s us do OpenThread alongside the LTE in a coprocessor style arrangement that’s very well supported officially by Nordic.
It’s a shame, I think Particle has great hardware and sad that we can’t find a good software stack for their great hardware. The Particle experience in evaluating the Boron had a lot of (unfulfilled) promise, and really great hardware. If the software stack can catch up or they could make mesh work, they could really have something incredible.
@kenmacd - So we have done about a week or two’s worth of due diligence and actual prototyping to find what works and what fails (and what the reality of what works/doesn’t work is), and despite Zephyr having Particle Boron support and a ublox SARA R4 driver, they never really worked well together.
OpenThread is not that straight forward, but there is some good, first-class citizen type of support for it in Zephyr and some very good RCP and NCP firmware options for the nRF52840 that let it function as an NCP or RCP for an nRF9160 and we have it working quite well on our own mashup of the nRF52 and nRF91 as well as a Fanstel board with an m.2 form factor that is similar, but out of respect for the fact this is Particle’s space for discussion of their products, I’ll leave the non-Particle discussion at that and leave it with a compliment to how excellent I think their hardware is. The Boron is a very good piece of kit from a hardware perspective and I hope they succeed in building a software stack for it that works and is differentiated. We investigated adding in support to DeviceOS for this ourselves and while it seemed possible, Particle didn’t seem interested in supporting it (their sales team was tepid at best on the prospect - not in a mean/bad way, just not their direction it seems) so that kind of scared us away from contributing to a platform controlled by them that is-but-isn’t FreeRTOS.
We’re heading down the path of using the two nRFs as I discussed with Nordic’s provided SDKs and it’s working pretty well, if you want to know more, feel free to DM me, but I want to limit the non-Particle discussion here and not overstay my welcome.