High power consumption NRF52832 & SI7021
-
@ncollins thanks bud!
with the htu21 the sleeping consumption is sub 5ua. its been 4 days and hovering around 3 volts. i'm keeping my fingers crossed. Would love to reliably use these. Since I had so much trouble with them I designed and put into use atmega328p boards quite a while ago now so I'm happy with those but I still had a crap ton of these nrf51 and nrf52 boards made thinking i would get a lot of use out of them.
Things are improving. With some of the more recent developments and the reboot strategy I at least have reliable motion sensors working now. They've been up for about 2 months now, huge improvement!
-
I think it's a symptom of the "deadlock" scenario. I had a similar experience with NRF51 soil level sensors that were on the edge of their usable range. Looks like they get stuck in a loop, drain a huge amount of power (these were AA and AAA LiFePO4), trigger undervoltage/brown out, then restart, effectively clearing the deadlock.
I'm guessing that high interference or weak signal (too far away) increases the number of transmission attempts, compounding the likelihood of lockup.
-
I think that's an accurate description. Range won't be a factor this time in particular as its probably 10 feet (3 meters) away from the parent. I'll grab it and reflash it in a few days with the updated code.
I see our graphs show identical behavior, interesting.
edit
If I want to try out the new code is this the one i'm after:
https://github.com/mysensors/MySensors/pull/1455? Its a little unclear to me
-
I think that's an accurate description. Range won't be a factor this time in particular as its probably 10 feet (3 meters) away from the parent. I'll grab it and reflash it in a few days with the updated code.
I see our graphs show identical behavior, interesting.
edit
If I want to try out the new code is this the one i'm after:
https://github.com/mysensors/MySensors/pull/1455? Its a little unclear to me
@waspie I haven't tried the code from the redesign branch, as there are a lot of additional enhancements that may not have been fully tested yet.
I've been testing this file on NRF52s, hal/transport/NRF5_ESB/driver/Radio_ESB.cpp, specifically from this commit https://github.com/mysensors/MySensors/pull/1448/files.
Given the redesign merge request was submitted a few days after this Fix ESB deadlock, the Fix ESB Deadlock might not be that effective. I haven't been testing on NRF51.
I'd suggest asking on github, as a comment on the NRF5 ESB redesign commit, for suggestions on the best way to test the latest improvements.
-
-
that's the reversion isn't it? so wouldn't that be the same as no changes at all? or is this supposed to be the pre-reversion test fix? i think i'll try that code in 1455. nothing to lose but another cr2032 heh
good idea on asking, will do
-
@waspie ...potentially. It's a little confusing, to be honest.
I used #1448 based on this comment in #1445 (the revision commit).
-
@ncollins 1455 is the latest and greatest
https://github.com/mysensors/MySensors/pull/1455
d00616 replied to use it.6 days on no dip (yet)
edit i guess its 3 days since the spike (plugged in) was on 12/10
-
@waspie Looking a lot better. This node is in the same location that it was before the update?
-
@waspie said in High power consumption NRF52832 & SI7021:
1455 is the latest and greatest
so would it be a good idea to flash all my nodes? got 10 laying around..:)
-
I don't know if any of you guys are still around and using this stuff -
I moved and am reviving a few of these 51/52 boards that I had built. Prior to moving I had decent luck with all these fixes though I don't quite remember where I was with any of this stuff seeing as it was 3 years ago.I had a few motion sensors and some temp/humd based on these fixes and they were working great, no dips.
Not sure any of you will ever see this but hey it all worked.
