Computing stuff tied to the physical world

Archive for January 2011

Back-soon server

In Hardware, Software on Jan 31, 2011 at 00:01

Soon, I’m going to move the JeeLabs server to a new spot in the house. Out of sight, now that the setup is stable.

But to do so requires rerouting an ethernet cable to the internet modem downstairs.

To do it right, I’d like to have a “we will be back soon” surrogate server plugged into the internet modem while transitioning, so that the status is reported on-line:

Screen Shot 2011 01 30 at 16.36.21

I could plug in a temporary Linux box, of course, or a laptop. But I want to keep this option available at all times, so a dedicated solution would be more practical. That way I can easily take the server off-line at any moment.

Ah, but that’s easy, with an Ether Card and an RBBB:

Dsc 2434

This combination just needs a 5..6V power supply, and 6 wires between the RBBB and the Ether Card.

Here’s the backSoon.pde sketch, which I’ve added to the EtherCard library:

Screen Shot 2011 01 30 at 17.24.05

In this case, being able to configure the MAC address of the interface as well as the IP address is in fact quite convenient, because this way the modem needn’t notice the hardware switch.

Only needs about 6 Kb. Actually, I’ll probably add a wireless option and use a JeeNode instead, to report total hits every once in a while. But either way, such a “back-soon server” really doesn’t come any simpler than that!

So if one of these days you see that message while surfing at JeeLabs, you know where it’s coming from :)

PS. I’ve put the back-soon server on-line as a test, it can be reached at

EtherNode on a breadboard

In AVR, Hardware, Software on Jan 30, 2011 at 00:01

After some recent comments on the forum about the etherNode.pde sketch, I wanted to make sure that the code is still working properly on this hassle-free setup (as well as with the Carrier Board):

Dsc 2432

And sure enough, it works as intended:

Screen Shot 2011 01 29 at 21.12.06

The output shows some packets from node 19 – which is the modded RFM12B running the RFM12B_OOK sketch, and it’s working nicely as you can see.

This sketch takes about 12 Kb of code (web server + EtherCard + RF12 driver), so there is ample room to add more features in there. You could use a modded RFM12B module, for example, and have everything you need to create a gateway between 868 MHz OOK devices and the LAN. In both directions in fact, since the RFM12B can also be tricked into sending out OOK packets.

Note that the Ether Card uses a few extra I/O pins from the JeeNode, so be sure to connect the 2×4 headers on the SPI/PSI pins between JeeNode and Bridge Board.

And the best part is that even with this Ether Card attached, all 4 ports on the JeeNode are still available for other uses. They are all brought out on the 8 leftmost pins, clearly labeled with both port numbers and Arduino pin numbers. Also available from the bridge board, as bonus: 2 LED’s and a push button.

As you can see, there’s a lot of empty real-estate on that breadboard – yearning to be put to good use…

PS. In case you’ve been waiting for one of those wooden bases, as included with the JeeNode Experimenter’s Pack: not to worry, I haven’t forgotten about you. The recent batch of packs were sent out without the base – they will be shipped separately once back in stock.

New OOK and DCF relay

In Hardware on Jan 29, 2011 at 00:01

With all the pieces finally in place, and now that I’m getting a little bit more time to hack around again, this seemed like a good time to reconsider the OOKrelay.

So I combined a JeeNode USB, the new OOK 433 Plug, a Carrier Board with box, and half a Carrier Card:

Dsc 2429

In the top left I also added a DCF77 receiver from Conrad, attached to the Carrier Card prototyping board. It’s a bit hard to see, because the little receiver board is actually mounted upright. Here’s a better view:

Dsc 2430

A JeeNode USB was selected, because this thing will be powered permanently, and I chose to hide the connector inside the box to make it more robust. So all this needs is a little USB charger. The LiPo charge option might be useful if I decide to make this thing more autonomous one day (i.e. to record accurate power outage times).

Note that this is a modded JeeNode, as described here, to be able to receive 868 MHz OOK signals.

So what this thing can do – as far as the hardware goes – is listen for both 433 MHz and 868 MHz OOK signals at the same time, as well as pick up the DCF77 atomic clock signals from Frankfurt. Sending out 433/868 MHz OOK is possible too, but since the unit isn’t constantly listening for OOK packets, it’ll have to poll for such commands, which will introduce a small delay.

That’s the hardware, i.e. the easy part…

The software will be a lot more work. I’m going to adapt / re-implement the functionality from the OOKrelay sketch, i.e. this unit will decode and re-transmit all incoming data as RF12 packets, so that they can be picked up by a JeeLink hooked up to my PC/Mac. The clock signal will be useful to accurately time-stamp all receptions, and is really of more general use.

So far, the following I/O pins have been used:

  • one port for the OOK 433 Plug, i.e. one DIO and one AIO pin
  • one input pin for the modded JeeNode, to receive 868 MHz OOK signals
  • one input pin for the DCF77 signal

There is still lots of room left for expansion. A Pressure Plug perhaps, to track barometric pressure. Or a Memory Plug to save up the last data while the central receiver is unavailable. Or both, since these can combined on a single I2C port.

Absent from all this, is a display. First of all, squeezing a 2×16 LCD in there would have been very tight, but more importantly, now that there is a JeePU, there really is no need. I’m already sending the info out by wireless, so a remote graphical display is definitely an option – without PC – or I could use a central server to get this info to the right place(s). This box is intended to be hidden out of sight, somewhere centrally in the house.

Only thing I might consider is a small LED near the USB cable, to indicate that all is well. Maybe… I’m not too fond of blinking LEDs everywhere in the house :)

Meet the OOK 433 Plug

In Hardware on Jan 28, 2011 at 00:01

After yesterday’s post about modding the RFM12B to receive OOK RF data, here’s a new option which goes the other way: add-on hardware for 433 MHz.

Meet the OOK 433 Plug:

This plug can probably be used without antenna, but adding one is bound to increase the maximum reception range (I haven’t done any range tests yet).

The receiver output is tied to the AIO pin, which must be configured as input on the JeeNode. The transmitter is tied to the DIO pin, to be used as output pin.

Both receiver and transmitter can be operated from 3..12V (I’ve only tested with 3.3V and 5V, so far). For the transmitter, I would expect the power output and range to increase with voltage, but even at 3.3V things seem to work quite well in both directions. There is a jumper to select between PWR and +3V as power supply, and there is an optional series resistor for the receiver output, which may be needed at higher voltages (normally, it can be omitted by closing that second jumper).

The reason for creating a separate plug is that it allows a single JeeNode to operate simultaneously on the 433 MHz and 868 MHz frequency bands. As suggested in the comments on yesterday’s post, a modded 868 MHz RFM12B can probably be made to receive 433 MHz OOK signals, but the receiver sensitivity is bound to be fairly low since the RF circuitry is really dimensioned for 868 MHz. Haven’t tried this, though.

There are several sketches which can be used with the OOK 433 Plug. To use the receiver on this board with little or no adjustment, try recv433_test.pde or ookRelay.pde. For tranmission, there is the send433_test.pde sketch.

I expect to combine and integrate code from the different OOK and relaying sketches in the near future, now that this plug has been created, but for now you’ll have to tinker with what’s available.

If you have suggestions (of better still: code or docs) for new protocol handlers to add and implement on a JeeNode, please let me know or share it on the discussion forum. It will interesting to see how many OOK protocols on 433 and 868 MHz we can figure out and implement, to make this all truly versatile for lots of different RF devices out there.

All code and docs are in the Café, with the OOK 433 Plug available from the shop, as usual.


Note – This server was down on Jan 28, from about 1:00 to 10:00 (CET). I’m investigating what happened.

OOK reception with RFM12B

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

A while back, JGJ Veken (Joop on the forum) added a page on the wiki on how the RFM12B can receive OOK.

I never got around to trying it … until now. In short: if you’re not afraid of replacing an SMD capacitor on the RFM12B wireless module, then it’s trivial!

Here’s what needs to be done – the capacitor on the left is 4.7 nF:

Screen Shot 2011 01 25 at 14.16.36

Unsolder it and replace it with a cap in the range 150..330 pF (I used 220 pF).

This cap appears to determine the time constant w.r.t. how fast the RSSI signal adapts to varying RF carrier signal strengths. With 4.7 nF, it’s a bit too sluggish to detect an OOK signal – which is nothing other than a carrier being switched on and off (OOK stands for: On / Off Keying).

The next trick is to connect the FSK/DATA/nFSS pin of the RFM12B via a 100 Ω resistor to AIO1 (a.k.a. analog 0, a.k.a. PC0, a.k.a. ATmega pin 23 – phew!):

Dsc 2427

As far as I can tell, this is a digital signal, so connecting it to AIO0 is really not a requirement. It might be more practical to connect it to one of the B0/B1 pins on the SPI/ISP header. Perhaps I should add a jumper in a future revision of the JeeNode PCB?

And lastly, the RFM12B must be placed in a special mode to get the RSSI signal onto that pin – i.e. compared to the RSSI threshold, also configured into the RFM12B (97 dBm).

All the pieces were there, and all I had to do was to follow the steps mentioned on the wiki page.

I made some changes to the code and added it as RF12MB_OOK.pde example sketch. Here is the main logic:

Screen Shot 2011 01 25 at 16.42.14

As you can see, all incoming data is forwarded using the normal RF12 mode packet driver.

Sample output:

Screen Shot 2011 01 25 at 16.56.39

It’s happily picking up FS20, EM10, S300, and KS300 packets, and the overall sensitivity seems to be excellent. And since it forwards all data as packets into the rest of the JeeNode network, I now have all the data coming in over a single JeeLink.

Sooo… with this “mod”, no separate OOK receiver is needed anymore for the 868 MHz frequency band!

PS. Haven’t done too many tests with this yet. Transmission is unaffected, as far as I can tell. Reception of packets with the RF12 driver still seems to work – it may be more susceptible to RF variations, but then again a “normal” packet uses FSK which is a constant carrier, so in principle this modification should not affect the ability of the RFM12B to receive standard FSK packets.

Thermo Plug fix (v2)

In Hardware on Jan 26, 2011 at 00:01

Another day, another fix.

The Thermo Plug also had a problem with layout, as described in this weblog post a while back.

I’ve had a new batch of boards made which moves the thermocouple screw terminal slightly outwards to get it out of the way of the AD597 chip:

Screen Shot 2011 01 25 at 16.54.26

The sharp edges come from the fact that new plug designs are now placed differently on a panel, using routing along the longer side of the plugs.

All plug PCBs and all JeeNode types have boards using a “standard” 21.1 mm width. The new approach simply means that these widths are now more accurate – “across the board” one could say :)

I’ve also addressed the transistor pinout confusion by adding a “C” label next to where the collector pin is.

Again, small tweaks, but good to have them resolved. All Thermo Plugs sent out from now on will be this new “tp2” version (the old board has “tp1” on it).

Onwards, again!

Carrier Board fix (v2)

In Hardware on Jan 25, 2011 at 00:01

This was looong overdue…

The Carrier Board has been updated to fix a problem with an incorrectly placed DC jack, as described here.

The new board simply omits the (faulty) connection to the DC jack:

Dsc 2421

If you want to use the DC jack you’ll need to connect some wires to it (both “+” and GND). It may not be the most elegant “fix”, but it’s effective and this change was risk-free…

To re-iterate: the DC jack can be soldered to all four pads now, there is no longer a risk of shorting anything out due to mixed-up wires on the schematic. It’ll be much sturdier than before.

All boards sent out in 2011 include the new design – you can recognize it by the fact that it includes the white DC Jack silk-screen printing on the back side – which v1 did not. And that it’s labeled “cb2” instead of “cb1”.


Easy Electrons – Transistor circuits #3

In Hardware on Jan 24, 2011 at 00:01

A third installement about transistors in this Easy Electrons series.

So far, I’ve shown how to get more current out of an I/O pin from an ATmega, since this will probably be the most common reason to use transistors in combination with a micro-controller. But these circuits all act as switches, i.e. they turn current on and off (or in the case of the voltage regulator: adjusting current flow to a certain value).

What if we wanted to control one or two DC motors for a little robot? Lots of fun stuff to do in that area, especially with wireless communication. To do this, we also need to be able to reverse the voltage placed on the motor, so we can make it turn forward or backward under software control. And if we want to make it a bit fancier, it would be nice if we could control the speed of the motor as well.

First things first. Reversing the direction of a motor can be done with a double-pole double-throw (DPDT) relay:

This low-tech solution will switch the +12V and the -12V poles to make the motor run clockwise or counter-clockwise. And if we were to use a transistor for the -12V (i.e. GND) side, we could also turn it on and off.

But that’s clunky! – let’s see if we can do differently. What we need is a way to place either a high or a low voltage on either side of the motor. Here’s a first (flawed!) attempt:

Look what happens when we put the proper voltages on A, B, C, and D:

  • with A high and B low, the left side of the motor is tied to “+”
  • with D low and C high, the right side of the motor is tied to “-“
  • it will start running

And now the other case:

  • with A low, B high, the left side of the motor is tied to “-“
  • with D high, C low, the right side of the motor is tied to “+”
  • it will start running in the opposite direction

And of course, when A = B = C = D = low, the motor will stop.

What the two transistors “on top” of each other do, is create sort of a push-pull circuit, since you can tie the central connection to either the “+” or the “-” voltage rail. This type of circuit is called an H bridge, due to it’s shape.

(note that I’ve left out 4 protection diodes, i.e. one across each C-E junction – they do need to be added in a real-world setup with DC motors)

There are several serious problems with this particular design, though:

  • to pull A or D high, we have to apply 12V, since 3.3V won’t be high enough to raise the base 0.7V above the emitter voltage level
  • if we pull A and B high, then we’ve got ourselves a short-circuit, with huge currents through both transistors on the left!
  • same for C and D…
  • and lastly, this thing needs a whopping 4 I/O pins

Let’s tackle that last point first: we can halve the I/O pin count by tying A and C together, and by tying B and D together. Now three out of the possible combinations will get us just what we want: stop, turn clockwise, turn counter-clockwise. But with both signals high, we still get a short circuit. Not good – we don’t want a software error to be able to start a fire…

The bigger problem though, electrically speaking, is that the input voltages involved are no longer suitable for an ATmega. This can be solved by adding an extra NPN transistor on both sides, for a total of 6 transistors. Instead of explaining the whole setup in detail, let me point you to some articles I found on the web:

  • this one describes the basic idea using relays
  • this page uses 6 transistors (lots more interesting pages on that site)

As you can see, it takes quite a few components to drive one small motor. Fortunately there are lots of H-bridge driver IC’s with various voltage- and current ratings. Some of these are quite small – such as the TC4424A I used on the DC motor plug, which is why I was able to actually put 2 of them on a single plug.

The second task we’d like to be able to do is control the motor speed.

This turns out to be fairly easy. The trick is to use pulse-width modulation (PWM). This is just a fancy term for a simple concept: we generate a set of pulses, and we control the on-time vs. off-time ratio of these pulses. As it turns out, DC motors are far too slow to follow these pulse trains if you generate them at 100 Hz or more. Instead, they will tend to average out the 0/1 values sent to them. And sure enough, a pulse train which is 100% off will cause the motor to stop, and a pulse train which is 100% on will cause the motor to run at full speed. Everything in between will lead to a motor running at intermediate speeds – simple!

For completeness’ sake, let me mention that the on-off power control circuits I’ve been describing in these last posts often use MOSFETs nowadays, instead of the traditional BJT transistors. For simple experiments and small DC motors, BJT’s are fine though.

Now if you think transistors are so great… wait ’till you see what MOSFETs can do!

I’ll go into those next week. Enough electronics for now.

Easy Electrons – Transistor circuits #2

In Hardware on Jan 23, 2011 at 00:01

Today, a second example of a transistor circuit. As announced yesterday, this one is about boosting the output current further…

With a transistor which amplifies current say 100 times, there are still limits to what you can control from an ATmega I/O pin: 10 mA x 100 = 1A. What if you want to drive a DC motor with a stall current well above that?

Quite simple, really: use two transistors “in series”. But how?

Note that this is not the way to do it:

Screen Shot 2011 01 22 at 23.13.37

On first sight, it looks exactly like what we need: after all, when the inout voltage rises above 2x 0.7V, both transistors will start to conduct, right? And since each of them can amplify their input current by 100, that means we could control a current which is a whopping 10,000x as large as the input current! So with the proper high-power transistors, this ought to work, right?

There is a sneaky problem, though. Keep in mind that the base voltage is always capped to at most 0.7V above the emitter, since the B-E junction is like a diode. So when the first transistor starts conducting, it’ll drive the second base up. Up to 0.7V, in fact. And that’s where things go wrong: the first transistor will drive 100x its base current into the second base. With 10 mA, that might well end up being around 1A. But most transistors can’t handle that: they expect small base currents to drive large collector currents. Another way to explain the problem, is that the C-E junction of the first transistor will always be 12 – 0.7 = 11.3V, so with a large current, it’s bound to overheat.

What we need, is a way to limit the current into the second transistor. Here are two ways to do it:

Screen Shot 2011 01 22 at 23.22.24

Both should work. The former is like a double amplification stage, whereas the latter uses the voltage follower approach described yesterday. I don’t really know which one would be better, because I’ve never tried either one.

That’s because there is also another circuit called the Darlington transistor, named after the person who invented it, Sydney Darlington:

150px Darlington Configuration.svg

The difference is subtle but important: the collector of the first transistor is no longer tied to the positive power supply rail, but to the collector, i.e. the lower side of the load.

The practical advantage of this combination, is that it’s still a 3-pin device, so you can use it wherever a transistor is being used, and that’s indeed it’s main raison d’être. Roughly speaking, a Darlington transistor acts like a transistor with a much higher current gain than a single transistor.

Its main drawback is that the saturation voltage, i.e. the voltage over the (combined) C-E junction, is higher than with a regular transistor – i.e. more like 1.1V than 0.4V. This is the voltage you get when driving the transistor all out – and it affects the amount of power absorbed by the transistor (P = E * I). So although a Darlington can switch higher currents from an I/O pin, it also generates roughly three times as much heat.

The reason I’m going into Darlingtons, is that they are very convenient and widely used. There is a 18-pin chip with 8 Darlingtons, tied into a tiny package, the ULN2803:

Uln 2803

This is what I used on the Output Plug, by the way. Not only does each pin drive 500 mA at up to 50V, you can actually tie them together to control larger currents. Each Darlington on this chip includes the necessary resistors, so it’s simply a matter of tying an I/O pin to its input, and it will “sink” up to 500 mA to ground.

An extra benefit of the ULN2803 is that it has a built-in reverse kickback protection diode, as needed when hooking up relays and motors. So that’s 8 more components saved, all by using this single chip.

Don’t get you’re hopes up too high, though. When driven from a 3.3V input, the output current of the ULN2803 might not go much higher than 300..350 mA on each pin. The components on the chip seem to have been designed for 5V. But it does work fine at 3.3V!

To summarize: the Darlington transistor pair is an easy way to get just a little bit more current (or more accurately: a higher gain) than from a single transistor.

So much for switching current on and off. Tomorrow, as last part of this mini-series, I’ll describe how to reverse the current as well, so we can also control the direction of a DC motor. And how we can control their speed. All with just a bunch of transistors.

Easy Electrons – Transistor circuits

In Hardware on Jan 22, 2011 at 00:01

With the basics and some real-world details out of the way, it’s time to start looking at some other circuits with transistors.

I’m going to describe three different types of circuits, to give you a feel for transistors – while noting that I’m just scratching the surface w.r.t. these amazing devices:

  • regulated power supply
  • more current with chained transistors
  • push-pull drivers

There’s way too much to say about this. Let’s get’s going!

Regulated power supply

In the post about diodes, I described a circuit based on a zener diode. One problem with that circuit was that it only worked for a few milliamps of current, the other was that this current was being drawn even under no load.

With a transistor, we can fix both problems at once:

Screen Shot 2011 01 21 at 23.48.09

Well, we’re not changing the fixed current draw really. But we can use a higher resistor value to draw less current, since only a little bit will will be needed to feed the transistor base.

So what’s going on here? Well, remember that the B-E junction is essentially a diode, connected in the forward direction. So from base to emitter, we have a 0.7 volt drop. Since the zener keeps the voltage fixed, the output voltage will be 0.7V below the zener breakdown voltage: i.e. 4 – 0.7 = 3.3V, tada!

The neat thing is that this is basically all there is to it!

The output voltage doesn’t really depend on the load current. With an amplification factor of 100, with a very light 1 mA load, the transistor will need to draw 10 µA on its base to generate that amount of current. It may seem like it does this as if by magic, “seeking” the proper settings all by itself. Let me try to describe what happens anyway. What we’re doing is keeping the base voltage at a fixed level. Here’s what happens when things start up, i.e. when the emitter is still at zero volts, right after turning on the power:

  • the base will then be at 0.7V, because it’s always 0.7V above the emitter level
  • this is much lower than the zener voltage
  • so all the current through R1 goes into the base
  • the transistor will amplify this and start conducting
  • that will “pull” the emitter voltage up, since the collector is tied to the input voltage
  • this in turn means that the load will be supplied with power
  • assuming the load is not a short circuit, the voltage on the emitter will rise
  • so will the base voltage – by 0.7V more, as always
  • at some point, the base reaches the zener voltage
  • that’s when current will start going into the zener
  • meaning: less current into the transistor base
  • where does it end? simple: when the emitter is precisely at 0.7V under the zener voltage
  • this adjustment process takes place continuously, so when the load current changes, the transistor will keep on adjusting its current to keep the base at the zener voltage
  • similarly, this will keep the emitter voltage at a fixed level even when the input voltage changes, since the voltage at the base remains the same

Voilá, a regulated power supply with a constant voltage output, a.k.a. a linear voltage regulator.

This voltage regulator will work fine for fairly large currents. After all, if we have a 10 mA current through R1, then a transistor with hFE 100 will be able to amplify this up to 1A.

But there is a catch: power consumption – again!

Note that the collector is held at the input voltage, and let’s assume this is fixed at 5V. And the emitter is held fixed too, at 3.3V in this example. So we have 1.7V on the C-E junction, with all the load current going through it. With a 1A current draw, that’s 1.7 watt of power. Not huge, but already well beyond what a little transistor can handle. This is why such circuits need to use power transistors and large heat sinks.

It gets worse with higher input voltage. Suppose we connect our setup to 9V instead of 5V. Now the C-E junction will have 5.7V over it, while still drawing 1A = that’s 5.7W of power, i.e. generated heat! So keep in mind, no matter how fancy your regulated supply is: if it works according to this “linear” principle, then it’ll turn all excess voltage into heat. See also an earlier post about this topic.

Our circuit also gives us a new way of looking at a transistor: while regulating, as shown above, it acts like a variable resistor, with the resistance being controlled by the amount of current flowing into the base.

So there you have it, the basic properties of a linear voltage regulator. I don’t want to stray too far from microcontrollers in this Easy Electrons series, but this really is a good example of how unusual transistors can be, compared to resistors and capacitors. Besides, voltage regulation is so common that it’s really useful to understand how it works and to be able to reason a bit about power consumption.

Tomorrow, we’ll go into “Darlingtons”! :)

2×16 LCD’s – yeay!

In News on Jan 21, 2011 at 00:01

At last… the long-awaited order of 2×16 character LCD’s has arrived!

Here’s what one of those boxes looks like:

Dsc 2418

Many of the pending LCD (+ LCD Plug) back-orders have now been sent out. Yippie!

That still leaves 3 more major items which are holding up a couple of packages: Carrier Board PCB’s, Relay Plugs and RBBB’s. The Carrier Boards are currently in Leipzig and will be here either on Friday, or else right after the weekend. The second item which is really hard to get these days, is the relay used on the Relay Plug – they are expected in about a week. The third item is the RBBB, which has been postponed a bit due to a temporary ATmega328 DIP shortage. This has now been resolved, so I expect to have them in by early February.


It’s strange how these supply issues can make such a difference… looks like I can’t seem to focus on anything substantial when there is a large back-log. Pretty silly, really. Oh well.

Sorry for the interruption, I just had to post about this. Tomorrow will be the third Easy Electrons post about transistors, as promised.

Easy Electrons – Transistors #2

In Hardware on Jan 20, 2011 at 00:01

Yesterday’s post started off a little mini-series about transistors. Today, I’ll go a bit more into the practical side of things. And in case you’re curious: tomorrow I’ll describe some interesting circuits with’em.

Let’s look at that NPN transistor symbol again:


First thing I want to point out is that there’s essentially a diode between the base and the emitter. The most important property of that, is that when there is current flowing from base to emitter, then there will be an ≈ 0.7V voltage drop across this “B-E junction”.

So yesterday’s calculation was a bit inaccurate. When putting 3.3V on the IN pin, current will flow through the resistor into the base, and from there to the emitter and to ground. Since the base is 0.7V above the emitter, and the emitter is tied to ground, there will be 3.3 – 0.7 = 2.6V over the resistor. Which means that the current through the base will be 2.6 mA, not 3.3 ma as reported yesterday.

With 0V on the IN pin, there is no current, so the voltage between base and emitter is irrelevant (0V in fact).

There was another inaccuracy in yesterday’s post (thx Reinhard), in that the current into the base also comes out the emitter. So with 2.6 mA into the base, and 3.3V current going into the collector, the total current coming out of the emitter is 2.6 + 33 = 35.6 mA (not 33 mA).

We’re not out of the woods yet. Transistors are not perfect conductors. Even when driven all out, there is a small residual voltage from collector to emitter. Usually it’s around 0.4V – this means we can now make much a more accurate calculation:

  • with 3.3V on IN, and 0.7V on the base, there is 2.6 mA into the base
  • with a current amplification factor (hFE) of 100, the collector-to-emittter current might reach 260 mA
  • however, the R2 resistor will limit this
  • with one side of R2 at 3.3V and the other at 0.4V, current through R2 is (3.3 – 0.4) / 100 = 29 mA
  • currents will be: 2.6 mA into the base, 29 mA into the collector, and 2.6 + 29 = 31.6 mA out of the emitter

Now we’re ready for a calculation which is crucial: the amount of power dissipated in the transistor!

It’s really very simple (P = I * E): the base current corresponds to 2.6 mA x 0.7 V = 1.82 mW, and the collector current corresponds to 29 mA x 0.4 V = 11.6 mW, for a total of ≈ 13.4 mW.

How do we know this? Well, if there is a current flowing and a voltage drop, then that’s by definition a form of power consumption. And it can’t turn into anything but heat, really!

Fortunately, 13.4 mW is very little heat, so even the simplest small-signal transistor will be able to handle it. But with larger currents involved, this type of calculation can tell you whether the circuit will: 1) work, or 2) overheat and fail.

Here’s an example to illustrate the point of such calculations – suppose you want to turn a motor on or off, controlled from an ATmega I/O pin:

Screen Shot 2011 01 19 at 23.45.31

(I’ll explain the “kickback” protection diode some other time – it just blocks, mostly)

We know that an ATmega can’t supply more than a few milliamps. Let’s assume it can output 10 mA, and that when doing so the output pin voltage drops to 2.5V – what value do we need for the R1 resistor? And what type of transistor would we need?

Clearly it depends on the motor. Let’s assume it’s a fairly small motor driven from a 12V power supply. What we need to make sure is that the circuit won’t break down. The worst case is when the motor “stalls” and then starts drawing a large current – that’s when something prevents it from turning while power is being applied. Don’t be surprised to see stall currents of several amps, even for small motors which only draw a few hundred milliamps under light load conditions!

Ok, now let’s figure out how much of a motor current we could handle with the circuit shown above:

  • to get max current output, we’ll feed as much current into the base as we can, i.e. 10 mA
  • so we’re feeding 2.5V, and the base is 0.7V, meaning that R1 needs to be (2.5V – 0.7V) / 10 mA = 180 Ω
  • let’s assume we get a transistor with an amplification factor of 100
  • IOW, it can only produce 100 x 10 mA = 1 A current

If we have a motor with a stall current larger than 1 amp, then something nasty will happen: the voltage between collector and emitter will rise above the 0.4V saturation voltage that you get when driving a transistor all out.

So what’s the problem? Heat!

We’ve got 12V on the one side of the motor. Say it has a 2A stall current. The transistor only amplifies its base current to let 1A through. What happens, is that the collector voltage will rise – my hunch is that it will reach about 8V (4V over the motor and 8V over the transistor, matching the 2:1 current ratio).

Now we’re in big trouble. The transistor is conducting 1A with a 8V voltage drop. That’s eight watt of power consumption, i.e. heat. If you take a simple little transistor which isn’t designed for that sort of heat dissipation, then it’ll heat up and go up in smoke. Fireworks!

Note how the lack of output current is what caused this. If the transistor had been able to deliver those 2A, then it’s power consumption would be “only” 2A x 0.4V = 0.8 watt – one tenth of what happened here.

As you might expect, there are several solutions around this. I won’t go into them here, though – I just wanted to go through these calculations to show you that you can’t drive everything directly from an ATmega I/O pin.

Tomorrow, some real circuits!

Easy Electrons – Transistors

In Hardware on Jan 19, 2011 at 00:01

Another installment of the Easy Electrons series. This time I’m going to follow up on the diode post, and go into transistors.

Transistors. Phew. Biiig topic!

There are several types of transistors. The most common one is the BJT. There are two variants, which are schematically drawn like this (from that same Wikipedia page):

Screen Shot 2011 01 18 at 23.32.33

A transistor has three pins, called Base, Collector, and Emitter. Using the convention that current “flows” from “+” to “-“, it’s easy to remember which in an NPN transistor (the most common variant):

  • the collector, eh, “collects” current – IOW, this is where current flows into the transistor
  • the emitter is where the current flows out again, to ground at some point
  • the base is the main control which determines what the transistor does

So what does it do?

One way to look at it, is as a current amplifier: put 1 mA into the base, and the current from C to E will be a multiple of that – anywhere between 50 and 500 times depending on the particular model, i.e. 50 .. 500 mA!

Note that I’m not suggesting that a transistor generates current. Only that when a voltage is applied between C and E, then the current flowing will be a multiple of the “control current” fed into the base.

Things are not quite that simple, though. How do you “put a current” into a component? You can’t just put a voltage on all the pins… before you know it, the current might easily exceed some allowed maximum rating! Transistors have pretty rigid limitations. When you exceed them, they can easily overheat and get damaged.

We don’t really have an easy way to control current, but what we can do is turn ATmega I/O pins on and off, i.e. control the output voltage on those pins. It’s relatively easy to turn that into current though – Ohm’s law: use some resistors!

Here’s a simple circuit to let us explore this behavior:

Screen Shot 2011 01 19 at 00.21.58

The input pin can be fed a voltage, and the R1 resistor will make sure that the current flowing into the base of the transistor will be limited. Likewise, R2 makes sure that no matter how much current the transistor wants to pass from its collector to its emitter, there will be a limit.

How much are these limits? Depends on the voltages and resistor values, of course. Let’s assume the following:

  • the “+” voltage is 3.3V (and GND is 0V, as always)
  • the input pin can have voltages between 0 and 3.3V applied to it
  • resistor R1 is 1000 Ω
  • resistor R2 is 100 Ω

The maximum current flowing into the base will never be more than when IN = 3.3V, i.e. 3.3V over 1000 Ω = 3.3 mA (using “I = E / R”).

The maximum current flowing from collector to emitter is what you’d get if the transistor were a complete short circuit between C and E, i.e. 3.3V over 100 Ω = 33 mA.

Note how I’ve made all sorts of worst-case assumptions about the transistor. In fact, I’ve calculated these values as if B, C, and E were all shorted together, and hence tied to ground (since E is tied to ground).

A real transistor behaves somewhat differently. But no matter how it actually behaves, I know that no more than 3.3 mA will be flowing into the base, and not more than 33 mA will be flowing into the collector and out of the emitter. Just about any NPN transistor can handle that.

Here’s what happens when IN is 0V (i.e. GND):

  • no current will flow into the base
  • since the transistor amplifies the current, no current will flow from C to E
  • if no current flows from C to E, then it’s basically like an open (unconnected) circuit
  • if unconnected, there will be no current flowing through R2
  • with Ohm’s law, the voltage across R2 is (E = I x R) = 0 x 100 = 0
  • so the voltage on the OUT pin will be 3.3V, the same as on the other side of R2

Now, when IN is 3.3V, this is what happens:

  • current will flow through R1
  • lots of current will flow from C to E
  • that’s the same as saying that C and E are more or less shorted
  • that means the OUT pin will now be (close to) 0V

We’ve created a signal inverter: 0V in = 3.3V out and 3.3V in = 0V out!

As I said, big topic. I haven’t even touched on some important details of a “real” transistor.

Stay tuned…

Two lousy caps

In Hardware on Jan 18, 2011 at 00:01

A couple of Ether Card kits have escaped into the wild without these ceramic 20 pF capacitors:

Dsc 2416

And a few probably also had no RJ45 MagJack (where you plug an Ethernet UTP cable into).

I’m very sorry about that. Turns out that we had a couple of kits prepared at a time when these components were out of stock. With the intention to add them into the bag before shipping.

In retrospect, placing those bags in the box was of course an urgent invitation for Mr. Murphy.

I’ve already sent out 2 sets of caps to people who’ve emailed me, but in case you recently got an Ether Card kit and these components were missing, pleasee email me. I’ll send them over asap, of course. I suspect that about a handful of these incomplete kits were sent out.

Stock levels are starting to return to normal here at Jee Labs, well at least to the point that most orders from 2010 have been processed (not all!), with a dozen single-item back-orders pending. Most of these are waiting for 2×16 character LCDs and Carrier Boards – both these are expected later this week. I’m also still behind w.r.t. the wooden base in the JeeNode Experimeter’s Packs.

On related news: there is a world-wide shortage of ATmega328 DIP chips, as you may have noticed. I’ve still got a couple to go, and more orders queued up for February and March, but it’s hard to tell right now when this is going to hit another of them atom-related walls around here.

On the plus side, all these stock issues have helped me better understand how to track what’s going on in the shop. I really wouldn’t mind adopting some sort of ERP and SCM systems at JeeLabs. Well… if they were a couple of orders of magnitude cheaper, that is :)

Two other interesting and related TLA’s are GLP and GMP – which describe ways to track exactly what goes on in laboratory cq. manufacturing processes. I’ve been involved with those in a previous life – the neat part is that if you get them right, then you can answer sort of “inverted questions” about a product, such as “what ingredients is it made of?” and “which batch of ingredients were used in this particular item?”.

Having such systems in place would have helped me figure out exactly who got the incomplete Ether Card kits, and then I would not have needed to publicly sollicit your help to fix this particular Murphy-case!

Oh well… one can always dream, right?

Touch screen mount

In Hardware on Jan 17, 2011 at 00:01

Electronics design is trivial compared to mechanical design, I tell you!

I’ve been looking at creating a Touch Screen option for the Graphics Board. In theory, it’s simple – just combine these two parts:

Dsc 2413

But how?

What I’d like to end up with of course, is that the touch screen is firmly held in place in front of the GLCD display:

Dsc 2414

The width of this touch panel is perfect. The touch surface is slightly higher than the 128×64 GLCD, but that could actually be used to create a couple of extra “fixed” buttons, perhaps even with some LEDs – right above the display itself (or below, if we turn the whole thing around).

It’s not hard to create a one-off mounting setup: just hot-glue the thing together, with plastic, wood, or foam-board. But that’s hardly a solution for others to replicate. And this really is one of those cases where the end result needs to look sharp, IMO. I’d really like to use this as a small self-contained unit for display and control of a few variables as part of a home-automation setup. So it better be robust. And battery powered, if possible.

The headache is the mechanical part… suggestions would be most welcome!

Poor Man’s Mesh Network

In Software on Jan 16, 2011 at 00:01

The recent packet relay and Extended node ID posts set the stage for a very simple way to create a fairly long-range (and very low-cost) little Wireless Sensor Network around the house.

Say hello to the Poor Man’s Mesh Network :)

Screen Shot 2011 01 14 at 13.54.50

(the main computer doesn’t have to be a PC/Mac, an embedded Linux box would also work fine)

Well, that’s a bit presumptuous. It’s not really “mesh” in the sense that there is no dynamic or adaptive routing or re-configuration involved at all. All the packet routes are static, so failure in one of the relays for example, will make everything “behind” it unreachable. In the world of wireless, that matters, because there are always unexpected sources of interference, and occasionally they completely wipe out the ability of a network to communicate on a given frequency band. For example, a couple of times a year, the data I’m collecting from my electricity and gas meters here at JeeLabs just stops getting in. Not sure what’s going on, but I’m not touching that setup in any way, and it’s unrelated to power outages. It might not be an RF issue, but who knows.

So what I’m referring to is not a super-duper, full-fledged, kitchen-sink-included type of wireless network. But given the extremely low cost of the nodes, and the fact that the software needs less than 4 kb of code, I think it’s a good example of how far you can get when using simplicity as guiding principle. Even an 8-bit MPU with 8 Kb of flash and 512 bytes of RAM would probably be sufficient for sensor nodes – so with the ATmega328’s used in JeeNodes, we really have oodles of spare capacity to implement pretty nifty applications on top.

Most of the details of how this works have already been presented in previous posts.

The one extra insight, is that the packet relay mechanism can be stacked. We can get data across N relays if we’re willing to limit our data packets to 66-N bytes. So by sacrificing a slight reduction in payload length we can extend the number of relays, and hence the total maximum range, as much as we like. Wanna get 10 times as far? No problem, just place a bunch of relays in the right spots along the whole path. Note that ACK round-trip delays will increase in such a setup.

The big design trade-off here is that all packet routing is static, i.e. it has to be set up manually. Each sensor node (the stars in that diagram) needs to have a netgroup which matches a relay or central node nearby, and within each netgroup each sensor node has to have a unique ID.

It’s not as bad as it may seem though. First of all, the range of the RFM12B on 433, 868, and 915 MHz is pretty good, because sub-GHz radio waves are far less attenuated by walls and concrete floors than units operating at 2.4 GHz. This means that in a small home, you wouldn’t even need a relay at all. I get almost full coverage from one centrally-placed node here at JeeLabs, even though the house is full of stone walls and reinforced concrete floors. As I mentioned before, I expect to get to curb and to the far end of our (small) garden with one or two relay hops.

Second, this star topology is very easy to adjust when you need to extend it or make changes – especially if all packet relays are one “hop” away from the central node, i.e. directly talking to it. You can turn one relay off, make changes to the nodes behind it, and then turn it back on, and the rest of the network will continue to work just fine during this change.

I’ve extended the groupRelay.pde sketch a bit further, to be able to configure all the parameters in it from the serial/USB side. These settings are saved in EEPROM, and will continue to work across power loss. This means that a relay node can now be as simple as this:

Dsc 2412

IOW, a JeeLink, plugged into a tiny cheapo USB power adapter. All you need to do is pre-load the groupRelay sketch on it (once), adjust its settings (as often as you like), and plug it in where you need it. How’s that as maintenance-free solution? And you can add/drop/alter the netgroup structure of the entire network at any time, as long as you’re willing to re-configure the affected nodes. If some of them turn out to be hard to reach because they are at the limit of the range, just insert an extra relay and tell the central software about the topology change.

It doesn’t have to be a JeeLink of course. A JeeNode, or some home-brew solution would work just as well.

Now that this design has become a reality, I intend to sprinkle a lot more sensors around the house. There have been lots of little projects waiting for this level of connectivity, from some nodes outside near the entrance, to a node to replace one of the first projects I worked on at JeeLabs!

So there you go. Who needs complexity?

Extended node IDs

In Software on Jan 15, 2011 at 00:01

The packet relay implementation shown a few days ago has some properties which somewhat limit its usability.

It all has to do with node IDs. As a relay it all works fine, i.e. packets will get relayed as intended. But the problem is that with a relay, all the packets relayed into another netgroup appear to come from that single relay node.

To go into this, let’s first set up a relay with the following configuration:

  • the main netgroup is #1, the relay listens on netgroup #2
  • the central node in netgroup 1 is node 31
  • the relay node listens on netgroup 2 as node 31
  • the relay sends packets out to netgroup 1 as node 30

Here’s that setup:

Screen Shot 2011 01 14 at 12.05.01

So – in principle – we could have up to 59 sensor nodes for getting actual work done. But there’s a problem: all packets sent by nodes 1..30 in netgroup 2 look like packets coming from node 30 once they reach the central node in netgroup 1!

Note that this is no problem if the relay is only used to extend the range of a single node: all we have to do is give the relay the same number of the node in netgroup 1 as what is assigned to that single node in netgroup 2.

But with more nodes behind the relay, we’re losing all their node ID’s. This is not very practical if we need to know exactly where the reported sensor data was generated, for example. We’re hitting the limitation that there are only 31 different ways to identify all incoming packets!

The solution is to insert the node ID of the original node as first byte of the payload data. So a packet coming from say node 7 in netgroup 2, will come in as a packet from node 30 (the relay), with an extra byte inserted in front of the packet, containing the value 7. The groupRelay.pde sketch has been extended to support this “multi-node relaying” capability.

On the receiving end, the software needs to know that node 30 in netgroup 1 is a relay. It then knows that the first byte is not data but an “extended” node ID, and it can use that to re-identify the packet as coming from a node in netgroup 2.

The extra data byte means that the maximum payload length across a relay is one byte less than what the nodes in netgroup 1 can send to the central node, i.e. 65 bytes instead of the 66 bytes supported by the RF12 driver.

Let’s use some conventions for node ID’s to support this mechanism. Node ID’s will be assigned as follows:

  • node ID’s 1..26 are available for “real” end points, e.g. sensor nodes
  • node ID’s 27..30 are available for relays and other “management” nodes
  • node ID 31 is to be used as standard ID for the central receiver
  • node ID 31 is also used by relays on the listening side
  • lastly, node 31 is normally the node which always listens, and which sends out ACKs

Note that there is nothing in the RF12 driver implementation which enforces such a numbering scheme. It’s just a convention to simplify configuration, and to simplify the software later on.

This scheme has the following implications:

  • the maximum number of end point sensor nodes is 26 x 250 = 6,500 nodes
  • each netgroup can have at most 4 group relays, i.e. the “fanout” is up to 4
  • each relay introduces a “hop” and may reduce the max payload size by one byte

Tomorrow, I’ll describe how to use this in a larger context.

Nodes, Addresses, and Interference

In Software on Jan 14, 2011 at 00:01

The RF12 driver used for the RFM12B module on JeeNodes makes a bunch of assumptions and has a number of fixed design decisions built-in.

Here are a couple of obvious ones:

  • nodes can only talk to each other if they use the same “net group” (1..250)
  • nodes normally each have a unique ID in that netgroup (1..31)
  • packets must be 0..66 bytes long
  • packets need an extra 9 bytes of overhead, including the preamble
  • data is sent at approximately 50,000 baud
  • each byte takes ≈ 160 µs, i.e. a max-size packet can be sent in 12 milliseconds

So in the limiting case you could have up to 7,500 different nodes, as long as you keep in mind that they have to share the same frequency and therefore should never transmit at the same time.

For simple signaling purposes that’s plenty, but it’s obvious that you can’t keep a serious high-speed datastream going this way, let alone multiple data streams, audio, or video.

On the 433 or 868 MHz bands, the situation is often worse than that – sometimes much worse, because simple OOK (which is a simple version of ASK) transmitters tend to completely monopolize those same frequency bands, and more often than not, they don’t even wait for their turn so they also disturb transmissions which are already in progress! Add to that the fact that OOK transmitters often operate at 1000 baud or less, and tend to repeat their packets a number of times, and you can see how that “cheap” sensor you just installed could mess up everything!

So if you’ve got a bunch of wireless weather sensors, alarm sensors, or remotely controlled switches, chances are that your RF12-based transmissions will frequently fail to reach their intended destination.

Which is why “ACKs” are so important. These make it possible to detect when packets get damaged or fail to arrive altogehter. An ACK is just what the name says: an acknowledgement that the receiver got a proper packet. No more no less. And the implementation is equally simple, at least in concept: an ACK is nothing but a little packet, sent the other way, i.e. back from the receiver to the original transmitter.

With ACKs, transmitters have a way to find out whether their packet arrived properly. What they do is send out the packet, and then wait for a valid reply packet. Such an “ACK packet” need not contain any payload data – it just needs to be verifiably correct (using a checksum), and the transmitter must somehow be able to tell that the ACK indeed refers to its original packet.

And this is where the RF12 driver starts to make a number of not-so-obvious (and in some cases even unconventional) design decisions.

I have to point out that wireless communication is a bit different from its wired counterpart. For one, everyone can listen in. Radio waves don’t aim, they reach all nodes (unless the nodes are at the limit of the RF range). So in fact, each transmission is a broadcast. Whether a receiver picks up a transmitted packet is only a matter of whether it decides to let it through.

This is reflected in the design of the RF12 driver. At the time, I was trying to address both cases: broadcasts, aimed at anyone who cares to listen, and directed transmissions which target a specific node. The former is accomplished by sending to pseudo node ID zero, the latter requires passing the “destination” node ID as first argument to rf12_sendStart().

For the ACK, we need to send a packet the other way. The usual way to do this, is to include both source and destination node ID’s in the packet. The receiver then swaps those fields and voilá… a packet ready to go the other way!

But that’s in fact overkill. All we really need is a single bit, saying the packet is an ACK packet. And in the simplest case, we could avoid even that one bit by using the convention that data packets must have one or more bytes of data, whereas ACKs may not contain any data.

This is a bit restrictive though, so instead I chose to re-use a single field for either source or destination ID, plus a bit indicating which of those it is, plus a bit indicating that the packet is an ACK.

With node ID’s in the range 1..31, we can encode the address as 5 bits. Plus the src-vs-dest bit, plus the ACK bit. Makes seven bits.

Why this extreme frugality and trying to save bits? Well, keep in mind that the main use of these nodes is for battery-powered Wireless Sensor Networks (WSN), so reducing power usage is normally one of the most important design goals. It may not seem like much, but one byte less to send in an (empty) ACK packet reduces the packet length by 10%. Since the transmitter is a power hog, that translates to 10% less power needed to send an ACK. Yes, every little bit helps – literally!

That leaves one unused bit in the header, BTW. Whee! :)

I’m not using that spare bit right now, but it will become important in the future to help filter out duplicate packets (a 1-bit sequence “number”).

So here is the format of the “header byte” included in each RF12 packet:

Screen Shot 2011 01 13 at 23.35.02

And for completeness, here is the complete set of bytes sent out:

Screen Shot 2011 01 13 at 23.34.14

So what are the implications of not having both source and destination address in each packet?

One advantage of using a broadcast model, is that you don’t have to know where to send your packet to. This can be pretty convenient for sensor nodes which don’t really care who picks up their readings. In some cases, you don’t even care whether the data arrived, because new readings are periodically being sent anyway. This is the case for the Room Nodes, when they send out temperature / humidity / light-level readings. Lost one? Who cares, another one will come in soon enough.

With the PIR motion detector on Room Nodes, we do want to get immediate reporting, especially if it’s the first time that motion is being detected. So in this case, the Room Node code is set up to send out a packet and request an ACK. If one doesn’t come in very soon, the packet is sent again, and so on. This repeats a few times, so that motion detection packets reach their destination as quickly as possible. Of course, this being wireless, there are no guarantees: someone could be jamming the RF frequency band, for example. But at least we now have a node which tries very hard to quickly overcome an occasional lost packet.

All we need for broadcasts to work with ACKs, is that exactly one node in the same netgroup acts as receiver and sends out an ACK when it gets a packet which asks to get an ACK back. We do not want more than one node doing so, because then ACKs would come from different nodes at the same time and interfere with each other.

So normally, a WSN based on RFM12B’s looks like this:

Screen Shot 2011 01 13 at 23.35.09

The central node is the one sending back ACKs when requested. The other nodes should just ignore everything not intended for them, including broadcasts.

Note that it is possible to use more than one receiving node. The trick is to still use only a single one to produce the ACKs. If you’re using the RF12demo sketch as central receiver, then there is a convenient (but badly-named) “collect” option to disable ACK replies. Just give “1c” as command to the second node, and it’ll stop automatically sending out ACKs (“0c” re-enables normal ACK behavior). In such a “lurking” mode, you can have as many extra nodes listening in on the same netgroup as you like.

To get back to netgroups: these really act as a way to partition the network into different groups of nodes. Nodes only communicate with other nodes in the same netgroup. Nodes in other netgroups are unreachable, and data from those other nodes cannot be received (unless you set up a relay, as described a few days ago). If you want to have say hundreds of nodes all reporting to one central server, then one way to do it with RF12 is to set up a number of separate netgroups, each with one central receiving node (taking care of ACKs for that netgroup), and then collect the data coming from all the “central nodes”, either via USB, Ethernet, or whatever other mechanism you choose. This ought to provide plenty of leeway for home-based WSN’s and home-automation, which is what the RF12 was designed for.

So there you have it. There is a lot more to say about ACKs, payloads, and addressing… some other time.

Another topic worth a separate post, is using (slightly) different frequencies to allow multiple transmissions to take place at the same time. Lots of things still left to explore, yummie!

Packet relaying vs. storage

In Software on Jan 13, 2011 at 00:01

In yesterday’s post I introduced a groupRelay.pde sketch, which implements a packet relay.

This can be used to (approximately) double the range between sensor nodes and the central data-collecting node. I’ve got two uses for this myself:

  • To try and get through two layers of reinforced concrete here at JeeLabs, i.e. from the garage to the living room to the office floor where my central data-collecting node is. I can get through one floor just fine (easily, even with a few extra walls), but two is giving me trouble.

  • To have a simple way to work with multiple groups of JeeNodes around here for testing and experimentation, while still allowing me to “merge” one of the test groups with the main, eh, “production” group. This can easily be accomplished by turning a suitably-configured relay on or off.

Note that all traffic takes place in the same 868 MHz frequency band. This isn’t a way to double the amount of bandwidth – all the packets flying around here have to compete for the same RF air space. All it does is separate the available space into distinct logical groups, i.e. net groups, which can be used together.

To summarize from yesterday’s post, this is how the relay code works right now:

Screen Shot 2011 01 12 at 18.07.18

If you think of time as advancing from top to bottom in this diagram, then you can see how the packet comes in, then gets sent out, then the ACK comes in, and finally the ACK gets sent back to the originating node. Let’s call this the Packet pass-through (PPT) approach.

This is very similar to how web requests work across the internet. There is an “end-to-end” communication path, with replies creating one long “round trip”.

But that’s not the only way to do things. The other way is to use a Store-and-forward (SAF) mechanism:

Screen Shot 2011 01 12 at 18.07.30

In this case, the relay accepts the packet, stores it, and immediately sends back an ACK to the originating node. Then it turns around and tries to get the stored packet to its destination.

This is how email works, BTW. The SMTP servers on which email is built can all store emails, and then re-send those emails one step closer to their intended destination.

There are several differences between PPT and SAF:

  • with PPT, it takes longer for the originating node to get back an ACK
  • with SAF, you get an ACK right away, even before the destination has the data
  • with PPT, all failures look the same: no proper ACK is ever received
  • with SAF, you might have gotten an ACK, even though the destination never got the data
  • with PPT, the logic of the code is very simple, and little RAM is needed
  • with SAF, you need to store packets and implement timeouts and re-transmission

But perhaps most importantly for our purposes, PPT allows us to place payload data in the ACK packet, i.e. ACKs can contain replies, whereas with SAF, you can’t put anything in an ACK, because the originating node already got an empty ACK from the relay.

Since SAF is harder to implement, needs more storage, and can’t handle ACK reply data, it just an inferior solution compared to PPT, right?

Not so fast. The main benefit of SAF, is that it can deal with nodes which don’t have to be available at the same time. If the relay is always on, then it will always accept requests from originating nodes. But the destination nodes need not be available at that time. In fact, the destination node might use polling, and ask the intermediate relay node whether there is data waiting to be sent out to it. In effect, the SAF relay now becomes sort of a PO box which collects all incoming mail until someone picks it up.

The implications for battery-powered wireless networks are quite important. With an always-on relay node in the middle, all the other nodes can now go to sleep whenever they want, while still allowing any node to get data to any other node. The basic mechanism for this is that the low-power nodes sleep most of the time (yeay, micro power!) and then periodically contact the relay node in one of two ways:

  • sending out a packet they want to get to some other place
  • polling the relay to get data waiting for them back as ACK reply data

The “sleep most of the time” bit is an essential aspect of low-power wireless networks. They can’t afford to keep a node awake and listening for incoming wireless packets all the time. An RFM12B draws about 15 mA while in receive mode (more than an ATmega!), and keeping it on would quickly deplete any battery.

So if we want to create an ultra low-power wireless network, we will neeed a central relay node which is always on, and then all the other nodes can take control over when they want to send out things and ask for data from that central node whenever they choose to. Which means they could sleep 99.5% of the time and wake up for only a few milliseconds every second, for example. Which is of course great for battery life.

BTW, in case you hadn’t noticed: we’re now entering the world of mesh-networking…

But the drawbacks of SAF remain: more complex logic, and the need to be able to queue up a lot of packets. So we need one node which is always on, and has plenty of memory. Hmmm, ponder, ponder… I remember having seen something suitable.

Of course: the JeeLink! It draws power via USB and has a large DataFlash memory buffer. Whee, nice! :)

Relaying RF12 packets

In Software on Jan 12, 2011 at 00:01

Since the RF12 driver does not implement a full OSI network “stack”, there are no such things as routers and mesh networks in Jee-land. This means you’re basically limited to the range of a single 868/915 MHz point-to-point packet connection.

There are a number of ways to increase the range. One is to use a directional antenna (I’ve never tried this, but it has been mentioned on the discussion forum). Another option is to lower the transmission baud rate inside the radio and the bandwidth settings, so that the power is “beamed” into a narrower frequency range. Both of these are based on RF properties.

A third option if you can’t get from here to there in one go is to take multiple “hops”. That’s what a mesh network tries to do fully automatically, adapting on the fly to varying reception conditions and network topologies.

I’m more interested in much simpler approaches, which can easily be implemented in a little 8-bit ATmega with limited code storage. There’s a lot we can do, even within these pretty hard constraints – and it’s fun to push those little boundaries!

So here’s another option: a dedicated “packet relay” node, which listens to a specific RF12 net group most of the time, and when a packet comes in, it turns around and sends the packet out over another net group. Apart from picking two net groups for this, the mechanism should be fairly transparent.

Here’s what happens when you install such a relay:

Screen Shot 2011 01 11 at 23.44.59

That only covers packets going one way. A refinement is to also deal with ACK packets. In that case, the relay should wait a little while to see whether an ACK comes in, and if it does, send that ACK back out to the original packet source:

Screen Shot 2011 01 11 at 23.45.05

Here’s a groupRelay.pde sketch, which implements this:

Screen Shot 2011 01 11 at 23.58.18

It’s pretty straightforward. But it’s only made for broadcast scenarios, i.e. the originating node must be using a broadcast packet (i.e. send to special node “0”). The relay can then simply re-broadcast the information.

In the case of ACKs, the originating node id will be in the header. The relay saves this, sends out a packet with an ACK-type request of its own, waits briefly for such an ACK to come in, and when it does, sends an ACK back to the originating node.

Note how the loss of packets will have the same effect as without a relay. The only difference being that there are 2 hops (or 4 w/ ACK) where packets can be lost or get damaged.

Tomorrow, I’ll explain a little bit what’s going on and what sorts of trade-offs this leads to.

Kit with SMD parts

In Hardware on Jan 11, 2011 at 00:01

A few weeks ago, I ordered a DDS-60 kit, because I wanted to do some experiments with an adjustable frequency generator. The kit is very interesting because it is controlled via a microcontroller, and because it works from 1 to 60 MHz, which is quite an impressive range for such a simple module:

Dds 60 (top) 400a

The other intriguing aspect was that it is built with SMD parts, so this kit needs to package a lot of very small components. Here’s what I got:

Dsc 2394

Very nice package. Not only are the parts individually labeled, they even were color-marked on one side. Here’s the SMD resistor / capacitor packaging in more detail:

Dsc 2396

What is a bit hard to see, is that these parts were actually sandwiched between a sheet of paper and a sheet of transparent adhesive plastic.

It was great fun to put together (I haven’t had an opportunity to try it out yet, but there is ATmega software for it among a long page of other options).

My curiosity was triggered because I found that the production of SMD kits such as the JeeSMD is fairly labor intensive.

We’re bound to go there more and more though, as an an increasing number of DIP-packaged through-hole chips and sensors are starting to disappear.

I’m not sure what that means for the future of Physical Computing hobbyists. It could go a couple of ways, IMO:

  • more and more “break-out boards” with the small chip pre-soldered
  • more SMD-style kits like the DDS-60, for hand-soldering with tweezers
  • a move towards low-end reflow controllers with manually-applied solder paste
  • … something else?

The first feels a bit more Lego-like to me, though it’s really an artificial distinction – as hobbyists, we’ve never manufactured the chips ourselves either, so it’s just one small “pre-fab” step extra.

Soooo… given the choice, in which direction would you want JeeLabs to go?

Wiki docs

In News on Jan 10, 2011 at 00:01

I’ve started adding some more info to the new “JeeLabs Café” wiki at

First change is that all products (boards, plugs, etc) now include at least these four files:

  • jlpcb-<NNN>.pdf – the schematic as a PDF page
  • jlpcb-<NNN>.sch – the schematic as EAGLE schematic (binary data)
  • jlpcb-<NNN>.png – the board traces as a PNG image
  • jlpcb-<NNN>.brd – the board design as EAGLE board (binary data)

The files are listed at the bottom of each page mentioned on the Hardware list (a read-only sub-area of the Café).

I’ve also started adding pointers to relevant weblog posts on these product pages. For example, the end of the JeeNode page now looks like this:

Screen Shot 2011 01 09 at 23.01.50

The other addition, is that I’m going to start adding pages focused around specific topics, acting as quick indexes into the weblog. The “stream of conscience” timeline that makes up the daily weblog is probably fine if you’ve been following along for some time and tend to read or skim most new pages fairly regularly. But for anyone stumbling upon this site out of the blue, I suspect that this site is really nearly impenetrable by now.

I don’t intend to the change the style and approach of the daily weblog, because it really is sort of a diary of my adventures through Physical Computing, finding my way around as a maker, and getting to grips with atoms. With all the ups, downs, exciting advances, and dead ends that I happen to bump into at JeeLabs.

But for task-specific and topic-specific access, it makes more sense to have an index to locate specific posts and perhaps annotate them a bit if the weblog entry is incomplete or obsolete by now.

Here’s the new Easy Electrons page on the Café to kick this off:

Screen Shot 2011 01 09 at 22.52.42

This new Easy Electrons index page is mentioned on the main Projects page.

The main page of the Café is still a bit crude, but there are a couple of automatically-generated pages worth visiting to find your way around in the Café, eh, I mean wiki:

Note also that the short URLs printed on all the pcb’s and on the package labels have been adjusted to point to pages in the Café. So when you type into your web browser, you’ll see a page which tells you that it’s a JeeNode v4, provides some info about it, and mentions that there is now a newer version.

I haven’t filled in all the older versions with full details yet, but for all current products, that two-letter-plus-a-digit code will always get you to the latest information in the Café.

Is everything perfect today? No… not by a long shot. But I hope this’ll let us move in that direction.

Easy Electrons – Diodes

In Hardware on Jan 9, 2011 at 00:01

It’s time for some Easy Electrons again.

Semiconductors are at the heart of today’s electronics designs: diodes, transistors, and the huge advances made possible by Integrated Circuits (i.e. IC’s) is what makes all those electronic devices around us possible. And it all happened in the time scale of just a few decades…

I can’t possibly cover everything in this series, so I’ll cover the two most common ones for now: the diode today, and the “normal” (BJT) transistor in the next installment.

Very roughly speaking, a diode is a one-way conductor. This is also indicated by the schematic symbol used for diodes (image from Wikipedia):

800px Diode 3d and ckt

The arrow-like symbol points in the direction of the current flow, if you stick with the convention that current flows from “+” to “—”. If you keep forgetting which side is called the Anode and which the Cathode, this trick might help: in the alphabet, we (eh, I mean currents) go from A (to B) to C.

Diodes are useful to protect a circuit against connecting a power source the wrong way around (we’ve all been there, right?):

Screen Shot 2011 01 08 at 22.40.28

With this diode, the circuit is protected. Hooked up the wrong way, the diode will block, so no current will flow through the circuit.

But diodes aren’t perfect. There’s a voltage drop when conducting current, usually around 0.7V. So with the above circuit, if the power supply is 5.0V, then the circuit will only get about 4.3V. With low-voltage components, and especially battery-powered devices, this sort of voltage loss is awkward – and often unacceptable.

Which is why you won’t see this reverse voltage protection very often in circuits operating at 5V, 3.3V, or less. There is another type of protection, however:

Screen Shot 2011 01 08 at 22.40.40

This one is a bit nasty. It doesn’t really prevent the circuit from getting a reversed voltage at all. Instead, it will act (almost) like a short circuit when the voltage is applied the wrong way around. The idea being that this will cause the power supply to shut down (or the battery to drain very quickly). The RBBB uses this type of protection to overcome the voltage drop problem. The (cheap) diode will protect the (much more valuable) ATmega, as well as all other components hooked up to it.

This sort of protection is tricky. If you were to connect a LiPo battery, for example, then the short circuit can cause HUGE currents to flow, since many LiPo’s are able to supply them. Think many Amps… and now something else may happen: even if the diode can handle the current, the rest of the power lines might well become overloaded. Especially thin copper traces on a PCB are likely to act like a fuse and simply… evaporate!

There are other ways to deal with the voltage drop and still end up with diode protection. One of them is to minimize the voltage drop – this is where Schottky diodes can be useful. They usually have only half the voltage drop of normal diodes, i.e. around 0.3V. That might just be low enough for your particular setup.

Another option is to build an “ideal diode”. This might sound like an impossible task, given the properties of diodes, but there is actually a way to do this using a MOSFET. I won’t go into MOSFETs here, but basically they can switch current while having almost no resistance and (Ohm’s law!) therefore also almost no voltage drop. Trouble is: MOSFETs don’t know which way the current is flowing, so you need considerable extra circuitry to tell them when to turn on and off, based on comparing voltages on both ends. And although it is not a simple or cheap solution, this datasheet of the LTC4413 chip shows that it is indeed possible to beat the diode characteristics with some clever engineering. Electronics is often like that: people have come up with the most amazing tricks to overcome certain drawbacks, for all sorts of electronic circuit tasks. That’s why it’s so much fun just exploring and discovering it all, IMO :)

The graph of what a diode does is very characteristic: in reverse mode it blocks, and in forward mode (i.e. above around 0.7V) it conducts, albeit not perfectly. For some good example graphs see this page on Wikipedia (just skip the math formulas and look at the pretty pictures).

Now, assuming the voltage drop is no problem, because you’ve got some extra volts from the power supply anyway, then diodes can be extremely useful. The bridge rectifier for example, can be used to get a properly polarized voltage out, regardless of how the power supply is hooked up. This is particularly useful with alternating current, as present on the AC mains lines and on the coils of a transformer (a lot more Easy Electrons articles will be needed to present all this stuff!).

Another interesting diode is the Zener diode. It’s like a regular diode, but one which can’t support a very high reverse voltage. With Zeners, this voltage is called the “breakdown voltage”, and it ranges from about 2..200V. The value is fixed for any particular model.

Zener diodes make very simple (low-current) regulated power supplies:

Screen Shot 2011 01 08 at 23.03.19

Note how we’re putting the Zener in reverse mode, and counting on it to break down. As it does, current will start to flow. Until enough current is flowing across the resistor (Ohm’s law!) to take up all the “remaining” voltage.

So with a resistor of 100 Ω, and a Zener of 5.0V, we could power it with say 6..9V. At 6V, the current would be (6 – 5) / 100 = 10 mA. At 9V, the current would stabilize at (9 – 5) / 100 = 40 mA.

The reason this can be used as a regulated power supply, is that we can connect our circuit in parallel with the Zener, and it would always get 5V. The only drawback is that we can’t draw more than 10 mA from it:

  • at 6V, the resistor needs to “eat” 1V, so that the Zener ends up with 5V
  • if the circuit draws 10 mA, then 0 mA will go through the Zener
  • if the circuit draws 5 mA, then 5 mA will go through the Zener
  • if the circuit draws 0 mA, then 10 mA will go through the Zener
  • at 9V, the current will increase to 40 mA (to get 4V over the resistor)
  • in all cases, the circuit will see a 5V input voltage

Cool, so now we have built ourselves a simple regulated power supply!

As I mentioned, this circuit is not very powerful. If we draw more than 10 mA, then the voltage drop over the resistor may increase, leaving less than 5V for our circuit.

There is another drawback with the above regulated supply: it’s grossly inefficient. The reason is that it will always draw 10 mA, whether our circuit needs it or not. And that’s at 6V – at 9V it will always draw 40 mA!

I’ll show you how a transistor can easily increase the current and improve the regulating efficiency in a future installment. Exploring these simple electronic circuits can be great fun, and most of the time you can reason your way through without even having to build them!

Next time: transistors – incredibly useful devices, with tons of ways to use ’em!

PS. Does anyone have tips on how to improve these diagrams? I really want to continue drawing them by hand, but the texts don’t come out very nice, no matter what I try!

Life resumes

In Musings on Jan 8, 2011 at 00:01

This thing came in recently – yippie!

Dsc 2410

Eh, 10.000 of them in fact – that ought to be enough for a while! ;)

In the past two days, I’ve been going through all the back-orders and sending out over 50 of them in fact. Note that most orders are bigger orders, since all the small and easy ones had already been dealt with.

This also brought out a serious shortcoming in my store’s inventory tracking system. I can see how many items are left (by going through the shelves and counting stuff), but I can’t see how much of those items are “already taken”, i.e. reserved for current back-orders.

Now in general, that’s not such a big deal, because most items are supposed to be in stock and the back-order is (should be!) low on most days. It was just a matter of making a mental note and taking care of the low-stock stuff.

But with so many items sold-but-not-yet-shipped, I’ve started seeing an avalanche effect: finding out that most of the stuff on the shelves was going much faster than anticipated while taking care of back-orders, and even running into some new shortages. Yuck.

This has happened to Ether Cards (now resolved), and has just happened to Carrier Boards as well (will be resolved in 2nd half of this month). Oh, and then there’s that 2×16 LCD which I think are in customs right now.

Summary: if you’re waiting for stuff, please hang in there. There’s more coming this weekend, but I’m not going to go all out 7 days a week and risk my health again. Been there, done that – I can now confirm from experience that it’s counter-productive.

In the atoms world, some limits, constraints, and delays are hard. Can’t do much else but respect that.

The good news is that I’ve just implemented some new tracking logic in my shop database, giving me real-time insight in those “already taken” figures. It’s nice to be on the consuming end of a database system for a change (I used to be on the producing end in a previous life).

Sorry for this somewhat off-topic post, but I’m going to call this Feierabend and enjoy the rest of this Friday evening watching a TV series with a nice sip of whisky. More substantial content to resume tomorrow.

LED discharge – measure or simulate

In Hardware on Jan 7, 2011 at 00:01

Yesterday’s post tried to create a new data point for measuring the forward drop voltage over a red LED at a slightly higher current. To summarize:

  • the voltage over the LED was read out as 2.229 V
  • the LED current was calculated to be 10.71 mA

But not so fast. What about component tolerances? What if the 100 Ω resistor isn’t exactly 100 Ω? And what if the supply voltage isn’t exactly 3.3 V?

It turns out that there’s quite a bit more going on here. Time to get the multimeter out and measure these values. If nothing else, this will be useful as cross-check against everything we did so far.

Here’s what I found (expected vs. actually measured):

  • 3.3V power supply = 3.298 V
  • “1” on VIN = 3.036 V (!)
  • “0” on VLOW = 0.213 V (!)
  • voltage over LED = 2.011 V
  • 100 Ω resistance = 99.7 Ω
  • current out of VIN = 7.85 mA
  • current into VLOW = 7.72 mA

Whoa – very different outcomes!

First off, this is a Voltcraft VC940 multimeter with 5-digit readout and a specified accuracy on DC voltage and current ranges (substantially) below 1%. For up to 4V, that means it shouldn’t be off by more than 20..30 mV, worst case.

First the good news: the power supply voltage on the 3.3V rail is very close to the desired voltage (3298 mV).

But check out those “1” and “0” digital I/O voltages: they are 3036 and 213 mV, respectively, i.e. around 10% off!

There’s a very simple explanation for that, and as it turns out, it’s in fact fully according to specs. Here is the output voltage you get when powering an ATmega at 3V, while drawing some current from one I/O pin:

As you can see, there’s just about a 0.3V drop at 25°C when drawing 10 mA. These I/O pins were not meant to be used as power supplies for other circuits, let alone as reference for analog circuitry.

Another way to put it, is that an I/O pin on an ATmega has an internal resistance of around 30 Ω. It’s easy to see that when we start drawing several milliamps through a 100 Ω resistor, then those “perfect” I/O signal lines are in fact a lot less like a real switched power supply.

The same holds for the “0” pin voltage levels. Once you start dumping current into such an I/O line, it will start to look more and more like a resistor tied to ground, and not just a direct connection to ground.

So the first conclusion is that the LED isn’t being fed as much current as we had expected, because the voltage levels are not quite 3.3V and 0V.

Let’s recaclulate our results with this new insight:

  • VIN = 3.036 V
  • VHIGH = 2.229 V (same as before, via the ADC)
  • VLOW = 0.213 V
  • voltage over the LED = 2.229 – 0.213 = 2.016 V
  • 99.7 Ω resistor voltage = 3.036 – 2.229 = 0.807 V
  • current through resistor = 0.807 / 99.7 = 8.1 mA

Ah, that’s a lot better: 2.016 V calculated vs. 2.011 V measured, and 8.1 mA calculated vs. 7.85 mA measured (about 3% off, oh well).

One last puzzle: why is the current measured out of VIN not the same as the current into VLOW?

You’ll need to check the schematic again to see what’s going on. Since the VLOW voltage is not 0V as would be the case with a perfect I/O output, there is now also some current flowing from VLOW to GND, through that other 1 kΩ resistor.

How much? Well, Ohm’s law points to the answer, as always: 0.213 V over 1 kΩ means there is 0.21 mA flowing through that resistor. Since the only source of power is VIN, and since all current must flow either into VLOW or GND, this means we can add that 0.21 mA to 7.72 mA to get 7.93 mA total.

Ok, it’s not conclusive in that some unexplained differences still remain, but this is nevertheless a lot closer to the real values in the circuit than the original 2.2V @ 11 mA we arrived at earlier.

Note that we don’t really need a multimeter to be able to make these corrections. I could have tied VIN to another analog input, to be able to use the digital I/O as (imperfect) power supply for the circuit, while at the same time measuring the voltage drop due to the higher current. I’ll leave that as an exercise for the reader.

There’s a lot more to be said about this sort of design and measurement work. Electronics is a very large field, and all we did so far, was hook up 4 simple components!

One very interesting option, is to simulate the circuit instead of building it on a breadboard. There is a well-known application for that called SPICE which takes a circuit description and computes, time step by time step, how the circuit behaves when subjected to certain input signals and power conditions.

JGJ Veken (Joop on the forum & wiki) was very kind to help out with a simulation of the LED discharge circuit I’ve been describing in these weblog posts. Here’s what came out:

Spice led Discharge

The voltage levels are slightly different, because the LED charateristics are different, but you can clearly see more or less the same graph as shown in yesterday’s post. Just to drive tht point home: yesterday’s results were measured in a real circuit, whereas the graph above is a simulation performed 100% inside a computer.

To find out more about this exciting way to try out circuits and explore different parameter settings, see these excellent wiki pages by JGJ Veken: 5Spice and LTSpiceIV. These are two different systems (both with common ancestry), the former commercial but free for personal use, and the latter available from Linear Technology as freeware (I don’t think either of them is open source).

So there you have it. This concludes my mini-series about experimenting with simple components, and using JeeNodes and Arduino’s to investigate the circuit and create a simple test-jig setups for it. Combine that with the SPICE simulation options available out there, and you’ve got a very simple and low-cost way to exlore electronics for yourself. Transistors? Filters? Op-amps? Go for it – there’s a world out there to explore and tinker with!

LED discharge – more measurements

In Hardware on Jan 6, 2011 at 00:01

Following earlier posts about the LED discharge circuit (here, here, and here), let’s do a few more measurements. Here is the schematic again:

I’m going to apply a 1-second charge pulse and then disconnect for 5 seconds, as before. This time, I’m going to disable the pull-up during those 5 seconds, and improve the timing of the reporting so the time to send out characters over the serial port does not affect the whole measurement cycle:

Screen Shot 2011 01 05 at 13.09.50

The reason the timing is so much better in this version, is that it is now based on MilliTimer, which continues to count while the serial port deals with its outgoing data. Note that 20 chars @ 57600 baud takes a few milliseconds, which can quickly add up when reporting values 10x per second.

The values are sent out in a format which can be used directly in a spreadsheet – here are the first few lines of output:

Screen Shot 2011 01 05 at 13.10.55

The values are:

  • voltage measured over the capacitor, i.e. LED + 1 kΩ resistor (Volts)
  • voltage measured over the 1 kΩ resistor (Volts)
  • difference, i.e. voltage measured over the LED (Volts)

Here’s a graph of the resulting measurements:

Screen Shot 2011 01 05 at 12.42.29

Due to Ohm’s law (E = I x R, i.e. I = E / R), that yellow line is also the amount of current going through the resistor in milliamps. Since there is no other path for the current than through the LED, by deduction this is also the current through the LED.

What you can see (blue curve), is that the capacitor charges up within a fraction of a second, and then discharges to under 2V in the next 5 seconds.

What you can also see (yellow curve) is that the current through the LED is proportional to the voltage on the capacitor. As the capacitor charges up, the current increases, and from the shape of the curves is should be clear that the relationship is essentially linear.

This is not surprising, since linear voltage-vs-current curves are inherent to resistive loads, i.e. the 1 kΩ resistor in this case. What is special is the LED placed in series with that resistor. What it does is “eat up” a fixed voltage, i.e. 1.8..1.9 V of the voltage present on the capacitor “stays” in the LED. The rest is passed on to the resistor, which does its usual linear current-to-heat conversion thing (only milliwats of heat in this case – we’re dealing with very small currents and very low voltages here).

But LEDs are not perfect devices. If they were acting like a perfect diode, they would have a fixed voltage drop, regardless of how much current goes through them. You can see from the green line that there is a slight change in voltage drop.

Does that mean a LED has something like a “hidden resistor” inside it? Not really. Here’s a plot over that same data, as current versus voltage:

Screen Shot 2011 01 05 at 12.50.33

That’s not very linear. Remember that resistors just do what Ohm’s law tells them to (or was it the other way around?): twice as much voltage = twice as much current, etc. Which in a graph would show up as a straight line.

In this case, the graph appears to be tapering off. In other words, as more and more current goes through the LED, its forward voltage seems to stabilize around a certain value. Probably around 1.9V, but this will be different for each type of LED.

Note that I placed the current on the horizontal axis, because that’s the variable we can control. The LED “decides” what voltage drop it wants to add.

What seems to be happening in this circuit, is that between 1.75 and 1.80 V there is a small amount of leakage. This is consistent with the video, showing that the LED continues to light up very dimly as the charge leaks away, even though the current is less than 0.25 mA, i.e. 250 µA, at these voltage levels!

Ok. Can we find out more about this forward voltage behavior? Sure. Let’s put 3.3V on VIN and 0V on VLOW, and then measure the voltage on VHIGH:

Screen Shot 2011 01 05 at 13.45.46

(Isn’t it fun to do this stuff under computer control?)

Sample output:

Screen Shot 2011 01 05 at 13.47.05

Whoa, looks like I need to revise my conclusions a bit. The LED forward voltage does go up quite a bit when more current is applied!

Let’s try to figure out how much current is flowing:

  • the cap is fully charged after a few seconds, so we can ignore it
  • therefore the cap voltage will be 2.229 V, as measured by the ATmega
  • and the voltage over the 100 Ω resistor will be 3.3 – 2.229 = 1.071 V
  • the resistor is 100 Ω so with “I = E / R”, we get 1.071 / 100 = 10.7 mA

IOW, at roughly 11 mA, the foward voltage drop of this particular LED is about 2.23V, quite a bit more than the 1.87 V we measured at 1 mA. But still not anywhere near a linear relationship.

Tomorrow, I’ll examine these results a bit more closely … because they aren’t quite right!

GLCD library

In Hardware, Software on Jan 5, 2011 at 00:01

There’s a new GLCD library to drive the 128×64 graphics LCD display on the Graphics Board. The library is called, wait for it… GLCDlib – with a wiki page and a web interface to the source code in subversion. There’s also a ZIP archive snapshot, but it probably won’t get updated with each future subversion change. For some notes about using subversion (“svn”), see this post.

The main class is “GLCD_ST7565”, it has the following members:

Screen Shot 2011 01 04 at 19.52.45

(some longer entries above were truncated, see the website for the full version)

The settings in this library have been hard-coded for use with the Graphics Board, which uses ports 1 and 4 to drive this display. If you want to use this with other I/O connections, you’ll need to change the #define’s at the top of the “GLCD_ST7565.cpp” source file in the library.

Here is the demo used in an earlier post, now included as “glcd_demo.pde” example sketch in the library:

Screen Shot 2011 01 04 at 19.49.49

This produces an output screen similar to this image. Note the use of flash-based string storage with “PSTR” to reduce RAM usage. It not an issue in this example, but more strings tend to rapidly consume RAM, leading to strange and hard-to-find bugs.

The nice thing about GLCDlib, is that you can also use it over wireless. There is a “GLCD_proxy” class, which sends all graphics commands out to another node. Each command is sent as a packet, complete with ACKs, retries, and resends to deal with lost packets.

The “JeePU.pde” example sketch implements the “host”, i.e. a JeeNode with Graphics Board, listening to incoming wireless requests. The “JeePU_demo.pde” sketch shows how to talk to such a remote JeePU node.

Because the transport layer (i.e. wireless or other comms mechanism) is separated out from the main graphics primitives, it is very easy to switch between a locally-connected GLCD and a remote one on a JeePU node. The magic is contained mostly in these lines:

Screen Shot 2011 01 04 at 20.02.40

The only other change needed to use a remote GLCD is to add these lines at the start of setup():

Screen Shot 2011 01 04 at 20.04.57

See the JeePU_demo.pde sketch for an example of how this can be used.

The JeePU node should be running in its own RF12 net group, because clients use broadcasts to send out the graphics commands. They do not need to know the node ID of the JeePU, just its net-group. This also means that multiple GLCD proxy clients can run at the same time, and each could be adjusting a specific part of the same JeePU display … whee, a multi-node status display!

One of the advantages of running the Graphics Board as a JeePU node, is that the other nodes don’t need to load the entire GLCDlib code, in particular they avoid the 1 Kb RAM buffer needed to drive the display.

The graphics code is based on what used to be the ST7565 library by Limor Fried at AdaFruit, which was in turn derived from public domain code attributed to “”.

Several great extensions (and a couple of bug fixes) for the core graphics routines were written by Steve Evans (aka tankslappa on the wiki and forum). Steve also implemented the remote/proxy code and the JeePU “host” and JeePU_demo “client”.

I just hacked around a bit on all that, including renaming things and adding an ACK mechanism to the RF12 wireless layer.

This code is likely to change and extend further, as we come up with more things to do with the current implementation. But for now, enjoy :)

Update – all the code is now at

Thermo Murphy

In Hardware on Jan 4, 2011 at 00:01

Mr. Murphy strikes again in the new year…

A post a while back, mentioned that the NPN transistor footprint on the Thermo Plug was wrong. I should have tracked this down earlier, but due to all the supply issues I only found some time just now (with thanks to Lennart for helping figure this one out).

Here’s the board footprint:

Screen Shot 2011 01 03 at 12.08.50

It’s not hard to see that from left to right, the pinout is emitter-base-collector.

Guess what… NPN TO-92 transistor footprints are not standardized!

Here’s the one from the BC549 I’ve been shipping in a few recent units:

Screen Shot 2011 01 03 at 12.06.16

Bzzzt… you have to mount it the other way around to make it work!

To give you an example of the mess w.r.t. orientation, here’s a diagram I found on Solarbotics:


And here’s the one from the 2N4401 I’m going to use for the Thermo Plug from now on:

Screen Shot 2011 01 03 at 12.05.37

Well, at least it’s just mirrored, with the base always in the middle. Not quite as bad as with voltage regulators (such as with MCP1702 vs LM2940, where the order is completely different).

If you’ve got a kit with the BC549, please make sure to mount that transistor 180° rotated w.r.t. what’s shown on the pcb. All units sent out from now on will have an NPN transistor which matches what’s on the board.

New wire jumpers

In Hardware on Jan 3, 2011 at 00:01

Just a quick note that the current Wire Jumpers in the shop are going to be replaced with new ones very soon:

Dsc 2407

Instead of 50 wires, the new pack will have 70 wire jumpers, consisting of the following length, in various colors:

  • 50x 80 mm
  • 10x 125 mm
  • 5x 165 mm
  • 5x 205 mm

Same flexible wire as before, with the same easy-to-insert pins on both ends.

No downsides, no compromises. Just more wires and more variations!

Easy Electrons – Need more power

In Hardware on Jan 2, 2011 at 00:01

Welcome to another installment of the Easy Electrons series.

There have been a few posts about What is “power”?, but that was about the electrical concepts of power and energy, and how it relates to voltage and current.

In this post, I’d like to go into a different topic: how to control more powerful electrical devices. As you’ve seen in the LED discharge circuit post, the I/O pins of an ATmega can be used as weak power supply, sort of. This is because an output pin set to “1” can be used as a 3.3V (5V on Arduino) power source, as long as you don’t draw more than a few milliamperes of current.

Here are the specifications of what a single pin can do, taken from the ATmega datasheet:

Source Datasheet

A few milliamps is not much. Barely enough to light a LED, and far too little to drive even the simplest electric motor. Let alone a light, a heater, or any AC mains appliance.

The first thing to note, is that there are a lot of different ways to control power – and each approach has fairly rigid limitations. You could use a power transistor to drive a bright 12V halogen lamp, but that same transistor would fail (spectacularly and dangerously so) if you tried to use it to control even the smallest AC mains lightbulb. Controlling power is a tricky business. As voltages and currents increase, so do the risks and potential effects of failure.

Let’s start simple, with an LED strip. These strips often need 12V to light up, and use about 300..900 mA per meter. There are several ways to control an LED strip of up to a few meters – using a relay, transistor, or MOSFET, respectively:

Screen Shot 2010 12 29 at 10.20.57

The relay is is the oldest type of power switch, and easiest to understand: an electromagnet closes a switch while powered up. It has been around for centuries. And although I included it as option, in practice even the smallest relays draw more current than what an ATmega I/O pin can supply (apart from very low power reed switches).

The transistor was invented only a few decades ago, and is at the heart of every electronic circuit these days. It’s usually depicted as follows in schematic diagrams (image from Wikipedia):

200px Transistor 2.svg

There’s a lot more to say about this fascinating invention. For now, let me just say that you can feed it a small current and it’ll control a much larger current (and voltage) on another pin.

And then there’s the MOSFET, which is even more recent than the standard bipolar-junction transistor. MOSFETs are pretty incredible: feed it a few microamps, and it can switch a huge amount of current (dozens of amps!). Perfect for direct hook-up to a microcontroller.

So how do we control an LED strip?

Easy – with a MOSFET, for example:

Screen Shot 2010 12 29 at 10.33.02

Note that the LED needs 12V at a fairly high current, whereas something like a JeeNode tolerates 12V – and needs only a few milliamps. In this case, we can get away with connecting both power supply inputs to the same 12V. The built-in voltage regulator will immediately reduce that 12V input to the 3.3V used in the rest of the circuit. So the voltage on the MOSFET “gate” will only be 0V or 3.3V – fortunately, that’s enough for many common MOSFETs these days.

It’s important to note that all these voltages and currents are fairly independent. The following would work just as well, using two separate power supplies:

Screen Shot 2010 12 29 at 10.33.14

I’ve drawn some extra arrows to indicate how the different current paths work. The crucial point is that current always needs to go through a closed loop. If the current “came from” the power supply on the left, then it will also always “return” to that same left-side supply. Think of it as “tagged electricity” if you like: what goes out of a battery on one en must come back on the other end of that same battery. It doesn’t really matter whether you think of electricity as “flowing” from + to –, or electrons flowing from – to +.

Note the connection between “–” on the left and “–” on the right. Without it nothing will work. The reason for this, is that voltages are always relative to some other part of the circuit. You can’t have a voltage (or a current, for that matter) over a single wire. You always need a return path. So in the case of the MOSFET, to drive it and put a voltage on it, you need to connect two wires – even if the current is small, as in this case. That’s why “–” is usually called ground, i.e. the reference against which we measure everything else.

Does this matter? You bet. If the power circuit uses a lot of current, then all its conductors must be able to carry that current: it needs thick wires! – but at the same time, the rest of the circuit can still get by with thin copper traces, as usual on boards like the JeeNode. This means that the ground connections (“–”) may need to be thick on one side, but not on the other – even though all ground connections have to be electrically tied together!

Current flow and proper design of all the wiring and connections is essential in power circuits. It’s a lot more involved than with purely digital circuits, or circuits which carry just milliamps.

How about controlling a lightbulb connected to 220V (or 110V)?

One way is with a relay (designed for such high voltages). But a relay can’t be driven directly from an output pin – so we add a transistor in between:

Screen Shot 2010 12 29 at 10.42.01

The extra resistor and diode are required (for reasons I won’t go into right now).

Note that there is no connection between this circuit and the switch shown at the top which is used to control the lightbulb. That relay does something which is crucial in the case of AC mains: it adds an isolation barrier between the low-voltage (safe!) side of the circuit and the AC mains (potentially lethal!) side of the circuit.

The second common way to control such a lightbulb is a Solid state relay, which uses a built-in opto-isolator to provide the isolation barrier. The advantage of an SSR is that it has no moving parts – hence no mechanical wear.

I’ve only touched briefly on how you can hook up stuff which needs more power than a feeble ATmega output pin can provide. Follow the links above if you want to find out more.

And marvel at the amount of knowledge and understanding Wikipedia brings us, freely available to anyone with an internet connection, anywhere in the world!

Meilleurs voeux de Paris

In Musings on Jan 1, 2011 at 00:01

Happy new year!

We’re celebrating with a brief trip to Paris, visiting friends.

We’re just south of Paris actually, in a tiny village called Vauhallan. Won’t have the opportunity to go to the “real” Paris today, so here’s a mini-impression from this delightful little village …

Regular transmissions will resume tomorrow :)