@mtiutiu Thank you very much. I like to read your words. Have fun with this port.

I have started 2014 to work on Sensors based on the nRF51 chips. At this time the MCU was well documented, but Software was only available under an NDA. Without luck, I tried to build a free Arduino version based on RFduino. There are problems with my linker scripts.

My next attempt was to use RIOT OS as the base for my Sensor project. Later I have found the great MySensors project. I have started to extend the RIOT Arduino layer to let MySensors running. On my research, I found the Arduino port of Sandeep Mistry (thank you!), so it was easier for me add the missing functionality to MySensors and arduino-nrf5 instead to RIOT OS. From this point, I required eight months to a functional MySensors port.

There are discussions about OTA for nRF5 sensors. We have two variants to that:

1. Use Nordics DFU mechanism.
2. Implement a SoftDevice independent mechanism

Nordics DFU is ready to use for applications using the official SDK and a SoftDevice. At the moment the MySensors port doesn't support running on Chips with SoftDevice. I think this is more than a little work to implement SoftDevice Support. (NVM collision, Interrupt and RTC sharing, dependencies to non-LGPL compatible SDK...)

The SoftDevice supports updating the firmware with a smartphone and is pre-installed on most/all nRF5 chips. With this type of bootloader, it's easy to install MySensors without using programmers or special hardware. On the other side SoftDevice and bootloader requiring a lot of Flash memory, the SoftDevice reduces the usable RAM.

As I know, Nordics bootloader cannot be protected to flash other software. When a device is lost, encryption keys can be extracted.

My idea is creating a new bootloader which allows only flashing encrypted or signed code. The encryption keys can be protected with nRF5 hardware access control wich denies accessing the bootloader memory from applications. The debug interface can be disabled.

This bootloader can initially be flashed via Nordic's DFU. To do this an additional loader is required, wich runs in RAM to erase the whole Flash.

For flashing a second nRF5 or maybe nRF24 is needed. The flashing controller or additional software manages firmware delivery and encryption.

The first installation of the alternative bootloader needs a component to establish a new connection with an asymmetric key exchange. The resulting key is stored in the protected bootloader area. The initialization part can be erased after pair to the central firmware management. This keeps the boot section small.

New firmware should be flashed via a very small radio protocol, from internal flash for MySensors OTA support and via the serial port.

@NeverDie said in nRF5 Bluetooth action!:

Your idea of having the pin mapping be selectable within the sketch sounds great! A+. I'm really looking forward to that and hope that you can do it soon.

With merging this pull request the feature should be available: https://github.com/mysensors/ArduinoBoards/pull/13

Documentation can be found at https://github.com/mysensors/ArduinoHwNRF5

The "ITC PolyU HK" is one of the most interesting nRF5 Boards I have found. This board is useable with the upcoming MySensors 2.2 release. The radio can communicate with nRF24 networks.

At eBay or aliexpress boards are available starting at 12€. The ob board hardware is:

• nRF51822QFAA (Cortex-M0, 16kB RAM, 256kb Flash, SPI, I2C, UART...)
• Two Buttons
• one RGB LED
• MPU6050 accelerometer
• AP3216C distance and ambient light sensor
• BMP180 pressure and temperature sensor
• CR2032 Battery Holder

At the moment I have decoded the layout. There is no arduino-nrf5 board definition. My idea is to build a repository of YAML based board definitions to generate board definitions without letting the list of arduino-nrf5 included boards growing.

Issues:

• Board is not supported by arduino-nrf5 at the moment
• UART only available via two of the solder/contact pads
• ~~Sleeping until pin interrupt consumes 1mA -> https://github.com/sandeepmistry/arduino-nRF5/issues/153~~

When the arduino-nrf5 board definition is ready, I reply here.

I'm not neutral ;-). I have ported MySensors to the NRF5 platform and completely reimplemented the NRF24 protocol, because at the point of starting Nordics License for the ESB protocol was not compatible with Open Source Licenses.

@Omemanti said in nRF5 Bluetooth action!:

Since this topic passed the 1000 posts, can someone tell me if the NRF5* , for mysensors, is worth diving into?

I you are able to do more than described in the MySensors example sketches, you should give it a try. It's a little bit more complicated than starting with ATMEGA based boards.

And could someone be so kind, to sum up some pro/cons?

Pros:

• Enough Flash and RAM
• Faster CPU
• periphery can do a lot of things while the CPU is sleeping (PPI, SHORTS)
• Small footprint of sensors
• Mostly free pin mapping in your Sketch
• NRF24 compatible
• Same price like ATMEGA + NRF24
• No bad clones like NRF24
• Better range than NRF24 (
• Flexibility to change the radio protocol
• BLE Long range, USB with the upcomming NRF52840
• Most complete 32 Bit implementation for MySensors (at the moment) supporting sleep(), hardware random numbers, soft signing and an internal EEPROM emulation without additional hardware.
• Great hardware included
• Can be mixed with other radio modules like NRF24 (useless but tested) or RFM (untested)
• Enough resources for better security concepts
• No need for ATSHA204 when you don't require read back protection. Enabling read back protection depends on OTA updates, which are not implemented at the moment.
• Well documented MCU's

Cons:

• Not all Arduino functionality available like EEPROM (available in MySensors or externaly via emulation), Tone library
• Maybe some bugs in the arduino implementation or radio implementation
• OTA firmware update is missing for MySensors, but it's possible
• BLE with MySensors is not supported/tested at the moment. I think BLE support needs a little bit of porting code to SoftDevice API
• Beta: Needs field testing
• Multiple NRF5 Arduino ports like (arduino-NRF5 or Primo). Only arduino-nrf5 without SoftDevice is supported at the moment.

Neutral:

• Radio is for 2.4GHz only which means less regulations but shorter transmit distance
• The NRF24 protocol isn't a good protocol for encryption or battery powered nodes permanently listening for packages, the protocol can be replaced in 100% NRF5 networks in the future

I think there is no future for 8 Bit Controllers in the Arduino world. If you want to do more without diving into the PROGMEM hell, then it's time to switch to 32 bit controllers. The NRF5 is an interesting and highly integrated choice for 2.4GHz networks.

My small home network is completely NRF5 based. From time to time a node stops receiving packages. The problem is known and documented by Nordic. I working on a fix.

There are some differences in timing between NRF24 and NRF5 which are no problem, I think. The NRF24 is ~12µs earlier in RX mode and the NRF5 is ~400µS earlier in TX mode. If this is a problem, it's catched by a retransmit. Instead of tuning this protocol, I think it's better to invest the time in creating a protocol which allows battery powered nodes to listen for packages and allowing better security than the NRF24 ESB protocol.

@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:

Do you work for Nordic?

No. I have ported MySensors to the nRF5 platform and contributed nRF5 code to arduino-nrf5 and RIOT OS.

Actually this is the most complete port supporting hwSleep() or hwCPUVoltage(). The good news is, there are a lot of other 32 Bit MCUs available and MySensors supports actually:

• ESP8266
• nRF5
• SAMD
• STM32F1
• Teensy3

The number of ported 32 bit MCU's are the reason for my opinion of 8 bit support. I'm sure we see much more interesting MCU's supporting MySensors in the future.

@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:

16meters instead of 15 meters? Very good range for wireless mouses and keyboards...

For long range sub GHz is the better choice. This is physics.
btw: https://www.youtube.com/watch?v=wRpW2KIPfVo

@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:

without the 2k RAM limit

64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.

If you are right, we can provide the same security level for both platforms without compromises. That's fine.

I think the question about the mass of data are storable in the RAM is a question of data alignment and the stack should be larger. With perfect misalignment, you can loose 5/8 of data memory. If you call all your functions with 8 bit arguments, then you loose 3/4 of stack.

In the unrealistic 3/4 scenario 2k 8 bit ram is comparable with 8k 32 bit ram.

@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:

I think in six month the pricing is eqal.

I will be happy if we will have a stable framework in a year

Please help by reporting the issues you have found, so we can create stable 32 bit platform support.

@Bogus-Exception said in Where to get legit nRF24L01+ modules?:

The chips on Mouser/DigiKey go at cheapest for under $4 USD...

At this price level, you can get an nRF51822/nrf52832 module. This is a NRF24 protocol compatible MCU with included radio. The nRF5 platform is supported with MySensors development branch. If possible choose the nRF52 series. They faster and more flexible. But the nRF51 is much more powerful than ATMEGA328 + nRF24.

Depending on the antenna the transmitting range should be better than nRF24 modules.

There are a lot of ready to use boards available at ebay and aliexpress.

More about the nRF5 port: https://www.openhardware.io/view/376/MySensors-NRF5-Platform

Radio discussions:

• https://forum.mysensors.org/post/70945
• https://forum.mysensors.org/post/70283

A cheap module with nRF52832 found by @Nca78 https://forum.mysensors.org/post/70614

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

Anyone here ever gotten the st-link v2 to work with the arduino and nRF52832? Seems like most published instructions pertain to the J-Link instead.

Yes, but I use Linux. I have all three supported programmers working. After adding an udev rule to fix permissions for any type of adapter they working very well. If you haven't luck, the CMSIS-DAP is an alternative to ST-Link or J-Link.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

Why is it that mysensors is opting for the Nordic proprietary mode instead of the BLE standard? Is it just too cumbersome or something?

There are some reasons I haven't implemented Nordics proprietary standard and I have no intension to use BLE as MySensors transport.

Like @scalz I think MySensors is a protocol and BLE is another protocol. MySensors is optimized to build a network of up to 255 nodes can communicate with low latency and BLE is a complex protocol for a limited number of nodes. There are a lot of use cases for both.

In my opinion, Nordic's BLE code and SDK is not Open Source friendly. I think you can't create LGPL code based on Nordics BLE SDK examples. To Compile code, you have to agree Nordics License or you have to choose.

For MySensors, I think the Apache implementation NimBLE should a good BLE implementation to start with. This Implementations looks more efficient than Nordics implementation and I like the OTA update/bootloader concept. At https://www.kickstarter.com/projects/redbearinc/bluetooth-5-ready-ble-module-nano-2-and-blend-2 is a demo video of a 32 node BLE network. It looks like there is a high latency in communication.

To support Nordics SoftDevice or another BLE implementation, the MySensors nRF5 code must be extended to use the hardware abstraction for e.g. random number generation, accessing flash memory or interrupt handling. When it's done a MY_RADIO_NRF5_BLE can be implemented.

Another option could be to use BLE packages without the BLE protocol, then its possible to communicate with any BLE MCU which allows direct access to the radio. Actually you can use the ESB protocol with BLE modulation, but I think this is incompatible to other BLE MCU.

BTW: The nRF52840 cannot communicate with 250kbit nRF24. This rate is depreciated since nRF52822 release.

@ben999 said in nRF5 Multi Sensor Board (12-14€):

Could it be a direct replacement of Arduino Pro Mini and nRF24L01+ ?

Maybe, the NRF5 can replace the combination of ATMEGA+NRF24 chips but it's a 3.3V chip and I don't know an NRF5 board in Arduino Pro Mini layout.

Please look at https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/1092 for pros and cons.

At the moment the radio protocol is a little bit unstable, because there is an hardware issue, which must be fixed in software. At the moment I do a rewrite of the ESB protocol, which fix this issue. My old implementation is hard to debug. With my new implementation the radio states are separated into extra functions and I use more of the nice event driven capabilities (PPI, Shorts). Until I have finished this fix, sometimes an NRF52 needs an reset.

@scalz said in nRF5 Bluetooth action!:

So, for your ebyte module your options are:

I working on the fourth option, I publish soon:

• Define the pin mapping in your sketch, then its part of your code

Like @scalz has written. Place the MCU in your layout and define the pin mapping later. Exceptions are analog pins, comparator pins , NFC pins, reset... The pins are documented in Infocenter: Pin assignments Please look at the "GPIO usage restrictions" chapter too.

There are two reasons missing SoftDevice support. The License at the time of starting my port of MySensors to NRF5 and I don't like to have the SoftDevice on my Nodes. I have never tested MySensors with a SoftDevice present.

At the moment I reimplement the ESB protocol, because there is an bug in the NRF52 hardware (PAN102) which I had no luck fixing it in the current ESB implementation. The new version uses more resources like PPI and Timer and splits the code for TX, TX with ACK and RX. I hope this is better to debug and easier to understand.

When I find some time, I do some tests if this code works with a SoftDevice present. When it works, then I remove or change the error/warning message about SoftDevice support. I have no plans to add code for dual Stack (BLE, ESB) or SoftDevice cooperation, but Pull Requests to do this are welcome.

If someone have plans to add BLE support, please look into the SoftDevice/DFU bootloader memory map. I think the DFU bootloader conflicts with the NVM library, which is used to store the MySensors configuration.

@NeverDie said in nRF5 Bluetooth action!:

For instance, how hard would it be to create a simple serial bridge so view serial output on your bluetooth phone, the way @sundberg84 is doing with a specialized bluetooth module: https://forum.mysensors.org/topic/6340/debug-to-a-sd-card-module

For similar functionality, there is an MY_DEBUG_OTA feature in MySensors development branch. You can send log messages to any node in the MySensors network.

The NRF5 MySensors port is running directly on the MCU hardware. Using the SoftDevice is like running an Operating System. There are limitations using the Hardware and APIs have to use. You are loosing control over the Radio, some Timers and RTC, Crypto components and the memory layout.

The reason the SoftDevice isn't supported is the old licence model. This model is changed with SDK14.

In my opinion with MySensors 2.x it isn't meaningful to play with the multiplexing of the radio module. I think this requires more changes in MySensors to handle the time when the MCU is in BLE mode.

If you are interested implementing a dual stack software, then I think the Arduino Primo port is a good point to start. This is based on the NRF5 SDK. The Primo port has no support for NRF51 devices.

If you are not restricted to Arduino, you can also see MyNewt or Zephyr. Both have BLE Open Sorurce implementations for the NRF5 MCUs.

@alowhum said in nRF5 OTA updates:

Any luck? Has OTA support for NRF5 materialised?

It's not complete yet. My idea is to use mcuboot as bootloader and the MySensors OTA protocol to transfer a new firmware image. The last one is completely finished. I use the zehpyr port of mcuboot. This is working fine for NRF52 MCUs, but it depends on an memory layout of zephyr. The arduino-nrf5 port is using another memory layout.

At the moment, I can flash a new firmware image over the air, the image starts until the first interrupt routine is called. I think this can be fixed for NRF52 MCUs. Last time, I have looked into the mcuboot project, the NRF51 MCU wasn't supported.

I can't work on that in the moment, because I'm very busy with non MySensors related tasks.

@NeverDie said in nRF5 Bluetooth action!:

Anyone tried building a bluetooth stack on the nRF5x from within the Arduino IDE? I can see how running it simultaneously with the mySensors code would be tricky, but maybe one could switch back and forth between the two? e.g. if you want to output debug text to a terminal window on your smart phone via bluetooth If so, anyone have any demo code for doing that?

The parts of the SDK to disable and enable the SoftDevice are not included into the arduino-nrf5 port, but on the Primo port.

For that matter, has anyone here tried the Arduino Primo? And if so, how did it go?

The Arduino-NVM library is not compatible. This results in a crash. My first try to use the SoftDevice API was not successful.

@ileneken3 Thank you.

Like @scalz has written, the range depending mostly on the antenna. With the same antenna the nRF52 series are more efficient.

If you need a simple module to start with, a RedBear BLE Nano 2 or Nano is a good module. It's a small module with integrated voltage regulator and 2.54mm pins. This module is available in the second generation with compatible pin layout.

If you need an cheap module, there are some starting at 3-6€ with an nRF51. I don't know how long these modules are sold. If possible, use nRF52 based modules. The nRF52 is faster (https://github.com/mysensors/MySensors/pull/845), more flexible and less current consuming then nRF51. The interrupt vector of the nRF52 can be moved into RAM. This reduces the interrupt latency and allows to implement OTA updates in an simple way.

Most peripherals (e.g. expect ADC) can be assigned to any IO pin. So you can change the role in arduinos board definition.

You can find detailed information about the current consumption in the datasheets. The MySensors sleep function consumes 3µA until you want to wait for an Interrupt (1mA). To fix this cores/nRF5/WInterrupts.c needs an partitial rewrite. I have no time at the moment to fix this issue. The discussion about how to fix is sleeping: https://github.com/sandeepmistry/arduino-nRF5/issues/153

Another point to save some energy is to manage the DCDC converter (not available on all boards) in the radio or sleep code. -> https://devzone.nordicsemi.com/question/685/ldo-vs-dcdc-nrf51822/

More energy savings, requires breaking the compatibility to NRF24 radios and implementing an additional communication protocol. This allows to implement battery powered nodes which can receive packages.

When issue 153 is fixed, I think the nRF5 platform is a good choice to start new developments of sensors without the CPU and memory limitations of ATMEGA or maybe in the future the limitations of NRF24 radio. When its not fixed this is a good platform for main powered components and sensors which are only waking up by time.

1. I have updated the radio driver with fixes for some hardware errata.
2. I have updated the https://github.com/mysensors/ArduinoHwNRF5 with an enhanced definition format. File name and contents are changed! The board description is compatible with the NRF5 variant provided by Arduino, but it's not possible to use this variant at the moment.

@d00616 said in 💬 MySensors NRF5 Platform:

I have changed the templates a little bit and moved the code for pin mapping generation. Now it works for me. Please give me some time to clear the code and create a new package (0.3.0). With the new package, you have to add '#include <compat_pin_mapping.h>' before '#end" in MyBoardNRF5.cpp. You have to rename the '#ifdefs' and '#define' in both board files to match MYBOARDNRF5 instead of MYNRF5BOARD.

Now, there is a new Version 0.3.0 for MyBoardNRF5 available. It can be installed via the Board Manager. Please change the templates like described above. I think, now the board definition is stable and ready to support other Arduino variants without changing the board definition.

Hello,

while takling with a manufacterer of nRF52 modules I have seen the product catalog. This http://www.ebay.com/itm/2pcs-E01-ML01D-100m-nRF24L01-2-4GHz-RF-wireless-transmitter-and-receiver-module-/191974998709 looks like an compatible module with original chip.

There are other modules available:

• http://www.ebay.com/itm/2pcs-E01-ML01S-2-4GHz-0dBm-110m-nRF24L01-Wireless-RF-transceiver-module-/191975027028
• http://www.ebay.com/itm/2pcs-E01-ML01SP2-1-2km-nRF24L01-PA-SPI-RF-wireless-receiver-transmitter-module-/191975030838
• http://www.ebay.com/itm/2pcs-E01-ML01DP4-2-4GHz-800m-nRF24L01-PA-LNA-SPI-Wireless-RF-transceiver-module-/191974974697
• http://www.ebay.com/itm/2pcs-Ebyte-E01-ML01DP5-2-4GHz-nRF24L01-PA-LNA-RF-wireless-transceiver-module-/191966308256
• http://www.ebay.com/itm/2pcs-E01-ML01SP2-1-2km-nRF24L01-PA-SPI-RF-wireless-receiver-transmitter-module-/191975030838

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

You're right. Especially after outfitting the atmega328p with an RTC, the cost is more of a wash. I think the RFM still wins on range, but maybe the 832 will be "good enough"...

The question is, when 832 modules are available. After announcing the nRF52832 with its preview DK, I have waited from 06/2015 to 08/2016 until modules are available for an acceptable price at aliexpress or ebay.

I think the atmega is a slow 8-bit MCU with less RAM. The limited RAM requires to transmit additional nonce packages, when signing is enabled. SoftSigning hashing is 76 times faster. A faster CPU allows to shorten the active time:

• atmega328 14000µs
• nRF51 1739µS
• ESP8266 380µS
• nRF52 183µS

The NRF24 has problems with clones, range and the limitation of packages to 32 bytes. The nRF52 allows to change the packet format to support >32 bytes packages.

At the moment sleep modes are only implemented for 328 and nRF5.

OTA updates are available for 328 and ESP8266. For nRF5 it requires to implement a boot loader. The internal flash should have enough capacity to store a simple bootloader and a firmware update.

If you plan to do a lot of writes into EEPROM the 328 has a real EEPROM. The SAMD requires an external EEPROM, the nRF5/Teensy/STM32F emulating the eeprom in Flash. The nRF5 is using the NVM driver, which allows much more writes to the emulated EEPROM. The price for NVM is some time for log cleaning after some hundreds writes.

IMHO the best MCU for creating new battery powered sensors is the nRF5 stating with a ~3€ board, if required in combination with RFM modules.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

I'm guessing that if I were to desolder the rFM52832 from the DK, then I could use the DK to program other chips using the SW pins by using the J-link that's part of the board.

I think it's simpler to use one of the ST-LINK v2 clones. The DK board should be good for development, debugging and current measurement.

@rmtucker said in 💬 MySensors NRF5 Platform:

Where is myBoardNrf5 so i can check?

This is the better repository: https://github.com/mysensors/ArduinoHwNRF5

@neverdie said in 💬 MySensors NRF5 Platform:

@d00616 Maybe you can just make it like it was before, where there was only one pair of I2c pins, not two as in your upgraded version? Maybe then it would work again.

Please give me some time. After an debug session with @scalz and @Yveaux, I think this is a tool chain (GCC 5.3) problem. The pin mapping array is part of the binary, but the Wire constructor gets an array with 0 while the Wire instance has pin mapping information.

Yesterday, I had a try to port ArduinoHwNRF5 back to the same tool chain (GCC 4.8) used by Arduino Primo and SAMD boards. I think for compatibility, this is the best option.

If I have no luck, I either remove the option of the pin remapping table or I go back to the old version. I think going back is no good idea, because the NRF52840 has more than one 32 GPIO, which requires advanced parameters.