Minimize power consumption

[biemster]

The current code is based on the SDK v3.1.1.2 lowPower beacon example, which seems to last on a coin cell for a couple/few weeks. There is also a git repo with a power optimized firmware here: https://github.com/ThuanLeUte/ble-st17h66_fw_power_consumption, and there might be other ideas to lower power consumption (like putting the chip in deep sleep and just wake up for a single broadcast every 5 sec). First it's necessary to actually measure the power consumption of the different firmwares, and then start experimenting with the code to get it lower.

[biemster]

@vadimkozhin did you ever analyse the power draw with the rigol on your bench?

[vadimkozhin]

did you ever analyse the power draw with the rigol on your bench?

@biemster Yes. It is aligning with datasheet - 4.7mA during transmit. For now I can't get anything less from a chip, so I decided just plug in the new batt and leave it to check if it lasts more then a week...

So far it works from 16.08. It transmits once in 5 sec.

[biemster]

Thanks! Did you also measure the current when idle?

[vadimkozhin]

It is... the same. I've not done precise measurements, just watch it on my power supply. It jumps from 4.7 to 5.2 approx.

[biemster]

I hope I will be able to improve on that, since the tags I got usually had the battery in place, and were switched on by pressing the button. I guess those tags are lying on the shelf sometimes for a month or more, which would drain the battery in that case.

[vadimkozhin]

Yes, according to datasheet there is a sleep mode with less current, but it is deactivated only with a hardware pin e.g. with button preset.

There is (according to datasheet) couple of interesting options, but I cannot succeed to activate them, with provided SDK samples. Good luck with experiments! :)

[biemster]

Thinking about it, 5mA on a 230 mAh 2032 should only give you 40 hours of running, so I guess it is idling already on a lower power mode?

[vadimkozhin]

5mA on a 230 mAh 2032 should only give you 40 hours of running, so I guess it is idling already on a lower power mode?

Exactly my thoughts! So that's why I decided just plug in the battery and see what will happen after a week or two. So far it is on since 16.08, so yes, definitely idling. May be need to find a way to accurately measure a batt consumption.

[biemster]

I had to replace the battery in one of my tags already for the second time, so I'm getting about a month or so, give or take a week. That's shorter than I was hoping.. The 1uA sleep mode with RTC will be my goal, do you think the datasheet means with external RTC?

[biemster]

So I put in two fresh batteries when I opened this ticket, but they both seem to have died already 4 days ago. That puts it on just over two weeks with an advertisement every 3 seconds, which is a bit disappointing I must say. Maybe I should prioritize this.

[vadimkozhin]

Mine is two months and still appears on the map. 8 sec interval. Will wait till it drain the battery.

[biemster]

Well done! I'll have to think out a way to accurately measure the power draw first. All I have at the moment is a basic multimeter from Lidl, I should be able to do better than that. Also the 2032s I'm using are not of the best quality, so my measurement could have been a bit biased.

[biemster]

@vadimkozhin do you by any chance know how long it takes the mcu to send out the advertisement packet?

[vadimkozhin]

do you by any chance know how long it takes the mcu to send out the advertisement packet?

Unfortunately not. The tag is "traveling" at the moment :) If you still will be interested in this interval, ping me in a week or so, then tag will be again in my hands and I can measure actual interval with oscilloscope.

[olivluca]

I don't know if it's useful or not, but maybe looking at this project and asking @pvvx could give you some ideas: the battery lasts around 1 year. Looking at the datasheet the telink chip is more efficient (deep sleep 1uA with ram retention vs. 4uA for the st17h66, transmission 4.8mA vs 8.6mA) but OTOH it has to manage a display and the temperature/humidity sensor.

[biemster]

I've been eyeing that project for a while as well, especially since the 17h26 seems to be a clone of the telink used in those thermometers. @pvvx seems to be very able with such material, good idea to ask him for suggestions.

[pvvx]

I didn't get good results with the available examples from the SDK for PHY62xx and AiThinker on PB-02-Kit modules (PHY6212).

---

The best example is with AT-BLE-UART: Before the test, enter the commands: AT+BLEMAC=234567123456 AT+BLEADVINTV=2560 AT+RST reboot... AT+SLEEP=0

Adv-Interval: 2560*0.625 = 1600 mc. The result of measuring the current along the 3.3V line only to the module: The current averaged over 140 seconds is 40.7 μA. The current in sleep mode is about 19..20 uA, which is a lot. Usually the sleep current is highly dependent on the software implementation and not on the directions in the datasheet...

[biemster]

Thanks @pvvx ! That's very useful info. With 40uA average you'd get 230 days out of a 230mAh button, that's considerably better than the two weeks I'm getting now, and it could even be stretched to a year with a longer adv interval. I'm still thinking out how to do the power measurement, and get a nice plot like yours, without breaking the bank on new equipment. (although I could just take an interval of 10+ seconds, and measure the sleep current with my DM as well I just realize..) I assume you made this plot with a scope?

[pvvx]

With 40uA average you'd get 230 days out of a 230mAh button, that's considerably better than the two weeks I'm getting now, and it could even be stretched to a year with a longer adv interval.

These are very bad indicators. For a key on a typical BLE SoC with advertisement every 3 seconds, the total average consumption should be less than 10 uA.

In active mode for most BLE SoCs (Telink, nRF, ERF): wake-up (1..2 ms) and advertising transmission (2 ms) - average current 5..9 mA

In sleep mode with RTC and active 32 kilobytes of RAM - 2..3 uA.

( 7mA 3ms + 0.003mA 2997ms ) / 3000ms = 0.009997 mA = 10uA

I'm still thinking out how to do the power measurement, and get a nice plot like yours, without breaking the bank on new equipment. (although I could just take an interval of 10+ seconds, and measure the sleep current with my DM as well I just realize..) I assume you made this plot with a scope?

https://github.com/pvvx/UBIA/tree/master/PowerProfiler

For best sampling results (up to 50..100kHz): GY-169(INA169) + oscilloscope https://aliexpress.con/item/4000107917726.html or INA199 + oscilloscope

• Replace the shunt resistor with a switchable set with a maximum resistance of 100 ohms.

PS: Without PowerProfiler, there is no point in programming BLE.

[biemster]

Just ordered a GY-169 INA219

[pvvx]

For a key on a typical BLE SoC with advertisement every 3 seconds, the total average consumption should be less than 10 uA.

Module TB-03F, TLRS8253, test_adv_power1: period adv 3 sec, RF TX 0 dB, ADV_TYPE_NONCONNECTABLE_UNDIRECTED. Average power 5.8 uA at 3.3V.

Module TB-03F, TLRS8253, test_adv_power3: period adv 3 sec, RF TX +3 dB, ADV_TYPE_NONCONNECTABLE_UNDIRECTED. Average power 6.1 uA at 3.3V.

[biemster]

Those are great numbers @pvvx ! I should definitely target sub 10uA seeing those results.

[pvvx]

With 40uA average you'd get 230 days out of a 230mAh button

The documentation for PHY62x2 does not indicate power consumption in sleep mode with active-retention RAM. And measurements with examples available in the SDK give disappointing readings - 10..20 uA, depending on the retention RAM size.

ST17H66B2 datasheet: 4uA @ Sleep Mode with 32KHz RTC and all SRAM retention Not known which memory block has a specific leak in the sleep (0.6V).

[biemster]

This is more complicated than I thought. I was hoping there would just be a function in the SDK power manager to call, with an enum or so to specify the sleep mode. What do you mean by "a memory block with a specific leak in the sleep (0.6V)"?

[pvvx]

hal_pwrmgr_RAM_retention(RET_SRAM0|RET_SRAM1|RET_SRAM2);
hal_pwrmgr_RAM_retention(RET_SRAM0);

During sleep, the LDO switches to 0.6 V and the leakage currents to different SRAM blocks are different.

[biemster]

That seems to be present in the current code already on L140. I'm wondering why sleep is broken in this implementation, I hope the INA219 arrives soon and I can start experimenting.

[biemster]

I didn't get good results with the available examples from the SDK for PHY62xx and AiThinker on PB-02-Kit modules (PHY6212).

@pvvx There is a newer version of this SDK including the sources of rf.lib where some of the sleep code is located available here: https://github.com/duanmubingshuai/test Maybe those can help you get better results?

[pvvx]

I tested on the PB-02-Kit by cutting the power wire of the module on the PCB. But on other outputs of the module, leaks are possible... A lot of consumption was due to taken examples from the SDK. Rewriting everything to my version turned out better:

The reason for the high consumption of PHY6212:

1. The program is placed in RAM. A large amount of RAM is constantly fed. Current in Sleep 5.6+ uA at 64KB.
2. Long time to wake up the chip from sleep. From 2 ms to the start of transmission of advertising packets.

• If you don't change pGlobal_config[MAX_SLEEP_TIME] to a value greater than the advertising interval, the chip will unnecessarily wake up for a couple of ms and sleep again every cycle of the advertising interval. This leads to an increase in the average current consumption. (There is a patch for GCC: https://github.com/biemster/st17h66_FindMy/blob/main/lib/rf/patch.c#L7712 )

This is PHY6212, and ST17H66 is most likely similar to PHY6252. ST17H66 and PHY6252 have a cache for executing code from FLASH. PHY6212 does not. There are different SDKs for PHY6252 and PHY6212: http://wiki.phyplusinc.com/doku.php?id=menu:sdk PHY62XX SDK v3.1.1 (适用PHY6222/PHY6252) PHY62XX SDK v2.1.1 (适用PHY6212)

---

PHY6252 used "_section_xipcode" (LR_ROM_XIP 0x11020000 0x020000) https://github.com/biemster/st17h66_FindMy/blob/main/FindMy/scatter_load.sct#L49 But there are no such sections for GCC: https://github.com/biemster/st17h66_FindMy/blob/main/FindMy/RTE/Device/ARMCM0/phy6202.ld

[biemster]

Got my INA219 today! I don't have an STM32 or TLSR lying around so I can't use the PowerProfiler directly, but I have some ESP's, pico's and arduinos to spare so I'm confident I can build something workable. @pvvx 's repo is a great resource for this, so it shouldn't be long!

[biemster]

So now I read the INA219 inputs have a bias current of 20 uA, making measurements at that level very inaccurate :( I guess it's back to the drawing board then..

I should have listened better to @pvvx and buy an INA169 which has an input bias current of 10 uA, although how much of a difference would that make? The INA199 has an input bias current of 28 uA, even worse than my 219. On the other hand the INA326 has an input bias current of 2 nA (nano!), but I can't find any modules from my favorite overseas supplier. Wait that's not a power monitor. Any suggestions are more than welcome!

[pvvx]

The input bias current depends on the voltage at the common inputs. It is stable at a stable temperature and is subtracted from the measurements... Use a zero calibration for each shunt and supply voltage. (INA228/INA229 - 20 bits, Input bias current: 2.5 nA (maximum).) Power Profiler is needed not for measuring the average total current, but for debugging with the aim of obtaining the lowest currents using a visual diagram of work. It is possible to measure the SoC sleep current with a simple tester. And to measure the current during activity - no. The average current is the sum of these currents over time.

INA169, INA180, INA199 can be used to connect an oscilloscope. The oscilloscope measures the average current over a short active cycle window. Knowing this current and the time of the measurement window of the active cycle, add the current in the sleep pause and get the average current.

If you need a turnkey solution, then there is a more or less option for the price and quality of nRF Power Profiler Kit 2. A professional absolute measurement solution with the required dynamic range costs more than a few hundred thousand dollars :)

[biemster]

thanks for that explanation @pvvx ! Good to know that those input bias currents can be calibrated out, I'm going forward then with this setup. Unfortunately I don't have an oscilloscope on my bench due to budget constraints, so a turnkey solution is even more out of reach :( I have a DM here capable of uA measurements, so the plan now is to have the chip sleep for 10+ seconds and measure the power draw with that, and then make the diagram with the INA219 and scale the output so it matches the sleep current measured with the DM.

[vadimkozhin]

Guys, just to inform you, my setup still working from August 16.

[biemster]

Guys, just to inform you, my setup still working from August 16.

That's amazing! I have quite a few drain on me already, to a point I'm not putting batteries in anymore. I'm still trying to find time to do the power measurement, seeing yours is still running is encouraging!

[vadimkozhin]

@biemster I forgot to mention one, may be important thing -- I am completely remove the buzzer from the board. And just for the info, beacon time interval in my example was set to 8000.

[biemster]

good point about the buzzer, as it is connected to uart which is active. I'll keep that in mind when I start on this (hopefully during the holidays), I just need to desolder the shunt on my INA219 and calibrate it so it shouldn't be that much work

[sebi5361]

Here are the measurements I made on my Lenze st17h66 beacon flashed with @biemster's latest FindMy firmware (commit 5633d40 on Sep 6, 2022) using the NORDIC Power Profiler Kit II: The average consumption is ~234.47uA @ 3V (spikes are every ~3.127s). It is 30 times more than to the nRF51822 FindMy beacons I have tested (234uA vs 7.60uA), so I think there is a great margin for improvement... Tell me if I can help with additional measurements.

[biemster]

that's great work @sebi5361 ! I noticed my batteries draining quite fast as well, this confirms that. I'm on holiday atm so i can't work on this for a couple days, but I'm definitely going to ask you to run this test again a couple of times on some new versions of the code, if you are willing. thanks!

[sebi5361]

Happy to help!

[biemster]

@sebi5361 from your measurements, what is the power draw while the chip is sleeping? and how many milliseconds do those peaks last? (I'm trying to figure out where most energy is spent, should i optimize the sleep or the peaks)

[sebi5361]

@biemster: I will give you the exact values pretty soon but you should start by optimizing the sleep... Indeed the average consumption is close to the sleep consumption (horizontal blue line on the graph is close to 234uA) currently.

[sebi5361]

Idle

224uA * 3.12s = 700uC

Emission

6.4mA * 4.6ms = 30uC Note the 3 similar emission spikes.

Conclusion

700uC vs 30uC = 23 times more reasons to spend time on idle rather than emission at the moment.

[pvvx]

3 peaks is a typical transmission of BLE advertising over 3 channels. Problems only in the first 2 ms. But this is an invariable part - this is the wake-up time of this SoC. A small optimization is possible, by a few percent, but this is already related to the internal algorithms in the SDK implementation.

Sleep consumption is atypical for this SoC. Something is set incorrectly. Most likely GPIO pull-ups or internal controllers are not disabled.

[sebi5361]

_Originally posted by @vadimkozhin in https://github.com/biemster/st17h66_FindMy/issues/7#issuecomment-1361054726_

@biemster I forgot to mention one, may be important thing -- I am completely remove the buzzer from the board.

For what reason might the buzzer be leaking some current? Is it the same for the LED? Should I remove both to perform additional tests?

Pictures of Lenze st17h66 round beacon:	Front	Back

[vadimkozhin]

@sebi5361

For what reason might the buzzer be leaking some current? Is it the same for the LED? Should I remove both to perform additional tests?

My version of the tag ticking the buzzer when chip output something on UART. So, if you completely silent the UART or hear no any ticking during packet transmit -- do not worry about the buzzer. But you also can measure if there is some voltage on buzzer during the packet send...

With LED -- it's the same. If during transmission led blinking, you can remove it (or cut the trace to it) and redo measurements, coz LED definitely eating some power.

[sebi5361]

Some great news: Without the buzzer (+ its related diode + its related CMOS), nor the LED, the average consumption drops from 234.47uA to 15.6uA @ 3V!

The improvement during the emission phase is modest (27.62uC vs 29.49uC) but becomes significative during idle (idle average current is 6.37uA vs 224.16uA): So there is now only a factor 2 for this cheap Lenze st17h66 beacon to become as efficient as a NORDIC nRF8166 beacon (15.6uA vs 7.6uA). As a nRF8166 beacon lasts ~1 year on a single CR2032 battery (those are real life measurements), one can expect our Lenze st17h66 beacons without buzzers to last ~6 months using the current firmware. Note: There is already room for improvement by changing the current advertising period from 3.127s to 5s (as with the nRF8166 beacons).

[biemster]

wow great find @sebi5361! this is really pinpointing where the code should be fixed. when I'm back from holiday after the weekend I'll get on this definitely. disabling the uart altogether or fixing pullups on the gpio as @pvvx mentioned should hopefully be as effective as removing the buzzer

[sebi5361]

Unfortunately I won't be able to test this aspect of the code with my Lenze beacon as there is no buzzer anymore... But if you decide to work on (i) the advertisement period, (ii) idling in sleep mode, (iii) preferably without SRAM retention, I'll be able to perform additional tests easily.

[pvvx]

becomes significative during idle (idle average current is 6.37uA

That's an awful lot. Should be up to 4 uA. Something else is not disabled... Datasheet: 4uA @ Sleep Mode with 32 KHz RTC and all SRAM retention

[sebi5361]

Hi @biemster, looking forward to knowing if you made any progress?