@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

d00616 created this issue in mysensors/ArduinoBoards

closed Add 'MySensors nRF5 Boards' #13

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.

d00616 created this issue in sandeepmistry/arduino-nRF5

closed attachInterrupt() current consumption #153

Bluetooth 4.0 nRF51822 Temperature Atmospheric Acceleration Sensor Module CR2032

$13.27

Sold out

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.

@lorenzo said in nRF5 OTA updates:

Hi, Any news on that? If needed I can help developping.

No news from my side. Currently I have no time to work on this feature.

You can fork my Repository https://github.com/d00616/ArduinoHwNRF5 to finish the work. It's possible to send a new firmware and the image is new replaced by the bootloader but with the first interrupt the MCU is crashing. For NF52 MCUs, I think this problem is fixable by moving the IV-Pointer to the image maybe there is an problem by different memory layouts of Arduino and Zephyr (used to compile mcuboot).

@neverdie said in MySensors NRF5 Platform:

@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840

With Zephyr, I mean the Zephyr OS. This board definition is part of a newer Zephyr Version, I had used to compile mcuboot. This was ~7 Month ago.

If someone try to work on mcuboot compatibility. Maybe only the IV is the problem. For NRF52 the IV can be moved to the beginning of the image, but the nRF51 IV is in the mcuboot rage.

Sorry wrong wording. All P0 ports can be mapped. But to map P1 ports there is additional code required which does'n exists in the Arduino port.

@neverdie said in MySensors NRF5 Platform:

@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?

Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....

The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.

For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.

If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.

It's welcome if someone can finish this work.

@andrew said in nRF5 OTA updates:

I just started to review the NRF5* possibilities. regarding to the code protection, are you sure that you have to implement this by your own?
what do you think about CTRL-AP - Control Access Port, APPROTECT?

This is already implemented -> https://github.com/mysensors/MySensors/blob/development/hal/architecture/NRF5/MyHwNRF5.cpp#L69

Do not enable this feature until the bootloader is working. I have an NRF52 board, I can't erase after enabling the feature. I think the problem is I haven't enabled the reset pin.

I have tried to erase the MCU with ST-Link an CMSIS adapters. Maybe I have more luck with an J-Link.

@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!:

Speaking of batteries, I found only one proper holder for holding two CR2032's in series:

There are CR2477 (560mAh) or CR2450 (950mAh) 3V cells. Maybe its's better to handle.

@nca78 said in MySensors NRF5 Platform:

Should we worry about that ?

No. There are some ports of Arduino for NRF5. At the moment MySensors is not compatible with the Primo Port, because it comes with the SoftDevice. It changes nothing for the current state.

@monte said in MySensors NRF5 Platform:

@d00616 thanks for a reply. I will evaluate my skills for this task, when I actually will get a chip to try it on. I need some really small pcb for my project, and single chip with mcu and rf with the size of nrf51 fits perfectly, but it requires quiet simple communications and full MySensors library will be overkill and hard to adapt for my needs.

If possible use the nRF52 series. There are some improvements like better radio sensivity, lower current consumption, more RAM and flash, better ADC and a better CPU. Maybe in the future there is a Firmware update OTA functionality which is easier to adapt to the NRF52 than the NRF51 platform. Another reason to use the NRF52 is, that the official Arduino NRF5 port only supports the NRF52. This port has a lot more capabilities than the arduino-nrf5 port, but MySensors is not compatible at the moment.