nRF5 action!
-
@ncollins The sandeepmitry library has incomplete coverage, but what it does provide is access to the nRF5 registers. From there you can do whatever it is that you want to do by manipulating the registers directly. That makes it closer to assembly language, at least in thought process, than the confortable arduino library support you may be accustomed to.
I haven't tracked the arduino or adafruit implementations. Maybe by now they have better library support? Alternatively, mbed and sager and probably others have their own library support for it, so there's always that which you can look into. Come to think of it, IIRC, Arduino simply adopted the mbed platform for the nRF52 rather than roll their own, which was a rather unusual move. That may mean it may never be completely "arduino" in the same way other arduino platforms are. -
@NeverDie I see.
Say the Arduino mbed route supports my nRF module, would MySensors library need to be rewritten? Any idea how coupled it is to the sandeepmistry core?
-
@monte thanks
I'm struggling with choosing the direction of the next steps in my diy sensor journey.
My focus has moved exclusively to nRF5 boards given the compact size, performance, and cost. I don't have range, penetration, or interference concerns, so I don't utilize any of the LoRa support in MySensors.
Given the ubiquitous support of BLE, recent advancements in mesh and long range capabilities, continued investment, widespread adoption...it might make more sense for someone with my use case to explore moving to a BLE based network.
I'm assuming there isn't much to gain by layering MySensors on top of BLE. And I'm not sure it makes sense for the MySensors community to expand and maintain support for boards capable of MySensors use, but primarily intended for BLE use. Especially, considering a significant majority of the community is completely satisfied with ATMEGA + (NRF24 / LoRa).
-
@monte thanks
I'm struggling with choosing the direction of the next steps in my diy sensor journey.
My focus has moved exclusively to nRF5 boards given the compact size, performance, and cost. I don't have range, penetration, or interference concerns, so I don't utilize any of the LoRa support in MySensors.
Given the ubiquitous support of BLE, recent advancements in mesh and long range capabilities, continued investment, widespread adoption...it might make more sense for someone with my use case to explore moving to a BLE based network.
I'm assuming there isn't much to gain by layering MySensors on top of BLE. And I'm not sure it makes sense for the MySensors community to expand and maintain support for boards capable of MySensors use, but primarily intended for BLE use. Especially, considering a significant majority of the community is completely satisfied with ATMEGA + (NRF24 / LoRa).
@ncollins If you have the gumption to do it, it might open up some interesting new possibilities. In the past programming bluetooth was a bit daunting, but it seems like some of the newer tools may be easier to learn: e.g. https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api
-
@ncollins If you have the gumption to do it, it might open up some interesting new possibilities. In the past programming bluetooth was a bit daunting, but it seems like some of the newer tools may be easier to learn: e.g. https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api
@NeverDie said in nRF5 action!:
https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api
Ha, I ordered one yesterday. I'll mess around and report back.
-
@Charall For MySensors NRF5, start with these:
https://forum.mysensors.org/topic/6705/mysensors-nrf5-platform
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners -
Just started testing my new NRF52805 breakout board. I added a new generic variant to sandeepmistry/arduino-nRF5, added a new board to mysensors nRF5, now I'm testing compatibility.
This new NRF52805 chip is interesting. Way stripped down compared to the rest of the NRF5 line. No PWM, no LPCOMP, only 10 GPIO (maybe 8 usable).
But, it's cheap, ~$2.50 for the EBYTE BT104-BT5005 module, compact, and appropriate for most low-power use cases.
Interestingly, the chip does not support the current MySensors default, but deprecated, data rate of 250Kbps. Today I also learned that modules can only communicate on the same data rate. So I created a ESP8266 + NRF24L01+ gateway at MY_RF24_DATARATE RF24_1MBPS, and it worked!
Still need to test a few things:
- I2C
- SPI
- Power consumption
If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.
-
@ncollins If you have the gumption to do it, it might open up some interesting new possibilities. In the past programming bluetooth was a bit daunting, but it seems like some of the newer tools may be easier to learn: e.g. https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api
@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.
Some things I learned:
- BLE is a great way for low power communication with a dedicated, physically close parent node
- BLE alone does not establish a network, just a link to a central/gateway node. Giving the limited range, that means having multiple gateways, and dedicated links (painful, inflexible)
- That led to the creation of BLE Mesh. I found this article from Integra Sources to be really helpful as they talk through the real world limitations they experienced trying to go to production with it. In summary, BLE Mesh is a "managed flood" which quickly leads to network storms if not optimized
- Then I found OpenThread
- After messing around for few days, I found this guide https://github.com/kyberpunk/openthread which really simplifies getting started. Two docker containers: OpenThread Border Router (sensor network gateway) and MQTT-SN (UDP6 MQTT bridge to MQTT Broker). I was able to setup a network with two NRF52840 dongles + NRF52840 DK, and post messages to my MQTT instance within a couple of hours.
OpenThread is supported on the the NRF52840, NRF52811, NRF52833, as well as 10-15 chips from other vendors.
I really like the ability to route via IP and the fact that all of the nodes communicate with common, well known protocols. I like the secure-by-default approach, and the built in tools for administering networks (commissioning new nodes).
I'm going to keep exploring this route, seems promising....
-
Update on my NRF52805 Breakout:
- I2C is now working, just a few small changes to select the right interface
- Power consumption looks good, around 1.8uA. The Si7021 module is reading 2.5uA in isolation.
Just need to test SPI and figure out a clever name for the board, and should be good to go.
-
Just started testing my new NRF52805 breakout board. I added a new generic variant to sandeepmistry/arduino-nRF5, added a new board to mysensors nRF5, now I'm testing compatibility.
This new NRF52805 chip is interesting. Way stripped down compared to the rest of the NRF5 line. No PWM, no LPCOMP, only 10 GPIO (maybe 8 usable).
But, it's cheap, ~$2.50 for the EBYTE BT104-BT5005 module, compact, and appropriate for most low-power use cases.
Interestingly, the chip does not support the current MySensors default, but deprecated, data rate of 250Kbps. Today I also learned that modules can only communicate on the same data rate. So I created a ESP8266 + NRF24L01+ gateway at MY_RF24_DATARATE RF24_1MBPS, and it worked!
Still need to test a few things:
- I2C
- SPI
- Power consumption
If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.
@ncollins said in nRF5 action!:
Just started testing my new NRF52805 breakout board. I added a new generic variant to sandeepmistry/arduino-nRF5, added a new board to mysensors nRF5, now I'm testing compatibility.
This new NRF52805 chip is interesting. Way stripped down compared to the rest of the NRF5 line. No PWM, no LPCOMP, only 10 GPIO (maybe 8 usable).
But, it's cheap, ~$2.50 for the EBYTE BT104-BT5005 module, compact, and appropriate for most low-power use cases.
Interestingly, the chip does not support the current MySensors default, but deprecated, data rate of 250Kbps. Today I also learned that modules can only communicate on the same data rate. So I created a ESP8266 + NRF24L01+ gateway at MY_RF24_DATARATE RF24_1MBPS, and it worked!
Still need to test a few things:
- I2C
- SPI
- Power consumption
If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.
Great work! For the gateway you might want to look into Ebyte E01-2G4M27D (https://www.aliexpress.com/item/4000536940861.html?spm=a2g0s.9042311.0.0.60da4c4dGywFPS), which should have better receive sensitivity than the usual nrf24L01 because it includes an LNA.
-
@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.
Some things I learned:
- BLE is a great way for low power communication with a dedicated, physically close parent node
- BLE alone does not establish a network, just a link to a central/gateway node. Giving the limited range, that means having multiple gateways, and dedicated links (painful, inflexible)
- That led to the creation of BLE Mesh. I found this article from Integra Sources to be really helpful as they talk through the real world limitations they experienced trying to go to production with it. In summary, BLE Mesh is a "managed flood" which quickly leads to network storms if not optimized
- Then I found OpenThread
- After messing around for few days, I found this guide https://github.com/kyberpunk/openthread which really simplifies getting started. Two docker containers: OpenThread Border Router (sensor network gateway) and MQTT-SN (UDP6 MQTT bridge to MQTT Broker). I was able to setup a network with two NRF52840 dongles + NRF52840 DK, and post messages to my MQTT instance within a couple of hours.
OpenThread is supported on the the NRF52840, NRF52811, NRF52833, as well as 10-15 chips from other vendors.
I really like the ability to route via IP and the fact that all of the nodes communicate with common, well known protocols. I like the secure-by-default approach, and the built in tools for administering networks (commissioning new nodes).
I'm going to keep exploring this route, seems promising....
@ncollins said in nRF5 action!:
@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.
Some things I learned:
- BLE is a great way for low power communication with a dedicated, physically close parent node
- BLE alone does not establish a network, just a link to a central/gateway node. Giving the limited range, that means having multiple gateways, and dedicated links (painful, inflexible)
- That led to the creation of BLE Mesh. I found this article from Integra Sources to be really helpful as they talk through the real world limitations they experienced trying to go to production with it. In summary, BLE Mesh is a "managed flood" which quickly leads to network storms if not optimized
- Then I found OpenThread
- After messing around for few days, I found this guide https://github.com/kyberpunk/openthread which really simplifies getting started. Two docker containers: OpenThread Border Router (sensor network gateway) and MQTT-SN (UDP6 MQTT bridge to MQTT Broker). I was able to setup a network with two NRF52840 dongles + NRF52840 DK, and post messages to my MQTT instance within a couple of hours.
OpenThread is supported on the the NRF52840, NRF52811, NRF52833, as well as 10-15 chips from other vendors.
I really like the ability to route via IP and the fact that all of the nodes communicate with common, well known protocols. I like the secure-by-default approach, and the built in tools for administering networks (commissioning new nodes).
I'm going to keep exploring this route, seems promising....
Very inspiring! I've had high hopes for Thread, and from your report it sounds like maybe now is a good time to jump in.
-
@ncollins said in nRF5 action!:
Just started testing my new NRF52805 breakout board. I added a new generic variant to sandeepmistry/arduino-nRF5, added a new board to mysensors nRF5, now I'm testing compatibility.
This new NRF52805 chip is interesting. Way stripped down compared to the rest of the NRF5 line. No PWM, no LPCOMP, only 10 GPIO (maybe 8 usable).
But, it's cheap, ~$2.50 for the EBYTE BT104-BT5005 module, compact, and appropriate for most low-power use cases.
Interestingly, the chip does not support the current MySensors default, but deprecated, data rate of 250Kbps. Today I also learned that modules can only communicate on the same data rate. So I created a ESP8266 + NRF24L01+ gateway at MY_RF24_DATARATE RF24_1MBPS, and it worked!
Still need to test a few things:
- I2C
- SPI
- Power consumption
If all goes well, I'll submit the merge requests and publish this board schematic on openhardware sometime in the next week.
Great work! For the gateway you might want to look into Ebyte E01-2G4M27D (https://www.aliexpress.com/item/4000536940861.html?spm=a2g0s.9042311.0.0.60da4c4dGywFPS), which should have better receive sensitivity than the usual nrf24L01 because it includes an LNA.
@NeverDie Thanks, and good call on the Ebyte NRF24 with LNA. I have a few laying around that I've been meaning to incorporate into a generic multi-sensor gateway/repeater node. If they're always connected, might as well collect environment data and maybe motion too.
-
@NeverDie I spent the last week really deep diving into NRF BLE & NRF networking capabilities.
Some things I learned:
- BLE is a great way for low power communication with a dedicated, physically close parent node
- BLE alone does not establish a network, just a link to a central/gateway node. Giving the limited range, that means having multiple gateways, and dedicated links (painful, inflexible)
- That led to the creation of BLE Mesh. I found this article from Integra Sources to be really helpful as they talk through the real world limitations they experienced trying to go to production with it. In summary, BLE Mesh is a "managed flood" which quickly leads to network storms if not optimized
- Then I found OpenThread
- After messing around for few days, I found this guide https://github.com/kyberpunk/openthread which really simplifies getting started. Two docker containers: OpenThread Border Router (sensor network gateway) and MQTT-SN (UDP6 MQTT bridge to MQTT Broker). I was able to setup a network with two NRF52840 dongles + NRF52840 DK, and post messages to my MQTT instance within a couple of hours.
OpenThread is supported on the the NRF52840, NRF52811, NRF52833, as well as 10-15 chips from other vendors.
I really like the ability to route via IP and the fact that all of the nodes communicate with common, well known protocols. I like the secure-by-default approach, and the built in tools for administering networks (commissioning new nodes).
I'm going to keep exploring this route, seems promising....
There's this nice HAT for the Raspberry Pi you might find interesting :) : https://gitlab.com/electronutlabs-public/indrium-pi-hat
On another topic, I would honestly like to see MySensors using OpenThread or BLE Mesh transport...
-
There's this nice HAT for the Raspberry Pi you might find interesting :) : https://gitlab.com/electronutlabs-public/indrium-pi-hat
On another topic, I would honestly like to see MySensors using OpenThread or BLE Mesh transport...
@Avamander That would make a great gateway. I believe I read a getting started guide by the creator of that Pi Hat, Playing with Thread and MQTT-SN on Nordic nRF52840. The tutorial is a little outdated now, but it's a good overview of the process of setting up a Thread network. There is a lot of good content on that blog.
I agree, but it is still not clear to me what the appropriate relationship between MySensors and OT / BLE Mesh is. It seems there is a lot of overlap in functionality. While I prefer to focus on the NRF5 series, a majority of the community is using ATMEGA328 and NRF24, or LoRa modules, which wouldn't support OT / BLE.
At the very least, I'd like to see MySensors tap into some more of the advanced NRF5 capabilities: OTA, NFC.
There are also a few examples of NRF5 modules running in dual mode: BLE + OT. If it's possible to run 2.4GHz + BLE in parallel, then there is potential to create a MySensors bridge device.
Or maybe leveraging BLE to configure MySensor nodes at runtime: modifying sleep duration, send frequency.
Given the abundance of storage and memory on the NRF5 devices, it is also feasible to create something like Tasmota / ESPeasy for MySensors. Use the same firmware on every node, have the MySensors gateway/controller manage and push configuration templates. Given the great work on MySensors NodeManager and the SmartSleep functionality, it seems like the foundation is already in place.
-
@Avamander That would make a great gateway. I believe I read a getting started guide by the creator of that Pi Hat, Playing with Thread and MQTT-SN on Nordic nRF52840. The tutorial is a little outdated now, but it's a good overview of the process of setting up a Thread network. There is a lot of good content on that blog.
I agree, but it is still not clear to me what the appropriate relationship between MySensors and OT / BLE Mesh is. It seems there is a lot of overlap in functionality. While I prefer to focus on the NRF5 series, a majority of the community is using ATMEGA328 and NRF24, or LoRa modules, which wouldn't support OT / BLE.
At the very least, I'd like to see MySensors tap into some more of the advanced NRF5 capabilities: OTA, NFC.
There are also a few examples of NRF5 modules running in dual mode: BLE + OT. If it's possible to run 2.4GHz + BLE in parallel, then there is potential to create a MySensors bridge device.
Or maybe leveraging BLE to configure MySensor nodes at runtime: modifying sleep duration, send frequency.
Given the abundance of storage and memory on the NRF5 devices, it is also feasible to create something like Tasmota / ESPeasy for MySensors. Use the same firmware on every node, have the MySensors gateway/controller manage and push configuration templates. Given the great work on MySensors NodeManager and the SmartSleep functionality, it seems like the foundation is already in place.
I wanted to write that Softdevice and ESB are not compatible for use at the same time, but then decided to fact check myself. Seems like now you can use Softdevice and ESB simultaneously. You can either disable softdevice in program, or use Timeslot API to manage access to radio of different protocols.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fconcurrent_multiprotocol_tsl_api%2Ftsl_usage_examples.html&cp=4_5_3_0_8_2
https://devzone.nordicsemi.com/f/nordic-q-a/55847/priority-level-overlap-between-softdevice-and-esb
https://jimmywongiot.com/2020/06/22/radio-timeslot-api-for-the-multiple-protocols/
If this is doable I can't think of a reason, why mysensors shouldn't use softdevice. -
I wanted to write that Softdevice and ESB are not compatible for use at the same time, but then decided to fact check myself. Seems like now you can use Softdevice and ESB simultaneously. You can either disable softdevice in program, or use Timeslot API to manage access to radio of different protocols.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fconcurrent_multiprotocol_tsl_api%2Ftsl_usage_examples.html&cp=4_5_3_0_8_2
https://devzone.nordicsemi.com/f/nordic-q-a/55847/priority-level-overlap-between-softdevice-and-esb
https://jimmywongiot.com/2020/06/22/radio-timeslot-api-for-the-multiple-protocols/
If this is doable I can't think of a reason, why mysensors shouldn't use softdevice.(Been away for a while, but saw this and thought I should chime in...)
@monte - I can confirm that this is true. I have custom nRF52832 boards with bootloaders and SoftDevices (S132) that are all currently happily running MySensors code too - I needed the bigger memory footprint AND FOTA updates, so...
As you suggest, you have to disable the SoftDevice before MySensors takes ownership of the radio otherwise there are problems. And depending on how/where you stack things, make sure that @d00616's awesome arduino-NVM layer (pseudo-EEPROM implementation) isn't going to write over anything important. I used Adafruit's FreeRTOS implementation as a starting point, but I'm not sure I fully understand what I've done in the scheduler.
I've not used the Timeslot API myself, but instead do a sort of hard-switch between the two for configuration, BLE OTA updates, etc. So for example, I have a switch in HA to put any individual node into "DFU OTA via BLE" mode - just like in the Nordic examples - then I can use their app to upload new firmware, update the SoftDevice, etc. and then reboot.
Hope that made sense.
Also @NeverDie, on the threads and meshes - I've had good success with Apache MyNewt. Their BLE Mesh implementation (using NimBLE) was relatively straightforward to work with. I made a 5x node test mesh with Publishers and Subscribers, everything provisioned using secure Network and App keys using Nordic's nRF Mesh app. Press a button on one node, all the others do something, etc. At that point, I'm not sure how useful it is to implement the MySensors protocol on top of that, but rather just choose a Publisher to act as a Gateway to your Home Automation software of choice.
-
(Been away for a while, but saw this and thought I should chime in...)
@monte - I can confirm that this is true. I have custom nRF52832 boards with bootloaders and SoftDevices (S132) that are all currently happily running MySensors code too - I needed the bigger memory footprint AND FOTA updates, so...
As you suggest, you have to disable the SoftDevice before MySensors takes ownership of the radio otherwise there are problems. And depending on how/where you stack things, make sure that @d00616's awesome arduino-NVM layer (pseudo-EEPROM implementation) isn't going to write over anything important. I used Adafruit's FreeRTOS implementation as a starting point, but I'm not sure I fully understand what I've done in the scheduler.
I've not used the Timeslot API myself, but instead do a sort of hard-switch between the two for configuration, BLE OTA updates, etc. So for example, I have a switch in HA to put any individual node into "DFU OTA via BLE" mode - just like in the Nordic examples - then I can use their app to upload new firmware, update the SoftDevice, etc. and then reboot.
Hope that made sense.
Also @NeverDie, on the threads and meshes - I've had good success with Apache MyNewt. Their BLE Mesh implementation (using NimBLE) was relatively straightforward to work with. I made a 5x node test mesh with Publishers and Subscribers, everything provisioned using secure Network and App keys using Nordic's nRF Mesh app. Press a button on one node, all the others do something, etc. At that point, I'm not sure how useful it is to implement the MySensors protocol on top of that, but rather just choose a Publisher to act as a Gateway to your Home Automation software of choice.
-
@acb so you just compile mysensors code with sofdevice chosen in options, and everything works? That's great news!
Do you mean you use FreeRTOS with mysensors also? So I guess you are using adafruit's bootloader then?@monte - No, not quite. I'll have to dig back into my local codebase. I use PlatformIO, but I remember having to modify one or more arduino-NVM files to make them compile for Adafruit's nRF52 BSP, something else with how the digital pins were defined (probably minor) elsewhere and of course update MyMainNRF5.cpp to work with their FreeRTOS scheduler. I remember that last part being a bit painful to debug - even with a JLink - but the nodes are pretty solid now.
I can do a diff later this evening if you're interested...?
Yes, Adafruit went with using an RTOS to manage their SoftDevice interfacing. I suppose there are pros/cons to that, but their support was definitely a pro! The useful part is being able to disable it cleanly (!) and then being able to jump back into it when it's safe to do so. FOTA updates with Nordic's app are always solid.
And yes, I've got a custom version of their bootloader running on my boards. Nothing fancy - different pins, buttons, LEDs, etc. I might have modified one or two other bits here and there, but their base should be a good enough starting point.
What boards are you using? And how are you programming them?
-
@monte - No, not quite. I'll have to dig back into my local codebase. I use PlatformIO, but I remember having to modify one or more arduino-NVM files to make them compile for Adafruit's nRF52 BSP, something else with how the digital pins were defined (probably minor) elsewhere and of course update MyMainNRF5.cpp to work with their FreeRTOS scheduler. I remember that last part being a bit painful to debug - even with a JLink - but the nodes are pretty solid now.
I can do a diff later this evening if you're interested...?
Yes, Adafruit went with using an RTOS to manage their SoftDevice interfacing. I suppose there are pros/cons to that, but their support was definitely a pro! The useful part is being able to disable it cleanly (!) and then being able to jump back into it when it's safe to do so. FOTA updates with Nordic's app are always solid.
And yes, I've got a custom version of their bootloader running on my boards. Nothing fancy - different pins, buttons, LEDs, etc. I might have modified one or two other bits here and there, but their base should be a good enough starting point.
What boards are you using? And how are you programming them?
@acb said in nRF5 action!:
I can do a diff later this evening if you're interested...?
Yes please, I think I'm not the only one who will appreciate your code :)
I have a bunch of 51822's but wanted to get into 52840. I have paused my research of NRF5 for some time, while I am finishing my other work, but I would like to have more complete experience with NRF5 than what is now provided by mysensors.
I guess FreeRTOS is a way to go, when you have far mo complex MCU then atmega, and far more capable.
I hope that mysensors core team will consider moving forward to more complex, but more powerful architecture.
