4 ms·

>I have about 20 nRF52840 boards deployed around my house for various automations. Is there an advantage of using the NRF boards over ESP ones for home automat

>I have about 20 nRF52840 boards deployed around my house for various automations. Is there an advantage of using the NRF boards over ESP ones for home automation?

grawp 3y ago
Non-obscure architecture, one of the most used Core in the world (Cortex M4), true Floating point coprocessor, non-chinese firmware for BLE, if are not afraid of doing full certification it can also be non-proprietary Wonderfull documentation. Ready made modules can be obtained at the same price as ESP32. You support EU chipmaker.
- grawp 3y ago
  Also absolutely wonderful documentation directly from Nordic Semi (for the peripheries) and from ARM (for the basic core).
vardump 3y ago
Power consumption might be one major advantage.
- tomn 3y ago
  this is the big one for battery-powered applications NRF52840 is specified to use 1.5uA when deep sleeping with RTC wake-up, while esp32-c3 is 5uA, which sounds ok, but is not the whole story. If you try to build something low-power with ESP32 you'll find that it takes a lot of time and energy to go from deep sleep to being able to transmit, while the NRF SDK is designed with that in mind. The NRF current consumption also includes the built-in voltage regulators -- this works from 1.7v to 5.5v, with a regulated output for peripherals, so all it needs is a battery and some passives. On the other hand the ESP32 is much more awkward -- it needs 3-3.6v, so you're going to need an external regulator, and a LDO with the required 500mA output current is going to have a significant quiescent current, and even then the voltages are awkward for lithium batteries once you consider the drop-out voltage. The tl;dr is that it's easy to get multiple years out of a coin cell with an NRF-based sensor, and that's just not happening with any ESP32.
5d41402abc4b 3y ago
I have an old wemos ESP32 board that for some reason, the CP2102 IC heats up if connected to a USB charger, but works fine when connected to a PC. Probably some design flaw? Also that specific board is no longer available so if you 3D print an enclosure or make your PCB around it, it becomes useless. Compare that with boards from nRF or ST or Pico which will be available for a minimum of 10 years. Pico W is the same price as a ESP32 board.
- drekipus 3y ago
  PC is regulated to provide 500mA, Cheap Chargers are hard wired to deliver up to 2A. As long as CP2102 can handle it, it's fine, but you can get a 500mA charger.
DannyBee 3y ago
power consumption, ecosystem. The non-RISCV ESP's are a very wonky architecture, and while there is lots of ESP code out there, finding stuff that just works is harder than one may think. Meanwhile, pretty much all NRF52840 stuff you will run into just works, and works reliably. The toolchains and underlying pieces are also basically only supported by EspressIf (yes some work is upstream, but unlike ARM Cortex, you won't find a lot of help from others on Xtensa). Real debugging of NRF52840 stuff is also easier to do because of this - lots and lots of debug tools work. You will also get much better documentation out of Nordic. Now, this is mostly about Xtensa, and almost certainly one of the reasons that they are moving the ESP's toward RISC-V. I don't have enough experience with the newer RISC-V ones to give you a view there.
haberlerm 3y ago
debugging actually works. I thought the ESP3-S3 with USB integrated serial+soft JTAG adapter would be a big step forward well turns out the situation with openocd/gdb/flaky USB stack/resetting issues after upload is IMO untenable if you have a lot of time on your hands, every now and then debugging might work
- DannyBee 3y ago
  Yes, this is the joy of xtensa.
sitzkrieg 3y ago
the docs and toolchains alone are worth it. i have a few of. their cell devkits and its a nice change
kpc 3y ago
For my use case, Zigbee was vastly preferable to WiFi (or BLE). IP stacks are complex, buggy, and require a lot of configuration -- even moreso if you add encryption into the mix. Zigbee was the simplest tool for the job. Some of the newer ESP32 boards do support Zigbee but I don't think they were available yet when I started my project. Might be worth looking into ESP32-C6 now. As others have mentioned, power consumption is also a consideration. My battery powered devices consume about 25uA and should theoretically last 5+ years on two lithium AAA cells.

>I have about 20 nRF52840 boards deployed around my house for various automations. Is there an advantage of using the NRF boards over ESP ones for home automation?

grawp 3y ago

Non-obscure architecture, one of the most used Core in the world (Cortex M4), true Floating point coprocessor, non-chinese firmware for BLE, if are not afraid of doing full certification it can also be non-proprietary Wonderfull documentation. Ready made modules can be obtained at the same price as ESP32. You support EU chipmaker.

grawp 3y ago
Also absolutely wonderful documentation directly from Nordic Semi (for the peripheries) and from ARM (for the basic core).

vardump 3y ago

Power consumption might be one major advantage.

tomn 3y ago
this is the big one for battery-powered applications NRF52840 is specified to use 1.5uA when deep sleeping with RTC wake-up, while esp32-c3 is 5uA, which sounds ok, but is not the whole story. If you try to build something low-power with ESP32 you'll find that it takes a lot of time and energy to go from deep sleep to being able to transmit, while the NRF SDK is designed with that in mind. The NRF current consumption also includes the built-in voltage regulators -- this works from 1.7v to 5.5v, with a regulated output for peripherals, so all it needs is a battery and some passives. On the other hand the ESP32 is much more awkward -- it needs 3-3.6v, so you're going to need an external regulator, and a LDO with the required 500mA output current is going to have a significant quiescent current, and even then the voltages are awkward for lithium batteries once you consider the drop-out voltage. The tl;dr is that it's easy to get multiple years out of a coin cell with an NRF-based sensor, and that's just not happening with any ESP32.

5d41402abc4b 3y ago

I have an old wemos ESP32 board that for some reason, the CP2102 IC heats up if connected to a USB charger, but works fine when connected to a PC. Probably some design flaw? Also that specific board is no longer available so if you 3D print an enclosure or make your PCB around it, it becomes useless. Compare that with boards from nRF or ST or Pico which will be available for a minimum of 10 years. Pico W is the same price as a ESP32 board.

drekipus 3y ago
PC is regulated to provide 500mA, Cheap Chargers are hard wired to deliver up to 2A. As long as CP2102 can handle it, it's fine, but you can get a 500mA charger.

DannyBee 3y ago

power consumption, ecosystem. The non-RISCV ESP's are a very wonky architecture, and while there is lots of ESP code out there, finding stuff that just works is harder than one may think. Meanwhile, pretty much all NRF52840 stuff you will run into just works, and works reliably. The toolchains and underlying pieces are also basically only supported by EspressIf (yes some work is upstream, but unlike ARM Cortex, you won't find a lot of help from others on Xtensa). Real debugging of NRF52840 stuff is also easier to do because of this - lots and lots of debug tools work. You will also get much better documentation out of Nordic. Now, this is mostly about Xtensa, and almost certainly one of the reasons that they are moving the ESP's toward RISC-V. I don't have enough experience with the newer RISC-V ones to give you a view there.

haberlerm 3y ago

debugging actually works. I thought the ESP3-S3 with USB integrated serial+soft JTAG adapter would be a big step forward well turns out the situation with openocd/gdb/flaky USB stack/resetting issues after upload is IMO untenable if you have a lot of time on your hands, every now and then debugging might work

DannyBee 3y ago
Yes, this is the joy of xtensa.

sitzkrieg 3y ago

the docs and toolchains alone are worth it. i have a few of. their cell devkits and its a nice change

kpc 3y ago

For my use case, Zigbee was vastly preferable to WiFi (or BLE). IP stacks are complex, buggy, and require a lot of configuration -- even moreso if you add encryption into the mix. Zigbee was the simplest tool for the job. Some of the newer ESP32 boards do support Zigbee but I don't think they were available yet when I started my project. Might be worth looking into ESP32-C6 now. As others have mentioned, power consumption is also a consideration. My battery powered devices consume about 25uA and should theoretically last 5+ years on two lithium AAA cells.