💬 MySensors NRF5 Platform

[Anticimex]

@d00616 yes I agree that protocol compatibility is priority. I just wanted to point out the current flaws with that encryption but you obviously know what you are doing :)
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.

[scalz]

@d00616
oki. i'll try to do some range tests, and your PR too! when i'll get more time :)
Would be nice if they would release a better package footprint for the 840..I said this because i've seen Fanstel is selling modules but not so cheap, so i prefer to wait a bit.
And i agree with you the 832 is already very nice, even if 840 has some nice feature.

[d00616]

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

[Anticimex]

@d00616 I don't see how this relate to the signing solution we use. We use HMAC-SHA256. We already have hw support for this in the atsha204a. There is no plan to replace this.
Encryption is also already existing in certain radios already (like the rfm69). So it will in a sense always be radio specific and needs to be in order to be effective.

[d00616]

@Anticimex Ok.

[Anticimex]

@d00616 I don't however see it as a problem if you implement some underlying security solution specific to nrf5 as long as it don't require protocol "awareness". That's just a bonus so feel free to have a look at that. But things will quite fast become quite messy if we start mixing security schemes in the protocol.
The signing backend does have versioning support so it is possible to extend it with new schemes, but so far the scheme we use is supported across all radio variants and it would be a pity to give up that compatibility unless the new scheme offer some improvement over the current one.
The main drawback with the current one is the message size limitation imposed by the current protocol version which forces us to truncate the signatures but in version 3 of the MySensors protocol, this limitation will be overcome by protocol upgrades.

[d00616]

@Anticimex At the moment I have other priorities than implementing another security solution or protocol for NRF5. Another protocol can be implemented as a second radio driver including breaking the NRF24 compatibility with larger packet sizes and protocol optimization.

[Anticimex]

@d00616 with v3 the protocol backwards compatibility will be broken nevertheless in a way which will support the current generic security protocol fully across all radio transports.
But there are basically two layers. A mysensors layer where signing is handled using HMAC-SHA256 with nonce exchange, timeouts, lock detection and whitelisting. A rf specific layer can implement additional security solutions (typically encryption) that work transparently with the MySensors protocol. For signing, it is probably not needed as we already have that in place, but encryption could be a relevant feature for the lower level layers.

[mtiutiu]

@d00616

Hi,

This is a such great addition for this project. For long time I wanted something like this: a RF SOC with pretty good and usable software support and low power also(and a Cortex arch - pff..that's too much :simple_smile: ). I just wanted to congratulate you for your work and bringing this in to MySensors project - it's very neat and useful.

I tested it and it works just great so far. I would give you 100 likes on openhardware.io if it would be possible :simple_smile: . Thanks once again for your effort.

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

[ileneken3]

Congratulations on winning the contest. That convinces me to give it a try.
Even though this has been available for months, I'm not seeing much discussion on:

• Improvements on range.
• The best module to purchase for the simplest nodes - like temperature.
• Battery performance.

Anyone have feedback on those yet?

Thanks ahead of time

[scalz]

@ileneken3
I'm having some fun with @d00616 work :) And it's working fine so far (thx again).

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

Regarding range, sure NRF52 is an improved chip compared to NRF24 for instance, but the most important part is the antenna. That's the case for all mcu though. Take a long range capable mcu and a bad antenna choice, or a bad antenna design (bad gnd plane, bad clearance for antenna etc) and you'll never get the long range (example: miniaturized chip antenna, or some pcb antennas too).

For the simplest devices to buy, no idea as i'm making custom boards.

[d00616]

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

[d00616]

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

[d00616]

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

[scalz]

@d00616 thx for the info :+1:
I'll try to measure power consumption asap

[NeverDie]

FWIW, you may want to delete this passage in your overview, as it's not really accurate:

Don't buy an nRF5 development kit to program other nRF5 modules. The programmer is hard wired to the nRF5 chip on most DK boards.

In fact, Nordic has this video that I just now came across on how to do it:
https://www.youtube.com/watch?v=n6sNDnRA6BY

IMHO, I think the DK is a good way for noobs to get started, because the setup is well supported for the onboard nRF52 and "just works." The fact that it can later be used to program external nRF5 devices is a nice (and very poorly advertised) bonus. The DK has a real Segger J-Link on the DK board.

That being said, the DK is not the cheapest option, so noobs may need to weigh "easy" vs "cheap" in their purchase decision.

[rmtucker]

I am having problems compiling the Mockmysensors example on the waveshare board.

If you comment out all sensors and uncomment
#define ID_S_MULTIMETER 28

I get the following error:
exit status 1
call of overloaded 'set(int&)' is ambiguous

[NeverDie]

@rmtucker said in 💬 MySensors NRF5 Platform:

I am having problems compiling the Mockmysensors example on the waveshare board.

If you comment out all sensors and uncomment
#define ID_S_MULTIMETER 28

I get the following error:
exit status 1
call of overloaded 'set(int&)' is ambiguous

Did you remember to do this?

// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_NRF5_ESB

[rmtucker]

@NeverDie
Yes did that.
Strange though if you run the sketch with just the first 2 sensors uncommented it compiles fine.
It must me something to do with multimeter?