Hello. I have four custom PCBs with P1 on it. The P1 module is a slave for nRF uC. On two of all boards, when the nRF set P1 to sleep, the current consumption is as expected, but on two other boards, the modules keep taking about 50-80 mA. I know it seems like the hardware or assembly issue, but the fact is that, when P1 goes to sleep without connecting to wifi, the consumption is good again. I also had some other issues with different consumption when going to sleep after connection and without the connection at all boards. I am using manual system mode and also system thread enabled.
In a brief, it seems like setting P1 to sleep was not completely accomplished and the device is still doing some stuff. Any ideas? Thanks in advance!
What system version have you got on your devices?
Some older versions did have troubles switching off the radio module before going to sleep.
Does an explicit WiFi.disconnect() and WiFi.off() change anything?
I’m using version 0.7.0 since yesterday, but the problems occurred also on 0.6.3. I’ve tried to disconnect and turn off wifi before sleeping and nothing changed. I also tried to connect to wifi only (without cloud connection), still the same. Is it possible that P1 keeps connection alive after going to sleep for some reason?
That shouldn't happen and I can't imagine why you see this issue.
So it's maybe best to open a support ticket as support.particle.io
I’m seeing similar behavior with a P1. My deep sleep current is right in line with the datasheet but I’m measuring 72mA in regular sleep instead of the 1-2mA stated in the datasheet. Would love to know what you found out, if anything.
Adding to this thread I did some more troubleshooting. Uncommenting SYSTEM_MODE(MANUAL) got me down to the correct regular sleep current (not deep sleep). Measured around 800uA in my product setup. Still troubleshooting but it appears that regular sleep does not work correctly in manual mode.
For some reason the bootup state of the WiFi module isn’t the most powersaving mode.
Try firing up the WiFi module (WiFi.on() - with or without actually connecting) and then switch it off again and see if and how this impacts the current draw.
I tried this. I had things in a state where I did WiFi.on() at startup up and then before going into stop-mode sleep I did WiFi.off(). I still measured 72mA. I wonder if having thread mode enabled prevents the module from actually shutting down before going into sleep. I was going to try adding a delay tonight to test that.
Ok closing the loop on my specific case. I think I was running into a combination of @ScruffR 's comment about the Wifi module not initializing into a low power state but also my own code which I completely missed in my test. Hopefully this can save somebody else some troubleshooting time. I have some connected peripherals in my product that draw a non-zero amount of quiescent current once the pins are initialized. In deep sleep on the P1 the pins return to a floating state so they essentially disconnect from my peripherals and don’t draw any current. In stop-mode, sleep however that is not the case so my things continued to draw current. The fix was 1) turning off the Wifi module before entering sleep and 2) returning my peripheral GPIO pins to inputs. After these two tweaks my product’s stop-mode sleep current is 800uA as expected.
4 Likes