|
I would imagine it runs for a long time if you are only powering it on to connect to WiFi, grab weather data, render the screen, and then shut off. The PiJuice page mentions "intelligent on/off switch", but I didn't easily find any details. Hopefully intelligent means "turn on at a certain time via an onboard RTC, turn off when systemd says it's OK" and the userspace code implements that dance correctly. In the absence of any power control, the PiJuice page says the 13000mAh model powers a Pi Zero W for 60 hours at idle (18 hours at full load). Based on the lack of discussion on the post, this is probably what's going on, though recharging every 2.5 days is exceedingly annoying, so maybe not. If you're doing a similar project, I really like the TPL5110 series of chips for power control. You basically connect it to your Li-ion battery, your project's voltage regulator's enable pin, and a GPIO pin. You set a time interval with resistors, and it draws 35nA while the power is "off". When the set time interval is reached, it enables the regulator, and your microcontroller boots. Do what you need to do, then set the GPIO pin. The TPL5110 then turns off the regulator and goes back to a very low state. With a 1200mAh battery, I can collect samples half-hourly and write them to a database over WiFi (with a RP2040 and ESP32) for several months without recharging. It all works very well, and would also work for the e-ink use case. I will say that I've had random luck doing this with e-ink displays. Some freak out and generate artifacts or fade out when you disconnect power. Some don't. Often marked with the same part number. So I have no idea what's going on there. Also, be careful about what your microcontroller does when you have the battery connected to an analog input to measure the battery voltage; you can easily draw a ton of current while otherwise idle that way. Large resistors are your friend, though be aware that some say things like "you'll blow up the chip if any IO pin has a voltage on it larger than Vdd". I didn't see that in the RP2040 datasheet and it didn't blow up, but your mileage may vary. One last note, when I've done projects like this in the past, I ended up just doing all the image manipulation on a server somewhere, and making the microcontroller just stream the bytes that the screen should display from the server. Then you never have to touch the microcontroller code, and you don't have to have a full Linux system on the client side (as this project did) with the associated power demands. $1 microcontroller > $35 Linux box. Though if you are a CircuitPython fan, this is ridiculously hard to implement because images get large fast and Python wants to read all the image data from the WiFi interface into RAM. Easier if you just write it in C. |
You could try setting the pins to Z state (floating) before turning off to see if it makes a difference.
If you have access to an oscilloscope you can also analyze what is going on in fine details.