Nordic vs. CSR Mesh


First, congratulations on the funding. I’m looking forward to getting the kits once they are ready.

I’m exploring BLE and mesh networking. It looks like you guys are choosing Nordic. I’m curious if you looked at all at CSR BLE and their mesh protocol? If so, do you mind sharing your thoughts on why you picked one over the other?

Thus far I haven’t dove into the detailed implementation of either device, but I’ve been downloading documentation. I’d love to hear from you guys, if you have an opinion.

Thanks - Tim


Great question. We looked at a fair amount of options when we chose the chipset. The major ones we looked at were CSR, TI, and Nordic.

The problem with CSR is that they are pretty closed. Generally, you have to buy a very large amount of devices before they would even talk to you. And then, most of their libraries and stack are closed. I looked into them about a year ago and basically hit a brick wall, they simply don’t want to talk to you unless you are going to buy 1M devices.

TI was also an option, but not a very attractive one. The main chipset uses an 8051 MCU, not ARM, and it had limited RAM. We needed at least 16K RAM for the Particle cloud encryption, so this wouldn’t work. Plus, they usually require expensive compilers and tools like Keil.

Nordic, on the other hand, works with gcc. Plus, they are now offering the new 32K RAM option which finally allows us to make this work. Before the 32K option was available, we were actually using a second MCU to do encryption for us, which added to the cost and complexity. The new nrf51822 is the first BLE SoC we could get our hands on that would allow us to support it.

The nrf51822 has also been around for a long time. It is a stable, reliable solution with a good ecosystem of modules to choose from. They also are moving more towards open source, so we shouldn’t have any issues opening up the whole codebase (except for the compiled BLE stack, but that comes pre-loaded anyway).

So really, Nordic hit all the right points, and it was kind of a no-brainer. Without the new nrf51822, this would actually be a much more complicated solution.


Thank you Eric for the quick response and sharing your experience on looking at the various options for BLE and mesh.

Up until a couple months ago, I thought BT and BLE were mainly peer to peer techs. So now that I’ve been doing some reading and investigating I am excited about mesh on BLE because of the low cost, and I like the idea that it may be standardized in time. Isn’t rev4.2 that will have mesh in it? I’d guess that any of the BLE mesh stacks right now will migrate to adopt any standardized form so that hopefully their is interoperability.


Bluetooth 4.2 just came out recently and does not include mesh yet. It mainly included some lower power and higher data rate enhancements, and the big inclusion of IPv6 support.

Mesh is expected in Bluetooth 4.3. Until then, yes, we plan to use the Nordic proprietary method. Once mesh becomes standardized, we will support that as well.

It is a pretty exciting time for BLE. I think it will start to become much more ubiquitous in the home, even Wifi routers may soon include BLE. It can be used way outside of normal bluetooth, and is an amazing low power option for battery powered devices in the home. I imagine you will start to see many more BLE devices that can talk directly to the internet in your home over the next few years


Agreed re: exicting times.

Anyone know if/how future Bluetooth mesh functionality might support (or integrate with?) micro location and/or triangulation types of capabilities? Is that something you guys have seen discussed?


I haven’t seen much from a mesh perspective on that. People use the proximity apps all the time, they are meant for micro location, so that is definitely available. Nordic already has some good examples with this.