I even designed a PCB for this thing and had a bunch of them produced:

The good news is that it works as intended and that I’ll be using this circuit for some projects.

The bad news is that they won’t be available as kits in the shop. Ironically, this was the first time where I actually had a batch of kits all wrapped up and ready to go, ahead of time.

But the reality is that I can’t pull it off. For two different reasons:

• The circuit is connected to live AC mains @ 230 VAC and that means there is a serious risk if you build this stuff, try it out, and then hurt yourself because of some mistake. And even after that, there is the risk that the whole circuit is not properly protected, exposing these voltages (even just humidity and condensation).

• The other risk is that once everything works, it gets built-in for permanent use and becomes part of your house. What if it gets wet or malfunctions for some other reason, and your house burns down?

As supplier, I’d be liable (rightly so, BTW – there is no excuse for selling stuff which might be dangerous).

The hardest part of all is that even if an accident has nothing to do with this Low-power Supply, I still have to prove that this stuff is safe under any circumstance and that it complies with all regulations!

I’m not willing to go there. Life’s too short and I don’t have the pushing power to go through it all.

Having said this, I do intend to use this supply myself and create all sorts of nodes for use here at JeeLabs. Because I know the risks, I know which failsafe features have been built into the supply, and I’m ok with it:

The design is available in the Café, to document what I’ve done and for others to do whatever they like with it.

I’m not happy about this decision, in fact I hate it. I’m really proud of finding out that it is possible to create sensor nodes which run off just 12 mW of AC mains power. But the right thing to do is to stop here.

So now, the JNµ can be put to sleep as well. Here’s the jouleTest sketch I used, tweaked to run on the JNµ as well:

And sure enough, about once every 10 seconds it shows that familiar packet-transmit current consumption:

The blue line is the AC-coupled supply voltage, a 3x AA Eneloop battery pack in this case. It supplies about 3.8V, but when running off a 1000 µF cap, it looks like this continues to work down to 1.8V (well below the RFM12B’s minimum 2.2V specs) – although with only about half the transmit power by then.

This current use fingerprint is almost identical to the ATmega328 running this same code. Not surprising really, since it’s the RFM12B which determines most of the power consumption, not the ATmega vs ATtiny difference.

Onwards!

Hooking up such a tiny chip is quite a challenge:

The trouble is that this stuff can’t be spread out too much – the specs say that both input and output caps have to be within 5 mm of the chip. So I tied it to a pcb – mostly for stability – and then wired everything up around it.

Without any load, this thing operates in quite an efficient mode:

The yellow trace is the voltage drop across a 10 Ω low-side resistor, the blue trace is the output, but AC coupled, i.e. showing only the ripple voltage.

The red line is the math function to integrate total power use in Coulombs – more on that later.

If you look at the top overview graphs, you can see the current blips which are over 160 ms apart, i.e. this thing is activating only 6 times a second. And each current pulse lasts only about 150 µs. The peak current on the input side, i.e. drawn from the battery, is about 12.5 mA.

Let’s put a 1 kΩ load on the 3.3V output line:

I’ve adjusted the scale a bit. The switcher is now operating at about 11 KHz. The peak current drawn is almost 18 mA, but note also that the current never drops to 0 anymore – the baseline of that yellow trace is 2 divisions down from the top, so that’s about 6 mA (as expected, since the load is always drawing current).

Now let’s push it and change the output load to 100 Ω, i.e. about 33 mA @ 3.3V. To make that work, I had to change the input sense resistor to 1 Ω:

The baseline for the yellow trace is now halfway, same as for the blue line.

I also added a third probe, the green line monitors output voltage, which is indeed steady at 3.3V (both red and green lines are based at the bottom of the screen). Note the huge peak current draw on the battery: over 290 mA!

Let’s try to understand what’s going on in this last case. First of all, with a 1 Ω sense resistor, a 190..290 mA current draw creates a voltage drop of around 0.25V – which means the battery voltage isn’t really reaching the switching regulator. The battery was measured to be at 1.37V, so the switcher is getting only about 1.1V on average. The datasheet says that it will only be 70..75% efficient on such an input voltage, when generating the 3.3V output.

The 100 Ω output load draws about 33 mA. That’s at 3.3V, so a perfect step-up regulator would need to draw 3x as much when running off 1.1V, i.e. 100 mA. A 70% efficient switcher would draw about 150 mA (0.70 x 150 ≈ 100). What I’m seeing here is more like a 40% efficient switching result (0.40 x 250 = 100) – hm, not sure why…

The other way to determine average current consumption, is to do some Coulomb counting…

In the first screenshot, each blip uses about 900 nanocoulombs (the red line rises 4.5 divisions over the entire width of of the screen). With 6 blips per second, we use 5.4 µC each second, i.e. 5.4 µA average current draw (not quite the 1.6 µA I expected, but still very impressive for an unloaded step-up regulator).

The second graph is trickier. We need to figure out the Coulombs increase per repetitive cycle. My guess would be around 820 nC. Multiply by the switching frequency of 11.25 KHz, and you get 9.2 mC per second, i.e. 9.2 mA average battery current to deliver about 3.3 mA @ 3.3V.

Gotta be a bit careful here. It turns out that the battery (which is a bit old), still delivers 1.44V at this lower power level. Also, since I’m using a 10 Ω current sense resistor in this case, there’s 92 mV wasted in that resistor. That leaves about 1.35V going in. A perfect switcher would draw 3.3V / 1.35V * 3.3mA = 8.07 mA. We’re pulling 9.2 mA, which is about 87% efficiency. That seems a bit optimistic, since the AS1323 doesn’t really go much further than 80%. Oh well, there are probably several measurement errors in my quick and dirty test setup.

For the third case with the 100 Ω load, I end up with a figure of 215 mC/s, i.e. an average current draw of 215 mA. Better than before but still under 50% efficiency.

One more datapoint: with a 100 kΩ load, the switching frequency goes to 120 Hz, while still using about 800 nC per cycle, i.e. ≈ 100 µC per second, or 100 µA. Again, pretty good for what is essentially a 33 µA load @ 3.3V – even if all these estimates are off by perhaps 25%.

So this chip might work quite well for bursty ultra-low power contexts such as a mostly-sleeping JeeNode!

It does all the right things to start off in low-power mode and puts the ATmega to sleep, even as the LED blinks!

The LED is a normal red LED with a forward voltage of about 1.6V and with a 470 Ω series resistor. The result:

(lots of noise because I’m using the default 1:10 probe and the scope at its most sensitive 1 mV/div setting)

Voltage over the 100 µF reservoir cap in blue, current consumption in yellow. You can see the startup dip when the cap reaches about 6V, then the 2s wait, and then the LED blink at about 2 Hz with a 10% duty cycle. There’s not much energy to spare – the reservoir cap doesn’t even get a chance to fully re-charge between blinks.

After about 4 seconds, I turned off the power to find out what would happen. Yet there’s still enough energy left to get two more full blinks, and then an aborted blink as the reservoir cap voltage drops below 3V.

Note how the power consumption is just 3 mA while the LED is turned on. The ATmega itself is hardly ever running (the very brief 10 mA peaks got filtered out in this scope capture).

It can even be made to flash with a 26 mA LED current (omitting the resistor) for 16 ms @ 2 Hz. In this case the reservoir cap voltage varied from 9.4 to 4.4 V, again leaving very little energy to spare. Maybe one day this can be refined to drive a TRIAC, which needs very frequent but brief pulses (a BT137, BTA312, or L6004L3?).

But there’s actually something extra-ordinary going on with that power-up sequence – let’s investigate:

The BIG surprise? This is running on a standard JeeNode with standard bootstrap – no power-up troubles at all!

Let me try and interpret everything happening in that last image:

• the initial very high blip (over 25 mA) is the JeeNode’s on-board 10 µF capacitor charging up
• the 65 ms @ 3.2 mA is the clock startup delay, as defined by the default fuse setting
• up to this point, the reservoir cap has lost some 2V of its charge
• the next blip is the boot loader passing control immediately to the sketch (!)
• then there’s the 32 ms loseSomeTime() call in setup(), with the ATmega finally powered down
• the last blip at the right-end side of the screen puts the RFM12B into low-power sleep mode

So what’s going on, and above all why is the boot loader problem gone, after all that trouble it gave me before?

The only explanation I can think of lies in the one change I made since then: I’m now using OptiBoot v4.4 … and it probably does the right thing, in that it skips the boot loader on power-up and only goes through a boot-loader sequence on reset. This is the well known ladyada fix. I guess my previous boot loader setup wasn’t using that.

This is really good news. It means you just need a recently-flashed ATmega and you can continue to use the normal FTDI upload mechanism while fooling around with this ultra low-power stuff. Even the 10 µF cap and regulator on the JeeNode can be left in when powering it from the new Low-power supply.

I made a few small improvements to that sketch:

1. the RFM12B is powered down at the end, so that the unit only consumes a few µA’s once done
2. the programming rate has been improved by getting rid of those horribly slow digitalWrite() calls, etc.
3. updated RF12demo and OptiBoot to the latest version (v8 and v4.4, respectively)

Furthermore, I switched from the funky switches to plain jumpers, with the following layout:

Another change is that the default with no jumpers is now to burn RF12demo w/ OptiBoot for use with a 16 MHz resonator – this is a good default for JeeNodes, JeeNode USB’s, and JeeNode SMD’s. To select the other options, just hook this up to USB, change the jumpers, and watch the serial output report on reset.

This is the output with no jumpers and no target board attached:

This is the output after a normal programming cycle (again, the default case, no jumpers installed):

Programming takes only a few seconds. Note that this programmer is fully self-contained and includes its own LiPo battery, so all you need to do is press the 6 pins on the ISP header pads. The neat thing is that due to the normally-discharged cap on the target board, the brief power dip caused by touching the ISP pads will generate a hardware power-on reset in the programmer, which then immediately starts its programming cycle.

So the the whole workflow is now as follows:

• grab this thing – and let’s call it a “Portable ISP Programmer” (PIP!)
• press the pins against the ISP header of the unit to be re-flashed
• watch the initial LED blink on the programmer as it comes out of reset
• wait 2..3 seconds
• watch the second LED blink, indicating that it has successfully completed programming

There is no power switch, since the programmer enters total power down when done. To re-charge, plug the programmer into a USB port and wait for the “charge” LED to turn off. Note that pressing the reset button also works, but that it adds a small boot loader delay before the isp_repair2 sketch gets started.

This has become so convenient, that I can now take any old JeeNode lying around here, and reset it to a well-known state in just a few seconds, before re-using it for some project or experiment.

The problem was to come up with a robust way to connect to the target board, but I think I’ve found a solution:

Take a 4-pin header, slightly enlarge the holes in the plastic, and then gently-but-forcefully press a couple of Pogo pins in there. I’m using the type with a large head with sharp edges. Here’s the whole assembly:

After that, it’s a matter of attaching all the wires and tying / glueing things together:

These units are all refurbished ones with a defective radio, since that’s not needed here.

The ZIP straps hold the battery and wires in place. The hot glue does the rest:

These programmers are considerably more effective than you might think – tomorrow, I’ll explain why…

Here’s the relevant code in the general-purpose Scheduler class in Ports.cpp:

And here’s what I ‘m going to change it to, to optimize and stay powered-down much longer:

This changes the wake-up period from 30 times per second, to roughly once every 8s, with blips like this:

My interpretation of this picture, is that the ATmega on this JeeNode needs a whopping 10 mA of power for 50 µs once every eight seconds to keep going. That 1 ms “lead-in” at < 1 mA is probably clock startup, or something.

This current draw is the same as before (this capture was with PIR installed). But instead of 1800 wake-ups per minute, there will now be 10 or so. This will reduce the power consumption from 2,000 µC to roughly 10 µC!

Does that mean the Room Node will now last 200 times longer on a single battery? Unfortunately, no. With these low-power games, the weakest link determines total battery life. In this case, there’s a PIR sensor which has to be constantly on, drawing about 50 µA. That’s 3,000 microcoulombs per minute.

But still, this little optimization should add quite a bit to the lifetime of a battery:

• old: 3000 (PIR) + 130 (radio) + 600 (estimated) ATmega/regulator + 2,000 (scheduler) = 5730 µC/min
• new situation, again per minute: 3,000 + 130 + 600 + 10 = 3740 µC/min

If you’re wondering what “microcoulombs/minute” means: that’s just current, so rescaling it to µC/s (i.e. µA’s), we get: old ≈ 96 µA, new = 63 µA. With a 2000 mAh 3x AA battery pack, that’s 2.5 vs 3.6 years of run time.

Note that these values are fairly optimistic. With motion in the room, there will be more than one packet transmission per minute. I have yet to see the real-life battery life of these room nodes, although right now it’s looking quite good: the nodes I have around here have been working for many months – 2012 will tell!

But either way, that change of just a few lines of C code should add about 50% to the battery life. Crazy, eh?

The yellow line is the current consumption of the entire room node. I’ve added some annotations, although there are still a few things I’m not so sure about, such as the 2.5 ms delay between SHT readout and XMIT start.

The red line is the integral of the yellow line, i.e. the total amount of energy consumed as time progresses. It took about 3 ms between the end of the packet transmission and the first ACK packet header byte coming in – this thumb-twitching with the receiver enabled accounts for about 1/3rd of the power consumption!

There is almost always room for improvement with this sort of stuff. The closer you look, you more you find things to optimize. For example, I noticed that there were blips every 32 mS or so (it’s slightly irregular):

This is zoomed in on both axes. The noise level is a bit higher, perhaps due to the 2 mV/div setting of the scope.

That’s over 1 ms @ 0.8 mA, at about 30 times per second on average. I don’t know what it is – it’s not the PIR sensor, which was removed during this measurement. Not a lot of energy per blip, but it does add up: ≈ each uses 1.1 µC, i.e. some 2,000 µC per minute. Whereas the first screen shows that a transmission takes only 130 µC.

So there you go: vampire power at microwatt levels!

Update – Ah, wait – of course! – it’s the Scheduler class in the Ports library! When idling, it lets time pass in steps of 0.1s (or rather 96 ms), and there’s no other way to do this than with 32 and 64 ms watchdog timer steps. I told you – there are no show-stoppers in this game, it works on logic and insight, all the way down!

Here’s an assembled unit, ready for testing and hooked up to power a JeeNode (w/ disabled bootstrap):

And here’s the whole test setup I had to create to check this thing out:

Lots of stuff involved, including high-voltage probe and 230V isolation transformer (to the right, out of view).

Here’s a demonstration of how it works – summarized as one elaborate scope capture:

Green is the mains voltage (235 Vrms), purple is the charge building up on the 100 µF reservoir capacitor, yellow is the regulated output, and blue is the JeeNode’s current consumption (measured as voltage drop over 10 Ω). Note how some of the voltages measured here differ more by than four orders of magnitude!

Anyway, that zoomed-in image is the clear signature of the second 8-byte RFM12B packet transmission. Current consumption varies from 23 to 26 mA. It’s a relatively coarse image, since it has been zoomed in 4,000 times.

The 3.3V supply level is reached ≈ 2s after power-up, with another 2.5s needed to fully charge the reservoir cap. You can see from the purple dips that this supply could sustain at least one packet transmit per second.

No surprises here, but it’s good to see that the PCB design works as intended. Next step: implement deep sleep on the ATtiny84 – hopefully this’ll take just some minor adjustments to the Sleepy::loseSomeTime() code.

It’s tiny – about 48 x 12 mm – even though it’s based entirely on through-hole parts. The idea is to build it up, add wires, and then encapsulate the whole thing in heat-shrink tubing to reduce the number of contact points.

It can not be repeated enough: when tied to AC mains, the ENTIRE circuit carries AC mains voltage levels!

I have a couple of configurations in mind (see yesterday’s post for the schematic):

• with C1 a 10 nF X2 cap and C4 replaced by a wire, this delivers an average of 0.3 mA on 230 VAC mains
• with C1 a 22 nF X2 cap and C4 replaced by a wire, this delivers an average of 0.3 mA on 115 VAC mains
• with both C1 and C4 22 nF caps, this supplies 0.3 mA on 230 VAC with no direct connection to AC mains
• with C1 and C4 replaced by a wire, this supply can be used with 10..24V DC in – which is great for testing
• with C1 and C4 each replaced by a 220 kΩ resistor, and R1 by a 1N4007 diode, this becomes a somewhat less efficient (but lower-profile) resistive version, again delivering up to 0.3 mA at 230 VAC

With C4 replaced by a wire, this circuit will have its “GND” output tied directly to the “N” input. This is important when powering the AC current monitor, which needs to have one side of its shunt at 0V relative to AC mains.

Note that no matter what, even with C1 and C4 both included, faults can develop in this circuit which cause the “low voltage” output of the circuit to end up directly tied to an AC mains “live” line. This is not, and will never be, a “safe” circuit. It can only be used safely while enclosed in a plastic box, with no contacts or parts sticking out.

In all cases, the on-board regulator will be activated once the input voltage rises to about 6V. This is the key to being able to power up a JeeNode or JeeNode Micro with their on-board RFM12B module.