Computing stuff tied to the physical world

Posts Tagged ‘AC Mains’

Automated + manual 230V

In Hardware on Apr 20, 2013 at 00:01

(This is based on an idea by Ard Jonker, who planted a seed and watched the coin drop, if you excuse the mixed metaphors…)

The recent experiment with direct relay switching suggests that it is possible to switch a latching relay with just two I/O pins tied together plus a 100 µF cap.

The thing about that circuit, is that it draws no current in either ON or OFF state – it only needs a little energy to change the state.

That means it could in principle be powered by a very low-power source, such as this other fun projects I had to shelve a while back. The reasons for this remain as valid as ever: I can’t realistically turn this into a safe kit, given the direct connection to AC mains. So while the thought of having 80 of these sprinkled around the house and consuming under 1 Watt total is a tempting thought, it just isn’t going to happen.

Which doesn’t prevent ME from using it anyway, of course…

Ok, now let’s bring a couple of components together:

  • a JeeNode Micro
  • a 12 mW AC mains supply
  • a directly-powered latching relay
  • a toggle switch
  • power cabling

Here they are, with a nice plastic case (whoops, forgot to include the JNµ, oh well):

DSC_4433

The toggle switch is the small but essential ingredient here. Let me explain:

JC's Grid, page 70

This is a switch which can be operated manually and remotely. Flipping the switch or the relay has the same effect: toggling power, regardless of the state of the other component!

This means it can be operated even when the automated system is off or disconnected, or has crashed. And likewise, the power remains under remote control regardless of the state of the manual toggle switch. This solves a key problem with all those cheap remote power switches out there: the necessity to find the remote, because there is no local switch anymore. And the fact that it breaks down when the home automation system fails.

Given the relay used, I doubt that this solution will be able to control more than 30..50 W, but there are plenty of such devices around the house these days, even LED lighting.

I think I’m gonna have to start messing with AC mains again… with caution, of course.

All power-up puzzles solved?

In AVR, Hardware on Nov 30, 2011 at 00:01

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):

DSC 2796

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):

DSC 2798

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!

DSC 2801

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:

DSC 2803

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?

UpdateI’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.

Who needs MOSFETs?

In Hardware on Nov 29, 2011 at 00:01

The “EPAD” MOSFET circuit described in an earlier post is nice, but as Ronald recently suggested in a comment, LEDs also have a nice high forward drop – so why not take advantage of that instead?

Much simpler and cheaper!

LEDs act a little bit like zeners, but they too have a somewhat round “knee” ar very low current levels. I’ve done some experiments, and have come up with a blue LED in series with a red one as suitable voltage reference:

DSC 2795

As you can see, even with 1 mA of current, they are clearly visible (especially the red one, which is a low-current type). So this also makes an excellent power-on indicator – at no extra charge – if you pardon the pun. There’s also a 1N4148 diode to a 470 µF buffer capacitor. Here are the voltages this thing seems to stabilize on:

  • 3.69 V @ 2 µA
  • 3.80 V @ 5 µA
  • 3.86 V @ 9 µA
  • 3.97 V @ 25 µA
  • 4.09 V @ 98 µA
  • 4.13 V @ 150 µA
  • 4.18 V @ 251 µA
  • 4.22 V @ 399 µA

Taking the extra diode drop into account, this leads to a very acceptable 3.04 .. 3.57 V supply voltage for a JeeNode.

So for a capacitive AC mains supply, this could be doable with 7 components:

  • a 10 nF X2 capacitor as reactive component
  • a 4.7 kΩ fusible resistor to limit the inrush current
  • a blue LED plus a red LED to create the necessary voltage drop
  • a 1N4148 across the LED for the reverse current
  • a 1N4148 from LEDs to feed the capacitor
  • a 470 µF 6.3V electrolytic capacitor for energy storage

This circuit is dangerous when directly connected to AC mains, but if a direct reference to one of the input pins is not needed, then it can in fact be made a bit safer: replace the 10 nF cap by a 22 nF unit, and add a second 22 nF cap on the other power line input (plus a second 4.7 kΩ fusible resistor for extra security). Touching the “low-voltage” side limits current to 1 mA – this should cause at most a slightly tingling sensation when touched.

I don’t know about temperature sensitivity, but in a case like this where voltage stability is not so important, this circuit might in fact be the simplest way to build a 0.1 .. 0.4 mA ultra low power supply!

Update – as pointed out by Martyn in the comments below, this circuit is not safe in case of a fault. It’s still transformerless, so it has to rely on caps to do its work – both of which can fail by shorting out. Fusible resistors are not a good enough security in terms of safety, because they don’t blow at current levels below 1 mA – they only protect the circuit from large currents in case something goes wrong.

As always: be careful with 115V and 230V AC mains!

Ultra low power supply

In Hardware on Nov 27, 2011 at 00:01

This is another post about my quest for an ultra low power supply for the JeeNode and JeeNode Micro, directly connected to AC mains (and hence dangerous, I can’t stress that enough).

To reiterate: the goal is to create a supply using at most 0.4 mA for powering a device at roughly 2.5 .. 3.5 V. With a capacitive transformer-less circuit, this should lead to a 230V power drain of under 0.1 W.

The zener diode approach doesn’t work for voltages under 6V. Low voltage zeners are too leaky.

Neither does a low-power linear regulator – maybe – driven from say a 12V zener + cap. It probably draws too much current on power-up.

A possible solution was mentioned in a 2008 article by Bob Chao, titled “Voltage clamp circuits for ultra-low-voltage apps”. It’s based on a special type of MOSFET called an “EPAD”.

There’s a chip called the ALD111933 (scary name!) which includes two of these. Here are some specs:

Screen Shot 2011 11 17 at 16 46 14

So its gate threshold is very strictly specified as 3.3V, and it can only drain just a few milliamps. Still plenty for me, though. Another design limit is that the device only supports up to 10V between source and drain.

Here’s what I have in mind as my next attempt for the ultra low power supply:

JC s Doodles page 24

The 9.1V zener will have no more than 10 µA of leakage, and the leakage of the MOSFET is negligible as long as the supply voltage remains under 3.3V. Which means all the surplus current can be used by the JeeNode – at last!

Note that there are no other voltage levels of this thing, so there’s not much leeway for charge on the capacitor to drop during high power use, i.e. packet transmission. I can think of two ways to improve on that: go back to a 470 µF cap, which will hold more charge, or add an extra diode in the MOSFET’s gate to increase the voltage level at which it triggers. Either way, I think this circuit ought to finally give me that constant trickle to keep going!

I’ve ordered the necessary parts. To be continued…

Transformers – part 2

In Hardware on Nov 21, 2011 at 00:01

Yesterday’s post described a new test setup to be able to safely experiment with low- to medium-range AC voltages. As a first check when working on new AC mains powered circuits, and to allow me to poke around.

The main idea is to use a few small transformers to create relatively weak AC power sources with a range of different voltage outputs. Here’s one way to connect their six secondary windings together:

Transformers in series

The key safety feature is the connection to ground. Anchoring the middle of the output signal to ground effectively halves the voltage when you touch one of the outputs. It also (sort of) centers the sine wave around earth ground.

Note that touching both ends of the 6 series-connected secondaries will still cause a scary 148 VAC jolt.

To make this more convenient to test with, a double-pole 11-position rotary switch will be used (the best I could find for a reasonable price). This will allow me to switch between each of the above voltages, as well as 0V.

Every position up to 92V will have at most 56V to ground, the highest two positions will make that 74V and 84V, respectively (through secondary coils designed to supply at most 20 mA). I’ll consider up to 46V to be safe.

Here are the parts I got from DigiKey – and how I would like to arrange it all:

DSC 2797

Next step is to come up with a nice box for it – the work never ends!

Transformers!

In Hardware on Nov 20, 2011 at 00:01

(No, not comic strips or movies…)

With 230V experiments becoming more commonplace here at JeeLabs, I’m worrying about safety again. It doesn’t take much to get sloppy once you do things over and over. But sloppiness and 230V don’t mix well!

Given the recent trials, and some great comments, I’d like to get back to a safer voltage level for day-to-day testing. Using the isolation transformer only for incidental cases because no matter what, 230V is tricky.

According to Wikipedia, a “safe” voltage is 50 VAC or less. According to another page, it’s even lower: 30 VAC.

Until now I’ve been using my lab supply, which goes up to 30 VDC. But that’s limited, and more importantly it doesn’t let me see the effects of AC rectification and ripple. It’s time to come up with a better test setup:

JC s Doodles page 25

A couple of small well-insulated PCB transformers, one rated 2x 18V @ 45 ma and two with 2x 28V @ 20 mA secondaries, respectively. The 18V and 28V secondaries are completely safe (by themselves) – they might damage a circuit, but they won’t harm me.

When combined, these can produce from 18 to 148 VAC. Note that 148 VAC is still over 400 Volts peak to peak, so this is serious stuff. The best way to keep the risks down is still to use low voltages as much as possible, of course.

One reason why these voltages are less risky than AC mains, is that the output current is very limited. I picked the weakest transformers I could find, meaning that their secondary coils have a high internal resistance and small magnetic cores. That and magnetic saturation should keep maximum currents limited to 20..30 mA.

Tomorrow I’ll describe a convenient hookup for all these little power sources.

Zeners – success!

In Hardware on Nov 19, 2011 at 00:01

In yesterday’s post, I reported how the 4.3V zener diode wasn’t quite cutting it – it wasted too much power.

But the new setup described in that post (12V zener w/ 100 µF cap from a 0.4 mA input trickle) works great:

DSC 2783

Note how the supply voltage recovers from a packet send within a mere 0.2 seconds. What I’m hoping now, is that with a capacitive supply on 230V, the average power supply consumption will end up well under 0.1 W.

This experiment was done with almost the same sketch as before – running on a standard JeeNode for now:

Screen Shot 2011 11 17 at 03 22 27

Every 10 seconds, a dummy packet gets sent out – as this receiving node shows:

    OK 4 0 0 0 0 0 0 0 0
    OK 4 0 0 0 0 0 0 0 0
    OK 4 0 0 0 0 0 0 0 0

And it keeps on going as long as the 0.4 mA trickle is on. It turns out that the energy consumption is so low that it will keep running for quite a while on a single 100 µF charge, before crashing into some indeterminate state:

DSC 2784

Note the time scale: 10 s/div – enough to send out six valid packets!

There’s still some nastiness to get startup reliable. I’ll probably need to mess with the BOD fuse setting and perhaps also power up with the 8x prescaler enabled, to be absolutely sure that the JeeNode doesn’t start drawing too much current before there is sufficient energy in the 100 µF capacitor.

For kicks, I tried pushing things to the limit: with a 10 µF cap, plus the 10 µF on board the JeeNode, the sketch still works, but each packet transmissions now drops the supply to a dangerously low level of about 3.7V:

DSC 2786

Eventually, sailing this close to the edge causes the node to fall into some sort of zombie state. But as you can see, it now takes only 50 mS to recharge this cap @ 0.4 mA. So could that trickle feed be reduced to – gulp – 0.04 mA? This is getting silly, but first I must get that power-up logic fixed – right now, the JeeNode isn’t starting reliably.

Anyway. It’s mind-boggling how little energy is needed to get a little bit of info across the house!

PS. I’ll stop posting oscilloscope snapshots for a while. There’s more to this weblog than scopes and signals…

Zeners?

In Hardware on Nov 18, 2011 at 00:01

If you recall the 6800 µf supply test, I used the following setup:

The problem was that this uses a 10 mA supply current as test, which is 10x higher than I want for the final 220V capacitive transformer-less version.

Trouble is, increasing the resistor to 22 kΩ didn’t work, there wasn’t enough juice to keep the JNµ running.

In a comment, Koen remarked that it might be due to the zener soft “knee”. Zeners are not perfect, they tend to cut off the voltages at a specified point, but it really depends on how much current flows. With too little current, the zener-like properties are in fact far less pronounced. Here’s what I measured, roughly:

  • 2.7 V @ 0.25 mA
  • 2.9 V @ 0.5 mA
  • 3.2 V @ 1 mA
  • 3.8 V @ 5 mA
  • 4.0 V @ 10 mA

That’s a lot of variation. In the case of the ultra-low power supply where very little current flows once the capacitor has been charged, it looks like a 1 mA “trickle” feed is not getting the energy to the right spot. Aha, found it:

Zener knee

Those zener diodes under 6V are pretty leaky! Unfortunately, I can’t seem to find any with better specs.

Time to try something else. How about the forward voltage drop of a regular diode? After all, that’s supposed to be somewhere in the range of 0.6 .. 1.0 V.

Here’s what I got with 5x the 1N4004 diode in series, and connected in conducting mode:

  • 2.6 V @ 0.25 mA
  • 2.75 V @ 0.5 mA
  • 2.9 V @ 1 mA
  • 3.1 V @ 2 mA
  • 3.3 V @ 5 mA
  • 3.45 V @ 10 mA

Hm, looks like that’s already a lot better! Next test is to replace the zener in the above circuit with 7x an 1N4004. With a bit of luck, that might provide a voltage in the proper range for the unregulated JNµ. Here’s what I get:

DSC 2777

Not bad! The 470 µF 6.3V cap charges up to 3.8 V in about 2 seconds.

Even better is that with a 4.7 kΩ simulated 0.65 mA load, the voltage drops a bit but still stabilizes at ≈ 3.15 V.

There is a major drawback, though: the forward drop over a diode tends to be very temperature-dependent :(

Here’s an idea for a different approach: add a regulator and let the capacitor charge up to say 12V. That would give a lot more energy to draw from, even if a sizeable portion of those milliwatts get “wasted” as heat. Also, it turns out that the 12V zener I used (1N5242) has a considerably better behavior – less than 10 µA when I drop 0.1 V under the zener voltage (11.8V in the unit I tested), whereas the 4.3V zener eats up most of a 1 mA trickle feed.

And lastly, there’s the idea of tracking the supply voltage with the ATmega/ATtiny itself, to let it decide when to delay a power-hungry transmission. After all, the micro-controller is able to turn itself from a 10 µA to a 30 mA power consumer, just by changing its own mode and the RFM12B from mostly power-down to full-power.

Theoretically, an MPU could in fact regulate the power supply voltage by “modulating” its current consumption!

Ok, so the new target I’d like to aim for as ultra-low power source will be: 0.01 µF X2 cap (a mere 0.4 mA trickle), 12V zener, MCP1703 regulator, and an even smaller 100 µF 16V cap, since there’s a lot more voltage drop available if you start from a full charge @ 12V. Will it work? Well, there are some surprises ahead – stay tuned…

AC Mains measurements

In Hardware on Nov 17, 2011 at 00:01

One of the things I ordered recently was a High-voltage Differential Probe. The reason for this is that I want to be able to view signals which are tied directly to 230V AC mains, both isolated and directly connected.

That’s – d a n g e r o u s – stuff, unfortunately.

And I intend to do this absolutely safely. My own safety first, of course. But also the safety of all the circuits I’m messing about with. One important trick is to simplify: the shorter the checklist of things I need to deal with, the more concentrated I can stay on the task and its risks.

With a multimeter, measuring 230V stuff goes as follows: disconnect all power, attach the multimeter, put it in the right mode, check that nothing touches anything it shouldn’t (and that all connections are solid!), stand back, turn on the power, read out the measurement, and power down again.

That’s already more than enough to worry about. Now imagine hooking up an oscilloscope and adjusting its knobs to get a good readout. Too many risks, potential for mistakes, and wires going all over the place!

I use the isolation transformer as much as possible. The voltages are still just as high between the two mains pins, but at least an accidental single connection to me or anything else isn’t a problem. The worst that can happen is a blown fuse, which in the case of the isolation setup is resettable and is set to go off at 4 amps.

Trouble is, an oscilloscope normally measures between its probe input pin and ground. Yes, ground!

One way to deal with that is to power the scope through an isolation transformer. But that’s actually one of the most dangerous “solutions” one could think of, because that means you lose all safety nets of having a safe ground attached to the instrument, its case, its probe’s BNC connectors, etc. I want more safety, not less!

Luckily, there’s a much better way to do this – but at €200 it’s not cheap:

DSC 2776

This is an isolated differential probe, which I got from BitScope. The box is 20 cm long, so it’s quite large.

Looks like there’s a fair bit of circuitry in there, too:

DSC 2773

It’ll run off an internal battery (which I just added) or off the included 9V power brick.

The point of all this is that you can put any voltage up to 1000 V between the two input pins, and that both of the pins can be up to 600 V “away” from ground potential. Yet the output will still stay within 6.5V of the scope’s ground level. The differential aspect is that it doesn’t care what the common-mode voltage excursions are, i.e. it’ll ignore any voltage which happens to be present on both inputs – only the difference is passed through.

With this probe, all you need to think about is the high voltage on the circuit and on the test leads. And as you can see, it comes with some very well-isolated cables, (huge!) clips, and test hooks. The specs are as follows:

Screen Shot 2011 11 15 at 23 05 28

The 20x range is nice for low-voltage measurements on AC-connected stuff, such as the output of a switching regulator: a scope set to 1 mV/div will be able to display signals from this probe at 20 mV/div, which is enough to view power supply ripple, for example.

Here’s a first test, simply viewing the 230V mains:

DSC 2775

Note that the vertical scale is 200x higher than indicated on this snapshot, i.e. 100 V/div (230 VAC RMS ≈ 325 VAC peak). The voltage shown here is definitely not a 100% pure sine wave – I have no idea why.

Onwards! (with caution)

Wait… make that 470 µF

In Hardware, Software on Nov 16, 2011 at 00:01

Yesterday’s post used a 6,800 µF capacitor as charge reservoir for stored energy. But wait, we can do better…

Now that I understand how discharge works out with the JeeNode in transmit mode, it all becomes a lot easier to handle. With a relatively small 470 µF 6.3V cap (still charged at 10 mA for now), I see this behavior:

DSC 2752

It’s running on 1000 x less charge than the 0.47 F supercap I started out with! Here’s the actual sketch:

Screen Shot 2011 11 03 at 01 09 37

First of all, the payload sent is now 8 bytes. Probably a reasonable amount for many uses (such as AC current sensing). Also, I’m now sending a single “a” character at the same time as the rest starting up, so there’s no need to wait for it – sending will overlap everything else that’s going on. Debugging comes for free, in this case.

What the scope shows, I think, is that the RFM12B needs about 1.6 ms to start a transmission, and that the transmission takes about 3.4 ms. The rf12_canSend() call probably returns true right away, since the RFM12B has just been woken up (this also means there’s probably no “listen before send” carrier detect in this test!).

Let’s zoom in a bit further…

DSC 2753

Ah yes, that actually makes a lot of sense (the channel 1 scale is actually 10 mV/div, not 100, and AC coupled):

  • ≈ 1 ms before “time is up”, the loseSomeTime() code switches to idle mode and draws a bit more
  • the start bit of the “a” is sent out the moment the loseSomeTime() code returns
  • brief high power consumption as the transmision is also set up and started
  • for roughly 2 ms, the RFM12B is initializing, not drawing much current
  • meanwhile, the ATmega is in rf12_sendWait(), in a relatively low-power mode
  • once transmission actually starts, a lot more current flows and the cap discharges
  • note the little bumps “up” – there’s probably a bit of inductance in the circuit!

All in all, the voltage drop is about 0.2 V, which is ok – especially in this setup, i.e. a JeeNode plus regulator.

Now, all that’s left to do is get the charging current as low as possible. I tried a 22 kΩ resistor, i.e. a 1 mA charge current, but that’s too weak right now: the voltage drops off and the node stops functioning. Looks like the JeeNode (yes, JN, not JNµ yet) is not quite in the ultra low-power mode I thought it was.

Oh, well. More work needed, but progress nevertheless!

Running off a 6800 µF cap

In Hardware, Software on Nov 15, 2011 at 00:01

The running on charge post described how to charge a 0.47 Farad supercap with a very small current, which drew only about 0.26 W. A more recent post improved this to 0.13 W by replacing the voltage-dropping resistor by a special “X2” high voltage capacitor.

Nice, but there was one pretty awkward side-effect: it took ages to charge the supercap after being plugged-in, so you had to wait an hour until the sensing node would start to send out wireless packets!

As it turns out, the supercap is really overkill if the node is sleeping 99% of the time in ultra low-power mode.

Here’s a test I did, using a lab power supply feeding the following circuit:

JC s Doodles page 21

The resistor is dimensioned in such a way that it’ll charge the capacitor with 10 mA. This was a mistake – I wanted to use 1 mA, i.e. approximately the same as 220 kΩ would with AC mains, but it turns out that the ATtiny code isn’t low-power enough yet. So for this experiment I’m just sticking to 10 mA.

For the capacitor, I used a 6,800 µF 6.3V type. Here’s how it charges up under no load:

DSC 2745

A very simple RC charger, with zener cut-off. So this thing is supplying 3.64 V to the circuit within mere seconds. That’s with 10 mA coming in.

Then I took the radioBlip sketch, and modified it to send out one packet every second (with low-power sleeping):

DSC 2746

The blue line is the serial output, which are two blips caused by this debug code around the sleep phase:

Screen Shot 2011 11 02 at 17 30 23

This not only makes good markers, it’s also a great way to trigger the scope. Keep in mind that the first blip is the ‘b’ when the node comes out of sleep, and the second one is the ‘a’ when it’s about to go sleeping again.

So that’s roughly 10 ms in the delay, then about 5 ms to send the packet, then another 10 ms delay, and then the node enters sleep mode. The cycle repeats once a second, and hence also the scope display refresh.

The yellow line shows the voltage level of the power supply going into the JeeNode (the scale is 50 mV per division, but the 0V baseline is way down, off the display area). As you can see, the power drops about 40 mV while the node does its thing and sends out a packet.

First conclusion: a 6,800 µF capacitor has plenty of energy to drive the JeeNode as part of a sensor network. It only uses a small amount of its charge as the JeeNode wakes up and starts transmitting.

But now the fun part: seeing how little the voltage drops, I wanted to see how long the capacitor would be able to power the node without being “topped up” with new charge.

Take a look at this scope snapshot:

DSC 2747

I turned on “persistence” so that old traces remain on the screen, and then turned off the lab power supply. What you’re seeing is several rounds of sending a packet, each time with the capacitor discharged a little further.

The rest of the time, the JeeNode is in ultra low-power mode. This is where the supply capacitor gets re-charged in normal use. In that last experiment it doesn’t happen, so the scope trace runs off the right edge and comes back at the same level on the left, after the next trigger, i.e. 1 second later.

Neat huh?

The discharge is slightly higher than before, because I changed the sketch to send out 40-byte packets instead of 4. In fact, if you look closely, you can see three discharge slopes in that last image:

JC s Doodles page 21

A = the first delay(10) i.e. ATmega running
B = packet send, i.e. RFM12B transmitting, ATmega low power
C = the second delay(10), only ATmega running again

Here I’ve turned up the scale and am averaging over successive samples to bring this out more clearly:

DSC 2750

You can even “see” the transmitter startup and the re-charge once all is over, despite the low resolution.

So the conclusion is that even a 6,800 µF capacitor is overkill, assuming the sketch has been properly designed to use ultra low-power mode. And maybe the 0.13 W power supply could be made even smaller?

Amazing things, them ATmega’s. And them scopes!

A “beefy” power supply

In Hardware on Nov 14, 2011 at 00:01

In a comment on the daily weblog, Jörg pointed to a very interesting chip which can directly switch 220 V.

All the parts are available as through-hole, so I decided to give it a go:

DSC 2743

I used the LNK302, with a 2.00 kΩ / 2.32 kΩ 1% resistance divider to select the output voltage. At the left there’s a fusible 100 4700 Ω resistor, a diode, and a 3.3 µF (400V!) electrolytic cap for (high-voltage) DC input.

The circuit officially only works with input voltages above 70 V, but that’s a conservative spec. It actually works fine from my 30 VDC lab supply, which means I can safely poke around in it and see how it behaves.

Time to fire up the scope again. Here’s the output with a 1 mA load:

DSC 2736

Channel 1 (yellow) is the output, but AC coupled, i.e. just the fluctuations, while channel 2 (blue) is hooked up to the same pin but in DC-coupled mode.

As you can see, the output is roughly 3.8V with brief but fairly large spikes of almost 0.3V. Basically, the switching chip periodically connects the input voltage to the output (through an inductor, and charging a 100 µF cap).

The fun begins when you start loading the supply a bit. Here’s what it does at 10 mA:

DSC 2737

Similar spikes, at roughly 10 KHz (quite a bit of variation in timing). Now 25 mA:

DSC 2738

More of the same, the repetition rate doubles to around 20 KHz, and the voltage drops a bit. Let’s go for 50 mA:

DSC 2739

It’s getting a bit jittery now, doubling its frequency every once in a while. And here’s 75 mA:

DSC 2741

Nice and steady output, the ripple voltage is under 0.2V now. Still holding at 3.2V.

Can we pull more current out of this circuit? Not really, I’m afraid – see what happens at around 80 mA:

DSC 2742

Going full speed now at around 65 KHz, but there’s simply not enough energy: the output collapses to 1.32 V.

With roughly 70 mA @ 3.2 V, input power consumption is about 20 mA @ 30 V. This isn’t stellar (37% efficiency), but also not really indicative of what it will do at 220 V, since I’m running the chip way out of spec.

I’ll need to do some tests at the full 220 VAC to make sure this behavior is similar under real-world conditions, but from what I can tell, 50..65 mA is probably about the limit of what this circuit can supply at about 3.3V. Which would be plenty for a JeeNode in full transmit mode BTW, including some additional circuitry around it.

One problem is the fairly large ripple voltage. It would be better to dimension the circuit for a 5V output, or even 12V, and then add the usual linear regulator to get it down to 3.3V for the logic circuit. This could actually be quite practical in combination with a small 12V relay (which isn’t affected by such voltage fluctuations).

Note that a circuit like this – even if it were to supply only 5 mA – would be plenty to drive a JeeNode which sits mostly in low-power mode and only occasionally needs to activate its RFM12B wireless module.

So all in all: a very interesting (non-isolated) option!

Update – Also ok on 220 V: 65 mA @ 3.0 V (draws 1.25 W, i.e. 15 %). With 2 mA @ 3.7 V, power consumption is 0.40 W (vs. ≈ 8 mW delivered, i.e. 2 % efficiency). At 80 mA, the voltage drops to 2.5 V – above that it collapses.

Capacitive transformer-less supply

In Hardware on Nov 13, 2011 at 00:01

The first AC-mains powered current node configuration used a resistive transformer-less supply. It took about an hour to charge with no load, and consumed about 0.26 Watt.

This is an improved version, using a capacitor:

JC s Doodles page 20

(Whoops, I see I forgot to draw the 470 kΩ resistor across the 22 nF cap, to discharge it when disconnected!)

The 4.7 kΩ 1/2W resistor limits inrush current – the worst case being when the cap is empty and plugged in at the top of the AC mains cycle. It’s also a “fusible” resistor, meaning that it’ll act as a fuse when overloaded for any reason. This won’t be enough to protect the circuit, let alone a person touching this circuit, but it will prevent a fire in case of a catastrophic short (which could otherwise pull over 16 amps until the mains fuse blows).

As before, it’s charging the supercap – supplying nearly 1V in this case:

DSC 2724

The 470 kΩ resistor right across that yellow 22 nF capacitor quickly drops the residual charge once unplugged.

Charging appears to go a bit faster, but there’s a problem because I’m running the ATtiny with a disabled brown-out detector (BOD). This means the ATtiny isn’t kept in reset as the voltage ramps up. As a result, it’s trying to run even at low voltages (and is bound to malfunction at voltage levels under 1.8V), but more importantly: it’s going to consume current while trying, which will prevent the supercap from charging! Which is is exactly what I see: the supercap voltage is barely rising above 1.34 V.

The BOD is an important hardware feature for circuits like these. It keeps the ATtiny in reset until the power reaches a certain level. That level is configurable for 1.8V, 2.7V, or 4.3V via the ATtiny’s fuses. In this case, 1.8V seems like the proper value to use – it will be too low for the RFM12B module which requires at least 2.2V, but this way the ATtiny can continue to run correctly even at lower levels, and then decide whether it wants to enable the RFM12B or not.

Unfortunately, I’m going to have to improve the sketch first. Right now, it just starts up and tries to do its thing, without consideration for the current voltage. Leaving the unit on for over two hours didn’t lead to a packet transmission, and only got the voltage up to about 1.8 V, whereas it keeps on rising with the ATtiny disconnected. Clearly, the ATtiny needs to become more aware of its current power state before it can act as a reliable AC current sensor. That’s the trouble with ultra-low power systems: it can be tricky to get them right!

Drat, it looks like I just messed up the fuses on the ATtiny, because I can’t reprogram it anymore. That’s the trouble with low pin-count controllers: it’s easy to mess them up!

Time to go back to separate power supply and JNµ test rigs. Let’s not muddle the issues any more than needed.

The good news is that this supply now consumes half of the resistive version, i.e. 0.13 Watt. Note that the power consumption of the resistive version could have been halved as well (see this comment). So in this case, the extra efficiency of the cap seems to be going into supplying a bit more current, i.e. charging the supercap faster.

Progress nevertheless (says the optimist): lower power consumption, faster start-up!

The AC current sensor node lives!

In Hardware, Software on Oct 28, 2011 at 00:01

At last, everything is falling into place and working more or less as intended:

    OK 17 172 31 173 31   <- 25 W incandescent
    OK 17 169 31 177 31
    OK 17 40 0 41 0       <- open
    OK 17 245 95 40 0     <- 75 W incandescent
    OK 17 140 95 245 95
    OK 17 43 0 140 95     <- open
    OK 17 39 0 43 0
    OK 17 118 2 42 0      <- 2W LED-light
    OK 17 211 2 97 2
    OK 17 219 2 102 2
    OK 17 107 2 219 2
    OK 17 89 2 107 2
    OK 17 40 0 82 2       <- open
    OK 17 39 0 40 0
    OK 17 38 0 39 0
    OK 17 219 53 38 0     <- 40 W incandescent
    OK 17 234 53 219 53
    OK 17 43 0 234 53     <- open
    OK 17 149 75 43 0     <- 60 W incandescent
    OK 17 23 0 149 75     <- open
    OK 17 42 0 23 0

That’s the log of packets coming in from the AC current node, as I inserted and removed various light bulbs. Still through the isolation transformer for now.

As you can see, every change is very clearly detected, down to a 2W LED light. These are all the bulbs with an E27 fitting I happened to have lying around, since the test setup was fitted with one of those. Some other time I’ll try out light inductive loads, chargers, and eventually also a 700 W heater as load.

I’m not interested that much in the actual readings, although there is a fairly direct relationship between these wattages and the 2-byte little-endian int readouts. The fluctuations across readings with unchanged load are small, and the no-load readout is lower than in my previous tests, perhaps the shorter and more direct wiring of this setup is helping avoid a bit of noise.

One problem I see is that some packets are lost. Maybe the way the wire antenna is laid out (quite close to the PCB’s ground plane) prevents it from working optimally.

The other problem seems to be that this node stops transmitting after a while. I suspect that the current draw is still too large, either on the ADC side (500+ samples, back to back) or due to the RFM12B packet sends (unlikely, IMO, after the previous test results). At some point the voltage over the supercap was 3.1V – I’m not sure what’s going on, since after a new power-up the unit started transmitting again.

Hm… or perhaps it’s that plus an antenna problem: when I rearranged it, things also started working again (I’m always cutting power before messing with the test circuit, of course).

But all in all I’m delighted, because this unit has a really low component count!

AC current node prototype

In AVR, Hardware on Oct 27, 2011 at 00:01

Time for some pictures. Here’s the “AC current node” prototype I’ve been working on:

DSC 2680

And in case you’re wondering: that’s a simple plastic enclosure I found a while back, which looks pretty much like (and probably was intended as) … a game catridge!

Here’s the completed unit with a test hookup:

DSC 2690

You can see the transformer-less power supply, and an ATtiny84-with-RFM12B board, which I’m tentatively calling the “JeeNode Micro” (“JNµ”) – 16 x 48 x 4 mm:

Screen Shot 2011 10 17 at 21 18 07

Please note that I’m using this for internal projects for now. I haven’t figured out whether it’s suitable for the shop, since the JNµ is different from a JeeNode in several ways, not in the least in that it requires quite a bit more hand-holding to develop “sketches” for and to load them into the unit. This isn’t even the first JNµ board – I’ve tried several different layouts in the past.

For this particular project though, it’s quite a good fit, both in size and due to the ATtiny’s differential ADC plus 20 x gain stage. I’ve yet to hook up the analog input to the sense resistor, BTW. It’s all work-in-progress…

Running on charge

In AVR, Hardware, Software on Oct 26, 2011 at 00:01

Now that the supercap charger works, and now that I’ve switched to the ATtiny84 as processor, everything is ready to create a self-contained AC current sensing node.

The one missing piece is the software for it all. It’s going to take a while to get it tweaked, tuned, and optimized, but a basic check is actually quite easy to do.

Here is the main loop if my first test, reusing most of the code already in the tiny50hz sketch:

Screen Shot 2011 10 17 at 20 03 56

My main goal was to quickly get power consumption down, so that the ATtiny would use less than what’s available through the low-power supply, i.e. roughly 1 mA. Without extra steps, it’ll draw over 4 mA @ 8 MHz.

What I did was to reduce the clock rate to 1 MHz (except while processing RF12 packets), and to turn off subsystems while not needed (timer 1 is never used, and the ADC and USI h/w is now enabled only while used).

These two lines at the top of loop() are special:

  set_sleep_mode(SLEEP_MODE_IDLE);
  sleep_mode();

They will reduce power consumption by halting the processor until the next interrupt. Since time is being tracked via the millis() call, and since that operates through a timer interrupt, there is no reason to check for a new millisecond transition until the next interrupt. This is a quick way to cut power consumption in half.

But keep in mind that the processor is still running most of the time, and running at 1 MHz. That explains why the current consumption remains at a relatively high 440 µA in the above code (with a brief “power blip” every 16 s). For comparison: in power-down mode, current draw could be cut to 4 µA (with the watchdog timer running).

Still, this should be enough for a first test. Sure enough, it works fine – powered by the ISP programmer:

    OK 17 84 2 0 0
    OK 17 67 2 84 2
    OK 17 103 2 67 2

Every ≈ 16 seconds, a 4-byte packet comes in with the latest reading and the previous reading (as 2-byte ints).

The interesting bit is what happens when the ISP programmer gets disconnected. While connected, it charged the supercap to about 4.9V – so with a bit of luck, this node should keep running for a while, right?

Guess what… it does. My test node just sent out 197 packets before running out of steam!

This includes the ≈ 500 x ADC samples and 16-second waits in each cycle. IOW, a 0.47 F capacitor charged to 4.9V clearly has more than enough energy for this application. In fact, it makes me wonder whether even a normal electrolytic capacitor might be sufficient. The benefit of a smaller capacitor would be that the node can be up and running much faster than the 1 hour or so needed to charge up a supercap.

Here’s my very very sketchy estimate:

  • let’s assume the unit operates down to 2.5 V
  • with 4.9 V charge, it can run for about 200 cycles
  • so with 3.7 V charge (on AC mains), it ought to run for 100 cycles
  • using a capacitor 1/100th the size, we ought to have enough charge for one cycle
  • with more power-saving logic, energy use can no doubt be lowered further

Given that the node is permanently powered, a 4,700 µF cap ought to be sufficient. I’ve ordered a 6,800 µF @ 6.3V electrolytic cap – with a bit of luck, that should also work. And if it does indeed, startup times will go down drastically, to hopefully just a few seconds.

Progress!

Charging a supercap

In Hardware on Oct 24, 2011 at 00:01

This is a quick experiment to see how this very low-power direct AC mains supply behaves:

JC s Doodles page 20

Note that I’ve built the 200 kΩ value from two resistors in series. This reduces the voltage over each one, and offers a slight security if one of them shorts out. The max 1 mA or so of current these resistors will let through is not considered lethal – but keep in mind that the other side is a direct connection, so if that happens to be the live wire then it’s still extremely dangerous to touch it!

One idea would be to add a “fusible” 100 Ω @ 0.5 W resistor in series with the 200 kΩ. These are metal-film resistors which will disconnect if they overheat, without releasing gases or causing flames. I can’t insert it in the other wire due to the voltage issue, so I’m not really sure it actually would make things any safer.

Here’s my first test setup of this circuit, built into a full-plastic enclosure:

DSC 2687

It took 20 minutes to reach 1.8V, the absolute minimum for operating an ATtiny. This is not a practical operating voltage, because whenever the circuit draws 1 mA or more, that voltage will drop below the minimum again.

The RFM12B wireless module will need over 2.2V to operate, and draw another 25 mA in transmit mode. The only way to make this work will be to keep the transmit times limited to the absolute minimum.

Still, I’m hoping this crude power supply will be sufficient. The idea is to run on the internal 8 MHz RC oscillator with a startup divider of 8, i.e. @ 1 MHz. The brown-out detector will be set to 1.8V, and the main task right after startup will be to monitor the battery voltage until it is considered high enough to do more meaningful work.

With 3.5V power, an ATtiny draws ≈ 600 µA @ 1 MHz in active mode and 175 µA in idle mode, so in principle it can continue running at this rate indefinitely on this power supply. But for “fast” (heh) startup, it’ll be better to use sleep mode, or at least take the system clock down well below 1 MHz.

This might be a nightmare to debug, I don’t know. Then again, I don’t have to use the AC mains coupled supply to test this. A normal low-voltage DC source plus supercap would be fine with appropriately adjusted resistors.

After 35 minutes, the voltage has risen to 2.7V – sure, take your time, hey, don’t rush because of me!

Another 5 minutes pass – we’re at a whopping 3.0V now!

Time for a cup of coffee…

After 45 minutes the charge on the 0.47F supercap has reached 3.3V – yeay! I suspect that this will be enough to operate the unit as current sensor and send out one short packet. We’ll see – it’ll all depend on the code.

After 1 hour: 3.75V, which is about as high as it will go, given the 5.1V zener and the 2x 0.6V voltage drop over the 1N4148 diodes. Update: my test setup tops out at 3.93V – good, that means it won’t need a voltage regulator.

Apparently, supercaps can have a fairly high leakage current (over 100 µA), but this decreases substantially when the supercap is kept charged. In an earlier test, I was indeed able to measure over 2.7V on a supercap after 24 hours, once it had been left charged for a day or so. In this current design the supply will be on all the time, so hopefully the supercap will work optimally here.

Not that it matters for power consumption: a transformerless supply such as this draws a fixed amount of current, regardless of the load. Here’s the final test, hooked up to live mains without the isolation transformer:

DSC 2688

Of this energy, over 95% is dissipated and wasted by the resistors. The rest goes into either the load or the zener.

Voltage levels

In AVR, Hardware on Oct 17, 2011 at 00:01

In yesterday’s post, I described the idea of powering the AC current detector via a transformer-less power supply, using a very large capacitor or a supercap.

That means the whole circuit ends up being connected to 220V AC mains. You might think that nothing changed, since the circuit was already connected to mains via the 0.1 Ω shunt, but there’s more to it – as always!

If the power supply is tied to AC mains, then that means the circuit’s GND and VCC are also tied to these wires. The problem is that these two things interfere with each other:

JC s Doodles page 19

Because now we have a signal coming from the voltage drop generated by the shunt which is referenced to the same voltage level as the GND of the circuit. In other words, that signal we’re trying to measure now swings around zero! And while the ATtiny has a differential input, which in principle only cares about the voltage differential between two pins, it’s not designed to deal with negative voltages.

Uh, oh – we’re in trouble!

I could use a capacitor to “AC-couple” the 50 Hz frequency into a voltage divider, but that effectively creates a high-pass filter which attenuates the 50 Hz and lets more of the noise through. Not a very nice outlook, and it’s also going to require a few additional passive components. I’m still aiming for a truly minimal component count.

But we’re in luck this time. The differential ADC appears to be perfectly happy with tying one side to ground. It might not be able to measure the negative swings, but it does the positive ones just fine. When I tried it on my existing setup, I still got more or less the same readings.

Still, we do have to be careful. A negative voltage on any input pin is going to seek its way through the ESD protection diodes present on each ATtiny I/O pin. Keep in mind that we’re dealing with a very low-impedance shunt, and large currents. So it’s important to limit the effect of negative swings to avoid damage to the chip. The easiest way to do so is to include a 1 kΩ resistor in series, i.e. between signal and ADC input pin. That way, even a 1 V negative voltage excursion will drive less than 1 mA current through the ESR diode, a value which is still well within specs. Even better, that 1 kΩ resistor can be combined with a 0.1 µF cap to ground, as low-pass for the ADC.

Good, so if that weak-supply-feeding-a-big-cap idea works, then the rest of the circuit ought to continue working as intended, even though we’re operating at the limit of the ATtiny’s ADC voltage range.

All that’s left to do then, is get that power supply right. Oh, wait: and figure out a way to get a wireless setup going. Oh, and also figure out a good enclosure to keep this dangerous hookup safely tucked away and isolated.

Oh well. Not there yet, but progress nonetheless!

Finding a power source

In Hardware on Oct 16, 2011 at 00:01

Assuming I can figure out a way to transmit wireless information from the ATtiny, I’d like to make that recent AC current change detector a self-contained and self-powered unit. At minimal cost, i.e. with as few parts as possible.

That’s a bit of a problem. Adding a transformer-based power supply, however feeble, or a ready-made AC/DC converter would probably triple the cost of the setup so far. Not good.

I really only need a teeny bit of power. The techniques to a get a JeeNode into low-power sensing have been well-researched and documented by now. It shouldn’t be too hard to make an ATtiny equally low-power.

First of all, this “power sensing node” really doesn’t have to be on all the time. Measuring power once every few seconds would be fine, and reporting over wireless only when there is a significant change in detected current. So for the sake of argument, let’s say we measure once a second, track the average of three to weed out intermittent spikes, and report only when that average changes 20% or more since the last value. For continuity, let’s also report once every 3 minutes, just to let the system know the node is alive. So that’s one packet with a 2-byte payload every 3 minutes most of the time, and one current measurement every second (with the same ADC sampling and filtering as before).

What this comes down to is that we need perhaps 3.3V @ 10 µA all the time, with a 30 mA peak current draw every couple of minutes.

A battery would do fine. Perhaps 2x AA or a CR123 1/2 AA. But it feels silly… this thing is tied to a power line!

Why not use a transformer-less power supply, as described in this well-known application note from MicroChip?

Well, there’s a problem. These types of supplies draw a constant amount of current, regardless of the load. Whatever the circuit doesn’t use is consumed by the zener diode. So to be able to drive a 30 mA peak, we’d need a power supply which constantly draws 30 mA, i.e. 6.6 watts of power. Whoa, no thanks!

Here’s a basic resistive transformer-less supply (capacitive would also be an option):

JC s Doodles page 19 copy

There is a way to reduce the current consumption, since we only need that 30 mA surge very briefly, and not very often: use a big fat capacitor on the end, which stores enough energy to provide the surge without the voltage collapsing too far. This might be a good candidate for a trickle-charged small NiMh cell or even a supercap!

Hm, let’s see. If the supply is dimensioned to only supply a very small amount of current, say 1 mA, then it would be more than enough to charge that capacitor and supply the current for the ATtiny while in power-down mode. A 0.47 F supercap (which I happen to have lying around) ought to be plenty. This power supply would draw 0.22 W – continuously. Still not stellar, but not worse than several other power bricks around here.

Alas, such a design comes with a major drawback: with such a small current feeding such a large cap, it will take ages for the initial voltage to build up. I did a quick test, and ended up waiting half an hour for the output to be useful for powering up an ATtiny + RFM12B. That’s a lot a waiting for when you plug in such a system for the first time, eager to see whether it works. It also means that the firmware in the ATTiny has to very careful at all times with the limited energy available to it.

Still, I’m tempted to try this. What’s half an hour in the grand scheme of things anyway?

AC measurement status

In AVR, Software on Oct 12, 2011 at 00:01

Before messing further with this AC current measurement stuff, let me summarize what my current setup is:

JC s Doodles page 17

Oh, and a debug LED and 3x AA battery pack, which provides 3.3 .. 3.9 V with rechargeable EneLoop batteries.

I don’t expect this to be the definitive circuit, but at least it’s now documented. The code I used on the ATtiny85 is now included as tiny50hz example sketch in the Ports library, eh, I mean JeeLib. Here are the main pieces:

Screen Shot 2011 10 07 at 00 32 58

Nothing fancy, though it took a fair bit of datasheet reading to get all the ADC details set up. This sketch compiles to 3158 bytes of code – lots of room left.

This project isn’t anywhere near finished:

  • I need to add a simple RC low-pass filter for the analog signal
  • readout on an LCD is nice, but a wireless link would be much more useful
  • haven’t thought about how to power this unit (nor added any power-saving code)
  • the ever-recurring question: what (safe!) enclosure to use for such a setup
  • and most important of all: do I really want a direct connection to AC mains?

To follow up on that last note: I think the exact same setup could be used with a current transformer w/ burden resistor. I ought to try that, to compare signal levels and to see how well it handles low-power sensing. The ATtiny’s differential inputs, the 20x programmable gain, and the different AREF options clearly add a lot of flexibility.

Onwards!

AC current detection works!

In AVR, Software on Oct 10, 2011 at 00:01

As promised, the results for the ATtiny85 as AC current detector, i.e. measuring current over a 0.1 Ω shunt.

Yesterday’s setup showed the following values in the display:

    30 71-101 68.

From right to left, that translates to:

  • it took 68 ms to capture 500 samples, i.e. about 7 KHz
  • the measured values were in the range 71 .. 101
  • the spread was therefore 30

With a 75 W lamp connected, drawing about 100 mA, I get this:

DSC 2677

With the 25 W lamp, the readout becomes:

DSC 2673

And finally, with a 1 kΩ resistor drawing 20 mA, this is the result:

DSC 2679

As soon as the load is removed, readings drop back to the first values listed above.

Now it seems to me that these readings will be fine for detection. Even a low 20 mA (i.e. 4.4 W @ 220V) load produces a reading with is 30 times higher than zero-load (with about 10% variation over time).

I’m measuring with 2.56V as reference voltage to remain independent of VCC (which is 3.8V on batteries). So each step is 2.5 mV with the built-in 10-bit ADC. With the 20x amplification, that becomes 0.125 mV per ADC step. Now let’s see… a 20 mA DC current across a 0.1 Ω shunt would generate a 2 mV differential. I’m using an order 31 moving average, but I didn’t divide the final result by 31, so that 1099 result is actually 35 on the ADC. Given that one ADC step is 0.125 mV, that’s about 4.4 mV peak-to-peak. Hey, that looks more or less right!

There is still a problem, though. Because half of the time I get this:

DSC 2675

Total breakdown, completely ridiculous values. The other thing that doesn’t look right, is that none of the readings are negative. With a differential amplifier fed with AC, one expects the values and signs to constantly alternate. Maybe I damaged the ATtiny – I’ll get another one for comparison. And maybe I didn’t get the sign-extensions right for the ADC’s “bipolar differential” mode. There’s a lot of bit-fiddling to set all the right register bits.

But still… this looks promising!

Update – Problem solved: it was a signed / unsigned issue. The values are now completely stable with under 1 % variation between measurements. I’m not even filtering out high frequencies, although I know I should.

More sensitivity

In Hardware on Oct 9, 2011 at 00:01

Yesterday’s post was nice, but it stepped over one teeny weeny little detail: the ATmega’s ADC isn’t sensitive enough to measure AC signals in the millivolts range. With a 3.3V reference, each step is ≈ 3.3 mV, while the signals at low power levels are close to a single ADC step. I could bump the sensitivity slightly by using the 1.1V bandgap as ADC reference voltage, but that still only gets me to 1.1 mV steps. Hardly enough to apply filtering to and set thresholds.

Ah, but there’s a way out… (there always is!)

The ATtiny85 is the smaller brother of the ATmega with a frighteningly low pin count of 8. The key is that it has a differential ADC option, i.e. it’s able to measure the voltage between two points (within 0..VCC) and that it has an optional 20 x analog signal amplifier built-in, when used in differential mode. As reference voltage, there is 1.1V, 2.56V, and VCC – providing a couple of ways to tweak the actual range and sensitivity.

Since I had the right ATtiny85 lying around, as well as TinkerLog’s prototyping board, I thought I’d give it a go:

DSC 2678

The problem with an 8-pin chip, of course, is that it only has 5 I/O pins (6 if you’re willing to use the RESET line and lose the ISP programming mode – which I wasn’t). That’s not much to interface with. The ATtiny85 I used has 8 Kb flash and 512 bytes of RAM, so that in itself should be sufficient for all the code I need.

There’s no boot loader. There’s no ready-to-use serial port. And it’s not an Arduino-compatible system, so you can’t just write sketches for it, right?

Not so fast. First of all, there’s the LCD Plug which needs only 2 I/O lines. That leaves me 3 pins: 2 for the differential analog input, and 1 for a debug LED. Plenty!

The LCD needs the Ports library. Which needs the Arduino IDE and runtime. Ah, but there’s more good news: there’s an arduino-tiny project which defines some boards and a set of “core” runtime source files which are intended to run on ATtiny85’s and other non-mega AVR chips. That’s quite a feat, btw, once you consider just how limited an ATtiny85 is (ASCII art by the arduino-tiny project):

                             +-\/-+
    Ain0       (D  5)  PB5  1|    |8   VCC
    Ain3       (D  3)  PB3  2|    |7   PB2  (D  2)  INT0  Ain1
    Ain2       (D  4)  PB4  3|    |6   PB1  (D  1)        pwm1
                       GND  4|    |5   PB0  (D  0)        pwm0
                             +----+

Still, they managed to support a couple of digital and analog I/O pins, with support for the millis() timer, analog in and out, and more. With this installed, I can write sketches and upload them via the AVR-ISP. Pretty amazing!

Sooo… just had to make a few small and obvious tweaks, and the Ports library works. There’s exactly one port (AIO1 = PB2, DIO1 = PB0, IRQ = PB1). Note that I’m using the new Arduino IDE 1.0 (beta).

That leaves me a whopping two pins for the differential analog input, which is what this is all about, after all.

Here’s my setup (hooked up to the safe 20 VAC brick):

DSC 2672

I was too excited to tidy up once the LCD hookup worked. It would all have fitted on a single (mini) breadboard.

Tomorrow, I’ll show you how this crazy little setup measures up…

Moving averages

In Software on Oct 8, 2011 at 00:01

In the comments, Paul H pointed me to a great resource on digital filtering – i.e. this online book: The Scientist & Engineer’s Guide to Digital Signal Processing (1999), by Steven W. Smith. I’ve been reading in it for hours on end, it’s a fantastic source of information for an analog-signal newbie like me.

From chapter 21, it looks like the simplest filtering of all will work just fine: a moving average, i.e. take the average of the N previous data point, and repeat for each point in time.

Time for some simple programming and plotting. Here is the raw data I obtained before in gray, with a moving average of order 349 superimposed as black line (and time-shifted for proper comparison):

O349s1

Note that the data points I’m using were sampled roughly 50,000 times per second, i.e. 1,000 samples for each 50 Hz sine wave. So averaging over 349 data points is bound to dampen the 50 Hz signal a bit as well.

As you can see, all the noise is gone. Perfect!

Why order 349? Because a 349-point average is like a 7-point average every 50 samples. Let me explain… I wanted to see what sort of results I would get when measuring only once every millisecond, i.e. 20 times per sine wave. That’s 50x less than the dataset I’m trying this with, so the 1 ms sampling can easily be simulated by only using every 50th datapoint. To get decent results, I found that an order 7 moving average still sort of works:

O7s50

There’s some aliasing going on here, because the dataset samples aren’t synchronized to the 50 Hz mains frequency. So this is the signal I’d get when measuring every 1 ms, and averaging over the past 7 samples.

For comparison, here’s an order 31 filter sampled at 10 KHz, i.e. one ADC measurement every 100 µs:

O31s5

(order 31 is nice, because 31 x 1023 fits in a 16-bit int without overflow – 1023 being the max ADC readout)

The amplitude is a bit more stable now, i.e. there are less aliasing effects.

Using this last setting as starting point, one idea is to take 500 samples (one every 100 µs), which captures at least two highs and two lows, and to use the difference between the maximum and minimum value as indication of the amount of current flowing. Such a process would take about 50 ms, to be repeated every 5 seconds or so.

A completely different path is to use a digital Chebyshev filter. There’s a nice online calculator for this over here (thx Matthieu W). I specified a 4th order, -3 dB ripple, 50 Hz low-pass setup with 1 KHz sampling, and got this:

Cheb

Very smooth, though I didn’t get the startup right. Very similar amplitude variations, but it needs floating point.

Let me reiterate that my goal is to detect whether an appliance is on or off, not to measure its actual power draw. If this can be implemented, then all that remains to be done is to decide on a proper threshold value for signaling.

My conclusion at this point is: a simple moving average should be fine to extract the 50 Hz “sine-ish” wave.

Update – if you’re serious about diving into DSP techniques, then I suggest first reading The Scientist & Engineer’s Guide to Digital Signal Processing (1999), by Steven W. Smith, and then Understanding Digital Signal Processing (2010) by Richard G Lyons. This combination worked extremely well for me – the first puts everything in context, while the second provides a solid foundation to back it all up.

Capturing some test data

In Software on Oct 2, 2011 at 00:01

(Whoops, looks like I messed up the correct scheduling of this post!)

Coming soon: a bit of filtering to get better AC current readouts.

There are many ways to do this, but I wanted to capture some test measurements from the AC shunt first, to follow up on the 220V scope test the other day. That way I don’t have to constantly get involved with AC mains, and I’ll have a repeatable dataset to test different algorithms on. Trouble is, I want to sample faster and more data than I can get out over wireless. And a direct connection to AC mains is out of the question, as before.

Time to put some JeePlugs from my large pile to use:

DSC_2661.jpg

That’s a 128 Kbyte Memory Plug and a Blink Plug. The idea is to start sampling at high speed and store it in the EEPROM of the Memory Plug, then power off the whole thing, connect it to a BUB and press a button to dump the saved data over the serial USB link.

Here’s the sketch I have in mind:

Screen Shot 2011-10-02 at 01.31.52.png

Note that saving to I2C EEPROM takes time as well, so there will be gaps in the measurement cycle with this setup. Which is why I’m sampling in bursts of 512. If that doesn’t give me good enough readings, I’ll switch to an interrupt driven mechanism to do the sampling.

Hm… there’s a fatal flaw in there. I’ll fix that and report the results tomorrow.

It just blew apart

In Hardware on Sep 28, 2011 at 00:01

Got quite a scare the other day:

DSC_2649.jpg

One moment I was cheerily plugging in and unplugging my 100 W light bulb for testing current measurements, and the next it came apart with a huge bang. No fuse tripped anywhere (as it would have in UK households).

It’s a good reminder of the amount of energy an AC power outlet can discharge at any time. In fact, the standard rating for individually-fused 220 V power groups is 16 Amps around here. That’s roughly 3600 W.

To get an idea of what that means – one Horsepower is the sustained power a horse can generate, which is about 740 Watt. So there are almost 5 horses in each power outlet, waiting to charge at you!

If you push that much energy into a liter of water, it’ll boil in 2 minutes flat. Doesn’t sound like much, eh? How about 1000 Amps at 3.3V? You’ll need copper wire with a diameter of 18 mm to handle that much current.

Compare that to a JeeNode in sleep mode drawing 10 µA, i.e. 33 microwatt. That’s 8 orders of magnitude less.

Anyway, I’ve gained some extra respect for 220V mains circuits.

Now, if only I could find a replacement … 100 W incandescent light bulbs are no longer sold in Europe.

GLCD scope on 220V

In Hardware, Software on Sep 27, 2011 at 00:01

I’m not willing to hook my Mac up to 220V through USB, whether through the DSO-2090 USB scope I have, or any other way – even if it’s tied to a galvanically isolated setup such as the recent current measuring setups. One mistake and it’d go up in smoke – I’d rather focus all my attention on keeping myself safe while fooling around with this AC mains stuff.

But there’s this little 100 KHz digital sampling scope sketch, based on the Graphics Board. Looks like it could be a great setup for this context, since it can run detached off a single AA battery.

It took some hacking on the original sketch to get a system which more or less syncs to the power-line frequency (well, just the internal clock, but that turns out to be good enough). Here’s what it shows with the input floating:

DSC_2639.jpg

Definitely usable. The three different super-imposed waves are most likely an artifact of the scanning, which takes place every 60 ms. One huge improvement for this type of repetitive readout is “digital phosphor”, like the professional DSO’s do: leaving multiple traces on the screen to intensify the readout. Single traces on a GLCD like this one end up with very little contrast, due to the lag of liquid crystals. What I do now, is leave pixels on for 10 scans before clearing the display. It’s not quite digital phosphor (where each scan fades independently), but it’s pretty effective as you can see. And this setup is a tad cheaper than that Agilent 3000X MSO I dream of…

Here’s a readout with this setup tied to the 0.1 Ω shunt in the AC mains line, with the power off:

DSC_2643.jpg

That’s three pixels of noise, roughly, i.e. some 10 mV.

With a 60 W light bulb turned on, we get this:

DSC_2641.jpg

Not bad at all! It looks like with a bit of smoothing and averaging, one could turn this into an ON / OFF signal.

Alas, the sensivity does leave to be desired. With a 25 W light bulb:

DSC_2644.jpg

That’s barely above the noise threshold. It might be difficult to obtain a reliable detection from this, let alone at lower power levels. The 1W power brick showed almost no signal, for example.

Note that with North-America’s 110V, the readout would be twice as sensitive, since it’s measuring current.

Still, these results look promising. Here is the <cough> DSO with digital phosphor </cough> sketch I used:

Screen Shot 2011-09-26 at 15.52.38.png

This code can be found as “glcdScope50” example in GLCDlib on GitHub.

Fun stuff. Just look how simple it is to gain new insight: a few chips, a few lines of code – that’s all it takes!

One piece of the puzzle

In Software on Sep 22, 2011 at 00:01

The measurement anomalies of the recent experiments are intriguing. I don’t want to just tweak things (well, up to a point) – I also want to explain what’s happening! Several insights came through the comments (keep ’em coming!).

Let me summarize the measurement algorithm: I measure the < 1 VAC peak-to-peak voltage ≈ 5000 times per second, and keep track of a slow-moving average (by smoothing with a factor of 1/500-th). Then I calculate the arithmetic mean of the absolute difference between each measured value and that average. Results are reported exactly once every second.

Some notes:

  • noise should cancel out for both the average and the mean values, when the signal is large
  • noise will not cancel out if it is larger than the fluctuation, due to the absolute function

There’s also another problem:

JC s Doodles page 15

I’m not synchronizing the averaging period to the power-line frequency, nor taking zero crossings into account.

This matters, and would explain up to some 2% variation in the measurement. Here’s why:

  • each 1-second sampling period measures about 50 cycles
  • let’s assume it’s 49-cycles-and-a bit
  • the extra “bit” will be residuals at both ends
  • the 49 cycles will be fine, averaged from zero-crossing to zero-crossing
  • but the ends may “average” to anything between 0 and 100% of the true average for entire cycles
  • so 1 of the 50 cycles may be completely off, i.e. up to 2% error (always too low)

So it looks like there are two measurement issues to deal with: noise and the lack of zero-crossing syncing.

It doesn’t quite explain the extreme values I’ve been seeing so far, but for now I’ll assume that an excessive amount of noise is being picked up in my crude breadboarded circuit and all the little dangling wires.

Shielding, digital noise filtering, and syncing to zero-crossings… quite a few things to try out!

A simpler direct connection

In Hardware on Sep 21, 2011 at 00:01

Now that direct connection to AC mains is no longer out of the question (at least to establish a baseline), I decided to create a much simpler hookup:

DSC 2633

That’s a 0.1 Ω resistor in series with the load and two diodes, all in parallel. The diodes are not that useful for load protection (anything over 1000 W will be a problem), but they may help with transients and spikes:

DSC 2633  Version 2

Note that the sense wires are attached to the shunt resistor. If anything were to get yanked loose by accident, then it would be those wires, not the shunt itself. As usual, this is all hooked up via an isolation transformer.

A quick check tells me that this setup does not perform any better than the previous direct connection with the sketch I’ve been using all along.

Even without anything plugged in, I can affect the readings by moving my hands close to the circuit:

    reading:RF12-868.5.17:oneLong:value = 28250
    reading:RF12-868.5.17:oneLong:value = 28247
    reading:RF12-868.5.17:oneLong:value = 28184
    reading:RF12-868.5.17:oneLong:value = 28637
    reading:RF12-868.5.17:oneLong:value = 33743
    reading:RF12-868.5.17:oneLong:value = 77924
    reading:RF12-868.5.17:oneLong:value = 92240
    reading:RF12-868.5.17:oneLong:value = 50233
    reading:RF12-868.5.17:oneLong:value = 30663
    reading:RF12-868.5.17:oneLong:value = 28476
    reading:RF12-868.5.17:oneLong:value = 28176
    reading:RF12-868.5.17:oneLong:value = 28145
    reading:RF12-868.5.17:oneLong:value = 29082
    reading:RF12-868.5.17:oneLong:value = 34851
    reading:RF12-868.5.17:oneLong:value = 43977
    reading:RF12-868.5.17:oneLong:value = 54547
    reading:RF12-868.5.17:oneLong:value = 62388
    reading:RF12-868.5.17:oneLong:value = 61987
    reading:RF12-868.5.17:oneLong:value = 61366
    reading:RF12-868.5.17:oneLong:value = 62199

So the next step will be to add filtering. Either analog or digital, we’ll see!