ESP32/ESP32S3 WOR Dual Core FREETOS SYSTEM

Hi William @ab9nq-william,

RE: Ultra-Low Power: Deep sleep mode with 5 mA current draw (Dev Boards)

  In case anyone reading your description above is thinking about a similar or related project, it appears the text is suggesting a deep sleep current is 5 milliAmps. This surprised me, as 5 milliAmps, although modest, would drain a small battery quite quickly, if permanently connected.

So I clicked the link you provided at the head of the note and, as I suspected, found a much more favourable value of 5 microAmps. 

From link: Ultra-Low Power: Deep sleep mode with 5 µA current draw

On the basis of 5 microAmps current consumption for the majority of operating time in a sleep mode, I suspect your system could be used in many circumstances. Perhaps you would like to clarify the true position, as I fear someone might discount a very useful contribution from you, due to a minute typographical error. 

Thank you for making your project available to all and bringing it to our attention.

Best wishes, Dave

@davee

ESP32 variant, ESP32 Devkit v1 development board was used in the project; 5 mA is correct for the lowest current consumption for this board due to LDO, USB chip active, on board Led and more. 

I used the Ebyte, EoRa Pi (ESP32S3 with LoRa SX1262, Dev Board) boards in a previous project.  Ebyte spec for this Dev Board is ~25µA with perpherials in deep sleep and running on battery and no USB.  EoRa Pi (alternative to Raspbery Pi) has two LDO's and bypasses USB, when on battery!  My post; Ebyte reference is about the EoRa Pi. 

Apologies for not being clearer on current consumption.    

Nordic PPK II observations from previous project using EoRa Pi Dev Board, yes, it is a development board!

Nordic Power Profiler Kit II Observations

Regards,

William

@ab9nq-william 

Thanks for this write-up on your LoRa/RTOS project. Very interesting, indeed. I have been interested in LoRa and more recently RTOS (FreeRTOS) for some time. 

I have a LoRa system operating my sprinklers for the lawn and garden and I’m looking to incorporate FreeRTOS as the operating system for a robot car I’ve been working on (forever). Regards, Lee WB5DTU

@lee-g 

Good Morning Lee,

I am a new to FreeRTOS and leaned heavy on AI Agents; was pleasantly surprised with their knowledge of FreeRTOS, seem like it was a lifetime of questions  I asked --each one answered promptly with extensive details covering questions how, why, fix, and code ssnippet or exmple, and debugging help if needed!  Longer your promp the better the answers you receive.

AI Agent tip:  Uploading your code requires appending filename extension to .txt (one of the supported file extensions supported.

Know the "forever" you mentioned; something you code takes "forever", coding, debugging, and improvements.

73's

William

Hi William @ab9nq-william,

  Thank you for helping to clarify the situation. Although I am not personally looking for such a project at present, the 'generic' requirement of a remote 'monitoring' station, which has an 'intermittent' radio or similar link to report change or activity, and which can be powered for a long period of time by a modest sized battery, is a recurrent theme, that often arises or provokes interest. The properties of a LoRa system usually extend the physical range of such a requirement, as well as being designed for applications that spasmodically transmit data are a natural match for such a system, and increase the value of the product.

Although radio transmissions, even for LoRa, usually require significant power whilst active, it is not unusual to discover that a large proportion of the battery capacity is consumed whilst the system is effectively 'sleeping' or 'dormant', and not conveying any information. Thus, practical examples of systems that achieve both the radio data transmission requirements, as well as achieving a very low battery drain in the 'sleeping' state, are likely to be of interest.

In the first instance, such interest is likely to be at a superficial level, whilst the basic capabilities of a particular system are clarified, and that is what I was aiming to achieve. Of course, the specific requirements of each project can vary widely, but one of the fundamental 'building blocks' is likely to be a system that can operate in a 'sleep' mode for a very long time on a single battery charge. 

So for my curosity, whilst I confess to not studying your material closely, I should like to ask a question, as I suspect my impression is mistaken. Considering and discussing only the most superficial details, could you please clarify and correct my revised impression of your project, which I will attempt to describe: 

Namely, that you have developed a LoRa system, which wakes on receipt of a radio message, and responds by transmitting a suitable 'status' reply. To minimise the power used to 'listen for' an instigating radio reception, the instigating radio transmissions are timed to a regular time slots.

The average current consumption by the 'remote, battery powered station', whilst sleeping in between time slots, is approximately 25µA. The remote station for this achievement is based upon an Ebyte product, consisting of an EoRa Pi, which is an ESP32S3 with a SX1262 Lora Transceiver.

You have also used an ESP32 Devkit v1 development board for part of the development work. The current consumption of this board in the 'sleep' mode was approximately 5 mA, in part due to the LDO voltage regulators and other components that would not be part of a 'final' product version of the remote station.  

(I am not clear why the ESP32 was substituted for the Ebyte board, but guess practical considerations, such as availability and/or cost may have played a role.)

Apologies for any mistakes and confusions on my part.

I also note with interest that you have used AI systems to aid your development. However, in view of the length of this reply, I shall refrain from broadening the discussion at this point, beyond encouraging you to provide any further lessons or tips you think may be of interest to others, perhaps in a separate discussion.

Thank you and kind regards, Dave

@Dave

Thanks for your interest.  Reason for using ESP32 Devkit v1 was availability; currently unsure of import duties due to tariffs I have not order anything for awhile from China.  EoRa Pi has an excellant price point of $16.99 US from China.  I have two EoRa Pi's; both used in the "EoRa Pi Foundatation" GitHub project, Nordic Power Profiler Kit II Observations are from this project.  NPPK II Observations are in earlier reply to this topic.

NPPK II Observation Image 4 shows a EoRa Pi transmission event.The spike is a single transmission with a 11.34 mA max. current, of 9.910 mS duration.

NPPK II Observation Image 5 shows multiple 11.30 mA "spikes" (transmission events) with a baseline current of 25.38 µA.

Project use an auto duty cycle active time 1.4%, sleep 98.6% of the time.  Achived using the RadioLib library to make use of "radio.sleep" that puts LoRa Radio in a powered down mode, this mode has no listening and no transmitting in this mode.  Preable wakes the ESP32S3.  Payload turns on switch, sets up a countdown timer to turn off switch and to change LoRa radio modes.  Without "radio.sleep" current consumption would be much higher.

"Radiolib Discussions" is good resource for makers working with various radios, including LoRa. This where I learned of radio.sleep.

Regards,

William

Nordic Power Profiler Kit II  (NPPK2) Observation of Wake-On-Radio (WOR) from Deep Sleep untill ESP32-S3 normal activity.  The current consumptions readings are HIGH; this is due to being a development board and not designed for battery useage like newer development board with two LDO VR, that are in the µA range of current consumption for the whole development board and costing less than $20 US.

NPPK2 is a testing device for very small currents; capable of current readings in the µA and nA ranges, plus does 100,000 sampls in second. 

Regards,
William

I'm confused.

First there is:

Posted by: @ab9nq-william

↑

This project demonstrates implementation of LoRa communication with deep sleep power management

But then there is:

Posted by: @ab9nq-william

↑

The current consumptions readings are HIGH; this is due to being a development board and not designed for battery usage...

Are the power savings from the deep sleep mode negated by the development board?

@TFMcCarthy

Apologies for not stating the NoricPower Profiler Kit II observation were done with out any optimizations; just the development board, no attempt to get the lowest current in µA range.  I will insert this fact into my previous post after this reply.

ESP32-S3 Series
Datasheet Version 2.1

I will follow-up with another NPPK2 Observation post; after optomizing for lowest power consumption.

Thank you for bringing this to my attention.

Regards,

William

Found I can not achive lower than 3.5 mA current for the ESP32-S3 DevKitC-1; believe the 7-8 µA must be spec for a bare ESP32-S3 with minimum components.  ChatGPT summarized my experience:  

Why a Full ESP32-S3 Dev Board Can’t Compete with the EoRa-S3-900TB for Low Power

After profiling with a Nordic Power Profiler Kit II, I found:

• ESP32-S3 full dev board (deep sleep) → ~3.6 mA
• Ebyte EoRa-S3-900TB (deep sleep) → ~25 µA

That’s roughly 140× lower current for the Ebyte board.

Same ESP32-S3 chip — huge difference.

Here’s why.

The problem is NOT the ESP32-S3 chip

The ESP32-S3 itself sleeps in the single-digit µA range.

The extra current comes from the development board hardware, not firmware.

So this is a board design issue, not an ESP32 limitation.

Why dev boards draw milliamps

Typical ESP32-S3 dev boards include parts that are always powered:

1. USB-to-UART chip (CP2102 / CH340 / FTDI)

Draws ~1–2 mA continuously
Cannot be disabled in software

2. Linear regulator (often AMS1117)

Very high quiescent current
Commonly 2–5 mA just sitting there
Even with ESP32 asleep

This is usually the biggest offender

3. Power LED

~0.5–1.5 mA constant

4. Misc support circuitry

Auto-reset transistors, pullups, ESD chips, etc.
Adds a few hundred µA

Typical math

USB chip ~1.5 mA

Regulator ~2–4 mA

LED ~1 mA

Misc ~0.3 mA

Total 3–6 mA

Which matches my measured 3.6 mA almost exactly.

So the board itself burns mA before the ESP32 even matters.

Why the EoRa-S3-900TB is different

The Ebyte board is designed for battery/IoT deployment, not bench development.

It typically includes:

• Low-IQ regulator (µA range, not mA)
• No always-on USB chip
• No power LED
• Minimal support parts
• Proper biasing of sleep pins
• Radio + MCU power designed together

Result:

Whole board deep sleep ≈ 25 µA (measured)

That’s production-grade power behavior.

Bottom line

Full dev boards are for:

• convenience
• USB flashing
• debugging

They are not for:

• battery operation
• ultra-low power
• current profiling

If you need µA sleep currents:

Use:

• bare module, or
• low-power purpose-built board (like EoRa series)

Not:

• feature-heavy dev kits

Rule of thumb

If your “deep sleep” is still in milliamps:

It’s almost always:
👉 regulator + USB chip + LED

Not your code.

73’s 📡
William

Hello, Nice project and great use of AI to get through a project. I am planning on using AI in my development efforts this year.

I have a question for you.

In your testing you used an ebyte lora module with an external esp32 which gave you the high sleep current.

To get around the high sleep current using an EoRa-S3-900TB board with an integrated esp32 S3 would get the sleep current down to micro amps. 

Is that correct. Please correct me if I am not understanding.

Thank you and that was a nice write up of the project

~Joe

Good Afternoon Joe,

You are correct; I have used the EoRa-S3-900TB previously, currently waiting on order from China.  Amazon.us is carrying this product now with a 200% mark up!

Project:  EoRa-Pi-Foundation  I used the EoRa-S3-900TB.  NPPK2 Observation screen captures were done for current compsumtions in the different stages of the project cycle.

Right side of the image, in black is the Baseline current. Spikes are from the LoRa SX1262 radio listening for the next preamble; in a duty cycle of 1.4% and 98.6% Sleeping. Top of image, in black is LoRa SX1262 radio current; spikes are of a very short duration.

Regards,

William. 

@ab9nq-william Thanks for the info.    I will have to look at EBYTE more closely they seem to have high quality boards that are well engineered.

Updated project code to include event time for each of the sequence of events; captured event times in "Putty" log.

"Putty" log of project event timings

Video link in the "Putty" log is prior to this code update.

Regards,

William