uC Power Profiles

Is there a way you can organize the power consumption of some of the uC u own in one place? such as the nrf52 in sleepMode/transmit/listening/and modem SleepMode (rf Off) for bt vs thread?

I got my first log on the esp8266 current profile. This is single esp-now frame. That spike surge is quite big maybe i need to add a capacitor.

organize, you mean in the website or in the forum ? Or in the source code ?
For the forum, I added this new tag #power_profile , all posts that have a power profile can be looked at together.

where ever u think is best. just for references and comparison.

I think using tags is ok for now, if you have suggestions, feel free, the forum is made for such quick and easy contributions using categories, tags and text search.
For higher level curations, I also document each design power profile consumption on the project webpage
Like here for the simplemesh sensortag

or the thread sensortag

that’s great thanks. I hav some question about ur findings. So what im seeing here is that the rnf52832 has usage in the mAs and the rnf52840 in the uAs. I’m sure this is mostly the characteristic of the chips, but is it also the trans. protocol as well or the protocol has little effect? Another question is that for the Thread sensor tag, u hav “wakeup cycle 1.7 sec including RF” 125uA. is this a single transmit packet or just the duration u r averaging? and the transmission time for a single packet is much smaller?

First with the nRF52832 I managed 9.6 uA as you can see in the documentation power table, and that number depend on the module I’m using, the minimal current of the chip itself is in the datasheet where all use cases are listed.
For the sensor Tag, the 1.7 sec are due to the light sensor integration time that is so long for low light condition. For light sensors there’s a compromise between letting them running all the time and consume average more power and get the measure immediately on host wakeup, or switch them on do the measure then off, then they consume almost nothing during sleep.

interesting, didn’t know it takes that long to prime a light sensor for low light reading. is it possible to keep a pin High while sleeping? that way u can power the light sensor, go to sleep for a short time, n then wake up and read? I know the trans. time different for number of bytes ur sending but what’s the average trans. time for a single packet u r sending currently?

It’s better than that, Zephyr RTOS has low power during sleeping so it’s enough to call k_sleep while waiting for the sensor. The sensors power is configurable with i2c to power it on and off then it’s independent from the host.
I’m sending large text frames so that it’s convenient to use json format that is directly used by the app without binary to text translation, for that long messages have to be split in two packets, each packet specified by the standard has a max byte size and is around 100 us I did not precisely measure it.

do u know if there is any way to automatically log data with the Power Profile Kit (PPK)?

What do you mean by automatically ? Like with command line ? Or do you mean automatic trigger ?
I think it can log for a very long time but with low sample rate so you can just leave it running.

i was thinking about getting the raw data like csv so i can plot it. but nvm i think the average shouldn’t be deviating much if im doing the same thing over a period of time.

this PPK kit is very useful. save me lot of time and the measurements is quite good. it was a good investment. thanks. I probably going to get another one if i hav the money but im saving to build the AR3 robot arm next.

1 Like

You’re right it’s handy because it provides all functions to quickly select and see the average and everything.
I did not feel the need to export in csv and run my own analysis scripts, as I’d have the to develop a gui and everything, unless you have a very complex validation script.
Why would you need two and not run tests one by one ? Then repeat the same test with another device as DUT.

this device is neat i just want to hav two.

I’m contemplating the power consumption today. so with a CR2032 at 3uA sleep, a device can sleep up to 7 years b4 the battery runs out. with 2 batteries that makes it 14 years, although CR2032 lifespan is only 10yrs. current iot devices run on 40nm silicon, imagine at 5nm the processing power will x8 approximately, and the power consumption will be 1/8. so a single CR could theoretically last 56 yrs in sleep mode and 2 of those will last 100 yrs. on 2 or 3nm silicon a single CR could last 100 yrs or more sleeping. The technology is here and it is in mass production. we just need to wait until it gets cheap enuf. XD

True at some points devices might no longer need to change battery, or simply rely on energy harvesting.
But it’s a race conditions because low power devices are getting smarter too, even if battery can keep them running long, if they throttle their cpu up they can use it rather quick.

actually when transmitting wireless signal at higher clock speed, it may reduce the transmission power bc the signal can be sent in shorter amount of time. when processing data, most of the time the lower clock is ok, the cpu process slower but at much lower power so more energy is preserved. it would b good to see a quad core on the rRF with different clocks for more power management options. maybe nRF54 will run on the cortex-m55.

You mean higher rf packet bitrate, yes it takes less power as it’s shorter.
Cpu clock on the other hand higher needs more power unless you finish the job faster and sleep :zzz:

i have been thinking about using iR communication as a mean to multiply pir sensor nodes, run it on cheaper uC (as low as $0.03), and extend battery life for many many years. The idea is that multiple pir nodes communicate with a parent node through iR communication, so it would consume much less power, n the parent node is connected to wall power and hav multiple iR receivers facing different direction. This is intended for indoor use only. Any idea on the feasibility of such approach?

Optical data connections are continuously being deployed, but I see them more for high throughput needs.
The issue with ir sensor nodes would be the restriction of placement that has to be within optical field of view of other nodes, which is to me as high of a restriction as requiring a placement with dedicated power connnction.
If you like the topic, then comparing the power consumption of rf vs ir might be a good exercise though.