nRF5 action!
-
I posted the files for a remote control based on the power amplified nRF52832:
https://www.openhardware.io/view/482 -
I posted the files for a remote control based on the power amplified nRF52832:
https://www.openhardware.io/view/482 -
@NeverDie @mfalkvidd : Thnx!,,
@NeverDie ; what do you mean with gamechanger? a completely new standard? will it be able to talk with the nrf24 like the nrf52382, of do you need to start all over again with a blank sheet?
@Omemanti said in nRF5 Bluetooth action!:
@NeverDie ; what do you mean with gamechanger?
Oh, and let's not forget the Bluetooth 5 capabilities of these chips, which I expect will allow the leverage of a lot of other bluetooth devices. Despite the title of this thread, we've barely even scratched the surface on that topic (yet). I'm looking forward to it.
-
@Omemanti said in nRF5 Bluetooth action!:
@NeverDie ; what do you mean with gamechanger?
Oh, and let's not forget the Bluetooth 5 capabilities of these chips, which I expect will allow the leverage of a lot of other bluetooth devices. Despite the title of this thread, we've barely even scratched the surface on that topic (yet). I'm looking forward to it.
@NeverDie The really nice thing about the nRF52832 and other nRF52 variants is that running the BTLE stack (Softdevice ) you can run BTLE and proprietary somewhat simultaneously. You choose where you want to have them running this. Each node or just one for Smart Device connectivity.
-
I don't think it will be either/or. It will be both. Pricing will probably favor the 52832. I'm even intrigued by the 51822, because you can buy it on a breakout for around $2.50, and it's very small, complete with a very small pcb antenna. I mean, where else can you find a complete system for that little money on such a small size? You can fit it in practically anywhere.
@NeverDie said in nRF5 Bluetooth action!:
you can buy it on a breakout for around $2.50
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-))) -
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.
@d00616 absolutely excellent summary, thank you.We definitelly needed some kind of "what do we know so far"
Is it confirmed that the range and power consumption are on par with 328+24L01 combo? I don't mean any "scientific" proof, but something like "I have placed nrf52 node at the same location in my house as nrf24 node and had no issues"
I am awaiting components to make "u-current meter" and test current consumption by myself -
@NeverDie said in nRF5 Bluetooth action!:
you can buy it on a breakout for around $2.50
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))@Toyman said in nRF5 Bluetooth action!:
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))Type nrf51822-04 in AliExpress search bar, you will find the cheapest module. Not many pins broken out because it's supposed to be used as a Bluetooth interface, but it's enough for many applications like door sensor, switches, etc etc
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html -
@Toyman said in nRF5 Bluetooth action!:
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))Type nrf51822-04 in AliExpress search bar, you will find the cheapest module. Not many pins broken out because it's supposed to be used as a Bluetooth interface, but it's enough for many applications like door sensor, switches, etc etc
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html -
@d00616 absolutely excellent summary, thank you.We definitelly needed some kind of "what do we know so far"
Is it confirmed that the range and power consumption are on par with 328+24L01 combo? I don't mean any "scientific" proof, but something like "I have placed nrf52 node at the same location in my house as nrf24 node and had no issues"
I am awaiting components to make "u-current meter" and test current consumption by myself@Toyman said in nRF5 Bluetooth action!:
Is it confirmed that the range and power consumption are on par with 328+24L01 combo?
Yes, it's better in both dimensions.
-
@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.
Where are the long range BLE modes? I think long range BLE modes are one of the best features of the 840 series.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.
Where are the long range BLE modes? I think long range BLE modes are one of the best features of the 840 series.
-
@Toyman said in nRF5 Bluetooth action!:
do you have an example? The lowest I can find is ca. $4 (incl.S&H).
Don't get me wrong, $4 is more then adequate for 328+24L01 replacement, but $2.5 is even better :-)))Type nrf51822-04 in AliExpress search bar, you will find the cheapest module. Not many pins broken out because it's supposed to be used as a Bluetooth interface, but it's enough for many applications like door sensor, switches, etc etc
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html@Nca78
I just now posted a small breakout board for it: https://www.openhardware.io/view/483 -
What's the proper way to deal with interrupts on nrf?
Many white areas:- shall I use "smartsleep()" instead of usual arduino way of attaching interrupts? is it enough?
- what pins have hardware interrupts? any?
- what about the macro mentioned in d00016 readme?
- how to overcome nrf51 bug of 1ma power consumption (code-wise)? Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping
I thoroughly read al the docs before asking!
-
What's the proper way to deal with interrupts on nrf?
Many white areas:- shall I use "smartsleep()" instead of usual arduino way of attaching interrupts? is it enough?
- what pins have hardware interrupts? any?
- what about the macro mentioned in d00016 readme?
- how to overcome nrf51 bug of 1ma power consumption (code-wise)? Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping
I thoroughly read al the docs before asking!
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Welcome to the bleeding edge. I'm only aware of the one way, which is how @d00616 does it in his example code above. It seems like this part of the code is still (?) under development. For instance, the HW supports multiple interrupts being active at the same time, whereas the current code seems to support at most one interrupt.
-
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Welcome to the bleeding edge. I'm only aware of the one way, which is how @d00616 does it in his example code above. It seems like this part of the code is still (?) under development. For instance, the HW supports multiple interrupts being active at the same time, whereas the current code seems to support at most one interrupt.
-
I made this adapter to aid with collecting serial debug output from the last two nRF5 breakout boards:
https://www.openhardware.io/view/484/IDC-10-pin-ARM-debug-adapter -
What's the proper way to deal with interrupts on nrf?
Many white areas:- shall I use "smartsleep()" instead of usual arduino way of attaching interrupts? is it enough?
- what pins have hardware interrupts? any?
- what about the macro mentioned in d00016 readme?
- how to overcome nrf51 bug of 1ma power consumption (code-wise)? Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping
I thoroughly read al the docs before asking!
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Many white areas:what pins have hardware interrupts? any?
There is an limit in the number of monitored pins but not which pins are monitored.
what about the macro mentioned in d00016 readme?
This macro is required on NRF52 to read back event registers in interrupts. This clears the cache.
how to overcome nrf51 bug of 1ma power consumption (code-wise)?
Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleepingThis depends on the nRF51 chip release. The first available chip release has this type of bug. I prefer nRF52 because the chip is much more flexible with better radio characteristics.
The flexibility of nRF5 MCUs starts with the interrupt vector in RAM. This allows to add bootloaders without adding latency or you can replace interrupts which are predefined in the arduino-nrf5 software.
-
@Toyman said in nRF5 Bluetooth action!:
What's the proper way to deal with interrupts on nrf?
Many white areas:what pins have hardware interrupts? any?
There is an limit in the number of monitored pins but not which pins are monitored.
what about the macro mentioned in d00016 readme?
This macro is required on NRF52 to read back event registers in interrupts. This clears the cache.
how to overcome nrf51 bug of 1ma power consumption (code-wise)?
Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleepingThis depends on the nRF51 chip release. The first available chip release has this type of bug. I prefer nRF52 because the chip is much more flexible with better radio characteristics.
The flexibility of nRF5 MCUs starts with the interrupt vector in RAM. This allows to add bootloaders without adding latency or you can replace interrupts which are predefined in the arduino-nrf5 software.
@d00616 said in nRF5 Bluetooth action!:
The first available chip release has this type of bug.
So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?
-
@d00616 said in nRF5 Bluetooth action!:
The first available chip release has this type of bug.
So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
The first available chip release has this type of bug.
So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?
There is a second method via GPIO -> pin sense for interrupt detection. This method requires less power, but you have to detect which pin is changed in software. Simulating a pin change interrupt is more complicated as detecting high or low level. I have started to do some researches and tests, but in my opinion it's to much work to support these outdated chip variants.
-
Motivated by the above, I just now did some current tests on the nRF52832 and found that:
- Going directly to an RTC sleep after powerup consumes 2.2ua.
- Enabling DCDC doesn't increase that.
- Nor does blinking an LED and then putting that pin into a disconnected state (D0) before sleep.
HOWEVER,
4. Activating Serial using Serial.begin(..) before sleep causes the current drain during sleep to rise to around 10.8ua. That was surprising to me, because this code in hwSleep(..) seems geared toward turning OFF serial prior to sleep:// Idle serial device NRF_UART0->TASKS_STOPRX = 1; NRF_UART0->TASKS_STOPTX = 1; NRF_UART0->TASKS_SUSPEND = 1;So, I guess more is needed there?
