Computing stuff tied to the physical world

LED discharge – PWM and DAC

In Hardware on Dec 30, 2010 at 00:01

In yesterday’s post we saw how a digital signal gets turned into something a lot more gradual, i.e. analog.

The reason for this is what I described as capacitors “dampening change” in an earlier post. This is incredibly useful in the world of Physical Computing. We can do “gradual” things with nothing but 0/1 signals coming out of a microcontroller!

The reason this works, is that capacitors mess around with the time domain. Put a “1” on them, and they will follow along eventually, i.e. a little while later. And likewise for a “0” – to bring up a previous diagram again:

This is especially useful with the timer hardware built into an ATmega. You can set up some of the pins to toggle at the rate of a hardware-controlled counter. From the ATmega328 datasheet:

Screen Shot 2010 12 29 at 23.28.11

This is a pin which is set up to generate a pulse repeatedly, and the clever bit is that you can control not just the rate, but also the ratio between on and off times. This is amazingly useful:

if the ratio is all the way off, i.e. the pin is permanently “0”, the the voltage on the capacitor in the above circuit will be 0V
if the ratio is all the way on (100% on), then the voltage of the capacitor will stabilize to 3.3V if you wait a little while
anywhere in between, and the capacitor will be charged while high and discharged while low, and end up being some intermediate voltage between 0 and 3.3V on average

On average: that’s the key. The voltage will still go up and down, but if we choose a high-enough pulse rate, then that variation will be minimal.

This is one useful way of looking at Pulse Width Modulation (PWM): 0 = 0V, 255 (on an 8-bit counter) = 3.3V, and everything in between is N/255 * 3.3V – IOW, we’ve just created a digital-to-analog converter (DAC)!

There are more ways to generate such an adjustable output voltage – see the Bleep! weblog post, for example. But if you just want a slowly adjustable analog voltage, then all it takes is one resistor and one capacitor.

And all it needs on the microcontroller, is one pin which pulses up and down in a specified ratio. The faster it does, the smoother the output voltage. The more accurately the time-off vs time-on ratio is, the more accurately we can set that output voltage. An 8-bit timer will not be able to divide the 3.3V supply voltage into more accurate steps than 0.013V, i.e. 13 millivolt, for example.

It doesn’t really matter how the pulse is generated. There are six pins on an ATmega which can generate pulses with hardware support. This is why the very confusingly-named analogWrite() function in the Arduino library can only be used on 6 specific (digital!) output pins. And it’s not really analog at all, it just becomes analog if you attach a resistor and a capacitor.

The benefit of hardware PWM, as this is called, is that the timer pulses can be made to repeat very quickly (up to some 64,000 times per second). That means a smaller capacitor will often be sufficient, and you can get either a very smooth output voltage or one which can be adjusted rapidly (but never both at the same time).

With software PWM, the pin toggling is done with software loops or timer interrupts. In that case, any output pin can be used. But this incurs a lot more processor overhead, and the pulse rates are far more limited. A while back, I posted a software PWM example to drive some LED strips (the PWM being used for brightness control in this case, even though no caps are involved). That code was almost too slow to avoid visible flickering, although some software tricks can be used to improve the pulse rate a bit.

To be continued, probably about a week from now…

LED discharge – it’s analog!

In Hardware on Dec 29, 2010 at 00:01

The LED discharge circuit presented yesterday can be used for a number of experiments. Yesterday, I asked what this sketch does:

Screen Shot 2010 12 27 at 13.19.46

Here’s what happens:

(Not sure this video will work properly with all browsers – here are MP4 and MOV links)

It’s a little bit of a trick: pin 6 is set to a “1” digital output (i.e. 3.3V) for one second, and then to an input for 5 seconds. Being an input means it no longer supplies power (or rather: a negligible trickle through the pull-up). So running the sketch is like periodically connecting a 3.3V power supply for one second and then disconnecting it for the next 5 seconds:

Screen Shot 2010 12 27 at 16.25.41

If you look at the circuit schematic again, you can see that pin 6 (i.e. DIO3) is connected to VIN. When it it at 3.3V, it will charge capacitor C1 through resistor R1.

The JP3, JP4, and JP5 pins are not used yet (analog 1 and 2 are inputs). The LED and resistor R2 are powered by the same voltage as what is currently present on the capacitor C1:

when pin 6 is high, C1 charges, and the voltage over C1 increases
the LED draws some current, and lights up
when pin 6 “floats”, C1 discharges, and the voltage over C1 decreases
the LED still lights up, but it gets dimmer as the voltage over C1 drops

Here’s a graph of the LED brightness over time, which matches what is shown in the above video:

Screen Shot 2010 12 27 at 16.31.01

There’s a lot of hand-waving in there: can’t actually know excatly what’s going on until we measure it, right?

Let’s start by measuring the voltage over the capacitor C1. Note that the bottom is tied to ground, i.e. it’s 0V by definition. The top side of the capacitor is tied to VHIGH, i.e. analog 2 (AIO3). So all we need to do is measure while waiting for time to pass:

Screen Shot 2010 12 27 at 16.55.46

Sample output:

Screen Shot 2010 12 27 at 16.53.43

Oh, wait. That’s not terribly useful. The analog converter reports values from 0..1023, corresponding to voltages 0..3.3V – so why not convert it to millivolts first? (I prefer to use ints, floating point isn’t very convenient on small 8-bit microcontrollers). This is the improved version:

Screen Shot 2010 12 27 at 17.03.29

And here’s some new output over a longer period of time, rearranged for brevity:

Screen Shot 2010 12 27 at 17.05.39

A quick copy of these values into a spreadsheet produces this graph:

Screen Shot 2010 12 27 at 17.11.14

As you can see, the measurements follow a very clear and regular pattern. But what’s going on? Why are these lines curved? Why doesn’t the voltage go all the way up to 3.3V? Why doesn’t it drop to zero? How does this graph explain the LED’s brightness changes? How can we get a constant brightness?

Questions, questions. Welcome to the real world, which – in case you hadn’t noticed – is mostly analog!

The neat bit about all this is that not only can we just play around and hook up components in all sorts of funky ways, we can in fact even explain exactly what is going on. Those graph shapes, for example, are fully predictable exponential curves, and there’s a very simple reason why they are this way.

I’ll go into that in a future post, but first let’s find out how to create an arbitrary voltage using nothing but one digital output pin. C’ya tomorrow!

LED discharge circuit

In Hardware on Dec 28, 2010 at 00:01

Yesterday’s post ended with the suggestion to play with some electronics bij hooking up some components to a JeeNode (or Arduino). This is really very useful (and oodles of fun, what a bargain), since it brings together so many aspects of physical computing:

electronics: resistors, LEDs, capacitors, charge
a microcontroller: JeeNode (or Arduino)
firmware: sketches
software: JeeMon

So let’s do it!

Here’s the initial plan, let’s see how it pans out:

set up a simple yet interesting circuit
hook it up to a JeeNode (an Arduino wold work just as well, but using 5V)
write a little test sketch to drive the circuit
use two analog input pins as a pair of DIY multimeters
report the results graphically
interpret the results and try out some variations

The circuit I’m going to use, looks as follows:

Dsc 2405

If you’re not familiar with solderless breadboards, note that those central holes in the picture are vertically interconnected in groups of five. I.e. the brown wire is connected to one side of a brown-black-red resistor on the right, as well as to one of the two wires coming out of that large black capacitor on the left. And so on.

One LED, one capacitor, two resistors, a few wires, and a JeeNode. That’s all. But as you will see, it’s enough to explore PWM and digital-to-analog conversion, and it illustrates how you can create your very own electronics workbench to explore “RC filters”, charge curves, discharge curves, pulse generators, timers, and even create a very simple oscilloscope to understand what’s going on in a dynamic electronic circuit.

The first thing I need to do is clear things up a bit. While that above picture is a fully functioning circuit, it’s pretty awkward to see exactly what is hooked up to what. Some of these components are polarized, so there’s in fact more to it than “which wire goes where”.

Here’s the same circuit, is schematic form:

Screen Shot 2010 12 27 at 12.24.48

See if you can match everything in the schematic up to that picture above.

First thing to notice, is that there’s a lot more info here, and it’s a lot more precise. The components use a standard notation, and their values are also indicated.

Now, although it was a fun exercise for me to draw this by hand and scan it in, it’s a bit tedious if I make mistakes while drawing or when things change. Fortunately, there are computer-aided design (CAD) software packages which make it simple to draw and edit such schematics on-screen. Here’s the same schematic using EAGLE:

Screen Shot 2010 12 27 at 12.37.42

It has the same layout as the hand-drawn version, but now all the components also have names: R1, R2, C1, LED1, etc. I’ll refer to these names from now on.

Ok, all nice and well, but what does the circuit DO ???

Well, first of all, since there is no energy source in there: nothing at all until you feed it from an external power source. Doh.

But this is where the fun starts. We could just hook up a battery to it (+ to VIN and – to GND), and there would in fact be some interesting behavior. But we can do a lot better than that: we can put the entire circuit under computer control! The digital output pins on an ATmega are terrific controllable power sources, as long as we only need a few milliamps at 3.3V or 5V. And if we need more… well, that’s where transistors come in (to be described in a future post).

The other great property of an ATmega (many MPUs, for that matter), is that they also have analog and digital inputs, so they can be used to measure various aspects of the circuit under test at the same time.

This is why the above circuit is hooked up to DIO3, AIO2, and AIO3 (digital 6, analog 1, and analog 2 on the Arduino, respectively).

I still haven’t told you what the circuit does. But if you’ve played around a bit with this stuff before, you should be able to predict what this little sketch does:

Screen Shot 2010 12 27 at 13.19.46

Stay tuned…

▶ View 1 Comment

Easy Electrons – Electric charge

In Hardware on Dec 27, 2010 at 00:01

Welcome to another installment of the Easy Electrons series.

The previous article was about capacitance. And specifically about the dynamic properties of capacitors. Complex stuff (literally so, in fact).

This time, I will focus on the charge and energy aspects of capacitors (and similar components).

First a small diversion into the land of electrical units: a farad can be interpreted as the amount of charge you need to create a voltage potential of 1 volt. Charge is described in terms of coulombs (named after Charles-Augustin de Coulomb). One coulomb is equivalent to 1 amp current during 1 second.

Once you start diving into this, you will be thankful for the International System of Units which created a set of units of measurement that are very easy to use and to remember. Being able to write that previous paragraph about what a farad is, without a single conversion factor or physical constant is a great help, also intuitively. I can clearly picture an amount of water (coulomb), being lifted a certain height (volt), and flowing at a certain rate (ampere). And even though the water analogy is quite limited, it’s a great help to visualize what’s “happening” inside an electrical circuit.

The farad unit is awkward, though.

It’s far too big a unit for most capacitors. You will often see caps described in terms of µF (microfarad, 10^-6), nF (nanofarad, 10^-9), or even pF (picofarad, 10^-12). Capacitors in the mF (millifarad) range are less common.

There’s another very widespread type of electricity containers: batteries. A battery is a bit like a huge capacitor, even though its “charge” is not held as electrical energy but as chemical energy. For batteries, the farad unit is also awkward, because it’s in fact too small. Let’s find out how many farad a standard 1.5V 2500 mAh AA battery would be, if it were a capacitor:

2500 mAh means it can supply 2500 mA during one hour
that’s 2.5 x 3600 = 9000 “ampere-second”
an ampere is defined as 1 coulomb per second
so the AA battery holds 9000 coulomb of charge
in our battery, that charge is “held” at 1.5V
so we’d need 9000/1.5 = 6000 coulomb to reach 1V
than means one AA battery is essentially a 6000 farad capacitor, charged to 1.5V

As you can imagine, it’s easy to make mistakes with farads because you may encounter values in normal use which vary over some fifteen orders of magnitude. Always check your zeros carefully!

Somewhere between the basic capacitor and the battery, lies the Supercap:

This is still a capacitor, but with a phenomenally high capacitance, compared to normal caps. The one shown here is 0.47 farad. No milli, micro, nano, or pico. These small devices are relatively new, and usually only work up to 2.7 or 5.5V, max.

If anything, supercaps look a lot like little batteries. They only hold their charge for a few hours though, due to a certain amount of internal leakage. Think of it as a resistor tied permanently to its output pins, draining the charge, slowly but incessantly.

One important use for capacitors (of all sizes) is as what I’d like to call “charge buffers”. This is the case whenever you see a capacitor with one side tied to negative, i.e. ground level:

Screen Shot 2010 12 12 at 21.17.17

What these do could be summarized as: resist change. If + in the left-hand image is tied to +3.3V, then the capacitor will charge up to 3.3V and then … it’ll essentially stop doing anything. But whenever there is a distubance in that 3.3V level, the capacitor will either draw current (if the voltage went up), or supply current (if the voltage went down).

It’s not that different from a rechargeable battery. Attach a voltage higher than the current battery and the battery starts charging. Attach a lower voltage, including any circuit consuming power, and the battery starts discharging.

The circuit on the right is slightly more involved, due to the extra resistor. The same happens as before, but now, as the capacitor draws or supplies current, the current has to pass through the resistor. As a consequence, the resistor will create a voltage drop (E = I x R, again!). The effect is similar to the LED circuit with a series resistor: the resistor will reduce the current flowing in or out, thus “dampening” the effect. So what you get, is that OUT lags IN, if IN changes, but eventually it’ll follow it to whatever voltage IN is.

The right-hand side is also called a low-pass RC filter. It tracks slow-moving changes fairly accurately, but rapid changes are evened out a bit.

The left-hand circuit is used all over digital circuits, to remove “noise” (i.e. very fast but random changes) in the power supply line. The noise comes from the fact that digital circuits switch connections all the time, changing electricity flow and power draw. Often a 0.1µF capacitor is used. This is usually called a “decoupling” capacitor. It rips high frequencies out of a supply line which you’d like to remain stable.

The right-hand circuit is also useful to even out variations, but in a more gradual and controlled manner. It’s used as last step in a power supply, and to even out pulse trains. One nice use of this, is to turn an PWM signal into an analog voltage:

a PWM signal which is always on will produce an output of that same voltage
a PWM signal which is always off will produce a zero volt output
everything in between will produce and averaged value in between the two extremes

There are some simple calculations to determine how fast things happen. Look for the term “RC time constant” on the web. And if you run into articles such as this one, don’t let the math discourage you. As I said in the previous post, the intricate details of capacitors involve complex calculations. Just skip them. There’s plenty you can do with caps without diving in.

Supercaps are also a lot of fun to play with. You get all the properties described above – after all, it is a capacitor like any other. The difference is that things happen a lot slower, due to the larger amounts of charge involved. Supercaps have enough energy to power an LED, for example (don’t forget the series resistor!). And when it does, you’ll see how it eventually fades and dies out, as the charge drops.

A simple experiment would be to measure the voltage over time with such a supercap driving an LED + resistor circuit. With Ohm’s law, you can then calculate the amount of current drawn. Which in turn gives you an idea how brightness in LEDs is related to the current through them. If you think that’s boring, how about measuring the voltage with a JeeNode, and then sending the results to your PC and plotting the values in real time? You may not realize it, but a lot of lab experiments related to electricity can be done with an ATmega, i.e. a JeeNode or an Arduino. Who needs a multimeter? Make one!

Easy Electrons!

Easy Electrons – Capacitance

In Hardware on Dec 26, 2010 at 00:01

This is the third installment of the Easy Electrons series.

Let’s talk about capacitance. Or more accurately: capacitors. What are they and what are they for?

My mental image of a capacitor uses the water analogy: a capacitor is like a bucket of water:

Screen Shot 2010 12 12 at 16.26.53

It’s a container, and in the case of a capacitor, it holds electrical energy. How much energy depends on how much water (electrical charge) and how high up (voltage potential) it is.

If you were to take a bucket of water to the top of the Eifel tower, you’d make a pretty hefty splash on the ground when emptying it!

Screen Shot 2010 12 12 at 16.26.43

Thinking in terms of electricity, a capacitor is a little bit like an isolator, because, when left alone, it prevents the water from going anywhere.

Capacity is measured in terms of farads, the name was chose in honor of Michael Faraday. I’ll talk more about that in a future post.

Ok, so what is a capacitor, eh?

Capacitors are funny little beasts. When you feed them with voltage or current changes, they sort of absorb them. It’s easy to visualize with the bucket of water analogy: if you hold one end of a hose submerged into the bucket and raise/lower the other end to model voltage change, you can imagine water flowing into or out of the bucket through the hose to rapidly adapt to the position (height) of the other end.

Once the current flows, capacitors immediately adapt and start to match the input voltage. Once they do, current stops. You can’t keep a constant current flowing through a capacitor. It’s not simply a conductor.

Another way to describe this, is that capacitors only affect a circuit while the voltage changes. Once it is constant, the capacitor stops playing along and will start to look more and more like a complete isolator.

This behavior is hard to grasp. You can’t just look at one state and reason from there, you have to look at the state over time and think in terms of change. Capacitance (and induction, for that matter) is substantially more complicated as concept than resistance.

But even though it’s hard, I think I can give you a feel for why it’s so tricky, using a little analogy.

When doing calculations with capacitance, dynamic systems, changes over time, and such, you’ll quickly run into something called complex numbers, a mathematical concept with immense implications in the field of electronics and other domains of physics.

Complex numbers are… w e i r d – well perhaps not as mind-bending as quantum physics, but still: complex numbers are an extension of normal numbers, in that every value consists of a real and an imaginary part. Want an example of how weird that is? How about: you can’t take the square root of a negative number such as -1, right? Because there is no value in the world which will produce -1 when multiplied by itself. Right? Wrong. With complex numbers, there is such a value (it’s called “i”, the unit of imaginary numbers).

But not to worry. I won’t expand further on complex numbers. And luckily there’s no need!

Suppose you were looking at a child sitting on a swing, swinging happily along – image on the left:

Screen Shot 2010 12 12 at 17.48.52

As you watch, you can see two things going on: a sideways motion and an up-down motion. Always mesmerizing, because there is this intriguing relationship between vertical and horizontal position and things like velocity. You’re looking at the fascinating world of complex numbers, using the analogy of a pendulum.

Now imagine yourself looking at that same child swinging, but from the back, swinging away and towards you. It’s the same situation, but you’re only seeing part of the picture – image above, on the right.

What you see, is a swing moving up and down in some smooth repeating cycle. There’s much less to reason about now. You can no longer contemplate the periodic alternation of angular velocity and potential energy (i.e. height). There’s a hidden dimension which you can’t observe. IOW, you’re no longer seeing the big picture, but only half the essential information, i.e. only the real part, not the imaginary part.

That’s what makes it so hard to build up an intuition about what capacitors do. They require a richer conceptual model. Most of us are not trained to think in complex numbers, we just see quantities as a simple numerical value.

Fortunately, this need not prevent us from dealing with capacitors. We just have to work a bit more from memorized rules and water analogies, instead of innate intuition.

This is why I think of a bucket of water, and how it “dampens” all changes it is subjected to:

Screen Shot 2010 12 12 at 17.20.41

That’s also known as a “low-pass filter”. Very useful to turn a PWM signal into an analog voltage level, for example.

And why for me, capacitors “pass electrical changes” and then “become isolators”:

Screen Shot 2010 12 12 at 18.26.30

That’s a high pass filter, by the way. It doesn’t let the flat portions of the input signal through, just the edges.

Next time: a bit more about farads, charge, and really really big caps.

Site changes

In News on Dec 25, 2010 at 00:01

Two small changes here at JeeLabs. Well, small for you, if I did my homework properly…

First, the https://jeelabs.org/ domain has been migrated to the new server, now that the new internet link appears to be stable.

This change should be mostly transparent. Same content, same format, same “content provider” as before, everything has been transferred as is.

The server and the internet link are quite a bit faster than before. Both are currently under 10% utilized, and should be able to handle growth as needed. The extra speed is particularly noticeable in the search box at the bottom right of this weblog:

Screen Shot 2010 12 24 at 14.56.13

The second small change is that “Jee Labs” will be called “JeeLabs” from now on. It’s official. No more white space. Eight bits closer to world domination :)

I’ve been wanting to get away from the two separate words for some time now, one reason being that a single InterCapped name is more googleable – and this server migration seemed like a good time to make the switch.

So better get used to it, this is the name of the new-yet-unchanged home:

Jeelabs

This was a fairly elaborate site migration for me, and now both jeelabs.net and jeelabs.org are done. I’ve got a few other changes ahead of me before the rented server (located in Nürnberg, Germany) can be taken offline. But that will have less impact and should be easy to finish in the months ahead.

Onwards!

▶ View 1 Comment

Home automation

Gas consumption

In Musings on Dec 24, 2010 at 00:01

The gas consumption at JeeLabs is enormous these days – some 15..20 m3 per day right now. One reason for this is that our house is well-insulated but very open. All the warm air tends to move 2..3 flights up, even though we try to keep all the doors upstairs tightly shut.

The trip to Germany a few days ago provided an interesting opportunity to get a better insight in how all this heating works.

Our thermostat is set up to heat the house from roughly 6:00 (6AM) to 23:00 (11PM). It’s a fairly advanced unit with some predictive logic to attain those settings, which is why it actually starts about an hourly early:

Screen Shot 2010 12 22 at 12.53.21

The above graph shows two superimposed heating cycles, with the current one still in progress (it was around 13:00 when I took that snapshot). As you can see, the heater is almost flat out, with some extra peaks during hot water use.

Here’s the gas consumption over the past 7 days:

Screen Shot 2010 12 22 at 12.51.45

The gray bands are sunset/sunrise, ie. day/night periods.

What I did was turn down the heating on Friday morning, when we left for our trip. The normal setpoint is 19..20°C, but the thermostat has a “vacation mode” which changes that into a permanent 14°C.

As you can see, the house took almost a day to cool off. Not bad, knowing that it was permanently freezing outside at that time.

On Saturday, the heating starts up a bit again, and then stays on at a reduced level most of the time, i.e. day and night, until we got back late Monday evening. Which is when I restored the normal cycle.

The interesting bit is the end effect of getting back to normal. Here are the same readings, now as totals over the entire day:

Screen Shot 2010 12 22 at 13.21.47

Same pattern as before, of course: 17th and 18th almost nothing, then slightly lower consumption rates to keep the house at 14°C, and finally on the 21st a big push to get back to our normal comfy levels.

Here are the same values, numerically:

15th – 15.71 m3
16th – 16.83 m3
17th – 3.52 m3
18th – 5.79 m3
19th – 12.40 m3
20th – 14.02 m3
21st – 28.16 m3

I should add that outside temperatures were a bit lower on the 19th and 20th, so these consumption levels cannot be compared 100% accurately.

But what stands out is that heating up the house back to 19..20° takes almost as much energy as what was saved on the days before. In other words: you can try to save all you like by turning the heater low when leaving the house – if you come back and want to get it back to the original level again, you basically have to add almost as much energy back in as if you hadn’t turned the heater down in the first place!

Heating is not a matter of “on = comfy, off = energy saving”, but one of keeping a whole pile of stones and concrete at a certain temperature. And this holds true even in very cold times. Apparently, the amount of stored energy is substantial compared to the amount of energy loss, and having a slightly cooler house doesn’t affect the rate of energy loss all that much.

This probably also explains why our gas consumption can still be 25% lower than average in this neighbourhood, despite the fact that many people are away and work elsewhere – while I keep the house heated all day long… (just a bit more sparingly than most, I guess).

▶ View 16 Comments

Snowed in

In Musings on Dec 23, 2010 at 00:01

There are worse times to be immobilized, than in this wintery time – with large parts of Northern Europe completely snowed in.

Here’s the view from JeeLabs, i.e. Houten / Netherlands, right now:

Dsc 2404

Dsc 2401

Dsc 2403

I find it absolutely gorgeous. With all the beauty of this scenery in plain view – and the nearly 30°C temperature differential across our double paned windows as reminder of the huge comfort brought about by yet another marvel of modern engineering.

Emergency stop

In News on Dec 22, 2010 at 00:01

This is a weblog post I never wanted to write…

If you’ve been waiting for stuff you’ve ordered from the JeeLabs shop in the past weeks, and it hasn’t arrived yet, then I have some really bad news for you: don’t expect anything the rest of this year…

I’m hitting the emergency stop button:

Emergency Stop

The two big issues in the past two weeks were mentioned in a recent post, and they are both of the kind I can (learn to) deal with: fluctuations in demand and fluctuations in supply, along with occasional shipping anomalies. It’s frustrating for everyone involved when this doesn’t work out well, but hey – been there done that, from both sides of the table now.

Trouble is, I’m now running afoul on a third hurdle: a couple of days ago, I strained my lower back. The trip to Braunschweig may have made it worse, unfortunately, although I had hoped these few days off would cure it. It’s most probably stress related, even though I consider myself an expert in stress avoidance. You see, normally I’m the guy who overcomes any type of setback, no matter what happens and no matter what the stress levels are. And having run a marathon 4 years ago, I have not the slightest inclination in the world to keep some mundane injury from letting me do what I love doing so much these days, i.e. taking JeeLabs further.

Except that now, I’m forced to pull all the stops on the shop. Continuing as is at this stage would be sheer folly.

There are currently some 70 back-orders. I will continue to send out packages as soon as new components come in. But given the delays of several of my orders, one of them pending for almost two months now, it’s no longer realistic to expect anything soon. The busiest delivery season of the year, a totally snowed-in infrastructure across all of Europe and beyond … it all doesn’t make the situation any better.

If you’ve been waiting for some time, please email me if you wish to cancel / get a refund and I’ll take care of it.

I’m not going to attempt to make a prediction for the next few weeks. My guess would be as good as yours. I can only wait, try and find out more about the actual status, and prepare to get things going again as quickly and smoothly as possible once everything returns back to normal.

Meanwhile, I’ve got some silly muscles to tend to… but that’s actually the easy and most predictable part!

Cheers,
– Jean-Claude

▶ View 25 Comments

JeeNode, Displays

Touch screen

In Hardware on Dec 21, 2010 at 00:01

Steve Evans (tankslappa on the forum) emailed me recently to present some really exciting developments he’s been working on: a touch screen interface for the Graphics Board:

Whatiwrote

You’re looking at a little touch screen, placed over the Graphics Board, and as you can see, the size matches up surprisingly well.

Pretty fantastic result! And considerably more precise than I had expected.

He used the touch screen overlay of the Nintendo DS, which can be obtained from eBay. As it turns out, this can be hooked up using 2 digital + 2 analog I/O pins, which is exactly what’s still available on the unused two ports.

All that was needed, were 4 pull-down resistors:

Connection

The devil is in the details, though. very small details in fact:

Tinyconnector

Steve mentioned that it took a considerable amount of patience to get 4 wires soldered to that tiny flexible ribbon, with 0.5 mm between each connection. Clearly, a proper connector would have been a bit more convenient (though just as tiny).

Being resistive and analog, this whole thing needs to be calibrated:

Calibrate 1

The code for this has been added as a sample sketch called touchscreen.pde in the JeeLabs repository.

BTW, this is part of a new GLCDlib library, which I’ll describe in more detail tomorrow. Stay tuned!

▶ View 4 Comments

Schönen Gruß aus Braunschweig!

In Musings on Dec 20, 2010 at 00:01

Not to worry, this weblog remains “mostly” English :)

Just wanted to say hello while on a very brief weekend-trip to Germany, visiting my brother…

I’ll leave you with a couple of visual impressions from this trip, including a visit to Wolfsburg (Alberto Giacometti and the “Phaeno” Science Museum) and the “Weinachtsmarkt” …

Regular scheduled transmissions to resume tomorrow…

Easy Electrons – LEDs

In Hardware on Dec 19, 2010 at 00:01

This is the second installment of the Easy Electrons series. This isn’t a “course” in electronics. Just a grab bag of topics, and an attempt to convey my somewhat intuitive grasp of them. That’s also why I’m not going to systematically cover all the usual types of components, not in the traditional order anyway.

Today’s topic is low-power signaling LEDs, or Light Emitting Diodes.

Heres a very nice exposed diagram of a standard low-power red LED, from HowStuffWorks:

Led Diagram

Schematically, a LED is shown as an arrow (same as a diode), with light coming out. Here’s the Blink Plug, with two LEDs and two switches:

Screen Shot 2010 12 12 at 14.42.29

Here is the way you hook up a single LED:

Screen Shot 2010 12 12 at 14.47.06

The arrow has to point from + to – for the LED to work. It’s a diode, meaning that in the other direction it just “blocks” (no current, nothing happens). Also note that, since this is a series circuit with LED and resistor connected one after the other, it doesn’t really matter in which order you hook them up. This circuit will work just as well if the resistor comes first. As long as + “flows” to – through the LED.

So what’s that resistor doing in there?

Well, LEDs (like any diode) are very peculiar in terms of voltage and current. They behave in a specific way:

below a certain voltage, nothing happens, i.e. no current flows
when no current flows, the resistor makes no difference at all (E = I x R, i.e. 0 x anything is still 0!)
above a certain threshold, the LED starts conducting and letting all current through
the LED only emits light above that threshold
the brightness of a LED is determined by the amount of current through it
LEDs only support a certain amount of current, any more will damage them

To use the water analogy, an LED is like a dam which will not let water through before a certain level has been reached. Once that happens, everything more spills over:

Screen Shot 2010 12 12 at 15.09.35

The threshold depends on LED type: with red LEDs, it’s usually around 1.7V, with blue LEDs, it’s more like 3V.

You can’t just connect an LED directy to a power source. Think about it. LED behavior can be graphed as follows:

Screen Shot 2010 12 12 at 14.47.16

In other words: if the voltage is too low, nothing will happen. And if it’s too high, the current through the diode will be immense (and destroy the LED). We could try to regulate the voltage just right, but it varies slightly per LED and also depends on temperature, for example. There’s no way we can adjust our power supply once and get just the right level, day in day out. Besides, often we can’t even adjust the voltage at all, such as with a battery.

So how do we solve this?

Well, that’s where the resistor comes in. This is an example of another major use of resistors: current limiting.

Again, go back to Ohm’s law, i.e. E = I x R (memorize it, please!). The more current flows through a resistor, the higher the voltage over it. Or equivalently, the higher the voltage placed on it, the more current will flow.

In the above LED circuit, the resistor will always have the input voltage minus the LEDs threshold voltage over it (once the input is higher than the threshold). The effect on the voltage and current in this circuit changes in an important way due to the extra resistor:

Screen Shot 2010 12 12 at 15.09.44

The vertical “knee” in the original LED graph has turned into a more gradual slope, due to the added resistor. As more surplus voltage is handed over to the resistor, it starts to gradually use more current. This effect is completely linear, btw. An LED with a 1.7V threshold will be twice as bright with a 4.9V power supply as with a 3.3V supply.

Ok, well, so much for the pictures. What this tells us is that we can now calculate exactly what resistor we need.

For example, say we want to light a LED using a 3.3V power supply and let 10 mA (0.01A) current flow through it, which is a good value for standard LEDs. What resistor do we need?

the LED “takes” a fixed 1.7V
that leaves 1.6V for the resistor when the supply is 3.3V
we want to get 10 mA flowing through the LED
since the resistor is in series, it’ll get those same 10 mA
E = I x R can also be written as R = E / I (same law, different usage)
so R needs to be 1.6 V / 0.010 A = 160 Ω

Take a LED, add a 160 Ω in series, and the LED will work great on a 3.3V power supply. A more easily available 150 Ω resistor will work fine too, BTW. Almost the same currrent.

What if you don’t have a 150 Ω resistor, but only a 1 kΩ one? No problem, the current through the LED then becomes: (I = E / R), i.e. 1.6 V / 1000 Ω = 1.6 mA – usally still enough to turn the LED on, but not as bright.

Easy Electrons!

Rethinking the Arduino hardware interface

In AVR, Hardware, Software on Dec 18, 2010 at 00:01

It’s been almost two years since the first design was created from which the JeeNode was born. It went from this very first prototype:

… to this leaner-and-meaner design, which is the current JeeNode v5:

Jlpcb 105

As you can see, it’s still essentially based on the same layout.

The JeeNode has been the flagship product here at JeeLabs for quite some time. It has been expanded to include a JeeNode USB variant which includes a USB interface and a LiPo charger, as well as a USB “stick-like” JeeLink that ties nicely into the WSN use of JeeNodes. And then there’s the bare-bones JeeSMD, which doesn’t have a wireless module built-in, but which is pin-compatible with the other two members of the JeeNode family.

With all the end-of-year stories coming up, and new year’s resolutions to follow soon, it seems like a good time to present my reasons for doing things this way.

Rethinking the Arduino hardware interface
That’s – in a nutshell – the essence behind the JeeNode.

I stumbled upon the fascinating world of Physical Computing and “Arduino’s” over two years ago, around the time when I also discovered an interesting low-cost wireless module. Lots of things “clicked” right away, but a few didn’t. Given that the Arduino is simply an ATmega (hardware), plus an IDE (software), plus a set of conventions (shields), I quickly realized that there might be more ways to skin this cat, and something new was born (inspired by the RBBB) – as summarized here a year ago.

I don’t want to rehash those points, but let me simply state what the JeeNode is about, assuming you know what an Arduino is.

the JeeNode lowers the operating voltage to 3.3V (implications)
it includes a wireless radio module (with software)
it drops the concept of shields (hard to combine)
instead, it adds 4 interchangeable 6-pin Ports (layout)
each port includes two dedicated I/O pins as well as power
there are numerous Plugs using this port pinout (list)
about half the plugs use (software) I2C and can be daisy-chained
there are many interface classes and code examples (here and here)
the remaining I/O pins are on two extra headers (details, PDF)
JeeNodes can be mounted upside-down (CB, GB, POF)
… or used alongside a solderless breadboard (BB)
with extension cables to move plugs further away (EC)
… or a prototype board to re-use all the I/O pins differently (PB)
reduced cost by using a detachable / reusable USB-FTDI interface

All this, while remaining fully compatible with “the” Arduino’s software + firmware.

But perhaps the most interesting bit coming out of all this, is that the JeeNode has become a practical ultra-low-power platform, with battery lifetimes measured in months, almost a year even, so far. There have already been tons of posts about this topic. It even spawned a nice little add-on to run JeeNodes from a single AA or AAA cell.

You may or may not agree with all the choices, but this is what the JeeNode is about.

Update – the Redmine repository is no longer available, everything is now on GitHub.

▶ View 4 Comments

The downside of success

In News on Dec 17, 2010 at 00:01

With over 2,500 units produced to date, it’s safe to call the JeeNode (Kit + USB + JeeLink) a success. A runaway success in fact, in my opinion.

Great, but…

This isn’t purely good news, alas. The demand for JeeLabs products has been increasing so much lately, that I’ve run into serious supply problems in the shop these past few weeks. I can assure you that I’m extremely unhappy with that state of affairs – and the pain isn’t over yet, with some parts taking weeks longer than expected to reach me. This shortage might last into January 2011 for items such as the Ether Card.

So it’s a bit awkward to talk about “success” at a time when there are still 50 back-orders in the shop (down from 90…), with probably quite a few people frustrated by the slow delivery times. A postal strike next week in the Netherlands and the extra delays due to the busy Christmas season are clearly not going to help one bit.

Summary: the JeeNode design has been working out very nicely, but my ability to make it properly available is lagging far behind. My only way out is to “get larger quantities – sooner”. Which is exactly what I’ve been doing lately, in collaboration with Modern Device, who have started carrying more and more JeeLabs products for the US and nearby regions. We’re both scaling up, while trying not to drive ourselves off the cliff…

Cliff

The current “crunch” is with headers, with 10,000 of them waiting in customs (again) and holding up just about everything, and with Ether Cards, RTC Plugs, and 2×16 LCD displays. That last one is holding up the Wireless Starter Packs as well.

In principle, all packages are sent out when complete, or nearly so in some cases. I cannot speed up things, although I keep looking for alternative suppliers. If you would prefer to get two partial shipments (no extra cost), please get in touch. I will of course also honor any cancellation, if you decide that you’ve had enough of this.

Please bear with me as I try to get over these growing pains. I apologize for all the delays and inconvenience this is causing. As new deliveries are coming in, I am continuously going through my backlog to fullfill as many pending requests as possible.

JeeNode, Electronics

Voltage: 3.3 vs 5

In AVR, Hardware on Dec 16, 2010 at 00:01

One of the decisions made early on for the JeeNode, was to make it run at 3.3V, instead of the 5V used by the standard Arduino.

The main reason for this was the RFM12B wireless module, which can only be used with supply voltages up to 3.8V, according to the specs. Running them at 5V seems to give varying results: I’ve never damaged one, but there have been reports of such failures. Given that the older RFM12 (no B) worked up to 5V, my hunch is that something in the design was found to give problems at the higher voltage. It’s just a guess on my part, though.

So what’s the deal with 3.3V vs 5V?

Well, the first thing to note, is that the ATmega328 used in a 3.3V JeeNode runs at the same 16 MHz frequency as a 5V Arduino does. This overclocking is “out of spec”:

You’re not supposed to do this, but in my experience the good folks at Atmel (the designers and manufacturers of ATmega’s and other goodies) have drawn up specifications which are clearly on the conservative side. So much so, that not a single case has been reported where this has caused problems in any of the several thousand JeeNodes produced so far. As I pointed out in a previous post, that doesn’t necessarily mean everything is 100% perfect over the entire temperature range. But again: no known problems to date. None.

This is good news for low-power uses, BTW. It means you can get the same amount of work done using less power, since power = voltage x current. Even more so because both voltage and current are lower at 3.3V than when running at 5V.

A second reason for running at 3.3V, is that you can use 3 AA batteries instead of 4 (either alkaline or rechargeable). And that you can also power 3.3V circuits with LiPo packs, which have this hugely convenient 3.5..4.2V range.

The third important reason to run JeeNodes at 3.3V, is that more and more neat sensor chips are only available for use in the 2.7 .. 3.6V range or so. By having the entire setup operate at 3.3V, all these sensors can be used without any tedious level converters.

Occasionally I’ve been bitten by the fact that I used a chip which doesn’t work as low as 3.3V, as in the first RTC Plug trial. But more often than not, it’s simply a matter of looking for alternative chip brands. One recent example was the 555 oscillator used on the Infrared Plug: the original NE555 needs at least 4.5V, but there’s an ICM7555 using CMOS technology which works down to 3V, making it a non-issue.

Mixing 3.3V and 5V devices

The trouble with these voltage differences, is not just that the power supply needs to be different. That’s the easy bit, since you can always generate 3.3V from a 5V supply with a simple voltage regulator and 2 little capacitors.

The real problem comes from the I/O interface. Placing a 5V signal on a chip running at 3.3V will cause problems, in the worst case even permanently damaging the chip. So each I/O pin connected is also affected by this.

Fortunately, there’s often a very simple workaround, using just an extra resistor of 1 kΩ or so in series. To see how this works, here’s the way many chips have their input signals hooked up, internally:

Screen Shot 2010 12 14 at 23.35.16

There’s a pair of diodes inside the chip, for each pin (not just the inputs), used for ESD protection, i.e. to protect the chip against static electricity when you pick it up.

These diodes “deflect” voltage levels which are above the VCC of the device or below GND level. They do nothing else in normal use, but if you were to place 5V on in a pin of such a device powered by 3.3V, then that would lead to a (potentially large) current through the upper diode.

With electronics (as with humans, btw), it’s usually not the voltage itself which causes damage, but the current flow it leads to, and – in the case of sensitve electronics components – the heat produced from it.

By placing a 1 kΩ resistor in series, we limit the flow through the diode to under 2 mA, which most devices will handle without any problems:

Screen Shot 2010 12 14 at 23.42.27

Ok, so now we can hook up signals to a JeeNode, even if they swing in the 0..5V range. This works best with “slow” signals, BTW. The extra resistor has a bad effect on rise and fall times of the signal, so don’t expect this to work with signals which are in the 1 MHz range or higher. Then again, it’s unlikely you’ll need to tie such fast signals directly to an ATmega anyway…

How about the other direction?

What if you have a chip running at 5V which needs to receive signals from a chip running at 3.3V, i.e. signals going in the other direction?

Well, it turns out that this may or may not work by simply tying the two lines together. The 3.3V output signal will definitely not damage a chip running at 5V. The worst that can happen, is that the 5V side doesn’t consider the signal valid.

We need to look into logic levels to figure this one out, as specified in the datasheet of the chip. The easy part is logic “0”, i.e. a low level. Most chips consider anything between 0 and 0.8V a logic “low”. There will hardly ever be an issue when tying a 3.3V chip to a 5V chip.

The tricky part is logic “1”, i.e. a signal which is intended to represent a high level. Now it all depends on what the 3.3V chip sends out, and what the 5V chip requires.

Most CMOS chips, including the ATmega, send out nearly the full power line voltage to represent a logic “1” (when the load current is low), so you can expect output signals to be just about 3.3V on a JeeNode.

On the input side, there are two common cases. Some chips consider everything above 1.6V or so to be a logic one. These chips will be perfectly happy with the JeeNode signal.

The only case when things may or may not work reliably, is with chips which specify the minimum logic “1” voltage to be “0.7 x VCC” or something like that. On a 5V chip, that translates to a minimum value of 3.5V …

Note that datasheets usually contain conservative specs, meant to indicate limit values under all temperatures, load conditions, supply voltages, etc.

In practice, I find that even with “0.7 x VCC”, I can usually drive a 5V chip just fine from a JeeNode. The only exception being higher power chips, such as stepper motor drivers and such, which operate mostly at much higher voltage levels anyway. For these, you may have to use special “level translator” chips, or perhaps something like the I2C-based Output Plug, which can be powered with voltages up to 50V or so.

This post only addresses digital I/O signals. With analog I/O, i.e. varying voltage levels, you will need to carefully review what voltage ranges are generated and expected, and perhaps insert either a voltage divider or an op-amp to amplify voltages. That’s a bit more involved.

But all in all, living mostly in a 3.3V world is often more flexible than living mostly in a 5V world, nowadays.

Which is the fourth reason why I decided to run JeeNodes at 3.3V, BTW.

Subversion

In Software on Dec 15, 2010 at 00:01

After yesterday’s post about source code control systems, here are some notes about getting started with it.

I’ll focus on Subversion, because that’s what I’m using.

Update, 2013 – Subversion is no longer in use, everything is now on GitHub.

There are two sides to a version control system: the server, where the source code “repository” is kept, and the client, which is your own workstation / PC. In distributed systems (DVCS), for example Git, there is no such asymmetry – client and server can perform the same tasks. But Subversion uses a centralized model: one repository, any number of clients.

You’ll need at least the client software to be able to use Subversion:

On Windows, you can use TortoiseSVN. It integrates deeply with the Windows Explorer, meaning that the current status of each file is always visible. See this page for some screen shots.
On Mac OSX it’s built-in (starting with 10.5, Leopard, I think) – although you probably have to install the Xcode that came with your Mac. You can check by typing “svn” in the terminal. If you get “Type ‘svn help’ for usage.”, then it’s ready for business.
On Linux, it’s a package called “subversion”. Install via your favorite package manager, depending on which flavor of Linux you’re using (e.g. Ubuntu).

Here’s the big picture:

Screen Shot 2010 12 14 at 15.26.17

Assuming you’re trying this out with existing source code (from JeeLabs, for example), then the server is somewhere on the internet, so you don’t have to deal with its setup. A little terminology and some conventions:

the server has all the source code and all the changes in a “repository”
you can get a local “working copy” by “checking it out” from the server
you can do anything you like on your copy, but…
don’t rename files or move anything around, without telling subversion
you cand send changes back by “checking them in” (a.k.a. “commit”)
you can adjust your copy to the latest version by “updating” your copy

So the basic idea is to check out a working copy (once), and then doing an update whenever you want to make sure you have the latest and the greatest. This update is totally safe: if you made changes on your working copy, and you do an update, subversion will tell you that there are changes, and occasionally maybe even a “conflict”, i.e. if your changes interfere with changes made by others.

Note that conflicts can occur in two ways: when updating your modified copy, or when committing your changes back to the server. The latter can lead to a conflict when someone made changes which you didn’t pick up yet.

If you don’t intend to make changes, or only minimally, then conflicts are a non-issue. In that case, subversion is simply a convenient (and very quick/efficient) way to keep up to date with all the latest changes.

There is another convenience, in that you can check to see what has changed, before updating. Perhaps you want to first examine the changes – and only the changes – to decide whether you want to adopt that latest version. This can be done with the subversion “status” and “diff” commands, but with the new Redmine setup at JeeLabs, it’s actually much simpler to use the web interface for this. Simply browse the repository from the web, starting here, and review the comments shown under the “Latest revisions” header (last ones are at the top). By zooming in as described yesterday, you can quickly see whether the changes are of interest to you. You could even decide to opdate only a single source file. Subversion will track all this, even with some parts updated and others not.

Let me give an example how to use subversion for getting the Ports library. I’ll use the command-line interface for this, assuming that it maps relatively simply to the GUI-based TortoiseSVN on Windows.

Step 1 – Initial check-out

You need to be in the proper place to check out. In this case, we want to get a “Ports” folder inside a “libraries” folder, which in turn needs to be placed inside the Arduino IDE’s “sketches” directory. On Mac OSX, this is “~/Documents/Arduino”. So the first thing to do, is make sure that the libraries folder exists:

    % mkdir -p ~/Documents/Arduino/libraries

Then go to that directory:

    % cd ~/Documents/Arduino/libraries

Now, we’ll check out the Ports library from JeeLabs:

    % svn checkout svn://svn.jeelabs.org/jeelabs/trunk/libraries/Ports

A new directory is created with the same name, i.e. “Ports”. It will contain all the source files. So we’re essentially done.

One thing to note, is that subversion needs to track a bit of information (such as where this Ports thing came from and when it was checked out). It does this in sub-folders called “.svn” – the leading dot is a convention to keep this area hidden. So it’s there all right, but you often won’t see it. That’s fine. Never go in there and make any changes, or you’ll completely mess up your working copy, as far as subversion is concerned.

Step 2 – Using the source code

Nothing much to say here. Just use it as if you had created the Ports folder yourself, perhaps by unpacking a ZIP archive. Apart from the “.svn” hidden areas, it’s the same thing. You should check out a copy of the RF12 library as well, since that’s always needed when using the Ports library:

    % cd ~/Documents/Arduino/libraries
    % svn checkout svn://svn.jeelabs.org/jeelabs/trunk/libraries/RF12

You can make changes to the source files if you want to. Subversion will know what you did, when asked, because it keeps an extra copy of the original files in the “.svn” folders, and besides, it could also use the server to check.

The one thing you can’t do with subversion (some other systems are more lenient), is to delete, rename, or move files and folders as you were used to. Don’t do things like these, or use other commands or programs to the same effect:

    % mv foo.c bar.c
    % rm foo.h

Instead, ask subversion to do it for you, and all will be well:

    % svn mv foo.c bar.c
    % svn rm foo.h

Step 3 – Tracking updates

Updating your copy to the latest version in the repository is trivial, and can be done at any time with:

    % svn update

You will get a concise summary of which files were changed. Changes may also include adding new files and removing obsolete ones. After the update, your working copy will be in sync with the repository again.

If you only want to find out what would be changed, without actually updating anything, use the status command:

    % svn status -u

But usually it’s simpler to use the web interface for this. For the Ports library, just go to https://jeelabs.net/projects/cafe/repository/show/Ports.

Step 4 – Submitting changes

If you have write access to the repository, then you can also submit the changes you made in your working copy. All you need is a reason… :)

Seriously, the only thing that needs some thought is what to put in the comment describing this change. Because Subversion insists on some comment. I usually check in after every little change and add a very brief note describing it, such as:

    % svn ci -m "fixed bug X so Y works again"

Note that with all these commands, you don’t have to mention the respository at all. Subversion knows which repository is being referenced by looking at the information in the “.svn” folder in the current directory you’re in.

I won’t go into conflict resolution or any of the numerous more advanced commands in subversion. Check the excellent manual online to find out more.

That’s it!

The only comment I’d like to add to conclude this weblog post, is that the above was written specifically for subversion. Many other systems exists, but once you are used to the terminology and conventions of one, using another version control system is usually no big deal. Lots of people seem to be using Git these days. No doubt due to the free GitHub source repository server, available to anyone who wants to maintain their source code in a public place. It comes with a nice and powerful set of features, see the help section for an overview.

Have fun with version control – and say goodbye to version mixups once and for all!

▶ View 1 Comment

Source code

In Software on Dec 14, 2010 at 00:01

From the beginning, all Open Source Software at JeeLabs has been maintained in a system called Subversion. This is a version control system which makes it easy to manage changes in (large amounts of) source code over (large periods of) time.

There are many such systems, with names like CVS, Subversion, Bazaar, Git, Mercurial, and more. I used CVS in the past, and switched to Subversion many years ago. It suits me well.

If you think that version control is not much more than “making frequent backups in an organized manner”, then you may be in for a surprise. Please keep reading…

All of these systems deal with the same task: managing edits. And all of them have reached a level of functionality and maturity, that frankly, I couldn’t understand how anyone writing software these days could live without…

That’s quite a statement, so let me explain.

Software development is a process. You write code, you fix bugs, you add new features over time – sometimes over a period of years, in fact. Coding is an error-prone activity, from trivial typo’s, to syntax errors, to feature omissions, to design errors… it’s all part of the process.

Suppose someone finds a bug. Wouldn’t it be great if you could go back and see what changes you made, and in what order? Maybe the bug is a new one? Maybe it got introduced by a recent change? Maybe it’s part of a very specific feature?

Here’s an extract of a special “annotated” view of the RF12.h header file. This overview was generated by Redmine, as it is now used for the JeeLabs Café:

Screen Shot 2010 12 13 at 21.05.29

The color-coded areas are “change sets”. The numbers indicate in which “revision” this particular code was added or last changed. The numbers are clickable, so if I click on “5976” for example, to view the last change related to the rf12_sendStart() code, I get this:

Screen Shot 2010 12 13 at 21.08.23

This shows exactly which files were changed at the same time, and the comment I added when I made that change, i.e. “more rf12_sendStart() low power modes”. The value is not just this little overview, but the fact that all other files and changes have been omitted. All irrelevant info is gone.

Let’s say I want to find out what was changed in the “radioBlip.pde” sketch at that time. I can click on the “(diff)” link, to get this:

Screen Shot 2010 12 13 at 21.10.20

Aha, this is apparently where I added some extra low-power-mode options to the RF12 driver, as I was writing the radioBlip example (red = deleted code, green = added code).

Note how only a small part of the source code is shown. I’m only interested in what changed, so all I get is a “diff” with a few lines of context. I can always go back to my full copy of the source code to see the rest.

This particular change was made 4 months ago. It took me three clicks in the web browser to find out what happened. Not “sort of”, but precisely. I don’t know about you, but to me that is an incredible way to keep track of things. I never have to guess, I can go back in time and zoom in on any specific detail I’m interested in right now.

Let me drive the point home: this isn’t a feature, it’s a necessity. There is no way I could call myself a software developer without tools like these.

All version control systems do this, it doesn’t really matter which one you use. All I can say is: if you haven’t been using any of them, pick one and put your whole (software) life in it. Today. You will have to learn some new conventions and some new habits. You will feel constrained initially. But once that wears off and the new habits kick in, you will wonder how you ever did without.

This doesn’t just apply to “official” software development, btw. Anything that takes more than say a day to work on, will benefit from revision control, IMO. Some people put their entire websites in there. Some people even put their entire home directory in there!

The nice thing about modern revision control systems, is that they are networked. With proper care and authentication, source code can live in a public “repository” accessible to more people. Websites such as http://github.com/ specialize in providing a complete environment for anyone who wishes to manage their source code in public. Completely free. All you need is the proper “client software” for the version control system you’re using, and a server (such as Github) where you get source code and send changes back.

By now, I no longer consider the source code on my hard disk to be crucially important. It’s a copy, “checked out” from my main subversion repository, which lives on an internet-facing server. I can get an up to date copy anywhere, just by checking out a new copy (as long as I remember where the server is, and my personal username/password).

The second killer feature (no less) of a version control system, is that it lets people work together on a single project, no matter where they are. Everyone gets their own locally checked-out copy of the same project, and everyone can make whatever changes they like, and “check-in” the changes whenever they please.

This happens very efficiently, because version control systems are immensely clever about dealing with text changes. They don’t send around complete projects and source files all the time, they quickly send little changes around (called “diffs”). This makes the mechanism 100% scalable. You could be working on a project with millions of lines of source code. Yet when you send in a change, the process is almost as quick as with a tiny project.

When more than one person makes a change to a source file, and sends in that change, three things can happen:

there is no one else who changed that file, so the change is accepted as is
someone else changed that file, but not in the same place – again, the change is automatically accepted as is, and “merged” in
someone else changed one or more of the same lines, in which case the change is flagged as a conflict

The last case is the only one which needs a bit of attention. The changes need to be compared, and someone has to decide what the final version should look like. Usually, the intent is easy to spot, and things can be resolved without any further discussion. In rare cases, the two people involved will have to discuss and resolve the issue between them.

This sounds like a lot of hassle. But it’s in fact one of my favorite features: I can check out someone else’s source code, and use it. But I can also make changes in any way I like, without ever sending them in. IOW, I can tweak any code I have in any way I like. Never will I risk losing those changes, even if I never send them in (often, they are not of general use anyway). And I’ll always be able to go back and see what my own changes were.

So with this guaranteed checking and comparing of source code, it becomes impossibe to lose changes. My own, or anyone else’s. The version control system will flag any potential problem before it actually becomes one.

More tomorrow, as I describe how to get version control going on your own machine, and how to hook up to the source code in the JeeLabs repository.

If you can’t wait and already know how to use Subversion, all the JeeLabs code can be found here:

    svn://svn.jeelabs.org/jeelabs/trunk/

If you just want to have a quick look around using the new Redmine web interface: the JeeLabs libraries can be browsed here, while JeeMon has its own repository area, which can be browsed here.

▶ View 4 Comments

Home automation

Popping fuses

In Hardware on Dec 13, 2010 at 00:01

The power-line isolation saga continues…

Danger High Voltage alt 1 md

Ok, so the idea of adding an extra RCD device which trips on differences in current turns out to be a mistake. It adds no extra protection when used in the secondary winding of such a setup. I will leave it out.

Next step was to hook up the circuit as described in the above post. Soldered evertyhing in place, used heat-shrink tubing to isolate the loose ends, lots of hot-glue to fix things, and then:

Dsc 2398

POP, said the 5A “slow” fuse – and the next one too!

That’s not just a molten piece of metal, BTW, that’s a vaporized coating on the left. I suspect that the current was substantially over 5 amps. But no ill effect on the rest of the house, no lights dimming, and no other blown fuses (the main ones downstairs are all 16A).

Uh oh, something is wrong. Well, at least I now know the fuse works!

Here’s the plan again:

Ah, wait, not quite! … I have a transformer with dual secondary windings:

Screen Shot 2010 12 12 at 12.36.53

What I did was wire them up in parallel:

Screen Shot 2010 12 12 at 12.37.03

And that’s where I went wrong. Each winding generates an AC voltage. There are two ways to put them in parallel. Connect them right, and you get twice the power – connect them in reverse, and one will generate an AC voltage which is exactly opposite in phase w.r.t. the other winding. The result is not just a short circuit, but two power sources actively counter-acting each other:

Screen Shot 2010 12 12 at 12.42.00

Hence the blown fuses. I did not expect a 300 VA transformer to blow a 5A fuse, which implies its power draw was over 1100 watt – but that’s exactly what happened.

The solution is simple, once you step back and think about it. Instead of connecting the windings in parallel, I need to connect them in series:

Screen Shot 2010 12 12 at 12.37.11

(and the same on the other up-converting transformer too, of course)

Here’s the key: it’s still possible too hook them up the wrong way. But doing so will simply lead to no ouput, i.e. zero volts, instead of the desired double voltage output. But no blown fuse.

Once I made this change (which required a lot of undoing), I found out that the transformer secundaries were indeed wound the other way than their wires had initially led me to believe.

Problem solved!

I now have a working isolation setup which turns a 230.3V input voltage into a 230.9V output voltage under no load. An 80 watt test load worked fine.

P.S. I also gained more respect for AC “power”: such circuit mistakes are a different ball game from fiddling around with an AA Power board and getting all sorts of microcontroller- and sensor hookups messed up!

▶ View 5 Comments

Easy Electrons – Resistors

In Hardware on Dec 12, 2010 at 00:01

A few days ago, I was completely overwhelmed by the positive response to a couple of posts about electronics principles such as power and circuit diagrams. Since I love to share what I’ve learned (and still learn) about this world full of discoveries, inventions, and creative engineering, I’ve been thinking about how to fold such a topic into this daily weblog.

The result is Easy Electrons – a series which will cover various aspects of electronics from the viewpoint of a technology enthusiast with a non-electronics background.

I’ve got some ideas about the frequency and topics for these posts, but I’m not commiting to a schedule or specific subjects just yet. Let’s see how it goes, and let me know what you think of these posts. Your comments will help guide me.

With that out of the way – let’s have some fun with electronics, eh?

But ya’ can’t run before you walk. This kick-off post has to go into some basic stuff. You may well know all this, but if in doubt, make sure you “get it”. Without these preliminaries, you will not be able to make sense of everything else in the upcoming posts of this series.

Resistance is not futile!

IMO, there is no concept more important in electrical circuits than resistance. One reason is that it’s everywhere, even the thickest copper wire has some resistance, however small. And an insulator, i.e. the stuff that prevents electricity from flowing all over the place, has essentially infinite resistance.

Take a voltage (or, using the water analogy: lift some water up). Once you let it “go”, it’ll want to flow. It does this using the path of least resistance. Thick solid copper pipe: huge current, massive power surge. Very thin wire: tiny current, squeezing its way through and heating up the wire. If the squeeze is strong enough (enough voltage) the wire will heat up to the point where Thomas Alva Edison made an incandescent light!

Voltage wants to flow. And when it does, it creates a current. It flows quickly when the resistance is low, it flows more slowly when the resistance is high, and it fails to flow when the resistance is infinite. That’s also why electricity will always pick a copper wire over plain air.

It’s time to introduce Ohm’s law:

    E = I x R

In words: voltage = current times resistance.

Voltage is described in volts (thanks to Alessandro Volta), current is described in amps (courtesy André-Marie Ampère), and resistance is described in ohm (due to Georg Simon Ohm).

I’ll simplify the world by saying: in simple cicuits with no effects from electric and magnetic fields, Ohm’s law is all you need to know. If you know any two of the quantities, you can calculate the third.

I won’t go into them now, but if you also learn the two Kirchoff’s circuit laws, then you’ll have some incredibly powerful tools to explain what’s going on, even in circuits with dozens of components, connected in all sorts of funky ways.

Physicists and chemists will be used to this, but if you come from the world of software, then note that these laws are really quite amazing: they let you predict what will happen when you hook up a circuit. Laws such as this were not “created” to terrorize kids in school, they are really extremely useful!

Let’s try it:

Screen Shot 2010 12 05 at 15.16.27

What’s the voltage on the right side? (assuming no load current)

I’m going to skip several details, but here’s how I would reason about it:

we want to know the voltage over the lower resistor
we know its resistance, so if we knew how much current is flowing, we could calculate it
the current flows through both resistors
the current IN is the same as the current OUT
so the same current flows through both resistors
we know the voltage over the total
if we knew the total resistance, we could derive the current through both
once we do, we know the current through the lower resistor
and from there, we can calculate the voltage, as requested

Question: what is the resistance of two resistors placed in series, one after the other?

Answer: this is one of those facts you’ll just have to memorize – resistance of R1 and R2 in series = R1 + R2.

so we have 9 volts over 3 kilo-ohm, i.e. 3000 ohm
the current is 9 / 3000 = 0.003 amps, i.e. 3 milliamps
voltage over 1 kΩ is 1000 x 0.003 = 3 volt

So the final answer is 3 volts.

But don’t stop there, please:

What if we use a 3V battery? Answer: (3/3000)*1000 = 1V.
How about a 12V power supply? Answer: (12/3000)*1000 = 4V.
See the pattern?

The two resistors act as a voltage divider. They don’t really “care” about the input voltage, they will simply divide it by 3. Because the ratio of the total to the lower resistance is (2+1)/1 = 3. This is also the reason why I drew that schematic in this particular way: it illustrates the voltage “drop”.

Hold on to that insight. Electric circuits usually have lots of voltage dividers. Whenever I see resistors in series, I try to determine what voltage is placed over them. And sure enough, most of the time, that’s what the resistors are used for. It works for any voltage. It also works for varying voltages: if you have an audio signal in the form a a rapidly varying voltage, then the voltage divider will simply pass the signal through, at a reduced voltage level.

Not every resistor is used as voltage divider. But more often than not, that’s all they do when used in series.

Easy Electrons!

P.S. Would you believe that I found out about this tutorial after writing the above? Heh… synchronicity :)

JeeNode, Techniques, Network

RF12 acknowledgements

In Software on Dec 11, 2010 at 00:01

The RFM12B wireless module is a transceiver, i.e. able to send and receive packets over wireless. This is an important advantage over simple sensor units which just send out what they measure, and things like RF-controlled power switches which only listen to incoming data but are not able to report their current state.

The only thing is… it’s a bit more work.

This is reflected in how the RF12 library works:

simple reception is a matter of regularly polling with rf12_recvDone()
simple transmission means you also have to call rf12_canSend() and rf12_sendStart()
the above are both essentially uni-directional, so packets can get lost

The second mechanism added to RF12 was a set of “easy transmission” functions, i.e. rf12_easyPoll() and rf12_easySend(). These look similar, but they send out data packets asking for an ACK (acknowledge) packet from the receiver to confirm that the packet was correctly received. If nothing comes in, they will re-send the packet (and repeat a few times, if needed). This mechanism greatly improves the chance of a message arriving properly at the destination. Losing an occasional packet is one thing, losing all retries is a lot less likely!

Note that packets can be damaged or get lost at any time. It may well be that the original packet arrived just fine, but the ACK got lost instead. The sender will resend, and then (probably) get the ACK which stops this retry cycle.

So with the easy transmission functions, note that very occasionally a packet might be received twice. If it is crucial to weed these out, you can include a counter in your data packets to help detect and ignore duplicates.

With RF12demo as receiver, ACK handling is automatic. It knows when the originating node wants to get an ACK, and will send it out as soon as possible. This is reported in the output as the text “-> ack”.

The code for this in RF12demo is horrendous:

Screen Shot 2010 12 10 at 18.27.08

This is silly, and overkill for simple cases. So let’s improve on it.

I’ve added two utility definitions to the RF12.h header, which can simplify the above code to:

Screen Shot 2010 12 10 at 19.58.02

That’s better, eh?

The rest is just there to deal with a special configuration setting in RF12demo.

So if all you want is to add logic in your own sketch to send back an empty ACK packet when requested, the above can be simplified even further to:

Screen Shot 2010 12 10 at 19.59.09

For completeness, here’s a complete processing loop for a receiving sketch which supports nodes using the easy transmission mechanism:

Screen Shot 2010 12 10 at 19.59.45

You have to send out the ACK after processing the packet, because the rf12_sendStart() call will re-use the same packet buffer and overwrite the incoming packet.

Also, RF12_WANTS_ACK and RF12_ACK_REPLY are defined as macros which access the global rf12_hdr variable, as set by rf12_recvDone(). IOW, the convenience comes for free, but it does depend on some fixed assumptions. I can’t think of a situation where this would lead to problems, given that RF12-based sketches are probably all structured in the same way, and that globals are part of the RF12 driver.

For another example, see the blink_recv.pde sketch, which has also been simplified with these two macros.

Home automation

RCD finally in

In Hardware on Dec 10, 2010 at 00:01

Remember the weblog post about mains voltage and my plan to work on some circuits involving high voltage?

Well, with fear and trepidation I can announce that the missing link has finally arrived:

Dsc 2397

That’s an “Aardlekschakelaar” in Dutch, i.e. a Residual-current device.

People are probably either very thankful or very afraid of this thing, judging by the number of acronyms under which it is known: RCD, RCCD, RCCB, GFCI, GFI, or ALCI – take your pick!

An RCD continuously compares the current in with the current out, and breaks the circuit once the difference exceeds a certain threshold. I decided to get the most sensitive one I could find, which trips at 10 mA. I’m terrified of electric shock – especially the non-lethal kind… (no idea about the other variant, and I intend to keep it that way).

Ok, so it took over a month from ordering the RCD to getting it delivered – from a mail-order company here in the Netherlands, go figure. I’ll build the RCD into my super-duper isolation jig as soon as I find some time. I sure don’t want to fiddle with 230V while distracted or in a hurry.

Speaking of which…

There are a large number of people waiting for orders from the JeeLabs shop right now, for which I offer my sincere apologies. The reason is not really lack of time (well, maybe a little…), but the fact that stocks have run out on several items. I’ve got just about everything that’s missing on order right now, but in some cases my hands are tied because things don’t always arrive as quickly as promised or expected.

I’ve been refraining from sending out partial shipments, because it doesn’t really make much sense most of the time (sending out a JeeNode without the matching JeeLink, for example), and because it adds substantially to my overhead. Which is of course my own concern, but it also raises the chance of mistakes, something which I really want to avoid.

Not everything is in yet, but I hope to have just about all shipments ready by this weekend. Please get in touch if you’d rather have a partial shipment sent out soon, rather than waiting until next week. There will be no extra charges for such split shipments.

Crazy times around here. And the long-overdue server migration isn’t making it any easier!

P.S. Don’t get me wrong. I’m still working on quite a bit of fun stuff on the side, so let me finish this slightly panicky post with a little smiley anyway :)

▶ View 16 Comments

New server

In News on Dec 9, 2010 at 00:01

JeeLabs is leaving the dark ages behind… into the light!

Yesterday, the fiber-optic cable was finally delivered. It’s that long box in the middle with the wiggly split:

Dsc 2391

Roll-out by Glashart, modem installed bij NKM, support bij Lijbrandt. It took three months between bringing that orange fiber-optic cable into the house to getting hooked up to internet with it!

This is offered as a Triple play service, of which I’ll only be using the internet connection and a telephone line (yeah, voice-over-wire still exists!).

The internet connection is not too shabby – here’s the “low-end” version I ended up with:

Screen Shot 2010 12 07 at 10.59.21

To be honest, I couldn’t care less about the download speed. Been happy ever since ADSL passed the 4 Mbit/sec mark (the rest is marketing, same as the CPU GHz “game”, and the top speed of a car, if you ask me).

The key reason to do this was to increase the upload bandwidth, which was 1 Mbit/sec – until now.

So finally I can announce the new web server for the JeeLabs Café:

Say hello to… jeelabs.net

Screen Shot 2010 12 08 at 16.03.12

I’ve been maintaining the docs in both places for a couple of months now. But as of today, cafe.jeelabs.net will be deprecated. I’ll gradually adjust all the bits there to redirect to the new server. The old URLs will continue to work for at least another 6 months, but no guarantees after that.

So what’s the deal with the new Café site, eh?

Well, it’s powered by Redmine and has a lot more features than the old site, which is just some static pages:

A wiki – with all the info from the old site, organized in a similar way, but now more people can join and participate. There’s already a nice section of contributed pages – see the interesting projects page. The wiki supports Markdown format, and attachments (which can be used as inline images).
An issue tracker, to better keep track of bugs, feature requests, and source code changes.
A forums section, which may replace the current Talk forums. I haven’t decided, the feature set is quite different. Main issue holding me back for now, is the lack of a simple spam filtering mechanism.
A respository browser for all the source code maintained at JeeLabs. This is a very nice and powerful interface to subversion, with full access to change logs, older versions, and source code differences. This replaces the jeelabs.org hack I had set up a while back.

Redmine has a number of other features which I haven’t enabled at this point. One of the things to note, is that it manages several different projects, including some private ones which aren’t even listed until you log in with the proper access rights.

Speaking of logins: all the info in the Café is public and browsable by anyone visitng the site. To submit bug reports or feature requests, however, you will need to register and log in. The process is simple an automated, with a quick check via email. To contribute on the wiki, I need to raise your access level to “Editor” – this is not automatic (to avoid spamming), so please contact me if you would like to add your own pages to the wiki or help maintain and extend pages already on there.

The main page of the new Café is at https://jeelabs.net/projects/cafe/wiki and here’s what it looks like:

Screen Shot 2010 12 08 at 17.34.20

There’s a separate Hardware sub-project in the Café with all the “official” documentation about hardware from JeeLabs. This is where you will find descriptions, detailed specs, connection diagrams, schematics, CAD files, and pointers to relevant posts on this daily weblog. An example:

Screen Shot 2010 12 08 at 16.29.51

Ok, enough screen shots. Back to work!

▶ View 14 Comments

Binary packet decoding – part 2

In AVR, Software on Dec 8, 2010 at 00:01

Yesterday’s post showed how to get a 2-byte integer back out of a packet when reported as separate bytes:

Unfortunately, all is not well yet. Without going into details, the above may fail on 32-bit and 64-bit machines when sending a negative value such as -12345. And it’s not so convenient with other types of data. For example, here’s how you would have to reconstruct a 4-byte long containing 123456789, reported as 4 bytes:

Screen Shot 2010 12 07 at 09.56.08

And what about floating point values and C structs? The trouble with these, is that the receiving party doing the conversion needs to know exactly what the internal byte representation of the ATmega is.

Here is an even more complex example, as used in the roomNode.pde sketch:

Screen Shot 2010 12 07 at 08.44.28

This combines different measurement values into a 4-byte C struct using bit fields. Note how the “temp” value crosses two bytes, but only uses specific bits in them.

Fortunately, there is a fairly simple way to deal with all this. The trick is to decode the values back into meaningful values by the receiving ATmega instead of an attached PC. When doing so, we can re-use the same definition of the information. By using the same hardware and the same C/C++ compiler on both sides, i.e. the Arduino IDE, all internal byte representation details can be left to the compiler.

Let’s start with this 2-byte example again:

I’m going to rewrite it slightly, as:

Screen Shot 2010 12 07 at 08.57.23

No big deal. This sends out exactly the same packet. But now, we can rewrite the receiving sketch as follows:

Screen Shot 2010 12 07 at 09.00.14

The effect will be to send the following line to the serial / USB connection:

    MEAS 12345

The magic incantation is this line:

Screen Shot 2010 12 07 at 09.01.45

It uses a C typecast to force the interpretation of the bytes in the receive buffer into the “Payload” type. Which happens be the same as the one used by the sending node.

The benefit of doing it this way, is that the same approach can be used to transfer any type of data as a packet. Here is an example how a Room Node code sends out a 4-byte struct with various measurement results:

Screen Shot 2010 12 07 at 09.07.07

And here’s how the receiving node can convert the bytes in the packet back to the proper values:

Screen Shot 2010 12 07 at 09.10.55

The output will look like:

    ROOM 123 1 78 -15 0

Nice and tidy. Exactly the values we were after!

It looks like a lot of work, but it’s all very straightforward to implement. Most importantly, the correspondence between what happens in the sender and the receiver should now be obvious. It would be trivial to include more data. Or to change some field into a long or a float, or to use more or fewer bits for any of the bit fields. Note also that we don’t even need to know how large the packet is that gets sent, nor what all the individual bytes contain. Whatever the sender does to map values into a packet, will be reversed by the receiver.

This works, as long as the two struct definitions match. One way to make sure they match, is to place the payload definition in a separate header file, say “payload.h” and then include that file in both sketches using this line:

Screen Shot 2010 12 07 at 09.16.47

The price to pay for this flexibility and “representation independence”, is that you have to write your own receiving sketch. The generic RF12demo sketch cannot be used as is, since it does not have knowledge of the packet structures used by the sending nodes.

This can become a problem if different nodes use different packets sizes and structures. One way to simplify this, is to place all nodes using the same packet layout into a single net group, and then have one receiver per net group, each implemented in the way described above. Another option is to have a single receiver which knows about the different types of packets, and which switches into the proper decoding mode depending on who sent the packet.

Enough for now. Hopefully this will help you implement your own custom WSN to match exactly what you need.

Update – Silly mistake: the “rf12_sendData()” call doesn’t exist – it should be “rf12_sendStart()”.

▶ View 13 Comments

Binary packet decoding

In AVR, Software on Dec 7, 2010 at 00:01

The RF12 library used with the RFM12B wireless radio on JeeNodes is based on the principle of sending individual “packets” of data. I’ve described the reasons for this design choice in a number of posts.

Let me summarize what’s going on with wireless:

RFM12B-based nodes can send binary packets of 0..66 bytes
these packets can contain any type of data you want
a checksum detects transmission errors to let you ignore bad packets
dealing with packet loss requires an ACK + re-transmission mechanism

Packets have the nice property that they either arrive intact as a whole or not at all. You won’t get garbled or inter-mixed packets when multiple nodes happen to send at (nearly) the same time. Compare this to some other solutions where all the characters sent end up in one big “soup” if the sending happens (nearly) simultaneously.

But first: what’s a packet?

Well, loosely speaking, you could say that a packet is like one line of text. In fact, that’s exactly what you end up with when using the RF12demo sketch as central receiver: a line of text on the serial/USB connection for each received packet. Packets with valid checksums will be shown as lines starting with “OK”, e.g.:

    OK 3 128 192 1 0
    OK 23 79 103 190 0
    OK 3 129 192 1 0
    OK 2 25 99 200 0
    OK 3 130 192 1 0
    OK 24 2 121 163 0
    OK 5 86 97 201 0
    OK 3 131 192 1 0

Let’s examine how that corresponds with the actual data sent by the node.

All the numbers are byte values, shown as numbers in the range 0..255.
The first byte is a header byte, which usually includes the node ID of the sender, plus some extra info such as whether the sender expects an ACK back.
The remaining data bytes are an exact copy of what was sent.

There appears to be some confusion about how to deal with the binary data in such packets, so let me go into it all in a bit more detail.

Let’s start with a simple example – sending one byte:

Screen Shot 2010 12 06 at 22.32.26

I’m leaving out tons of details, such as calling rf12_recvDone() and rf12_canSend() at the appropriate moments. This code is simply broadcasting one value as a packet for anyone who cares to listen (on the same frequency band and net group). Let’s also assume this sender’s node ID is 1.

Here’s how RF12demo reports reception of this packet:

    OK 1 123

Trivial, right? Now let’s extend this a bit:

Screen Shot 2010 12 06 at 22.38.13

Two things changed:

we’re now sending a larger int, i.e. a 2-byte value
instead of passing length 2, the compiler calculates it for us with the C “sizeof” keyword

Now, the incoming packet will be reported as:

    OK 1 57 48

No “1”, “2”, “3”, “4”, or “5” in sight! What happened?

Welcome to the world of multi-byte values, as computers deal with them:

a C “int” requires 2 bytes to represent
bytes can only contain values 0..255
12345 will be “encoded” in two bytes as “12345 divided by 256” and “12345 modulo 256”
12345 / 256 is 48 – this is the “upper” value (the top 8 bits)
12345 % 256 is 57 – this is the “lower” value (the low 8 bits)
an ATmega stores values in little-endian format, i.e. lowest-range bytes come first
hence, as bytes, the int “12345” is represent as first 57 and then 48
and sure enough, that’s exactly what we got back from RF12demo

Yeah, ok, but why should we care about such details?

Indeed, on normal PC’s (desktop and mobile) we rarely need to. We just think in terms of our numbering system and let the computer do the conversions to and from text for us. That’s exactly what “Serial.print(12345)” does under the hood, even on an Arduino or a JeeNode. Keep in mind that “12345” is also a specific representation of the abstract quantity it stands for (and “0x3039” would be another one).

So we could have converted the number 12345 to the string “12345”, placed it into a packet as 5 bytes, and then we’d have gotten this message:

    OK 1 31 32 33 34 35

Hm. Still not quite what we were looking for. Because now we’re dealing with ASCII text, which itself is also an encoding!

But we could build a modified version of RF12demo which converts that ASCII-encoded result back to something like this:

    OKSTR 1 12345

There are however a few reasons why this is not necessarily a good idea:

sending would take 5 bytes instead of 2
string manipulation uses more RAM, which is scarce on an ATmega
lots of such little inefficiencies will add up, once more data is involved

There is an enormous gap in performance and availability of resources between a modern CPU (even on the simplest mobile phones) and this 8-bit few-bucks-chip we call an “ATmega”. Mega, hah!

But you probably didn’t really want to hear any of this. You just want your data back, right?

One way to accomplish this, is to keep RF12demo just as it is, and perform the proper transformation on the receiving PC. Given variables “a” = 57, and “b” = 48, you can get the int value back with this calculation:

Screen Shot 2010 12 06 at 23.11.04

Sure enough, 57 + 48 * 256 is… 12345 – hurray!

It’s obviously not hard to implement such a transformation in PHP, Python, C#, Delphi, VBasic, Java, Tcl… whatever your language of choice is.

But there’s more to it, alas (hints: negative values, floating point, structs, bitfields).

Stay tuned… more options to deal with these representation details tomorrow!

Update – Silly mistake: the “rf12_sendData()” call doesn’t exist – it should be “rf12_sendStart()”.

No more diode!

In Hardware on Dec 6, 2010 at 00:01

The JeeNode v5 introduced a change, which I now regret – due to the amount of confusion it has generated, and the limited utility: an extra protection diode in the PWR line on the FTDI connector (and only there!).

Here’s the PCB layout, as seen in EAGLE:

Screen Shot 2010 12 05 at 17.44.49

The diode is marked “D1”, with a solder bridge on the back side of the board (red lines are on top, blue lines on the bottom, and plated-through holes are in green).

Here’s a close-up:

Dsc 2074

What it does, is block the power when it’s connected the wrong way around. But that only protects the FTDI connector, which is actually quite well protected agains reversal already (if you flip the connector, GND will go to the reset cap, which blocks all DC current anyway).

The drawback of this design is that it lowers the voltage by about 0.7V, so instead of 5V, you get about 4.3V on the remaining PWR pins, such as on all the port headers.

Worse still, is that it causes the JeeNode to stop working from a 3.3V power source, such as the AA Power Board, because it will drop the voltage to about 2.5V – which is too low to run at 16 MHz!

I did design a workaround into the JeeNode v5: there’s a solder jumper on the other side of the board, to bypass that diode. Where “bypass” means: short out the diode, as if it wasn’t part of the circuit in the first place.

The irony is that I’ve been closing this solder jumper on every new JeeNode I’ve built so far.

Add to that the fact that the holes for that diode are almost too small to push the thick diode wires through, and it becomes clear that this new “feature” causes more problems than it solves.

Starting now, once the stock of kits is exhausted, new kits will be shipped WITHOUT the diode!

You will now have to always add a drop of solder to close the jumper on the back:

Screen Shot 2010 12 05 at 18.04.03

If you don’t, there will no power connection from the FTDI header to the JeeNode.

It’s an important change, but it removes the nasty suprise that sometimes things work and sometimes they don’t!

Oh, and if you’re into this tradition – I hope you had a nice Sinterklaas!

Electric circuits

In Hardware on Dec 5, 2010 at 00:01

At the risk of prolonging this “electronics course” and boring everyone after the past two installments about power and switching regulators, here are some thoughts about electronic circuits.

I find the hydraulic analogy very useful, as long as you don’t push it too far. There is a (thick) book called Practical Electronics for Inventors by Paul Scherz (2007) which manages to construct analogies for just about all types of electronic components. It’s a stretch, but it does help understand things.

Here’s an example I found on the web:

Transistor

It’s quite easy to see how a small current can control a larger one. It also falls short, because “current” is really “pressure” in this case. My suggestion would be: do look at those analogies if you want to quickly build a mental model of how a specific component works, but keep the limitations of such analogies in mind.

The neat thing about electricity, is that you can completely understand a circuit by just applying a bit of logic. By which I mean: reason how it probably / sort-of works. And predict some of its behavior. It really pays to invest a bit in understanding electronics circuits.

There is a whole world to discover when you get into this. There are lots of conventions to figure out, but the neat thing is that these conventions are pretty much standardized by now. Electric circuits have been around for a couple of centuries, even if some of the newer components are only decades old.

Here’s part of the Infrared Plug, as a circuit diagram:

Screen Shot 2010 12 04 at 23.47.50

Even without knowing all the conventions, you’re probably able to guess many of the components. Connectors (PORT1, SV1), resistors (R1, R2, R3, R4), capacitors (C1, C2), a transistor (Q1), two LEDs (LED1, LED2), and a box marked “LM555D” which is an integrated circuit for building timers and oscillators.

How it works would be a bit of a long story for this post, but let’s make a guess:

C1 is charged up because it’s connected between + (VCC) and - (GND)
there are two resistors (R1 and R2) which limit the current flowing into it
the charge on C1 is measured through pin 6 of the chip (THR, i.e. threshold)
pin 7 (DIS, i.e. discharge) is actually an output, which can be either open or low

What the LM555D does (consider it magic for now), is watch the voltage level on THR. When it is low, DIS is not connected. The capacitor will charge up, until THR reaches a certain voltage.

At that point, the chip (through magic), decides to pull DIS low, i.e. put it at almost 0 volts, i.e. ground level.

While DIS is low, something completely different happens: with pin 6 being at a fairly high voltage, and DIS low, capacitor C1 will start to discharge, with current flowing into R1 in the opposite direction.

At some point, the THR voltage will be very low again, at which point the chip (magically) decides that it’s time to disconnect DIS. Then the cycle repeats: C1 will start to charge up through R1 and R2, etc… ad infinitum.

These 4 components are the heart of what is called an astable multivibrator.

We haven’t even looked at the rest of the circuit yet. I’ll leave it at that for now, just mentioning that the transistor is there to drive a strong current through the LEDs in a rapid ON/OFF pattern.

The components are dimensioned in such a way that this circuit oscillates at… 38 KHz. Which “happens” to be what most remotes send out as well.

There is a lot more to say about electric circuits, of course. I just wanted to point out that there is a huge amount of information you can glean from such “schematics” of various circuit diagrams.

Since everything made at Jee Labs is open source, you can dive into all of this. Look for the PDF’s linked on the various hardware pages if you’re interested.

It’s fun. It’s enormously informative. And unlike my use of the term “magic” there is really nothing special going on at all. It’s only magic until you dive in. If you have questions about how JeeNode pins are hooked up, for example: check out the manual (PDF). It’s all in there!

Update – for entertaining introductions of the main electrical components, there are a couple of short videos by Collin Cunningham on the Gizmodo website.

▶ View 9 Comments

What is “power” – part 2

In Musings on Dec 4, 2010 at 00:01

To continue yesterday’s post, let’s go into that last puzzle:

Why does the 1x AA Power Board run out of juice 3 times as fast as a 3x AA battery pack?

The superficial answer would be: it’s one battery instead of three, so obviously it’ll last 1/3rd as long.

But that’s not quite the whole story…

The AA Power Board contains a switching regulator called a boost converter. Switching regulators are a lot more efficient than ordinary “linear” voltage regulators. They play games with energy conversion into electrical and magnetic fields. And by doing so, they mess with the rule that current is always the same everywhere.

But let me first explain what a linear regulator does:

Screen Shot 2010 12 02 at 22.12.51

Don’t laugh – that’s the essence of a linear voltage regulator: a variable resistor!

Well, it’s far more complex than that in reality. But the machinery inside a linear voltage regulator is all about wasting energy. The goal is to waste just the right amount to get the desired 3.3V on the output pin, regardless of changes in input voltage and current draw. Functionally, all the regulator does is continuously adjust its internal resistance to get the right output.

If you think about it, there’s in fact little else you can do with resistors. They exist to drop voltage, and by doing so, they generate heat, even if the amount is minimal and usually irrelevant.

The other type of regulator is the switching regulator. Huge topic, way beyond the scope of this post (and way over my head, in fact). I’m bringing it up because the AA Power Board uses a switching regulator to “boost” the voltage from say 1.5V to 3.3V.

So how does one boost voltage?

The hydraulic analogy would be to pump water from one level to a higher level using only water power (height and flow). There’s an ingenious pump called a hydraulic ram which can do that. The one I’ve seen in action works by letting water flow and then quickly interrupting that flow. All of a sudden, the water has nowhere to go and pressure builds up. All you need is an outlet pointing up, and the water will go there as only option.

The flow will quickly stop, so the trick is to repeat this cycle, and then – in a pulsating fashion – you actually can get water to climb up. Voilá, a higher voltage!

That’s also how the AA Power Board works. It contains an efficient switch, which pulses the current flow, and (in most cases) an inductor which transforms current changes into a magnetic field, and vice versa. The inductive “kick” is what makes it possible to play games with current vs. voltage without turning it all into heat.

But you don’t get anything for free. Apart from circuit losses, you lose the conversion factor w.r.t. power – drawing 10 mA @ 3.3V will require 30 mA @ 1.1V – with circuit losses increasing that slightly further. You can’t ever get more watts out of this than you put in!

So, roughly speaking, to get 3.3V from a 1.2V AA NiMH battery, you need to draw about 3 times as much current from the battery as what will go into the target circuit.

Which is why a 2000 mA single AA battery behaves roughly like a 650 mAh battery delivering 3.3V via the boost converter. With our circuit drawing 10 mA, that will last 650 mAh / 10 mA = 65 hours.

That’s roughly a third as long as the 3x AA battery pack. QED.

There are some losses and inefficiences. Even with a switching regulator, you should expect no more than 90..95% efficiency under good conditions. But this is nowhere near the inefficiency of a linear regulator with a high input voltage. On a 9V battery, the on-board regulator of a JeeNode will be less than 40% efficient.

Note that there are also down-converting switching regulators (called buck converters), and these do have much higher efficency levels. Even the AA Power Board is able to handle over 5V on its input, and still deliver a 3.3V output, by going into a buck conversion mode. In which case the input current will be less than 10 mA to deliver 10 mA @ 3.3V on its output – something a linear regulator simply cannot do.

Conclusion: if you want very power-efficient solutions, look carefully at what voltages to use for supplying your circuits, and use switching regulators when the voltage differential is substantial. Linear regulators can only drop voltage, and can only do so by wasting energy.

There is another benefit to using a boost converter: it lets you suck the last breath out of batteries. The AA Power Board can be used with batteries with only 0.85V or so left in them, and if kept connected and running, it’ll work all the way down to 0.6V or so. You can be assured that by the time an AA Power Board gives up, its battery will have been completely drained!

One last note about the AA Power Board: maximum efficiency is achieved with an input voltage between 2.4V and 3.0V, so if you want to optimize, consider using either 2 AA (or AAA) cells, or a 3V battery such as the CR123A, which is half the size of an AA and a great source of energy with about 900 mAh of oomph…

But just to put all this into perspective: if all you want is a good solid source of power for a JeeNode and everything attached to it, use a 3x (or 4x if you have to) AA battery pack. Or use power from USB.

Me, I’ll stick to single rebranded Eneloops @ 1.2 .. 1.3V.

▶ View 3 Comments

What is “power”?

In Musings on Dec 3, 2010 at 00:01

Here’s something which may be totally obvious to some, yet clear as a mud to others…

Voltage, current, power – what are they? Here are some puzzles I’ll go into:

Why does a 4x AA battery pack run out almost as fast as a 3x AA battery pack?
Why does a 9V battery last about 1/4th as long as a 3x AA pack?
Why does the 1x AA Power Board run out of juice 3 times as fast as a 3x AA battery pack?

Let’s take it one step at a time. An often-used analogy for electricity is water (see hydraulic analogy). To simplify, let’s say that electricity flows from a high voltage to a low voltage, such as ground. Likewise, water flows from a high location to a lower location. So let’s make the analogy that high voltage equals water high above the ground.

This is what happens in a circuit where a 3.6V battery powers a JeeNode:

Screen Shot 2010 12 02 at 19.56.58

While in the battery, the voltage is “at” 3.6V. When it goes through the on-board voltage regulator, it is made to drop to 3.3V, and then that electricity flows through the ATmega, RFM12B, etc, to ground.

Let’s assume the circuit draws 10 mA. The thing about current is that it’s doesn’t change across a circuit, like voltage does. Using the water analogy: current is the amount of water flowing. And no matter where it flows, the amount at the top is the same as the amount lower down. It might trickle down in different ways, but the amount into the whole circuit is the same as the amount coming out:

Screen Shot 2010 12 02 at 20.13.33

So what we have is a battery, where the electricty “starts out”, and then it traverses first the voltage regulator, then the ATmega, etc, and then it flow back into the battery at 0V, which in effect “pumps” it back up to 3.6V. And the the cycle repeats.

I’m taking many liberties here. Electricity doesn’t really flow from + to -, and there’s no pumping involved either. But as a mental model, this actually works pretty well.

So what’s “power” then, eh?

Well, power is defined as “voltage times current”. I’ve added the calculations in that second diagram. As you can see, with a 10 mA current consumption, the battery generates 36 mW, of which the voltage regulator consumes (i.e. wastes) 3 mW, and the ATmega, etc, get the remaining 33 mW.

What you may not realize, is that “consuming power” is basically equivalent to “turning electricity into heat” – because that’s what happens, essentially. Think about it: the JeeNode is really just a mini electric heating. It isn’t very much heat, and it happens over a long stretch of time. But in the end, when the battery is dead, you’ve done nothing but heat up the surroundings a teeny bit…

Well, almost: a small amount will have been emitted as radio energy when the RFM12B is transmitting.

Ok, so now let’s try to answer the above three questions.

Why does a 4x AA battery pack run out almost as fast as a 3x AA battery pack?

This is due to the voltage regulator. If you feed it say 4.8V, instead of 3.6V, it will simply waste that extra energy: the voltage drop over the regulator will be 1.5V instead of 0.3V, so that the output of he regulator stays at 3.3V. That’s the whole purpose of the regulator after all: to deliver a constant voltage, regardless of the voltage placed on its input pin.

Here’s what would happen if you put 9V on the voltage regulator:

Screen Shot 2010 12 02 at 20.32.10

And here’s how that works out in terms of power consumption:

Screen Shot 2010 12 02 at 20.33.05

(correction: the 5.3V – bottom middle – should have been 5.7V)

In other words: you can raise the voltage all you like, it won’t have any effect on the amount of power needed or used by the ATmega, etc. They will always get 3.3V, and will continue to draw 10 mA as before.

The only thing that happens, is that the voltage regulator works a little harder, and wastes a bit more power by turning it into more heat!

Conclusion: if your circuit doesn’t need the higher voltage to work properly, power it at the lowest practical voltage. Keep in mind that the “low-drop” voltage regulator on the JeeNode likes to have at least 0.1..0.2V to do its job properly. Both 3x AA packs and LiPo batteries are just about perfect for JeeNodes.

Another very important lesson from this is that if you’re trying out stuff, and you notice that the voltage regulator is getting very hot because some part of your circuit draws a lot of current, then you should try to reduce (!) the voltage you’re feeding into it: you’ll help the regulator, by giving it less power to eat up and waste.

Why does a 9V battery last about 1/4th as long as a 3x AA pack?

Now with the above explanation, it should be clear that the 9 volts won’t give you a longer-running JeeNode. But why is it so much shorter?

The reason is that not all batteries contain the same amount of energy. The capacity of a battery is specified in terms of milli-Ampere-Hour: an AA battery often has over 2000 mAh. This means it can supply 2000 mA for one hour. Or 1000 mA for 2 hours, 500 mA for 4, etc. And then it’s empty.

Energy is defined as Voltage x Current x Time (or equivalently: Power x Time). The unit is watt hour.

So the amount of power you get when draining an AA battery in one hour (voltage x current) is: 1.5V x 2000mA = 3.0 watt. Consquently, the amount of energy in a a 3x AA pack is 9.0 watt hour.

For a standard 9V battery, the figure is around 500 mAh. This is 9V x 500 mAh = 4.5 watt hour of energy.

Great, so a 9V battery has half as much energy as a 3x AA battery pack, and should last about half as long, right?

Wrong! – go back to that first discussion about feeding the voltage regulator with 9V instead of 3.6V: it just turns that extra voltage into heat.

The way to estimate lifetimes, is to use the current draw as starting point. We assumed in all these examples that the circuit is drawing a constant 10 mA.

On a 3x AA pack (or 4x AA, for that matter), this means we get 2000 mAh / 10 mA = 200 hours of run time.

But on a 9V battery, we’ll only get 500 mAh / 10 mA = 50 hours of run time!

Conclusion: don’t use 9V battery packs for JeeNode projects. They are an expensive way to waste energy, and you’ll keep running to the shop to get new ones.

Why does the 1x AA Power Board run out of juice 3 times as fast as a 3x AA battery pack?

Before even going into that, the first puzzling fact about running a JeeNode off a single AA is really: how can a 3.3V circuit run off a 1.5V power source in the first place? Think about it. As you know, most electrical circuits don’t work at all when the supply voltage is too low.

It’s equivalent to asking: how can you get water which flows at a certain level to lift itself to a higher level?

Hint: there exists an ingenious type of water pump which can do this!

To be continued in tomorrow’s post…

▶ View 9 Comments

Bridge Board – caveats

In Hardware on Dec 2, 2010 at 00:01

There is some complexity lurking in the design of the Bridge Board, which in turn may lead to some head scratching, I’m afraid…

That complexity comes from the fact that not all I/O pins are always available.

Let’s start with an overview of the different pin groups:

Annotated bb

The basic idea is that when you connect all four port headers, then you’ll get access on the breadboard to all the pins marked above in RED. This is the most common usage, and main intended use of the Bridge Board. Note that DIO2, DIO3, AIO2, and AIO3 are available on multiple pins.

So if you follow yesterday’s post, you can use all the pins shown in red as is. The main benefit being that you can easily access the main 8 I/O pins, and that port 2 is in fact replicated in the same layout on the breadboard if you want to hook it up to JeePlugs.

If all you need are the leftmost 16 pins – you can skip the rest of this post.

The remaining pins takes a bit more explanation and preparation, and requires adding some more header on the Bridge Board as well as on the JeeNode! – here’s the summary:

to use the 6 SPI/ISP pins marked in BLUE, add the 2×4 pin header on the right
to use 4 more I/O pins marked in GREEN, add a 8-pin header on the left (the middle 6 are actually enough)
to use FTDI, add the 8-pin header on the left (only JeeNode v4: also the 2×4-pins on the right)

That last option also requires soldering in a 0.1µF capacitor if you want to include the reset-on-open capability for easy uploading. It’s mostly intended for use with a JeeSMD, which does not have an upload capability of its own.

There is a reasoning behind all this madness:

The leftmost 16 pins on the breadboard were the main design goal for this board.
The middle 13 pins (IRQ to B0) match the layout need for the Ether Card.
The rightmost 20 pins are compatible with both Ether Card and Carrier Board.
The Bridge Board is compatible with JeeNode v5 and v4, JeeNode USB, and JeeSMD.

The two LEDs are brought out on separate pins and always available – on the LED1 and LED2 pins, respectively. They are very efficient and require only a few mA to shine brightly. You can hook them up to any I/O pin or other 3.3/5V signal on your breadboard. They make a great debugging tool when the going gets tough.

The push-button at the top of the board is also always available on the BTN pin. It is connected to ground, so pressing the button shorts the BTN pin to ground – you can use the internal ATmega pull-up and some software debouncing to read out this button.

The button can be used as reset button if you have the RST pin, which is right next to it, hooked up to the JeeNode. This requires either the 8-pin PSIX header or the 2×4-pin SPI/ISP header to be hooked up, as described earlier.

Read the rest of this entry »

Assembling the Bridge Board

In Hardware on Dec 1, 2010 at 00:01

This is going to be one of those long posts again, with lots of pictures…

I’ve switched to a new Bridge Board v2 revision, which differs only in some minor ways from the BB v1, so this also applies to that board. The changes are:

the FTDI connector orientation has changed to match the underlying JeeNode
one extra breadboard pin on the right, to better match the large breadboard
minor tweaks to layout and labeling

Since this is an assembly guide, let’s start with the parts included in the kit:

Dsc 2368

And here’s what we want to end up with – a module which plugs into a breadboard:

Dsc 2381

Ok, let’s get started… there are two current limiting resistors for the on-board LEDs. I prefer to mount them on the bottom of the board, because that leaves the “1” and “2” labels clearly visible on top:

Dsc 2369

Everything else is soldered on the top side of the board. Let’s start with the LEDs. These are polarized, so make sure to insert them properly:

Dsc 2370

The only other component left is the push-button:

Dsc 2371

Congratulations! All that remains is to solder on the various pin headers.

More…