Minimize power consumption #7
Comments
|
@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. |
|
Thanks! Did you also measure the current when idle? |
|
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. |
|
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. |
|
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! :) |
|
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? |
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. |
|
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? |
|
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. |
|
Mine is two months and still appears on the map. 8 sec interval. Will wait till it drain the battery. |
|
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. |
|
@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. |
|
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. |
|
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. |
|
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: Adv-Interval: 2560*0.625 = 1600 mc. |
|
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. |
These are very bad indicators. In active mode for most BLE SoCs (Telink, nRF, ERF): In sleep mode with RTC and active 32 kilobytes of RAM - 2..3 uA. ( 7mA * 3ms + 0.003mA * 2997ms ) / 3000ms = 0.009997 mA = 10uA
https://github.com/pvvx/UBIA/tree/master/PowerProfiler For best sampling results (up to 50..100kHz):
PS: Without PowerProfiler, there is no point in programming BLE. |
|
Just ordered a |
Module TB-03F, TLRS8253, test_adv_power1: period adv 3 sec, RF TX 0 dB, ADV_TYPE_NONCONNECTABLE_UNDIRECTED.
Module TB-03F, TLRS8253, test_adv_power3: period adv 3 sec, RF TX +3 dB, ADV_TYPE_NONCONNECTABLE_UNDIRECTED.
|
|
Those are great numbers @pvvx ! I should definitely target sub 10uA seeing those results. |
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 |
|
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. |
|
hal_pwrmgr_RAM_retention(RET_SRAM0|RET_SRAM1|RET_SRAM2); During sleep, the LDO switches to 0.6 V and the leakage currents to different SRAM blocks are different. |
|
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. |
@pvvx There is a newer version of this SDK including the sources of |
|
I tested on the PB-02-Kit by cutting the power wire of the module on the PCB. The reason for the high consumption of PHY6212:
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. PHY6252 used "section_xip_code" (LR_ROM_XIP 0x11020000 0x020000) |
|
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! |
|
So now I read the INA219 inputs have a bias current of 20 uA, making measurements at that level very inaccurate :( 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? |
|
Finally came in the mail "iSearching"... |
How will Jtag work during the Sleep SoC if the chip is powered down? |
😄 that was just to debug the interrupts, they where not working during normal operation either. But I fixed that now biemster/st17h66_blinky#2! The only issue left for blinky now, is that when the soc goes to sleep it seems to turn off the RTC as well, or the interrupts, or both. Or it is actually waking up, but in a uninitialized state. |
|
Is this the correct board pinout? |
That looks about right yes. (I only every use p9 and p10, and p3 (and batt)) |
|
And how are things with OTA on native firmware? |
|
I've seen some references of OTA in the SDK, but I never looked into that at all. Would be quite handy though, although that would require the whole BLE stack and SDK right? |
|
Yes, the entire BLE stack will be needed. |
|
That's a very interesting idea! I'm also planning to use them as a simple wireless button, I'll open a repo for this soon. Didn't think much about security though, which would be necessary. |
|
@natschil seems to have gotten Zigbee working: biemster/st17h66_RF#7, so I will likely adopt that for my HA switches and ditch BLE in further work. |
|
I don't want to hijack the discussion, but I'm having some issues flashing after de-soldering the buzzer - has anyone had the same problem? Previously I was able to flash with UART connected to P9 and P10 on the back of the board.. Edit: it seems that without the buzzer, the board can be powered over the UART pin, so to really reset it it is necessary to disconnect both uart and power. |
|
Some updates, for those who interested. Tag still works. Can see it from the app. Deployed Aug 16, 2022. |
yes thanks for reporting this, I'm having issues regularly with this as well when running the flasher |
That's amazing, it's on a 5s advertisement interval right? I really should add battery level reporting to the status byte. |
|
For those who interested: my tag stop transmit on 26.04. So, the tag works from Aug 16, 2022 till Apr 26, 2023. Traveled across EU and stable transmits 24/7, no any freezes or bugs detected during about 8 months. |
|
Aww poor thing! But that's a great achievement, I hope some of mine will reach that too. |
|
@vadimkozhin I've been pondering sending a couple out in some sort of art / social experiment, just to see where they travel, has your tag been in a similar project since it traveled a lot? |
|
@biemster I've pass the tag to my friends who has leave for business or travel during last months. Cyprus, Italy, Luthuania, Poland, Netherlands and Germany so far. Works and transmits each time perfectly. I've contact them during travels, and compare the locations. Very accurate results, up until the side ot the street. Amazing! One thing that suprises and scares a bit — carriers never recieves a single standart Apple warning about 'tag is following you'. I'm having also an original airtag atttached to my dog, but registered not on my id, and it alarms each time when I walk with the pet... |
|
That's amazing indeed! And scary! I don't have an iDevice, so I can't corroborate, but I definitely thought that this single key implementation would light up every iPhone that was carried along.. |
|
The alerts work for me but with a diminished sensitivity which I don't consider bad . If I am around the block walking I get no alerts but if I am driving for some distance after a certain amount of time I get an alert. |
|
@Itheras Yes, for me is the same. Seems like if the tag which is not registered on same id as the phone travels some distance together the alert appears. But if the registerd phone travels with this setup, not registerеd phone does not recieve an alert, which is completely fine. And first case is also ok. It prevents attaching the tag to person and spy on them without any notice. |
|
I didn't manage to reprogram the tag yet, but my use case would be to attach it to my car and bicycle, hence I wouldn't want the potential thief to be alerted if he has an iphone. |
|
@olivluca I agree. I just mention it, but is it a bug or a feature depends from the use case 😁 |
|
I agree is my experience that the decreased sensitivity make it more suitable for that use. You still get alerts but they behave differently, if attached to a vehicule it takes a longer round trip in a short period for it to trigger in a bicycle it probably won't trigger since it seems the distance is a mayor factor in it triggering. a few miles at least 15+. also even if detected the fact that there is no buzzer to try and locate may spook the thief in to just abandoning what is stolen . in my experience it still has anti stalking functionality but the changed behavior give you more time to track the stolen asset before it gets detected. |
|
It’s possible to reduce the size with a dremel tool smaller than the CR2032. Then attach power wires to the VDD cap and use conductive glue to the battery since solder won’t stick. Then harden it all up with epoxy. |
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.
The text was updated successfully, but these errors were encountered: