nRF51822 vs nRF8001 when having an external MCU

RE: nRF51822 vs nRF8001 when having an external MCU

awneil — Fri, 09 Oct 2015 11:57:08 GMT

... and any comments for the nRF52 series?

RE: nRF51822 vs nRF8001 when having an external MCU

julian — Wed, 07 May 2014 04:24:23 GMT

nRF51822 comes with CPU, but nRF8001 doesn't? does that means for nRF8001 has to add CPU somewhere?

RE: nRF51822 vs nRF8001 when having an external MCU

David Edwin — Mon, 17 Mar 2014 17:21:23 GMT

Sleep current for the nRF8001 is slightly lower than the nRF51. See section 12.4 Current Consumption parameters in I_idle and I_sleep in the nRF8001 datasheet I_idle is lower for the nRF8001 while i_sleep is almost the same between nRF51 and nRF8001

You can also implement an complete power cutoff for the nRF8001 and nRF51, by which the power is cutoff (you should first read the RAM by do a Read Dynamic data) and when the nRF8001 is required again, the power can be restored and the RAM is also restored using Write Dynamic Data

This enables you go to the lowest power states possible. The nRF8001 enables this out of the box using Read Dynamic Data and Write Dynamic Data.

You should examine if the nRF8001 fits your needs and then consider the nRF51 if it does not, especially if you are using it as a connectivity device as the nRF8001 interfaces are easier to use and to get started.

RE: nRF51822 vs nRF8001 when having an external MCU

Ole Morten — Mon, 17 Mar 2014 10:29:12 GMT

There is no doubt that the nRF51822 is a lot more flexible than the nRF8001. From a BLE perspective, it has primarily 3 benefits, which may or may not be applicable:

Higher throughput (6 packets per interval instead of 1).
Possibility of being a Central (by replacing a softdevice).
Possibility of having multiple bonds.

However, there is no doubt that it introduces extra complexity, in that you have a second controller to program. There are a serialization example in the SDK, showing how the full softdevice API can be serialized, so this could be an option. A slightly more elegant solution may be to make a higher-level API yourself, tailored to your application, to reduce serial interface traffic and hence power consumption.

As for flashing, there are an example bootloader in the SDK as well, but it is currently not possible to replace a softdevice with it. For full flexibility, you would therefore most likely have to include a SWD implementation on your main controller, and flash the nRF51 over it. If however you can live with not replacing the softdevice, you can get away with just the UART bootloader. The next softdevice release will also make it possible to do minor revision upgrades using the UART bootloader.

As for crystals, the only required crystal for both the nRF8001 and the nRF51822 is the high-frequency oscillator (16 MHz for nRF8001 and 16 or 32 MHz for nRF51822). With the nRF8001, it's possible to use the DC/DC (if you don't have a 32 kHz crystal), while on the nRF51822, the DC/DC is currently unfortunately unusable.

Software-wise, the nRF8001 is a lot simpler than the nRF51822, and can as Soren says be used over an SPI interface. We've recently released the Arduino SDK for it, which should be easy to port to other MCUs if needed.

Bottom line, if you can live with its limitations, the nRF8001 is a much simpler way of adding BLE to an application. However, if you need the possibilities of the nRF51822, it's perfectly possible to use it in a serialization setup as well.

RE: nRF51822 vs nRF8001 when having an external MCU

Soren — Mon, 17 Mar 2014 00:41:31 GMT

Hi David,

I had faced the same dilemma before when I was using an external microcontroller and TI's CC2541 which has some processing power besides its wireless capabilities.

What I disliked the most about the aforementioned setup was that I needed to flash twice with two different programmers, one for my microcontroller and one for the Bluetooth chip, which also diminishes your PCB real estate because you need headers and traces for both.

Of course if you use an SoC that takes care of both your processing and communications, you save a lot of space. However in terms of design flexibility, I always prefer to keep my modules separate. That's why now I use a low-powered microcontroller with nRF8001, which can be programmed over SPI. Unfortunately, I need 3 oscillators in this setup.

Some microcontrollers such as "EFM32" and "PIC24F GC Series" are more advanced than SoC modules and have some great power-saving features.

Cheers, Soren