As reported in a recent post, there were startup problems when powered from a 0.4 mA trickle-fed capacitor.
In short: it didn’t work…
The problem with a trickle-feed supply is not that the voltage level will ramp up very slowly (the brown-out detector and power-on reset circuitry should be able to handle that). The problem is that the circuit needs to draw less current than the trickle at all times – because otherwise the capacitor won’t ever reach its full charge level.
One problem was the MCP1702 voltage regulator, which has a large current draw before the input voltage reaches 3.3V where it can start regulating. So I removed the regulator, and created a setup which limits the capacitor charge to around 3.8V – thinking that without the regulator, the ATmega would at some point start up and immediately put itself and the RFM12B into sleep mode, letting the supply voltage rise a bit further.
Strangely enough, it didn’t work at all. I kept seeing a start-up spike of several milliamps. Here’s the current consumption on power-up (the scope shows the voltage over a 10 Ω resistor in series with the power supply):
That’s over 10 milliamps, for well over a second – Huh?
And then it finally dawned on me: the boot loader! The ATmega is set to look for an upload right after power-up or reset, which is what the boot loader is all about. Guess what it does: look for incoming commands on the serial port for roughly one second, before passing control to the main sketch stored in the ATmega.
Clearly, the boot loader is running at full power. Whoops!
So the first conclusion is that in this context, we can’t use a boot loader. The solution is to change the high fuse from 0xDA to 0xDB with an ISP programmer. It’ll make it harder to upload code, but there’s no other way.
Great. I thought that would solve the problem. But that’s not all. The default fuse settings also cause the ATmega to wait for 65 milliseconds on power-up. This is for crystals to get up to a stable oscillation. Unfortunately, that means the ATmega is spending 65 ms in a higher-power mode on startup.
So I changed the fuses to use the 1K / 14 CK startup mode (power-up / reset). The way I read this, it means that the ATmega will power-up after 1024 + 14 clock cycles once it comes out of hardware reset, and after 1024 clock cycles when coming out of sleep mode.
Furthermore, the divide-by-8 prescaler fuse bit needs to be set, because the ATmega will power up with a 2.7 V supply voltage (the BOD level). At that level, running at 16 MHz is way out of spec, and no doubt very unreliable.
So all in all, the following fuse settings are required:
- BOD level = 2.7V, i.e. don’t power up before the supply has reached 2.7V
- enable ÷ 8 pre-scaler on startup (can be disabled in software later)
- make the clock start up in low-power 1K / 14 CK mode
- disable the boot loader, jump immediately to the main sketch
Here is the power consumption with these changes (note the 40x X scale and 5x Y scale differences):
There’s still a 0.65 mA current draw during start-up. Unfortunately, this one is nasty: it’s caused by the RFM12B module, which powers up in this mode. Best thing I can do is put the RFM12B to sleep as soon as possible, but that can’t happen before the ATmega has started up fully. So basically, there’s a 0.65 mA current draw which we can’t get rid of (other than adding extra circuitry to control the RFM12B’s power – but see also below).
What this means, is that I’ll have to settle for a 1 mA trickle feed supply for now. It’s enough to keep charging the buffer cap, and this way things ought to finally get past that power-up hurdle.
And guess what? It works!
The cap charges until the supply reaches 2.7V, then the ATmega snaps out of reset and puts the RFM12B to sleep.
The interesting thing now, is to check whether that MCP1702 current anomaly on startup really was a problem. So I switched back to a standard JeeNode, and tried it with the above fuse settings.
Hey, it still works! So we could go back to a 12V zener charging a 100 µF cap. This puzzle has come full circle!
More good news – it looks like there is a sneaky way to avoid the 0.65 mA power-up current draw of the RFM12B: make the ATmega start up at 1.8V instead of 2.7V – the RFM12B isn’t pulling much current at that level. So if we turn it off right away then the RFM12B will be put to sleep before it gets a chance to draw too much current.
Does this work? You bet. Here is by far the craziest low-power setup I’ve ever been able to get going:
That’s a 100 µF cap charged using a 10 µA trickle. You can see the 1.8V bump where the ATmega kicks in, inits the RFM12B, puts it to sleep, and later on sends 2 packets. This is a standard JeeNode, but with special fuse settings:
- internal 8 MHz RC oscillator, fastest startup
- don’t enter the boot loader
- brown-out level is set to 1.8V
The fuse settings are: extended = 0x06, high = 0xDB, low = 0xC2.
Fascinating how everything affects everything, eh?
Update – I’m having some doubts about this last result. Will need to triple-check my calculations on this one. That last report is most definitely incorrect, there’s no way to get the RFM12B to start up with a 10 µA trickle – it starts up with the crystal oscillator active, which means that it’ll draw at least 0.6 mA until put to sleep.
Applause ! Excellent results. I think that final charging current is ~150µA, but amazingly small – a 3300pF series capacitor is enough. That’s in the range of X1/Y2 Ceramics.
It is great fun watching you enjoy yourself.
Very nice findings!
Some things are a bit strange:
why does the bootloader wait so long (1s) for a message? It should always be ok to jump to the main program (if it is there and valid) after a few milliseconds.
the RFM12 draws 0.65mA after power-up? Ok, after a POR the oscillator is enabled as well as the clock output (AFAIK), probably to be able to provide a clock to a connected controller. Would be nice to know how the RFM12 behaves if kept in reset state.
I think the boot loader has to wait a bit for incoming characters – how else would it know when to jump into action?
As for power-up current draw – yes, I intend to research this further. I’m still seeing some oddness. Note that the RFM12B is not tied to the ATmega’s h/w reset in any way, it has its own POR logic and timing. I’m going to try using the undocumented 0xFE00 software reset and see what sort of effect it has on current consumption.
The bootloaders I use just look if a valid firmware is present and then jump to this after just a few milliseconds, just enough time to receive one or two characters. It does not have to wait longer on startup. If the bootloader is invoked by a ‘master’ which wants to upload new firmware, then this master would send the ‘reset’ command and would then send the ‘here I am’ message to the bootloader a few milliseconds later (or after receiving a warmstart message from the bootloader).
My question regarding reset state was directed towards a decision to maybe make a connection to the reset of the RFM12 in future designs. At the moment, you have to rely on the fact that the AVR gets a bit earlier out of reset state than the RFM12. If this would not be the case for some reason, than the solution would not work.
Grats. Really happy to hear that. Can’t wait to buy the final thing :)
@JohnO: I now what you mean, but that still sounded soooo wrong.
Oops. So long a jcw knows what I mean, I’ll not risk it again.
Hi,
I wonder if you have thought to reuse info from your power metering experiments (the current transformer) to generate power for a node, which sits close to some often loaded line (fridge?).
It will probably be less efficient, but will be easier to install.
Or some other method which uses electro magnetic induction from the environment. One might name it elmag. smog recycle experiments :)
Good idea – I’ve added to my (infinite) list of things to try out. My first goal was a direct connection, since it’s for the AC current monitor, which already needs a direct connection anyway. But for other uses, syphoning some energy off a nearby source would be an interesting option indeed.
MarSik, this thread http://forum.jeelabs.net/comment/4282#comment-4285 is heading in that direction already
Hmmm, that leaves me wondering how you are going to measure current while at same time using it as a power source, especially when using two capacitors.
JC, I think hanging a suitable cap on the RM12 nRES pin will keep it from eating charge until the ATmega is alive and can configure it actively. A series resistor is needed to limit the current into the pin when POR cycles.
Brilliant. I’ll try that – and then I’ll have to adjust a scheduled post where I was going to admit defeat…
Alas… power consumption does not go down with nRES pulled low. The RFM12B is in a intermediate state pulling 0.6 .. 0.8 mA until the ATmega tells it otherwise. Looking again at the specs, it’s the crystal oscillator – which actually makes sense if the RFM12B’s clock output were used to drive an MPU.
Ah, then a doubled up ALD11193 in series with the RFM12B Vcc ?
Not enough current capability – the RFM12B will draw up to 25 mA at full transmit power. Drat, that would have been a nice option too.
Last try – half ALD11193 between collector and base of a series pass NPN for RFM12B Vcc
Alternatively, use an LDO with an enable pin
Running out of blades ;-)
Hm… now that’s a thought: 3.3V LDO with enable, powering entire circuit, trickle fed by 12V zener + 100 µF cap, and a circuit which disables the LDO until cap has at least 6V?
The LT1121-3.3 might do it, DIP-8 – with a voltage divider from Vin to the shutdown pin.
Exactly. Then if you still need to keep away from the zener knee, dispense with the shunt regulator by sniffing Vcc and PWM the transmission timing.
The LT1121-3.3 shutdown pin has some hysteresis built in, but a rather wide setpoint spread and tempco. An 820K -SHDN- 100K divider from Vin should allow for sinking the 6μA and flip ON around 6v. It comes at the cost of ~15μA for the divider itself; a lower loss would need an active circuit.
Thanks – I will try this. The 15 µA “loss” is inconsequential – the goal is to get away from that ≈ 1 mA charge level. I’m going to aim for 100 µA (leaving perhaps 60 µA for actual charging). An extra benefit of the regulator is that it’ll give more ADC options than just the 1.1V bandgap for the AC current monitor, since I can now assume VCC is always 3.3V.
Another very interesting LDO: MIC5281, can withstand up to 120V. Perhaps a resistive divider with a diode? IOW, eat up most of the energy in the resistor, and the rest in the LDO? Something like 1.8 MΩ + 480 kΩ would supply over 100 µA. Would have to be into a 470 µF cap (to avoid it dropping much during packet transmission). Hm, no, wait – this won’t get past the startup hump of the RFM12B…
Ok, I’ll order the LT1121-3.3.