Zigbee: Deep sleep without rejoin using RTC FAST Memory (TZ-1384)

[michapr]

Is your feature request related to a problem?

Using the energy efficient deep sleep mode the device must rejoin to the Zigbee network after wakeup because all session information is lost. This take additional time (energy).

Describe the solution you'd like.

I would like to save all needed information (data) to the RTC FAST Memory, it will not be lost in deep sleep mode (if right configuration). So after start we could check the RTC RAM value - if valid, the join procedure can be skipped.

If connection is multiple times not possible the rejoin can be forced (set RTC values to invalid)

Describe alternatives you've considered.

No response

Additional context.

a similar method was implemented for the ESP32 at LoraWan

[chshu]

a similar method was implemented for the ESP32 at LoraWan

Could you share some more infomation on this feature?

The needed information include the runtime information all over the stack, it's challenge to put them together.

[michapr]

Hi,
here you can see the example code for ESP32 LoRaWAN -libraries and discussions in Github available
https://github.com/radiolib-org/radiolib-persistence/blob/main/examples/LoRaWAN_ESP32/LoRaWAN_ESP32.ino

This are really too much information for store/restore using RTC memory? I don't think so... But it could save very much energy for sleeping devices (like sensors) if ESP will be live only for such a very short time for reporting.

Thank you!

[chshu]

@michapr Does the device need to go through the rejoin process in this step: LoRaWAN_ESP32.ino#L102?

You may refer to a previous discussion here: #9 (comment).

[michapr]

Does the device need to go through the rejoin process in this step: LoRaWAN_ESP32.ino#L102?

As far as I remember/know - yes. But this is not a real rejoin, it is only for restoring the internal "session parameters" (simple said...)
The online time is very small, only for LoRaWAN transmission. Have tested it and it was working fine with HELTEC devices and ESP32/RFM module. Have created some solar powered sensors based on this.

Would be really nice to support the deep sleep mode for H2/C6 modules.

[dmartauz]

@chshu any news on this? Developers want to use Espressif SoCs for battery-powered devices. However, the solution must be competitive in terms of power consumption against Silicon Labs and others. From what I understood it is feasible, but it needs heavy code refactoring, correct?

[chshu]

@dmartauz @michapr We are developing next-generation 802.15.4 SoCs (e.g., ESP32-H4) for battery-powered devices, featuring integrated DC-DC converters and optimized power consumption. Stay tuned for updates! You can also reach out to our business team via this link to share your project requirements and reserve early samples.

[michapr]

@chshu Hi, thanks for the information, that looks interesting.
But I don't think the new device can solve this fundamental problem either.
Because the processor is restarted in deep sleep and all information is lost, the entire rejoin procedure has to be run through again for Zigbee, which costs time (and electrical energy).
The only solution is to buffer the entire Zigbee session information in the RTC or other non-volatile memory so that the data can be transmitted immediately (without rejoin).
Or (which is certainly not possible for the new model) - a deep sleep mode that continues the program at the same point as before the deep sleep (with the old session information) - as some other processors do.

That's why I think it's definitely worth optimising the software in order to be able to create good, effective battery-operated Zigbee devices.

[chshu]

Because the processor is restarted in deep sleep and all information is lost, the entire rejoin procedure has to be run through again for Zigbee, which costs time (and electrical energy).

That's why light sleep should be used in such case, instead of deep sleep. The light sleep current will be optimized a lot in our next generation 802.15.4 SoC, very close to other 802.15.4 platforms, so please stay tuned.

The only solution is to buffer the entire Zigbee session information in the RTC or other non-volatile memory so that the data can be transmitted immediately (without rejoin).
Or (which is certainly not possible for the new model) - a deep sleep mode that continues the program at the same point as before the deep sleep (with the old session information) - as some other processors do.

Not only is the Zigbee session information lost, but also the runtime data, digital peripherals, RAM, and CPU states are all cleared after deep sleep. What you're looking for is to achieve the same light sleep functionality based on deep sleep, but that's not feasible.

[dmartauz]

@chshu I contacted your sales support. Could you please share some more info including estimated timeline on new 802.15.4 SoCs in the meantime?

[michapr]

What you're looking for is to achieve the same light sleep functionality based on deep sleep, but that's not feasible.

No, of course not :)))

I'm speaking only about the Zigbee session information, as you know. See the ESP32 LoraWAN solution above - it is working fine.
RAM,CPU,digital devices are not so critical.

But of course an optimized light sleep could be a solution - you already know something about the expected power consumption in this very light sleep mode?

[rdorys]

What you're looking for is to achieve the same light sleep functionality based on deep sleep, but that's not feasible.

No, of course not :)))

I'm speaking only about the Zigbee session information, as you know. See the ESP32 LoraWAN solution above - it is working fine. RAM,CPU,digital devices are not so critical.

But of course an optimized light sleep could be a solution - you already know something about the expected power consumption in this very light sleep mode?
@chshu

I second this, l wonder what could be power consumption during esp32 H4 light sleep.

Some of others brands sound very optimized on this point (NRF52840 seems to be as low as 1.7uA without need to redo all the join procedure) and I think it will be a key point for making commercial battery powered devices… but I don’t want to re-learn a complete sdk.

It sounds really weird to me that you can’t make a battery powered button with esp32 H2 or C6 that sends instantly info to the network (and not 3s with deep sleep) and can last several years on typical coin cell. I think it’s a pretty commun use case people have.

Only few micro amps on light sleep would be fantastic !

[chshu]

I second this, l wonder what could be power consumption during esp32 H4 light sleep.

We don’t have the exact power consumption numbers yet, as they will only be available once the mass production chip is ready. However, it is expected to be in the few microamp range.

For customers with clear project requirements and a need for battery-powered 802.15.4 applications, please contact our business team via this link to share your project details and reserve early samples.