» Hardware Jee Labs

Sending packets without battery

In AVR, Hardware, Software on Sep 2, 2010 at 00:01

Here’s a fun experiment…

After yesterday’s improved power-down current results, I wanted to find out how much power it really takes to send out a bunch of small packets. No acks, just periodically sending out a packet and sleeping.

Trouble is, I didn’t want to wait for a battery to run down, since that would take months or even years. Bit long to get results for this weblog, eh?

So instead, I used this little chap:

Dsc 1873

It’s a super-capacitor which can handle up to 5.5V and has a capacity of 0.47 Farad! That’s like putting a thousand 470 µF caps in parallel. Amazing stuff, in an even more amazingly small package.

Here’s a JeeNode, fitted with this new power source, to give you an idea of just how small this thing is:

Dsc 1874

The next step was to design a small sketch to test this. Here’s what I came up with:

Screen Shot 2010 08 29 at 11.57.38

Some of the code left out for brevity. Full source code can be found here.

What this demo does is send out a packet with a 2-byte payload, then sleep for approximately 1 second, then send again, etc. Until power runs out.

Sure enough, packets started coming in every second:

    OK 4 0 0
    OK 4 1 0
    OK 4 2 0
    OK 4 3 0
    [...]

I expected it to send out say 100 packets or so, before the charge in the 0.47 F supercap would run out.

Guess how far it went…

    [...]
    OK 4 178 28
    OK 4 179 28
    OK 4 180 28
    OK 4 181 28

That’s packet number … clickety, clickety … 28 * 256 + 181 = 7349 !!!

In other words, the JeeNode was able to send out well over 7000 packets, i.e. two hours of packets sent once a second.

This is fantastic. I think the secret – apart from the 3 µA powerdown mode – is that the RFM12B + RF12 driver require very little time to start up, send off a packet, and go back to sleep again. There is no ACK involved, the RFM12B is hardly ever in reception mode.

With real-world use, I expect power requirements to be considerably higher. First of all, a Room Board will draw around 50 µA, due to the on-board PIR sensor. And second, I’m going to want to use ACKs for at least the motion detector reports, so that the system has a robust mechanism for reporting motion whenever it is detected. This means putting the RFM12B in receive mode for a few milliseconds, waiting for the ACK. And repeating this process a few times if that ACK isn’t immediately received.

But still … over 7000 packets without a battery!

Update – with one packet per 5 seconds, the charge lasted 4523 packets, i.e. just over 6:15.

Update #2 – with one packet per 60 seconds, 771 packets got sent out, that’s 12:51 hours … looks like the self-discharge of the supercap is eating up the remaining energy.

▶ View 9 Comments

Making 6-wire cables

In Hardware on Aug 31, 2010 at 00:01

I’ve been making cables for the Utility Plug recently. They come with the kit, but the reason for choosing these “modular” jacks and connectors, is that they are very easy to make yourself.

FYI, the 26 AWG wires in this type of cabling are rated for 360 mA current. Plenty for signaling and powering electronic stuff, but not suited for high power or high voltages.

I use the following low-cost crimp tool for most of my 4-. 6-. and 8-core cables:

Dsc 1851

Actually, I have a second one for 8-core cables (i.e. RJ-45 network cables) – it’s sturdier but also more expensive:

Dsc 1862

Here’s how the cable is made, from start to finish. First, make a clean straight cut:

Dsc 1852

Then you have to strip the outer mantle, without damaging the inner wires:

Dsc 1853

This is what comes out:

Dsc 1854

It fits perfectly into a “6P6C” RJ-12 modular plug (6 positions, 6 connections):

Dsc 1855

Now the magic part:

Dsc 1856

Seen from the other side, with the plug ready to be crimped on:

Dsc 1857

Here’s a before-and-after picture, you can see the metal pushed into the cable (and the cable jacket clamped for strain relief):

Dsc 1858

Another view:

Dsc 1859

How does it work? Well, here’s the crimp tool, in released state:

Dsc 1860

And here it is again, squeezed tight (it has a stop, ya can’t squeeze too far):

Dsc 1861

If you keep goin’ at it for a while, you get this:

Dsc 1863

And that’s where they end up at Jee Labs:

Dsc 1864

Easy. And if you don’t want to go through all this: just cut up a telephone cable instead (note that such cables will work fine, but most of them only connect the inner 4 wires, i.e. AIO, DIO, +3V, and GND, not PWR & IRQ).

Sensors

New PIR motion sensor

In Hardware on Aug 30, 2010 at 00:01

From now on, the Room Board is going to be shipped with a new PIR (passive infrared) motion sensor:

Dsc 1866

The reason I went looking for a replacement is that the ELV unit was out of stock for a long time, especially in quantity. It seems to be back now, but I had already found a good alternative.

The unit shown above is nice for a couple of reasons:

it’s equally low-power, drawing 40..50 µA
this unit is specifically for 3 .. 3.3V, whereas the ELV unit was running slightly out of spec
- (it officially requires 5..24V, but the regulator brings that to 3V)
it’s slightly lower on the sensor side (and higher on the component side)
the sensor seems to be sensitive over a somewhat wider angle
it’s no longer a kit, no need to solder-in that sensitive PIR chip anymore

I’ve yet to do some serious testing w.r.t. range, but it appears to be ok.

Here are the two sensors side-by-side:

Dsc 1867

One unfortunate detail is that the pinout is different. Yes, even 3 pins can lead to incompatible variations!

The old sensor has: VCC GND OUT – the new one uses: VCC OUT GND. Besides, I want to connect it to +3V now, i.s.o. PWR.

I solved this by using the other side of the room board, and reconnecting GND slightly differently – i.e. cutting the pin off and rewiring it as follows:

Dsc 1868

It’s a hack, but it works. The two remaining pins are still enough to keep the sensor board firmly in place.

Onwards!

Home automation

LED strip efficiency

In Hardware on Aug 29, 2010 at 00:01

LED lighting is efficient right? Oh, sure… the LEDs are, but the way they are connected isn’t necessarily!

I’ve always been puzzled by those resistors you see on RGB LED strips:

Dsc 1664 2

My impression is that these strips consists of segments which all have (essentially) the following schematic:

Screen Shot 2010 08 27 at 21.59.22

Measuring the 60-LED/meter RGB strip I have here, I get the following readings for 0.5 m, i.e. 10 of the above segments:

RED draws ≈ 180 mA, the voltage over its resistor is ≈ 5.5V
GREEN draws ≈ 170 mA, the voltage over its resistor is ≈ 2.2V
BLUE draws ≈ 190 mA, the voltage over its resistor is ≈ 2.4V

Total current draw is roughly 540 mA, or 1.08 A/meter @ 12V. So the total power consumption is 13 watts for each meter of LED strip.

But…

the red LED’s resistor consumes 0.18 x 5.5 = 0.99 W on each 0.5 m
the green LED’s resistor consumes 0.17 x 2.2 = 0.37 W on each 0.5 m
the blue LED’s resistor consumes 0.19 x 2.4 = 0.46 W on each 0.5 m

That’s 3.64 W of the 13 W pumped in per meter – turned into … heat!

Is LED lighting a good idea, in terms of efficiency? Yes, probably. A meter of RGB LEDs at full power draws 13 watts and looks a lot brighter to me than a classical lightbulb, halogen light, or even them new fluorescent “long-life” bulbs that are all the rage (but oh so ugly).

Note that I’m not talking of “power LEDs”, i.e. the 1W, 3W, or more LEDs that are used for very bright lights and which need te be mounted on a cooling fin (Infineon, etc). These are usually driven by a (more complex) constant-current source, and not a plain 12V supply. The reason for this is that at those power levels, you couldn’t possibly adjust the current draw via resistors – these would become scorching hot and cause lots of problems of their own!

The are a couple more figures to be gleaned from the above information, btw, but you can also measure these values directly on the RGB strip:

the red LED resistors are 300 Ω each, each LED gets 2.2V
the green LED resistors are 120 Ω each, each LED gets 3.3V
the blue LED resistors are 120 Ω each, each LED gets 3.2V

That voltage is the real reason for all these resistors. If you were to feed exactly 6.6V to the 3 red LEDs (9.8V for green, 9.6V for blue), then you wouldn’t need any resistors to pick up the slack. But that’s not feasible in a practical / cheap way, so instead we drive these strips with 12V and have the resistors eat away 28% of excess energy in the form of generated heat. Note: it would be more accurate to say: “if you were to feed exactly 180 mA, etc” … because the voltage is a “side effect” for each type of LED, the current is what determines their brightness.

Another source of inefficieny is the 12V power supply – let’s assume it’s about 90% efficient. Then 72 watts of power going into the LEDs will draw a total of 111 watts from the power line.

The good news is that these ratios won’t change when the LEDs are dimmed via PWM. A 50% pulse reduces the total amount of energy used by the same percentage (again: 28% of that is gobbled up by resistors).

Sooo… if you’ve got 8 meters of RGB strip going at full power, then that’s about 100 watts – 28 of which are turned into heat before they even reach the LEDs. And the power supply used another 11 to do its job.

I still think LED strips are a good idea – if I can get the white balance right and if their color is very even.

Fractional bits?

In AVR, Hardware, Software on Aug 28, 2010 at 00:01

To continue this little weblog series on bits, I’m going to go into bit fractions.

Yeah, right… there is no such thing, of course – unless you’re into probabilities or fuzzy logic, perhaps.

What I actually want to do, is describe “analog output” on the ATmega, using the Arduino library’s analogWrite() function. And throw in some bit manipulations along the way, to stay somewhat on topic.

The little secret with analogWrite() is that it doesn’t do what its name suggests. The ATmega has no way of generating an analog signal, i.e. a voltage level between 0 and VCC.

Instead, a pulse is generated, with a varying duty cycle. I.e. the “on” and the “off” times of the pulse will be different, the ratio of these times being proprtional to the 0..255 value passed as argument to analogWrite(). With “0″, the signal will be 100% off, with “255″ the signal will be 100% on. With “128″ the pulse will be on the same amount of time as off. With “1″, it will be on very briefly, and then off most of the time, and so on…

The neat thing is that you connect it to an incandescent lamp, or a motor, then the effect will be that these will light/turn at less than their full power, due to the time it takes for these devices to try and follow the pulse. So the effect is similar to a fractional adjustment: you can dim / slow down these devices by using analogWrite().

It even works with LEDs, although these turn on and off very fast. In this case, the reason is that our eyes can’t follow such fast changes, and so we perceive the result as dimmed as well. A whole industry was once created around this “persistence of vision” property of our eyes – it’s called TV…

Here’s a sketch which uses this pulsed output to control the brightness of a LED connected to DIO3 (i.e. D6):

Screen Shot 2010 08 27 at 16.44.38

Note that I didn’t have to define pin 6 as an output, analogWrite() does that.

What the above does, is ramp up gradually from 0 to 255, and then repeat:

Screen Shot 2010 08 27 at 16.49.06

Suppose we want it to fade in and out instead:

Screen Shot 2010 08 27 at 16.49.17

Try implementing this yourself.

Note that you’re going to need at least 9 bits of information to do this: 8 for the brightness level and 1 to keep track of whether you’re currently in the up ramp or in the down ramp:

Here’s one way to do it, using some bit trickery:

Screen Shot 2010 08 27 at 17.05.15

A few notes:

I’ve changed the “level” variable from an 8-bit byte to a 16-bit word
bit 8 toggles from 0 to 1 and back every 256 level counts
it’ll be 1 when level is 256..511, 768..1023, etc
when it’s 1, we flip the bits, i.e. 0 becomes 255, 1 becomes 254, etc
the analogWrite() function ignores all upper bits

If you think that was an obscure call to analogWrite(), try this one:

    analogWrite(6, level ^ -((level >> 8) & 1));

Maybe you can decypher it when written slightly differently?

    analogWrite(6, level ^ -bitRead(level, 8));

(hint: bitRead() always returns either 0 or 1)

It’s all pretty geeky stuff, and let’s hope you’ll never have to deal with code such as this again, but the point of this story is that there’s no magic. You just have to know what each operator does, and how to translate an integer from decimal to binary notation and back.

I’ll summarize my intuitive interpretation of bit operators below:

“X | Y” = take X and copy all the 1′s of Y into it
“X & Y” = take X and copy all the 0′s of Y into it
“X ^ Y” = take X and flip all the bits where Y has 1′s
“~ X” = flip all the bits of X
“- X” = arithmetic minus (same as “(~X) + 1″ !)
“! X” = 1 if X is zero, 0 otherwise
“X << N” = multiply X by 2, N times
“X >> N” = divide X by 2, N times

Some tricks based on this:

“~ 0” = all bits set to 1 (same as “-1″ !)
“~ 0 << N” = all bits 1, but N lowest bits set to 0
“bit(N) – 1” = a constant with N lowest bits set to 1
“X & (bit(N) – 1)” = the N lowest bits of X, the rest is 0
“X & ~ (bit(N) – 1)” = X, but with the N lowest bits set to 0
“!! X” = 0 if X is zero, 1 otherwise

An useful rule when writing logical expressions is: when in doubt, parenthesize! – see C operator precedence.

Sooo… use bit(), bitRead(), bitWrite(), bitSet(), and bitClear() wherever you can, since it usually makes the code easier to read. But there’s no need to get lost if you see ^&|~!’s in your expression – just slow down and decode such expressions step by step!

Flippin’ bits

In AVR, Hardware, Software on Aug 27, 2010 at 00:01

After yesterday’s post about setting and clearing bits, let’s explore reversing bits, i.e. changing them from 0 to 1 and back. And let’s do it by blinking an LED attached to DIO of port 1 – i.e. Arduino digital pin 4:

Screen Shot 2010 08 26 at 10.31.26

The “if (onOff = 0)” etc is the logic that toggles onOff between 0 and 1 on each pass through the loop:

    if (onOff == 0) onOff = 1; else onOff = 0;

But there are lots of ways to do the same thing, coded differently:

    if (onOff == 0) onOff = 1; else onOff = 0;
    if (onOff == 0) onOff = bit(0); else onOff = 0;
    if (onOff == 0) bitSet(onOff, 0); else bitClear(onOff, 0);
    onOff = onOff ? 0 : 1;
    onOff = (~ onOff) & 1;
    onOff = (onOff + 1) & 1;
    onOff = ! onOff;
    onOff = 1 - onOff;
    onOff = onOff ^ 1;
    onOff ^= 1;

See if you can figure out all of these.

Take your pick. Those last two use C’s XOR operator. I tend to prefer shorter source code, so I’d use that last notation (note that the resulting compiled code is not necessarily shorter than the other examples).

Now suppose you have a byte value “X” and you want to flip the 4th bit in it, while not changing anything else. That’s a bit more work. It could be done like this, for example:

    if (bitRead(X, 4) == 0) bitSet(X, 4); else bitClear(X, 4);

Or like either of these:

    X = X ^ bit(4);
    X ^= bit(4);

This shows clearly that the “^” XOR operator does exactly what we need: flip bits.

Back to blinking an actual LED, as done with the above sketch. Here’s a little mind bender – another sketch, doing the same using raw ports and the XOR operator:

Screen Shot 2010 08 26 at 10.58.10

The first example was doing things “the Arduino way”, using pinMode() and digitalWrite(). It compiles to 890 bytes of code. This second example goes straight to the hardware and uses 554 bytes of code:

Arduino digital pin 4 is bit 4 on the “D port” of an ATmega
“DDRD” is the “Data Direction Register”, where we set up pin 4 as an output
“PORTD” is the out “Port Register”, which controls the actual output signal

You can see the XOR in action in that last example. It takes all the output bits of port D (Arduino pins 0 .. 7), and flips just a single bit, i.e. bit 4.

Just for kicks, I’ll show you one more way to blink the LED:

Screen Shot 2010 08 26 at 11.03.44

This uses a relatively little-known feature of the hardware, which actually has “bit flipping” built-in. The “PIND” register is normally used for input, i.e. for reading the state of a pin as an input signal. But you can also write to that register. When you do, it will be used to flip output pins, but only for the bits which were set to 1. It’s essentially a built-in XOR.

That last example uses 550 bytes of code, most of which is overhead from the Arduino run-time library (setting up the milliseconds timer, etc). So what’s in a measly 4 bytes, right? Wrong. There is a minute, but sometimes important difference: the other approaches all had to read the register value first, flip the bit, and then write the value back. This last version only writes a (constant) value to a register. With interrupts, that can be very important: this last version can’t ever go wrong, it will always flip the requested bit. The other version could have an interrupt occur between the read and the write. It’s a known issue for the Arduino Mega. It can lead to code which runs for a week, and then fails mysteriously. Bugs like these are fiendishly hard to properly diagnose.

Bit-flipping can be quite useful for physical computing. Not only does it let you easily toggle specific bits, and change the state of some output pins, it can also be a way to clear a bit. Let’s say you need to generate a (very) quick pulse. Here are four ways to accomplish the same thing:

    bitSet(PORTD, 4); bitClear(PORTD, 4);
    PORTD |= bit(4); PORTD ^= bit(4);
    PORTD |= bit(4); PIND = bit(4);
    PIND = bit(4); PIND = bit(4);

That second one based on XOR works, because bit 4 is known to be one, so setting it to zero is always the same as flipping it. That’s also why the third PORTD/PIND example works, with PIND doing the XOR in hardware. Lastly, the fourth approach will only work if bit 4 was initially zero. It’s the fastest one, and does not suffer from the interrupt race condition mentioned above.

Ok, that’s enough flippin’ for one day!

Tomorrow, I’m going to go into, ehm… “fractional bits” (haha!) ;)

Update – see comment below on why “bitSet(PORTD, 4); bitClear(PORTD, 4);” are also interrupt-safe (mostly – but not on every pin of an Arduino Mega!).

Sideways?

In Hardware on Aug 25, 2010 at 00:01

I’m always looking for new ways to fit stuff together. JeeStuff ain’t no Lego, but that sure won’t stop me from trying to make it as modular as possible…

Here’s an idea:

Dsc 1842

I just used a pair of Proto Boards and inserted a bunch of plugs into them. Just to see what it would lead to, not as “the” actual design.

Would probably have to invent another type of “backplane” for this approach, but what surprised me was how sturdy the resulting object was.

Would probably need to have 15 to 25 possible slots to place headers in (perhaps even allow soldering the plugs in for good?). And some way to select which AIO and DIO pins go to which port. With I2C, they could be connected in parallel, with dedicated plugs you’d have to reserve a port for them of course.

The reason this could work is that everything in the JeeFamily has the same 21.1 mm width. That was quite deliberate, although I didn’t have this particular path in mind at the time.

Hmm… mounting? Power options? Ethernet? Breadboard area?

Just doodling… ideas are cheap – and plentiful, here at Jee Labs!

Meet the Utility Plug

In Hardware on Aug 23, 2010 at 00:01

To end the current series of new plug announcements, here’s one which is a bit of everything and nothing, called the Utility Plug:

Dsc 1834

It comes as a kit:

Dsc 1837

It brings out 6 pins to a modular jack, the same kind as used by fixed-line telephone sets around the world.

In its simplest form, you can just put a dab of solder on each of the 4 solder jumpers, and you’ll end up with a connector that brings out the 6 pins of any of the ports on a JeeNode. This plug kit includes a 1-meter length of flat white cable with a connector attached to one end. The other end is … up to you!

Modular plugs and jacks were chosen because they are very easy to get and crimp on (there are cheap plastic tools for it). If you don’t need the PWR and IRQ pins, i.e. if you only need to use AIO, DIO, +3V, and GND, then you can even take a spare telephone cable, cut it in half, and end up with… not one, but two pieces of cable which fit this connector! That’s because most telephone cables only connect to the inner 4 wires, but they still use this same 6-pin connector.

As far as I understand it, the 6-pin variant is called RJ-12, and the 4-pin variant RJ-11. They can be mixed because they have the same physical dimensions.

One reason I’ve wanted this Utility Plug for some time, is simply to have a more solid connector to plug and unplug stuff from, without having to mess with 6-pin headers. Unlike the headers, modular jacks are polarized, so there’s never a chance of connecting stuff the wrong way around – quite important once you’ve built a project and finished it by putting it inside a box, for example.

But that’s just the first half of the story…

As you can see, there’s a bit more going on with this plug. There are some places to add resistors, transistors, and diodes. The reason for this is that you often have to put a resistor in series (for say an LED), or to “pull up” the voltage on a pin, or even a small transistor to handle a little more current than a ATmega pin can by itself. Other uses would be to adjust the level of input signals, or to add reverse-polarity protection to an input pin.

The Utility Plug has 2 identical areas to handle such simple modifications:

Dsc 1840

Each of those dotted areas has the following circuit traces laid out for it:

Screen Shot 2010 08 22 at 19.55.15

(this is the DIO side, the AIO side is virtually identical)

This won’t be sufficient to deal with every scenario you might encounter, but my calculations tell me that it will deal with 27.183 ± 0.0002 different cases :)

To make this practical, a few extra components are included in the kit:

2x 100 Ω, 1 kΩ, and 10 kΩ resistors (1/6 watt)
2x 1N4004 diodes, for AC to DC conversion and to drive inductive loads
2x 2N4401 transistors which can switch up to 500 mA @ 40V

One word of advice when using this plug, is that you should really do some back-of-the-envelope calculations, to make sure things will work within the range you’re designing your circuit for. The resistors will let you keep currents down, and the transistor will let you generate a slightly more powerful output signal.

Remember: “E = I x R” is your friend!

Other components than those supplied can also be used, of course. Each section on this Utility Plug is nothing more than a miniature breadboard area with some pre-defined circuit connections.

See the café and shop pages for further info.

Now I’ve got to fire up some projects to use this thing. I’ll keep you posted when I get to that.

Another LiPo option

In Hardware on Aug 21, 2010 at 00:01

The other day, I found a Lithium battery in a local shop, which has just about the right size and properties for use with a JeeNode USB:

Dsc 1818

Found it here, for €9 … so it won’t break the bank.

The nice bit, apart from its size, is that it is fully enclosed and isolated, with two contacts which are easy to solder:

Dsc 1819

Do read that warning, and then proceed anyway :)

What you see above, is the battery with a bit of solder applied to each terminal. Next, I attached some wires:

Dsc 1820

I used two-sided tape to permanently fasten the battery to the JeeNode USB’s back side. Note that the headers were already soldered on, with all the extruding pins clipped to get a slightly flatter surface:

Dsc 1821

The ground wire didn’t need insulation after all, since it connects right next to where the battery is. The positive wire was connected to PWR on port 3, to leave the PSI header free if it ever needs to be hooked up later.

And that’s all there is to it:

Dsc 1822

There is no switch to disconnect the LiPo, so the JeeNode USB can run down the battery if it’s not running a good power-saving sketch. But who needs a switch anyway, when you can do it in software, right? Just upload this:

Screen Shot 2010 08 16 at 01.23.09

When run, the JeeNode will power off completely. This code has been added as “powerdown_demo.pde” sketch in the Ports library.

For proper use, sketches running on a LiPo-powered JeeNode USB should periodically measure the current LiPo voltage via the ADC6 pin, which is tied to a voltage divider. For this to work, the voltage should not have dropped below about 3.4V, so that the ATmega still gets a properly regulated 3.3V as AREF to compare with. The voltage on ADC6 is always half the voltage on the PWR pin. So what every sketch needs to do, is to occasionally measure the voltage, and once it reaches 3.4V, shut down completely using something like the above code.

So there it is – another JeeNode, ready to go … to recharge it, I just plug it into USB!

Meet the Opto-coupler Plug

In Hardware on Aug 20, 2010 at 00:01

After two new output plugs, here’s one for input – a dual Opto-coupler:

Dsc 1841

The idea is simple: feed it 5..50 mA of the proper polarity, and the other side can be read out by a JeeNode without any electrical contact. As the name says: light is used to remove the need for a galvanic connection.

This can be used for more than just high voltages: there are many cases where two different low-voltage circuits have independent ground levels, and where you want to keep it that way.

Electricity always takes the path of least resistance (literally!), and with high-current loads (or inductive spikes), you never know when some piece of equipment decides that it would love to send 5A through the GND pins across a JeeNode. There’s no danger involved here, but some traces on the JN print will go up in smoke (literally!).

A simple example is when you’re dealing with two power sources, and hook them up – accidentally or on purpose. Nothing will usually guarantee that the ground pins get connnected first. You might just briefly get the positive high-current supply hooked up in such a way that it finds another ground loop…

As with the Relay Plug, I’ll mention that you can use this Opto-coupler Plug to sense AC mains voltages (well not directly… more on that in a moment). But the risk is all yours.

The terminals on this plug are also detachable, but smaller: they use a 3.5 mm pin separation, and can handle a bit less current. The reason for this distinction is that you don’t want to accidentally put a high-power connector from the Relay Plug into this low-power Opto-coupler Plug. Since the connectors don’t match, this risk is avoided.

So what can you use as input source with this Opto-coupler Plug? Well… that depends – on the resistors soldered onto this plug, to be precise. Each resistor is in series with a LED contained inside the opto-coupler:

Screen Shot 2010 08 19 at 18.11.47

The dual opto-coupler used here will operate with roughly 4 .. 55 mA of current through the LED. The series resistors included with the kit are 1 kΩ @ 1/8W – this translates to a DC input voltage range of about 5 .. 12V. Any higher, and the resistor will get too hot – any lower, and the opto-coupler won’t trigger.

For higher voltages, you can replace these resistors with a higher value. Try to keep current consumption minimal, say 5 mA. Here’s the calculation to make it work with a 24V input: 23 V (roughly 1V gets taken up by the LED) with 0.005 A is … scribble, scribble, scratch, scratch … E=I*R … R=E/I … R = 23 / 0.005 = 4600 Ω!

So you should be good with a 4.7 kΩ resistor. Now let’s calculate the power consumption of that resistor … ponder, ponder … P=I*E … E = I*R … P = I*I*R = 0.005 * 0.005 * 4700 = 0.1175 W. Phew, a 1/8W (0.125W) resistor will work, but with little slack. Not surprising, really: the resistor is eating up 23 of the 24 V sent into the plug. Meaning: heat. That’s why low current use is best: current has a quadratic impact on the power consumption.

The trouble is that with 4.7 kΩ, you can only use the plug with 24V: any lower, and the current through the opto-coupler will be too low, any higher and the resistor will deliver its final puff, in the form of smoke…

So there you have it, with some free electricity calculations thrown in: this plug will work as is on a 5 .. 12V input source, and with the proper resistor value you can also make it work @ 12 .. 24V. The two inputs are fully independent, so different resistor values are possible.

If you happen to have a current-limited source in the 4 .. 55 mA range, then simply omit the resistors and put a dab of solder to close the jumper on the pcb. That’s 0 Ω, if you really want to know :)

On the JeeNode side, first enable the pull-up resistors on AIO and DIO, and then read them out as digital inputs. If you wanted to get maximum sensitivity, you could even use the AIO pin in analog input mode, and place the threshold a bit lower. That’s going to require a bit of experimentation (and it only works on the AIO side).

New café and shop pages have been added, as usual.

There’s one more new plug on the menu, a few days from now … that one will be a bit different from the rest. Even simpler, yet fairly versatile. Stay tuned!

LowPower

New AA battery option

In Hardware on Aug 19, 2010 at 00:01

Today might be a good day to set aside your dislike of Apple for a moment…

There is a new battery pack + charger option on the market:

Dsc 1816

In Europe, this combination costs €29.95, and it gets you 6 rechargable batteries plus a charger.

The specs are what make this thing particularly interesting for low-power battery-powered devices:

each NiMH AA cell holds 1900 mAh charge (rumored to be rebranded Sanyo Eneloops)
the batteries are reported to retain at least 70% of their charge for 2 years
battery lifetime is reported as being at least 10 years (with recharges, of course)
the charger drops to 30 mW “vampire” power draw once the batteries are charged

To start with the latter: I’ve verified it. When charging, there’s a small yellow LED and it draws less than 4 watts. When done, the LED turns green, and power consumption drops to 0.18W. Then, after 6 hours, the LED goes off and the power consuption drops to… zero! At least on the very sensitive SBC-500 I used.

This is a very big deal!

It means you can permanently leave these chargers plugged in, with a few spare AA’s. No cost, no waste – simply a way to keep a couple of cells fully charged and ready to go.

It’s also perfect for JeeNodes, using the standard 3x AA battery holder:

Dsc 1817

That’s 4.1V when fully charged. And JeeNodes will work with them all the way down to 3.3V, i.e. 1.1V per cell. Also, unlike LiPo batteries, running NiMH batteries down won’t do them any harm.

At last, I can stop wasting alkaline batteries… I’m probably going to replace all of them in the months ahead!

Meet the Relay Plug

In Hardware on Aug 18, 2010 at 00:01

Here’s another plug, useful for various applications around the house – the Relay Plug:

Dsc 1812

This one uses miniature relays to control two independent contacts. It has two MDC3105 relay drivers on board, and uses the same detachable terminals for connection to the outside world as the MOSFET Plug.

Unlike MOSFETs, relays provide a fully isolated switching capability. There is no electrical connection between the switched out pins on the terminal block and the JeeNode. The traces on the PCB were in fact laid out with a wide separation between switched pins and the rest of the circuit.

These plugs have just the right size for the Carrier Board + Box, by the way:

Dsc 1823

The relays currently used for this board are rated up to 3A @ 250V (both AC and DC). This means that you could use them for controlling up to 750W worth of devices connected to the mains on each output. Just keep in mind that messing around with the mains voltage is dangerous and can be lethal. Note also that neither the pins on the underside, nor the screws on the terminal blocks are isolated, so you’ll have to consider really carefully how to physically mount everything to prevent shock hazard. I definitely wouldn’t use these plugs for mains power in the box as shown above – such a box can easily open when dropped.

Did I mention that AC mains can be lethal? Ah, yes, I think I did…

Then again, if you know what you’re doing: sure, go right ahead.

For the rest of us, these relays are probably more suitable for controlling low-voltage lights, motors, fans, and… larger relays. One item on my (infinitely long) to-do list is to use these relays to control the power of a couple of external hard disks. Not just to save on electricity when not in use, but also because disks which are not powered up and hence don’t rotate are pretty safe from software mishaps, both accidental or malicious.

The relays are driven from the PWR line, which has to have a supply voltage between 4 and 6V to operate properly. Less, and the relays won’t turn on – more, and the relays + relay drivers will be damaged. Each relay draws about 30 mA of current while turned on. They are not latching: power loss will switch them off.

Controlling the relays in software couldn’t be simpler: use the Port class in the Ports library to set both DIO and AIO as outputs, and then use digiWrite() and digiWrite2() to control DIO and AIO, respectively. Since each relay uses up one port, you can have up to 4 Relay Plugs, i.e. 8 relays hooked up to a single JeeNode.

Here’s an example which listens for incoming radio packets to control a Relay Plug on port 1 (this example is included in the Ports library as “relay_demo.pde”):

Screen Shot 2010 08 15 at 23.18.02

Sending “1,1,17s” via another JeeNode or JeeLink turns both relays on. Sending “0,0,17s” turns them off again.

Documentation for the new Relay Plug is in the café, and there’s an order page in the shop for them now.

Meet the MOSFET Plug

In Hardware on Aug 16, 2010 at 00:01

There’s a new plug at Jee Labs – one I’ve been waiting to use myself for quite some time – a dual MOSFET plug:

Dsc 1807

The IRLZ34N’s used here should be able to drive over 5A @ 50V, but this will require a heatsink. For use without heatsink, a maximum currrent of 1 .. 3 amps should work fine. Just keep in mind that MOSFETs can generate a few watts of heat when used continuously at 2A or more. You can tie the MOSFETs in parallel for larger currents. You’ll need to add protection diodes to switch inductive loads, such as DC motors, relays, and solenoids.

This plug was designed for driving LED strips, but other loads can be driven as well. With two MOSFET Plugs, there are 4 individually controllable switches – to drive an RGB strip and a white strip, for example.

The terminal blocks used on this plug are heavy duty and detachable and use a standard 0.2″ grid (5.08 mm). They are much more convenient than fixed terminal block, particularly if the plug is mounted high or in some remote spot behind a book case or curtain. The two outputs have separate connectors.

The traces on this board have been made extra wide to be able to handle large currents flowing through the terminal block pins. The pins are laid out as two pairs: one side must be tied to ground, the other side (+A or +D) is then tied to the load, which in turn gets connected to a positive supply voltage (3..50V). Note that the positive supply voltage used by the load is not connected to the plug. A pulldown resistor is used to keep the MOSFETs switched off when the I/O pins are not connected, or not set up as outputs. Also, keep in mind that this plug ties the plug signal ground and the load ground together – it is not isolated from the load power supply.

The length of the plugs is 34 mm, making them a perfect fit for the Carrier Board + Box:

Dsc 1815

Note that a closed box provides little airflow to cool the MOSFETs, so this setup is not recommended for high-current use. Having said that, I’ve been driving a few meters of RGB LEDs with these MOSFETs without them even getting warm. See this earlier weblog post.

For dimmer use, there’s example code for a remote-controlled JN and 4 MOSFETs using software PWM.

I’ve set up a documentation page in the café and an order page in the shop. Since the prototypes worked on first try, these MOSFET Plugs are available as simple through-hole part kits right away.

A Murphy-less plug, so to speak :)

JeeNode, Techniques

Serial communication vs packets

In Hardware, Software on Jul 12, 2010 at 00:01

When you hook two devices up via wires, you’ve got essentially two options: parallel, i.e. one wire for each bit you want to transmit & receive (example: memory cards inside a PC). Or serial, where information gets sent across bit by bit over only a few wires (examples: ethernet, USB, I2C). Parallel can achieve very high speeds with little circuitry, but serial is more convenient and cheaper for large distances.

Serial communication is very common. The model even carries through to the way we think about the “command line” – a stream of characters typed in, followed by a stream of output characters. Not surprising, since terminals used to be connected via RS232 serial links.

Wireless connections are also essentially serial: you rapidly turn a transmitter on and off (OOK), or you change its frequency of operation (FSK), to get the individual bits across.

But there’s a lot more to it than that.

With two devices connected together, you get a peer-to-peer setup with a link which is dedicated for them. This means they can send whenever they please and things will work. The same can be done with wireless: as long as only two devices are involved, one device can send whenever it likes and the other will receive the signal just fine (within a certain range, evidently).

With such a peer-to-peer setup, the serial nature of the communication channel is obvious: A sends some characters, and B will receive them, in the same order and (almost) at the same time.

But what if you’ve got more than two devices? Ah, now it gets interesting…

With wires, you could do this:

Screen Shot 2010 07 11 at 11.20.41

It’s easy to set up, but it’s pretty expensive: lots of wires all over the place (N x (N-1) / 2 for N devices) plus lots of interfaces on each device (N-1). With 10 devices, that would be 45 wires and 90 interfaces!

Worse still, this is very hard to use with wireless, where each “wire” would need to be a dedicated frequency band.

The solution is to share a single wire – called multi-drop:

Screen Shot 2010 07 11 at 11.24.58

Now there’s one wire, a couple of “taps”, and one interface per device. Much cheaper!

Trouble is, you’ve now created a “channel” which is no longer dedicated to each device (or “node” as it is usually called in such a context). They can’t just talk whenever they like anymore!

Whole new slew of issue now. How do you find out when the channel is available? What do you do when you can’t send something right away – save it up? How long? How much can you save up? What if someone else hijacked the channel and never stops transmitting? What if all nodes want to send more than the channel can handle? How do you get your information out to a specific node? Can all nodes listen to everything?

Welcome to the world of networking.

All of a sudden, simple one-on-one exchanges become quite complex. You’ll need more software to play nice on the channel. All nodes need the same software revision. And you’ve got to deal with being told “not now”.

Note that these issues apply to wired solution sharing the same channel (RS485, Canbus, USB, Ethernet) as well as all wireless networks.

Simple OOK transmitters used in weather station sensors just ignore the issue. They send whenever they want to, in an après moi le déluge fashion… (“what the heck, I don’t care whether my message arrives”). This usually works fairly well when transmissions are short, and when lost transmissions are no big deal – they’ll send out a new reading a few minutes later anyway.

Another aspect of this shotgun approach is that it’s a broadcast mechanism. The sending node transmits its messages into the air without interest as to who receives them, or whether there’s anyone listening even. All it needs to do is include a unique code, so that the receiver(s) will be able to tell who sent the message.

For weather sensors, the above is ok. For security / alarm purposes, it’s a bit unfortunate – missing an intrusion alert is not so great. So what the simplest systems do is to yell a bit louder: repeat the alert message many times, in the hope that at least one will arrive intact. No guarantees, yet some very common security systems seem to be happy with that level of reliability.

For more robust setups, you really need bi-directional communication, even if the payload only flows in one direction. Then each receiver can let the transmitter know when it got a packet intact.

There’s a lot more (software) complexity involved to use a channel effectively, to get data across reliably with “ACK” packets, to detect new and lost nodes, to deal with “congestion” and external causes of bad reception, etc.

With JeeNodes and wireless comms via the RFM12B module, the basic RF12 driver is somewhere in the middle between unchecked uni-directional transmission and fully checked self-adapting configurations.

So what does this all mean for the “end user” ?

Well, first of all: wireless communication can fail. A node can be out of range, or a badly-behaved machine can be sending out RF interference to such an extent that nothing gets across no matter what nodes do. Wireless communication can fail, it’s as simple as that! But with bi-directional communication, at least all nodes can find out whether things work or not.

The second key property of communication via a shared channel, is that you can’t just send whenever you like. You have to be able to either save things up until later, or discard messages to let future ones through.

This means that treating a wireless channel as a serial link is really a very bad idea. Keep in mind that the baudrate can drop to zero – this means that you must be prepared to save up infinitely much data for re-transmission. And the more you intend to re-transmit later, the longer you’re going to have to need that channel when it becomes available. That will frustrate all the other nodes trying to do the same thing.

One way around this, is to use a RF link with very high data rates. That way there will be a lot of slack when nodes want to catch up. But then you still need to be able to buffer all that data in the first place. Not a great idea for limited devices such as an ATmega…

The better way is to design the system to work well with occasional loss of packets. Take an energy meter, for example: don’t sent the pulse or rotation trigger, but keep a count and send the current count value. That way, lost packets will not affect the accuracy of the results, they will merely be updated less frequently when the RF link is down.

The RF12 driver used in JeeNodes was designed for the context of a little data, sent on a periodic basis. The difference with a serial link, is that you don’t get garbled text on the other side, but packets (i.e. chunks of data). All you need to keep in mind is that occasionally an entire packet won’t make it.

This design also deals with multiple nodes. Each incoming packet can have a “node ID” so receivers can tell everything apart. Packets never get mixed up or combined or split in any way. Each packet is a verified and consistent amount of data.

Couldn’t we implement a virtual serial link?

Well, yes – there are well-known techniques to implement a virtual circuit on top of a packet-based communication channel.

But doing so would be a bad idea, for reasons which have hopefully become clear from the above. A virtual circuit would either have to act as perfect channel (not feasible with finite data storage) or drop characters in unpredictable places. It is far more practical to impose a packet / chunk structure on the sender, and then be allowed to drop chunks with clearly-defined boundaries when the RF link is out of service or overloaded.

The moral of the story: think in packets when using JeeNode wireless comms – you’ll get a lot more done!

Update – see some good comments by John M below, about IP, UDP, TCP, and the OSI model which describes all the levels of abstraction involved with networking, and all the standard terminology.

JeeNode, Techniques

RF12 communication

In Hardware on Jul 11, 2010 at 00:01

(This weblog post seems to accidentally have escaped into the wild a few days early…)

The RFM12(B) wireless radio modules from HopeRF, as used on the JeeNode, uses “Frequency Shift Keying” (FSK) as the way to get information across a wireless channel on the 433, 868, or 915 MHz band.

With wireless, there’s always a trade-off between speed and range. More speed, i.e. a higher data rate, lets you either get more data across in the same time or the same amount of data in less time, which might reduce battery consumption. But higher data rates require a larger frequency shift in the transmitter for the receiver to still be able to detect all the bit transitions reliably. A larger frequency shift wastes more power though (I think…). And a larger frequency shift means that the receiver has to accept more bandwidth to catch all the signal details.

Btw, another way to extend the range is to improve the antennas – see this discussion.

I’ll leave the narrow-band vs. wide-band details to the EE’s and amateur radio experts in this world, along with all the RF / HF calculations, because frankly I’m at the limit of my knowledge on these topics.

But what the above comes down to is that we’ve got essentially three parameters to fool around with when using RFM12B’s for wireless networking:

the data rate, which needs to be identical on both sides
the frequency shift on the transmitter side
the bandwidth on the receiver to filter out unwanted signals

Here are the relevant sections from the HopeRF RF12B datsheet:

Data rate

Screen Shot 2010 07 08 at 00.58.29

Frequency shift

Screen Shot 2010 07 08 at 01.00.43

Bandwidth

Screen Shot 2010 07 08 at 01.01.15

Screen Shot 2010 07 08 at 01.01.37

The challenge is to find “good” settings, which really depends on what you’re after. The settings used in the RF12 v3 driver are as follows:

Data rate = 49.142 KHz (see this discussion)
Frequency shift is set to 90 Khz
Bandwidth is set to 134 KHz

This was chosen partly on what I found around the web, and partly by pushing the data rate up while verifying that the range in the home would be sufficient for my own purposes (i.e. to reach the office from the electricty meter: a few concrete walls and floors).

It can probably be improved, but since such changes affect all the node in a net group, I never bothered after the initial tests were “good enough”.

The RF12 library now includes a new rf12_control() function, which allows making changes to these parameters. It’s a low-level option, but you could easily add some wrappers and an API to adjust parameters in a more intuitive way.

As mentioned in the forum, there’s a (Windows-only) tool to do the conversion to hex parameter settings. That ought to make it fairly easy to tweak these things, if you want to push the envelope.

Some people will no doubt be quite interested in such optimizations, so if you’ve found an interesting new combination of parameters, please consider sharing your findings in this forum discussion.

Having said all this, please keep in mind that these settings will still lead to fairly low data rates. The default data rate corresponds to ≈ 6 Kbytes/second of one-way data, assuming perfect conditions and 100% utilization (“hogging”) of the frequency band. With the official ISM rules imposed on the 868 MHz frequency band in Europe, each node is allowed to use only 1% of that rate – i.e. about 60 bytes per second of throughput! (there are no such restrictions @ 433 and 915 MHz – but 915 is not allowed in Europe).

There are alternate bands in the 860′ish MHz range, but I’ve never quite figured out what works where, so for now I’m sticking to this simple 1% rule. For day-to-day sensing and signaling purposes around the house, it’s actually plenty.

To put things into perspective: the IEEE 802.15.4 standard used by XBee’s has up to 16 channels of 250 Kbaud each at its disposal, when operated at 2.4 GHz. It’s a whole different ball game. And a different range: 2.4 GHz gets absorbed far more by walls than the sub-GHz bands (which is why mesh networking becomes a lot more important, which requires more resources, making it harder to keep overall battery consumption low, etc).

So you see: speed, range, complexity, cost – lots of tradeoffs, as with everything in this world!

Update – just got an email with a lot more info about the 868 MHz regulations (for the Netherlands, but I assume it’ll be the same across Europe). Looks like cordless headphones get 40 channels to pick from with 100% utilization (in the 864..868 MHz range), so you could pick one of those channels to avoid the 1% rule.

ISP, JeeSMD, Techniques

Assembling the JeeSMD, part 2

In AVR, Hardware on Jul 9, 2010 at 00:01

Yesterday’s post was about assembling all the SMD components of the JeeSMD kit.

The last step is to program a sketch into the ATmega. This isn’t as straightforwards as with a JeeNode, because there’s no on-board FTDI or USB serial port hookup.

It’s fairly easy to create an FTDI connection, but even if you do, you’ll still need an ISP programmer to install a boot loader (see this recent post for some background).

So let’s hook up an ISP programmer first:

Dsc 1787

I’m using a somewhat weird setup: first of all, my cable connector was attached the wrong way around, so I always have to use this one in that weird folded-over position.

But a more important issue is that the ISP connection needs to use pins 1..6 of the 2×4-pin SPI/ISP connector on the JeeSMD. That doesn’t work with normal flat cable connectors, which assume 2×3 pins and are too wide to fit in a 2×4-pin header. My solution is to insert wire-wrap pins the wrong way around into the cable header. This effectively extends the connector, but now it won’t be as wide and it’ll fit just fine. Another solution would be to only solder 2×3 pins in the SPI/ISP position – you can always add two more pins later.

Once you’ve passed that hurdle, you can use any ISP programmer you like. There have been several posts about this on the weblog, as listed here.

Now, if you want to use FTDI, then presumably you just uploaded a bootloader into the ATmega, with all the proper fuse settings, etc. The next step then, is to somehow connect to a 6-pin FDTI header.

There are several ways to do this. The one I use nowadays, is through a Carrier Board, which includes the 6-pin FTDI connector:

Dsc 1786

The point about the FTDI connector, is that it’s almost trivial. All you need is 4 wires to GND, PWR, TX, and RX – plus a way to reset the board from the RTS signal. The clever way to generate a reset is to insert a 0.1 µF capacitor between the serial side RTS and the ATmega’s reset pin. Tiny trick, huge implications (does the name “Arduino” ring a bell?).

So how does the Carrier Board implement FTDI? Easy: it adds the capacitor. And you can easily do that yourself without a Carrier Board. Here’s how:

Screen Shot 2010 07 08 at 23.20.52

Note that what FTDI calls “RX” is connected to what the ATmega calls “TXD”, and vice versa. It’s all a matter of perspective… Once you have the FTDI connection set up, you can upload sketches using the Arduino IDE just as with any other board. All you need is a USB-BUB or some other equivalent USB-to-FTDI interface.

Congratulations: that’s all it takes to build and use the Arduino-compatible JeeSMD!

JeeSMD, Techniques

Assembling the JeeSMD

In AVR, Hardware on Jul 8, 2010 at 00:01

The JeeSMD is a kit with tiny “Surface Mounted Device” (SMD) components. SMD was designed for automated assembly with Pick & Place machines, but with a bit of patience it’s fairly easy to assemble a board by hand – see this post for an overview of what you will need.

You won’t be able to do this without at least a fine-tipped (0.4..0.6mm) soldering iron plus the following tools:

Dsc 1773

A magnifier lamp also helps, I know I couldn’t do this without one anymore!

This is a step-by-step guide on how to assemble the SMD kit, which consists of these parts:

Dsc 1772

The tiny ones (don’t sneeze!) are hardest to tell apart:

Jee smd Closeup

(thanks to Steve E for the macro shot – I just added some labels)

There are 2 10 kΩ resistors in there, although you only need one. That lets you get started without having to worry too much – if you mess up completely, just remove it and start over with the other one.

For a fantastic resource with detailed videos about hand-soldering SMD, see this Curious Inventor page.

So let’s get started. First thing to do is to apply flux wherever you’re going to solder things. The flux is essential because the flux in your solder wire will have evaporated longe before you can move your tip from the wire to the part.

I’m right-handed, so that’s how I hold my soldering iron. That leaves only my left hand for the tweezers – and no hand at all for the soldering wire:

Dsc 1774

Use your tweezers for all these parts, and don’t let go – once a 0603 part flies off or drops on the floor, your chances of finding it again are next to zero. Best is to work on a clean flat surface with everything around you removed.

The trick is to place the part and then push it down while you touch it with your iron with solder already on it. The moment a part is soldered down on at least one pin, it becomes a lot easier:

Dsc 1775

The matte “stain” you see around these pads is the flux, which has dried up but is still active.

(Remainder continued after the break…)

Musings

A whole lotta boxes

In Hardware on Jul 5, 2010 at 00:01

There are tons ideas floating around here at Jee Labs (thanks in no small part to a few people joining in on the brainstorming side of things). Never a dull moment!

One direction I’d like to explore a lot further, is coming up with kits which include a really nice enclosure. Even geeks sometimes like to show off their creations in such a way that not all the guts are spilling out, with wires everywhere, and everyone else scared of messing up… or even just touching something.

Because I like to get a real physical feel for things at times, I ordered a large set of ABS enclosures in a wide range of shapes, varieties, sizes, and colors:

Dsc 1760

See? That’s what “research” looks like! ;)

Now there are many ways to create enclosures, also with acrylic panels, aluminum plates, and PCBs. Even 3D printing is starting to become an option. Not to forget my favorite foam board, and more environmentally friendly materials such as cardboard and wood.

In many cases, it’s possible to fit a project + board into an enclosure after the fact – especially if the enclosure is made specifically for that purpose. And sometimes you just get lucky and find a case which turns out to fit existing boards really well with only a little extra tweaking:

But sometimes it’s easier to pick an enclosure first, and then see whether a proper board can be designed to create a perfect fit.

This is what the JeeLink did, and it ended up becoming a really practical gadget, IMO:

Anyway, with this new “box full of boxes” at Jee Labs, I hope to be able to design more kits in the future which are not only fun to build, but also end up looking good and practical for daily use in and around the house. We’ll see.

“Making stuff fit” is often a neat puzzle. But it’s also easy to overlook details – always the crucial ones, of course.

Arduino, ISP, JeeNode

Uploading? ISP? FTDI? Huh?

In AVR, Hardware, Software on Jul 4, 2010 at 00:01

There seems to be a fair bit of confusion in- and outside the Arduino world, and it’s spilling over to JeeNodes …

I’d like to go through some terms and buzzwords to try and clarify how to get your Arduino or JeeNode to do the thing you want it to do. I’m going to assume that you are familiar with the process of writing software (“code”), compiling it, and running it – at least on a Windows, Mac, or Linux computer (let’s call them all PC’s for now). With software for the ATmega, there are two approaches, depending on whether you use the Arduino IDE or not:

Screen Shot 2010 06 28 at 23.50.22

Both lead to the same result: a “hex” file with code that needs to be transferred from the PC to the ATmega.

The step which can be puzzling when starting out with physical computing and embedded hardware is how to get things across from your PC to that little Arduino or Arduino-like system you’re holding in your hand. And vice versa, since we often want to get results back or see some confirmation that things are working properly.

The confusion comes from the different conceptual levels involved, and things like:

do you mean how to connnect? – plug in a USB cable
do you mean how does the ATmega change its own code? – through a boot loader
do you mean via ISP (In System Programming)? – no, that’s normally not needed
do you mean via FTDI? – yes, that’s the name of the chip which is hooked up to USB
isn’t FTDI a connector? – yeah, that too, sort of… i.e. a 6-pin convention
isn’t a power + serial cable enough? – no, resets also play a key role
do I have to use the Arduino IDE? – no, you can also use a program called “avrdude”
what’s avrdude? – a program which can upload to a boot loader or an ISP programmer
do I need an ISP progranmmer? – nope, the boot loader does essentially the same thing
so why not just get rid of ISP? – because you need ISP to install the boot loader

Confused? Welcome to the club…

In case you’re wondering… the process is called “uploading” because the PC initiates this as outbound transfer:

Screen Shot 2010 06 29 at 01.51.50

To get your code (“sketch” in Arduino-speak) into an ATmega, you need three things, working together to make uploading happen under all possible conditions:

An electrical connection – to power the ATmega, to communicate with it, and to restart the ATmega when it is stuck or busy doing something else.
A common language / protocol – the communication must be understood by both sides, i.e. PC and ATmega.
Software on both sides of the connection – Sending something when the other side isn’t listening, or listening while no-one is sending will not have the desired outcome.

Let’s go through each of these separately.

1. An electrical connection

There are several ways to make the connection. With an Arduino, or any similar board which has a USB connector, you can simply plug in the USB cable:

Screen Shot 2010 06 28 at 23.52.41

Some boards use a separate USB interface (“FTDI adapter”), allowing reuse of that interface for multiple boards:

Screen Shot 2010 06 28 at 23.54.08

The end effect is the same: a connection which powers the ATmega and allows communicating with it using a simple serial protocol. There’s also a trick in this hookup to let the PC reset the ATmega whenever it wants.

2. A common language / protocol

Ah, now it gets interesting. First thing to note is that there is no single common language / protocol!

That’s right. It all depends on what you want to do. Here we want to upload code from the PC to the ATmega. That requires exchanging “ISP commands” over the connection. But once uploading is done, we really want to reuse the connection as a regular two-way serial link.

The way it works is that the PC will reset the ATmega just before uploading new code. This activates a “boot loader” on the ATmega. Now both sides will be in sync (briefly) so they can exchange the necessary information to make an upload happen. IOW, right after reset the protocol is “ISP commands”. Once the upload is done, the connection can be reused for any protocol you like – as determined by the code that was uploaded.

3. Software on both sides of the connection

Back to the software now. We need to send ISP commands over the connection.

As you may have guessed, that’s exactly what the Arduino boot loader on the ATmega understands. When reset, the boot loader in the ATmega gets control. It waits and listens for incoming STK500 ISP commands. If none come in within a second or so, it relinquishes control to whatever was previously uploaded to the ATmega.

On the PC side, we need software which resets the ATmega and then immediately sends all the ISP commands needed to transfer and program the contents of a hex file.

This is what “avrdude” does. You can either use it implicitly from the Arduino IDE by starting an “Upload” from the menu, or you can launch it manually from the command line – avrdude needs a few options to tell it where the USB port is, what baudrate to use, the type of ATmega, the protocol to use (i.e. STK500), etc.

There’s more…

The above describes the different pieces and concepts involved in getting code into an ATmega. The beauty of it is that once it works, it really works well. Supplying power, uploading, communication, control, debugging … all with one simple USB cable. You only need to go back a few years to appreciate just how much this approach simplifies embedded development.

But there’s one important detail: the ATmega has to have a functioning boot loader. Placing a boot loader into an ATmega is a bit more complicated (and involves other things such as “fuses”). It’s a chicken-and-egg problem.

This is where the ISP programmer comes in. An ISP programmer is a fairly simple piece of hardware. In fact, you can make your own, as I’ve described in several posts on this weblog. See this and this post for some quick solutions which require nothing more than a working Arduino or JeeNode.

The good news, is that you usually don’t have to worry about installing the boot loader – it’s all done for you. Once. For the mechanism described above, you’ll never need an ISP programmer.

Some people actually prefer to use the ISP technique for uploading their sketches. In fact, sometimes you have no choice, i.e. when you need the serial port at all times, or when you can’t spare the 1..4 Kb required by the boot loader code, or when working with ATtiny chips which don’t support bootloaders.

In thoses cases, you’ll need a setup with an ISP programmer. But for most people doodling around with ATmega’s and the Arduino IDE, the above boot loader mechanism is usually very convenient and the easiest to get going.

Either way, it helps to understand the process. I hope the above was helpful in that direction.

Six lousy pins!

In Hardware on Jul 3, 2010 at 00:01

This has been a somewhat frustrating week. Just when June ended up being the biggest month ever for the shop (no doubt propelled by the special June discount), Mr. Murphy strikes again.

I’ve been waiting for several weeks now for a batch of pin headers. Had lots of them when I ordered, but since the 6-pin headers are included in just about everything, I still ended up running out sooner than expected.

This is the cuplrit – the 6-pin female port header connector:

Dsc 1764

It’s not easy to find alternatives, because I insist on having a clean 6-pin header, not some cut-off-from-a-long-strip header with very rough plastic edges on both sides.

All would have been well, if the shipment had gone its normal route. But it’s been in this country, at Schiphol Airport, for over a week now! And some lazy bum in customs seems to be sitting on it. The irony is that they do this to charge me 19% VAT – which I then get back (being a company) a few months later. More paperwork.

I’ve started shipping some packages without this item, but often even that is not an option. I can’t really send out new JeeNode kits without these headers, for example – it really wouldn’t solve anyone’s problem.

So there you go. If you’re among the several dozen people waiting for the goodies from Jee Labs to get sent to you: I’m just as eager as you to get it all resolved! – probably more, because here, all those frustrations tend to accumulate by proxy :(

Affected are: Plug Headers, JeePlug Packs, JeeNode kits, Wireless Starter Packs, and probably a few more.

(A separate issue is that the JeeNode USB won’t be back in stock for at least another week)

What can I do? Order lots and lots of them, evidently. Which is what I did (many thousands) – in the hope that this silly state of affairs won’t happen again. And offer my sincere apologies to everyone waitng.

Six lousy pins! And in two days I’ll probably be drowning in them…

Update – Just got a letter from the postal service: no invoice included. Need to supply info. By mail. So there is light at the end of the tunnel, but it’s going to take several more days. My apologies. All for some VAT, which gets refunded later. What a silly world.

Arduino, ISP, JeeNode

Fixing a faulty ATmega (Arduino)

In AVR, Hardware, Software on Jul 2, 2010 at 00:01

After a recent post on how to repair an ATmega with a faulty (or even missing) bootloader and helping someone out with it, it occurred to me that this mechanism will work for any Arduino – not just JeeNodes.

Any 3.3V or 5V Arduino’ish system which lets you upload the isp_repair.pde sketch can be used to program any board with an ISP connector on it. The code is for ATmega328′s, because that’s all I use around here these days.

The trick is to hook up a few power and I/O lines in a specific way:

Screen Shot 2010 06 28 at 16.59.11

I’m using an Arduino Pro as example, but that’s just one of many you could use. Now connect these six wires:

ISP pin 1 = BLUE = Digital pin 4
ISP pin 2 = RED = VCC (+5V)
ISP pin 3 = GREEN = Analog pin 0
ISP pin 4 = PURPLE = Analog pin 3
ISP pin 5 = ORANGE = Digital pin 7
ISP pin 6 = BLACK = GND

Note: if your working board operates at 3.3V, then you should connect the RED wire to +3.3V, not +5V (that way signal levels and power supply will match). Also: the target board should not be connected to anything, since it will be powered through the ISP connector.

The only thing left to do is to upload the isp_repair.pde sketch to your working board, and open up a console window. You should see something like this:

That’s it – disconnect all the wires. The ATmega on the target board now has a boot loader and the standard pin 13 blink sketch. Ready again to accept whatever sketch you upload to it!

JeeBot, JeeNode

TwitLEDs finale

In AVR, Hardware, Software on Jun 29, 2010 at 00:01

The TwitLEDs project by Myra and Jean-Claude Wippler (daughter and father) has come to a conclusion. It was great. I’ll just summarize by pointing to the six posts on the Jee Labs weblog describing the technical details, and some pictures and videos, showing the results.

2010-06-22 – Something different…
2010-06-23 – TwitLEDs robot, part 2
2010-06-24 – TwitLEDs robot, part 3
2010-06-25 – TwitLEDs robot – action shots
2010-06-28 – TwitLEDS robot, part 4
2010-06-29 – TwitLEDS finale (this post)

Here you can see the finished TwitLEDs robot:

Dsc 1741

This is the, ehm… print head?

Dsc 1749

And last but not least, some videos. First a trial run for the print mechanism:

Next, a trial run for the vehicle, trying to stay out of trouble:

And here the result!

And one more:

Ok, that’s it. Myra and I both had oodles of fun building this and trying things out – hope you did too :)

Onwards!

(If you can’t view the videos on vimeo, see 1, 2, 3, and 4)

TwitLEDs robot, part 4

In Hardware on Jun 28, 2010 at 00:01

Today’s episode continues the description of a little robot car which “prints” Twitter messages on a glow-in-the-dark surface.

The last missing piece was the Twitter interface. I implemented it in Tcl/Tk using JeeMon.

Here’s the setup we’re using:

Dsc 0002

The idea is to search Twitter every 30 seconds for a specific search term, and then send the message into the air using a JeeLink.

This is the main code, i.e. application.tcl:

Screen Shot 2010 06 27 at 13.02.06

It uses a custom rig (i.e. module) called twitter.tcl to do the generic part, i.e. firing off HTTP GET requests with a query, and reporting results on screen as well as calling a user-specified call-back proc:

Screen Shot 2010 06 23 at 22.58.32

Here’s an example of the output, when left running for a little while – note that only messages containing the text “design” will be picked up:

Screen Shot 2010 06 23 at 23.10.39

This implementation is a bit simplistic. It will truncate each tweet and only send out the first 60 characters (to fit into a single RF12 packet).

But hey… this is proof-of-concept, after all!

Update – the arena wall is ready. Time to try it out!

Dsc 0017

Here’s a video of the TwitLEDs robot, driving around while staying out of trouble… as you can see, it really manages to do so – mostly ;)

That almost concludes this project. Tomorrow, the last installment will be posted, with final photos and videos.

Reflow

Manual labor

In Hardware on Jun 26, 2010 at 00:01

Isn’t it gorgeous?

Dsc 1738

Yeah – a panel of 20 UART Plugs, using my little reflow grill setup. Perfect, almost no adjustments needed – just two spots which didn’t get hot enough for a shiny solder joint and one solder bridge. Trivial to fix.

Except, ehm… all the chips were soldered on the wrong way around. Yet again: when it rains, it pours!

Fortunately, it was very easy to get all the chips off (using a hot air unit) and then redo the whole thing on a new panel. But it’s a shame, most panels now work out nicely these days. And this one came out really great. Oh well.

All I need to get a handle on is yours truly… doh.

TwitLEDs robot – action shots

In AVR, Hardware, Software on Jun 25, 2010 at 00:01

As promised in the previous post, some pictures and movies of the TwitLEDs robot in action.

First another view of the robot, with the different pieces:

Dsc 1747

We don’t have the proper “arena” yet, i.e. a big fenced-off floor area covered with glow-in-the-dark paint. Instead, these first trials used two pieces of foam board, taped together. It’s not perfect because the robot keeps running off track, and because the hump between the two pieces is quite high. Foam board isn’t really suited for this: it curls up too much from the moisture in the paint. We probably should have waited a bit longer for everything to dry completely…

The inital test code just printed out its name (povGlow) and the compilation date. In the first tests, one of the LEDs wasn’t working (a software bug, not hardware), so the text isn’t quite right:

Dsc 2039

You can clearly see the fading of the letters over time. This happens very quickly, but those faded letters then remain visible for quite a while. That’s why you can still see several trial runs “printed out” on the foam board.

So the basic idea of printing with light works, as you can see!

Here is a video (sorry, not inline), showing how the robot veers to the right as I put my hand in front of it to prevent it from running off the track. Note that I’m not touching the robot, I just briefly trigger the distance sensor. The on-board LED lights up in red when the correction takes place. It’s not very smooth, but it works.

Another picture, showing the decay of the printed text brightness:

Dsc 2067

Maybe 7 pulsed blue lasers (from DVD writers, perhaps?) could be used to create even more intense blue dots. As it is, with these blue LEDs the writing is very clear – but only in a relatively dark room. With the lights on, the text becomes virtually invisible. Even though the LEDs are bright enough to be painful to look at:

Dsc 1749

The quality of this “printer” is actually pretty good, considering how simple its technology is:

Dsc 2056

Finally, a run where the robot happened to stay a bit longer on track, allowing it to display its brief message a few times. Again as video – you can see the wobbling foam board, and this thing driving like a drunken duck, leaving its trail of fading messages behind.

All that remains, is to try and get some tweets into it in real time. Stay tuned…

Several days of testing have now drained the 4 alkaline AA to the point where the robot advances noticeably slower. Looks like we’re getting no more than an hour or two out of these batteries. Which is not really surprising: the DC motors must be eating quite a bit of current, and the LEDs probably draw up to 200 milliamps or so. Self-powered autonomous motion is really hard!

TwitLEDs robot, part 3

In AVR, Hardware, Software on Jun 24, 2010 at 00:01

To continue on yesterday’s post, here is how we got a little autonomous robot going.

The main part was solved by picking the Asuro robot kit. It’s really low-end, but it has just enough functionality for this project, and at €50, it’s very affordable. In fact, Myra built a spare one because the first unit broke down. In the end, I was still able to fix it: a burnt out transistor (both H-bridges are done with discrete components!). So now we have two Asuro’s:

Dsc 1750

The nice bit about the Asuro is that it has an odometer on each wheel. IOW, there are IR LEDs + sensors to count the number of steps (8 per rev) made by the wheel, and the C library code includes logic to adjust the speed of the motor. It’s a bit crude, but because of this the Asuro can drive fairly straight. As we found out later, it has a bit more trouble doing so while driving slowly, so it’s still a bit wiggly.

But it works. Two small DC motors, some simple gears, motor axles soldered to the PCB (what a great low-cost solution), and room for an extension board. To give you an idea of how crude this thing really is: there is no on-board voltage regulator. When used with 4 alkaline AA batteries, you have to remove a jumper so the extra voltage drop over a diode gets the supply voltage down to under 5.5V …

The Asuro is full of such nifty cost-cutting tricks. It even includes a bidirectional IR link, over which new code can be uploaded. The IR link is very short-range, so it would have been insufficient for our purposes – but for quick code tweaks, the IR link works fine.

Speaking of code, here is the main avoider.c logic running on the ATmega8:

Screen Shot 2010 06 18 at 23.57.08

This is not an Arduino sketch, but I made it look a bit like one by using the same setup() and loop() functions.

This code has to be compiled with avr-gcc. The Asuro comes with several examples with Makefiles. I simply copied one and started extending it. A little optional USB-IR adapter is used to connect to the Asuro (an RS232 one is included with the Asuro kit, but I don’t have any RS232 ports). The whole setup works pretty well from the command line, especially considering that it’s a completely different setup than the Arduino IDE.

Anyway, back to the design of the TwitLEDs robot.

The challenge was to find a simple way to make this robot drive around without bumping into things. The Asuro has a row of switches at the front, but these are not very reliable, and besides: bumping and stopping and turning would mess up the LED strip being “printed” on the glow-in-the-dark paint.

So instead, we mounted a Sharp 10..80 cm distance sensor on top. It’s very easy to read out, since it produces an analog voltage, inversely related to the distance of objects in front of it.

The logic for collision avoidance is crude, but sufficiently effective: turn more and more right as you get nearer to an obstacle. The on-board LED turns from off to green to yellow to red as the distance decreases, so it’s easy to see what the robot is doing. I’ve tweaked it so that when it drives straight towards an obstacle, then turning will be quick enough to never bump into that obstacle.

Here’s the completed unit, with the Sharp proximity sensor on a little expansion board at the front, and the LED blinker glued to the side of the battery pack – the LEDs hover 1 .. 2 mm above the ground:

Dsc 1741

Myra’s idea was to have this thing drive inside a more or less circular “fence” made of corrugated cardboard. The whole area inside the fence will be made of some panels, covered with 3 layers of glow-in-the-dark paint.

There is a flaw in the current design, in that the robot can only evade an obstacle by turning to the right. If it approaches a wall obliquely from the right, it will do the wrong thing and drive straight into the wall. But we’re hoping that as long as it doesn’t over-correct, and by sending it off in a tangent, it will keep adjusting slightly to the right as it drives around and around in “sort of” circles.

More tests and tweaks will no doubt be needed.

But as it is, this thing really seems to stay out of trouble. We can let it loose in the room and it’ll veer to the right whenever it comes near an obstacle. Sometimes it veers to far, though. Again, I hope a more controlled “arena” will be sufficiently simple to keep it going.

When the robot does bump into its front switches, it turns both motors off, blinks for 10 seconds, and then starts off again. Time enough to pick it up and aim it in a different direction.

So that’s it. An autonomous unit with two independent computers, IR distance sensing, a short range IR link, and the JeeNode with a longer-range wireless RF link. Even including a JeeLink on the laptop side, the cost of all this was only slightly over €100.

Tomorrow, some pictures + movies. Gives me time to finish the Twitter link, and then on to the grand finale!

(Reminder: one week left for the June special in the Jee Labs shop!)

TwitLEDs robot, part 2

In AVR, Hardware, Software on Jun 23, 2010 at 00:01

Yesterday’s post introduced the robot Myra and I have been working on. Here’s the first part we built:

Dsc 1725

It’s basically a backplane for the LED blinker component. Or to put it differently: a simple persistence-of-vision (POV) unit, using a JeeNode, and Output Plug to drive a few LEDs. Only the output plug was soldered-in permanently. The removable JeeNode allows it to be easily programmed and re-used, and the removable LEDs allow trying out different units. This turned out to be important, because I only had a few green LEDs when starting this, and had no idea then as to what sort of LEDs would give the best POV results later on.

Myra did all the soldering. Here are the two LED mounts we ended up with:

Dsc 1745

The one on the left is the super-duper LED concoction we built as final version. The one on the right was great for initial testing.

Everything is held together with rubber bands, zip-lock ties, tape, and ample amounts of hot glue (once verified to work!) – hacking at its best, clearly:

Dsc 1742

Here’s the LED blinker with the final LED strip, side view:

Dsc 1743

Side view close-up – with the foam board cover:

Dsc 1746

Bottom view:

Dsc 1744

Seven blue LEDs, ready to shine very brightly and controlled by the JeeNode.

The software started out very simple, of course. Things like this, just to make sure it all works:

Screen Shot 2010 06 18 at 23.01.21

This is the main part of what is more or less the final twitLEDs.pde sketch:

Screen Shot 2010 06 18 at 23.03.06

I found a suitable font table by googling around a bit. This is needed to go from ASCII characters to dots-in-a-readable-pattern. No room for Unicode (don’t laugh: some tweets are in Japanese and Chinese, and they won’t show properly).

The amazing bit is that everything worked essentially on first go. It blinked! But does it blink in the proper pattern? Our first test consisted of Myra taking a long-exposure shot, as I waved this thing around in the air – with the lights off. Liesbeth tracked progress through all the shrieks and laughs… but from a safe distance :)

Dsc 1793

Yippie. It really works!

Tomorrow: driving around without bumping into things.

Something different…

In AVR, Hardware, Software on Jun 22, 2010 at 00:01

Ok, so I’ve got tons of projects on my plate to do and to finish. And tons more that are still very experimental, or haven’t even been started. Plenty to keep me busy, with the summer vacation period nearing fast.

Yet here’s something different. The timeline for this project was imposed by external factors: my daughter Myra doing a project for the last quarter of her second year at the Design Academy in Eindhoven.

She wanted to do something which triggers human interaction, and she wanted to try something with Physical Computing. “Terrific, I’ll help!” – I shouted, completely ignoring all the pending work on my own plate…

So here’s the start of a few articles about the “TwitLEDs” project we’ve been working on recently. All the basic ingredients work as I write this, but we have yet to finish the final setup and go through a last rehearsal.

What is it?

It’s a mix between a matrix printer and a persistence-of-vision (POV) display.
It’s called the TwitLEDs robot. And it’s hooked up to the internet.

Get it? No? Ok, then let me try again. I think this picture tells it best:

Dsc 2069

The idea is to have a little autonomous robot driving around, leaving messages behind on a floor covered with glow-in-the-dark paint. The messages are collected off Twitter using a configurable search term. This is done from a laptop and then sent to the robot by wireless.

There were several fairly non-trivial problems to solve here, with some experimentation needed to find a workable mix – as well as some time contraints. A few days of work would be the most I could set aside for this. Luckily, I didn’t get lost in too many dead alleys, so it worked out nicely.

Here are the pieces we used:

A low-cost robot kit called Asuro – based on an ATmega8, so I had all the software ready for it. In fact, I played around a bit with it a while back – as reported here.
A JeeNode for wireless connectivity.
An Output Plug to drive some LEDs.
Seven blue LEDs. I picked a bright one with a very focused beam (C503B-BAN-CY0C0461).
Glow-in-the-dark paint. Green stuff. Three coatings.
Some panels to create a floor. Covered with the green stuff.
Some cardboard to create an “arena” on the floor to contain the robot.
JeeMon running on a MacBook, with a JeeLink to send out the messages.
A fairly dark room. This just won’t work with the lights on, unfortunately.

As with every project, the first part is the hardest and the most critical success-factor: figuring out what to do, what not to do, and finding solutions within the many constraints we had to operate under. I’ll spare you the ideas that didn’t make it, and the (really neat) ideas we simply didn’t have time for.

Being the sole programmer on the team, I got to deal with all the software. Yummie! :)

The most important insight for me was that we could implement this project with three completely independent subsystems:

The LED blinker, driving 7 LEDs in the proper pattern, basically a POV unit (plus receiver).
The robot, moving around while continuously trying to stay out of trouble.
The server process running on the laptop, connecting to Twitter and sending messages into the air.

We started off with the LED blinker because it was a major component with few unknowns, i.e. we picked the low-hanging fruit first. Here’s a picture of it, still under construction:

Dsc 1726

More on the LED blinker tomorrow…

JeeNode, LowPower, Sensors

Battery savings for the Pressure Plug

In AVR, Hardware, Software on Jun 20, 2010 at 00:01

Reducing power consumption is fairly tricky, as you can see in the many previous posts about this topic. And to be honest, I haven’t quite gotten to the point where I want to be with the Room Board. My first “major” (ahem) setup with about a dozen nodes around the house didn’t quite go as I had hoped. Most batteries were empty within a month. A few nodes are still going, but those are hooked up to power adapters…

I’d like to revisit this issue and try to improve things a bit. To make the rooms sketch perform better, and also to make the code structure a bit clearer. The current rooms code is quite complex and hard to follow.

But before messing with the rooms.pde sketch, let’s tackle something simpler: the wireless sensor node based on the Pressure Plug, as described here, and then simplified here. I’ll use that last version as starting point.

The first point to note is that to get a substantial first power reduction, you have to focus on the portion of the code where it’s spending most of the time. Which, in the case of “bmp085demo”, is here:

Screen Shot 2010 06 17 at 01.55.06

That’s right: it’s waiting for the next second to “happen”. And even with a slow’ish sensor such as the BMP085 at maximum resolution, it’s spending more than 90% of its time there… waiting!

I’ll use an approach which might be a bit surprising: let’s not change any of the current logic. The idea is that once we’ve done our thing for the current second, we can go into low power mode, as long as we make sure to get back to normal operating conditions in time for the next second.

So what we’re going to do is add some code to the end of the loop() function. It’s functionally equivalent to adding it at the start, since loop(), eh, loops – but I think it makes a better point.

The end of loop() used to look as follows:

Screen Shot 2010 06 17 at 02.01.01

I’m changing it to this:

Screen Shot 2010 06 17 at 01.43.00

IOW, at this stage all the hard work has been done. We wait a bit for all interrupt-driven I/O to complete (serial and RF12). And then we need to figure out how much time remains until the next second. The power saving happens by spending that time in power off mode.

But this requires some preparation. When inducing a comatose state like this, you have to make absolutely sure that something is still able to get you out of coma and back up and running again. This is what the ATmega’s “watchdog” is for: we set it up to wake us up in 16 milliseconds, just before entering sleep mode. And then we keep doing that until it’s almost time to take another reading. The actual watchdog interrupt handler does nothing, btw – all we want is to get back out of power down.

Note that the radio also needs to be turned off and back on again. It’s the biggest power consumer when enabled. Turning it off and going into power down mode is what lets us go from a tens-of-milliamps current drain to a tens-of-microamps current drain.

All the logic for this is located in the loseSomeTime() function, which was adapted from a slightly different version in the rooms.pde sketch:

Screen Shot 2010 06 17 at 01.42.33

And that’s about it. The average power consumption of this sensor node will go down by an order of magnitude. It’ll still be 1..2 mA, but it’s a major improvement: this node should now run 2..3 months on AA batteries. The source code for bmp085demo.pde has been updated.

I’d like to stress that such gains require very little effort for many types of sketches. All you have to do is figure out where the sketch is spending most of its time, and deal with just that part of the code. Getting into yet lower power consumption levels would require more work.

Input Plug, oh my

In Hardware, Software on Jun 19, 2010 at 00:01

More fallout from the bad ISP programmer. As reported on the forum, there is a problem with the Input Plug. Fortunately, it’s fixable in software.

The problem is that the ISP programming of the ATTiny45 chip on the Input Plug had the same problem as the recent, ehm, Murphy debácle: the fuses weren’t always set properly.

So the ATTiny starts up running at 1 MHz i.s.o. 8. And hence the timing is off when driving pulses to it to control the analog multiplexer.

The solution was to add a “fix” parameter to the InputPlug class in the Ports library. It defaults to 0 (no fix needed), but when set to non-zero, the timing is adjusted to slow down by a factor 8. That way, channel selection will take a bit longer – but at least it’ll work:

InputPlug myPlug (3, 1); // plug on port 3, slow down for wrong ATTiny fuse

This code has been added to the Ports library. There is a downside: the fix means that channel slection now takes roughly 900 µs, instead of the intended 100 µs.

Next question is: how to make sure this won’t happen again? – Answer: build a test jig, so all plugs can be tested fully before shipping. Trouble is, all Input Plugs ship as follows (this is an early hand-soldered unit):

Dsc 1732

Without headers!

My mistake was of course that I would wing it, and avoid the testing. Bzzzt. Time to build a little test contraption:

Dsc 1733

The other side is filled with 17 tiny 1 kΩ SMD resistors, creating a voltage divider with 16 different voltage levels. Soldering this was quite a challenge, btw:

Dsc 1737

And now I can take advantage of the fact that everything is gold-plated. So the following will make contact, just with the pins being pushed in and pressing lightly against the board:

Dsc 1735

I’ve been using the same trick for some time now, to test other plugs. Here’s how to connect the whole thing to one of the ports:

Dsc 1736

Below is a little readout test – a better test setup would be to simply perform the check and display a go / no go signal, but for now I’m just reporting the 16 values:

Screen Shot 2010 06 16 at 19.00.21

Sample output:

Screen Shot 2010 06 16 at 20.24.30

As you can see, the selection is now working reliably (once connected).

So that proves the bug and gives me a new tool to test Input Plugs before shipping. And of course I’ll re-flash the ATtiny45 chips on all remaining Input Plugs in stock at Jee Labs. For those already out there: you can either use the software fix, or send your Input Plug(s) back to me and I’ll fix the fuse settings to make selection snappier, as originally intended.

Problem solved. Phew.

Does it feel good to have to confess to another goof-up on my end? Of course not. But worse than that would be to keep quiet on this – and I won’t. I’m human, I make humiliating mistakes (LOTS!), I occasionally cut corners, but I do my best to learn and deal with it all. There is no doubt whatsoever in my mind that every person and company goes through these sorts of mishaps. It’s just usually not out in the open for everyone to see. Well, at Jee Labs, it doesn’t work that way – this is open source: software, hardware, goofs … e v e r y t h i n g !

▶ View 7 Comments

Home automation

Mac Mini as home server

In Hardware on Jun 18, 2010 at 00:01

Whoa, great news – the Mac Mini is getting even more energy efficient:

Screen Shot 2010 06 15 at 12.41.01

It was announced today. Here’s what the new box looks like (and no more power brick!):

Screen Shot 2010 06 15 at 12.41.20

We’ve been using the Mac Mini as our TV + audio system for several years now. It’s connected to a master/slave power switch to switch off the other components when in sleep mode (sat tuner and amplifier). Works great, although I had to replace the hard disk recently. The new one would be a great successor… one day.

Might also be an excellent option for a home server, although a SheevaPlug or GuruPlug uses even less power in idle mode (approx. 4 vs 10 Watt). But that’s more of a software decision really: Mac OS X vs. Linux.

Home automation, JeeNode, JeePlug

RGB via the Dimmer Plug

In Hardware on Jun 17, 2010 at 00:01

As someone pointed out in the comments a few days ago (see? that’s what weblog comments are for!), there’s Jee Labs’ own Dimmer Plug to unload the ATmega of all PWM duties:

Dsc 1729

Hm, I really forgot all about that one… doh.

It’s a great suggestion, of course. And fortunately, it can easily be swapped into the RGB strip controller series. All I need is a slightly different JeePlug to tie things together:

Dsc 1730

The result has a 2×3 pin header which matches the one on my previous interface, so now it’s just a matter of swapping cables.

And new software, of course. Here’s a test sketch which cycles brightness and colors similar to the first test sketch:

Screen Shot 2010 06 15 at 18.42.36

Except that this no longer requires any processor attention once set. And there are a few extras: it’ll work with up to four independent sets of RGBW LED strips, and it has a “global” brightness control (currently set to max), making it easy to set up the color once, and then dim the whole shebang while keeping that setting.

Also – because it’s hardware now – the PWM happens much faster. I can’t tell the difference, but I have this hunch that our cat probably can. There’s got to be a difference between blinking at 120 Hz and 100 KHz!

I’m not sure yet which approach I’ll keep. Both software and hardware PWM work fine. Decisions, decisions…

Home automation, JeeNode

RGB driver board

In Hardware, Software on Jun 14, 2010 at 00:01

To follow up on yesterday’s post, I made a more permanent 4-channel board for driving an RGB LED strip plus the original white LED strip already in use.

A JeeNode is used to drive these strips, using a small custom JeePlug to hook up ports 1 and 4, as well as to use the LED voltage as power source for the JeeNode:

Dsc 1717

Here is the plug in more detail:

Dsc 1718

It includes an LP2950 linear regulator to put 5V on the PWR pin, that way this thing can be used with any input voltage from 12 to 24V. Here is the bottom side:

Dsc 1719

The driver itself uses four IRLZ34N MOSFETs, three of which will be used for the RGB strip, and the other for the white strip so that it too can be controlled and even dimmed remotely:

Dsc 1715

The back side is hand-wired using sturdy copper wire, although in this case only 300 .. 600 mA is being switched per color. The 10 kΩ pull-down resistors prevent the lights from turning on in the absence of control signals.

Dsc 1716

And here’s the completed setup:

Dsc 1714

The two wires sticking out are for attaching my 12V lab power supply during testing. The other green 2-pin screw terminal is for attaching the white LED strip.

The RGB ledstrips can now be installed next to the LED strips already in use here at Jee Labs:

Dsc 1722

Here’s a trivial test sketch to turn each of the 4 colors on and off:

Screen Shot 2010 06 11 at 13.17.35

The results can be seen in this brief video.

What remains, is to write the software so this thing can be controlled via wireless. I might add an LDR to sense ambient light levels, or even a Room Board. Perhaps some basic ramp-up / ramp-down PWM logic. Or maybe I’ll just duplicate this setup and drive the two sets of LED strips I have, independently and from a single JeeNode.

Hardware is easy, it’s always the software… the code will be presented tomorrow!

Reminders: 1) June discount and 2) Jee Labs will be closed from July 14th to August 14th.

Home automation, JeeNode

Driving an RGB strip with MOSFETs

In Hardware, Software on Jun 13, 2010 at 00:01

Another day, another project started. I have a nice 5-meter LED strip in the office, which provides indirect lighting at Jee Labs. Works fine, but despite being called “warm white”, it’s slightly greenish. Not so great…

Someone suggested adding an RGB strip next to it, to compensate for the color.

So to start off this multi-part series, I wanted to simply control RGB. This is very easy to do with three MOSFETs. I used IRLZ34N’s N-channel, since the LED strips are common anode. The circuit is trivial: source to ground, drain to LED cathode, and gate to an I/O pin. Rinse and repeat three times. I didn’t even add a pull-down resistor to the gate, though I probably should.

Here’s the circuit, fully connected to a test strip with 9 RGB LEDs using a separate 12V power supply:

Dsc 1664

I wrote a little test sketch which ramps the light levels up and down using PWM, and which goes through all the RGB combinations – using some bit fiddling:

Screen Shot 2010 06 07 at 13.17.10

The LEDs are pulsed in software, with a cycle time of 8160 µsec (32 * 255), i.e. roughly 120 Hz. No discernible flickering. A more advanced version ought to use interrupts to keep the PWM going in the background.

Here’s a video of the result – with apologies for the very low quality.

Since the JeeNode has RF on board, it will only be a small step to add wireless control. Stay tuned…

Update – Source and drain were listed the wrong way around, I’ve updated the text above.

▶ View 10 Comments

IR trigger for Nikon camera

In AVR, Hardware, Software on Jun 12, 2010 at 00:01

Here’s a fun project: sending out infrared remote codes to takes snapshots :)

This is the code:

Screen Shot 2010 06 10 at 17.19.44

This sketch is doing everything in software, and it’s sort of pushing the limits by pulsing a TSKS5400S IR emitter LED at 38.4 KHz using software delay loops.

The timing diagram on this website was a great help to get this working in no time. Here’s another site.

With the 33 Ω resistor in series, total current through the IR LED should be somewhere between 20 and 50 mA. Since the latter is beyond the ATmega’s current sourcing capapbility, I suspect that the pin voltage will actually drop quite a bit below VCC. A transistor or MOSFET could be added for more power. As it is, this seems to trigger reliably up to about a meter away.

Here’s the setup, triggering my trusty D40 Nikon:

Dsc 1692

… a self-portrait!

Lot’s of people have already done this ages ago, btw. Here’s a sketch which uses assembler to get the timing more accurate. But the above does work – the main point is to avoid digitalWrite(), which is relatively slow.

ISP, JeeNode, Techniques

A Happy Ending!

In AVR, Hardware, Software on Jun 10, 2010 at 00:01

The multi-ISP programmer I built and started using some two weeks ago, turned out to be quite a nightmare. Not only were incorrectly programmed ATmegas sent out to about two dozen people, I also had to go through about 70 kits, prepared as new stock just days after I started using this programmer. Twice!

Yes, twice. Because the first “fix” turned out to be insufficient. Doh.

This was a clear case of one bug hiding another, and another, and another. Yep, four bugs: a bug in the MemoryStream class in the Ports library, a timing problem exposed by fixing that bug, and two incorrect assumptions about how the “avrdude” utility works. I’ve now got an explanation for everything that went wrong.

There’s no doubt some interesting psychology at work here … I was so proud of my idea op programming multiple ATmega’s! The main idea was to create an AVRISP-compatible unit which stores everything sent through it and then just replays the saved stream as often as needed. Trouble is, I jumped to conclusions the minute a first “run” worked. Roll the presses! Print it! Tell it to the world!

Anyway. There is a happy ending to all this!

The latest version of the isp_capture.pde sketch in the Ports library has been working properly for over a week now, programming well over a hundred ATmega’s (and it now does auto shut-down a few minutes after use):

Isp Capture Output

The last bug was a very puzzling one: everything worked, but sometimes the fuses wouldn’t get programmed. It turns out that avrdude first reads the fuses, and only sends out commands to program them if the fuses don’t match the new value. Since the programmer needs to work with brand-new as well as previously-programmed chips, the replay mechanism would have depended on the prior state of the chips: not good.

The solution is very simple: I now always program each fuse twice, with two different (valid) values. The second one will remain in force, evidently. Since the replay code was already ignoring fuse mismatch checks, this now means that even if the first setting is skipped by avrdude, the second will always be emitted.

Here is the shell script to prepare the Flash Boards:

Screen Shot 2010 05 30 at 01.35.40

So this has now become a very useful tool at Jee Labs:

Dsc 1432

I love the on-board LiPo battery: I can grab it, use it where I need it, and put it back – no wires = freedom!

For pre-loading the fuses, boot loader, and RF12demo, it already saved me a huge amount of time. Its “burn rate” is up to 500 chips/hour. And Mr. Murphy taught me some valuable lessons along the way…

And now it’s time to move on!

Repairing a faulty ATmega

In AVR, Hardware, Software on Jun 9, 2010 at 00:01

This post is being written after a pretty nasty foul-up on my part w.r.t. sending out badly-flashed ATmega chips. It’s probably too late to be of use to anyone involved in that little débâcle, but I thought I’d describe a DIY fix here in full detail anyway. I’ve simplified the code to make it even easier to use than what was described here.

So what is this about, eh?

The ATmega328 chip used in JeeNodes (and Arduino’s, and various other similar board) comes with a serial boot loader pre-loaded into the high end of its flash memory. This is arguably one the most important features that made the Arduino popular: it lets you upload a new “sketch” into the ATmega over the serial or USB port.

Lots of little details, but the point here is that the boot loader itself can’t easily be damaged, even if you load a non-functional sketch into the ATmega. Just resetting it will let the boot loader overwrite the flash memory with a new version – hopefully a better one. Basically, no matter what goes wrong, there’s always the boot loader in the ATmega to upload a new sketch to it.

There’s a chicken-and-egg problem, though: how do you get that boot loader into the ATmega in the first place? Well … you don’t. It’s normally placed there by the supplier of your ATmegas.

Since Jee Labs is one of the suppliers of JeeNodes (for Europe, and Modern Device for the US), I do need to do a little more. I use an “ISP” programmer to place that boot loader there, along with the RF12demo sketch.

But there’s really not much to all this, and this whole boot loader / ISP stuff can easily be performed by anyone. Keep in mind that’s it’s just about getting that first step right: proper fuses and the boot loader stored in flash memory. Nothing more.

All you need is a working unit and a second target unit with the ATmega that needs to be repaired (or initialized for the first time – same thing). For Arduino’s, it’s all explained at http://arduino.cc/en/Tutorial/ArduinoISP.

As it so happens, there’s now even simpler software to do this, so I’m going to describe the process in terms of using one (working) JeeNode to repair another JeeNode (note that this still should work for Arduino’s as well).

The basic idea is still the same: we need to connect 6 wires. There are 2 wires for +3V and GND and 4 wires connected to ports 1 and 4. On the target JeeNode, the wires will be connected to the ISP connector:

Screen Shot 2010 05 29 at 01.37.23

The target JeeNode will receive its power from the working JeeNode, so don’t plug it into anything. Note that this can also be done with JeeNode USBs. All we need, is to make a few connections for power and I/O.

The working JeeNode should be plugged into a USB-BUB, or something similar. Do that now, because the following wiring step can be a bit sensitive to movement.

The following six connections need to be made:

Screen Shot 2010 05 29 at 02.57.58

On the working unit, the wires or wire jumpers can be inserted into the 6-pin port headers.

On the target side, you’ll probably just have gold-plated holes for the ISP connector. The nice thing about gold plating is that it easily makes contact. So one way to hook up the wires is to insert all six as shown above, and position the whole thing in such a way that there is a slight tension on the wires – just enough to make contact.

Ok, you should now have the working unit powered up, and the target unit receiving power and signals through these 6 wires. Good, leave them alone now.

To do the actual reflashing, I’ve added an isp_repair.pde sketch to the Ports library, which does everything. Upload that sketch to the working JeeNode, and open up the console. Here’s what you should see:

Screen Shot 2010 05 29 at 02.24.05

That’s it. The target ATmega has been set up with the proper fuse settings and a boot loader. You can remove all the wires, and hook up the JeeNode to a USB-BUB. It’ll now accept sketches like any other JeeNode. Fixed!

▶ View 10 Comments

SMD hand-soldering tools

In Hardware on Jun 8, 2010 at 00:01

I’ve been hand-soldering SMD for some time now. The reflow approach is better suited for batches and recurring work, but sometimes I don’t have solder paste stencils, and sometimes I just need to do one-off builds.

There are tons of instructions on the web. Seach for “curious inventor smd” for example, for some great videos.

First thing to note is that it’s not as hard as it seems. Soldering SMDs by hand is still just that: soldering. The only thing you have to take care of, IMO, is alignment. Once a component is soldered on in two or more places, it’s virtually impossible to adjust it. And pushing too hard, or heating far too long, just gives you lifted solder pads and broken traces, because SMD pads are not as robust as a plated-through hole. Once that little piece of copper comes off the board, you’re hosed…

Ok, here are the tools I use:

a soldering iron
tweezers
a flux pen
solder wick
solder
magnifying lamp

That’s it. I hardly ever use my hot-air soldering station. I don’t have a de-soldering unit (a soldering iron with a hole in it and air suction, basically). For lots of SMD-by-hand work, you don’t need ‘em. Although for serious “rework”, you probably do.

Here’s the “Ersa i-CON nano” soldering station I’ve been using for a month or so now:

Dsc 1515

The iron is excellent. Small, and due to its construction it’s also incredible cool (yeah, in both senses):

Dsc 1516

The tip is held on with a spring. It’s clever, because that knob shields even more of the heat, and the tip sits around the heat core, absorbing every bit of heat instead of radiating it out:

Dsc 1517

The warm-up speed of this thing is incredible, it’s ready for use in under 10 seconds. The unit will fall back to 240°C when not used for a few minutes, and drops all the way back to about 45°C when left unused yet longer. It’s configurable, but in an odd way: a Windows program can write a file to a µSD card, which you then insert into the base. It’ll pick up the settings, and use them from then on. I’ve configured the presets as 280°, 320°, and 360°, respectively. For manual work (with leaded solder) I usually set it to 320°. For work on reflowed boards (using unleaded solder), I use the 360° setting.

Should have bought this ages ago. I use the smallest tip available, which is a 0.4 mm round tip. It’s slightly too pointed IMO, so the solder tends to move away from the tip due to adhesive forces. But it works well, and the heat really gets all the way to the tip. On the handle, I hardly feel any heat. I check the display to see if it’s on.

The holder is also clever. It’s some sort of shaped rubber, I think. Heavy, so it won’t slide away, nor get damaged from touching it with the iron, and the way it is shaped means that at rest the handle will cool down all the way back to room temperature.

It’s not cheap (Conrad #588374), but to me it’s worth every penny. Having said that, there are no doubt other units at a fraction of the price which should also work really well. What I’d look for: pencil-like, regulated, and no more than 40 to 60 Watt. I fell for the instant startup, the configurability, and the auto switch-off.

Here’s my previous 15 Watt Weller soldering iron, a few decades old by now (tip replaced only once, I think):

Dsc 1518

Also really nice, but slightly underpowered (ground pins and ground planes are a bit tricky, as are thick copper wires). Another difference is the lenght of the tip – I really like the Ersa’s short pencil-like dimensions.

My daughter still prefers the Weller btw, so we’re both happy now :)

Here are the other tools I use:

Dsc 1519

Not much to say about this, other than that you really should get tweezers wich were designed for this work. They become an extension of your hand. They let you pick up grains of sand, even blind-folded. Well, almost. They may not look like much, but use them gently or you’ll bend them and bring the two opposite sides out of alignment – rendering them useless. Can’t remember where I got these – DigiKey and Farnell have ‘em too.

The flux pen is essential for SMD work: apply flux, place component, then solder. When fixing things, I often apply flux again. The enemies are corroded solder and corroded pads – flux takes care of both. This is Farnell #876732.

The wick is equally essential. It took me a while to learn an important lesson: shorted pins are no big deal. Just wick the solder away and everything will be fine again. Can’t get the solder off? Just add more solder first, and then use the solder wick. Snip off each piece after use, as solder wick can only be used once. The type I use is not great – it leaves an ugly brown flux residue.

And last but not least, get a magnifying glass with built in circular lighting:

Dsc 1521

Actually, my daughter prefers broad daylight and nothing between her eyes and her work. To which I can only say: 1) yeah, but she’s 21! and 2) I’m a night owl … starlight + moonlight don’t seem to cut it for me! :)

I think I got that lamp from Conrad, but I can’t find it anymore. It was under € 15, ten times cheaper than another lamp I got with a long arm. The short arm is inconvenient, but it’s more solid. The big benefit of this 3x magnifier is that it has a built in 10x close-up section. Great for very close inspection. The one drawback of this small light is that you can’t look through with both eyes, so you don’t get stereoscopic vision with better depth clues. The cover is useless, btw. I haven’t needed a microscope yet, although there are limits to what you can see with this thing.

Anyway, that’s what I’m using. The rest is patience. And practice.

Arduino, Network

EtheRBBBreadboard

In AVR, Hardware, Software on Jun 7, 2010 at 00:01

Please excuse the crazy title. This picture probably tells you more:

Dsc 1509

You’re looking at an RBBB from Modern Device, hooked up to the Ether Card from Jee Labs. The hookup is trivial, it need 6 wires: 2 for power and 4 for SPI:

Screen Shot 2010 05 29 at 04.18.26

And that’s all you need to create a webserver!

Here’s a sample screen (yep, it’s been running for almost 12 hours):

Screen Shot 2010 05 29 at 00.03.48

And here’s the code for it:

Screen Shot 2010 05 28 at 12.05.03

It presents a self-refreshing page with the “uptime”, i.e. how long the server has been running since power-up.

The code is available as “rbbb_server.pde” example sketch in the EtherCard library and is a simplified adaptation of the etherNode sketch, omitting the RF12 driver and calls, of course. It compiles to 6 Kb of code.

As with the etherNode sketch, the MAC address and IP address have to be set to suitable values in the source code before uploading it to the RBBB.

BTW… did you notice anything?

The RBBB is running at 5V. And it works. Because the Ether Card is compatible with 3.3V and 5V signals!

Which also means that the Ether Card can be used with any Arduino board. It’s not specific to JeeNodes and it’s not limited to being used with the Carrier Board, either.

The generic software for the Ether Card is contained in the “EtherCard” library, listed on the software page in the Café. It doesn’t depend on Ports or RF12 libraries, so this thing really is a completely independent product.

It just “happens” to fit gorgeously into a box alongside a JeeNode :)

So there you have it – the Ether Card can be used with just about any microcontroller setup. All it needs is a power supply of 3.6V or more, 4 SPI I/O pins, and the proper software to make it sing of course…

Onwards!

▶ View 7 Comments

LCD display voltages

In Hardware on Jun 4, 2010 at 00:01

As of this month, the 2×16 character LCDs from Jee Labs are 100% suitable for 3.3V use. The previous batch was made for 5V, although the backlight can always be used at a lower voltage: it’s just a few LEDs with a current-limiting resistor after all.

But the logic level officially had to be 5V. Then again, in practice, I’ve used those LCDs with a LiPo battery without any noticeable problems.

The new LCD units are specifically for 3.3V, so both voltage jumpers on the LCD Plug should be set to +3V.

To see which unit you’re using, look on the back. These are the new 3.3V units:

Dsc 1522

Note the “33V33″ suffix.

I suspect that the difference is only in a few on-board resistors. I haven’t tried running these new LCDs at 5V logic levels – they may not be up to it.

But for LiPo and 3x AA battery use, the new units will be perfect.

IC socket ≠ IC socket

In Hardware on Jun 3, 2010 at 00:01

Ok, so the JeeNode v4 kit is fine, judging from how many people have ordered them and built them. Cool, that was the whole point – a small Arduino-compatible kit with RF on board that’s easy to build and use.

As was to be expected, I ran out of IC sockets the other day. So I ordered new ones. Except, I picked a different supplier (DigiKey i.s.o. Farnell), because I thought it would simplify my life to obtain everything from as few sources as possible. Silly me…

Here’s what I got, 500 times:

Dsc 1500

Guess where it doesn’t fit?

Dsc 1503

The bent pins won’t fit through the JeeNode v4 PCB, where I used smaller holes to simplify soldering. Grrr…

There’s a solution, but it requires a bit of extra work. Take a set of flat beak pliers and flatten the pins, sort of:

Dsc 1501

Now it will fit, with a bit of juggling, while being careful not to bend any pins:

Dsc 1502

Problem solved. But I’ve learned another lesson: when things work, don’t change … A N Y T H I N G !

FWIW, I only found out about this problem after a handful of JeeNode kits had been sent out with these bent-pin IC sockets. I immediately ordered more suitable ones, which arrived the next day, and switched over to resolve the problem.

(Luckily, these IC sockets fit just fine on the Ether Card, so all it not lost…)

Mystery boxes

In Hardware on Jun 2, 2010 at 00:01

Ok, here’s a puzzle for you. A project with two boxes, but what are they for?

The first box is truly a “black box” – no connections at all, no display, no button, nothing:

Dsc 1495

Not much to see on the inside either:

Dsc 1494

The second box has a 5-way button and an LCD display:

Dsc 1497

There’s a USB connector on the bottom right, but it’s only used for charging and debugging.

There’s a bit more electronics inside this one:

Dsc 1496

Still a few wires missing, because I haven’t hooked everything up yet.

So there you have it. Both boxes are self-contained, but the project I’ll be using them for needs both. I’ll reveal the project once I’ve got the basic software going – it’s always the code that takes the most time to develop!

▶ View 18 Comments

JeeNode, Network

Assembling the Ether Card

In Hardware on May 30, 2010 at 00:01

(This is going to be a long post, so I’ve split it up a bit)

Here are the steps needed to assemble the Ether Card kit, starting from this PCB:

Dsc 1433

This board is very easy to build, since it uses only through-hole parts and has relatively few components. The basic idea is to build from the flattest to the highest components. That way, when you turn the card over for soldering, you can push on it to press the component against the board.

So let’s start with the 7 resistors. Don’t mix them up, they have three different color-coded values:

Dsc 1435

Turn over the board, don’t use too much solder, make clean solder joints, and snip the wires off when done:

Dsc 1436

The important thing is to get the solder flowing into the plated-through holes.

Next, the ferrite bead (a small inductor which blocks high frequencies):

Dsc 1439

More…

Using LiPo batteries

In Hardware on May 29, 2010 at 00:01

The latest revision of the JeeNode USB includes a LiPo battery charge circuit:

Screen Shot 2010 05 22 at 13.45.15

The “+5V” pin is the incoming pwoer from the USB bus, it goes directly to the MAX1555 LiPo charger. From there, the PWR line is fed, so this will normally be at 4.2V when no battery is attached. That PWR voltage in turn is fed to the on-board 3.3V regulator for the ATmega and RFM12B.

This design was chosen because it lets you very easily add a LiPo battery: simply attach it between PWR and GND. There are no switches or switch-over issues: plug-in to charge, then use unplugged as needed.

I’m going to use the Carrier Board as example, and I’m going to use a LiPo battery from SparkFun, which comes with a polarized JST plug already attached. Here is the matching socket:

Dsc 1486

What we need is a spot where this socket can be soldered on. Ah, here it is, on the PWR/SER/I2C connector:

Dsc 1487

The trouble is that the pins are not 0.1″ apart as needed here, and that the socket won’t be usable if mounted sideways. So I cut off the plastic tabs and bent the wires a bit differently (taking care not to bend too much, because they break very easily):

Dsc 1484

The result fits perfectly on the Carrier Board, with the whole setup in turn fitting very nicely in the ABS box:

Dsc 1485

I’m using an 850 mAh LiPo cell.

One point to note is that the charge current from the MAX1555 is fixed at 280 mA. The rule for LiPo battery is to charge them at no more than 1C, i.e. a 850 mAh cell shouldn’t be charged with more than 850 mA. So in this case, we’re fine, with an estimated charge time of 3..4 hours for a fully discharged battery.

IOW, don’t use this setup with LiPo batteries smaller than 300 mAh or so.

Another thing to avoid with LiPo batteries is to discharge them below about 3V. You can check rf12_lowBat() from the RF12 library once in a while. It reports when the voltage at the RFM12B drops below 3.1V, i.e. around 3.2 .. 3.3V on the LiPo. Once this happens, power down the ATmega + radio to avoid draining the battery any further.

Why all the fuss? Because LiPo batteries can burn and explode, when improperly handled. There’s a lot of energy in there, and at some point things can exceed the design limits. Search for “lipo explode” on YouTube…

There are really only two issues: 1) the short-circuit discharge current can be extremely high (20C, i.e. 17 Amps with the above unit!), so short circuits and polarity reversals must be avoided at all times. And 2), charging should be done with the proper circuitry, such as the one in the JeeNode USB.

Why use LiPo’s? Well, they are very compact for the amount of energy they store, they can be recharged over and over again, and they have a very low self-discharge rate (i.e. long shelf life when not used).

When used properly, LiPo batteries are a great way to power JeeNodes, etc.

Dear Mr. Murphy

In AVR, Hardware on May 28, 2010 at 00:01

Dear Mr. Murphy, you must have had a ball these past few days…

I goofed. Again. Big time. Well, not Toyota- or BP-scale big time, but still. It’s all your fault, Mr. Murphy!

About two dozen faulty ATmega’s were shipped as part of the JeeNode Kits. And another five dozen or so were packed into kits-in-stock:

Dsc 1505

What happened? Well, that “flashy” new multi-ISP programmer I was so proud of has a bug when the “isp_cpature.pde” sketch is used in replay mode: it doesn’t program the fuse bits properly. Whoopsy daisy. I thought I had all the scenarios covered and tested, but clearly I didn’t. Those ATmega’s are shipped running at 1 MHz, and the pre-loaded RF12demo is initializing the serial port to a totally useless 57600 / 16 = 3600 baud.

This morning (i.e. yesterday by the time this post comes out), I went through the stock of ATmegas, including those in already-packaged-and-labeled JeeNode kits, and redid the fuses and uploads. Not quite my idea of fun.

Anyway. The good news is that everyone has been contacted, and that I’ve sent out replacement ATmega’s to those people who I’m quite certain have the botched version. A few people will have run into the problem (that’s how I found out!), but most kits are probably still in transit, and will now be followed by the fixed ATmega(s) shortly.

In case I missed anyone, here are the symptoms: the LED on the USB-BUB stays on relatively long when a JeeNode kit is plugged in, there is no greeting from the pre-loaded RF12demo or there are only garbled characters, and you can’t upload to the JeeNode. The problem is only with ATmegas sent out in the past few days, no more than perhaps a week ago. JeeNode USBs and JeeLinks are not affected. If you run into exactly this problem, please email me and I’ll send you a replacement ATmega.

To make matters worse, I also mixed up some of the early Carrier Board and Ether Card orders, fogetting to include this or that. All issues reported to me have now been resolved.

Oh well, live and learn.

Now go home, Mr. Murphy, and don’t come back. Please? :)

Good news and bad news

In Hardware on May 26, 2010 at 00:01

You’re supposed to tell the bad news first, so…

The Carrier Board described a few days ago works nicely, along with the box, Carrier Card, and EtherCard.

BUT… I completely goofed with the optional DC power jack connector :(

With the current board, the center pin is connected to ground. Whoops! I’ve hacked it for now by rewiring stuff a bit, and leaving 2 of the 4 solder pads on the power jack unsoldered:

Dsc 1475

If you look very closely, you’ll see some black electrical isolation tape between the board and this side of the power jack. The other side of the jack looks like this:

Dsc 1476

Warning – the wires are not attached correctly in this picture. The PWR line on the top side needs to be hooked up to the rightmost pin on the DC power jack.

It all looks worse than it actually is, because the whole thing gets mounted into a box and is also held into place by the cutout in the outer wall. So the power jack can’t really move around, despite the fact that it’s only held by two solder joints on a single side.

Oh well – s…tuff happens.

And the good news is…

There are actually two much simpler and stronger workarounds for this problem, because only a single copper pad is causing the problem. The copper pad in the very corner of the board is the only one that needs to be fixed!

The first workaround is to cut the two thin traces connecting this pad with the surrounding ground plane:

Dsc 1483

Since the traces are right next to the edge of the board and very thin, all you need is a Stanley knife to cut those two traces. A V-type cut is the way to do it:

Dsc 1482

Use a multimeter or continuity tester to verify that the pad is indeed no longer connected to ground.

Voilá! Now that the corner pad has been isolated, the power jack can be soldered on in the normal way, and wired into the rest of the circuit as needed.

The second workaround is to cut the pin off from the jack itself, so it can’t touch the exposed corner pad:

Dsc 1481

Better safe than sorry, so it’s probably best to also use insulating tape, as was done above.

IOW, the incorrect power jack connection is a major glitch, but there are several effective ways to work around it. Given that not everyone will even want that DC power jack option, I’m going to stick with these PCBs.

JeeNode, Network

Meet the Ether Card

In AVR, Hardware, Software on May 24, 2010 at 00:01

Yesterday’s post was a sneaky way to show you a glimpse of an exciting new addition to the always-evolving Jee Labs product range – meet the Ether Card !

Dsc 1454

It’s a low-end Ethernet extension card, with a form-factor specifically made for the Carrier Board + Box:

Dsc 1467

It is based on the good ol’ trusty ENC28J60 chip, with all the components needed to hook it up to a JeeNode (or any other unit running the SPI bus at 3.3V).

I’ve started working a bit on the software side. The Ether Card is pretty standard in every respect, with the GPL2 code by Pascal Stang and Guido Socher working just fine with it. All it needs is a different chip select pin (PB0, Arduino pin 8) and proper interrupt guards to prevent the RF12 driver from interfering.

The card has been running smoothly for days on end here. It gets slightly warm, I’d estimate some 20°C above ambient. The regulator stays cool when powered from 5V. Total current draw is ≈ 150 mA, incl. JeeNode.

The Ether Card only uses through-hole parts, no SMDs. It has been added to the shop as kit and as PCB-only version. Here’s the PCB – in glorious blue-and-gold:

Dsc 1433

Here’s a sample web server requiring under 10 Kb of flash and showing a page with the last 25 RF12 packets:

Screen Shot 2010 05 19 at 11.33.18

So there you have it. JeeNodes can now handle wireless and wired networking.

It’s going to be oodles of fun to develop software for / on / with this Ether Card!

Credits: I would like to thank Andras Tucsni, who started the ball rolling by prototyping a complete working system and implementing the chip-select and interrupt changes needed for inter-operation with the RF12 driver on SPI. Andras also wrote the demo sketch which generated the above output. Knowing that it can be done and having working sample code makes a huge difference!

In and out of the box

In Hardware on May 23, 2010 at 00:01

The last two posts about the Carrier Board and Carrier Card showed how the whole kaboodle was designed for a specific light-gray plastic ABS box:

Dsc 1463

If you just use batteries and wireless, then that’s the end of the story.

But most of the time, this needs some cutouts. Let me describe how I created a custom version with a standard low-voltage power jack and an RJ-45 connector, using just these tools:

Dsc 1480

First step is to very carefully mark the position and saw some thin slots in this thing. ABS plastic is very soft and easy to cut with a little saw like the one above:

Dsc 1468

I tend to make the cutouts too narrow, because there is no way back!

To get a clean break, I use the knife to scratch along the line where the plastic needs to break, and then bend it (oops, you’ll also need some small pliers for that):

Dsc 1469

This coutout was in the top half, for the DC jack. After some trimming with the knife, the cutout looks pretty accurate. Next one was the RJ-45 connector:

Dsc 1470

Same idea: mark, saw, scratch, and break off:

Dsc 1471

Almost there. Still a bit too narrow, and not quite deep enough – some more trimming produced this:

Dsc 1473

Ah, that’s just about perfect (the left side could still be made a tad deeper):

Dsc 1478

Finished!

Meet the Carrier Card

In Hardware on May 22, 2010 at 00:01

The companion to yesterday’s Carrier Board is the Carrier Card:

Dsc 1458

It fits exactly in the plastic case, of course:

Dsc 1459

(If you look closely, you can see a hole to screw the left half of the board to the center of the shell.)

The Carrier Card is made of two halves which can be broken apart and used separately, if needed:

Dsc 1462

Here’s another configuration:

Dsc 1461

This allows inserting all sorts of JeePlugs, and using some or all of the connectors on the lower edge of the carrier Board for more elaborate projects. Everything is on a 0.1″ grid, so this also works with perf-board, etc.

By including the PWR/SER/I2C + SPI/ISP headers and connecting everything together, up to 19 I/O pins from the JeeNode are available when a full-width Carrier Card is inserted in the lower row of five 6-pin headers.

I’m looking forward to finally setting up some of the Jee Labs projects in a more permanent manner.

Tomorrow, I’ll show how to make some nice cutouts in the side of this box. ABS plastic is fairly easy to trim manually. Really good looking rectangular cutouts in the top or bottom are no doubt a bit harder – I intend to experiment with some CNC stuff for that.

Stay tuned!

Meet the Carrier Board

In Hardware on May 21, 2010 at 00:01

Finally, all the pieces have arrived to be able to announce the Carrier Board !

Dsc 1434

It fits into a plastic box of about 70 x 125 x 30 mm, made of two identical ABS shells which click together:

Dsc 1310

The JeeNode, JeeNode USB, and JeeSMD can all be used, they are “carried” by this board, so to speak:

Dsc 1311

Tons of ways to hook up plugs to this thing. There’s a diagram with all the pinouts (PDF).

Here’s a version which has all headers soldered in – not very useful, but I had to test everything anyway:

Dsc 1315

Note that only the port headers use male pins on the Carrier Board (towards the JeeNode, that is). The PWR/SER/I2C and the SPI/ISP headers both use pins with the opposite orientation. This was done because the ISP header is more useful as pins on the JeeNode, and to avoid confusing the PWR/SER/I2C header with ports, since both types use 6 pins.

More related news tomorrow…

Multi-ISP programmer

In AVR, Hardware on May 18, 2010 at 00:01

This is a project I’ve been meaning to do for a long time:

Dsc 1432

It’s a portable ISP programmer which can program four 28-pin ATmega’s independently. It takes about 12 seconds to program fuses, bootloader, and RF12demo sketch into each chip, so with this unit I can essentially keep going and program some 20 chips per minute. Just what I need for yesterday’s batch of fresh ATmega’s. For reference: a USBtinyISP needs a few minutes per chip! (update: but it can be speeded up, see comments below)

Not that I need to program 1200 chips/hour! The point is that at this speed, I can now flash ATmega’s just-in-time, i.e. with the very latest version of RF12demo, etc.

This multi-ISP programmer is built from 4 Flash Boards, 1 JeeNode USB, 3 JeeSMD’s, a 450 mAh rechargeable LiPo battery, and a couple of ZIF sockets, resonators, and resistors. I’ve got roughly a dozen more ZIF sockets for the shop of there is interest. Also some 6-pin IDC headers and flat-cable.

The unit uses the capturing ISP programmer sketch and is very simple to use: plug the JeeNode USB in and use it as a normal AVRISP programmer @ 19200 baud. Use as many programming steps as you want. When idle for 3 seconds, the process stops – blinking the LED twice. Then exchange its Flash Board with one of the others and repeat the process until all flash boards have been set up.

From then on it can also work in battery-powered mode: insert chip, press button, wait for LED to start blinking, then rinse and repeat. Total current draw will be well under 90 mA, so this programmer should get over 5 hours of autonomy on one charge – up to 6000 chips… :)

The programmers are independent, so I can upload different contents in each of them. I’ve labeled each flash board to be able to do this without mixing things up.

The JeeNode USB v3 powers all the boards and includes the LiPo charge circuit, so the battery can be recharged by simply plugging it in. There’s a slide switch to disconnect the LiPo battery.

Some more build pictures. As you may have noticed, there is no connection from the 2×3-pin ISP header to the ZIF socket. That’s because I wired those up from below by using stacking headers for 2 of the 4 ports:

Dsc 1422

Here is the other side, wired up manually with wire-wrap wire. I’ve since covered it up a bit to avoid accidental shorts. The risky one is a direct short between the LiPo power pins, the rest is probably harmless.

Dsc 1430

And here’s the side view:

Dsc 1431

I’m looking forward to using this thing: swap chip, push button, swap chip, push button, … how convenient!

New ATmega batch

In AVR, Hardware on May 17, 2010 at 00:01

At last, 250 new ATmega328′s came in from DigiKey:

Dsc 1419

You may not have noticed, but in these past months there has been a major shortage of ATmega328 chips – everywhere. Once that happens, people start stockpiling, driving the shortages and delays up yet further, etc.

That’s 250 chips to intitialize with a boot loader + RF12demo sketch! Kinda illustrates my need for a good ISP programmer setup, eh?

There’s a substantial amount of capital investment involved in this stuff, so I’ve been cautiously moving about while trying to keep all the essential items in stock for the shop. So far, so good, mostly. But this batch sure is welcome… one less thing to worry about.

Onwards!

Musings

There IS a pattern

In Hardware, Software on May 11, 2010 at 00:01

If you’ve been following this daily weblog for a while, you may have noticed that it’s all over the place – as if I’m working on everything and nothing. At the same time!

But there’s a pattern, dear reader.

Not fully worked out, not fully planned, not static, but still… there is.

The pattern is that I’m currently trying to automate some of the stuff I need to do here to keep Jee Labs running. The shop has been growing steadily, which is great because it means I can keep doing this – which is exactly what I want to do. Indefinitely, preferably.

But the shop needs to run smoothly, so that I don’t end up becoming its slave. That means the daily production work needs to be automated as much as possible. Only then will it be possible for me to work on all sorts of fun projects, keep up this daily weblog, and fill it with – hopefully – interesting topics, day in day out.

This “self-automation” is why I created the Flash Board, for example. And why I’m redoing the reflow controller to work more reliably. I’ve also been automating like crazy recently to try and stay on top of this huge pile of parts called (haha!) inventory.

I have not lost track of the main focus of Jee Labs – the direction where it all started: energy use tracking and environmental monitoring around the house. It’s still my main focus. And now that the basic hardware works, with lots of configurations and sensors to play with, the next frontier is the software.

But software is a very finicky beast. With hardware, you hook up a few parts and it starts working – after some soldering and/or tinkering, evidently. Software is both primitive and complex in comparison: primitive, in the sense that you have to create these big house-of-cards constructions to get anywhere. Complex, because each of the ingredients is usually a massive chunk of code.

So I’m taking a lot of time to think through numerous aspects of the software. JeeMon is the house I’m building, but its core structure needs to support ideas which haven’t even been invented yet. In terms of software, that means it has to be very modular. I’ve currently got a few components in place, and the binding structure and modularity trade-offs are starting to become clear.

What I don’t have right now, is a clear enough view on the data storage side of things. So all the little JeeMon experiments so far have been side-stepping the issue of persistence (the IT word for “storage”). I’m showing things on screen. Great, but of limited utility.

What’s the big deal with persistence? Well, the moment software includes a storage mechanism, you get into the issue of how to make changes. Suppose you have a working system, and you want to change it in some fundamental way because of a new insight. How do you deal with the data it has already stored? It sounds trivial, but I think it’s everything but trivial – on a very fundamental level.

Storage is a big deal. It is crucial. And it comes up even with something as simple as displaying a moving average. How do you deal with a system restart when there are moving averages in graphs you want to show, for example?

Software development and persistence create opposing forces. Development means just that: to progress from one insight to the next as you go along and extend your understanding of the deeper issues in the problem space at hand. And then, ideally, to implement solutions in better – sometimes completely new – ways. As a developer, I constantly tear my software apart, to put it back together in improved ways (I probably do it 10x more often than most developers). This is a learning process, and the result – IMO – leads to simplicity, elegance, and almost as a side effect: robustness.

Persistence is the elephant in the room. It opposes change. Data saved on disk (or flash memory) has a structure, and changing that structure can be anything from awkward to nearly impossible. That’s why starting from scratch is so easy. That’s also why version 2 of anything in software can be so elusive. It’s not just data, btw – code is data too, in this context. Try folding a new idea into an existing bit of code …

Maybe I’m overstressing this a bit – m a y b e. But this is the main reason why I work on completely unrelated issues at times, such as streamlining the shop activities.

In the meantime, as background process, I keep exploring scenarios for the software and collecting insights from what others do or even just ask for.

So there you have it: ISP programmers, solder reflow controllers, even tangential activities such as 3D printing and CNC milling, they all get addressed here at Jee Labs. Meanwhile, I try to figure out the best way forward for many far-reaching design choices w.r.t. JeeMon.

The good news is that I think this detour is coming to an end. I think a simple, small, modular, and fun way of tying all sorts of hardware together via software is starting to shape up – in a vague hand-waving style right now, but that’s just a matter of pushing the ideas into code. And doing the grunt work.

Neither the ideas nor the code are the hard part. Ideas are cheap and plentiful. Code is easy and can be created gradually. No, the really hard part is to come up with a “pervasively modular” architecture. I.e. how to set up a system (and hence make choices) which can evolve, even in ways not yet imagined.

What I’m after is not a solution, but a tool. And that takes a bit more time…

As the well-known Chinese proverb goes:

Fish

I’m not a teacher, but the fish doesn’t interest me nearly as much as improving the whole process of fishing.

Arduino, Reflow

Setting up the thermocouple node

In AVR, Hardware, Software on May 10, 2010 at 00:01

This is part 2 of my reflow controller series. Unlike what was announced yesterday, I’m going to first describe how to set up the temperature sensing wireless node. JeeMon hookup to follow soon.

Our very first step could be to connect the thermocouple via a JeeNode and USB to the PC, but I’m going to do something more interesting and go straight for a wireless hookup. One reason for this is due to a problem with direct connections, but since this is going to be used in un-tethered mode anyway, it’s a good excuse to use a wireless configuration right from the start.

Here is the “thermoSend.pde” sketch I’m going to use (code here):

Screen Shot 2010 05 09 at 14.29.35

This contains all the ingredients needed for a simple basic sensor node: all we do is set up wireless, and then read out the thermocouple value and send it off once a second.

The easy transmissions code works with broadcast packets, so we don’t need to define a destination for the wireless packets, just this sensor node’s ID (1), the choice of frequency band (868 MHz), and a group ID (6). That’s done with the rf12_initialize() call.

The readings are converted to an integer in the range 0 .. 3300, representing a temperature range of 0 .. 330.0°C. Then we send that 2-byte integer in binary mode over wireless. That’s what the code inside loop() does. The map function is part of the Arduino library code.

The easy transmit system will take care of re-transmission if a packet is lost. All the transmission details are handled by rf12_easyPoll(), which needs to be called often.

One detail of the easy transmit system to keep in mind, is that only changed values are sent. No packets will go out if the reading is the same as the last one. In this scenario, that’s fine – there’s always some jitter in the readings, so we should see new packets at least a few times a minute, even when the sensor temperature is constant.

Ok, let’s get going. If you haven’t installed the Arduino IDE yet, go do it now.

Create the above sketch named “thermoSend” in the Arduino IDE. On my Mac, it ends up as a folder named “Documents/Arduino/thermoSend/” in my home directory. Plug in the JeeNode via an FTDI adapter such as the USB-BUB (or use a JeeNode USB) and check your Arduino IDE / Tools / Serial Port settings to make sure you’re hooked up to it. With multiple nodes on USB, it’s easy to mess up the wrong one – happens to me all the time…

Now the node is ready. Unplug, hook it up to a battery, and power it up.

You’re sending packets into the ether now. Quick, let’s try and collect those packets before they falll on the floor!

To do that, hook up a JeeLink or a second JeeNode. It needs to be running the RF12demo sketch, which is what it does out of the box if you got it from Jee Labs or Modern Device.

We need to connect to the JeeLink. Easiest way is to use the Arduino IDE. Make sure you are connected to the proper USB port. So again, check the Arduino IDE / Tools / Serial Port menu and select the JeeLink serial port.

Now open the Arduino IDE’s serial console. You should see something like this:

[RF12demo] A i1 g212 @ 433 MHz
Available commands:
[etc]

You are now in direct communication with the JeeLink. We need to set it up to listen to the proper transmissions. Sort of like tuning to the proper radio station. So type the following line and press “Send”:

2i 8b 6g

This sets node ID = 2, frequency band = 868 MHz, and net group= 6.

If all is well, and the wireless node is powered up, you should start to see packets come in, something like this:

OK 33 212 0
 -> ack
OK 33 209 0
 -> ack
OK 33 212 0
 -> ack
OK 33 209 0
 -> ack
OK 33 212 0
 -> ack

That’s a header byte (i.e. 33, associated with node ID 1) and 2 data bytes.

There won’t be packets every second, because only changed readings are sent. But there will be packets, and if you touch the thermocouple end, you should immediately see the rise in temperature:

OK 33 212 0
 -> ack
OK 33 226 0
 -> ack
OK 33 24 1
 -> ack
OK 33 44 1
 -> ack

No, I’m not suffering from sudden hypthermia: that’s not 4.4°C :) – what you’re seeing is binary overflow of the first data byte. A byte can only hold values 0..255. Anything higher and it will wrap around. That’s why two bytes are sent. The second byte contains the reading divided by 256, i.e. the number of wraparounds. You’re looking at the binary representation of an “int” on Atmel AVR chips.

So the above readings are: 21.2°C, 22.6°C, 28.0°C, and 30.0°C.

IOW, the actual temperature is: (byte1 + 256 * byte2) * 0.1°C

The next episode will be about hooking up JeeMon to the Jeelink and using it to read out the data and do something more meaningful with it. Stay tuned.

JeeNode, Reflow

Reflow revisited

In Hardware on May 9, 2010 at 00:01

As mentioned yesterday, I’m restarting the reflow oven/grill project because my old setup with an NTC resistor is causing some mechanical problems with the connection of the NTC and because I want to end up with a setup which will be easier for others to replicate.

My intention is to start this project from scratch, using a JeeNode and a Thermo Plug as sensors, and then adding a JeeLink, an FS20 remote-controlled power switch, and of course a grill to create a fully automated and self-contained reflow station for soldering SMDs on printed circuit boards.

I’ll be replicating some of the first experiments, but there will be no need to calibrate NTC readings.

I’m also going to use JeeMon to illustrate how to design and implement the software for this from scratch. I expect to extend and improve JeeMon itself along the way, since it’s still very much in its infancy.

In case this is all new to you: reflow soldering is a technique whereby you apply solder paste to a PCB, carefully add all the components on top, and then bake that whole enchillada according to a preset temperature / time profile. The end result is a finished circuit. Here are some pictures from a few months ago.

Here is the intial setup:

Dsc 1413

From left to right: a 4.5V 3x AAA battery pack, the JeeNode, the Thermo Plug, and a 1-meter thermocouple sensor. This consists of two metal wires of different types, joined at the end. The end is where sensing takes place, because every junction of two different metals generates a tiny electric potential related to temperature.

Yesterday’s post contained the very simple sketch I’m using for this first step.

Tomorrow, I’ll describe the software setup and the first steps needed to read out the data sent by this sketch.

Update – switched to a slightly simpler setup, as shown in the updated picture.

Reflow, Sensors

Thermocouple enigma

In Hardware on May 8, 2010 at 00:01

I’ve been scratching my head while trying to get the Thermo Plug to work with an on-board AD597 + thermocouple.

Sure, it works fine…

But only on a 4.5V battery pack! When I connect this thing through a USB-BUB, the readings are severely distorted 9 out of 10 times.

Here’s a sample of the readings on USB:

251 251 251 238 244 261 238 248 251 254 251 206 241 261 251 254 241 209 244

Here are some readings I get on battery power, i.e. not attached to anything:

206 209 206 206 206 209 206 209 209 209 206 206 206 209 203 206 206 206 209

This is the sketch I’m using (code here):

Screen Shot 2010 05 07 at 14.36.29

I’ve tried to rule out noise and other flakiness on the 5V PWR pin by adding capacitors and even a ferrite bead to filter out HF, but none of it seems to have any effect.

Big puzzle! Does anyone have any suggestions what else to try?

The good news is that everything works fine with batteries, so I can continue working on the code for my reflow grill controller. It needs an update because the NTC has a flaky wiring connection (can’t use solder there!) and because I want an accurate temperature readout without having to calibrate things.

▶ View 11 Comments

Assembling the Flash Board

In AVR, Hardware on May 7, 2010 at 00:01

Here is a step-by-step instruction for assembling the Flash Board, starting from these components:

Dsc 1386

The 24M01 1 Mbit EEPROM is already on the board. The build proceeds essentially in flattest-to-higher order, so that when you turn the pcb around for soldering, you can push down the part properly.

We start with the 470 Ω current limiting resistor for the LED:

Dsc 1388

Try to make nice and shiny joints:

Dsc 1387

Cut off the excess wires:

Dsc 1389

Next is the little start button:

Dsc 1390

There are four pins to solder:

Dsc 1391

They are a bit long, so it’s best to cut them off:

Dsc 1393

Next, the LED. This one is polarized, be sure to put it in the right way:

Dsc 1394

The last component on the top is the 2×3-pin ISP header:

Dsc 1396

Again, make sure all pins have good solder joints:

Dsc 1397

Now, all we need to do is solder in the 4 6-pin headers. The easiest way to do so is to push these headers into a JeeNode for proper positioning:

Dsc 1398

The push the Flash Board on top and you’ve got a convenient way to solder them:

Dsc 1399

That’s it, done!

Dsc 1400

Now you can upload the isp_capture.pde sketch and use this brand new ISP programmer.

Happy programming!

Low-level development

In AVR, Hardware on May 6, 2010 at 00:01

I’m working on some ideas which require some low-level code, and fairly accurate timing. Serial or wireless I/O are not an option, and hooking up the logic analyzer is not convenient (I may have to, if the going gets tough).

For now, here’s a very simple setup which ought to be sufficient:

Dsc 1385

Two boards, hooked up via two USB ports. They are on the same computer, so there should be no issues with voltage levels when leaving them both connected at the same time (I’m not too worried about the ground loop).

The board at the top is the Flash Board as ISP programmer (I’m not using the new capturing features here). The board below is the “target”, a plain JeeNode hooked up to a USB-BUB. Nothing fancy.

I’ve added 8 bits of “I/O” by hooking up 8 LEDs with current-limiting resistors – red on the DIO pins, green on the AIO pins as debugger, as described here.

The target board also has the option to communicate over serial (i.e. through its USB connection), but that adds code and affects timing – something which I probably can’t tolerate in my specific tests.

Nothing very unusual here, but it’s worth pointing out that a couple of years ago, a setup like this could easily have cost over 1000 <pick-your-favorite-currency>, whereas this one is well under 100.

Let’s see how it goes…

A capturing ISP programmer

In AVR, Hardware, Software on May 5, 2010 at 00:01

Meet the new, improved, autonomous, self-guiding, hassle-free, portable ISP programmer!

Dsc 1381

It works as follows:

hook up a JeeNode or JeeNode USB to your computer
upload the isp_capture.pde sketch to it
insert the Flash Board and hook it up to the target
program the target, using this as a standard STK500/AVRISP programmer @ 19200 baud
wait for the LED to blink twice
done

And this is where the fun starts:

connect the JeeNode to a battery or any other power source
insert the above Flash Board again and hook it up to the target
press the button on the Flash Board
wait for the LED to first turn off and then start flashing
done

You’ve just programmed another target MPU … look ma, no hands!

The first hookup went through a normal programming cycle, but it also stored everything in the EEPROM on the Flash Board: code, data, fuses, verification bytes, everything. That’s why I’m calling this a capturing programmer.

When pressing the button, it essentially repeats all the same steps.

This works for anything you can program with an AVRISP programmer: ATmega, ATtiny, whatever. And it will even capture multiple programming cycles, as long as they are started before the LED blinks twice, i.e. within a few seconds. So you could set up a script to call avrdude with a few different things to do – e.g. set fuses, program the flash, program the AVR EEPROM, set the lock bits.

There are some tricks under the hood to make this work. First of all, the baudrate as ISP programmer is set to 19200, so that the bootloader in the JeeNode doesn’t accidentally take over after reset (it listens at 57600 baud).

Another trick, and the main reason this all works transparently, is that the entire serial communication session is stored in EEPROM as is. When pressing the button, it simply replays the input to the programmer code as if it was coming from the serial port (and matches the results, also against EEPROM). There is some logic involved to be able to store both input and output streams, and keep them properly apart.

The EEPROM is connected via I2C to port 3. I used the MemoryPlug and MemoryStream classes from the Ports library to access it.

Lastly, there is some debugging built in. While used as AVRISP programmer, the serial port is in use for programming @ 19200 baud. But when in replay mode, the serial port is set to 57600 baud and used to report what the programmer is doing. Here is a transcript:

[isp_capture]
ISP bytes: 39680
Code size: -32768
Page size: 128
Data size: 1024
Signature: 86 00 00 01 01 01 01 03 FF 95 0F
Programming...
Done in 13.9 seconds.

That’s it. There is visual feedback when programming succeeds in the form of a flashing LED, so that this setup can be used without serial link. I’d like to add auto power-down one day, for serious battery use.

I’m going to use a bunch of Flash Boards here, pre-loaded with the different contents of ATmega’s and ATtiny’s I’m constantly preparing here at Jee Labs. Will probably also dedicate a bunch of JeeNodes to this, but that’s optional – any available JeeNode can be temporarily turned into an ISP programmer by simply uploading the “isp_capture.pde” sketch to it and inserting a Flash Board.

Now I can easily reprogram all those Room nodes in the house!!

PS. There’s nothing JeeNode-specific about this setup. The on-board wireless isn’t used (yet?).

PPS. For your convenience, I’ve tagged all related posts on this weblog with ISP.

Communication 101 – Networks

In Hardware, Software on May 4, 2010 at 00:01

After yesterday’s introduction, let’s tackle the more advanced version of communication: networking.

For example a set of machines connected via Ethernet:

Screen Shot 2010 04 26 at 13.48.00

(often, the hub will also be connected to a router and/or internet)

While similar to “point-to-point” communication on the surface, and sometimes even at the hardware level, this is completely different in terms of software.

The difference between dedicated links and networks, is that the network is shared for use by multiple nodes. It can’t deal with everything at once, so again, “time” is a crucial aspect of networking.

First of all, you’ve got to take turns talking, How do you take turns? Not so easy. In face-to-face conversations, we use an intricate system of pauses, expressions, gestures, and behaviors to effortlessly take turns in a conversation. On the phone, it’s a little harder, on a phone with a noticeable time lag, it can be frustratingly hard.

With computers, one thing you have to do is break each transmission into chunks – i.e. “packets”. Then it’s a matter of getting all the packets across, one by one, in the correct order, until the task is done. Or abort between packets, and allow changing roles so that other nodes can start to transmit.

Ethernet is a common way to connect computers, and TCP/IP is the standard used to do make communication possible. The whole internet is built on it. On a network, everyone has to play by mutually agreed rules. These can be fairly complex, which explains why microcontrollers need some extra hardware and code to be able to act as Ethernet node – and it can easily reach the limits of what they can do.

The nice bit about networking is that once you’re “on” a network, any node can communicate with any other node. But again, there is quite a bit of machinery and logic needed to make that possible.

The two key features of the serial communication described yesterday, is that they are reliable and throttled. Well, not so on a network. Packets get lost or damaged in transit. Someone could be messing with the cable while two units are exchanging packets, and disrupt the whole process. Even if two nodes are working 100%, they can still fail to exchange a packet!

So with networking, you have to deal with things like timeouts, acknowledgement packets (which can get damaged as well), and re-transimssions. You also have to deal with flow control, to avoid sending more data than a receiver can handle. Imagine sending a steady stream of packets: if one of them gets lost, we have to detect the failure (takes time), re-send the packet (takes more time), and catch up with the new incoming data!

Before you know it, yesterday’s “Serial.println(value);” example turns out to require a lot of logic and error-handling.

It gets worse: what if the receiving node isn’t even connected right now?

The transmitter should to be able to detect this so it can decide what to do.

Sometimes, there is no alternative but to ignore it. Sometimes, that’s not even such a big deal – for example with a sensor which is periodically sending out new readings. It’ll fail, but once the receiver is back online, it’ll all start to work again.

If you’ve ever ever looked into a “networking stack” (i.e. its code), or even implemented one yourself, you know that writing this sort of code is a complex task. It’s not easy to communicate reliably when the communication channel is unreliable.

This daily weblog is a nice analogy, btw. I send out daily “posts” (packets), but this one for example continues where yesterday’s discussion left off. In a way, by assuming that you, dear reader, will follow along for more than one post, I’m creating a “story” (virtual circuit), based on daily chunks. It’s a fairly robust communication stream operating at a constant rate. Based on nothing but web pages. So now you can think about packets, next time you watch a YouTube video :)

What about wireless networks?

Screen Shot 2010 04 26 at 13.48.08

The good news is: wireless networks have to deal with most of the same issues as wired networks, and these issues are well understood and solvable by now.

The bad news is: wireless networks have to deal with a lot more unreliability than wired networks. All it takes to disrupt a wireless network is some RF interference from an old arcing motor, or even just walking out of range!

It’s possible to maintain the illusion of a serial connection over a network – it’s called a virtual circuit. TCP/IP does that: when you talk to a web server, you often exchange a lot more than will fit in one data packet. So TCP/IP sets up a mechanism which creates the illusion of a serial link – a virtual pipe between sender and receiver. Put stuff in, and it’ll come out, eventually.

Except that this illusion can break down. There’s no way to maintain the illusion of a permanent “connection” when you unplug the receiver, for example. Or walk out of range in a wireless network.

There’s no way even to give guarantees about communication speed. You might be at the very edge of a wireless network, with the system frantically trying to get your packets across, and succeeding perhaps once an hour. Oof – made it – next – yikes, failed again – etc.

In a wireless sensor network (WSN), which keeps sending new readings all the time, the illusion of a virtual circuit – i.e. virtual serial connections – can break down. And what’s worse: when it does, it’ll do exactly the wrong thing: it will try to get the oldest packet across, then the next, and so on. Which – if the network is really slow – is just going to lead to a permanent backlog.

What you want in a WSN, is to occasionally drop the oldest readings, which are more and more obsolete anyway, if that helps recover and obtain the most recent readings again.

A bad WSN’s can give you lots of data you don’t want, whereas a good WSN will give you the latest data it can. The trick is to stop trying to send an old value as soon as you’ve got a new and more up-to-date reading.

This is the reason why the RF12 driver used with JeeNodes uses a packet delivery model, instead of a virtual circuit model. In networking terms: UDP instead of TCP. Also: best effort instead of (semi-) guaranteed in-order delivery.

Nice bonus: packet delivery is far simpler to implement than virtual circuits.

What has worked so well for teletypes and serial consoles for several decades, is not necessarily a good idea today. Not in the context of networks, particularly WSN’s. For another example, you need look no further than the web: part of HTTP’s success is based on the fact that it is “state-less”, i.e. not fully connection-based.

So all I have to do now, is to convince the whole world that thinking of communication as serial connections can be awful in some scenarios!

Heh, piece of cake: just make the whole world read this weblog, eh?

Communication 101

In Hardware, Software on May 3, 2010 at 00:01

Triggered by a recent post on the discussion forum, it occurred to me that I may be taking way too many concepts for granted. My problem is that I’ve been around computers too long. Not so much in being socially inept (just a bit introvert :) – no, the issue is that I seem to have become pretty familiar with how they work, from silicon to database to web-server.

This is a huge hurdle when trying to share and explain what I’m doing, and it probably makes this weblog harder to dive into than I intended, as a friend recently pointed out – an insight for which I’m very grateful.

So after this little bit of personal communication, let me get to the point: what I’d like to do from time to time on this weblog is to go into some key topic, relevant to the projects here at Jee Labs, but doing it in such a way that will hopefully bring more insight across to people who share the enthusiasm for all this Physical Computing stuff, but not necessarily all that techie background.

Not to worry – this is not the start of a textbook :) – nor a treatise. Just trying to clarify some stuff. Succinctly, as much as I can. If you know all this, or if it bores you – bear with me for one or two posts, I will go back to other topics again in the next posts. When I make mistakes, or say nonsense, please do correct me. I live to learn.

Today, I’ll kick this off with Communication (Wikipedia) – in the context of information exchanges between computers and peripherals, and within the hardware of various types of systems.

First off: why communicate? Because that’s what computers do, essentially. Number crunching (i.e. the literal sense of “to compute”) is secondary by now.

Examples, in the context of physical computing:

sending a measurement value to our PC
sending information to a display
sending data to an attached chip or device
sending a control signal to turn things on or off
sending packets by wireless to another node

How can information be sent? In short: as bits, from a software perspective, or as electric / magnetic / optical / mechanical signals from a hardware perspective. You could say that Physical Computing is about bridging those software and hardware perspectives. Sensing “stuff” and making “stuff” happen. With the fascinating part being that there is computation and change awareness (state) and decision-taking involved via the microcontroller which sits in the middle of it all.

This is a big topic. Let’s narrow it down. Let’s focus on communication in the form of bits, because ultimately just about everything goes through this stage.

Screen Shot 2010 04 26 at 13.38.51

Let’s take that first example: sending a measurement value to our PC. How do you do that? Simple, right? Just put something like this in your sketch:

Serial.println(value);

Whoa… not so fast. There’s a lot going on here:

we select an interface (Serial)
we fetch the measurement value from a variable (value)
we convert that data to a text string (println)
we transmit the text, character by character, over a serial link
somehow that serial link uses electrical signals to travel over a wire (hint: FTDI)
somehow this finds its way into a USB port (hint: device driver)
somehow this is picked up by an application (hint: COM or /dev/tty port)
somehow this appears on the screen (hint: serial console)

And what’s probably the most complex aspect of this entire process: it takes time. What appears to happen in less than the blink of an eye to us, is in fact a huge time consumer as far as the microcontroller is concerned.

If we ignore the details, you have to admit that this works pretty well, and that we can indeed easily get results from a microcontroller board to our PC.

That’s due to two key features of this comms channel:

the connection is reliable: what is sent, will arrive, eventually
the connection is throttled: sending is slowed down to match the reception speed

It’s easy to take this for granted, but not everything works that way. When you send data to an attached LCD display for example, the software has to take care not to send things too fast. LCD displays need time, and there are limits to how fast information can be presented to them. The Arduino “LiquidCrystal” library is full of little software delays, to avoid “overrun”, i.e. sending stuff faster than the LCD can properly handle.

The trouble with delays is that they hold everything up!

Well, that’s the whole point of delays, of course, but in a microcontroller, it means you don’t get to do anything else while that delay is in progress. Which has its own problems, as I’ve described earlier.

If you think about it for a moment, you might see how delays in fact make communication virtually impossible: because if you’re supposed to wait for all the little steps to complete, how can you possible handle incoming data, which has no idea that you’re currently waiting in delays and not listening to anything?

I won’t go into the (hardware-based) solutions which work around this issue, but it has been solved, to a certain extent. This is why data coming in from the USB link will usually arrive just as expected, yet at the same time sending out data usually slows down the microcontroller in clearly noticeable ways. Try making a blinking LED, and then sending a string with Serial.println in between each blink. Sure enough, either the blinking or the serial output will become slower or even irregular.

Communication of of data takes time. We don’t have infinitely fast connections. Even something as simple as “Serial.println(value);” is full of nasty side-effects and details, especially on a microcontroller such as the ATmega.

It’s good to keep this in mind. This is one reason why something as seemingly simple as collecting data from multiple serial streams requires a fairly advanced library such as NewSoftSerial, and why even that clever code has its limitations.

Tomorrow, I’ll talk about packets, networking, and wireless communication.

ATtiny 8-pin ISP programmer

In AVR, Hardware on May 1, 2010 at 00:01

Yesterday’s ISP programmer used a 28-pin socket wired up for ATmega328 chips (and the older 48/88/168 versions).

As it turns out there are enough unused pins available in that socket to also support the ATtiny 8-pin series (such as 25/45/85). The trick is to add a few extra wires so that the ISP programming signals have the proper setup for these smaller chips as well:

Dsc 1376

This allows placing an ATtiny in the socket at the top end, i.e. using just pins 1..4 and 25..28:

Dsc 1377

This trick works, because the I/O pins used by the ATtiny happen to be normal I/O pins for the ATmega, so it doesn’t mind having some logic signals there (pins 9..12 and 17..20 can probably also be used, but then inserting the chip becomes more error-prone).

And sure enough, avrdude can now program the ATtiny as well:

Screen Shot 2010 04 25 at 02.44.46

For other chips, you’ll need to wire up a chip-specific socket, but at least for these ATtiny chips an ATmega setup will work just fine!

ATmega 28-pin ISP programmer

In AVR, Hardware on Apr 30, 2010 at 00:01

The Flash Board presented a few days ago was only half the story. Here is the other half, i.e. the chip socket.

What you need is a board with a 10 kΩ reset pull-up resistor, an 8..16 MHz resonator for the clock, and – just to be safe – a 0.1 µF decoupling capacitor. I used an empty JeeNode v4 PCB to hook it all up:

Dsc 1372

I added the ISP connector in a slightly unusual way: with long pins bent sideways. The reason being that the ZIF socket won’t fit on the board otherwise. In fact, it won’t fit directly anyway because the holes are too small and the socket is too long. So I pushed it (hard!) into a 28-pin IC socket first:

Dsc 1371

Then I soldered the socket in, and there it is:

Dsc 1373

An ISP programmer for 28-pin ATmega’s!

Tomorrow, I’ll describe how I’ve modded this setup to also allow programming 8-pin ATtiny DIP chips …

JeeLink

JeeLink’s “Plan B”

In Hardware on Apr 29, 2010 at 00:01

Hmm, it looks like the plastic “USB stick” cases are seriously and totally unavailable. I’ve completely run out of cases, and the next shipment from Farnell is reported to be in… July!

Can’t have everyone wait for it, so I’ve started replacing the case by some semi-transparent heat-shrink tubing:

Dsc 1375

It’s not quite as pretty or sturdy, but it does protect the board so you can easily plug in or remove the JeeLink. The red, green, and blue LEDs are still clearly visible.

If nothing changes on the delivery-of-cases front, then this change will become permanent. Otherwise, I’m willing to repackage any JeeLink you send back at no extra cost. Once the original cases are available again.

Will keep y’all posted on this …

Update – Just got a note from Farnell that the cases are shipping (!). I’m going to hold back on all JeeLink shipments until Monday – with a bit of luck, I can send them off with the “real” plastic cases after all!

Meet the Input Plug

In Hardware on Apr 28, 2010 at 00:01

After yesterday’s exploration into sending 4 bits over one I/O pin, it was easy to complete the Input Plug:

Dsc 1364

I got the silkscreen labels completely wrong, but once that was clear it all went more or less as intended.

A new “InputPlug” class has been added to the Ports library. It’s essentially still a Port, but with one extra “select(channel)” member to set the input channel from 0..15.

Note that this is called an input plug, but it’s really an analog 16-channel multiplexer in front of the AIO pin of a port. It can be used for analog input as well as digital input (just use digiRead2() i.s.o. anaRead()).

But it can also be used as output demultiplexer, even for analog (i.e. PWM) output when connected to port 2 or 3! Just keep in mind that as output, the usefulness is limited since there is no latching going on: the pin goes to high impedance, i.e. disconnects, when the channel is not selected.

One possible use as output, is to drive a set of transistors – one at a time, e.g. to multiplex a 7-segment or matrix display. By setting the AIO pin permanently to 0 (or 1), you could use the channel selection to pull one of the 16 pins down (or up).

The Input Plug is not an I2C plug – it requires a dedicated port and can’t be daisy-chained.

The following “input_demo.pde” example sketch has been added to the Ports library:

Screen Shot 2010 04 19 at 23.26.41

Sample output:

Screen Shot 2010 04 19 at 23.10.33

All inputs read out as 1023 because of the pull-up in this demo, except for one pin which I was manually connecting to a 1.5V battery in rapid succession.

Will be adding this plug to the shop shortly. See the documentation page for further details.

Decoding a pulse train

In AVR, Hardware, Software on Apr 27, 2010 at 00:01

The (planned) Input Plug uses an ATtiny chip to decode a 16-channel selection code using a single I/O pin.

Here is the relevant part of the schematic:

Screen Shot 2010 04 19 at 19.50.37

The DIO pin is connected to PB4 of the ATtiny. The ATtiny PB0..PB3 pins in turn are hooked up to the A..D select inputs of the analog multiplexer. So all the ATtiny needs to do is decode an incoming “pulse train” on its PB4 pin, and send out the decoded value on its PB0..PB3 output pins.

My first attempt used a simple serial protocol: a start bit and 4 data bits, clocked at a fixed rate:

Screen Shot 2010 04 19 at 19.52.59

This worked, but it was a bit flakey because the internal clock of the ATtiny is not accurate enough to ensure everything stays in sync for the entire duration of the transmission, i.e. across 5 bit periods. This is clearly explained in the following image (from here):

async1

It’s better to use a self-clocking format, for example 5 pulses of varying width, because then only the length of each individual pulse matters. Above a certain threshold = 1, below = 0. And we can reset when there are no pulses.

Here’s the a transmit test sketch, which sends a 0..15 counter every 100 ms:

Screen Shot 2010 04 19 at 19.57.36

As you can see, the pulses are 4 or 8 µs wide, with one pulse every 12 µs. Roughly.

Note that interrupts have to be disabled during each “transmission”, since these pulses are very short and need to be fairly strictly controlled.

The decoder on the ATtiny (ATtiny85 in this test) is also quite simple. It waits for a pulse start and then counts in a loop until the signal drops to zero again. Counts above a certain value are treated as “1″. Missing pulses and pulses which are way too long cause the decoder to be reset and start from scratch:

Screen Shot 2010 04 19 at 20.01.21

This can be compiled with avr-gcc, and it’s of course just a few bytes (even an ATtiny is overkill here):

Screen Shot 2010 04 19 at 20.02.44

I’m using yesterday’s Flash Board for ISP programming. Makes a good test that it also works with ATtiny MPUs.

Here’s the test setup (with the ISP programmer disconnected):

Dsc 1362

And sure enough, the LEDs display a little running 4-bit counter, driven by data sent over a single DIO pin.

Should be good to go for the Input Plug!

Meet the Flash Board

In Hardware on Apr 26, 2010 at 00:01

The Flash Board is a brand new piggy-back board to turn a JeeNode into an ISP programmer:

Dsc 1352

It’s compatible with the ISP plug described a few days ago, but it includes a few extra features:

on-board button and LED
on-board 128 Kbyte EEPROM memory
holes for a “direct-connect” ISP connector

It works with the isp_flash.pde and isp_prepare.pde sketches. See those two posts for details about these.

This board is now in the shop as kit, with the EEPROM soldered on since most people probably don’t want to solder such tiny surface-mounted chips. Note that the above two sketches don’t use the on-board EEPROM.

Here’s the Flash Board in more detail:

Dsc 1357

Nothing fancy, but I find it convenient, especially in combination with a JeeNode USB and a LiPo battery pack as a Portable ISP Programmer!

The “direct connect” ISP connector is a funky way to dispense with the ISP cable altogether, and plug this thing directly into a board with 6-pin ISP holes:

Dsc 1358

The master JeeNode + Flash Board are pushed upside down into the 6 holes of the ISP header, i.e. without header. Due to the way these extra long pins are placed, they will go in under an angle and push sideways to make a good connection. The trick is that these pins use two separate ISP headers, to end up with pins 1-2/3-4/5-6 swapped, so that they’ll work properly upside down. See the after-burner weblog post for another example of this.

Sure, it’s a bit funky. And you don’t have to use this. But it works :)

ISP, JeeNode, JeePlug

ISP plug

In AVR, Hardware, Software on Apr 24, 2010 at 00:01

For one of my projects, I needed a quick way to reflash an AVR via ISP. Didn’t want to have to use any of the several ISP programmers around here, so I made my own “ISP plug” for use on a JeeNode:

Dsc 1353

The pins are connected as follows:

ISP pin 1 = MISO = DIO1
ISP pin 2 = VCC (+3.3V)
ISP pin 3 = SCK = AIO1
ISP pin 4 = MOSI = AIO4
ISP pin 5 = RESET = DIO4
ISP pin 6 = GND

Here the top view, made from a little JeePlug board:

Dsc 1354

Bottom side:

Dsc 1355

Note that this ISP setup draws 3.3V from the JeeNode and uses it to power the target, so the target board should not have its own power and it should not draw more than say 100 mA of current @ 3.3V.

The code for this is called “isp_flash.pde” and is derived from the “ArduinoISP” sketch. I added software-based (bit-banged) SPI communication for use with the above I/O pins, and did a fair bit of cleanup of the source code.

The nice thing about this ISP programmer is that it works out of the box with Arduino IDE 0018:

upload the ISP_flash.pde sketch to the JeeNode
insert the ISP plug and hook it up to the test circuit (or one of these …)
burn the boot loader using the Arduino IDE:

Screen Shot 2010 04 18 at 18.04.06

The result will be a properly initialized ATmega, with protected bootloader and the default blink demo pre-loaded.

It’s not terribly fast because it uses a 19200 baud connection, but it’s simple and can be a life-saver if you ever damage the bootloader on an ATmega, or want to prepare blank ATmega’s for use with a JeeNode.

This plug can in fact be used as ISP programmer for any type of ATmega or ATtiny with “avrdude”:

Screen Shot 2010 04 18 at 18.14.42

You’ll need to adjust the serial / USB port, fuse settings, and sketch as needed, of course.

JeeMon, JeeNode

A mini scope

In Hardware, Software on Apr 22, 2010 at 00:01

Triggered by a discussion on the forums, here’s a little demo of how to build your own “Poor Man’s Scope”:

Screen Shot 2010 04 21 at 20.36.10

I connected an LDR between AIO1 and ground, and played around with light levels during this screen shot. The last samples were all over the map because I inadvertently touched the LDR leads.

All you need to reproduce this experiment is: an LDR, a JeeNode, and the JeeMon runtime. Oh, and the Arduino IDE to compile and upload a sketch to the JeeNode.

The sketch is adapted from the arduino-arduinoscope.pde demo. This is not nearly as fancy (or even flashy) as that Processing-based version, but it’s very easy to set up and get started with, IMO.

Anyway, here is the sketch running on the JeeNode:

Screen Shot 2010 04 21 at 20.44.32

It does a lot more than I’ll be using here, since I’m only picking up and displaying the first analog value, i.e. AIO1 on the JeeNode.

To get started with JeeMon, you could go read this page to get some background, but all you need really is the executable, so you can just download the appropriate one: for Windows, Mac, or Linux.

Then:

unpack the ZIP file, so you end up with a “JeeMon” executable
create a directory called “JeeMon-rigs”
in that directory, create a file called “application.tcl” (contents shown below)
adjust the serial port of the JeeNode to your setup (look at the top of application.tcl)
launch JeeMon, and you should get the real-time scope display shown above

Here is the application.tcl file, written in Tcl and using the built-in Tk GUI subsystem for visual display:

Screen Shot 2010 04 21 at 20.53.36

I’ve sprinkled some comments in the code. There are a fair number of pesky little details (as in all programming languages), but even without knowledge of Tcl/Tk you should be able to more or less see what’s going on.

There’s a lot one could improve or add to this thing. There always is. This is just a starting point.

But there you go: a Poor Man’s Scope in less than 100 lines of JeeNode sketch + JeeMon rig code. Fun!

Picking up RF noise

In Hardware on Apr 14, 2010 at 00:01

In yesterday’s OOK scope, there were many pulses at around 880 µs and 1100 µs which I couldn’t explain:

Screen Shot 2010 04 11 at 152609

Here’s another graph from new readings, same sketch, same ELV 868 MHz receiver:

Screen Shot 2010 04 11 at 16.39.16

That’s clearly much better. The difference? It’s all about how you hook up the RF receiver!

This was used during the first set of readings:

Dsc 1337

And this was used for that second graph:

Dsc 1336

So the receiver is picking up a lot more noise from the Carrier Board!

It’s not that surprising, in hindsight – the Carrier Board has a lot of traces running all over it it to hook up the numerous different signals on the board.

Note also that it took 20% less time to pick up the roughly 1,000,000 pulses for that second graph. My hunch is that the receiver’s AGC is ending up being set more sensitive without the spurious noise picked up from the circuit next to the OOK receiver.

Anyway, that’s one mystery solved.

Is the Carrier Board a bad idea? Not so fast. Here’s the ELV 433 MHz receiver, plugged directly into a JeeNode:

Screen Shot 2010 04 11 at 17.19.58

And here it is again, with a Carrier Board between receiver and JeeNode:

Screen Shot 2010 04 11 at 17.28.43

So at 433 MHz, it’s now attenuating the noise from the JeeNode.

Unfortunately, it gets even more confusing: look how few pulses the 433 MHz Conrad receiver picks up when plugged directly into a JeeNode during the same amount of time:

Screen Shot 2010 04 11 at 17.38.21

I’m inclined to go with the Conrad receiver for testing BTW, since it seems to pick up all the important pulses. Much simpler to debug with less noise!

Looks like I’ll have to be real careful while comparing results and drawing conclusions. And use some sort of ground plane or shield in the final setup.

OOK plugs

In Hardware on Apr 12, 2010 at 00:01

I’d like to get some more weather sensors etc. connected to JeeNodes, so I made some “OOK plugs” by hand:

Dsc 1332

top: 433 MHz receiver and transmitter, by Conrad
bottom left: 868 MHz receiver by ELV
bottom right: 433 Mhz receiver (also by ELV?)

The top two units need an external 17 cm wire antenna, the bottom two have built-in PCB antennas.

Here’s my OOK test unit, using a JeeNode USB v3 and the new Carrier Board & box:

Dsc 1334

And here a first test setup:

Dsc 1335

One of the things I’d like to establish is to what extent these units can be combined in one box. A previous attempt with the OOK relay seems to indicate that there can be severe interference between these units. Even “receivers” tend to emit quite a bit of RF power from their tuned circuits over short distances.

Haven’t wired up these units yet The plan is to tie receivers to the AIO pin and transmitters to the DIO pin, so that a pair of them can be used on a single port.

Update – Here is a detailed view of the different receivers and how they were hooked up:

Dsc 1513

Dsc 1514

Closing in …

In Hardware on Apr 11, 2010 at 00:01

The first Carrier Boards and Carrier Cards have come in, as described a few weeks ago on this weblog:

Dsc 1309

The Carrier Board is sort of a chameleon, given all the options it has for connecting stuff together:

Dsc 1329

You’re not supposed to use all those options at the same time, although you could if you really want to:

Dsc 1313

On the back you can plug in either a JeeNode, a JeeNode USB, or a JeeSMD as “processing engine”. Here’s a JeeNode USB:

Dsc 1315

As you can see, the USB connector will fall inside the case when plugged in this way, e.g. when you don’t use it, or to hook up a cable permanently.

Or… you can turn the board around, and make a cutout in the case to access the USB jack from the outside:

Dsc 1316

Wanna see how much you can cram into a box? Here’s a first attempt, with still some room to spare:

Dsc 1323

One more feature worth mentioning, is that there are pads and holes for an SMD-type DC jack. Here’s the jack soldered on, with a JeeSMD plugged in (the “+” end needs to be wired up manually):

Dsc 1325

Lots of options with all this. Great, now I can start working out some projects which need an enclosure.

There is one issue with the Carrier Board, alas … It turns out that the RX/TX pins on the FTDI connector (top right, first picture) were accidentally reversed. So this board doesn’t work with a USB-BUB out of the box.

That’s ok, though. I only had five of these prototypes made – just enough to try them out. Will fix it before ordering more boards for the shop.

It’ll take some time, but it’ll all work out nicely in the end, I expect.

The JeeNode USB v3 has arrived

In Hardware on Apr 9, 2010 at 00:01

Well, I finally got around to finishing the details (ehm… at least some) of the new JeeNode USB v3.

I’ve added it to the Shop, replacing the older JeeNode USB v2. Starting now, all JU’s sent out will be v3′s.

As you may recall, the main reason for bringing out a new version was because the v2 model had the 3.3V on-board regulator mounting messed up, requiring manual fixes to be made for each unit.

The new v3 board has the regulator mounted correctly. Here is a list of all the differences, since a new run gave me the opportunity to do a bit more:

The 3.3V regulator is now also used to supply power to the ATmega and RFM12B. This improves ADC accuracy, since running the ATmega off the FTDI regulator and bringing out 3.3V from another regulator isn’t really a good idea.
The RFM12B has been moved to the side a bit, to make room for a pad with hole to solder the antenna wire to. Less risk of it breaking off during use.
The board length has been increased (80.7 mm vs 79.8 mm) so the RFM12B no longer sticks out.
The USB jack has been moved out a bit, so now it sticks out. This will be more convenient when mounting the board flush against the outer wall of some enclosure.
There is now an on-board MAX1555 Lithium Polymer battery charge chip on board, as well as an orange LED, which lights up while the circuit is charging.
As a result, the PWR pins brought out on the port headers, etc, will now be at 4.2V instead of 5V, while plugged into USB. When on battery power, it will be whatever the battery supplies. You can still connect other types of batteries to the PWR pin to power the unit, as long as their voltage does not exceed 5V!
The on-board FTDI chip used for USB comms will be unpowered while running off batteries, to lower power consumption (it draws a few mA).
There is an on-board voltage divider connected to PWR, so that the ATmega can monitor the current battery voltage level. This is a high-impedance divider.

Oh, and since I got bored with just fixing things, I decided to throw a fresh bug into the mix ;)

The current boards have some incorrect silkscreen labels:

Juv 3 Silkscreen Errors

Just ignore ‘em. The P1 / P2 / P3 / P4 labels are the proper ones. FWIW: this was caused by panelizing this board in EAGLE without moving the labels out of the NAME layer. Probably a common (beginner’s?) mistake.

Anyway, I’ll get new boards made once my small initial batch runs out. Speaking of batches… I’ve now got lots of obsolete “JeeNode USB v2″ pcb’s :(

Comes with the territory, I guess: bugs in the atom world lead to REAL junk!

JeeLink, JeeNode

Demo remote LCD

In Hardware, Software on Apr 6, 2010 at 00:01

It’s hard for me to realize just how confusing all this Jee stuff can be, and it’s certainly good to be reminded of that once in a while. Not everything makes sense for people who aren’t immersed into all this every day.

I want to improve that. In fact, it’s the main reason I’ve been chasing around in search of a good forum + wiki setup. As it stands, I’m hesitant to start writing down lots of things and, eh… yes, documenting all this Jee stuff. But this will change. Promise.

For starters, some good news on the forum + wiki front: I’ve decided to standardize on Markdown as formatting language. It’s ancient (i.e. proven), it’s clean, and with just one or two extras it will be good enough for most of the things I need. The reason I’m bringing it up here, is that I’ve just finished converting all the wiki pages to Markdown, as well as 90% of the current Jee Labs documentation pages. The forum remains bbForum, but it has now been adjusted to use Markdown formatting as well. So has WordPress. In fact, this is the first weblog post written in Markdown (in Textmate, my favorite text editor).

Yeay for one set of conventions, and yeay again for simplicity!

Ok, back to the main topic of this post.

Here’s a demonstration on how to send a text string to a remote LCD via wireless JeeNodes. This is the hardware I’m going to use for that remote LCD node:

a JeeNode USB
an LCD Plug with 2×16 LCD display
one extension cable
plus a hookup to USB to power this whole thing

Dsc 1300

Ok let’s set up a simple demo sketch for the remote receiver end (code here):

Screen Shot 2010 04 05 at 20.09.58

Very simple, really: wait for an incoming packet and display the bytes as characters on the LCD. Plus some initialization code.

On the sender end, I’m using a JeeLink running the pre-loaded “RF12demo” sketch:

Dsc 1302

First step is to put the JeeLink in the right mode:

8b 4g 1i

That’s the 868 MHz band, group 4, node ID 1.

Now we can send a message to node 9, which is running the remoteLCD sketch, by sending a packet with the individual character codes to the JeeLink (the “9″ at the end is the destination node ID):

84,101,115,116,32,49,50,51,9s

The result:

Dsc 1305

Yippie. No wires. Magic! :)

Gravity Plugs

In Hardware on Apr 5, 2010 at 00:01

Ok, some panelized boards and components are starting to trickle in. Here’s the first production batch:

(no, I don’t reflow ‘em as a triangle, it just looks pretty this way…)

You’re looking at 15 brand new Gravity Plugs, i.e. 3-axis accelerometers. This is by far the smallest SMD chip ever soldered here at Jee Labs. The pads are too small for a soldering iron, even with a 0.4 mm tip.

Out of a panel of 20, some 18 appear to be working properly, but I did have to wick away some solder (i.e. fix solder bridges) to get several of these units working.

I’ll be adding this and a few other new plugs to the shop in the next few days.

Now, if I only had some time to play with these sensors…

Stencil Jigs

In Hardware on Apr 4, 2010 at 00:01

Ok, I’ve prepared a couple more Stencil Jigs for applying solder paste:

Here’s one in more detail:

Basic idea is that a couple of scrap PCB pieces are hot-glued to an A5-sized piece of foam board to keep the panel in a fixed spot. Then add the stencil and fix it to the jig in exactly the right spot.

The placement of components is still a manual task, and quite a precision job for some of the latest boards, but by now my daughter and I are starting to get quite good at it – yep, it’s become a family thing :)

The new jigs will speed up production of the ever-growing Jee Labs collection of JeePlugs and other boards!

After-burner

In AVR, Hardware on Apr 3, 2010 at 00:01

To reply to a comment posted yesterday, this is the contraption I use to re-flash a JeeNode or JeeLink after the fact via its ISP connector:

It has two diodes, dropping the incoming 5V power from the programmer to around 3.8V – this turns out to be needed in the case of JeeLinks, which has the VCC pin on the ISP header connected to 5V instead of the 3.3V driving the ATmega. The high voltage was causing problems with logic signal levels.

The other component on the board is a 100 µF capacitor, to reduce voltage fluctuations (it.s probably superfluous, I added it while debugging the setup).

Here’s this “after burner” in action:

The long pins are at an angle, because that way they can be gently pressed into the holes and they will stay there during programming.

Like most hacks, it looks awful, but it works pretty well!

New stencil is in

In Hardware on Apr 1, 2010 at 00:01

Just received the new solder paste stencil from Pololu, it’s laser-cut from 3 mil mylar sheet:

Great, once all the parts are in I can try out the new JeeNode USB v3 boards and start “baking” a couple!

Improved carrier board

In Hardware on Mar 28, 2010 at 00:01

Two weeks ago, I posted a note about a new enclosure and carrier board design to mount a JeeNode inside.

This led to several (virtual) experiments, to figure out how it would work out in different usage scenarios. One of the main problems remaining was that the design was not suited for a JeeNode USB, because the USB connector would have been inside the case – not perfect…

Here’s an improved design, which has been sent off to create a first prototype:

Screen shot 2010-03-27 at 21.23.13.png

The main change is that this allows using either a JeeNode with FTDI connector or a JeeNode USB. This was accomplished by moving the connectors around a bit, which urned out to be fairly tricky due to the huge number of interconnections.

The new trick is that this carrier board can now be used with two different JeeNode orientations. By attaching it one way, the FTDI or USB connector will end up inside the box, while turning it around 180° will put those connectors on the left side, almost sticking out. Just right to access it through a cutout.

Two other improvements over the previous design are that the carrier board includes connectors positioned in such a way that they will accept a Room Board, and the presence of an extra FTDI connector.

As before the bottom row of five 6-pin headers gives access to all signals of the JeeNode. Plugs can be attached in many different ways, supporting lots of combinations, with room for a variety of other components.

Battery level on JeeNode USB

In Hardware on Mar 26, 2010 at 00:01

The new JeeNode USB v3 includes a resistor divider to track the voltage level before the voltage regulator. This signal is connected to the otherwise-unused A6 input of the ATmega328 SMD chip.

Here’s a little sketch to see what it does:

Screen shot 2010-03-24 at 01.02.16.png

In prose: read out analog pin 6 once a second, and broadcast the measured value as wireless data packet on netgroup 2. The readings are also sent to the serial port.

Since a 1:2 voltage divider is used, the full-scale of the ADC (i.e. 3.3V in) is 6.6V, a value which can never be reached on the JeeNode USB. The map() function is used to scale this back to an integer in the range 0..660, i.e. hundredths of a volt.

Here is the serial output while connected:

Screen shot 2010-03-24 at 01.04.19.png

This is exactly as expected: the LiPo charger outputs 4.2 Volt when no battery is connected, which then goes into the on-board voltage regulator.

Here’s the serial output when a fully charged LiPo battery is connected (still plugged into USB):

Screen shot 2010-03-24 at 01.04.36.png

Again as expected: the battery pulls down the voltage slightly to 4.17 Volt.

But the interesting bit of course is when unplugging the USB cable. That’s why the RF part was included in this example: we can’t use the serial port anymore, and have to pick up the packets with a second JeeNode or JeeLink.

Sample output:

Screen shot 2010-03-24 at 00.52.51.png

That’s two bytes in each packet, forming a little-endian 16-bit int. The corresponding value is 161 + 256 * 1 = 417. The battery is still charged, so we’re still getting the same 4.17 Volt readout.

By leaving this sketch running on the LiPo battery for a while, it will slowly discharge. Output after one hour:

Screen shot 2010-03-24 at 01.27.15.png

Not much difference: 4.16 Volt.

Here’s a different LiPo battery which has been lying around unused for several months:

Screen shot 2010-03-24 at 01.24.23.png

Still a very respectable 126 + 256 * 1, i.e. 3.82 Volt!

So there you go. The node can run off a LiPo battery, and track its charge state. This could be used to power down the node when the voltage becomes critically low – perhaps 3V or so. LiPo’s don’t like being run down completely, and this is how a node can avoid doing so.

You may be wondering why the voltage readings were not immediately stable on startup, as seen in the first two output screens. Even if restarted, this same behavior will be observed, i.e. even if there was no power dip.

I think this is due to the fact that two very high impedance 1 MΩ resistors are being used for the voltage divider. These cannot supply a lot of current, which means the input charge for the ADC’s sample-and-hold isn’t being built up quickly enough. This will probably happen each time the ADC is switched over from another channel.

But there is a good reason for this: with 1 MΩ resistors, the leakage from this voltage divider is only 2 µA. For a battery-powered application, where every constant current drain affects its total lifetime, this matters.

▶ View 10 Comments

Heading Board

In Hardware, Software on Mar 24, 2010 at 00:01

Another new plug: the Heading Board.

This one is a pretty odd combination: a 2-axis compass, a barometric pressure sensor, and a thermometer:

It’s based on the HDPM01 module by HopeRF, and the board underneath is just to re-route the pins to the proper headers. As you can see, it barely fits.

Note that this board requires two port headers and sits on top of a JeeNode in the same way as a Room Board. This is necessary, even though the sensor uses I2C, because it also needs two more signal lines: a XCLR control signal, and a 32 KHz clock, i.e. 4 I/I pins in all.

The clock signal is tied to the IRQ line, because this is also the OC2B timer 2 output. So this board ties up timer 2 to generate a 32800 Hz clock, and it interferes with using the IRQ pin (which is shared by all port headers). Furthermore, one of the AIO pins is unused. So it’s a slightly odd fit for the JeeNode, really. Oh, well… soit.

Now let’s try it out.

There’s a new HeadingClass in the Ports library, which handles all the basic logic to access this board.

Here’s the heading_demo.pde sketch to read out the temperature and pressure sensor:

Screen shot 2010-03-22 at 23.58.36.png

Very simple stuff, given that most of the code is in the HeadingPort class.

Sample output:

Screen shot 2010-03-22 at 23.58.24.png

I’m not convinced of the accuracy of these sensors. Both the temperature and the pressure values vary a bit, and differ about 0.5% from the readings I see on the Pressure Plug.

Tomorrow, you’ll see why this is called a Heading Board!

JeeLink

Ready to Link!

In Hardware on Mar 23, 2010 at 00:01

Today, a fresh batch of JeeLinks came in:

All ready to go (and, no, you don’t get to pick the antenna color of these units…).

Got several bits and pieces in today, which means I’ve been able to fulfill most of the pending orders – at last!

One other item worth mentioning is that I finally have the black mini-breadboards in stock:

The delay (since last December!) was in the end all due to my own negligence – I had forgotten to fill in a form to supply more details about the contents of the package which was being held at customs. Doh.

Lots of new plugs to finish, several other new items, and yet more boards I’m going to try out. Plus a couple of days reserved for non-JeeLabs activities later this week.

It’s going be be a busy end of March!

Gravity Plug

In Hardware, Software on Mar 22, 2010 at 00:01

The plug story continues…

The Gravity Plug contains a 3-axis accelerometer with 2..8g settable range:

As before, a new GravityPlug class has been added to the Ports library, along with a “gravity_demo” sketch to illustrate its use:

Screen shot 2010-03-19 at 13.08.33.png

Sample output:

Screen shot 2010-03-19 at 13.26.31.png

Values are X, Y, and Z, in that order.

I’m not sure about the high bit readout with the current code, maybe this needs some tweaking to get the ranges right, but you can see the effect of moving the plug around a bit.

The Y axis wraparound may be due to the chip not being completely flat on the board. This is a minute chip, which can’t be soldered by hand because the pads are too small and on the bottom side of the chip. I applied solder paste manually and then used the reflow grill – but even that is tricky, it’s very difficult to get an even-yet-small amount of paste on there! A solder paste stencil will no doubt solve this.

Lux Plug

In Hardware, Software on Mar 21, 2010 at 00:01

Here’s a second simple plug which works:

(the silkscreen markings are incorrect, this plug responds to I2C addresses 0×29, 0×39, or 0×49)

The Lux Plug measures incident light intensity which can be converted to a 16-bit Lux value in the range 1 .. 65535. A 16x multiplier can be used to increase the dynamic range to 20 bits.

A class named – surprise! – “LuxPlug” has been added to the Ports library, as well as a “lux_demo” sketch:

Screen shot 2010-03-19 at 01.31.30.png

Sample output:

Screen shot 2010-03-19 at 01.29.01.png

The two first values are the raw readings from two internal sensors. The TAOS datasheet explains how to derive the Lux value from them. This calculation is included as the “calcLux” member in the class (to be called after getData() has obtained a reading).

Onwards!

Dimmer Plug

In Hardware, Software on Mar 20, 2010 at 00:01

Looks like the Dimmer Plug is working as intended – yippie!

I connected a LED with series resistor between the L1 output and PWR (i.e. 5V in this case).

Added a new “DimmerPlug” support class in the Ports library, and a “dimmer_demo” example sketch:

Screen shot 2010-03-18 at 22.42.06.png

The result is a LED which blinks briefly 4 times per second, with increasing intensity. When the maximum intensity has been reached, it restarts from off. Note that the blinking and brightness control is done by the plug – the sketch just keeps feeding it new settings.

There are 16 independent channels, the outputs can be either open-collector or totem-pole, and by adding a MOSFET, transistor, or darlington stage, much larger currents and voltages can be controlled by this plug.

Another fun application would be to connect up to 5 RGB LEDs, for full 24-bit color control of each one of them.

The above code has been added to the Ports library.

Meet the JeeNode USB v3

In AVR, Hardware on Mar 19, 2010 at 00:01

Just got a couple of new boards back (this was an experiment, expediting some of the boards to get them several days ahead of the rest of this prototype batch).

Meet the new JeeNode USB v3 (this unit was soldered by hand – phew!):

As you may know, the main reason for this revision was to resolve a problem with the voltage regulator, but since I had to rework the design anyway I also added a LiPo charge circuit.

The good news is that everything seems to work fine so far. There are some cosmetic problems with this board, but no show stoppers.

And of course the big deal is being able to hook up a Lithium Polymer (LiPo) battery:

There is an extra LED in the corner, left of the USB jack, which will be orange (once I get them in). It lights up while charging. The charge current is max 280 mA, so this board won’t draw more than that from USB.

Without LiPo connected, the current still goes through the charge circuit, so another major change is that the PWR pin on all the headers of this board never carries more than 4.2V – don’t use the JeeNode USB if you need 5V in your circuit (use a JeeNode + USB-BUB if you really need the 5V).

Two BIG honking warnings, since LiPo batteries can be quite dangerous: one is that they need to be charged with the proper circuitry, such as on this new board, so don’t hook ‘em up any other way. The other issue to keep in mind at all times, is that LiPo’s can discharge at a very high rate! That “20C” label above means that this particular little battery is rated to sustain a discharge @ 20 x 450 mA = 9 amps!

You can probably cause a fire with those wires shown above, by simply shorting out a fully charged battery!

And you will probably fry the circuit and vaporize PCB traces by connecting the battery in reverse!

I’m exploring some options to reduce these risks. Hard-wiring the LiPo would be one way to reduce the chance of loose wires shorting out something. Perhaps a small custom PCB glued to the battery, with a fuse or polyfuse and a switch, wrapped in heat-shrink tubing? The trouble is that battery sizes and capacities vary greatly.

Some first tests w.r.t. power consumption: it looks like the JeeNode USB v3 will draw about 120 µA when in sleep mode. With the above 450 mAh battery, it would last up to 5 months without recharging (and without doing anything useful, such as turning on the radio module once in a while). There’s probably still some room for improvement here, but for now it’ll have to do.

FWIW, I’m going to hand-assemble a few of these boards in the coming weeks, but unfortunately that means there won’t be many v3 units available in the shop, initially. I’m also having solder paste stencils made up right now. Once these are in, the new boards will be much easier to assemble – using the reflow grill that gets a lot of work done here at Jee Labs.

JeeNode, JeeSMD

Meet the JeeSMD kit

In AVR, Hardware on Mar 18, 2010 at 00:01

Meet the new kid kit in the Jee family – the JeeSMD !

At a glance:

Same pinout as a JeeNode – same 4 port headers, same PWR/SER/I2C, same SPI/ISP
No wireless, no FTDI, just an ATmega328 – all SMD (32-TQFP, SOT-23, and 0603)
Two extra pins on the right side (allocated to the RFM12B module on JeeNodes)
Has a 3.3V regulator, a 16 MHz resonator, and four passive components

What’s the point? Well, it’s going to be made available as an SMD kit, and it’s going to be low-cost. If you don’t care about wireless or FTDI, then this is a convenient and compact way to hook up some Jee Labs plugs.

Of course, all the other stuff fits as before, including the Proto Board, for example:

Here’s the board in more detail:

(don’t look too closely at this prototype PCB – there are some silly cosmetic mistakes…)

There are some trade-offs w.r.t. JeeNodes:

No FTDI on board – you have to either add the equivalent connections yourself via the left and right headers plus a 0.1µF cap, or use ISP for flashing the ATmega328 chip
No wireless, so this isn’t a “node” in the usual sense – just a tiny Arduino’ish board
It’s all SMD, so if you want to practice soldering SMD by hand – this is one way to get started!

I’ve got a few boards for people who want to get their hands on them. The kits will be ready in about a week.

Now the JeeSMD kit needs a detailed set of instructions and close-up shots on how to assemble and start using it – more work to do!

JeeLink

JeeNodes on Bifferboard

In Hardware, Software on Mar 17, 2010 at 00:01

The Bifferboard described yesterday is a bundle of fun (well, for geeks like me anyway…).

But this weblog is about physical computing, not just embedded hardware or software.

So let’s hook up a JeeLink!

The first hurdle is a silly one: my Bifferboard only has a single USB slot, and it needs the USB stick to run off. So for this experiment I added an unpowered USB hub:

Did I mention that this is a standard Debian setup? Here’s the kernel log with the JeeLink plugged in:

Screen shot 2010-03-15 at 12.45.30.png

Note how it recognizes the FTDI serial link without having to install or configure anything. Perfect!

The other factoid which can be gleaned from this info is that it took about 36 seconds from the start of the kernel boot to this stage. From this, I’d estimate a Bifferboard with JeeMon to boot up in well under 60 seconds.

To verify that the USB recognition is really complete, I used this little test in “try/application.tcl”:

And sure enough, it recognizes and identifies the USB device:

Let’s try one more thing – by changing try/application.tcl to this code:

Screen shot 2010-03-15 at 13.01.48.png

Sample output:

Screen shot 2010-03-15 at 13.01.23.png

That’s a Bifferboard receiving JeeNode packets via a JeeLink – yippie!

I can now go back to developing JeeMon further on my desktop machine, in the knowledge that software updates are one little restart away (due to JeeMon’s built-in self-updating over internet) and that apps will probably work as is on a Bifferboard. Long live platform independence!

JeeMon

JeeMon on Bifferboard

In Hardware, Software on Mar 16, 2010 at 00:01

The Bifferboard is an interesting computer which was mentioned on the forum a while back:

It has an ethernet jack, and all it needs is 5V power and a USB stick with Linux on it. You can get an impression of its diminutive size with the JeeLink next to it.

So let’s try it out!

The Bifferboard will work with several different Linux distributions. I decided to use Debian because it’s stable, easy to manage, and has lots of packages ready to install. And because I’m very familiar with it.

Setting up Linux is fairly easy, using these instructions. The hardest part has been done and is fully automated with two scripts: formatting and creating a USB stick to contain a complete Debian 5 (lenny) system. This needs to be done from Linux on your desktop machine, I used Ubuntu.

The only tricky part is that a matching kernel needs to be flashed onto the Bifferboard itself. My older unit has 1 Mb flash, newer units have 8 Mb flash. There are two ways to flash the unit: via a special serial console cable and via a direct ethernet cross-over connection. I tried the ethernet thing, but couldn’t get it to work, and since I had already hooked up a serial line for debugging, I ended up using that method.

The serial port is available as 3.3V I/O signals, but it requires soldering an extra header to the Bifferboard:

(only 3 lines are needed: RX / TX / GND, but I’m swimming in 6-pin connectors around here…)

Those pins are then tied to a USB-BUB, which in turn is hooked up to my Linux setup. The connection is 115200 baud, and shows the kernel boot log on startup.

Once the reflashing is done and the USB stick has been inserted, you end up with a standard Debian setup, which can be accessed over the network via SSH:

Screen shot 2010-03-15 at 12.19.06.png

If there is interest, I can set up a wiki page with more details about all this.

Now the fun part: the Bifferboard is x86 compatible, so it will run the standard JeeMon build for 32-bit Linux!

Screen shot 2010-03-15 at 12.16.03.png

There’s about 25 Mb of usable RAM (no swap space), which should be plenty to run just about anything in JeeMon with some other processes alongside it.

The one thing to keep in mind, is that this is a low-power board. It’s equivalent to a 486SX, i.e no hardware FPU, and it looks like it runs about 100 times slower than my (modern) Mac. But hey, you do get something in return: an very small unit and a power consumption of only 1.5 .. 2.5 watt!

Carrier Board

In Hardware on Mar 14, 2010 at 00:01

Yesterday’s enclosure has started a new ball rolling…

I’ve decided to support a mix of plugs with room for prototyping. A first mockup:

This will be made possible by a new Carrier Board with tons of different ways to connect to:

Ports 1 and 4 each have four positions for adding plugs. All connected in parallel, so you can hook up more than one if you’re using a bus such as I2C on that port. Note the big dots, identifying the PWR pins for orientation.

Ports 2 and 3 can be plugged in, but their pins are also brought out to a series of 6-pin headers in the bottom right. These 18 pins bring out everything else, including full SPI, hardware I2C, and the serial I/O lines.

Lastly, the SPI/ISP and the PWR/SER/I2C connectors from the JeeNode have been duplicated.

Note that you can also ignore all that plug stuff and just insert your own board into the entire bottom row, using five 6-pin headers. That gives you access to all the pins on a JeeNode. Here’s a board I’m going to try out:

There’s a split down that board, to allowing breaking off and using either side independently. The left side is essentially a dual JeePlug and will fit in all the 2-port positions on the Carrier Board.

These boards will be included in the next round of PCBs. We’re back to the “Patience, grasshopper!” part…

JeeNode enclosure

In Hardware on Mar 13, 2010 at 00:01

At last! – Here’s a fantastic enclosure for the JeeNode:

The plugs are just one possible orientation, they will also fit sideways, i.e. stacked on their side like the JeeNode in there. No screws, no glue – this just needs a PCB of the right size – or as in this case: perf-board with some male headers to connect to the JeeNode ports.

The whole box clicks together with the other side, which has exactly the same shape:

Available in light gray and in black from Dick Best in the Netherlands.

I’ll look into adding this enclosure option to the shop.

Home automation, JeeNode, X10

Xanura CTX15

In Hardware, Software on Mar 9, 2010 at 00:01

Another popular home automation module is the Xanura CTX15:

That’s a live 220V power-line connection in the top right corner!

I’ve connected the CTX15 module through a UART Plug, with a 4.7 kΩ resistor in series with the RX signal (yellow from CTX15). This is because the signal swings up to 5V, whereas the UART plug only accepts 3.3V voltage levels. The module is powered from the PWR pin, which on a JeeNode USB carries 5V.

The CTX15 is a bi-directional interface, it can send as well as receive A10-type power-line commands (a superset of X10). The trouble is that it needs to be polled to read out what has been received and buffered so far.

Here’s a sketch which takes care of that:

Screen shot 2010-03-08 at 12.08.53.png

And here’s some sample output:

Screen shot 2010-03-08 at 12.08.40.png

As a test, I powered up yesterday’s XM10E test setup as well, to send out on and off commands to unit A.1 every 3 seconds. As you can see with the CTX being read out every 5 seconds, multiple received packets will sometimes be combined and returned as one reply.

New board summary

In Hardware on Mar 7, 2010 at 00:01

Here is a summary of the boards which are currently being, eh … prepared? etched? sprayed? drilled?

First of all, a new JeeNode USB with improved voltage regulator setup:

Screen shot 2010-03-07 at 00.53.02.png

The Dimmer Plug contains a 16-channel LED dimmer with independent PWM brightness control, using I2C:

Screen shot 2010-03-07 at 00.53.25.png

The Lux Plug contains a sensitive light meter with high dynamic range, using I2C:

Screen shot 2010-03-07 at 00.53.36.png

The Gravity Plug contains a 3-axis accelerometer with 2..8G range, using I2C:

Screen shot 2010-03-07 at 00.53.45.png

The Proximity Plug connects up to 8 contacts as capacitive sensing switches, using I2C:

Screen shot 2010-03-07 at 00.53.58.png

The Input Plug supports 16 inputs, as either analog or digital inputs (not I2C):

Screen shot 2010-03-07 at 00.54.09.png

And three more boards. One of them is a mystery sensor – I’ve masked out its name for now :)

Screen shot 2010-03-07 at 00.56.00.png

The other two boards are experimental boards of a different kind – I’ll describe ‘em when they work.

I’ve started setting up documentation pages for these new PCBs, but so far that’s just the EAGLE files. Will add more info in the coming week – with luck they’ll be back here for testing within the next 10 days.

I guess the best tactic for me now, is to just forget about this and work on some other stuff for a while. Drat.

Patience, patience, patience. I hope it pays off!

▶ View 9 Comments

Energy

Catching sun rays

In Hardware on Mar 6, 2010 at 00:01

A few days ago, this country went through a curious ritual…

In the Netherlands, there is a subsidy as encouragement for people to place solar panels on their roof tops.

Screen shot 2010-03-05 at 23.03.57.png

The system works as follows:

You’re considering setting up a couple of photovoltaic solar panels. You quickly find out that the government is handing out money for this. Yippie … and then you get into the rules and regulations bit:

You can’t apply for the subsidy before March 1st.
There is a limited amound of funding.
On the day when submissions exceed funding … it’s roulette day!
… the remaining subsidies are assigned at random.

The result?

On March 1st – everyone submits their proposal for solar energy.

On March 2nd – sorry folks, we’re all sold out, try again next year!

It turns out that some 17,000 people signed up for 2010. And about 5,000 of them will win that lottery ticket.

Tell me, please, what’s the meaning of the word “encouragement” again?

Anyway, so much for silly incentives. The reason I’m posting this is that we’ve been looking into solar energy and have decided to install 18..20 solar panels on our roof. It’s relatively well-positioned, and even the cabling in the house turns out to be very easily adapted for it. And yes, I’m one of the 17,000 who signed up for the Dutch Solar Casino. Except that we’re going to go ahead regardless of the outcome (3 months from now!).

The numbers are much better than I expected:

With 18..20 panels, we can fill the smallest half of our roof
Modern panels can produce about 3600 “Watt peak” total
Heading and tilt are such that we’re still at ≈ 90% of optimal
Estimated yearly output will be 2500 kWh, 20% more than we need
Unused power is fed to the grid and billed at the same rate, as credit
In other words, the electricity grid will become a – very – big capacitor for us :)

All in all, I think it’s a good deal. There will always be better deals in the future, but this is fine.

As for buying more stuff to save and join the green hype: panels also need to be produced and shipped. The energy needed to do so appears to be less than what those panels produce in their first 18 months. So the electricity in the next 20..30 years after that is free, green, and effortless.

I was very surprised to find out that solar energy is practical at 52° latitude, but it really is.

Sooo… apart from seasonal swings and energy storage, Jee Labs will be “slightly off the grid” later in 2010!

JeeMon

JeeMon goes embedded

In Hardware, Software on Mar 5, 2010 at 00:01

Testing out a new setup … I started by launching the JeeMon runtime executable as follows:

Then I went back to my Mac and opened a browser window:

Screen shot 2010-03-02 at 15.56.12.png

It works! You’re looking at a little web server running on a tiny Technologic TS-7500 board:

ARM based, 64 Mb RAM, µSD card socket on board, running Debian (lenny). It’s not very high powered, but in return it only uses 400 mA @ 5V, i.e. it can run off USB power.

I haven’t yet figured out how to get the FTDI USB serial driver on there, but once that’s solved this little unit will be able to act as host for USB-connected JeeNodes or JeeLinks.

The RAM and storage is more than sufficient to run even a very elaborate JeeMon setup, I expect.

This might be an interesting low-end always-on home sensor & automation system!

JeeNode, Reflow

Fabrications

In Hardware on Feb 24, 2010 at 00:01

Several hours of work, and this sort of stuff is born… 16 new JeeNode USB’s:

It looks pretty, but I’m not going to show you the high resolution picture… even on this one you can probably spot one or two problems :)

The fact is that hand-assembly of SMD takes a lot of patience. By now, I think it’s absolutely doable for one-offs, such as to assemble one board with some parts. But larger quantities do tend to bring out the trouble spots.

Usually, on a run this size, I’ll expect to see 3 or 4 boards not working right away, and ending up with perhaps one board which I can’t fix quickly. I’ve got a box with a bunch of units by now, which don’t seem to want to be cured. Oh well, their loss – that means they get to wither away in a dark box, waiting for better times :)

New Dimmer Plug

In Hardware on Feb 17, 2010 at 00:01

One last plug… who knows, with a bit of luck, some of them might just work on first try?

The Dimmer Plug controls up to 16 LEDs or other lamps, and is based on the PCA9635 chip:

Screen shot 2010-02-16 at 21.29.21.png

It’s driven from the I2C bus, with a couple of jumpers to allow daisy-chaining up to 8 plugs on a single port:

Screen shot 2010-02-16 at 21.46.19.png

Here’s an extract of the datasheet, showing the different ways to hook up LEDs:

Screen shot 2010-02-16 at 02.04.23.png

Basically, you can drive one LED directly per pin, or add a transistor to drive many more in parallel or in series. The chip just does the PWM part, with various blinking options and more, all from an I2C bus.

To drive high-power displays, the outputs can be tied to darlington arrays such as the ULN2803, or to MOSFETs. There are no drivers on the plug because there are too many different usage scenarios. It all depends!

Originally, I wanted to make this plug also fit on a the back of a display such as this one:

That pressure plug on the photo was added for size comparison. It’s the same size as this Dimmer Plug, which happens to allow daisy-chaining two such displays tightly next to each other when you include the headers.

But I can’t make it fit without widening the plug and mounting components on both sides. So I’ll leave it as is – it could still be mounted on the back by adding lots of little wires and 16 resistors, but it will take some more work. Or one could add a little board to sit in between, with 16 resistors and pins to stick into the 3×6 headers.

Now I’ll stop with this plug madness. Need to finalize all the layouts and traces, send the designs off, and then the waiting starts. Luckily, there’s still enough other stuff left to do around here :)

Update – there are some errors in the schematic. I’ll fix them before sending off this board.

New Input Plug

In Hardware on Feb 16, 2010 at 00:01

The plug rage continues. Sixteen inputs, analog and digital in any mix:

Screen shot 2010-02-15 at 12.58.04.png

I haven’t routed the connections yet so the layout and dimensions might still need to change.

This plug is an experiment. It does not use I2C, so it will need a dedicated port. The trick is that an on-board ATTiny45 is used to decode a pulse train of four pin selection bits from just the DIO pin.

Here’s the schematic:

Screen shot 2010-02-15 at 13.08.55.png

The 16 inputs are multiplexed into the AIO pin. By defining this as an analog input, you can have up to 16 analog pins, using the 10-bit ADC built into the ATmega. But defining AIO as a digital input, you can use it as a digital pin. Even works with pull-up, but the pull-up will only be active as long as the same input remains selected. Unselected inputs return to a high-impedance state.

Needs some more work though, including some firmware for the ATtiny.

New Proximity Plug

In Hardware on Feb 15, 2010 at 00:01

Yet another plug! This time it’s a proximity capacitive sensor based on the MPR084:

Screen shot 2010-02-14 at 22.01.08.png

This one has 8 inputs which can be connected to various surfaces to create capacitive touch sensors. There’s also a pin for a piezo sound unit to produce key clicks.

Slightly more elaborate schematic this time, with an extra 8-resistor array for pull-up:

Screen shot 2010-02-14 at 12.05.27.png

Yet again: connected via I2C, and supports no more than 3.6V as power source. There’s a solder jumper to choose between two I2C addresses, so you can use two of these for a total of 16 inputs on one port (or Plug Shield).

Haven’t tried this chip out yet, but it will be fun to see what it can do – once I get some prototype boards ready.

New Gravity Plug

In Hardware on Feb 14, 2010 at 00:01

Another plug coming up – based on the BMA020 (BMA120?) 3-axis accelerometer:

Screen shot 2010-02-12 at 23.07.28.png

Again an awfully tiny chip, with even smaller pads. This chip has a programmable ±2g/4g/8g range with 10 bit resolution. As with yesterday’s plug, this chip communicates over I2C and supports up to 3.6V.

The schematic is obviously very simple again:

Screen shot 2010-02-12 at 23.07.59.png

The Gravity Plug will also work with an Arduino, through the Plug Shield.

It’ll take at least a few weeks before I can test these new plugs and make them available.

Onwards!

New Lux Plug

In Hardware on Feb 13, 2010 at 00:01

There’s a new plug in the works, with a really neat TSL2561 light sensor:

Screen shot 2010-02-12 at 21.06.49.png

The chip is even smaller than what I’ve been working with until now. The nice thing about the TSL2561 is that it has six orders of magnitude dynamic range and that it’s interfaced via I2C.

The JeePlug port headers are in fact perfect for sensor chips like these, which often only tolerate up to 3.6V:

Screen shot 2010-02-12 at 21.08.28.png

The Lux Plug will also work with an Arduino, through the Plug Shield.

Stay tuned. There’s more coming…

Improved bracket

In Hardware on Feb 12, 2010 at 00:01

Encouraged by some comments on yesterday’s post, I printed the same bracket again, laying on its side:

The horizontal base comes out ok (I cleaned up the hole):

Interestingly, the top of the bracket isn’t filled in, which is actually better:

The sides look much better as well:

(the Skeinforge settings aren’t perfect yet, layers could be mashed smoother together)

But wow – what a difference this makes! Thanks for the tip!

Here’s another object, a Geneva Wheel from Thingiverse:

Turning is not very smooth, had to cut off some plastic from the round shafts, but hey: it works!

PS. Don’t worry, I’m working most of my time on JeeNode stuff, hardware and software that is… ;)

JeeNode bracket experiment

In Hardware on Feb 11, 2010 at 00:01

I just had to try making a little mounting bracket for JeeNodes…

Here’s the design:

Screen shot 2010-02-08 at 11.13.51.png

The design dimensions are 25 x 12 x 10.5 mm. It was created with OpenSCAD, which takes a description of the object and generates the solid model shown above:

Screen shot 2010-02-08 at 11.14.06.png

Does it work? Can it be printed? Can it be used? Yeah, sort of…

Works for JeePlugs too, since all the boards have the same 21.1 mm width:

Took me three tries to get the sizes and the little ridge right (the middle one):

Pretty ugly stuff, when seen up close. But hey, that’s what pioneering looks like!

The ridge which holds the board doesn’t come out very clearly – the features are not yet a match for what the JeeCake 3D printer can do (or should it be the other way around?):

But despite appearances, this bracket is already surprisingly functional. Apart from the awful surface and rough shape, it’s a springy and very robust little piece of ABS plastic. It could easily be screwed down, and it would hold the board quite well.

Fascinating, it’ll be fun to see how this evolves over the next few years.

CNC, JeeNode

Wireless CupCake

In Hardware on Feb 8, 2010 at 00:01

JeeCake, the CupCake 3D printer here, is an interesting mix of machine, electronics, and software.

The RepRap Motherboard is the main on-board controller, based on an ATmega644. It drives 3 stepper motors, communicates with the Extruder board, and talks to a desktop computer via its FTDI interface and a USB cable.

On the PC side (which can be Windows, Mac, or Linux), there is a Processing-/Arduino-like package called ReplicatorG to control the machine. It takes G-code, which is not related to Google in any way, but rather an ancient CNC control language from the 60′s.

ReplicatorG then converts this to a binary RepRap 3G protocol, as documented here and then uses that to drive the CupCake. Everything from moving the axes, adjusting the nozzle temperature, controlling the extruder motor, to writing settings in the machine’s EEPROM memory.

The neat part is that the v1.2 motherboard has an SD card adapter on board, and that the CupCake can run unattended by getting its detailed build instructions from files stored on an SD card.

Except for one little detail: there are no controls or displays on the CupCake, other than a few LEDs. This is not enough to select which file to print, adjust the zero position, or start a build. It looks like a new “Generation 4″ design is on the way, including an interface board with an LCD screen and some push buttons.

Right now, you have to connect the machine via USB, start everything up via ReplicatorG, and then you can yank the USB plug and it’ll happily continue printing what it started, right to the end (well, except that on Mac OS X 10.6, yanking USB cables can lead to kernel panics – looks like a serious bug in the FTDI USB driver).

Anyway, I don’t really care for controls, or even displays on the CupCake. All I want is some way to control a unit sitting on the other side of the room, or in a nearby room. It can be fairly noisy due to some sort of occasional wood panel resonance, and having it printing right next to me is not really my idea of fun.

Which is where JeeNodes come in: wouldn’t it be nice to be able to control the CupCake via wireless? The protocol is already perfectly suited for it, since it uses packets of max 32 bytes – well within the 66-byte limit of the RF12 driver. And if the object being printed is already on the SD card, then only a few packets need to be exchanged to get going. During printing, some status info could be sent back – again very low rate stuff, easily within the JeeNode’s wireless constraints.

Here’s the idea:

Hook up a JeeNode to take the place of the USB cable, and let it behave as a RecpicatorG control program.

The interface needs to swap RX and TX for this, and because the CupCake’s signal levels are at 5V, two 1 kΩ resistors need to be inserted to prevent excessive current. One more detail is that the power pin on the FTDI connector is not connected, since the motherboard is powered off its own PC supply. So a separate wire needs to be added to power the JeeNode off the ISP connector right under the FTDI connector:

The one wire not shown here is the ground wire, running from top right to bottom left on the other side of this little custom interface board.

It turns out that the motherboard is actually powered from the 5V standby supply pin, so it’s always powered, even when the power supply is in standby mode.

I’ve started writing some code on the PC/Mac side to control the CupCake without using ReplicatorG. Here’s some sample code in Tcl which works when connected directly through USB:

Screen shot 2010-02-07 at 15.05.08.png

And here’s the corresponding output:

Screen shot 2010-02-07 at 15.04.35.png

As you can see, it can access all sorts of status info, read the file names on the SD card, and control the machine. This is part of a larger project, the beginnings of which are now in the subversion code repository.

It takes a lot of work to make hookups like these work, because there are so many different bits and pieces (literally) involved. The next step is to see if the JeeNode can indeed communicate with – and control – the JeeCake, and then code needs to be written to replace the current direct-USB connection by a packet-based wireless hookup through a JeeLink + JeeNode.

Oh, and then I need to create some sort of little on-screen control panel to adjust the nozzle temperature, jog the Z axis up and down, pick a file to print, and start the print job! Not to mention making it robust and secure…

Arduino, JeePlug

Plug shield on Arduino Mega

In AVR, Hardware on Feb 7, 2010 at 00:01

The Plug Shield can also be used on an Arduino Mega:

Note the two extra wire jumpers, since the I2C interface is on pins 20 and 21 on the Mega board.

The above has an RTC plug and an LCD plug hooked up, so let’s to set up a simple clock with this – and use it to demonstrate the brand-new RTClib along the way:

Screen shot 2010-02-05 at 17.22.01.png

I’ve omitted the details of the Wire coding, but you can get the full sketch here.

Custom object

In Hardware on Feb 6, 2010 at 00:01

This is not what you might think it is:

I’ve been placing my headphone next to me on my desk for ages. There is of course never enough room on top, but plenty of spare room underneath:

So here’s my home-made headphone bracket:

Here’s the design, made with Sketchup:

Screen shot 2010-02-03 at 14.22.47.png

I just picked a “2″ in a suitable font, re-sized it, “drilled” some holes in the base, and then “printed” it.

Piece of JeeCake!

PS. Given that CNC and 3D printing is not really the main focus of this weblog, I’ve set up a page on the wiki.

Update – design files added to Thingiverse.

JeeNode USB v2 error!

In Hardware on Feb 3, 2010 at 00:01

Yikes… there is a major bug in the current JeeNode USB v2 board!

The on-board MCP1703 3.3V has been connected with Vin and Vout reversed!

The effect is that the +3V pins on all the port headers will have approx. 4.7V instead of the intended 3.3V. This in turn means that all plugs connected to these headers will have a higher voltage than should be.

The on-board logic is not powered by this regulator but gets its power from the 3.3V pin on the FTDI chip, so the JeeNode USB v2 itself works just fine (my weak excuse for why I didn’t catch this problem earlier…).

Here is the schematic – with the problem staring me in the face, now that I know about it:

Screen shot 2010-02-02 at 13.51.39.png

Here are the printed circuit board traces:

Screen shot 2010-02-02 at 14.39.16.png

And here is the board with the voltage regulator connected the wrong way around, as it has been shipped until yesterday, i.e. Feb 1st 2010:

If you have a faulty unit, there are a number of ways to fix this:

Send it back and I’ll fix the voltage regulator for you.
Remove the voltage regulator and add your own from a PWR pin to a +3V pin.
Unsolder and re-solder the VR flipped, as described below.

To reiterate: this bug only affects plugs connected to the JeeNode USB, not the JeeNode USB itself. If you don’t use the ports, or don’t mind having a higher voltage on the +3V pins, then you could just ignore the issue.

Here’s how I’ve fixed this on existing JeeNode USB’s, including ones still in stock. First, I used solder wick to remove the regulator (careful not to lift the pads):

JU2 no VR.png

The next step is to mount the VR back on its side. The pins which need to be exchanged are:

MCP flip.png

One way to do this, is to turn the VR on its side and solder pins 1 and 2 back on pads 1 and 3:

As last step, I added a thin wire from what used to be pad 2, to the pin now sticking out on top (was pad 3):

As I said, I’ll be happy to do all this fixing for you if you send me your JeeNode USB v2.

It ain’t pretty (real bugs never are) – but it’ll at least let you continue to use the JeeNode USB v2 as intended.

All JeeNode USB v2′s shipped from now on will have this fix, until an improved “v3″ is ready. As always, “new copper” (i.e. a new PCB) will take a few weeks – it’s at the top of my list to fix and resolve this for good.

With many thanks to castello for drawing my attention to this bug on the forum.

Room Board assembly

In Hardware on Feb 2, 2010 at 00:01

As announced recently, I’ve now added a full kit for the Room Board in the shop, containing:

The room board PCB.
SHT11 temperature + humidity sensor.
An LDR light sensor.
The ELV PIR motion sensor.
Two 6-pin male headers.

Here is the kit (oops, forgot the two 6-pin headers):

From top left to bottom right: PIR lens, PIR sensor, 3-pin header, SHT11, LDR, Room Board PCB, pre-assembled PIR sensor board.

The hardest part to solder is the SHT11 sensor. It has 10 gold pads on the side, of which only 8 are connected. Make sure you place the sensor in the right orientation. With the text on the pcb readable, the round part is pointing down:

Next, solder in the LDR light sensor. Be sure to place it in the LDR1 position:

The wires of the LDR may be a bit more difficult to solder than ordinary components, so be sure to use enough flux:

Next, we need to prepare the ELV PIR sensor board – the board itse;f already has all the SMD’s soldered on, just the PIR sensor itself.

Careful – do NOT touch the surface of the PIR sensor, as any traces of oil will reduce its sensitivity:

The sensor has to be pushed through the bottom side of the lens holder, into the board – from the non-component side:

Solder the three wires and snip them off. Don’t use too much solder or you’ll risk shorting out the pads with the nearby components:

Then turn the board around and click the fresnel lens onto the base (it has three different-sized notches):

Next, we need to connect the boards together:

The pins go through the room board and should be snipped off once soldered:

Almost there – the last step is to solder the two 6-pin male headers onto the room board. To hold them in the right position, I just push them into a JeeNode:

… then place the room board on top and solder both headers, all 12 pins. Leave the 8 holes on the side of the PCB free (these are for another type of PIR sensor):

That’s it – you’re done!

For more info on uploading the “rooms.pde” sketch firmware to the JeeNode, go back to the docs page.

RTC battery fix

In Hardware on Feb 1, 2010 at 00:01

I’ve been getting some email about the RTC Plugs not retaining their clock. It turns out that there is a problem:

The center contact of the battery “holder” is the PCB itself, and being gold-plated, I thought it’d be best to keep it as is.

The problem is that the solder mask layer can be slightly thicker than the gold-plated pad, causing the battery to not make contact – despite the pressure of the metal clip.

This can be fixed by adding a small dab of solder:

This will cause the coin cell to press more against both contacts, so a good connection is virtually guaranteed.

Needless to say, I’ve updated all RTC plugs here and will ship this improved version from now on.

Room node – last

In Hardware on Jan 31, 2010 at 00:01

Here’s a last post about mounting a room node in a ceiling corner.

The enclosure and support struts were cut out of an A4 sheet of foam board, according to the template PDF on the wiki:

Unfortunately, the JeeNode doesn’t quite fit with the FTDI pins sticking out, so I had to cut away a bit of the support material. As you can see, everything is glued together with hot glue, even the room board. The battery pack is stuck on the top part with double-side tape.

The motion sensor sticks out in the middle, at the cross-point of two diagonals on that slanted surface, to be precise. The holes for the LDR and SHT11 have not yet been made:

Here’s how everything sits in the completed unit:

There’s still some leeway to move the JeeNode up a notch, but I’ll leave it at that.

Enough of all this mechanical tinkering!

Room node mount

In Hardware on Jan 30, 2010 at 00:01

It’s time to finish that room node ceiling mount, at least the prototype.

At first, I thought I’d use the new 3D printer for some sort of nifty mounting bracket:

Screen shot 2010-01-29 at 20.48.04.png

… but it turns out that there’ a much simpler solution:

This pushes the top of the mount against the ceiling, right under the battery pack, which is by far the heaviest part anyway:

I don’t like the look of the paper sheet wrapped around the foamboard, but whatever – it works!

There’s a new wiki page with the description and a PDF with the outline of the pieces required to make a ceiling mount. Haven’t quite accounted for the thickness of the foam, since it depends a bit on which way it’s cut and folded, but the PDF should be usable as starting point.

One more 3D post

In Hardware on Jan 29, 2010 at 00:01

Ok, one last post on the CupCake CNC trials before I get back to JeeNode stuff.

The raft is now very solidly stuck to the base:

This thing really sticks well, with plastic pushed down into the criss-cross grooves of the acrylic base. The trick is to place a plain paper sheet between the extruder head and the base, and to lower the Z axis until the paper slides away with just a tad of friction.

Unfortunately, the next problem comes up – as seen in this first Geneva Wheel trial:

It turns out that the next layer of the raft doesn’t stick well to the first one. I solved this by raising the default 230° setting to 240° for the raft.

Another serious problem was that there is a lot of plastic on the right end of the raft as the print nozzle paused (!) on each turn. And the second layer of the raft doesn’t extend all the way to the end. This was solved by adding three noise-suppressing 0.1 µF caps to the extruder motor and disconnecting all the end-stop optocouplers.

The object itself seems to come out fairly well, though there were some blobs of plastic around the nozzle during printing which clearly interfered with the X-Y motion at times.

Here are over a dozen more parts, printed using black ABS for a change:

These all came out ok, but note that even these small parts take 10..15 minutes to print – each.

The biggest remaining problem is “warping” – it’s causing over half my trials to fail:

This part failed to build (should have been 20 mm high), it slowly came off the base and started interfering more and more with the extruder nozzle. At some point the nozzle got stuck in fact. Note how the thickness of the part is completely uneven. This is caused by the ABS cooling down and shrinking a bit – slowly pulling itself off the raft (with considerable force). A heated baseplate seems to be the hack to solve this – but that will require a lot more tinkering.

Oh well. We’ll get there… eventually :)

Update – upgraded to ReplicatorG 0012 with Extruder firmware v1.8 and switched to Zach Hoeken’s thermistor settings (raft setting reverted to original 230°). The last change was to shine a halogen light on the platform and object, to heat it up a bit – this seems to get rid of just about all the warping, yeay!

More 3D trials

In Hardware on Jan 28, 2010 at 00:01

It’s not as simple as it seems…

Well, the CupCake worked straight out of the box, which is of course fantastic. But printing does seem to have two tricky bits, called “extrusion” and “rafts”.

Here’s the printer making its third part:

What’s about to happen, is that the “raft” (that woven mat laid out on the bottom to hold the rest of the construction) is about to come off the base. In the above picture you can see two other problems: the raft itself coming apart, and a blob of plastic (front right) when the printer decided to pause for a few seconds, while the extruder kept pushing out plastic…

The problem seems to be that when the plastic cools down fully it becomes quite springy and rigid. Which is great for the final object, but causes trouble in keeping it stuck to the acrylic base. I suspect that the heated platform which people are experimenting with is to overcome this problem, by keeping the base slightly sticky for the duration of the build.

Or maybe a few wires extending further out from the raft would help, by “tacking down” the whole thing.

The other purpose of the raft is to even out the surface. In my case there is a slight difference in height across the base. I should probably try to get rid of that first.

Anyway, here are the objects made so far:

The meandering plastic retains its shape – that’s probably part of the magic behind all this.

PS. The stepper motors are noisy. I don’t think the software I’m using is micro-stepping right now.

CupCake #361 is alive!

In Hardware on Jan 27, 2010 at 00:01

Just got the missing part for the CupCake CNC 3D-printer in from MakerBot – partly their mistake, partly my mistake, long story… anyway – in the end they were extremely helpful in coming up with a good solution.

Which I had to try right away, of course ;)

After a bit of head scratching w.r.t. firmware versions and uploading, everything came together at last.

Here’s the first object getting printed at Jee Labs – whee this is fun:

After 8 minutes, it’s done and steps aside:

Mystery object…

After removing the “raft” and cutting off some loose ends:

So what is it? Oh, nothing spectacular really – it’s a Z-endstop for the machine itself. I figured that after us people doing so much to get it going, this machine might as well start working on improving itself right away…

I’m astonished by how well this first part came out. Very clean, very plastic’y, much sturdier than I expected.

All that’s left is to give this new beast a name – Jee3D? JeeCup? JeeCake? CuppaJeeno?

Ceiling mount – sliding part

In Hardware on Jan 26, 2010 at 00:01

Ok, here’s the sliding part of the room node mount:

Totally hacky for now, the reinforcement bits are all glued in and cut to shape.

What totally surprised me, is that the JeeNode itself barely fits, even though there seems to be so much empty space in there. The tricky bit is that it can’t stick out on either side – in the end I could only make it fit by turning it a little, and moving the battery pack out of the way to make room for that orientation:

This thing is larger than I expected it to be – the big triangle against the ceiling is 14 cm on both sides and ≈ 20 cm on the long diagonal side.

Last step will to to figure out a way to mount this concoction. Oh, and then redo it all from scratch to create a decent printable DIY template.

Ceiling mount – first step

In Hardware on Jan 25, 2010 at 00:01

As promised, the foam board construction – well, a first step anyway:

The “folds” are a bit ugly this way, I’ll hide them on the inside using V-cuts in the next version.

Room node and battery pack included for size comparison. You’d think they fit easily inside, but the battery pack is surprisingly tricky, given that the room node needs to stick through the slanted side facing outwards.

The “walls” are also a foam mockup I’m using to avoid having to use an actual ceiling corner :)

Here’s how I intend to to place everything inside:

The battery pack will be attached to the top, i.e. flat against the ceiling. The room node will be mounted such that the PIR sensor sits in the middle, sticking out.

Onwards!

Room node ceiling mount

In Hardware on Jan 24, 2010 at 00:01

Been pondering a lot lately on how to mount all those room nodes around the house…

Without an enclosure the room nodes look very “hacky”. And what’s even worse: there is no way to mount them! The problem is that you want to point the PIR sensors at least approximately into the center of the rooms they are overseeing. The least conspicuous place for them is probably in the corner, near the ceiling.

Our house has white walls, so naturally I’d like to have something white up there, not some black or metal box!

Here’s an idea:

Screen shot 2010-01-22 at 14.12.54.png

To be made of – wait for it – foam board!

It’s probably a bit hard to visualize, but the idea is to attach a triangular “corner plate” to the wall (using glue / nails / screws / telekinesis / whatever). Then you slide this assembly with JeeNode and battery pack onto it.

Here’s a paper mockup of the sliding part:

With one or two “struts” to reinforce it, this ought to be fairly sturdy and easy to slide in and out (will probably have to do that often in the beginning!). Perhaps a few needle pins will be enough to keep it fixed in place.

Laid flat, the sliding part looks like this:

Needs some holes in the middle section, for the PIR, SHT11, and LDR sensors.

The geometry of this thing is quite simple, once you wrap your mind around what it really is – an equilateral triangle placed against the top corner with horizontal cross sections on top and cutting off the bottom part:

Screen shot 2010-01-23 at 13.46.52.png

The trick will be to get the sizes right. The paper mockup shown here is about 12 cm on each side, enough for a JeeNode, but too small to also hold a 3x AA battery pack behind it. It also shouldn’t be too hard to make some extra templates pointing off-center – so that you’d essentially aim the PIR by picking the most suitable enclosure variant.

I’m going to try a version using foam board next. Never a dull moment :)

P.S. If you qualify for a 10% discount in the shop, please note that there are 7 days left.

Lithium node

In Hardware on Jan 23, 2010 at 00:01

The 3.6 long-life / low-current OmniCel lithium batteries just came in.

Say hello to the latest room node at Jee Labs:

Colorful, eh? ;)

The battery is connected directly to +3V and GND, i.e. after the voltage regulator, since its operating voltage is an excellent match for the ATmega and RFM12B.

No motion sensor was needed for where this node is going (and I didn’t have any left anyway), so that reduces the current draw by some 40 µA. Average should be somewhere around 200 µA – as mentioned before, this can no doubt be optimized further.

Since there are no motion triggers, this node will only send one or two packets per minute – the battery should last well into 2011, according to the specs.

Unless the receiver is turned off and this thing starts re-transmitting all the time. I really need to fix that flaw…

For a fun enclosure, check out the Airwick post by Szymon Kobalczyk on the Jee Labs discussion forum.

Single AA room node

In AVR, Hardware on Jan 21, 2010 at 00:01

The range of things to try is just endless…

Here is a (v2) JeeNode with a (prototype) room board and a 1-cell battery:

Note that this prototype board is turned 180° w.r.t. the official Room Board, to match the Rooms sketch.

This node uses a 1.5 => 5V converter from SparkFun, which I had lying around. It’s far from optimal, with one third of the energy eaten up by the 3.3V voltage regulator, but it’ll have to do for now. Let’s see how long it lasts…

The whole thing is mounted on a little piece of foam board with dual-sided adhesive tape. Just to try it out.

To give you an idea of what’s flying around over the 868 MHz airwaves around here:

Screen shot 2010-01-20 at 00.18.35.png

That’s some 10 room nodes, the OOK relay with a bunch of sensors, and the energy/gas metering packets. Note how the Linux system time is exactly in sync with the DCF77 atomic clock receiver (using UCT i.s.o. CET). Note also that the OOK relay data is currently reported twice: once through a direct USB connection, once over the air.

Lots of fun! And that’s just the beginning, as far as I’m concerned :)

On a related note: I’m investigating whether it would be feasible to bring out a complete kit for the Room Board – with motion, light, temperature, and humidity sensors all included. If I can find the right distributors and order in sufficient quantity, it might be possible to get such a kit in the shop for €39, incl. VAT. Let me just say that if it can be done, you’ll be the first to know!

Interesting battery option

In Hardware on Jan 19, 2010 at 00:01

Found an interesting (one-time, i.e. disposable) battery cell the other day at Farnell:

Screen shot 2010-01-17 at 21.03.13.png

These have the size of an AA cell, but they deliver 3.6V, so they can effectively replace 3 AA cells at once. The voltage is just right – this battery could be used with or without the JeeNode’s 3.3V voltage regulator.

The discharge graph is as follows:

Screen shot 2010-01-19 at 16.47.29.png

I’ve ordered a few with wires attached to them, so they could be tied directly to the PWR & GND pins of the FTDI connector. Will report back once some “field tests” have been done.

Update – better discharge graph, see comments below.

▶ View 12 Comments

Fun board

In Hardware on Jan 17, 2010 at 00:01

Here’s a fun project:

This is an A4-sized foam board with four “indicators”. Each of the colored vane pointers can rotate 90°. The idea is to place a sheet of A4 paper underneath them with some sort of scale, so that you can see 4 status values at a glance. Energy consumption, number of pending emails, whatever.

Here’s the back side:

That’s an old v2 JeeNode with an ATmega168 and 4 cheap micro-servos strapped to it. The extra capacitors reduce the voltage ripple while these servos move, since they seem to generate quite a lot of noise.

The whole thing is held together by zip-lock straps:

The servo axes pass through holes in the bottom, which is in the fact the front plate.

Here is a test sketch to move each of the servos via commands given to the serial port:

Screen shot 2010-01-16 at 10.55.46.png

The basic range for each servo is 45 to 135 degrees, and the h/j/k/l keys control each individual servo, so this lets me position each one with commands such as “45h”, “90j”, “135k”, “75l” etc. There are also commands to move all servos, or to return each one of them to the middle position. These positions are only approximate, each servo will need slightly different values for their end ranges.

It turns out that these servos can’t all be moved at the same time reliably. I’m guessing that they generate too much noise or pull down the 3.3V regulator too far. So all actions involving multiple servos need to be staggered. Another problem is that these low-cost servos sometimes get “stuck” and keep jittering around the target position – this can be prevented by detaching them, since each servo will stay at its last position.

Next step will be to drive these indicators from wireless. I’m going to postpone that for now, because this status display really needs a “switchboard” type application running on the central PC to manage real-time updates.

This thing can’t run off batteries, unfortunately, because the servos draw too much current. I’d be interested to make a display in the future which does run wirelessly – maybe something with solenoids or tiny DC motors.

JeeHub, JeeLink

One of the JeeHubs?

In Hardware on Jan 15, 2010 at 00:01

Just got this thing in:

It’s a SheevaPlug with 512 Mb RAM, 512 Mb flash, Gb ethernet, and a USB host port.

As you can see, I plugged a JeeLink into it, along with a 2 Gb memory card.

This is just one of several configurations I am going to look into. One of the design criteria for the server side is that it needs to be portable to a fairly wide range of hardware, from desktop PC’s, to some really small embedded Linux boards. This SheevaPlug sits somewhere in between, with a lot more oomph than needed just for JeeMon, yet an idle consumptions of only a few watts.

Haven’t turned it on, let alone adapted the JeeMon software for it, but that’s only a matter of time.

Time? Man, that’s such a scarce resource around here!

▶ View 7 Comments

Meet Roomie

In Hardware on Jan 13, 2010 at 00:01

It may not be the prettiest gadget in the home …

… but I find it mighty convenient. I think I’m going to call it a “Roomie”.

The battery pack shown here is an older green one, the ones currently in the shop are black.

It’s nothing but a JeeNode with a battery pack and a Room Board on top. This example is not optimal, it uses a power hungry ePIR. But you get the idea.

The battery pack is tied to the dedicated connection for it – going through the strain relief holes and around the other side to the solder pads:

And the whole thing is glued together with hot glue:

Nice thing is that this doesn’t restrict the uses of a JeeNode. When switching the battery off, you can hook it up to a USB interface via the FTDI header.

In fact this will even work upside down on a foam board, as used with POFs:

Just think of it as a JeeNode with a power pack sitting on its back :)

Arduino, JeeNode

Pin I/O performance

In AVR, Hardware, Software on Jan 6, 2010 at 00:01

There was a discussion on the Arduino developer’s mailing list about the impact of a small change to the digitalWrite() function, and for some time I’ve been hearing that digitalWrite() has a huge amount of overhead.

Time to find out.

Here is the sketch I used to measure how often a pin I/O command can be issued using various mechanisms:

Screen shot 2010-01-05 at 11.42.53.png

The logic is that I’m counting how often the same command can be called between timer overflows, i.e. every 1024 µs (one byte, incrementing @ 16 MHz / 64), before the timer tick count changes again.

And here’s the sample output:

Screen shot 2010-01-05 at 11.42.14.png

There’s a small amount of jitter, which tells me the loops are syncing up almost exactly on the timer ticks. Interrupts have not been disabled, so the timer interrupt is indeed being serviced – once for each loop.

What these values tell me, is that we can do about:

10 analog 10-bit readings per millisecond with analogRead()
128 pwm settings per millisecond with analogWrite()
220 pin reads per millisecond with digitalRead()
224 pin writes per millisecond with digitalWrite()
1056 pin reads per millisecond with direct port reads
1059 pin writes per millisecond with direct port writes

(I’ve corrected the counts by 1000/1024 to arrive at these millisecond values)

So the Arduino’s digital I/O in IDE version 0017 can do roughly 1/5th the speed of direct port access on a 16 MHz ATmega328.

But WAIT! – There’s a large systematic error in the above calculations, due to the loop overhead. It looks like the loop takes 1024000/1251 = 819 ns overhead, so the actual values are quite different: digitalRead() -> 3712 ns, direct port read -> 151 ns. Now the values are more like 1/25th!

So let’s redo this with more I/O in each loop iteration (all 4 ports):

Screen shot 2010-01-05 at 11.55.31.png

The sample output now becomes:

Screen shot 2010-01-05 at 11.56.59.png

With these results we get: one digitalRead() takes 4134 ns, one direct port read takes 83 ns (again correcting for 819 ns loop overhead). The conclusion being that digitalRead() is 50x as slow as direct port reads.

Which one is correct? I don’t know for sure. I retried the direct port read with 16 entries per loop, and got 67 ns, which seems to indicate that a direct port read takes one processor cycle (62.5 ns), as I would indeed expect.

Conclusion: if performance is the goal, then we may need to ditch the Arduino approach.

Update – Based on JimS’s timing code (see comments): digitalRead() = 58 cycles and direct pin read = 1 cycle.

Update #2 – The “1 cycle” mentioned above is indeed what I measured, but incorrect. The bit extraction was probably optimized away. So it looks like direct pin access can’t be more than 29x faster than digitalRead(). As pointed out by WestfW in the comments, digitalRead() and digitalWrite() have predictable performance across all use cases, including when the pin number is variable. In some cases that may matter more than raw speed.

Update #3 – Another caveat – Lies, damn lies, and statistics! – is that the register allocations for the above loops make it extremely difficult to draw exact conclusions. Let me just conclude with: there are order-of-magnitude performance implications, depending on how you do things. As long as you keep that in mind, you’ll be fine.

▶ View 15 Comments

Arduino

Arduino Duemilanove

In AVR, Hardware on Dec 30, 2009 at 00:01

Not everything is about wireless. Nor about nodes, ports, or plugs. Of course not – that would be boring :)

To offer more choices, I’ve added the Arduino Duemilanove to the web shop:

Duemilanove_HI.JPG.jpeg

Jee Labs is now an official distributor for these famous boards. Woohoo!

JeeNodes and complexity

In Hardware, Software on Dec 29, 2009 at 00:01

In yesterday’s post, I commented on a couple of aspects of the Arduino world which are giving me some trouble.

Now it’s time to do the same for all this “JeeNode” and “JeePlug” stuff I’ve been working on in 2009. Because there too, there are some ugly edges, uncomfortable trade-offs, and unsolved issues.

Let me start by pointing out the obvious: the Arduino world and Jee Labs are totally and utterly incomparable in scale. In terms of number of people involved, money involved, business interests, variety, maturity, promotion, reach, ambition, … they really differ in every aspect you can think of.

Except technology: Arduino’s and JeeNodes both live in the space of Physical Computing. And JeeNodes are compatible to Arduino’s in terms of software and PC interfacing. That’s not so surprising, since I designed JN’s to get going as fast as possible with as few key changes as possible.

These key changes were:

Voltage levels – run at 3.3V to support more sensors and wireless
Hardware ports – multiple identical interface connectors
Hardware extension – I2C buses which allow daisy-chaining
Software – connector-independence through the “Ports” library
Physical shape – a much smaller RBBB-like form factor

Two key additions driving some of this were:

Wireless – built-in bi-directional wireless link
Low power – selecting all hardware so it can run off batteries

Because one major use for all this is remote battery-powered operation, a minimal PC interface was chosen (3.3V signals for use with an FTDI adapter).

So is all this Jee stuff merely about creating wireless nodes? Not really. That just happens to be my area of interest. Staying focused is good, and I definitely intend to stick to this for quite some time.

So far so good. I thought I had it all figured out.

Then reality – and complexity – set in. Here are a number of issues:

Connector choices – ports use 6-pin 0.1″ headers as connectors: cheap and widely available. Not polarized, so you can plug things in the wrong way (and you will) – it took a while, but it has been standardized, and the POF approach solves polarization where it matters most: during experimentation.
Library dependencies – the “Ports” and “RF12″ (wireless) libraries have become inter-dependent, so you now have to include both of them all the time. As far as I can tell, this is not a software modularity issue but an Arduino IDE problem. This is starting to become a major inconvenience for small projects.
Class dependencies – classes such as “MilliTimer” are very small and self-contained but the more they get used, the more they lead to the above library dependency troubles. If adding modular and useful code leads to headaches, then something is definitely wrong.
Wireless functionality – a small driver takes care of packet reception and transmission in the background. It’s very low level but an easy transmission layer on top now adds robust communication for sensor networks. More convenience functions like these need to be added.
Multi-node development – it’s tedious to deal with multiple interfaces when more than one JN is plugged in, because USB interface names are meaningless. There is currently no way to auto-detect when a JN is plugged in or removed, let alone do something specific depending on what sketch that JN is running.
I2C ≠ I2C – ports support a software (bit-banged) I2C bus, but the ATmega also has pins which support hardware I2C. The underlying driver code is completely different. There is no generalized layer yet to hide these differences, so right now code written to use I2C plugs via the Ports library needs to be changed to work with hardware I2C and the Arduino’s “Wire” library. This must be fixed.
Ports vs. Plug Shield – due to the I2C differences described in the previous item, code written for ports on a JN needs to be adapted to work with the Plug Shield on an Arduino, and vice-versa. Tedious.
External power – the various power pins on a JN are all tied together, because the voltage drop of diodes would hamper ultra-low power use. That means you can’t hook up a JN to FTDI while a battery is tied to one of the other power pins (unless the battery has an on/off switch and you’re careful).

Some of the above issues have already been sorted out. Others can be addressed in future hardware designs. Some, such as “external power” are likely to remain as is for now. And some just need more or better software.

Adding or modifying software is easy. The hard part is avoiding restrictive decisions which have long-term consequences. Here’s the most challenging one: should I maintain 100% software compatibility with the Arduino world and benefit from all the shared knowledge already built up, or should I start off on a new journey and redo whatever is needed from scratch to reach a workable level again? I haven’t decided.

Screen shot 2009-12-28 at 00.33.52.png

When you hit a wall, do you look for a way around it or do you tear it down? Depends on the wall, I s’pose.

Arduino

Arduino and complexity

In Hardware, Software on Dec 28, 2009 at 00:01

This is – in a nutshell – the Arduino world:

Screen shot 2009-12-27 at 18.53.04.png

In prose: an ATmega board, some hardware peripherals, an environment for embedded software development, a front-end for visualization, and a website to bring all these facets together for a growing worldwide community.

For each of these, there are alternatives and variations. These add variety and increase the number of choices for everyone interested in this low-cost physical computing world. The “Arduino” name is conquering the world, and it sticks … even as “duino” suffix. Names are a great way to create a brand.

But what is Arduino, really? Is it an ATmega? Is it a board that fits in the palm of your hand? Is it a standard for connecting other boards? Is it a standard way of structuring software? Is it defined by a set of standard libraries? Is it the dual aspect of the IDE, i.e. Wiring vs. Processing? Is it the main web site or the discussion forum?

The answer depends no doubt on who you ask. And if this is a healthy ecosystem, then all of these will evolve and improve over time. In my opinion, the current state of an ecosystem is far less important than its ability to evolve.

That’s where complexity comes in.

It’s not hard to construct a great system, even an elaborate one. But what is extremely hard, is to come up with a system which supports evolution of all the pieces involved. Because with multiple pieces, you have to make decisions. You have to interconnect the pieces, and that requires making choices. And once you do, you reduce the number of future paths, including many you don’t even know about yet.

Making choices can be good. Hooking up an Arduino to a PC via a serial connection is a great low-cost solution for uploading, debugging, and interacting. The transition from an RS232 connection + a separate power supply to a USB connection with “built-in” 5V power is an excellent example of how evolution can lead to substantial progress.

Technological evolution can take years. And as in life, that’s where the really interesting stuff happens.

Unfortunately in the Arduino world, I’m hitting some nasty edges which tell me we need more generality or flexibility. I’ll describe a few, in terms of interfaces between the different pieces shown above:

Voltage levels – the most widely used Arduinos are based on 5V, meaning that all their I/O pins are also 5V-based. More and more sensors can only be used with a supply voltage up to 3.6V or so. Interfacing them to a standard Arduino requires the use of level converters. Often, resistors will do – but you can’t simply ignore the issue. This is an area where I2C can help.

Hardware modules – the Arduino “shield” concept doesn’t extend very far, because each shield determines which pins it needs. Pins are a scarce resource, and each pin location on the connector is fixed. It’s hard to design shields which will actually stack with others. Even more so now that there is a new Arduino Mega with slightly different pin allocations.

Software modules – libraries are a great concept: code which is there when you need it, but doesn’t get in the way (i.e. included) if you don’t. Right now, adding a library which depends on say the “Wire” library means that you have to include the Wire library in your sketch even if you don’t ever use it. This is almost a show-stopper.

C/C++ code – on the surface, programming for the Arduino board is like programming in C and C++, with a bunch of very common issues resolved and a wide variety of useful functions available, ready to use. Newbies can get going fast and old hands can find their way around in no time. Except… the IDE does some funky things with headers and declarations. And it breaks a couple of fairly basic C/C++ conventions.

Automation – the IDE works with a specific scenario in mind. As of the latest 0017 release, multiple sketches and consoles are supported. This solves some of the issues, but it’s hard to automate this further: after uploading, I still have to manually launch the serial console. If I have some other app talking to the hardware, there is no mechanism to upload a new sketch and then resume that app because the serial USB connection is dedicated.

Visualization – it’s interesting to see how the Arduino / Wiring / Processing approach is bridging a huge range of hardware in an integrated manner. But there are several choices involved which reduce flexibility towards entirely different approaches. Some visualizations (as well as other types of data processing) would benefit from using a more internet-/web-centric approach. Lower-end hardware cannot support the Java environment used by Processing, so that code can’t be leveraged. There are alternatives. Scripting language support would be useful.

Don’t get me wrong: all these issues are tough ones! It’s probably impossible to solve them all and to make everyone happy. These issues are definitely not things open source software is obliged to address from day one. But my point is that this is not about where we are today, but about having the mechanisms to evolve to where we want to be tomorrow.

If you’ve followed this weblog for a while then you can probably guess that I’ve got some ideas and suggestions on how to move forward on all this. I would really like to help take the existing Arduino platform further – but I’m not sure at this point that it can be done within the current constraints. I don’t even know whether anyone else considers the issues listed above to be important. All I know is that as I continue to add more software and design new hardware, the “push-back” from the current Arduino design choices is increasing… a lot.

Do I want to change the Arduino world (i.e. make a case, convince people, find compromises) – or do I want to sidestep some of its decisions by starting all the way from scratch? I haven’t decided.

CupCake

In Hardware on Dec 27, 2009 at 00:01

Spent a day with the family on assembling the CupCake CNC 3D-printer. Great fun!

Here’s where we are now:

The enclosure and all three axes have been assembled. As seen from the top:

Still remaining: the plastics extruder and the electronics – next week, hopefully!

RF12 status lights

In Hardware, Software on Dec 24, 2009 at 00:01

Here is a little setup to see what’s going on in the ether, wirelessly speaking, that is:

Four LEDs, blinking according to the following status signals:

RECV – blinks briefly for each received packet
RSSI – shows the value of the RSSI bit in the RF12 status
DQD – shows the value of the DQD bit in the RF12 status
ALIVE – blinks at 1 Hz, just to show that this node is alive

I changed some thresholds to get better results: RSSI threshold -91 dBm and DQD set to 7 (normally -103 and 4, in the current RF12 driver).

Here is the sketch which drives the LEDs accordingly:

Screen shot 2009-12-20 at 16.05.18.png

In this example, I’ve set up the RF12 parameters to receive group 5 in the 868 MHz band.

The result is quite interesting: DQD is flashing constantly, in an irregular pattern. RSSI blinks only once in a while, and some of these cause RECV to light up – as expected: only packets with the proper FSK format are filtered out, and only some of those are for this specific net group.

The reason for doing this will become clear tomorrow…

Idiot plug

In Hardware on Dec 23, 2009 at 00:01

Sometimes (far more often than I dare to admit, actually) – I mess up…

Such as the reversed pins on a recent plug.

Here’s the solution:

I’ll call it my “idiot plug”. Saved my day on the power consumption tracker:

Onwards. Quickly, please :)

JeeNode, JeePlug, LowPower

Power consumption tracker

In Hardware on Dec 21, 2009 at 00:01

After the recent battery life estimation and refinement posts, I wanted to create a more permanent and more automated setup for monitoring the total power consumption of JeeNodes. I expect to be repeating these power usage optimizations regularly, with new sketches.

Here’s the idea. A little interface to let one JeeNode (or Arduino, whatever) monitor the power consumption of another. This ought to provide a fairly accurate measurement within a day or so.

First the schematic:

Screen shot 2009-12-19 at 16.27.09.png

This is a “low-side” current meter. In fact there are two of them in series, one with a 60 mA range, the other with a maximum range of about 1 mA. So this setup can measure up to 60 mA with approximately 1 µA resolution at the lower end. These ranges could easily be changed by adjusting the 5 Ω (2x 10 Ω) and 270 Ω resistors.

The low range resistor has a forward-biased diode, which limits the total voltage drop over it to under about 0.6V. This means that the total voltage drop over the measurement circuit will stay under 1V for currents up to 60 mA. With a 5V supply, that leaves about 4V to be supplied to the JeeNode being tested – more than enough headroom for the 3.3v regulator to do its thing.

Note that there is a drawback to low-side current sensing: the “ground” level supplied to the test circuit isn’t really ground. It’s floating “somewhere” above zero, and what’s worse is that the actual level will depend on the amount of current drawn. But in this case it doesn’t really matter, since the test circuit isn’t connected to anything else anyway (we’re doing all this to measure a battery-power wireless system, after all).

Two op-amps are used to amplify the 0 .. 0.3V signals 10 times. A neat trick: the low range op-amp (on the right) nicely compensates for the floating reference level from the high-range resistor by using that as reference for its negative input. So basically, these two op-amps generate two analog voltages in the total range of 0 .. 3.3V. I picked the OPA2340 CMOS op-amps because they can operate at 3.3V and can output rail-to-rail voltages. They also happen to draw very little current.

Here’s a custom-made JeePlug with all the above components:

Note: I don’t know what got into me while building this plug, but the pins on the port connector are all reversed. So I’m forced to plug this thing in the other way around. Doh!

This is only half the story. Tomorrow: the software side of power tracking.

Update – for a very nice current metering setup, see also David Jones’ µCurrent adapter.

UartPlug class

In AVR, Hardware, Software on Dec 20, 2009 at 00:01

Here is a utility class for the UART Plug:

Screen shot 2009-12-18 at 13.42.26.png

The interface is exactly the same as the Serial class, so it can be used interchangeably. Here is the updated “uart_demo” example in the Ports library:

Screen shot 2009-12-18 at 13.38.44.png

Here’s a test setup with a second JeeNode running RF12demo plugged in:

Sample output:

Screen shot 2009-12-18 at 13.38.29.png

Both input and output are supported by this UartPlug class – this demo is essentially a serial pass-through.

The UART supports accurate baud rates all the way up to 230400, which is in fact beyond the current I2C rates of the Ports library. Even at 57600 baud, I’ve seen several serious overruns with the above demo. One reason is that it’s only reading out one byte at the time, going through a multi-byte I2C bus sequence for each one (!). Note also that the Serial class does not buffer its output, so it can easily bog down everything else.

The UART hardware can support both hardware handshaking and XON/XOFF throttling, so this would be another way to avoid buffer overruns.

Up to say 9600 baud the UartPlug class should work fine, even with several UART plugs on the same I2C bus.

JeeNode, LowPower, Sensors

Battery life – refinement

In AVR, Hardware, Software on Dec 19, 2009 at 00:01

Yesterday’s post described how to estimate the battery life of a JeeNode running the “rooms” sketch with the SHT11, ELV PIR, and LDR sensors. To summarize:

the code started out using 370 µA average current, i.e. roughly 7 months on 3 AA cells
of these, 200 µA were caused by the 1-second periodic wakeup “blip”
another 120 µA were due to the actual measurements and packets sent every 30 seconds
and finally, the remaining 50 µA come from the PIR + JeeNode current draw in sleep mode

Yesterday’s post was also about reducing that 200 µA blip consumption to somewhere around 20 µA.

Today, let’s tackle the other power “hog”: the 300 ms @ 12 mA spike. Here is that pattern again:

The high peak at the end is the RF transmission of a packet, followed by a “knee” during which the node is waiting for the ack packet in RF receive mode.

Note that the main power drain is NOT caused by wireless communication!

This period of over 300 milliseconds is when the ATmega is polling the SHT11, waiting for a fresh reading. Twice in fact: once for the temperature and once for the humidity measurement.

So the explanation is very simple: we’re polling and waiting in full-power mode. Quelle horreur!

The fix requires a small modification to the SHT11 driver in the Ports library. Instead of a fixed delay, it needs to be extended to allow using an arbitrary function to waste some time. Here’s the modified code:

Screen shot 2009-12-18 at 01.00.53.png

A new second arg has been added, specifying an optional function to call instead of delay(). The code remains backward compatible, because this argument defaults to zero in Ports.h:

So now all we need to do is define a delay function which goes into real power down mode for a little while:

… and then adjust the two measurement calls to use this function:

Screen shot 2009-12-18 at 01.05.08.png

Does all this make a difference? You betcha:

That’s a substantial fraction of a second in which the ATmega will draw considerably less than 12 mA. How much less? Let’s expand the vertical scale:

Most of the time, the voltage is around 50 mV, i.e. 1 mA over 47 Ω. That’s the SHT11 current draw while active. There are two measurements – so everything behaves exactly as expected!

A couple of quick wake-ups remain, to check whether the SH11 measurement is ready. And so does the wireless TX/RX peak, of course. Here is an isolated snapshot of that RF activity (200 mV/div and 4 ms/div):

Approximate current draw: TX = 35 mA, RX = 20 mA. Total time is about 10 ms.

Looks like we’ve reduced the power consumption of this once-per-30-second spike by perhaps 90%. As a result, the node now consumes about 20 (blip) + 20 (spike) + 50 (sleep) = 90 µA on average. Even with much smaller 800 mAh AAA cells, the battery life of these low-power nodes should now be over a year.

There are several conclusions to take home from this story, IMO:

The biggest drain determines battery lifetimes.
Measuring actual current profiles always beats guessing.
A simple USB storage scope is plenty to perform such measurements.

If I had followed my hunches, I’d no doubt have spent all my time on getting the current draw of packet transmissions down – but as these experiments show, their effect on power drain is minimal.

There are more optimizations one could explore. There always are. But the gains will be limited, given that the ELV PIR sensor consumes 30..40 µA, and that it needs to be on at all times anyway, to be able to detect motion.

Sooo… end of story – for now :)

All source changes checked in. The entire rooms sketch still compiles to under 8 Kb of code.

Battery life estimation

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

To get an indication of battery power drain, I measured the voltage drop over a 47 Ω resistor in series with the 5V supply, using a JeeNode with Rooms Board and the latest version of the “rooms” sketch.

Here’s the blip I see, once a second (100 mV/div and 20 msec/div):

That’s a 40 msec pulse of about 5 mA, in other words: 5 mA during 4 % of the time, which averages out to around 200 µA current draw continuously. Not bad, but not stellar either: it’s 4 times the sleep mode current.

Every once in a while, a much longer and bigger spike shows up:

Which looks like roughly 350 msec @ 12 mA.

Let’s assume the big one is a real transmission. It sort of fits: the spike at the end is a brief transmission at ≈ 35 mA total, followed by a 20-ish mA period of reception (waiting for the ack to come in).

Very roughly speaking, the area of that extra spike at the end is about the same as the 5-to-10 mA step at the start of this period. So as an estimate, we’re consuming about 12 mA during 350 msec – let’s round down to 300 msec.

Let’s also assume these bigger current patterns happen every 30 seconds, when the node is reporting changed values (everything other than motion gets reported at that rate in the latest “rooms” sketch).

So 1% of the time (300 ms every 30s), power consumption is 12 mA. This averages out to 120 µA continuous current consumption.

In other words: a JeeNode running this latest rooms sketch with the SHT11 and ELV-PIR sensors, is consuming roughly 200 (blip) + 120 (spike) + 50 (sleep) = 370 µA.

Using a 2000 mAH 3-cell AA battery, this should lead to a 225-day lifetime – over 7 months.

Can we do better? Sure.

It’s basically a matter of figuring out what’s going on during those 40 and 350 msecs, respectively. Interestingly, more can be gained by improving non-transmitting “blips” than twice-a-minute high-power RF packet exchanges.

Do those 40 ms @ 5 mA every second look a bit suspicious? Yep – that’s the “idling” power level. What happens is that I was a bit too pessimistic in the time spent in sleep mode. This was the code:

Screen shot 2009-12-17 at 00.51.26.png

Looks like this is about 40 ms off, and so the code ends up waiting for the 1 sec timer to expire… in idle mode!

Let’s change this to end up closer to the desired time:

Screen shot 2009-12-17 at 02.59.16.png

Here’s the new blip (different scales):

We’re down from 40 to 10 msec blips – tada!

That translates to an average 50 µA current draw from the blips, bringing the total down to 220 µA. Which translates to a 375-day battery life: over a year!

Now we’re cookin’ … but could we do even better? Sure.

Note that only the 2 ms spike at the end of the 5 mA blip is the actual active period. The time up to then we’re just waiting in idle mode – and wasting power.

We could shorten the sleep timer to 994 ms, since we don’t care whether readings are taken exactly 1 second apart. Now the RFM12B-based watchdog timer will wake us up just 2 ms short of the target time. And sure enough, the 5 mA blip is down to around 3 ms – shown here with an even further expanded time scale:

But that’s silly. We’re tweaking a millisecond timer, and we’re not even interested in an “exact” 1000 ms cycle in the first place! It makes much more sense to just use the RFM12B wakeup timer to get us close to that 1 second cycle, and then immediately take a measurement. Here’s the corresponding code change in periodicSleep():

Screen shot 2009-12-17 at 02.35.36.png

Does this make a difference? Definitely:

One final remark: the above battery lifetime estimates do not take into account the increased power consumption when motion is detected and more packets are sent (up to once every 5 seconds). On the plus side, when no light / temperature / humidity changes happen, the packet frequency will drop further, to once-a-minute.

The above changes have been checked into the source code repository.

Update – I just found out that the DSO-2090 scope has a high-pass low-pass filter option:

Sure wish I’d found out about that feature sooner… it’s so much more informative: the initial ramp is probably the clock starting up, and the little peak could well be the LDR pull-up during ADC conversion!

Prototyping

In Hardware on Dec 17, 2009 at 00:01

Some things I just can’t seem to do without are these:

… and these:

Great for all those Projects On Foam in various stages of incubation here at Jee Labs:

Since I’m too lazy to always dismantle and re-use everything – especially POFs – I decided to get some more and also add these mini breadboards and wire jumpers to the web shop.

Pretty low tech stuff, but these just work so well that they’ve become timeless.

JeeNode, LowPower, Sensors

Rooms sketch, reloaded

In AVR, Hardware, Software on Dec 16, 2009 at 00:01

With the new easy transmission mechanism and the low power logic implemented, it’s time to revisit the “rooms” sketch, which I use for all my house monitoring nodes based on the Room Board.

I’ve wrapped the code used in POF 71 a bit further, with these two extra functions:

Screen shot 2009-12-15 at 22.25.44.png

With this, the main loop becomes very simple – even though it will now power down the RFM12B and the ATmega328 whenever there’s nothing to do for a while:

Screen shot 2009-12-15 at 22.25.57.png

The lowPower() and loseSomeTime() code is still the same as in POF 71 – this is where all the hardware low-power trickery really takes place:

Screen shot 2009-12-15 at 22.24.57.png

Note that these need an “#include <avr/sleep.h>” at the top of the sketch to compile properly.

I’ve also disabled the pull-up resistor on the LDR while not measuring its value. This drops power consumption by over 100 µA, depending on actual light levels.

A quick measurement indicates that power consumption went down from 20 mA to some 50 µA (much of that is probably the PIR sensor). These are only approximate figures, because my simplistic multi-meter setup isn’t really measuring the charge (i.e. integrated current draw), just the current draw while in sleep mode.

These changes have been checked into the repository as “rooms.pde”.

This code isn’t perfect, but since “perfection is the enemy of done” I’ll go with it anyway, for now. One difference with the original rooms sketch is that the motion sensor is not read out as often so brief motion events might be missed. Another issue with this code is that if the central node is off, a lot of re-transmissions will take place – without the node going into sleep mode in between! IOW, a missing or broken central node will cause all remote nodes to drain their batteries much faster than when things are properly ack’ed all the time. Oh well, let’s assume this is a perfect world for now.

With these levels of power consumption, it’s finally possible to run room nodes on battery power. I’ll use some 3x AAA packs, to see what sort of lifetime this leads to – hopefully at least a couple of months.

Will report on this weblog when the batteries run out … don’t hold your breath for it ;)

Update – I just fixed a power-down race condition, so this code really goes back to sleep at all times.

Arduino, ISP, JeeNode

Re-flashing and ISP

In AVR, Hardware on Dec 11, 2009 at 00:01

This is the second of two posts about everything related to uploading, re-flashing, bootstraps, FTDI, and ISP.

Yesterday’s post described the process of uploading new sketches via USB or RS232 using a boot loader.

But how did that boot loader get into the ATmega328?

That’s a bit of a chicken-and-egg problem. Ya’ can’t use a boot loader to get the boot loader into flash memory!

This is where a lower-level hardware-based mechanism called In System Programming (ISP) comes in. ISP is a clever trick in the ATmega chip which in effect activates a special boot loader built into the hardware. This is done by holding the RESET line of the ATmega low, at which point the chip becomes essentially useless, since the reset prevents the chip from starting to run its firmware. The trick is that in this mode, some of the pins on the ATmega become an interface to that special hardware-based built-in boot loader.

So what we need to do, is to manipulate those pins to send commands which will store data into the flash memory. What we’re going to send in most cases, is the data for the boot loader in upper memory. With that boot loader in place we can then switch to “normal” uploading via the serial interface and USB.

ISP programming is also used to change “fuse bits” on an ATmega. There are a few configuration settings for the ATmega – what type of clock it uses, how it boots up, enabling a watchdog timer, etc. These are stored in “fuses” which can only be adjusted via ISP programming.

There are 3 I/O pins involved in ISP programming, plus the reset line and power. On the Arduino as well as on the JeeNode and JeeLink boards, these lines are available via a 2×3-pin ISP connector with the following layout:

ISP pins.png

The interesting thing is that you don’t even need an Arduino or JeeNode to set up flash memory and fuses. ISP is so low-level that it works directly on the pins of an ATmega chip. This is very useful to pre-load the boot loader (or test program – anything you like, really) onto a chip before soldering it permanently onto a board.

(continued…)

Arduino, JeeNode

Uploading and FTDI

In AVR, Hardware on Dec 10, 2009 at 00:01

This is the first of two posts about everything related to uploading, re-flashing, bootstraps, FTDI, and ISP.

First, our goal: what we want to do is get our software (“sketch”) from the PC/Mac into the AVR ATmega328 microcontroller on our Arduino or JeeNode. This is a fairly simple process once all the pieces are in place…

The effect is that the flash memory built into the ATmega is re-flashed. Being flash memory, your software will remain in the microcontroller even without power – ready to start again once power is applied.

There are two ways to get your software into the ATmega: In System Programming (ISP) and uploading. ISP will be described tomorrow, here we’re going to focus on uploading.

Uploading works with a “boot loader”. This is a small piece of software started after power-up (or a reset), which usually listens on the RX and TX pins of the serial interface for commands. These commands then tell it what data to store in which part of the flash memory:

Screen shot 2009-12-09 at 12.25.31.png

The surprising thing is that the boot loader itself is also stored in flash memory. It’s stored in a small (1..4Kbyte) area in upper memory, and the data it writes always goes to the lower part of memory. That’s why it’s called a bootstrap or boot loader – imagine lifting yourself by pulling on the straps of your own boots. In this case the ATmega is lifting its own functionality up by reprogramming its flash memory via its own boot loader.

(continued…)