The idea of this is so that when power is lost, the unit has a couple of seconds to stop writing to the microSD card, and perhaps tidy things up to ensure a clean boot next time.
However, we haven't managed to get it to work properly yet.
The boards have a 20 Ohm resister in-line with the super-cap, so that there is no unmanaged in-rush current when charging the capacitor from empty.
The capacitor takes a few minutes to fully charge to about 4.8V (5V - the voltage of the zener diode that forms part of the power loss detection circuit).
At this point, it should be possible to then remove the power source, and have the unit operate powered solely by the super-capacitor, until its voltage level drops below about 3.3V.
GPIO24 is the line that reads our input-power-available signal (effectively the input power before passing through a zener diode, after which it charges both the super-capacitor, as well as powering the rest of the board. To test the system, I configured that GPIO line for input, and had a little shell script that sits in a loop reading from it.
root@OpenWrt:/# cd /sys/class/gpio
root@OpenWrt:/sys/class/gpio# echo 24 > export
root@OpenWrt:/sys/class/gpio# cd gpio24
root@OpenWrt:/sys/devices/virtual/gpio/gpio24# while [ true ]; do cat value; don
e
1
1
1
1
1
...
It reports 1 when there is an input power supply (other than USB, which is another little problem we need to solve), and 0 when there is no input power supply, but is running on the super-capacitor. At least that is the theory.
However, with the 20 Ohm resister, the voltage on the low-side is only about 2.2V, much too low to be useful. Thus I tried putting a 10 Ohm resister in parallel, dropping the combined resistance to about 6.7 Ohms. That still wasn't enough.
Then I tried bridging the resister by using a multi-meter in current measuring mode after having already charged the capacitor. This gives effectively 0 Ohms, and provides an upper bound of what is possible with this super-capacitor. With that configuration, things were more promising, as I saw u-boot try to boot, but as can be seen, as soon as it tried using the DDR RAM, it would reset, as presumably the DDR RAM draws too much power for the super-cap to sustain the supply above 3.3V:
1
1
1
1
1
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
DRAM:
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
DRAM:
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
D?
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
?
*********************************************
* U-Boot 1.1.4 (Jun 6 2015) *
*********************************************
AP121 (AR9331) U-Boot for DOMINO v1
?
As can be seen above, there is no line with 0, before it hits the u-boot reboot loop, indicating that the board does not operate on the super-capacitor, even for just a few milliseconds.
We'll have to think of an appropriate solution to this problem, but first we need to understand the situation more completely.
Is the capacitor unable to provide enough current for the DDR RAM?
Is the capacitor too small?
Also, only one of three super-capacitors seemed to work. The other two might have been damaged at some point in the process, but having 2/3 faulty makes me think that we shouldn't be relying on them.
small solar panel connected to super capacitor pulse charging a LIB?
ReplyDeleteWhathe is the internal resistance of the supercapacitor?
ReplyDeleteWhat is the internal resistance of the supercapacitor you're using?
ReplyDeleteLow enough -- the problem has been fixed on the latest revision of the PCB. I hope to write a blog post about it soon.
DeletePaul.