Best posts made by d00616

@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.

@gohan said in Where to get legit nRF24L01+ modules?:

@d00616 It would be nice to make sure they are actually genuine chips

I don't know that. The ebay page says the chips are direct imports from Nordic. I have ordered nRF52 modules. In comparison with other shops the modules are well documented and complete (DCDC inductor, two oscillators). After placing my order I got the datasheet. I have ordered a lot of different nRF5 modules via eBay or Aliexpress. This is the first time I've got a documentation. I have asked a question and god a fast response. My question is discussed with the R&D at Friday.

This manufacturer sells nRF5 and a lot of other modules. As I know, there are no clones for nRF5 available. If they selling fake nRF24 modules, I think they god problems to order nRF5 chips from Nordic. If they selling bad modules, they have problems to sell other modules. There are only positive ratings at eBay and Aliexpress.

Ratings for nRF24 modules:

• "Smaller then the ordinary black one, and wakes up faster from sleep, All good"
• "Works fine and very fast delivery, will order another one still"
• "Absolutely the best NRF I could get, Top , Top ,Top..."
• "First seller which sells GENUINE NRF24L01+ from NORDIC.Thank you very much!!!"

I have ordered two nRF24 modules for testing.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

What exactly do I need to do to get it work? I tried it from Windows, and failed. I seem to recall you said you got it to work from Linux after changing a definition. Would you mind showing the steps, or providing a link on how to do that?

I have updates my documentation: https://www.openhardware.io/view/376

I have tested all three programmer types with Windows 10. It looks like Zadig installs the correct drivers for J-Link and ST-Link adapters. The CMSIS-DAP requires the serial driver from mbed.

@neverdie said in MySensors NRF5 Platform:

Ashes on my head. The mysensors code is working with I2c after all. I confirmed it on the second (alternate) node. I had switched two of the wires in the myboardnrf5 pinout, but hadn't on the generic nRF51 pinout. Correcting for that, it now works.

Thank you for reporting this. Great news to hear this.

@dbemowsk said in Mysensors with AT Tiny:

It was a thought of a way to make smaller simple sensors more than anything.

@scalz is on the way to create an really tiny sensor. The nRF5 is protocol compatible to nRF24, but have an really powerful CPU inside.

https://forum.mysensors.org/topic/7167/nrf52-recessed-vibration-contact-sensor-for-door-window/1

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

BTW, it would also be nice to know whether or not the OTA sketch upload capability will work on an nRF51, or only an nRF52 (and also whether it will work on an nRF52832 or only the future nRF52840). Anyone know?

Nordic's DFU bootloader is also working with nRF51 chips. https://devzone.nordicsemi.com/documentation/nrf51/4.4.1/html/group__bootloader__dfu__description.html

At the moment the MySensors implementation is not compatible with a SoftDevice. This requires to change interrupts, use some SoftDevice system calls and move the NVM driver Flash area out of the DFU bootloader area.

I have started a new thread for OTA update discussion: https://forum.mysensors.org/topic/7146/nrf5-ota-updates

@Nca78 said in Minimalist SAMD21 TQFP32 Pro Mini:

Right, it sucks for low power at it needs recalibration every 4 seconds to stay accurate enough, generating 10uA extra consumption. But I'm not sure if this is needed for bluetooth only (because it has to wake up regularly and listen during a precise time window), or also for "nrf24" mode because in that mode we don't need to be precise or regular listenin.

That's correct. If required, the calibration task must be implemented or is part of the SoftDevice. At the moment the radio doesn't require a precise RTC for nRF24 compatibility. For battery powered sensors listening for commands a time slotted protocol is required. Then this protocol relies on a precise RTC.

I think about implementing Read Back Protection to avoid accessing Signing/Encryption Keys via debug interface. This functionality is not part of arduino-nRF5.

The Read Back Protection must enabled once from Firmware by flashing User Information Configuration Registers.

There are two options to implement this. First one is to add this feature to arduino-nRF5 and the second one is to add this feature to MySensors.

I prefer MySensors to force this functionality because the additional step to activate this feature via Arduino menu can be forgotten or not enabled by ignorance.

@Nca78 said in nRF5 Bluetooth action!:

If supplied with less than 3.6V you can do it with ADC, 1.2V voltage reference and 1/3 prescaling.
But I've only looked at the theory yet.

For this, you can use the implemented hwCPUVoltage() function. Reading the voltage costs nRF51: 260µA/20µs | nRF52: 700µA/3µs

@Mike_Lemo said in nRF5 Bluetooth action!:

You mean way more complete every thing is accesable there and there is an example for everything and I didn't use my sensors anyways

No. I mean if you want to use the Nordic MCU with BLE and you want to access the whole hardware without developing drivers, then the Nordic SDK is an option. For special requirements like tone() you have to develop your own routine for Arduino or SDK.

If you want write code which is compatible with other Vendors or want use MySensors then the SDK isn't the best choice.

The arduino-nrf5 targets to provide the Arduino language. I think this is mostly complete. MySensors brings additional support for enhanced pin output modes and the random number generator (no SoftDevice support here).

Accessing the internal MCU hardware must be added via Arduino libraries. With the new SDK license I think it's possible to put parts of the SDK into libraries supporting Hardware which is not specified in the Arduino reference.

If you want to develop BLE applications with portable code, there are open source implementations like http://mynewt.apache.org/ which are designed to be portable.

@NeverDie said in nRF5 Bluetooth action!:

Here it is, though it's rather messy. Nonetheless, all it does is measure the supercap and solar panel voltages, send them, then sleep for 12 hours. Then repeats:

RadioHead sets the radio into the Idle state. The radio isn't powered off. There is no call in RadioHead to power off the radio.

@NeverDie said in nRF5 Bluetooth action!:

Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.

The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

@NeverDie said in nRF5 Bluetooth action!:

Actually, even just sleeping the MCU with a simple command like:
sleep(100);

is apparently enough to require a re-init of the radio afterward. Not sure why that would be.

sleep() deinitializes the transport with transportDisable(). This results in power down the radio.

At the moment I review the ESB code. I think the nRF5 is 12-13µs after an nRF24 in RX mode and 432µs before an nRF24 in TX. This can result in unstable connections when debug messages are disabled.

@NeverDie said in nRF5 Bluetooth action!:

So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

This is a use case for shortcuts. PPI is not required.

There is no TXIDLE event but looking at the state diagram is TXIDLE a result of ether READY or END event. You can enable following shortcurts:

NRF_RADIO->SHORTS = RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_START_Msk;

In PPI this should be the code (untested):

#define CHANNEL (1)
NRF_PPI->CH[CHANNEL].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
NRF_PPI->CH[CHANNEL].TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CH[CHANNEL+1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;
NRF_PPI->CH[CHANNEL]+1.TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CHENSET = (1 << CHANNEL) | (1 <<( CHANNEL+1));

@NeverDie said in nRF5 Bluetooth action!:

Is there any example code which illustrates the use of interrupts on the nRF52832?

Yes. In a sketch, you have to put the interrupt routine into one line. You can define the interrupt only once. If you want to use the radio ISR, you can't enable the radio in MySensors.

https://github.com/sandeepmistry/arduino-nRF5/issues/52

https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L500

@NeverDie said in nRF5 Bluetooth action!:

Which settings are key for ensuring that packets sent by the nRF24 are correctly received by the nRF5? It would be nice to leverage the versions of the nRF24 that have amplified Tx.

These are more than settings. You have to set the Radio configuration like in Radio_ESB.cpp, reverse the addresses and handle sending ACK packages by software.

This is a good resource to understand the OTA protocol: https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit/log/39510-shockburst-vs-enhanced-shockburst-nrf24-vs-nrf5x

I can provide a simple example how to use the MySensors transport code without Radio Head. This works for nRF5 and nRF24 modules, but its outside of that what the MY_CORE_ONLY mode is designed for.

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#endif

#include <MySensors.h>

void setup() {
  Serial.begin(115200);
  
  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

void loop() {
  // Check for packages
  while (transportAvailable()) {
    uint8_t buffer[256];
    uint8_t num = transportReceive(&buffer);
    Serial.print("Data=");
    for (int i=0;i<num;i++) {
      if (buffer[i]<0x10) Serial.print("0");
      Serial.print(buffer[i], HEX);
      Serial.print(" ");
    }
    Serial.println();
  }

  wait(1000);

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
}

@NeverDie said in nRF5 Bluetooth action!:

Yes, and thanks to @d00616's work, RESET can also be enabled/disabled from the Tools menu of the arduino IDE if using myNRF5Board as the board definition.

The reset support isn't complete at the moment. The menu is active, but it has no effect at the moment. I fix this with release 0.2.0.

@NeverDie said in nRF5 Bluetooth action!:

@d00616 What do you foresee regarding the nRF52840? It's presently unsupported.

In those places where it was obvious, I took the design of the NRF52840 into consideration. I think, when an Arduino port supporting Sketches without SoftDevices is available, then porting is simple. At the moment, I have no plans to expedite an Arduino port.

@Toyman said in nRF5 Bluetooth action!:

For MYS, our only hope is d00616, if he doesn't do it, chances somebody will apapt 52840 to MYS are negligible.

Please don't be so pessimistic. I expect some very small changes to MySensors to support the NRF52840 platform when arduino-nrf5 is ported to the new NRF5 MCU generation. When arduino-nrf5 supports the NRF52840 platform, I do some tests with the 840DK, I already have.

Looking back to the NRF52832, I think in 6-9 month we can buy NRF52840 modules with production ready chips. I think there is no reason for panic.

@NeverDie said in nRF5 Bluetooth action!:

I think we can rule out #3. So, if it isn't #2, then is perhaps #1 a factor? I wouldn't think so.

I think, you have to do more things:

1. Change compiler attributes to disable FPU support
2. Change the memory layout in linker scripts. Look into boards definition. Linker scripts are placed under ./cores/nRF5/SDK/components/toolchain/gcc/ The SDK14 has scripts supporting the nrf52810
3. The SDK14 has an dedicated startup code (gcc_startup_nrf52810.S), I don't know if this relevant for arduino-nrf5

I think there is more to do than compile the code. I think the SDK code for arduino-nrf5 must be updated to SDK 14, then a nre MCU must be defined.

I have compared the startup code. The difference is in the interrupt vector. It should work with the NRF52832 startup code, but the linker script must be changed.

@Anticimex said in MySensors NRF5 Platform:

Best would be to come up with a solution that was radio agnostic, but for me encryption is not worth spending too much effort on. I'd say it's obscure enough as it is. Combined with signing, I think people will have a hard time breaking into it.

What do you think about switching signing and encryption to AES-CCM? AES-CCM is part BLE(AES-CCM) and ZigBee(AES-CCM*) specification and available as hardware unit in NRF5 and other MCU. With AES132A a coprocessor is available.

AES-CCM provides encryption and authentication. With AES-CCM the SHA code can be removed. http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fccm.html&cp=2_2_0_28&anchor=topic

My thesis needs testing; I think AES-CCM on an AVR is faster than AES-CBC with SHA signing in Hardware and requires transmitting less data than the actual signing implementation.

I don't know something about the code size of AVR projects. When 8k are available, it's possible to store a unique AES-128 key per node in 4k. For AES key updates, a second 4k page is required.

The keys can be managed with the VirtualPage class: https://github.com/d00616/MySensors/blob/add_nrf5_platform/drivers/NVM/VirtualPage.h

For key exchange a library like micro-ecc is available. A device can authenticated with an preshared secret.

The IV can be built by the node ID and a counter incremented with every packet and a global distributed timestamp.

The counter can be stored in EEPROM after ~1000 packages and is rounded up to next 1000 after a reboot of a node.

If a node counter reaches the end, a new AES-Key is generated and distributed by the gateway.

I have modified the way how random numbers handled for signing. With the original version of MySensors, Nonce data for signing generated from the internal pseudo random generator and the millis() time.

My change replaces the way random numbers are generated with MySensors.

The AVR platform uses a 32 Bit random seed build from a floating analog pin. The way of the generation of this seed is FIPS 140-2 compliant.

For support MCU with a fast way to generate random data, the hwGetentropy() command is now available to allow rapid generation of random data.

The ESP8266 platform uses the internal random source for randomness for hwGetentropy() and Arduino's random() function.

The NRF5 platform initializes the pseudo random number generator from internal hardware number generator. The internal AES-ECB unit generates random data after filling with HWRNG data.

On Linux getrandom() is implemented via syscall().

signerAtsha204SoftGetNonce speed:
AVR = ~14000us (sha204Soft)
NRF51 = ~152us (AES), 1739us (sha204Soft)
NRF52 = ~31us (AES), 183us (sha204Soft)
ESP8266 = ~20us (RANDOM_REG32), 380us (sha204Soft)
Linux = untested!

All Nonce results tested for FIPS 140-2 compliance successfully.

I have no Raspberry Pi to check my change. It would by helpful if someone can install my version on a Raspberry Pi.

The code can be found at https://github.com/d00616/MySensors/tree/add_random_abstraction

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

It's great that you have that perspective to share. Which of the three do you most prefer, and why? Also, if picking one for use under a Windows environment, which would you recommend most?

The J-LINK is integrated into my nRF51 Dev Boards. Arduino-nrf5 uses openocd but I have also used the original software. The CMSIS-DAP is part of some RedBear boards I use.

For any other board without an integrated programmer I use the cheap ST-Link clones and an extra USB to 3.3V serial converter. Be careful I have two versions looking identical but with completely different pin assignments.

The arduino-nrf5 cannot address different devices. This is the reason I like to use different programmers. I can connect two devices and address them by choosing another programmer.

@scalz said in MySensors NRF5 Platform:

I have not tested battery performance for the moment.. NRF52 is capable of very low power but i think the low power is not enabled yet in the porting, it's explained in the project prez if i remember

Low power in implemented at the MySensors side. There is an issue at the Arduino side -> MySensors NRF5 Platform

Edit: The radio is saving power in some states. There is a little room for improvments like fast rampup for nRF52. With an NRF24 incompatible protocol there is room for improvements.

@mfalkvidd With "./configure --my-transport=nrf24 --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttyMySensors2Gateway --spi-driver=SPIDEV --my-signing=software --my-signing-request-signatures" I can compile on my x86 machine.

Now, I can write some code to check the generated random data.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

Has anyone seen anything else which is that small or even smaller?

Yes. 9x9mm with antenna: https://de.aliexpress.com/store/product/PTR5628-Nordic-nRF52832-Module-BLE-4-0-Module-Free-shipping/130096_32760971926.html but photo and product description are different. I had a discussion with the manufacterer end of 2016 at this time the module was shown as 9*9mm module. The PTR5628 has no 32kHz oscillator, you have to use the unprecise RC oscillator.

@d00616 I found the current issue is a problem only with older nRF51 hardware. I can't measure the current on with newer nRF51 or nRF52 chips. But a fix is documented in http://infocenter.nordicsemi.com/pdf/nRF51822-pan_v3.0.pdf (s. PAN #39)

I have checked the hwGetentropy() on my x86 Linux. When https://github.com/mysensors/MySensors/pull/830 is merged, I create a new Pull Request.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

Which library is most recommended for exploiting the RTC that's on an nRF52832? Likewise, what's the best library for sleeping the nRF52832? Since I have the DK, I'd like to take some current measurements while running some demo code for that. That will establish a baseline for comparing future measurements.

Sleeping is implemented by hwSleep(). This function uses one RTC. If you need advanced RTC access, you have to cooperate with this RTC, because the interrupt routine must reset the state registers. On nRF51 the other RTC is used for millis(). The nRF52 has one RTC free.

@scalz Have you checked if there is a difference in range between NRF5_1MBPS and NRF5_BLE_1MBPS data rate?

@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.

@NeverDie said in Minimalist SAMD21 TQFP32 Pro Mini:

So, what's the smallest nRF52 module that also includes a 32Khz crystal? I think I might want to standardize as much as possible on a single module rather than juggle a bunch of different ones.

I have found the Raytec Modules. http://www.raytac.com/products.php?id=1
The smallest one is the MDBT42V 8,4x6,4x1,5mm with PCB antenna and 80m range in open space.

This module https://www.mtmtech.com.tw/M905.html is 6.5 ✕ 6.5 x 1.1 mm

@scalz You don't need to change your design for me

This is another concept for windows.
http://www.eq-3.com/products/homematic/heating-and-climate-control/homematic-wireless-window-rotary-handle-sensor.html

@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).

@Nca78 said in Minimalist SAMD21 TQFP32 Pro Mini:

Has anyone noticed that a bunch of cheap Chinese "smart bands" use a nrf51822 ?

Yes. There are people working with it. Please read the discussion at github. There are watches with non nordic chips.

https://github.com/sandeepmistry/arduino-nRF5/issues/165

There are a lot of other hardware like the Noke Lock

Or the iStubb 2 with integrated stop up converter (maybe inductor + software) which works with 0.9V.

I have added a note at the end of the installation documentation. To make things easier, I have opened an issue to update the Arduino-nRF5 release.

https://github.com/sandeepmistry/arduino-nRF5/issues/182

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

Sleeping until pin interrupt consumes 1mA -> https://github.com/sandeepmistry/arduino-nRF5/issues/153

I have found some documentation. The high current consumption was listed as PAN#39 and is fixed with this MCU: http://infocenter.nordicsemi.com/pdf/nRF51822-pan_v3.0.pdf

The MCU is nRF51822QFAAH0.

@NeverDie said in nRF5 Bluetooth action!:

If we upload to an nRF52840 the current mysensors demo code examples for an nRF52832, will it work? Anyone tried it?

The 52840 is currently unsupported:
https://github.com/sandeepmistry/arduino-nRF5/issues/70

You can try the source code from: https://github.com/lpercifield/arduino-nRF5/tree/nrf52840

I2C should be fixed now. Version 0.4.0 is released!

@gohan said in Where to get legit nRF24L01+ modules?:

You have to think about those people that aren't developers and rely only on guides of setups that are proven to work well and for simple battery powered sensors you don't need that much processor power

Not really. This was an answer to @Bogus-Exception, who thinks about chip replacing.

@NeverDie The "Taida Century nRF52 minidev" has a lot of pins mapped out:
https://github.com/RIOT-OS/RIOT/wiki/Board%3A-nRF52-minidev you can select the programmer like your needs. The RedBear BLE Blend 2 has also a lot of pins mapped out, but the CMSIS-DAP is preselected.

@NeverDie said in MySensors NRF5 Platform:

BTW, I'm using the Windows version of Arduino IDE 1.8.5, which is the most current.

I don't know the correct path on an Windows system. On my system the Sketches are in the ~/Arduino folder in my home directory (~). The arduino-nrf5 is in ~/.arduino15/packages/sandeepmistry/hardware/nRF5/0.4.0 and the ArduinoHwNRF5 files are in ~/.arduino15/packages/MySensors/hardware/nRF5/0.2.1

@gohan said in Where to get legit nRF24L01+ modules?:

I need to get some nrf24 but I'm unsure to start moving to the nrf5x or not.

IMHO the only missing feature to start is OTA updates. Implementing OTA updates is a question of (my) time. On the other hand the ATMEGA limitations like PROGMEM dealing, 2k RAM or slow speed cannot be fixed. With nRF5 you haven't care about used RAM or Flash. The radio protocol can easily changed to support encryption at the RFM level.

@Mike_Lemo said in nRF5 Bluetooth action!:

@d00616 It says there NFC is not useable but what if my board is NFC hardware ready? how would I use that?

It's simple. Use that. NFC isn't enabled or disabled by the board definition. Without SoftDevice, you have to enable the NFC functionality by flashing into the UICR.

You can define your own Board. Look into the "boards.txt" file and the "variants" folder in ~/.arduino15/packages/sandeepmistry/hardware/nRF5/0.3.0/ Most pins can be assigned to roles like SPI, I2C, UART.... Pins like NFC, RESET are fixed and analog Pins an be ordered like your needs.

@NeverDie said in MySensors NRF5 Platform:

In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

It's a good question about, how to design the API to do this. I have no good idea.
Until an API, you can set MY_HW_RTC->CC[0] to (MY_HW_RTC->COUNTER+2). This ends sleep with some latency.

Some news. After playing with NRF5 and the NRF24 protocol. The red EBYTE modules are fakes.

Over the N of NRF is a dot. I have ordered these modules: https://aliexpress.com/item/Wireless-Module-NRF24L01-original-2-4-Ghz-RF-transceiver-SPI/32712174920.html they have an rectangle over the N and responding line an original NRF24L01. Maybe this helps to identify originals.

The difference between both modules is in NoACK attribute handling. Fakes always responding with ACK and sending inverse NoACK attributes. So fakes have problems communicate with original modules.

EDIT: This was an issue at the NRF5 side.

@NeverDie said in nRF5 Bluetooth action!:

My understanding (which may be wrong) is that in this context a "softdevice" is a veiled reference to the bluetooth stack and/or related bluetooth code, which at present the mysensors code isn't using. In any case, when I programmed both the adafruit and the sparkfun using the mysensors code, I didn't include a chip identifier in a list, nor any soft devices, and it worked anyway.

I haven't tested MySensors with a present SoftDevice. The drivers/NVM code (EEPROM emulation) conflicts with the DFU bootloader.

It's better to see the SoftDevice as an Operating System providing BLE functionality and some hardware abstraction, while MySensors is directly ported to the hardware.

@d00616 said in MySensors NRF5 Platform:
Back from the compiler hell. There is no chance getting the GCC 4.8 to work without forking the arduino-nrf5 code. Compiling with GCC 4.8 has the same result.

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.

@gohan said in Where to get legit nRF24L01+ modules?:

how did you setup NRF5 "sniffer" ?

At the moment, I reimplement the protocol for NRF5 chips to fix an NRF5 hardware issue. I don't have a "sniffer".

BTW, my red modules are working really great; the link you provided from aliexpress are really genuine?

My red modules are good working clones, but they are clones which violating the protocol. Using clones resulting in sending more packages over the air and never receiving an ACK package from original NRF24. So it looks like a duck, but not quacks like a duck over the air.

EDIT: Sorry, Cannot identify clones at the moment.

@NeverDie said in nRF5 Bluetooth action!:

So, now the next question is whether the Ebyte nRF52832 can be made to run in DCDC mode, instead of LDO mode, to make it more suited for battery operation. However, at the moment, I'm not even sure how big or small a power savings that would equate to. Anyone know?

There is no DCDC support for ESB radio at the moment. The DCDC mode is only efficient on high current states, like enabled radio and should only enabled in an defined voltage range.

@monte said in MySensors NRF5 Platform:

Hello, @d00616. Could you tell me which ESB library did you use to port it to arduino environment? The one that comes with Nordic SDK? After searching for few hours I haven't find any other realization of ESB mode for arduino IDE except your port included with MySensors. It's a pity. Are you going to release general purpose library, maybe?

The ESB library is written from scratch. At the time of of starting the Nordic SDK license was incompatible with open source projects. I have no plans to release this as stand-alone library. At the moment there is only an subset of the ESB protocol implemented. Enough to be compatible with MySensors RF24 devices.

Feel free to use my code to create a stand-alone library. If required, we can talk about dual licensing to code with an additional open source license.

Sorry for my NRF24 clone post yesterday. The ACK bit was an issue with the NRF5 platform. I had switched the memory region to handle TX/RX/ACK packages separately. Sometimes the received packages are written in the wrong region. I had seen my testing ACK bit. Now, I have changed my NRF5 code and I can't see no difference between the modules, I have. ACK and timing are exactly at the same level.

I have found a simple way to mass erase the MCU. Select "None" as SoftDevice and use the "Burn Bootloader" function. There is an error generated but the device is erased.

@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.

@icmathad said in How to make radio ESB disable:

how to make radio ESB mode disable in MySensor API. please help me out.

If you mean to switch between BLE and ESB. This is not possible at the moment.

The function call to disable the SoftDevice is not available with the arduino-nrf5 port. This is required to release the radio interrupt. This function call is available with the Arduino Primo port.

If you are using the NRF51 the used RTC for sleep() is conflicting with the SoftDevice. The SoftDevice must be disabled before sleep(). The NRF52 comes with an additional RTC, which is used for sleep().

The most blocking reason the SoftDevice is unsupported is the arduino-NVM library, required as EEPROM emulation. This library isn't using the SoftDevice API for flash access. The library blocks the program flow, if a SoftDevice is present. I had invested some time without luck. I don't know why.

Pull requests are welcome.

@d00616 said in nRF5 Bluetooth action!:

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

Merged. Have fun with board definition in your sketch.

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

That's all I can think of right now

That's most complete.

Looking at the most modern MCU's (nRF51, nRF52, CC1350, EFR32BG13P733) with integrated radio mostly AES-CCM is available as hardware component. With AES-CCM encryption and authentication is available. AES-CCM is part of the BLE specification. I think this type of MCU's are the future and the time of 8 Bit MCUs with external radio modules are mostly over. The nRF5 MCU's are compatible with MySensors starting with release 2.2.

In my personal opinion AES-CCM is a good choice for battery powered nodes, but I think it's no problem to accept other security schemes.

@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.

@NeverDie said in nRF5 Bluetooth action!:

Apparently a system reset doesn't change the values in the reset registers.

The "Reset" menu was from my first approach creating user manageable boards for arduino-nrf5. I haven' tested it. With the reset menu I set the "-DCONFIG_GPIO_AS_PINRESET" option. This option should be processed in "cores/nRF5/SDK/components/toolchain/system_nrf52.c". If not the SystemInit() function is not processed in the startup code. This is a problem handling the chip errata. I have not time to check this at the moment.

Here is a PR which want to enable reset as default: https://github.com/sandeepmistry/arduino-nRF5/pull/91

@NeverDie I don't know why the println() doesn't work. There is an "DEBUG_OUTPUT(x, ##VA_ARGS)" macro, you can use when debug is enabled.

NRF_ADC is the nRF51 ADC and NRF_SAADC is the ADC of the nRF52. They are defined when "nrf.h" is included.

What board type have use used for your tests?

@NeverDie said in nRF5 Bluetooth action!:

I tried this function call on an nRF52 DK, and it seems to work. I then tried it on an Ebyte module, treated as an nRF52 DK "board", and it reported zero voltage.

I have tried the hwCPUVoltage() function with an Ebyte and an RedBear module. Both modules are reporting the voltage.

@NeverDie said in nRF5 Bluetooth action!:

That's good news. There must be something wrong with how I'm doing it. Which board type are you using for the Ebyte module?

I have the equal module like yours.

@NeverDie said in nRF5 Bluetooth action!:

@d00616 Would you please share the pin mappings and board type that you are using for your ebyte module? Since you are having success, I think that will fix the problem.

The module is connected to SWDIO/CLK, VCC and the GND near the radio. I don't remember which pin I used for Serial TX.

@NeverDie said in nRF5 Bluetooth action!:

Does the nRF52 mcu communicate with its radio using SPI, or some other bus? Or are all the radio registers simply memory mapped?

The registers are memory mapped, the data transferred with "EasyDMA" into the memory.

@NeverDie said in nRF5 Bluetooth action!:

I've confirmed it now. Even if I comment out all apparent radio message sends, the mere act of including: '#include <MySensors.h>' results in a loss of control by the sketch itself to something within MySensors that wants to establish communication between the node and the gateway.

The SecurityPersonalizer defines '#define MY_CORE_ONLY' before including 'MySensors.h'. In theory, you can use the radio functions defined in 'hal/transport/MyTransportHAL.h' directly. I had no luck with this, but I haven't invested time to debug this.

@Mike_Lemo said in nRF5 Bluetooth action!:

I want to define the enforcer for the pins within their dedicated sketches without running around to the internal arduino files and change the pin assignment for each upload to each board.
How'd I do that? I assume you'd have to do some thing like that in the upper side of the personal code.
#define SDL...(Something else I don't know ) 11
#define SDA...(Something else I don't know ) 12

You have to install the "MySensors nRF5 Boards" package. In the examples section for this package, you can find two files (MyNRF5Board.h + MyNRF5Board.cpp). Add these files to your sketch and compile it using "MyNRF5Board nRF52822" as you board.

@Mike_Lemo said in nRF5 Bluetooth action!:

Well apperantly this function uses a PWM pin at 50% duty but the frequency varies according to the functiong user parameter now I just know how to active a PWM pin at 50% duty but not how to acces the NRF52 registers to change the frequency of the PWM.

The registers are documented in the Infocenter and the bitfields.

I don't realy know how to access the registers you see at the product's PDF and the other process.

To access the registers, you have to add '#include <nrf.h>' to your code. Mostly the hardware is accesses by NRF_HWNAME->REGISTER

Doing PWM is a little bit complex. The code is different for nRF51 and nRF52. Look into wiring_analog_nRF51.c and (wiring_analog_nRF51.c)[https://github.com/sandeepmistry/arduino-nRF5/blob/c98a190eb34c0247eb8e0764a6367c7f9e51d2fc/cores/nRF5/wiring_analog_nRF52.c#L214]

If you clone this code, for nRF52 you have to use another timer, like TIMER2, because you can't define the interrupt routine twice.

@Nca78 said in nRF5 Bluetooth action!:

Does that mean I have to go the long hard way with a bluepill as programmer and openocd ? Anyone has other ideas to unlock and erase the device ?

Select in to Tools menu "None" Softdevice and then "Burn Bootloader". This raises an error but the device is erased completely.

@Mike_Lemo said in nRF5 Bluetooth action!:

I couldn't find that exact "MySensors nRF5 Boards" library you were talking about also what is the purpose of this library anyways?

Follow the instructions for ArduinoBoards and ArduinoHwNRF5

Do you know where can the arduino library folder be found with all the arduino functions?

The arduino-nrf5 port only implements functionality documented in the official Arduino Reference but mostly not more functionality available for SAMD :-(. Additional functionality like BLE or using included hardware must come from external libraries like MySensors.

A good way to implement the tone commands is to fork the arduino-nRF5 repository at github. Change what you need and create an pull request with reference to the Arduino reference. If you inform me about your PR I comment it to increase the chance for acceptance otherwise it's time to maintain an separate fork of this repository.

@Mike_Lemo said in nRF5 Bluetooth action!:

Dunno that whole arduino BRF52832 programming thing seems too complicated just started to learn how to use the nordic SDK with eclipse until a proper solution is found.

The Nordic SDK is more complete than Arduino-nrf5 at the moment, but there is no compatibility with MySensors.

The good news, with SDK 13 the 'Nordic Semiconductor ASA' License was changed. The old ASA was the reason for me to rewrite the complete ESB protocol. Now the license is much less restrictive. I think now the way is open to integrate SDK code into arduino-nrf5 or provide SDK based arduino-libraries.

@NeverDie said in nRF5 Bluetooth action!:

It hasn't been easy, I'll grant you that. I get the impression d00616 probably does most of his work in Linux, and so some of the disconnect with the Windows IDE probably stems from that.

I can't change the way of Windows driver handling, but when there are Windows specific issues then they bust be fixed.

@NeverDie said in nRF5 Bluetooth action!:

So, generalizing, I suspect that the reference voltage for analogRead() is Vcc-0.3.

The internal reference is 0.6V the nRF5 MCU's have an internal programmable divider. With Arduino this divider is programmed to 1/5. If you switch to the external reference the "gain" is 1/4.

I measure with my CDEByte 11-15µA for sleep without interrupt waiting. With a RedBear BLE Nano 2 I have measured 15µA. Both compiled as BLE Nano 2. I have used the VC165 multimeter.

@NeverDie said in nRF5 Bluetooth action!:

Is there a mysensors demo sketch that involves i2c? I could try it on my end, though I expect I'd probably get the same as you.

I have used I2C with an display and u8g2 without any problem.

@NeverDie said in nRF5 Bluetooth action!:

I have one unused infor-link module left. I'll try wiring it up, but without the input pins this time, and measure it. I'm wondering now whether the sleep current will measure out to be 60ua, or 6ua

With the nRF51 there is an bug, after using the debug interface the current consumption is higher until reset.

@NeverDie said in nRF5 Bluetooth action!:

I think a high priority is to get the DCDC working on the nRF52.

You can try to do this:
#include <nrf.h>

...in before()

NRF_POWER->DCDCEN = 1;

@NeverDie said in nRF5 Bluetooth action!:

I should be receiving my nRF51 modules a few days from now. Since they lack a 32K oscillator on the module, which "board" should I program it as?

With the Generic nRF51822 or the MySensors nRF5 boards, you can switch the oscillator via the tools menu. You have to choose the RC oscillator.

@NeverDie said in nRF5 Bluetooth action!:

It's getting too baroque. What I'd really like to have is a short nRF5 library of just the bare essentials (like the MIRF library is for the RF24).

You can take a look into the actual Nordic NRF SDK. There are the ESB library for nRF24 compatible communication.

@NeverDie said in nRF5 Bluetooth action!:

FWIW, range on the tiny nRF51822 does seem compromised when compared against larger sized nRF52832 modules. Not really surprising, but I had hoped it might be a little better than it is.

This is an idea, I don't know if this helps. The two pins near the antenna are GND. Try to solder an 3cm isolated wire to the pin near your PCB and route it parallel of your pcb away from the nRF51 board. The extends the GND pane size.

@rmtucker said in nRF5 Bluetooth action!:

But what is the transportGetSendingRSSI(void)?

This is the RSSI of the receiver. With nRF5 it's part of the ACK payload.

@NeverDie said in nRF5 Bluetooth action!:

Where is the sleep(...) function defined for the nrf5? I've looked, but I can't seem to find which library it is in. Anyone know?

It's defined in "hal/architecture/MyHwNRF5.cpp"

@NeverDie said in nRF5 Bluetooth action!:

Yeah, MySensors can definitely do it. Nice work @d00616 !
Thanks.

It turns out that with RadioHead, I am almost able to send packets from an nRF24L01 to an nRF5 module: it's just that the packets arrive as garbage. So, the packet and/or frame formatting must be different, but indeed the network ID's are matching or else I wouldn't be receiving anything at all.

The ID's are reversed between nRF5 and nRF24. Look into the code how to reverse the ID's.

@NeverDie said in nRF5 Bluetooth action!:

I found the smoking gun in the radiohead documentation. Turns out RadioHead does indeed use a different packet format for the nRF5 that is "NOT compatible with the one used by RH_NRF24 and the nRF24L01 product specification, mainly because the nRF24 only supports 6 bits of message length."

You have to choose the correct number of bits for length, S0 and S1. I have played a while to find out the correct configuration. When ACK is enabled you have to do a lot of timing work.

@Terrence said in nRF5 Bluetooth action!:

@NeverDie Ya, that really sucks. It would have been great to mix and match.

At the moment I have no opinion to the "GPL or commercial" license of Readiohead. So I have no plans to port my Code .

The Nordic SDK has an ESB library supporting the nRF24 mode. IMHO Starting with SDK 13 the license is more Open Source friendly.

@NeverDie said in nRF5 Bluetooth action!:

What more can be done to reduce current consumption on an nRF52832 when the MySensors "sleep" function is being used with RTC wakeup. I've measured a 300mv drop on a 10F capacitor over a 12 hour time period. Of that 300mv, perhaps 20mv was lost due to self-discharge of the supercap. So, that still leaves 280mv of loss due to the nRF52832 . That is too high a rate of loss.

Wh = 0.5 * 10F * 280mV = 0.392 Wh = 0.0326667 W
I=0.0326667/2.56V = 12.76mA

Looks like the node is most time fully active.

@NeverDie said in nRF5 Bluetooth action!:

I had wrongly assumed that the "sleep(...)" command would sleep the radio. Thanks for pointing out my error. How/when is it that Mysensors puts the radio to sleep? Does it just happen automatically at the end of every sending/receiving?

We are both not 100% correct The hwSleep() function doesn't disable the radio, but the sleep() function does it, when MY_SENSOR_NETWORK is defined.

After Sleep transportReInitialise() is called. Then you have to initialize RadioHead again.

@rmtucker said in nRF5 Bluetooth action!:

Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.

The sleep() function is now more precise for sleeping <512s:

https://github.com/mysensors/MySensors/pull/909

The PR is waiting for merge.

@rmtucker said in nRF5 Bluetooth action!:

I can not understand why you are drawing 9.4uA in the first place?.
My nrf51822 seems to consistently only draw 4-5uA with no strip down of software when in mysensors sleep mode.

While developing the nRF5 port, I had no chance to measure the current of the nRF52 accurate. With my original nRF51 dev kit I I have a sleeping current matching the data sheet.

Now I can measure currents in the µA range. With all nRF52 I have, I measured sleeping currents around 10µA. This is to much. We have to see 2-3µA. I have no original nRF52832 dev kit to compare. The reason of this sleeping current can be either an error in the layout or there is a component which is not required in active state while sleeping.

At the moment I have no time to analyse this. There is a bug in the radio code, which I have to fix. When transport debug is disabled no packages are received. In my opinion this has more priority.

@NeverDie said in nRF5 Bluetooth action!:

Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.
[Edit: Setting it to HIGH also helps similarly.]

Thank's. I check this after I fixed the Radio.

Actually, I have this board running. I measure a voltage of 0.13mV=6,6µA at the shunt with a simple sleep sketch. When I switch two pins into INPUT_PULLUP, then I measure 0.15mV==7,5µA.

When I switch on the LED then I measure 12.75mV == 0,6375mA, One pin in OUTPUT_H1H0 mode. With LED off I measure 0.15mV==7,5µA.

My MCU is nRF52832 QFAAB0 1615AX

P.S.: I have no documentation about the board. When I measure the boards current, then I have an shunt factor of 22,5. I think calculating with 20 is ok.

@NeverDie said in nRF5 Bluetooth action!:

Thanks! I just now ordered one of your boards so that in the future we can share a common platform for comparing numbers.

Ok. I have measured my Ebyte with the same sketch and in the µA range of my VC165 multimeter. Sleep current is 9.9µA with two ports in INPUT_PULLUP and one Port in OUTPUT_H0H1 mode. (b.t.w. this module costs actually 3,82€)

@scalz said in nRF5 Bluetooth action!:

in that case, you need to set it as a floating input i think, like it's generally at reset.
In datasheet, section 20 (p111), is explained how works the GPIO. You have a Bit for disconnecting it. See the PIN_CNF[n] registers. For instance, p.140, you can see how it looks for the P0.10, and the Bit 1.
This should do the job..

Should I add a DISCONNECTED mode to hwPinMode()?

@NeverDie said in nRF5 Bluetooth action!:

As a follow-up to rmtucker's line of inquiry, what is currently the shortest deep sleep that's supported? Is it one millisecond, or something else?

Why do you need this type of short sleeps?

Sleep is for battery powered devices. A device that wakes up more than 1000 times in the second might be hard to drive with a battery.

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie
Theoretically it is 2 clock ticks at 32768khz so 0.000061035secs i think.

This is correct.

But how long it takes to go into sleep mode and come out of sleep mode i am not sure.

It's simple to evaluate with micros() before and after a sleep().