Computing stuff tied to the physical world

Capacitive power supply

In Hardware on Jan 29, 2012 at 00:01

(Thanks for your overwhelming understanding w.r.t. not making the Low-power supply available as kit!)

The concept of the transformer-less capacitive power supply still puzzles me – intuitively I still don’t get it:

Capacitive AC DC 2

(the above image was copied from this excellent site with a web-calculcator for it all)

So what exactly is going on here? Tomorrow, I’ll simplify that circuit in an attempt to really get it, but for now let me show you what I see on the oscilloscope. What I did was feed a ≈ 100 Vpp signal into the above circuit, which is essentially the same as in the Low-power Supply.

To interpret the graph, you need some info:

  • the scope ground was connected between the capacitor and the resistor
  • the yellow trace is the voltage over the resistor
  • the blue trace is the voltage over the capacitor
  • the yellow trace is inverted, i.e. negative voltages at the top, positive at the bottom
  • zero is the middle of the screen for both signals

Here’s the scope capture:

SCR97

Ignore the fact that these waves are hideously complex, ignore the red lines for now, and also note that watching voltage over a resistor is the same as watching current through that resistor. Voltage and current are always proportional in a resistor, that’s what defines a resistor (Ohm’s law: voltage = current x resistance).

So what are we seeing here?

Well… when the yellow line is high, the blue line rises sharply. When the yellow line is zero, the blue line is flat.

That makes a lot of sense: the resistor is charging the capacitor. And similarly for negative values, it’s discharging the cap (and then charging it negatively).

So ignoring the zener and the rest of the righthand side of the circuit, this is really all that’s going on: when the input voltage is highly positive, current flows in one direction, charging the cap and dropping to zero, and when the input voltage is highly negative, the whole process unfolds in the opposite direction.

One more piece of the puzzle: current is “charge per time unit” (in units: Amperes is Coulombs per second).

In other words, the capacitor accumulates the charge pushed into it, in either polarity. And while it does so, the resistor “takes the heat”, so to speak: it limits the current by creating a voltage drop over itself.

Please let this sink in, dear reader. It’s essential to get a solid intuitive grasp on what’s going on.

Note also that it really makes no difference at all how complex the input signal is. The resistor and capacitor work in tandem, sharing the task of dealing with that signal. In other words: the capacitor is always trying to catch up!

This is where it gets interesting.

You may or may not have given up in high school when it came to advanced maths / calculus – derivatives and integrals, in particular. If so, then get ready to finally get to grips with these incredible concepts.

Let me explain the red lines in the above image – they are generated by the built-in math functions of this scope. One red line is the integral of the value measured across the resistor, and the other red line is the derivative of the voltage across the capacitor. But here’s the big surprise:

  • the integral of the voltage over the resistor is the same as the voltage over the capacitor!
  • the derivative of the voltage over the capacitor is the same as the voltage over the resistor!

What’s the point? Well, this means that I didn’t have to measure both signals to see what’s going on. I could have omitted the blue trace, because it can be calculated from the yellow trace (and vice versa). Even though these traces have completely different shapes, they are in fact totally inter-locked and inter-related.

As I said before, the voltage over a resistor is proportional to the current through it. So the derivative of the voltage over the cap is the same as the current through it (the current flowing through the resistor and the capacitor is always the same, since they are connected in series).

The derivative is the rate of change, i.e. the slope of the graph. Integrating the current (i.e. the derivative) is like adding “all the little currents together over time. A capacitor is no more and no less than a “current integrator”.

And that’s exactly the same as saying that a capacitor accumulates charge. It’s like a tiny rechargeable battery, it takes the current pushed through it and it stores that current (as charge). As the charge accumulates, the voltage rises. Loosely speaking, this is the same as saying that it pushes back harder and harder against the incoming current. At some point it pushes back so hard, that no more current comes in. At that same point, there will be zero volts over the resistor, and the voltage over the cap stays constant. Check the graph to see where that happens.

One last observation is that the blue line is a lot smoother than the yellow line. That’s not surprising: when you integrate (accumulate) a jittery signal, things tend to smooth out. That’s why capacitors are also a fundamental component in filters, i.e. circuits which let some frequencies through more and others less. That schematic we’ve been looking at here is also known as an RC circuit – if you ignore the zener and the rest. One way to look at an RC filter is to see the capacitor as the sluggish part, and the resistor as taking up the slack. So with any input signal, the voltage over the cap is related to the low frequencies, while the resistor follows more the high frequencies.

Did this explain how a capacitive power supply works? Probably not. But first we need to get to grips with what a capacitor does, and hopefully this little experiment helped you get some intuition for what’s going on.

I’ll try to take this further tomorrow, by simplifying things a bit. Stay tuned!

DIY versus outsourcing

In Musings on Jan 28, 2012 at 00:01

Currently on the front page of the JeeLabs shop:

Screen Shot 2012 01 27 at 16 15 38

The benefit of doing everything yourself, is that you can make things work exactly as you want them.

The drawback of doing everything yourself, is that you have to do everything yourself…

Having become pretty independent in my work areas, my hobbies, and my income streams over the years, I know all about those trade-offs. Or at least I think I know about most aspects of this DIY-vs-outsourcing range.

It’s a bit like trying to stay on your feet with a floor covered with marbles…

Example: I used to rent a web server (a real physical one, with full root access and Linux on it). No worries about hardware outages or connectivity details. Being housed at an ISP with thousands of servers, means they’ll have round-the-clock watchdogs and support staff, and will jump into action the minute something is seriously wrong.

At the same time, I had total control over the web server software and operating system configuration. With a Linux distribution such as Debian, maintenance was delightfully simple (“apt-get update && apt-get upgrade”).

The flip side is that I had to choose and configure a web server (“lighty” / lighttpd at the time), and technologies to create dynamic database-driven websites (I built my own back then, based on Metakit – my own database).

Did it work? Sure. Did it evolve? Nope. Too busy. Didn’t want to risk breaking anything.

Only thing that setup did was track security updates (automatically). I had two break-ins over the 10 years that this went on. Learned more about rootkits than I care about (they’re evolving to amazingly sophisticated levels).

Did I learn a lot? You bet. And some of that knowledge is priceless and timeless. Big, big benefit.

But I also had to learn lots of stuff I really care very little about. For me, network routing, package installation dependencies, mail server configuration, and lighttpd configuration were a waste of time. The latter because lighttpd wasn’t really kept up to date very actively by its developer(s). Other options became more practical, meaning that all that lighttpd-specific knowledge is now useless to me.

The story is repeating itself right now. Redmine, which I use on http://jeelabs.net/ is not up to date, because I haven’t found a simple upgrade path. The difference is that it’s not just me not updating my stuff, I now have the same stagnant state with stuff from others. So what’s the point of Redmine? As far as I’m concerned, it’s a dead end (luckily, everything in there is stored in Markdown format – a solid long-term standard which I also use for the forum and the weblog).

With the forum, running on Drupal, it’s different again. Module updates are automated more or less, so I tend to track them from time to time. But Drupal itself is a little harder to update. And sure enough, it’s falling behind… With Drupal, I’m also running into not being knowledgeable enough to put it to really good use.

But the reason for writing this post is a different one – see the message at the top.

For the web shop, I use the Shopify web store service. They have the servers (at Rackspace – very good ops, I’ve used them for a couple of years). And Shopify develop and run the web store software (using Ruby on Rails).

They take care of dealing with nasty things such as possible DoS attacks, heavy data security, financial gateway interfaces – lots of important issues I no longer need to worry about. So far so good.

But they have their own agenda:

  • some things don’t change, and that’s good: it works, the shop is operational
  • some things don’t change, but that’s bad: years have gone by, and they still haven’t got a clue about VAT
  • some things change, and that’s good: improvements to the service, new features for customers
  • some things change, but that’s bad: they change their API and their XML data structures

That last one is what bites me now. I created a little scripted setup whereby I always pull information about orders from their shop database, to fill my database here with all the details, so I can generate paper invoices, and do the fulfillment of orders here. Doing this here was necessary to be able to do the Value Added Tax thing properly, as required by law and as my accountant wants it, of course.

So to summarize, the choices are:

  1. do everything yourself (and pay in time)
  2. outsource everything (and pay in money)
  3. choose a mix (and deal with the interface changes)

Everything is a trade-off, of course. In my case, I’m moving more and more to #1 as far as operational choices are concerned (own server, own fiber connection), and #2 as far as day-to-day software use is concerned (solid, but actively developed open source software, and Apple hardware + Mac OSX for my main workplaces). These choices are optimal for me, in terms of cost and stability.

The choice to host my own servers was made a lot simpler because I’m running VM’s for the different sites, built from ready-to-run images from TurnKey Linux. What makes them (and others, like Bitnami) different, is that all VMs are automatically backed up to the cloud (Amazon S3 in my case). The way TKL does this is really clever, reducing the amount of data in incremental backups, even for all the records stored in MySQL. So not only are my VM’s pre-configured and run out of the box, they automatically self-update and they automatically self-backup – if anything goes completely wrong, I can switch to cloud-based instances and be up and running again in no time.

TurnKey Linux is an example of using third-party stuff to side-step (and in fact avoid) a massive amount of effort, while retaining maximum operational flexibiity. My Amazon S3 bill is a whopping $1.01 per month…

But the web shop setup at Shopify is far from optimal. It was supposed to be choice #2, but ended up being #3 due to the mismatch between what I need (a European shop with correct VAT handling) and what they offer (flashy stuff, aimed at the masses). In hindsight, it was a bad choice, but I really don’t want to do this myself.

Oh well, I’ll suffer the consequences – will fix my scripts and get everything going again by next Monday!

PS. My little presentation yesterday at HackersNL #5 can be found here (PDF) – for those who read Dutch.

Can’t be done

In Hardware on Jan 27, 2012 at 00:01

As you may know from posts a short while ago, I’ve been working on creating an ultra-low power supply, providing just enough energy to a JeeNode or JeeNode Micro to let it do a little work, report some data over wireless, and then go to sleep most of the time.

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

Screen Shot 2012 01 25 at 01 57 45

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:

DSC 2894

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.