The startup saga continues. Too many inter-related issues, I need to simplify…
Before tackling the power-ramp startup scenario, i.e. starting up a JeeNode (or JeeNode Micro) on a slowly-charging capacitor, I wanted to make absolutely certain that the sketch is set up to get the best low power mode as quickly as possible after a hardware power-on reset.
Time to create a test setup:
This is a JeeNode running off 3.6 .. 3.9 V battery power, driving a MOSFET plug using this sketch:
In other words: power up for 2.5 seconds, power down for 0.5, then rinse and repeat. The JeeNode sitting upright at the bottom right is the Device Under Test (DUT). It’s a JeeNode without regulator, with a little test board to pass the ground connection through a 10 Ω resistor. This lets me measure current (or rather: voltage drop) as well as the voltage of the power supply.
Here is the behavior of a standard ATmega, with standard fuses and a sketch to init & power down the RFM12B:
There’s a 1.5s startup delay as the boot loader listens for incoming commands, before it passes control to the current sketch. The lower half of this screen shot shows that point, i.e. right when the sketch is given control. Within about 250 µs, the RFM12B is put to sleep. The vertical scale is 2 mA/div (Ohm’s law, 10 Ω resistor).
Note the time scale: the lower portion is zoomed in 1000x w.r.t. the top.
After lots of experimentation, with the boot loader disabled, I managed to get startup a lot quicker, using a lot less energy. The code used was as follows (with these fuse settings: EXT = 0x06, HIGH = 0xDB, LOW = 0xC2):
Here is a screenshot with all the traces properly labeled and with measurement units added:
Note again the horizontal time scale (top left). Here’s how to identify the different portions of these graphs:
- the first blip is when the ATnega comes out of power-on reset
- the second blip is for the rf12_initialize() and rf12_sleep() calls
- the third blip is the first time loop() is run, which then quickly goes to sleep again
The big surprise (and disappointment) here, is the time between blips 1 and 2, where the average current consumption is about 0.75 mA (between the white cursor lines). This is caused by the RFM12B starting up (a bit irregularly) with the crystal oscillator enabled, instead of in power down.
The problem is that the RFM12B can’t be accessed in the first 30 ms or so after power up (probably because it’s still busy getting out of its own hardware reset). That’s a shame, since the ATmega can go to sleep in ≈ 250 µs.
The point of this all, is to make a JeeNode (or JNµ) start up with a capacitor powered from AC mains, using as low a current trickle as possible. But unless I can find a way to shut that RFM12B down very early on, it looks like a 1 mA or so trickle will be needed to overcome this initial power “hogging” behavior.
I’m not (yet?) willing to throw more hardware at the problem, but that would be one way to work around it: use an I/O pin and a MOSFET to power the RFM12B, after the voltage is high enough to be able to overcome this dip.
In the previous post, I managed to get a JeeNode started with what I though was a 10 µA trickle, but it now looks like I was off by two orders of magnitude in those tests. It’s easy to lose track of details while making changes!
Conclusion: an AC mains power supply with 1 mA trickle is an option, but I’m not ready to give up … yet!
(You say that the first blip is the ATmega coming out of sleep. At the same time, the current jumps up to this 0.75mA the RFM draws after reset. Is this coincidence?
Ok, I see that you switch on the supply immediately to full voltage, then this is clear.)
One possible solution would be to make the capacitor so big, that after charging to the ‘startup’ voltage for the RFM12, it can hold the voltage high enough (with 0.75mA flowing) for the needed 30ms so that the RFM12 (and the ATmega) does not go into reset during this time. It should be possible to calculate the uFs needed for this (depends on how much hysteresis these two chips have between startup and shutdown voltage).
I tried this – but the RFM12B starts drawing current before the ATmega has a chance to wake up, preventing the voltage from ever reaching the 1.8V needed for the ATmega to start. The supply has to feed the cap with a trickle > 0.75 mA.
But not to worry – I haven’t used up all my arrows yet…
I have visions of you in the Apollo 13 simulator, tirelessly attempting to bring down power consumption, saving the day for all of us ;-)
Fascinating stuff, low power
What about supplying power to RF module from a GPIO pins of ATmega? Datasheet for ATmega328 say that it’s capable of sourcing 10 mA from each GPIO, but not more, than 150 mA in total. So 2-3 pins bound together should fit the bill. As a nice side-effect of this, because of GPIO voltage drop, ATmega could be powered at 4.0 volts and thus run at higher clock speed, while RF module will get it’s 3.3 volt on both power and data lines.
Forget to add most important part – powering RF module from GPIO would allow to power it up with as much delay as needed, thus allowing to bring down trickle charge current much lower.
Yes, it could work I think. You can’t rely on the voltage drop of I/O pins, though – that depends on the amount of current drawn, and would not happen with I/O lines and with the RFM12B’s power while it is not receiving or sending. Also, the ATmega is already running at 16 MHz (slightly over-clocked) from 3.3V, higher voltages would not make a difference in terms of speed.
The main issue is the number of I/O lines. Especially on an ATtiny (JNµ), there may not be any pin left, let alone several.
The advantage of your solution is that it requires no extra hardware. I’m exploring another path which does require a few more components, but the results look promising.