Computing stuff tied to the physical world

Flashback – Anatomy of a transmission

In Hardware on Oct 5, 2013 at 00:01

One of the really fun things I always like to work on, is to push the envelope on power savings in the JeeNode.

It all started long ago, but over the years, I did refine the measurement process as my insight and instruments both got better. Here’s the most primitive approach, inserting a multimeter in series with the power supply to measure the static current consumption:

The big problem with this is that a multimeter is far too slow to really see what’s going on. Only static idle current can be measured this way.

Another approach was to use a second JeeNode as power consumption tracker with some extra circuitry, to measure the voltage drop repeatedly:

This design can capture spikes by performing lots of repeated measurements, and in this particular case it even had a fairly large measurement range of 1 µA to 60 mA. This was done by using two separate sensing circuits and switching between them as needed.

But the real breakthrough came mid 2010, when Jörg Binkele sent me an oscilloscope snapshot of the voltage over a small series resistor. Here is one of the last ones, after lots of power saving techniques had already been applied:

As you can see from the annotations, there is an incredible amount of information one can glean from such oscilloscope traces.

This was one of the main reasons for me to learn more about oscilloscopes and eventually to buy a modern one myself – as described in a couple of posts, such as this one.

The capabilities of a modern digital storage oscilloscope (DSO) are truly phenomenal – and much of it is not even that much affected by the actual price range, although their cost does tend to keep them out of reach for occasional hobby use.

After many days of tinkering, it became possible to produce a very detailed map of the current consumption of a sensor acquisition + packet transmission cycle, as seen here:

The “haircomb” is the power consumption while sending individual bytes over SPI to the RFM12B module (and the received ACK after that), whereby the ATmega is even going to sleep between those bytes. For reference: the entire trace on this last screen is similar to the little blip marked “RFM12B transmission” on the previous screen. It’s not only considerably more detailed, but actually calibrated in 5-mA steps on the vertical axis.

Fascinating stuff, and no doubt a major reason why JeeNodes can perform so well nowadays in terms of ultra-low power consumption. If you had asked me this in 2008, I honestly would never have thought such a level of insight and performance to be attainable by anyone without access to a big research lab!

Flashback – Dive Into JeeNodes

In AVR, Hardware, Software, Linux on Oct 4, 2013 at 00:01

Dive Into JeeNodes (DIJN) is a twelve-part series, describing how to turn one or more remote JeeNodes, a central JeeLink, and a Raspberry Pi into a complete home monitoring setup. Well, ok, not quite: only a first remote setup is described with an LDR as light sensor, but all the steps to make the pieces work together are described.

More visually, DIJN describes how to get from here:

.. to here:

This covers a huge range of technologies, from embedded Arduino stuff on an ATmega-based JeeNode, to setting up Node.js and the HouseMon software on a Raspberry Pi embedded Linux board. The total cost of a complete but minimal setup should be around €100. Less than an Xbox and far, far more educational and entertaining, if you ask me!

It’s all about two things really: 1) describing the whole range of technologies and getting things working, and 2) setting up a context which you can explore, learn, and ~~hack on~~ tinker with in numerous ways.

If you’re an experienced Linux developer but want to learn about embedded hardware, wireless sensors, physical computing and such, then this offers a way to hook up all sorts of things on the JeeNode / Arduino side of things.

If you’re familiar with hardware development or have some experience with the Arduino world, then this same setup lets you get familiar with setting up a self-contained low-power Linux server and try out the command line, and many shell commands and programming languages available on Linux.

If you’ve set up a home automation system for yourself in the past, with PHP as web server and MySQL as back end, then this same setup will give you an opportunity to try out rich client-side internet application development based on AngularJS and Node.js – or perhaps simply hook things together so you can take advantage of both approaches.

With the Dive Into JeeNode series, I wanted to single out a specific range of technologies as an example of what can be accomplished today with open source hardware and software, while still covering a huge range of the technology spectrum – from C/C++ running on a chip to fairly advanced client / server programming using JavaScript, HTML, and CSS (or actually: dialects of these, called CoffeeScript, Jade, and Stylus, respectively).

Note that this is all meant to be altered and ripped apart – it’s only a starting point!

Flashback – Easy Electrons

In Hardware on Oct 3, 2013 at 00:01

The Easy Electrons series is a set of weblog posts which were published end of 2010 and beginning 2011 to try and bring across a bit of intuition w.r.t. electronics.

Many many times, people not trained in electronics struggle with the concepts of voltage vs. current, wonder why some component suddenly overheats, what a capacitor does, why you need a resistor in a certain circuit, or how large that resistor should be.

Unlike software, hardware and electronics are bound by the laws of physics. Painfully so, in fact – you can damage stuff when hooking things up incorrectly, and you can even get hurt if the voltages or currents involved are high enough. And it’s not just AC mains that can hurt you: even a car battery can be dangerous if you don’t know what you’re doing.

Knowing why things happen is extremely important in electronics. And learning the basics is really just a matter of reading up on it and investing a bit of effort. There’s no magic – in fact, there is so much knowledge about electronics nowadays, that you really can predict and explain stuff, even before hooking things up.

Since I loved tinkering with electronics as a teenager, I was lucky to gain a good deal of very intuitive knowledge about electronics early on. So much so, that basic DC electricity knowledge became second nature to me. Ohm’s law is not some technical rule, it’s obvious – the linear relation between voltage and current, and the fact that resistance is simply the slope of that relationship, is so ingrained by now, that I don’t even think of Ohm’s law as something distinct from the essence of electricity. Same for Kirchhoff’s laws – and the water analogy which works so well in so many cases to match intuition to the real world.

So the Easy Electrons series was born – no math, no theory, just a set of posts which tackle a number of electronics concepts in what I hope can bring across some of that intuition. My drawing tools at the time were based on paper and a scanner, so the drawings were a bit crude and hard to read – here’s an example where I’m trying to explain how to drive LED strips which draw more power than the weak I/O pins of an ATmega can provide:

There are posts about voltage and current, about power and heat, about resistors and capacitors, about LEDS and diodes, and about transistors and MOSFETs, to name a few.

Don’t take my word for it, heck… don’t even read my posts if you don’t want to – all I can say is: if you ever hook up electronics circuits of your own imagination and invention: get to grips with the basics, so you’ll understand why hooking up a bunch of LEDs in parallel is usually not such a good idea, why using a power supply with a higher voltage is likely to lead to overheating and damage, and why hooking up relays and motors often requires extra protective circuitry.

It’s not hard, it’s not magic, it requires no math of any sophistication (and there’s always the brilliant Khan Academy if you want to brush up on it anyway). It can be exhilarating to be able to design and predict what a circuit will do before hooking anything together.

Electronics is a truly wonderful field to explore (and it’s huge!). You don’t need much to experiment with, and you will learn a lot – if only to become quite respectful of the laws of physics, which are merciless (still: most mishaps are harmless and nothing gets damaged).

You’ll run into everything from “nothing happens” to “it’s smoking”, and it’s terrific fun!

Flashback – The first JeeNode PCB

In AVR, Hardware on Oct 1, 2013 at 00:01

The first JeeNode circuit board was very exciting to make, back in January 2009:

Initially, I just wanted to get the connections right and didn’t care for silkscreen labelling, so there was none. It was created with CadSoft’s EAGLE, a commercial package with a freeware version for small boards. The “JeeNode” name came a month later, by the way.

The learning curve of the EAGLE package is steep, but then again, drawing this sort of stuff is going to be complicated whatever you do, because it’s not about drawing a nice picture where only aesthetics matter, but a meticulously designed diagram of which all the paths and connections have to follow certain rules, such as wires not crossing (doh!) and wires all having a minimum width and separation.

Here’s the JeeNode v6 PCB in comparison, of which many thousands have been produced:

It’s still surprisingly similar in design to the first iteration, although the production details and fabrication process have greatly improved over the years. One aesthetic detail I’ve always been pleased with is the blue-with-gold color choice. The gold plating is easier to solder than the HASL process I used initially, and is much more resistant to corrosion. Don’t think too much of this gold layer, by the way: it’s chemically deposited (fairly nasty stuff, from what I understand) and only a few atoms thick. Still… enough to do its work, and visually attractive (all in the eye of the beholder, evidently).

The purpose of a PCB is three-fold: a physically strong base for all the components, a reliable interconnect between all the pins to implement the actual circuit design, and silkscreen labelling to ease assembly and use afterwards.

The result: a tangible product. Quite an exciting change for a software developer used to work with bits and bytes, and who could never before point to the “real” result of it all!

Flashback – Batteries came later

In AVR, Hardware, Software on Sep 30, 2013 at 00:01

During all this early experimentation in 2008 and 2009, I quickly zoomed in on the little ATmega + RFM12B combo as a way to collect data around the house. But I completely ignored the power issue…

The necessity to run on battery power was something I had completely missed in the beginning. Everyone was running Arduino’s off either a 5V USB adapter or – occasionally – off a battery pack, and never much more than a few days. Being “untethered” in many projects at that time, meant being able to do something for a few hours or a day, and swapping or recharging batteries at night was easy, right?

It took me a full year to realise that a wireless “node” tied to a wire to run for an extended period of time made no sense. Untethered operation also implies being self-powered:

Evidently, having lots of nodes around the house would not work if batteries had to be swapped every few weeks. So far, I just worked off the premise that these nodes needed to be plugged into a power adapter – but there are plenty of cases where that is extremely cumbersome. Not only do you need a power outlet nearby, you need fat power adapters, and you have to claim all those power outlets for permanent use. It really didn’t add up, in terms of cost, and especially since the data was already being exchanged wirelessly!

Thus started the long and fascinating journey of trying to run a JeeNode on as little power as possible – something most people probably know this weblog best for. Over the years, it led to some new (for me) insights, such as: transmission draws a “huge” 25 mA, but it’s still negligible because the duration is only a few milliseconds. By far the most important parameter to optimise for is sleep-mode power consumption of the entire circuit.

In September 2010, i.e. one year after starting on this low-power journey, the Sleepy class was added to JeeLib, as a way to make it easy to enter low-power mode:

class Sleepy {
public:
    /// start the watchdog timer (or disable it if mode < 0)
    /// @param mode Enable watchdog trigger after "16 << mode" milliseconds 
    ///             (mode 0..9), or disable it (mode < 0).
    static void watchdogInterrupts (char mode);
    
    /// enter low-power mode, wake up with watchdog, INT0/1, or pin-change
    static void powerDown ();
    
    /// Spend some time in low-power mode, the timing is only approximate.
    /// @param msecs Number of milliseconds to sleep, in range 0..65535.
    /// @returns 1 if all went normally, or 0 if some other interrupt occurred
    static byte loseSomeTime (word msecs);

    /// This must be called from your watchdog interrupt code.
    static void watchdogEvent();
};

The main call was named loseSomeTime() to reflect the fact that the watchdog timer is not very accurate. Calling Sleepy::loseSomeTime(60000) gives you approximately one minute of ultra low-power sleep time, but it could be a few seconds more or less. To wait longer, you can call this code a few times, since 65,535 ms is the maximum value supported by the Sleepy class.

As a result of this little class, you can do things like put the RFM12B into sleep mode (and any other power-hungry peripherals you might have connected), go to sleep for a bit, and restore all the peripherals to their normal state. The effects can be quite dramatic, with a few orders of magnitude less power consumption. This extends a node’s battery lifetime from a few days to a few years – although you have to get all the details right to get there.

One important design decision in the JeeNode was to use a voltage regulator with a very low idle current (the MCP1700 draws 2 µA idle). As a result, when a JeeNode goes to sleep, it can be made to draw well under 10 µA.

Most nodes here at JeeLabs now keep on running for well over a year on a single battery charge. Everything has become more-or-less install and forget – very convenient!

Flashback – RFM12B wireless

In AVR, Hardware, Software on Sep 29, 2013 at 00:01

After the ATmega µC, the second fascinating discovery in 2008 was the availability of very low-cost wireless modules, powerful enough to get some information across the house:

It would take another few months until I settled on the RFM12B wireless module by HopeRF, but the uses were quickly falling into place – I had always wanted to track the energy consumption in the house, to try and identify the main energy consumers. That knowledge might then help reduce our yearly energy consumption – either by making changes to the house, or – as it turned out – by simply adjusting our behaviour a bit.

Here is the mouse trap which collected energy metering data at JeeLabs for several years:

This is also when I found Modern Devices’s Real Bare Bone Board Arduino clone by Paul Badger – all the good stuff of an Arduino, without the per-board FTDI interface, and with a much smaller form factor.

Yet another month would pass to get a decent interrupt-driven driver working, and some more tweaks to make transmission interrupt-based as well. The advantage of such as design is that you get the benefits of a multi-tasking setup without all the overhead: the RF12 driver does all its time-critical work in the background, while the main loop() can continue to use delay() calls and blocking I/O (including serial port transmission).

In February 2009, I started installing the RF12demo code on each ATmega, as a quick way to test and try out wireless. As it turned out, that sketch has become quite useful as central receiving node, even “in production” – and I still use it as interface for HouseMon.

In April 2009, a small but important change was made to the packet format, allowing more robust use of multiple netgroups. Without this change, a bit error in the netgroup byte will alter the packet in a way which is not caught by the CRC checksum, making it a valid packet in another netgroup. This is no big deal if you only use a single netgroup, but will make a difference when multiple netgroups are in use in the same area.

Apart from this change, the RF12 driver and the RFM12B modules have been remarkably reliable, with many nodes here communicating for years on end without a single hick-up.

I still find it pretty amazing that simple low-power wireless networking is available at such a low cost, with very limited software involvement, and suitable for so many low-speed data collection and signalling uses in and around the house. To me, wireless continues to feel like magic after all these years: things happening instantly and invisibly across a distance, using physical properties which we cannot sense or detect…

Flashback – Discovering the Arduino

In AVR, Hardware on Sep 28, 2013 at 00:01

It’s now just about 5 years ago when I started with JeeLabs, so I thought it might be a good idea to bring back some notes from the past. Get ready for a couple of flashback posts…

One of the first posts on this weblog was about the Arduino, or rather Atmel’s AVR ATmega chip I had just discovered (it was the ATmega168 back then):

It was the Arduino IDE which made it trivial to play with this chip, an open source multi-platform software package combining an editor, the avr-gcc compiler, and the avrdude uploader. And despite the use of very Arduino-ish names such as “sketches” (firmware) and “shields” (add-on hardware), it was all nearly-standard C and C++, with a couple of convenient libraries to easily access I/O pins, the ADC, the serial port, timers, and more.

Five years ago, a fascinating brand new world opened up for me. I knew all about C and C++ as well as digital I/O and boot loaders, but a lot of really interesting and powerful new technologies were new to me: I2C, SPI, embedded timer hardware, and above all: sleep mode. These chips were not only able to run at an amazing 16 MHz clock rate, they could actually go to sleep and use a watchdog timer to wake up again later, saving 3 orders of magnitude on energy consumption.

A small universe, controlled by standard software and able to interface to the real world.

Physical Computing. Low cost. Accessible to anyone.

Wow.

Small Gravity Plug update

In Hardware on Sep 25, 2013 at 00:01

The Gravity Plug contains a BMA020 3-axis accelerometer from Bosch Sensortec, which is being replaced by a newer BMA150 chip. Luckily, it’s fully compatible in both hardware and software, so the GravityPlug implementation in JeeLib will continue to work just fine with either one.

But the new chip does have more features: you can override its calibration parameters and defaults, by changing values in a new EEPROM area added to the chip. That in itself is probably not too useful for simple setups, but the new chip also offers access to its built-in temperature sensor, so I’ve added some extra code and expanded the gravity_demo sketch to take advantage of that:

#include <JeeLib.h>

PortI2C myBus (1);
GravityPlug sensor (myBus);
MilliTimer measureTimer;

struct {
  int axes[3];
  int temp;
} payload;

void setup () {
    Serial.begin(57600);
    Serial.println("\n[gravity_demo]");

    if (sensor.isPresent()) {
      Serial.print("sensor version ");
      sensor.send();
      sensor.write(0x01);
      sensor.receive();
      Serial.println(sensor.read(1), HEX);
      sensor.stop();
    }

    rf12_initialize(7, RF12_868MHZ, 42);
    sensor.begin();
}

void loop () {
    if (measureTimer.poll(1000)) {
        memcpy(payload.axes, sensor.getAxes(), sizeof payload.axes);
        payload.temp = sensor.temperature();

        rf12_sendNow(0, &payload, sizeof payload);

        Serial.print("GRAV ");
        Serial.print(payload.axes[0]);
        Serial.print(' ');
        Serial.print(payload.axes[1]);
        Serial.print(' ');
        Serial.print(payload.axes[2]);
        Serial.print(' ');
        Serial.println(payload.temp);
    }
}

Here is some sample output:

GRAV 2 -10 130 41
GRAV 0 -9 133 41
GRAV 4 -14 127 41
GRAV 0 -12 134 41
GRAV 4 -15 130 41
GRAV 4 -13 129 42
GRAV 3 -8 128 41

The reported temperature is in units of 0.5°C, so the above is reporting 20.5 .. 21.0 °C.

Unfortunately, the old chip isn’t reporting anything consistent as temperature:

GRAV 51 -31 -225 2
GRAV 50 -29 -225 0
GRAV 51 -30 -224 1
GRAV 52 -30 -227 1
GRAV 51 -30 -229 1
GRAV 52 -31 -223 2
GRAV 51 -31 -225 1

I have not found a way to distinguish these two chips at runtime – both report 0x02 in register 0 and 0x12 in register 1. Makes you wonder what the point is of having a chip “ID” register in the first place…

Anyway – in the near future, the Gravity Plug will be shipped with the new BMA150 chips. It should have no impact on your projects if you use these accelerometers, but at least you’ll be able to “sort of” tell which is which from the temperature readout. Note that the boards will probably still be marked as “BMA020” on the silkscreen for a while – there’s little point in replacing them, given that the change is so totally compatible either way…

HouseMon

My development setup – hardware

In Hardware on Sep 11, 2013 at 00:01

After yesterday’s notes about my development software, some comments about hardware.

As you may have noticed, I use Apple’s hardware with Mac OS/X. Have gone from big (clunky!) setups to the svelte 1 kg 11″ MacBook Air, and now I’m back on a 15″ model. It’s unlikely that I’ll ever go back to a desktop-only setup, and even the 1920 x 1200 pixel 24″ screen on my desk has been sitting idle for many months now (apart from its use in the FanBot project). One reason is that screen switching with multiple physical screens has not been convenient so far (the next OS revision this fall promises to fix that), but even as is, I find the constant switching between different pixel sizes disruptive. Nowadays, I’m often in house-nomad mode: switching places several times a day around the house – from the desk, to the couch, to a big comfy rotating chair, and back. Heck, even outside, at times!

So one setup it is for me. And these days, that’s a 15″ Retina MacBook Pro (“RMBP15”):

There’s a lot to say about this, but the essence boils down to: 1920 x 1200 with VM’s.

To me it’s not essential which operating runs on the host: pick one which you feel really at home with, and go for a laptop size and build quality that suits you and your budget.

Now the crazy thing about the MBPR15 is that its screen is not 1920 x 1200, but 2880 x 1800 pixels. And out of the box, the machine comes set to a 1440 x 900 “logical” screen size, i.e. doubling up all the pixels. Which, in my view, is too small as main development environment – at least by today’s measures (hey, we’ve all been there – but it really is worth stepping up whenever you can).

So there’s this curious 1.5x magnification setting on this Mac laptop – does this mean that a 1-pixel thick line will end up getting drawn as “one pixel and a half”?

Obviously not. It’ll all be anti-aliased, as you can see in this close-up:

If you click on the image above, you’ll see a larger version. There is some interesting stuff going on behind the scenes when using a RMBP15 in 1920 x 1200 “interpolated” mode:

to the applications, the screen is reported as being 1920 x 1200
so that’s the way apps deal with for screen area and placement
for lines, the Mac OSX graphics engine will do its anti-aliasing thing
for text, the graphics engine will draw the fonts at their optimal resolution

That last one does the trick: when drawing a 12-point text, the graphics engine will actually draw an 18-point version, using the full screen resolution. As a result, text comes out as sharp as the LCD display will allow, without the application having to do a thing.

I tend to go for the smallest font sizes in editors and command-line shells which my glass-assisted (no, not that one) eyes can still read well (Menlo 10, for monospaced fonts). This gives me a 100 line window height in MacVim, which is perfect. But on a real 1920 x 1200 display, that would actually be pushing it. However, due to the rendering going on inside a Retina Mac, what you actually get to see is text drawn in a 15-point font on a display with over 200 dpi resolution. The result is excellent.

These choices for screen, window, and font sizes are really hitting the sweet spot for me. An 100 x 80 character editing window with splits and tabs as needed, a decent area to see the browser’s console log (and command line), and a main HMTL display area which is still almost exactly the 1366 x 768 size of a common small laptop screen. I rarely use the Mac’s multiple-desktop feature (called “spaces” in OSX), because I don’t have the patience to wait through its sweep-left-and-right animations. And because there’s no need: one “mode” with carefully-positioned windows, and other windows which can be moved to the front and back – a bit disruptively, but that’s because IMO that’s exactly what they are!

The second part of my laptop story is that since everything is running on an Intel 64-bit chip, virtualisation comes easy. This means both Windows and Linux can be run at the same time on the same machine (assuming you have enough RAM). I regularly fire up a Linux VM, and then ssh into it from the command line. For editing, I don’t even have to leave MacVim: just opening a file as scp://debianvm/housemon/ will open a directory window in MacVim and let me navigate from there. With the entire editor environment intact for fast file selection, tags, folding, etc. With Windows, it’s a matter of “mounting” my home directory on Windows, and all the local command line tools can be used for editing, git, diff, and so on (there’s a lot more possible, but I don’t use Windows much).

I’ll finish off tomorrow with some other handy software utilities I’ve come to rely on.

PS. No, this wasn’t intentionally made to coincide with Apple’s latest publicity blitz :)

3 years on one set of batteries

In AVR, Hardware on Sep 8, 2013 at 00:01

Ok, so maybe it’s getting a bit boring to report these results, but one of the JeeNodes I installed long ago has just reached a milestone:

That “buro JC” node has been running on a single battery charge for 3 years now:

And it’s not even close to empty: this is a JeeNode USB with a 1300 mAh LiPo battery tied to its back, and (as I just measured) it’s still running at 3.74 V, go figure.

Let’s do the math on what’s going on here:

the battery is specified as 1300 mAh, i.e. 1300 mA for one hour and then it’s empty
in this case, it has been running for some 1096 x 24 = 26,304 hours total
so the average current consumption must have been under 1300 / 26304 = 50 µA
well… in that case, the battery should be empty by now, but it isn’t
in fact, I suspect that the average power consumption is more like 10..25 µA

Two things to note: 1) LiPo batteries pack a lot of energy, and 2) they have a really low self-discharge rate, so they are able to store that energy for a long time.

The other statistic worth working out, is the amount of energy consumed by a single packet transmission. Again, first assuming that the battery would be dead by now, and that the microcontroller and the rest of the circuit are not drawing any current:

1,479,643 packets have been sent out, i.e. ≈ 1300 / 1500000 = under 1 µAh per packet
since 60 packets are sent out per hour: about 60 µAh per hour, i.e. 60 µA continuous
energy can also be expressed in coulombs, i.e. 60 µC gets used per packet transmission (3,600 seconds to the hour, but there were 60 packets sent out during that period)
so despite the fact that the RFM12B draws a substantial 25 mA of current during transmission, it does it so briefly that overall it’s still extremely low-power (a few ms every 1s, so that’s a truly minute duty cycle)

The conclusion here is: for these types of uses, with occasional brief wireless sensor data transmissions, the power consumption of the wireless module is not the main issue. It’s far more important to keep the idle (i.e. sleep mode) of the entire circuit under control.

The 2nd result is also a record, a JeeNode Micro, running over 6 months on a coin cell:

This one is running the newer radioBlip2 sketch, which also measures and reports the battery voltage before and after packet transmission. As you can see, the coin cell is struggling a bit, but its voltage level is still fine: it drops to 2.74 V right after sending out a packet (drawing 25 mA), and then recovers the rest of the time to a fairly high 2.94 V. This battery sure isn’t empty yet. Let’s see how many more months it can keep this up.

The 3rd result (penlight test), is this setup, based on the latest JNµ v3:

The timing values are way off though: it has also been running for over 6 months, but I accidentally caused it to reset when moving things around earlier this summer. This one is running with a switching boost regulator. The Eneloop battery started out at 1.3 V and has now dropped slightly to 1.28 V – it should be fine for quite some time, as these batteries tend to run down gradually to 1.2V before they start getting depleted. This is a rechargeable battery, but Eneloop is known to hold on to its charge for a surprisingly long time (losing 20% over 2 years due to self-discharge, if I remember correctly).

You can see the boost regulator doing its thing, as the output voltage sent to the ATtiny is the same 3.04 V as it was on startup. That’s the whole idea: it regulates to a fixed level, while sucking the battery dry along the way…

Note that all these nodes are not sensing anything. They’re just bleeping once a minute.

Anyway… so much for the progress report on a pretty long-running experiment :)

Electricity usage patterns

In Hardware, Software on Sep 3, 2013 at 00:01

Given that electricity usage here is monitored with a smart meter which periodically phones home to the electricity company over GPRS, this is the sort of information they get to see:

Consumption in blue, production in green. Since these are the final meter readings, those two data series will never overlap – ya can’t consume and produce at the same time!

I’m reading out the P1 data and transmitting it wirelessly to my HouseMon monitoring setup (be sure to check the develop branch, which is where all new code is getting added).

There’s a lot of information to be gleaned from that. The recurring 2000+ W peaks are from a 7-liter kitchen boiler (3 min every 2..3 hours). Went out for dinner on Aug 31st, so no (inductive) home cooking, and yours truly burning lots of midnight oil into Sep 1st. Also, some heavy-duty cooking on the evening of the 1st (oven dish + stove).

During the day, it’s hard to tell if anyone is at home, but evenings and nights are fairly obvious (if only by looking at the lights lit in the house!). Here’s Sep 2nd in more detail:

This one may look a bit odd, but that double high-power blip is the dish washer with its characteristic two heating cycles (whoops, colours reversed: consumption is green now).

Note that whenever there is more sun, there would be fewer consumption cycles, and hence less information to glean from this single graph. But by matching this up with other households nearby, you’d still get the same sort of information out, i.e. from known solar power vs. returned power from this household. Cloudy patterns will still match up across a small area (you can even determine the direction of the clouds!).

I don’t think there’s a concern for (what little) privacy (we have left), but it’s quite intriguing how much can be deduced from this.

Here’s yet more detail, now including the true house usage and solar production values, as obtained from some pulse counters, this hardware and the homePower driver:

There is a slight lag in smart meter reporting (a value on the P1 port every 10s). This is not an issue of the smart meter though: the DyGraphs package is only able to plot step lines with values at the start of the step, even though these values pertain to the past 10 seconds.

Speaking of which – there was a problem with the way data got stored in Redis. This is no longer an issue in this latest version of HouseMon, because I’m switching over to LevelDB, a fascinating time- and space-efficient database engine.

From PWM to voltage

In Hardware on Jun 30, 2013 at 00:01

The Arduino library has always had an “analogWrite()” function, even though the ATmega doesn’t have any way to generate a varying voltage. So why the name?

Well, what most microcontrollers can do is generate a pulse-width modulated signal, also known as PWM. That’s just a fancy way of saying that the microcontroller periodically generates a pulse, of which the width can be varied under software control.

Here’s a diagram from the Arduino PWM tutorial page:

It’s very easy to generate an approximate voltage between 0 and VCC by simply adding a resistor and capacitor to act as low-pass filter:

That image came from an excellent article by Scott Daniels about this same topic on the ProvideYourOwn.com website. Check it out for much more background information.

So how do these two little components turn PWM into a voltage?

To see what’s going on, we can tie the resistor to a PWM pin, call “analogWrite(N,128)” to set a 50% duty cycle, i.e. halfway, and then watch the result on the oscilloscope:

(the above was generated with a 10 kΩ resistor and 0.1 µF capacitor – see this calculator)

What you’d want to see, is a 1.65 V output. As you can see, the real thing is indeed centered around that value, but with a lot of “ripple” (yellow = PWM, blue = Vout).

The reason for this is that the PWM is charging and discharging the capacitor. The average value will be the ratio of on-to-off time against the digital voltage, i.e. 3.3V, so a 50% duty cycle will lead to half VCC, i.e. 1.65V. But it’s still charging & discharging.

Can we get a cleaner signal out, without that up-and-down wavering? Yes: by increasing the repetition rate, i.e. the PWM frequency (while keeping the on-off ratio the same). There’s a page on the Arduino site about this. Here’s the result, with a 64x higher rate:

The purple line is a third probe on the same output signal, but set to AC coupling and much higher sensitivity, to show that the ripple is still there, but much much lower.

Now I can get to the point of this post: my intention was to see if I could generate a clean sawtooth wave, to use as supply voltage (after amplification) for testing circuits at various VCC levels – as used a few times in recent posts. Here’s the code I came up with:

void setup () {}

void loop () {
  for (int i = 0; i < 256; ++i) {
    analogWrite(5, i);
    delay(10);
  }
}

The result is this:

And now there’s indeed a sawtooth, but as you can see, sudden changes like the down edge take some time to pass through the RC filter, somewhat messing up the signal.

No problem, if we increase the delay time in the above loop by a factor of 50:

Voilá – things are fine now. A pretty smooth voltage ramp from 0 to VCC every 2 seconds, all from a single digital output pin on the ATmega – we’ve created a DAC!

Status of the RFM12B

In Hardware on Jun 28, 2013 at 00:01

The RFM12B wireless radio module has been around for quite some time. When I found out about it at the time, I really liked the mix of features it provided – far more capable than the morse-code like OOK modules in cheap sensors, very low power, and available at a considerably lower cost than the XBee and other ZigBee solutions out there:

There was little software for it at the time, and writing an interrupt-driven driver for it was quite a challenge when this all started, but nowadays that’s no longer an issue – the RF12 driver which is now part of JeeLib has turned out to work quite well.

There have been some rumours recently, and understandably also some worries, that the RFM12B might be phased out, but if I may paraphrase Mark Twain on this: the reports of the RFM12B’s death have been greatly exaggerated…

After some email exchanges between HopeRF and Martyn Judd, I’m now happy to report that we have received a formal statement from HopeRF to clarify the issue:

“The popular RFM12B S1/S2 modules remain in production with a large volume of long standing and long term orders. There is NO plan to discontinue the series and NO plan to end production in the foreseeable future. It is correct that we no longer recommend this series to customers developing new projects, since we have developed more recent designs, for example the RFM6X series. These incorporate functionality improvements that can provide a better price/performance for specific applications.”

— Derek Zhu, Marketing Manager, HopeRF

As I see it, this means that the RFM12B will be around for quite some time and that we don’t have to worry about supplies for keeping all current networks based on these modules working. I definitely intend to keep using RFM12B’s at JeeLabs and in products designed and produced by JeeLabs.

Having said that, I’m also evaluating alternatives and looking for a convenient option to act as next step forward. My focus is on low-power consumption and good range for use within the house, both of which I hope to take even further. I’d also like to make sure that over-the-air flashing with JeeBoot will work well with the current as well as future choices.

In my opinion the RFM12B continues to be a simple & excellent low-cost and low-power foundation, so I’m taking my time to very carefully review any new options out there.

Meet the FanBot

In Hardware, Musings on Jun 27, 2013 at 00:01

The FanBot is a very simple robot based on a small PCB with microcontroller by Peter Brier, some LEDs as eyes and mouth, and a servo to allow the robot to wave its arms:

Over a thousand boards have been produced, along with accessories to let children create a little cardboard robot with their own name and a little program to store a personalised sequence of LED blinks and servo movements. The µC is an ARM LPC11U24 chip, donated by NXP – which has plenty of power, but more importantly: can be programmed by powering it up as a USB memory stick.

Wednesday was the kick-off / trial day, with 120 kids dropping by and creating their own FanBot. The FanBots will all be used for the main event to cheer on the main RoboCup contestants. Here’s a quick impression of the first 80 “fans” (it’s a huge task to get them all up there, checked, stapled, and connected – not to mention the power/network setup!):

It’s a really wonderful project, IMO: lots of young kids get exposed to new technology, learning about robots by building their own, and creating a huge collection of truly individual and personal robots, all cheering together!

For more info, see Peter and Marieke’s KekBot weblog – there’s also a progress page.

The RoboCup championship itself uses more sophisticated robots, such as these:

Many more pictures of this event can already be found on the RoboCup 2013 website and on their Flickr group. The event has only just started so if you’re in the neighbourhood: it’s free, and bound to be oodles of fun for kids of any age!

Myra and I had a wonderful time, and I even had a chance to see Asimo in action, live!

And JeeLabs ended up getting a spot on the sponsor page – not bad, eh?

Update – Forgot to mention that one of the requirements of RoboCup is that everything must be made open source after the event. This means that any advances made can be used by anyone else in the next year. What a fantastic way to stimulate shared progress!

Packaged but not virtualised

In Hardware, Software, Linux on Jun 26, 2013 at 00:01

Since VMware started virtualising x86 hardware many years ago, many uses have been found for this approach of creating fully self-contained software environments. I’ve used VMware many years, and was pleased when Apple switched the Macs to “Intel inside”.

Nowadays, I can run numerous variants of Windows as well as Linux on a single laptop. I switched to Parallels as VM core, but the principle remains the same: a large file is used as virtual hard disk, with an operating system installed, and from then on the whole environment simply “runs” inside the Mac host (in my case).

Nowadays, we all take this for granted, and use virtual environments as ultra-low cost web servers without even giving it any thought. I have a number of virtual machines running on a Mac Mini for all the JeeLabs sites in fact (and some more). One piece of hardware, able to suspend and resume N completely independent systems at the click of a mouse.

But there’s a drawback: you end up duplicating a lot of the operating system and main services in each VM, and as a result this stuff not only consumes disk space but also leads to a lot of redundant backup data. I keep the VM’s very lean and mean here, but they still all eat up between 3 and 10 gigbytes of disk space. Doesn’t sound like much, but I’m pretty sure my own data uses less than 10% of that space…

Both Parallels and VMware (and probably also VirtualBox) support snapshotting, which means that in principle you could set up a full Linux environment with a LAMP stack, and then use snapshots to only store what’s different for each VM. But that’s not useful in the long run, because as soon as you get system updates, they’ll end up being duplicated again.

It’s a bit like git “forks”: set up a state, create a fork to create a variant, and then someone decides to add some features (or fix some bugs) to the original which you’d also like to adopt. For git, the solution is to merge the original changes into your fork, and use “fast-forwarding” (if I understand it correctly – it’s all still pretty confusing stuff).

So all in all, I think VM’s are really brilliant… but not always convenient. Before you know it, you end up maintaining and upgrading N virtual machines every once in a while.

I’ve been using TurnkeyLinux as basis of all my VM’s because they not only maintain a terrific set of ready-to-run VM images, but because they also make them self-updating out of the box, and because they’ve added a very convenient incremental daily backup mechanism which supports restarting from the back-up. You can even restart in the cloud, using Amazon’s EC2 VM “instances”.

And then someone recently told me about Docker – “The Linux container engine”.

This is a very interesting new development. Instead of full virtualisation, it uses “chroot” and overlay file systems to completely isolate code from the rest of the 64-bit Linux O/S it is running on. This lets you create a “box” which keeps every change inside.

My view on this, from what I understand so far, is that Docker lets you play git at the operating system level: you take a system state, make changes to it, and then commit those changes. Not once, but repeatedly, and nested to any degree.

The key is the “making changes” bit: you could take a standard Linux setup as starting point (Docker provides several base boxes), install the LAMP stack (if someone hasn’t done this already), commit it, and then launch that “box” as web server. Whereby launching could include copying some custom settings in, running a few commands, and then starting all the services.

The way to talk to these Docker boxes is via TCP/IP connections. There’s also a mechanism to hook into stdin/stdout, so that you can see logs and such, or talk to an interactive shell inside the box, for example.

The difference with a VM, is that these boxes are very lightweight. You can start and stop them as quickly as any other process. Lots of ’em could be running at the same time, all within a single Linux O/S environment (which may well be a VM, by the way…).

Another example would be to set up a cross compiler for AVR’s/Arduino’s (or ARMs) as a box in Docker. Then a compile would be: start the box, feed it the source files, get the results out, and then throw the box away. Sounds a bit drastic, but it’s really the same as quitting an application – which throws all the state in RAM away. The point is that now you’re also throwing away all the uninteresting side-effects accumulated inside the box!

I haven’t tried out much so far. Docker is very new, and I need to wrap my mind around it to really understand the implications, but my hunch is that it’s going to be a game changer. With the same impact on computation and deployment as VMware had at the time.

As with VM’s, Docker boxes can be saved, shared, moved around, and launched on different machines and even different environments.

For more info, see this page which draws an analogy with freight containers, and how one standard container design has revolutionised the world of shipping and freight / cargo handling. I have this feeling that the analogy is a good one… a fascinating concept!

Update – Here’s a nice example of running a Node.js app in Docker.

FanBots at RoboCup 2013

In Hardware, Software, Linux, ARM on Jun 25, 2013 at 00:01

There’s an event coming up in a few days in Eindhoven, called the RoboCup 2013:

This is the world championship of robotic football. For all ages, and with various levels of sophistication. Some robots are tiny cars, trying to work together to play a match, some robots are little human-like machines consisting of lots of servos to make them walk on two feet, and some robots are very sophisticated little “towers” on three wheels, zipping along at impressive speeds and able to catch, hold, and kick a standard-size football.

I’m not directly involved in this, but I saw some of the preparations and it really promises to be a fantastic event. Lots of geeks with laptops, soldering irons, and mechanical stuff. The kick-off is next Wednesday and the event lasts for five days, with the finals on Sunday.

On the side, there is a gorgeous (not-so) little project going on, whereby kids of ages 8 to 12 can visit a workshop to build their own FanBot (for free). The FanBot can blink its eyes and mouth, and wave its arms – part of the exercise is to create a little “program” of things it does at the press of a button, so this will also be a first encounter with programming!

There’s a Dutch page about the project and a general page in English mentioning FanBots.

But the really exciting goal will be to create a huge stand for all the FanBots and make them cheer the football-playing robots in the main event hall. The aim is to get up to 1000 of them, all blinking and waving – and all orchestrated and controlled from a central system. It’s all being designed and built by Peter Brier and by Marieke Peelen of KekkeTek.

One task in the project is to register all the FanBots and print out a little “passport” as last step – which the kids can then use to pick up their own FanBot once the RoboCup 2013 event is over. This is the part I volunteered to help with.

I’ll describe the setup in more detail soon, but that’s where the Raspberry Pi’s w/ LCD screen and webcams will be used. It’ll be fun to see whether we can get 1000 kids to build and sign up their little robots during three days – there’s quite a bit of logistics involved!

Admission is free, so if you’re in the neighbourhood: don’t miss it – it’s going to be fun!

Using eMMC as root disk

In Hardware, Linux on Jun 24, 2013 at 00:01

The Odroid/U2 mentioned yesterday also has the option to add an eMMC card, right next to the µSD card slot – I went for a whopping 64 GB “SSD” in this case:

The reason to use this, is that it’s indeed nearly three times as fast:

# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   1604 MB in  2.00 seconds = 802.41 MB/sec
 Timing buffered disk reads: 146 MB in  3.02 seconds =  48.40 MB/sec

That’s faster than the maximum transfer rate of USB 2.0, by the way.

But how do you set these things up? The bottom view shows yet another connector, yuck:

It turns out that you can get an adapter from the Odroid/U2 shop:

That turns it into a µSD card, but unfortunately it wasn’t recognised in my Mac laptop. Luckily, this concoction did seem to do the trick:

Through this, I was able to burn the Debian disk image onto it, and through some clever logic in the bootstrap loader, the eMMC card simply takes precedence when present and starts up fine with the same device name as the initial µSD card (which now ends up on /dev/mmcblk1 if also present).

One last step is needed to resize the root partition to take full advantage of the entire eMMC card. Google found this article which explains the whole (nasty) procedure.

Final result:

# free
             total       used       free     shared    buffers     cached
Mem:       2031632      77660    1953972          0       9540      37420
-/+ buffers/cache:      30700    2000932
Swap:            0          0          0

And… tada!

# df -H
Filesystem      Size  Used Avail Use% Mounted on
rootfs           62G  1.2G   58G   2% /
udev            1.1G     0  1.1G   0% /dev
tmpfs           209M  222k  208M   1% /run
/dev/mmcblk0p2   62G  1.2G   58G   2% /
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           417M     0  417M   0% /run/shm
/dev/mmcblk0p1  133M  8.5M  124M   7% /boot

Neat, neat, neat – although the total system cost is close to $200 at this point, due to the expensive eMMC memory card – five times the cost of a Raspberry Pi, but with four times the RAM, a comfy 60 GB of fast SSD storage, and probably 5..10 times the performance.

It’s not for everyone and it has no GPIO pins to hook anything up, but I like it!

More about the Odroid/U2

In Hardware, Linux, ARM on Jun 23, 2013 at 00:01

As mentioned recently, there are many alternatives to the Raspberry Pi. I’m looking mostly at ARM-based systems these days, because Node.js support for MIPS is not really there (yet?), and you really want a JIT-type system to get the most out of a Node.js based setup.

Well, having received the Odroid/U2, first thing I had to do is get a micro-HDMI to HDMI adapter (always some new connector/cable type, yawn…). Also had to get a 16 GB µSD card, because the Debian image I wanted to try was for cards of 8 GB or more (yawn!).

But now that everything is in, I’m finally able to take that little black cube for a spin:

First impression: it’s fast, much snappier than a Raspberry Pi. Try launching aptitude, for example – which takes a long time on RPi’s and other low-end ARM & MIPS systems.

Both are running class-10 SD cards, as far as I can tell. The RPi is running at 700 MHz:

# cat /proc/cpuinfo 
Processor   : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 697.95
Features    : swp half thumb fastmult vfp edsp java tls 
[...]
Hardware    : BCM2708

The OU2 has four cores running at 1.7 GHz:

# cat /proc/cpuinfo 
Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
BogoMIPS    : 1992.29
processor   : 1
BogoMIPS    : 1992.29
processor   : 2
BogoMIPS    : 1992.29
processor   : 3
BogoMIPS    : 1992.29
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
[...]
Hardware    : ODROIDU2

Disk speeds are interesting, first RPi then OU2:

# hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
 Timing cached reads:   340 MB in  2.00 seconds = 169.91 MB/sec
 Timing buffered disk reads:  62 MB in  3.00 seconds =  20.66 MB/sec

# hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
 Timing cached reads:   1616 MB in  2.00 seconds = 808.23 MB/sec
 Timing buffered disk reads:  52 MB in  3.05 seconds =  17.03 MB/sec

I haven’t set up the eMMC card yet, which is said to be several times faster than µSD.

Power consumption of the OU2 is 2.9 W on the AC mains side of a little 5V adapter I’m using. Not bad. I’m tempted to try and set this up as my only always-on server here at JeeLabs, including all the web server stuff even. There’s 2 GB of RAM in this thing, should be enough to run some serious stuff. Perhaps even the (Java-based) CrashPlan backup system I’ve been using for almost a year now.

I don’t really care that much about file storage – a 64 GB eMMC disk would be plenty for everything that needs to be online here at all times, perhaps with an external 2.5″ USB hard disk for secondary / archival backup.

Cheap webcam

In Hardware on Jun 21, 2013 at 00:01

For a project I’m involved in (yeah, yeah, it’ll all be posted in due time), I needed a couple of webcams to take simple snapshots. Started out with a cheap unit from eBay, but that one really wasn’t up to its task. Then I found this limited-stock offer at Conrad:

It’s €10 and it even includes a headset which I don’t need. Go figure…

Can’t be much, eh? Well, how about 1280×1024 with auto-focus and auto-white balance?

(you can click-through to see the full-size image)

Amazing stuff. Amazing bargains. Amazing internet. Amazing mail-order. Wow…

What if the signal lines are very long?

In Hardware on Jun 19, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

This question came from figuring out how to drive an SPI chip over a few meters distance. Normally, you’re not supposed to do that: I2C and SPI in particular are designed for use on a PCB, i.e. distances in the order of dozens of centimeters at best. Fortunately, in this case speed was not an issue, so what if we simply take the clock signal way down, to say 10 KHz (50 µs on + 50 µs off). Can we create a solid SPI setup across a few meters of wiring?

To try this out, I decided to take a reel with some 70 to 80 meters of multi-core wire:

Being untwisted and unshielded, this is probably as bad as it gets for signalling purposes. Then I started with a clean 10 KHz square wave of 0..5V from the signal generator:

Here’s what happens to the signal on the signal generator side (i.e. same probe placement), when simply connecting the open wires of the above cable to signal and ground:

This is caused by the load and the reflection of the signal on the end of that long cable. Think of it as an echo of that voltage change, propagating back and forth and colliding with the signal – causing this fairly substantial change in signal rise time and shape..

But to really see the effects, we have to also look at the signal at the other end, where it’s going to be picked up and used. I made the following setup, with three different probes:

(sorry for the confusion: “B” and “M” were mixed up in this drawing)

YELLOW probe on the incoming signal generator end
MAGENTA probe on the outgoing signal
BLUE probe on the outgoing ground connection
RED is the MAGENTA minus the BLUE level (as math function)

All the vertical scales are set to the same 1V per division from now on:

Note that there are some really strange effects in there: the magenta output signal is “ringing”, as is to be expected with such a long coil of wire and lots of stray capacitance, inductance, and resistance. But the blue “ground” level is also ringing, almost as much in fact! And the yellow input is funny, too. Let’s zoom in a bit on that rising edge:

What does this mean for signal propagation? Well, as you can see, everything rattles and shakes in situations like these. It really makes a difference for example as to how the end is connected to power. If you use the (blue) output ground as reference, then the signal will appear as the difference (i.e. the red line), which has less extreme ringing than if you use the (magenta) output referenced to the incoming ground pin.

None of these effects are problematic at this 10 KHz signalling rate. If you need to pass signals like these, it definitely pays to A) keep the signalling rate low, B) reduce the steepness of the edges, and C) add a fairly substantial load resistance at the end of the wire (between signal and ground, say 330..1000 Ω). The reasons and details of all this will have to wait for some future posts.

What I do want to mention, is that you can actually see the speed of light in action here. Let’s zoom even further into that rising edge (sorry, blue and magenta are reversed now):

It takes over 400 ns for the yellow rising edge to reach the other end. In vacuum, light travels some 120 meter in that amount of time – not so very different from the 80 meter or so of cable the electricity has to traverse. Pretty amazing what you can do these days, with nothing more than a signal generator, a modern oscilloscope, and a coil of wire!

Again?

In Hardware on Jun 18, 2013 at 00:01

After yesterday’s puzzle, I thought that would be the end of it. But sensitised to this, I did check again this morning. And guess what… the problem came back!

This time, I was determined to find the culprit. Starting around my office with lots of powered devices, I narrowed it down to the power adapter of an Acer Inpire One netbook:

Seems conclusive, right? Extra evidence: I took that netbook apart a while ago to install more RAM. All went well, except that the battery charge circuit never seems to have recovered – it’s pretty tiny stuff in there, I must have damaged or disconnected something. Luckily, I was using this netbook only in the lab, i.e. plugged in, so no big deal for me.

Except… this netbook was not plugged in before yesterday. This is a different puzzle!

And digging a little deeper, the pattern is not even exactly tied to when it’s plugged in.

Oh well – this gives me an excuse to talk about knapsacks… stay tuned.

Oscilloscope sampling rate

In Hardware, Linux on Jun 16, 2013 at 00:01

Just to finish the series on Raspberry Pi I/O – here’s proof of its GPIO pulsing speed:

The trouble is the irregularity caused by Linux’s multi-tasking properties, and I wanted to show you some examples of that. After a few dozen captures, I came up with this one:

Looks pretty bad, right? Tons of hickups in what was meant to be a 5.2 MHz pulse train.

Not so fast…

The sample rate used by the oscilloscope for this capture was 10 MHz, so it’s sampling the signal at 100 ns intervals. That’s extremely risky, because when the signal is also pulsing at this rate, you might end up missing each peak for a substantial amount of time. This would make it appear as if the signal was low or high all the time, despite its rapid changes.

This effect is called “aliasing”, and the solution is simple:

Do Not Sample At A Rate Close To The Frequencies In Your Signal!

I’m inclined to discard the above snapshot – it’s probably a measurement artefact.

Here’s another screen, this time at 50 MHz sample rate, i.e. 20 ns between captures:

At that rate, it’s impossible to miss pulses which are all in the range of 100 ns or longer. As you can see, there are still glitches (almost on every snapshot there is one), but it’s not as bad as the previous screen shot was suggesting.

Anyway. Enjoy your RPi and all the Linux high-level stuff it can do (like, ehm, run the Arduino IDE and cross-compile stuff for ATmega’s), but beware of treating it like a CPU which is exclusively at your service.

A Raspberry Pi is fast most of the time, but it’s (occasionally) a bit occupied with itself…

Fast I/O on a Raspberry Pi

In Hardware, Software, Linux on Jun 15, 2013 at 00:01

To follow up on yesterday’s post about WiringPi and how it was used to display an image on a colour LCD screen attached to the RPi via its GPIO pins.

A quick calculation indicated that the WiringPi library is able to toggle the GPIO pins millions of times per second. Now this might not seem so special if you are used to an ATmega328 on a JeeNode or other Arduino-like board, but actually it is…

Keep in mind that the RPi code is running under Linux, a multi-tasking 32-bit operating system which not only does all sorts of things at (nearly) the same time, but which also has very solid memory and application protection mechanisms in place:

each application runs in its own address space
the time each application runs is controlled by Linux, not the app itself
applications can crash, but they cannot cause the entire system to crash
dozens, hundreds, even thousands of applications can run next to each other
when memory is low, Linux can swap some parts to disk (not recommended with SD’s)

So while the LCD code works well, and much faster than one might expect for all the GPIO toggling it’s doing, this isn’t such a trivial outcome. The simplest way to deal with the RPi’s GPIO pins, is to manipulate the files and directories under the /sys/class/gpio/ “device tree”. This is incredibly useful because you can even manipulate it via plain shell script, using nothing but the “echo”, “cat”, and “ls” commands. Part of the convenience is the fact that these manipulations can take place entirely in ASCII, e.g. writing the string “1” or “0” to set/reset GPIO pins.

But the convenience of the /sys/class/gpio/ virtual file system access comes at a price: it’s not very fast. There is too much involved to deal with individual GPIO pins as files!

WiringPi uses a different approach, called “memory mapped files”.

Is it fast? You bet. I timed the processing time of this snippet of C code:

int i;
for (i = 0; i < 100000000; ++i) {
  digitalWrite(1, 1);
  digitalWrite(1, 0);
}
return 0;

Here’s the result:

    real    0m19.592s
    user    0m19.490s
    sys     0m0.030s

That’s over 5 million pulses (two toggles) per second.

This magic is possible because the I/O address space (which is normally completely inaccessible to user programs) has been mapped into a section of the user program address space. This means that there is no operating system call overhead involved in toggling I/O bits. The mapping is probably virtualised, i.e. the kernel will kick in on each access, but this is an interrupt straight into protected kernel code, so overhead is minimal.

How minimal? Well, it takes less than 90 ns per call to digitalWrite(), so even when running at the RPi’s maximum 1 GHz rate, that’s less than 90 machine cycles.

Note how the RPi can almost toggle an I/O pin as fast as an ATmega running at 16 MHz. But the devil is in the details: “can” is the keyword here. Being a multi-tasking operating system, there is no guarantee whatsoever that the GPIO pin will always toggle at this rate. You may see occasional hick-ups in the order of milliseconds, in fact.

Is the RPi fast? Definitely! Is it guaranteed to be fast at all times? Nope!

What it took to generate that LCD image

In Hardware, Software, Linux on Jun 14, 2013 at 00:01

As shown yesterday, it’s relatively easy to get a bitmap onto an LCD screen connected to a few I/O pins of the Raspberry Pi.

But there were some gotcha’s:

the image I wanted to use was 640×480, but the LCD is only 320×240 pixels
the WiringPi library has code to put a bitmap on the screen, but not JPEGs
this is easy to fix using the ImageMagick “convert” command
but the result has 24-bit colour depth, whereas the LCD wants 16-bit (5-6-5)

The “convert” command makes things very easy, but first I had to install ImageMagick:

    sudo apt-get install ImageMagick

Then we can run “convert” from the command-line (long live the Unix toolkit approach!):

    convert snap.jpg -geometry 320x240 -normalize snap.rgb

This handles both the rescaling and the transformation to a file with (R,G,B) types, each colour is one byte. As expected, the resulting image file is 320 x 240 x 3 = 230,400 bytes.

I didn’t see a quick way to convert the format to the desired 5-6-5-bit coding needed for the LCD, and since the code to write to the LCD is written in C anyway (to link to WiringPi), I ended up doing it all in a straightforward loop:

#define PIXELS (320*240)
uint8_t rgbIn24 [PIXELS][3];
unsigned rgbOut15 [PIXELS];

[...]

for (x = 0; x < PIXELS; ++x) {
  uint8_t r = rgbIn24[x][0] >> 3;
  uint8_t g = rgbIn24[x][1] >> 2;
  uint8_t b = rgbIn24[x][2] >> 3;
  rgbOut15[x] = (r << 11) | (g << 5) | b;
}

Note that this is a C program compiled and running under Linux on the RPi, and that it can therefore easily allocate some huge arrays. This isn’t some tiny embedded 8-bit µC with a few kilobytes – it’s a full-blown O/S running on a 32-bit CPU with virtual memory!

The other gotcha was that the bitmap to be supplied to the LCD library on top of WiringPi was expected to store each pixel in a 32-bit int. Total waste of space, and probably the result of a rushed port from the UTFT code (written to assume 16-bit ints) to the RPi. Which is why rgbOut15 is declared as “unsigned” (int, i.e. uint32_t) array, although the image really only needs an uint16_t. Oh well, what’s an extra 150 kB, eh?

Anyway, it works. Perfection can wait.

Note that this sends out all the data pixel by pixel to the display, and that each pixel takes the bit-banging of 2 bytes (the interface to the LCD is 8-bit wide), so each pixel takes at least 20 calls to digitalWrite(): 8 to set the data bits, and 2 two to toggle a clock pin – times two for the 2 bytes per pixel. That’s at least 4.6 million GPIO pin settings in half a second!

Tomorrow, I’ll show how WiringPi can make GPIO pins change in under 100 nanoseconds.

Getting an image on the LCD

In Hardware, Linux on Jun 13, 2013 at 00:01

To follow up on yesterday’s setup, I’ve managed to drive the display from Linux, using the WiringPi library by Gordon Henderson.

It supports driving the Raspberry Pi’s GPIO pins from C using Arduino- / Wiring-like calls to digitalWrite(). That, in combination with the UTFT library by Henning Karlsen, and some work done by iTead to combine everything was enough to get this self-portrait:

The display is a bit shiny, and the contrast and brightness are a bit low, unfortunately :(

Drawing the image takes about half a second, but considering that it’s all done through bit-banging of a few I/O pins from a “user space” program, that’s pretty good actually!

There are a couple of interesting (and sneaky) details, which I’ll go into in the next post.

Hurray for open source and the remixing / sharing it enables!

LCD screen for the RPi

In Hardware, Linux on Jun 12, 2013 at 00:01

For a little side-project I’m involved in (more on that in a future post), I wanted to try adding a little LCD screen with touch sensor to a Linux setup. Found this one at iTead:

There’s a little ribbon cable and adapter (just re-wiring) available for it, which allows plugging this thing into a Raspberry Pi. The nice thing about this screen, apart from being 320×240 pixels and 16-bit color TFT, is its physical size – just right for a stacked setup:

Stay tuned, as I explore how to hook this thing up and make it show stuff…

Accurate timing with jittery packets

In Hardware on Jun 11, 2013 at 00:01

A few days back I mentioned the SYNC message mechanism in CANopen, and how it can have about 150 µs jitter when sent out on a CAN bus running at 1 Mbit/s.

Here’s the basic idea of sending out SYNC packets at a pre-defined fixed rate:

Once you have such a mechanism, you can do things like send out commands which all devices need to perform on the next sync for example. Nice for controlling the X, Y, and Z axis of of a CNC machine with the accuracy needed to make them all move exactly in sync.

The SYNC message has a very very high priority on the CAN bus, but even so, it can be delayed if it wants to send while some other transmission is taking place. So even though it will probably be first one to go out, it still has to wait for the bus to become available:

As a result, that SYNC pulse we wanted to arrive on time T ended up coming in at T + X. With X being under 200 µs when the bus is running at 1 MHz, but still.

Can we do better?

Yes, and no. We can’t avoid the jitter in that SYNC packet. But while the master sending out that SYNC packet cannot time it more precisely, it does know when the packet actually went out. So it does in fact know what T + X ended up being for that transmission.

And here’s the clever bit: the master can now send out a second (slightly lower priority) packet with a time stamp in it, i.e. containing that “T + X” value, down to the microsecond in fact. The arrival time of that time stamp packet is not so important. What matters is that each slave tracks exactly when the sync came in, and then uses the time stamp to adjust for any difference or drift that may be taking place.

This won’t help make the SYNC pulses come in more accurately, but it will let each slave know exactly what the time of that pulse was, and hence how accurately their own clocks are running. With this mechanism, all clocks can safely be assumed to run within 1..2 µs of each other, and therefore all future commands can now be tied to specific times which are known to be matched up between all slaves with two orders of magnitude better accuracy.

Ingenious, that CAN bus, eh?

What’s inside that chip?

In AVR, Hardware on Jun 9, 2013 at 00:01

Came across an interesting post the other day, from a Russian site which looks “under the hood” of some sophisticated chips – some well-known in the West, some less so.

First, the technique of using sulfuric and nitric acid is described and illustrated:

But the really bit interesting bit is what comes out. Here’s the ATmega8:

(both pictures were copied from that site, i.e. zeptobars.ru – I hope that’s ok)

The size of this chip is 2855 x 2795 µm, i.e less than 3 x 3 mm.

Fascinating! I wonder what all the different bits and pieces are…

Trying out CANopen

In Hardware, ARM on Jun 8, 2013 at 00:01

Time for some electronics doodling… here are two LPCxpresso boards, with LPC11C24 ARM chips on each. One of them has been cut in half and hacked, as you can see:

The reason for using this chip is that they have CANopen drivers built into them, in ROM. That makes it a lot easier to get started, with so many things being unclear anyway – from the compiler toolchain (I ended up with a mix of ARM’s Linaro toolchain and NXP’s LPCxpresso IDE), to figuring out how to get a basic CAN packet on the bus and off again.

Anyway, couple of days of hardware + firmware tinkering, and here’s the result:

I’m getting a lot of mileage out of the Hameg HMO2024 scope as you can see, including its hardware CAN bus decoding (a paid option, but free at the time I got the intro bundle).

You’re looking at 4 packets, i.e. 2 request/response pairs going over the bus.

Note how the voltages are jumping up and down a bit. For CAN, this is irrelevant, because it works based on the difference between the CAN-L and CAN-H levels. It’s caused by the master node running its CAN interface at a slightly lower voltage (USB + diode drop). Then again, it’s rather useful for debugging because you can see who sends what! As is clearly visible above, the ACK bit comes from the other node in each exchange.

In terms of speed, there’s one packet every 145 µs, which translates to 55 Kbyte/sec for the 8-byte payload, i.e. 440 Kbit/s out of 1000 Kbit/s actual throughput (more, since there is also an address, the ACK bit, etc). It might not seem like much, but keep in mind that this is also the worst-case timing. The CAN bus does not start thrashing or losing packets when pushed to its limit – all that can happen on a maximally loaded-bus is that the lowest-priority messages will hardly ever get a chance to pass through.

On the software side, a CAN bus is really quite simple to use, since the built-in hardware does all the hard work of acquiring and releasing the bus, resending on packet damage (a noise spike, for example), adding and checking CRCs, buffering a few incoming packets, and even filtered reception – so that only specific ranges of message IDs get picked up.

Not much of this is available for Atmel chips, alas. And that ARM world sure is a lot less physical computing friendly w.r.t. open-source and platform-agnostic toolchains.

All those ARM Cortex chip manufacturers still seem to be living in the dark ages…

CANopen sits on top of CAN

In Hardware on Jun 7, 2013 at 00:01

The CANopen protocol sits on top of the low-level CAN bus protocol. Due to the way CAN bus packets are tagged with a message ID, but not specifically routed from or to a specific device (i.e. node), and due to the maximum packet payload size of 8 bytes, you really need something like CANopen to make it usable. For reference, here’s a 2-node CAN bus setup:

The interesting bit about CANopen, is that it’s all about data acquisition and process control (that’s what you do when you put this stuff in a car, after all). And what intrigues me about that, is the similarity with monitoring and controlling stuff around the house.

I’ve been reading myself silly lately, to wrap my head around all the CANopen terminology and to try and distill the essence of… ehm, CANopen, life, and a few other things :)

But instead of just describing CANopen as it is, and pouring lots of its concepts and new terminology on you, let me try to describe this from an outsider’s perspective:

CANopen works in terms of accessing and saving objects. It’s not necessarily 100% centralised, but that’s how it often gets used: a central CANopen node to control, inquire, and manage a bunch of CANopen slave nodes, all on the same CAN bus.
There are a lot of conventions w.r.t. these objects, because the goal of CANopen is to allow devices from different manufacturers to inter-operate (that’s probably why it’s called “open”). So there’s a standard way to find out which devices are present and what their basic capabilties are, to enable/disable each one of them, to configure their communication settings, to start and stop data acquisition streams – all with lots of room for manufacturer- and device-specific details to be managed as well.
The central concept here is the “Object Dictionary” in each device, which is indexed by a 16-bit number, plus a numeric 8-bit subindex for entries which are more structured. Objects can be 1..4 bytes, in which case they can be exchanged in one packet, or larger, in which case CANopen takes care of all the packing and unpacking.
There is a simple yet effective heartbeat mechanism, so that each device (and of course also the master) can figure out which devices are currently present, which are active, and – with timeouts – which devices seem to have dropped out for some reason.
Each device announces itself when powering up, so auto-discovery is possible, even for devices which the master has never seen before – although it’ll be more effective when the master has a detailed description of each type of device, so that it can optimally manage and control it.
There are mechanisms for urgent error reporting, dropping out gracefully, and throttling to avoid bus congestion.
Everything is prioritised (the CAN bus does that), with top priority (msg ID 000) given to essential (but infrequent) master messages, such as starting and stopping device activity on the bus. Note that, due to the top priority, these will always get through.
Next in priority is a time synchronisation message, which can be used to make all device clocks “sing in sync”. With a 1 Mbit/s bus rate, these sync messages will never have more than about 150 µs jitter (and there’s a clever optional scheme to increase the time resolution in all slaves to 1 µs).

There is much more which I can’t all describe in this post, but the one design idea I’d like to highlight is the distinction between managing a large set of objects (via SDO’s, i.e. Service Data Objects) and maximally efficient data streams (via PDO’s, i.e. Process Data Objects). Where PDO’s can be set up to be sent across in a regular time-synchronised manner or in a more ad-hoc / event-based / asynchronous fashion.

I really like this distinction: there is a large heterogenous mix of data objects, which can be accessed and changed via individual SDO requests, and there are streams of PDO data which don’t waste time and bandwidth on describing themselves – just the raw bytes. The heterogenous data objects can fully describe those streams, their exact byte (even bit) structure, the conditions under which data gets sent, their frequency, and their priority.

Lots of interesting connections with the way the RF12 driver sends packets, the announcer packet idea, and the way HouseMon distinguishes between incoming data and the meta-data inside each driver describing these incoming packets.

A thousand days!

In AVR, Hardware on Jun 6, 2013 at 00:01

It’s getting a bit repetitive, but I just noticed this:

That’s over 1000 days of sending out one packet a minute on this thing:

… and over 100 days on the recent JeeNode Micro v3:

The battery boost version runs off a single Eneloop AA battery, and is doing fine too:

Onwards!

What if you’re out of wireless range?

In Hardware on Jun 5, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

Ok, so you’ve got some JeeNodes up and running, all talking to each other or to a central node via the wireless RFM12B module. Or… maybe not: the signal is too weak! Now what?

There are several approaches you can try to improve wireless range:

optimise your existing antenna(s)
lower the data rate and reduce the bandwidth
use a more advanced type of antenna
use a directional antenna
install a repeater of some kind

Let’s go through each of these in turn.

First thing to try is to optimise the little wire “whip” antenna’s that come standard with a JeeNode. Make sure the antenna wire is 82 mm long (that’s for 868 MHz), is sticking up (or sideways) perpendicular to the board, and check that both antenna’s are pointing more or less in the same direction (but not in the direction of the other node: the RF field is circular around the wire, not on top or below).

One thing to keep in mind with these weak signals, is that salty bags of water (us people, that is) tend to absorb RF energy, so these radios work better with us out of the way. Be sure to take a step back while tweaking and hunting for the best orientation!

If that doesn’t help enough, you can do one more thing without messing with electronics or hardware: reduce the datarate of the transmitter and receiver (they have to match). See the RFM12B Command Calculator for settings you can change. To reduce the data rate by two thirds, call rf12_control(0xC614) after the call to rf12_initialize(), for example. The bad news is that you have to do this in all the nodes which communicate with each other – all the data rates have to match!

This in itself won’t extend the range by that much, but with lower data rates you can also reduce the bandwidth in the receiver (with rf12_control(0x94C2)). You can think of this approach as: speaking more slowly and listening more closely. The effects should be quite noticeable. Radio amateurs have been using this technique to get halfway around the world on mere milliwats, using a system called QRSS.

If that doesn’t give you the desired range – here are a few more tricks, but they all require extra hardware: improve the antenna, use “directional” antennas, or use a repeater.

Here’s an example of an improved omni-directional antenna design, as seen on eBay:

And here’s a directional “Yagi” antenna, which needs to be aimed fairly accurately:

I haven’t tried either of these (you can build them yourself), but the omni-directional one was mentioned and described in Frank Benschop’s presentation on JeeDay. He reported getting quite good results, once all the antenna + cabling quirks were resolved.

If neither of these are an option, then the last trick you can try is to add a relay / repeater node to your network, as described in this weblog post some time ago. This will double the range if you place that node in the middle of the two nodes which can’t reach each other, but it adds some complexity to the packet addressing mechanism.

Move over, raspberry

In Hardware, Linux on Jun 4, 2013 at 00:01

The Raspberry_Pi is a great little board at an amazing little price. But as mentioned yesterday, it’s not very fast as a server. I suspect that a lot of it has to do with the SD card interface and the SD card itself, so I started looking around for alternatives.

And boy, there sure are lots of ’em – still well below €100. I’ll single out one system, the Odroid U2 – knowing full well that there must be over a dozen others out there:

It’s smaller than a Raspberry Pi, but it comes mounted on a “big” (6x6x6 cm) heat sink.

The specs are pretty impressive:

And the board is neat – the result of a huge mobile phone market driving size down:

Could this be used as central web / file / home automation server?

Speedy Raspberry

In Hardware, Linux on Jun 3, 2013 at 00:01

The Raspberry Pi is an amazing little board, with an amazing amount of power and functionality at an incredible price – it’s probably fair to say that our technology geek’s world will never be the same again, now that we have the RPi.

But it’s no speed monster…

Sometimes during development, it really gets in the way – especially when you’re used to working on a modern fast laptop, which is some 20 times faster (and that’s per-core).

So I decided to overclock one of my RPi’s, and see what it does. Overclocking in Raspbian is trivial with the standard raspi-config utility:

Just go to the Overclock section, and pick one:

I went for the fastest there is, but decided to run a 2-hour test to make sure it really works. Turns out that someone has already done all the work, and even created such a stress test:

root@raspberrypi:~# ./overclock-test.sh 
Testing overclock stability...
reading: 1
945+1 records in
945+1 records out
3965190144 bytes (4.0 GB) copied, 352.455 s, 11.3 MB/s
reading: 2
[...]
reading: 10
945+1 records in
945+1 records out
3965190144 bytes (4.0 GB) copied, 358.522 s, 11.1 MB/s
writing: 1
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 95.2065 s, 5.6 MB/s
writing: 2
[...]
writing: 10
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 83.4848 s, 6.4 MB/s
./overclock-test.sh: line 18:  2414 Terminated
              nice yes > /dev/null
CPU freq: 1000000
CPU temp: 58376
[    5.217175] Registered led device: led0
[    8.943589] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    9.418819] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   19.181046] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   19.431053] bcm2835-cpufreq: switching to governor ondemand
[   19.431082] bcm2835-cpufreq: switching to governor ondemand
[   21.736829] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SS
[   22.134893] ip_tables: (C) 2000-2006 Netfilter Core Team
[   22.174573] nf_conntrack version 0.5.0 (7774 buckets, 31096 max)
[  750.951153] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
Not crashed yet, probably stable.

Ya gotta love that last message, nicely semi re-assuring ;)

I did fit a set of cooling fins from Watterott (some nice IR heat pictures there):

As checked with vcgencmd measure_temp, the temperature never rose above 58.4°C.

Onwards!

Solar PV production

In Hardware on Jun 2, 2013 at 00:01

This is the sort of graph I’ve been waiting for – now that there is more sun, at last:

(the steep increases and decreases are probably due to shadows from the other roofs)

All values were obtained from the SB5000TL inverter as 5-minute readouts over Bluetooth:

total delivered power on AC mains – 29 kWh for the entire day
total incoming power on the east-facing roof (12 panels)
total incoming power on the west-facing roof (10 panels)

The east-facing panels are actually slight to the north, and the west-facing ones slightly to the south. Which might explain the similar peak production levels despite the different number of panels, i.e. different “insolation” angles.

The peak values are not the highest I’ve seen so far. A cold day with light clouds recently pushed the maximum to over 4700 watts. But that was a rare event. These values are fine with me – I find such levels of solar PV output in a location well up north on this planet (52°N, to be precise) pretty amazing, in fact.

It takes two to CAN

In Hardware, ARM on Jun 1, 2013 at 00:01

The CAN bus described yesterday keeps drawing my interest. It feels right on many levels…

Anyway, for a real CAN bus test, I’ve set up two nodes, to be able to see a full handshake:

That’s one node sending out a 0x101 packet, and another node responding to it with a 0x202 packet with the same payload. There are lots of interesting things going on here:

The CAN protocol requires any receiving node to send out an ACK bit the moment it has received a valid packet – this doesn’t tell the sender who got it – only that some node was listening and got it. The only thing you can conclude at this stage really, is that there is actual communication – it’s up to higher level layers to verify things.
The sender is a node connected to a 3.3V-based CAN transceiver, so the voltages it puts out on the bus are lower than the receiving / echoing node (which is an ARM-based LPCxpresso 11C24 board with a 5V transceiver, running a standard CAN example in the LPCxpresso IDE). As you can see, voltages are hopping a bit, but all that matters is the voltage difference between the two lines, so everything is fine.
There is no one listening to the reply, so the LPC11C24 doesn’t get a good ACK on that, and keeps re-sending the packet. It does this a number of times and will then give up.
The Hameg HMO2024 scope with its added serial decoding options is very effective in this setup – I made it trigger on a 0x202 packet, and it shows a nice list of the data it has captured. Since I’m using the analog channels, the levels are also clearly visible.
The bus is running at 500 KHz, so the basic bit timing is in multiples of 2 µs. Zooming in, I saw that the gap between each packet is 22 µs, which matches exactly the CAN bus specs requiring nodes to wait for at least 11 idle bits before they start. Speaking of which: the CAN names for “0” and 1″ are “dominant” and “recessive”, respectively – because a dominant bit always wins and forces the bus to a “0” (voltage applied).
The packet times here are ≈ 250 µs, so there’s some 10% of overhead for the gaps between packets, and the total “overhead” for getting 8 bytes of payload across (i.e. 128 µs) is about 100% – but that includes things like bit-stuffing, a message ID, a CRC check, and an ACK. Half the theoretical bit rate to be able to send real-time data with little latency, good reliability, and precisely tagged is actually very good.

Note that the CAN bus requires special transceiver chips. The level conversions are minimal (from “0” and “1” to pulling the two lines apart, in terms of voltage), but what they also add is a substantial amount of protection against common-mode signals, which is when both signals move up or down by the same voltage. This is extremely important in a car, where large currents can lead to huge spikes and voltage changes, but it really doesn’t hurt in other applications either: the CAN bus is a very nice way to tie pieces together – and when there is an issue with ground levels, the whole design even allows for opto-couplers to be used for complete isolation between nodes.

The “standard” way to hook up CAN nodes is through three pins (CAN-H, CAN-L, and GND), but it’s not uncommon to include a +5V supply pin, making this a neat 4-wire bus.

Yes, we CAN bus

In Hardware on May 31, 2013 at 00:01

The CAN Bus is a very interesting wired bus design, coming from the automobile industry (and probably built into every European car made today). It’s a bus with an ingenious design, avoiding bus collisions and supporting a good level of real-time responsiveness.

I’ve been intrigued by this for quite some time, and decided to dive in a bit.

There are several interesting design choices in CAN bus:

it’s all low-voltage, just 0..5V (even 0..3.3V) is all it takes on each connected node
the bus is linear, reaching from 40 m @ 1 Mbit/s to 500 m @ 125 kbit/s, or even longer
signalling is based on voltage between two wires, and terminated by 120 Ω on each end
signals are self-clocked, with bit-stuffing to insert bit-transitions when needed

But the three most surprising aspects of the CAN bus design are probably the following:

the design is such that collisions cannot happen: one of the two senders always wins
each CAN bus packet can have at most 8 bytes of data (and is CRC-checked)
as described recently, messages have no destination, but only a message ID (type)

What’s also interesting is that – like I2C – this protocol tends to be fully implemented in hardware, and is included in all sorts of (usually ARM-based) microcontrollers. So unlike UARTs, RS485, I2C, and SPI, you simply get complete and valid packets in and out of the peripheral. No need to deal with framing, CRC checking, or timing decisions.

You can almost feel the car-like real-time nature of these design trade-offs:

short packets – always! – so the bus is released very quickly, and very often
no collisions, i.e. no degradation in bus use and wasted retransmits as it gets busier
built-in prioritisation, so specific streams can be sent across with controlled latencies
with a 16-bit CRC on each 0..8 byte packet, chances of an undetected error are slim

Since my scope includes hardware CAN bus decoding, I decided to try it out:

The message has an ID of 0x101 (message ID’s are either 11 or 29 bits), eight bytes of data (0xAA55AA55FF00FF00), and a CRC checksum 0x1E32. I’m using a 500 KHz bit clock.

If you look closely, you can see that there are never more than 5 identical bits in a row. That’s what bit-stuffing does: insert an opposite bit to avoid longer stretches of identical bits, as this greatly helps deduce exact timings from an incoming bit-stream.

It seems crazy to limit packets to just 8 bytes – what could possibly be done with that, without wasting it all on counters and offsets to send perhaps 4 bytes of real data in each packet? As it turns out, it really isn’t so limiting – it just takes a somewhat different mindset. And the big gain is that multiple information streams end up getting interleaved very naturally. As long as each of them is reasonable, that is: don’t expect to get more than 2 or 3 data streams across a 1 Mb/s bus, each perhaps no more than 100 kb/s. Then again, you can expect these to arrive within a very consistent and predictable time, regardless of what other lower-priority burst traffic is going on.

Neat stuff…

90 days on a coin cell

In Hardware on May 26, 2013 at 00:01

Just saw that my JeeNode Micro test setup has been running and “blipping” for 90 days:

The voltage is starting to drop a bit, and the voltage drop before and after using the radio has increased from 0.08 to 0.16 V (reported with a granularity of 0.02 V), but everything seems to be fine. It has pumped out over 120,000 packets so far.

The other test is a JeeNode Micro with boost regulator, running of one Eneloop AA battery. That battery voltage has also dropped a bit, but as you can see, the boost regulator is doing its thing and still providing the exact same 3.04 V as it did when the test was started.

It’ll be interesting to see how long each of these setups holds out. I have no idea, really. It’s not just a matter of capacity – with the coin cell, it’ll also depend on how long the battery can continue to provide these brief 20..20 mA power bursts for each transmission.

Onwards!

Electronics, Solar, HouseMon

MPPT hunting

In Hardware on May 21, 2013 at 00:01

Solar panels are funny power sources: for each panel, if you draw no power, the voltage will rise to 15..40 V (depending on the type of panel), and when you short them out, a current of 5..12 A will flow (again, depending on type). My panels will do 30V @ 8A.

Note that in both cases just described, the power output will be zero: power = volts x amps, so when either one is zero, there’s no energy transfer! – to get power out of a solar panel, you have to adjust those parameters somewhere in between. And what’s even worse, that optimal point depends on the amount of sunlight hitting the panels…

That’s where MPPT comes in, which stands for Maximum Power Point Tracking. Here’s a graph, copied from www.kitenergie.com, with thanks:

As you draw more current, there’s a “knee” at which the predominantly voltage-controlled output drops, until the panel is asked to supply more than it has, after which the output voltage drops very rapidly.

Power is the product of V and A, which is equivalent to the surface of the area left of and under the current output point on the curve.

But how do you adjust the power demand to match that optimal point in the first place?

The trick is to vary the demand a bit (i.e. the current drawn) and then to closely watch what the voltage is doing. What we’re after is the slope of the line – or in mathematical terms, its derivative. If it’s too flat, we should increase the load current, if it’s too steep, we should back off a bit. By oscillating, we can estimate the slope – and that’s exactly what my inverter seems to be doing here (but only on down-slopes, as far as I can tell):

As the PV output changes due to the sun intensity and incidence angle changing, the SMA SB5000TL inverter adjusts the load it places on the panels to get the most juice out of ’em.

Neat, eh?

Update – I just came across a related post at Dangerous Prototypes – synchronicity!

Supply noise sensitivity

In Hardware on May 19, 2013 at 00:01

Yesterday’s post showed how with 3 resistors, one capacitor, and a P-MOSFET, you can set up a circuit to measure battery voltage with a voltage divider, even for voltages above VCC.

The whole point of this is that it can be switched off completely, drawing no current between measurements.

While trying this out, I started with a 1 MΩ pull-up on the P-MOSFET gate, and got this:

A very odd switch-off pattern, looked like an oscillation of some kind. Even with with the 100x faster switch-off using a 10 kΩ pull-up instead, the problem persisted:

This turned out to be a problem with the power supply. I was using a little USB plug with a switching regulator. These tend to work fine, but they do create a bit of “ripple voltage”, i.e. the 5V output is not exactly 5V DC. Here are the fluctuations, typical of units like these:

In other words: that little ripple was greatly amplified near the point where the P-MOSFET was starting to turn off, thus creating a regular but highly exaggerated turn-off pattern. Because – in a certain range – MOSFETs act like amplifiers, just like regular transistors.

It all went away when I switched to the lab supply, but it sure took some head-scratching…

Anyway, in real use this won’t matter, since the whole point is to use this with batteries.

Zero-power measurement – part 2

In Hardware on May 18, 2013 at 00:01

After a great suggestion by Max, on yesterday’s post, here’s a another circuit to try:

It adds a capacitor and a resistor, but it allows using a P-MOSFET and a divider ratio which can now use the entire ADC range, not just 1 V or so as in yesterday’s circuit. Note however that if VCC is not fixed to the same value under all conditions, then the ADC’s reference voltage can float, and use of the 1.1V bandgap may still be needed.

Here’s the voltage at the top of the divider, showing how it switches on and off:

That’s with the pull-up resistor value R set to 1 MΩ, which takes 208 ms to turn the MOSFET back off. We don’t need that long, a 10 kΩ resistor for R will do fine:

That still gives us 2 ms to measure the supply level. Note that turn-off is automatic. DIO needs to be turned high again, but that can happen later. In my test code, I left it low for 1s to, then high for 7s.

Here’s a neat set of superimposed measurements (using persistence), while varying the high voltage from 3.5 to 12.0 V in 0.5 V steps:

Warning: for 12V, the divider ratio must be changed so the centre tap stays under VCC.

Note that with higher voltages, the MOSFET will turn off sooner – this is because there is now more current flowing through the pull-up resistor. But still plenty of time left to measure: 1 ms is more than enough for an ADC.

Tomorrow, an example of how these measurements can sometimes go awry…

Zero-power battery measurement

In Hardware on May 17, 2013 at 00:01

As promised, here’s a circuit which can be used to measure a voltage higher than VCC without drawing any current while not measuring:

Besides the fact that this needs an N-FET + I/O pin, there are several finicky details.

First of all, note that the following circuit will not drop the power consumption to zero:

The idea in itself is great: set DIO to logic “0” before performing a measurement, acting as GND level for the resistor divider (10 + 10 kΩ would be fine here). Then, to switch it off, set DIO to an input, so that the pin becomes high-impedance.

The problem is that the pin divider is still connected and that the AIO pin cannot float any higher than VCC + 0.6 (the drop over the internal ESD protection diode). The top resistor remains connected between PWR and VCC + 0.6, therefore it’s still leaking some current.

That also explains why the first circuit does better: the MOSFET disconnects all I/O pins from that PWR line, so that there is just a resistor from AIO to ground (which is harmless).

But there’s a catch: we need to be able to turn the N-channel MOSFET on and off, which means we need to be able to apply a voltage to its gate which is a few volts above the drain pin (the bottom one, attached to AIO). With a resistive divider of 10 + 10 kΩ on a 6V PWR line, that voltage will immediately rise to 3V, and there’s no way the DIO pin can keep the MOSFET on (it can only go up to logic “1”, i.e. 3.3V).

The solution is to use a different divider ratio: say 50 + 10 kΩ. Then, a 6V PWR level leads to a 1V level on the AIO pin, i.e. on the drain of the MOSFET. With DIO set to “1”, that means the MOSFETs gate will be 2.3V above the drain – enough to keep it turned on.

BTW, all this tinkering over the past few days has left me with a bunch a funky headers :)

Anyway, to summarise the zero-power battery monitor:

to work with 6V PWR, use a 50 (or 47) kΩ top resistor and 10 kΩ for the bottom one
use an N-channel MOSFET with low turn-on voltage (called a “logic level MOSFET”)
to measure the voltage, set DIO to “1”
measure the voltage on the AIO pin, where 0..1V will correspond to 0..6V on PWR
to turn off the divider, set DIO to “0”

As you can see, this approach requires an active component to switch things and an extra I/O pin, but then you do end up with a circuit which can completely switch off.

For simple uses, I’d just use yesterday’s setup – sub-microamp is usually good enough!

Measuring the battery without draining it

In Hardware on May 16, 2013 at 00:01

In yesterday’s post, a resistive voltage divider was used to measure the battery voltage – any voltage for that matter, as long as the divider resistor values are chosen properly.

With a 6V battery, a 10 + 10 kΩ divider draws 0.3 ma, i.e. 300 µA. Can we do better?

Sure: 100+100 kΩ draws 30 µA, 1+1 MΩ draws 3 µA, and 10+10 MΩ draws just 0.3 µA.

Unfortunately there are limits, preventing the use of really high resistor divider values.

The ATmega328 datasheet recommends that the output impedance of the circuit connected to the ADC input pin be 10 kΩ or less for good results. With higher values, there is less current available to charge the ADC’s sample-and-hold capacitor, meaning that it will take longer for the ADC to report a stable value (reading it out more than once may be needed). And then there’s the leakage current which every pin has – it’s specified in the datasheet as ± 1 µA max in or out of any I/O pin. This means that a 1+1 MΩ divider may not only take longer to read out, but also that the actual value read may not be accurate – no matter how long we wait or how often we repeat the measurement.

So let’s find out!

The divider I’m going to use is the same as yesterday, but with higher resistor values.

Let’s go all out and try 10 + 10 MΩ. I’ll use the following sketch, which reads out AIO1..4, and sends out a 4-byte packet with the top 8 bits of each ADC value every 8 seconds:

#include <JeeLib.h>

byte payload[4];

void setup () {
  rf12_initialize(22, RF12_868MHZ, 5);
  DIDR0 = 0x0F; // disable the digital inputs on analog 0..3
}

void loop () {
  for (byte i = 0; i < 4; ++i) {
    analogRead(i);                    // ignore first reading
    payload[i] = analogRead(i) >> 2;  // report upper 8 bits
  }

  rf12_sendNow(0, payload, sizeof payload);
  delay(8000);
}

This means that a reported value N corresponds to N / 255 * 3.3V.

With 5V as supply, this is what comes out:

L 10:18:14.311 usb-A40117UK OK 22 193 220 206 196
L 10:18:22.675 usb-A40117UK OK 22 193 189 186 187
L 10:18:31.026 usb-A40117UK OK 22 193 141 149 162
L 10:18:39.382 usb-A40117UK OK 22 193 174 167 164
L 10:18:47.741 usb-A40117UK OK 22 193 209 185 175

The 193 comes from AIO1, which has the 10 + 10 kΩ divider, and reports 2.50V – spot on.

But as you can see, the second value is all over the map (ignore the 3rd and 4th, they are floating). The reason for this is that the 10 MΩ resistors are so high that all sorts of noise gets picked up and “measured”.

With a 1 + 1 MΩ divider, things do improve, but the current draw increases to 2.5 µA:

L 09:21:25.557 usb-A40117UK OK 22 198 200 192 186
L 09:21:33.907 usb-A40117UK OK 22 198 192 182 177
L 09:21:42.256 usb-A40117UK OK 22 197 199 188 183
L 09:21:50.606 usb-A40117UK OK 22 197 195 187 183
L 09:21:58.965 usb-A40117UK OK 22 197 197 186 181
L 09:22:07.315 usb-A40117UK OK 22 198 198 190 184

Can we do better? Sure. The trick is to add a small capacitor in parallel with the lower resistor. Here’s a test using 10 + 10 MΩ again, with a 0.1 µF cap between AIO2 and GND:

Results – at 5V we get 196, i.e. 2.54V:

L 10:30:27.768 usb-A40117UK OK 22 198 196 189 186
L 10:30:36.118 usb-A40117UK OK 22 198 196 188 183
L 10:30:44.478 usb-A40117UK OK 22 198 196 186 182
L 10:30:52.842 usb-A40117UK OK 22 198 196 189 185
L 10:31:01.186 usb-A40117UK OK 22 197 196 186 181

At 4V we get 157, i.e. 2.03V:

L 10:33:31.552 usb-A40117UK OK 22 158 157 158 161
L 10:33:39.902 usb-A40117UK OK 22 158 157 156 157
L 10:33:48.246 usb-A40117UK OK 22 158 157 159 161
L 10:33:56.611 usb-A40117UK OK 22 158 157 157 159
L 10:34:04.959 usb-A40117UK OK 22 159 157 158 161

At 6V we get 235, i.e. 3.04V:

L 10:47:26.658 usb-A40117UK OK 22 237 235 222 210
L 10:47:35.023 usb-A40117UK OK 22 237 235 210 199
L 10:47:43.373 usb-A40117UK OK 22 236 235 222 210
L 10:47:51.755 usb-A40117UK OK 22 237 235 208 194
L 10:48:00.080 usb-A40117UK OK 22 236 235 220 209

Perfect!

Note how the floating AIO3 and AIO4 pins tend to follow the levels on AIO1 and AIO2. My hunch is that the ADC’s sample-and-hold circuit is now working in reverse: when AIO3 is read, the S&H switches on, and levels the charge on the unconnected pin (which still has a tiny amount of parasitic capacitance) and the internal capacitance.

The current draw through this permanently-connected resistor divider with charge cap will be very low indeed: 0.3 µA at 6V (Ohm’s law: 6V / 20 MΩ). This sort of leakage current is probably fine in most cases, and gives us the ability to check the battery level in a wireless node, even with battery voltages above VCC.

Tomorrow I’ll explore a setup which draws no current in sleep mode. Just for kicks…

What if we want to know the battery state?

In Hardware on May 15, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

One useful task for wireless sensor nodes, is to be able to determine the state of the battery: is it full? is it nearly depleted? how much life is there left in them?

With a boost converter such as the AA Power Board, things are fairly easy because the battery voltage is below the supply voltage – just hook it up to an analog input pin, and use the built-in ADC with a call such as:

word millivolts = map(analogRead(0), 0, 1023, 0, 3300);

This assumes that the ATmega is running on a stable 3.3V supply, which acts as reference for the ADC.

If that isn’t the case, i.e. if the ATmega is running directly off 2 AA batteries or a coin cell, then the ADC cannot use the supply voltage as reference. Reading out VCC through the ADC will always return 1023, i.e. the maximum value, since its reference is also VCC – so this can not tell us anything about the absolute voltage level.

There’s a trick around this, as described in a previous post: measure a known voltage with the ADC and then deduce the reference voltage from it. As it so happens, the ATmega has a 1.1V “bandgap” voltage which is accurate enough for this purpose.

The third scenario is that we’re running off a voltage higher than 3.3V, and that the ATmega is powered by it through a voltage regulator, providing a stable 3.3V. So now, the ADC has a stable reference voltage, but we end up with a new problem: the voltage we want to measure is higher than 3.3V!

Let’s say we have a rechargeable 6V lead-acid battery and we want to get a warning before it runs down completely (which is very bad for battery life). So let’s assume we want to measure the voltage and trigger on that voltage dropping to 5.4V.

We can’t just hook up the battery voltage to an analog input pin, but we could use a voltage divider made up of two equal resistors. I used two 10 kΩ resistors and mounted them on a 6-pin header – very convenient for use with a JeeNode:

Now, only half the battery voltage will be present on the analog input pin (because both resistor values are the same in this example). So the battery voltage calculation now becomes a variant of the previous formula:

word millivolts = map(analogRead(0), 0, 1023, 0, 3300) * 2;

But there is a drawback with this approach: it draws some current, and it draws it all the time. In the case of 2x 10 kΩ resistors on a 6V battery, the current draw is (Ohm’s law kicking in!): 6 V / 20,000 Ω = 0.0003 A = 0.3 mA. On a lead-acid battery, that’s probably no problem at all, but on smaller batteries and when you’re trying to conserve as much energy as possible, 0.3 mA is huge!

Can we raise the resistor values and lower the current consumption of this voltage divider that way? Yes, but not indefinitely – more on that tomorrow…

Energy, power, current, charge

In Hardware on May 14, 2013 at 00:01

The International System of Units, or SI from the French Système International is a wonderfully clever refinement of the original metric system.

Took me a while to get all this clear, but it really helps to understand electrical “units”:

power says something about intensity: volts times amperes, the unit is watt
energy says something about effort: power times duration, the unit is watt-second
current says something about rate: charge per time unit, the unit is ampere
charge says something about pressure: more charge raises volts, the unit is coulomb

Of course, some units get expressed differently – that’s just to scale things for practical use:

a kilowatt (kW) is 1000 watts
a watt-hour (Wh) is 3600 watt-seconds
a kilowatt-hour (kWh) is 1000 watt-hour
a milli-ampere (mA) is 1/1000 of an ampere
a micro-coulomb (µC) is 1/1000000 of a coulomb

But there are several more useful equivalences:

When a 1.5 V battery is specified as 2000 mAh (i.e. 2 Ah), then it can deliver 1.5 x 2 = 3 Wh of energy – why? because you can multiply and divide units just like you can with their quantities, so V x Ah = V x A x h = W x h = Wh
Another unit of energy is the “joule” – which is just another name for watt-second. Or to put it differently: a watt is one joule per second, which shows that a watt is a rate.
A joule is also tied to mechanical energy: one joule is one newton-meter, where the “newton” is the unit of force. A newton is what it takes to accelerate 1 kg of mass by 1 m/s2 (i.e. increase the velocity by 1 m/s in one second – are you still with me?).
So the watt also represents a mechanical intensity (i.e. strength). Just like one horsepower, which is defined as 746 W, presumably the strength of a single horse…
Got a car with a 100 Hp engine? It can generate 74.6 kW of power, i.e. accelerate a 1000 kg weight by 74.6 m/s2, which is ≈ 20 km/h speed increase every second, or in more popular terms: 0..100 km/h in 5 seconds (assuming no losses). But I digress…

The point is that all those SI units really make life easy. And they’re 100% logical…

Maxing out the Hameg scope

In AVR, Hardware on May 10, 2013 at 00:01

Yesterday’s post was about how test equipment can differ not only in terms of hardware, but also the software/firmware that comes with it (anyone hacking on the Owons or Rigols yet to make the software more feature-full?).

Here’s another example, where I’m using just about all the bells and whistles of the Hameg HMO series scopes – not for the heck of it, but because it really can help gain more insight about the circuit being examined.

This is my second attempt at understanding what sort of start up currents need to be available for the new JeeNode Micro v3 to properly power up:

I’m applying a 0..2V power up ramp (yellow line) as power supply, using a 1 Hz sawtooth signal. This again simulates an energy harvesting setup where the power supply slowly ramps up (the real thing would actually rise far more slowly, i.e. when using a solar cell + supercap, for example). The current consumed by the JNµ v3 (blue line) is measured by measuring the voltage drop across a 10 Ω resistor – as usual.

The current consumption starts at about 0.85V and rises until the power supply reaches about 1.4V. At that point, the current consumption is about 77 µA. Then the ATtiny84A comes out of reset, enters a very brief high-current mode (much higher than the peak shown, but this is averaged out), and then goes into ultra low-power sleep mode. The sketch running on the JNµ is the latest power_down.ino, here in simplified form:

#include <JeeLib.h>

void setup () {
    cli();
    Sleepy::powerDown();
}

void loop () {}

Note that since this is the new JNµ v3, the RFM12B module never even gets powered up, so there’s no need to initialise the radio and then put it in sleep mode.

The red line uses the Hameg’s advanced math features to perform digital filtering on top of the averaging already performed during acquisition: the averaging keeps the power-up spike visible (albeit distorted), at the cost of leaving some residual noise in the blue trace, while the IIR digital low-pass filter applied to that result then makes it possible to estimate the 77 µA current draw just before the ATtiny84A starts running.

Here’s the zoomed-in view, showing the interesting segment in even more detail:

The IIR filtering seen here is slightly different, with a little spike due to the following power-up spike, so the 86 µA reported here is slightly on the high side.

Note how the Hameg’s storage, high sensitivity, averaging, adjustable units display, variable vertical scale, math functions, on-screen measurements, on-screen cursors, and zooming all come together to produce a pretty informative screen shot of what is going on. Frankly, I wouldn’t know how to obtain this level of info in any other way.

So what’s all this fuss about measuring that 77 µA level?

Well, this is how much current the JNµ draws before it starts running its code. There’s nothing we can do to reduce this power consumption further until it reaches this point. In the case of energy harvesting, the supply – no matter how it’s generated – will have to be able to briefly deliver at least 77 µA to overcome the startup requirements. If it doesn’t, then the supply voltage (presumably a supercap or rechargeable battery) will never rise further, even though a JNµ can easily draw less than a tenth of that current once it has started up and goes into ultra-low power with brief occasional wake-ups to do the real work.

What I’m taking away from this, is that a solar energy setup will need to provide at least 0.1 mA somewhere during the day to get a JNµ started up. Once that happens, and as long as there is enough power to supply the average current needed, the node can then run at lower power levels. But whenever the supercap or battery runs out, another period with enough light is needed to generate that 0.1 mA again.

It all sounds ridiculously low, and in a way it is: 0.1 mA could be supplied for over two years by 3 AA batteries. The reason for going through all this trouble, is that I’d really like to find a way to run off indoor solar energy light levels. Even if it only works near a window, it would completely remove the need for batteries. It would allow me to just sprinkle such nodes where needed and collect data … forever.

Oscilloscope firmware

In Hardware on May 9, 2013 at 00:01

Oscilloscopes are very complex instruments. The “front end” is all about being able to capture a huge range of signals at a huge rate of speeds. This is what lets you hook up the same probe to AC mains one day, and pick up millivolt signals another day, and to collect many minutes of data on a single screen vs displaying the shape of a multi-MHz wave. This isn’t just about capture, at least as important is the triggering part: how to decide what to pick up for display on the screen.

For low sampling rates, it’s very easy to use an ADC and just collect some data points – as shown in this older weblog post, even AC mains, although triggering can be an issue.

With the Xminilab presented recently, a lot of this has been solved in software, supporting a pretty impressive range of options, even for triggering. The Xminilab is particularly interesting because the full source code is available.

But for serious work, you’ll need an Owon or Rigol scope. These can sample at up to 1 Gsa/s, i.e. one billion samples per second. Truly, truly capable front-ends, able to handle very wide voltage and acquisition speed ranges.

The Hameg HMO2024 is more expensive, and many of its specs are not much better than the Owon (worse even, in some cases: a smaller display size and less sample memory).

The devil is in the details. Here’s a recent screen from the HMO2024 (borders cropped):

And here’s my first cut at acquiring the same info on the Owon (click for full size):

Let me add that I now have lots of experience with the Hameg, and only just started using the Owon, so there might be relevant features I’ve failed to set up in an optimal fashion.

A couple of quick observations:

This is not a “typical” measurement setup: a very slow, low-amplitude signal is nothing like the usual measurements one would come across, with higher signal levels, and faster sampling rates. Then again, that’s part of the whole point of an oscilloscope: it’s so versatile that you end up using it in lots of situations!
As you can see, the Owon has a lot more pixels to display a signal on, so I was able to increase the voltage sensitivity one notch to get more detail, and capture a bit longer.
Some differences are obvious but not that important: the Owon provides less information on-screen about the current settings, and it does not use anti-aliasing for the traces (i.e. intensity variations to produce a fake “sharpening” effect of steep lines).

The two major differences are that: 1) the Hameg lets me apply additional digital signal processing to effectively reduce the random variations and smooth out the signal (this is done after capture, but before drawing things on-screen, i.e. all in software/firmware), and 2) the Hameg includes support for a “reference trace”, i.e. storing a previous trace in its built-in memory, and displaying it in white next to a new capture – to compare power consumption with and without WiFi, in this case.

Note that the Owon capture depth was set to 1,000 samples instead of the maximum 10 Msa, otherwise the screen would have shown a very wide red trace, almost completely swamping out the signal shown on screen. With this reduced setting, the current consumption is still fairly easy to estimate, despite the lack of low-pass filtering.

Is this a show-stopper for the Owon? Not really. It still gives a pretty good impression of the current consumption pattern during starup of the Carambola 2. If you really wanted to improve on this, you could insert an analog filter (a trivial RC filter with just 2 passive components would do). With a bit of extra work, I’m sure you can get at least as good a current consumption graph on the Owon.

The trade-off is (recurring) convenience and setup time vs. (up-front) equipment cost.

PS. The Rigol DS1052E does have a low-pass filter – every scope has different trade-offs!

PPS. For a great view into oscilloscope development over the past 5 years, see Dave Jones’ comparison video of the Rigol DS1052E and the new – phenomenal! – DS2000 series.

What if I turn the chip around?

In Hardware on May 8, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

Ok, you’re all excited, you’ve built some electronic circuit – either by assembling a kit, or all on a breadboard, or perhaps you’ve even go so far as to design and create a custom PCB.

Any non-trivial circuit will have polarised components on it, whether capacitors, diodes, transistors, regulators, or… the most common one in oh so many varieties: a “chip”, with 6..40 pins, or sometimes even more.

Mr. Murphy loves chips. Because sooner or later, you’ll connect one the wrong way around. Even if you know what you’re doing, sometimes the orientation marker on a chip is fairly hard to see, especially on the smaller SMD types.

So what happens if we put things in the wrong way around?

Obvious answer: it depends (on the chip).

Comforting answer: more often than not, nothing will happen, the thing will get hot, and it’ll still work fine once you fix the problem, i.e. turn the chip around and reconnect it.

The good news is that it’s not so easy to really damage most chips, with a few precautions:

use a “weak” power supply, i.e. one which can’t put out to much current, as current leads to heat, and heat is usually the cause of component damage – a lab power supply with adjustable “current limiting” set to a low value is a very good idea
keep your hands near the ON/OFF switch when powering up a circuit for the first time, keep your eyes open, and … use your nose: bad stuff due to heat often shows itself as smoke (by then, it’s often too late), and as components getting far too hot, and starting to smell a bit
for low-voltage circuits, and this includes almost all digital circuits: place your fingers on several of the key components right after turning power on: if you sense anything getting hot, turn off the power – NOW!
sensing heat is an excellent way to save a project from serious damage: we can easily tell if something heats up to 50 °C or more, yet most silicon-based chips will be able to heat up way beyond that before actually getting damaged (125..175 °C) – so as long as you turn the power off quickly enough, chances are that nothing really will break down, and chips and resistors will often start to smell – a useful warning sign!

Note that analog circuits tend to get damaged much more easily. Put a transistor the wrong way around, and it’ll probably go to never-never land the moment power is applied.

One reason digital chips are so resilient, is the fact that they are full of ESD diodes. These tend to be on each of the I/O pins of a chip, as protection against Electrostatic Discharge. Here’s what a typical I/O pin circuit on a digital chip looks like:

Nothing happens under normal conditions, since the diodes are all in blocking mode. When the I/O pin voltage rises above VCC or drops below GND, however, the diodes start to conduct, while trying to remove the charge, so that the voltage levels never reach values which might damage the sensitive oxide isolation (that’s the “O” in CMOS and MOSFET).

Now have a look at what happens when a chip gets powered up with bad voltages on two of the I/O pins (the light-blue parts are not conducting and can be ignored):

The way to look at this is that the pin(s) with the highest voltage will start feeding into the (internal) VCC connections, and the pins with the lowest voltage will start drawing current from the (internal) GND connections. Or, to put it a different way – some I/O pins will act as VCC and GND supply lines, albeit with some internal ESD diodes in between:

In this diagram, VCC and GND are fed from pins which were not intended as such!

As you can see, the diodes now start conducting as well, drawing a certain amount of current. If these currents are not higher than the diodes can handle (usually at least a few mA per diode), then the chip will act more or less like a short to the rest of the circuit. With a bit of luck, your power supply will decide to lower its output voltage and enter “current limiting” mode. The result: nothing works, but nothing truly dramatic happens either. It just gets hot and all the voltages end up being completely wrong.

Sooo… next time you power up your new project for the first time: stay alert, use your fingers, be ready to cut power, and… relax. If it doesn’t work right away (it hardly ever does!), you’ll usually have time to figure out the problems, fix them, and get going after all.

Note that there are no guarantees (things do occasionally break), but usually it’s fixable.

Electronics, Linux

Carambola 2 power consumption

In Hardware, Linux on May 7, 2013 at 00:01

The Carambola 2 mentioned yesterday is based on a SoC design which uses amazingly little power – considering that it’s running a full Linux-based OpenWrt setup.

There are a couple of ways to measure power consumption. If all you’re after is the average power on idle, then all you need to do is insert a multimeter in the power supply line and set it in the appropriate milliamp range. Wait a minute or so for the system to start up, and you’ll see that the Carambola 2 draws about 72 mA @ 5V, i.e. roughly a third of a watt.

If you have a lab power supply, you can simply read the power consumption on its display.

But given an oscilloscope, it’s actually much more informative to see what the power consumption graph is, i.e. over time. This will show the startup power use and also allows seeing more detail, since these systems often periodically cycle through different activities.

The setup for “seeing” power consumption is always the same: just insert a small resistor in series with the “Device Under Test”, and measure the voltage drop over that resistor:

Except that in this case, we need to use a smaller resistor to keep the voltage drop within bounds. Given that the expected currents will be over 100 mA, a 100 Ω resistor would completely mess up the setup. I found a 0.1 Ω SMD resistor in my lab supplies, so that’s what I used – mounting it on a 2-pin header for convenience:

With 0.1 Ω, a 100 mA current produces a voltage of 10 mV. This should have a negligible effect on the power supplied to the Carambola 2 (a 1 Ω resistor should also work fine).

Here’s the result on the scope – white is the default setup, yellow is with WiFi enabled:

Sure takes all the guesswork out of what the power consumption is doing on startup, eh?

Embedded Linux – Carambola 2

In Hardware, Linux on May 6, 2013 at 00:01

This has got to be one of the lowest-cost and simplest embedded Linux boards out there:

It’s the Carambola 2 by 8devices.com:

The 28 x 38 mm (!) bare board is €19 excl VAT and shipping, and the development bundle (as shown above) is €33. The latter has a Carambola2 permanently soldered onto it, with 2 Ethernet ports, a slave USB / console / power port, a USB host port, a WiFi chip antenna (which is no longer on the base board, unlike the original Carambola), and a switching power supply to generate 3.3V from the USB’s 5V.

The processor is a MIPS-based Atheros chip, and with 64 MB ram and 11 MB of available flash space, there is ample room to pre-populate this board with a lot of files and software.

The convenience of the development setup, is that it includes an FTDI chip, so it comes up as a USB serial connection – you just need to find out what port it’s on, connect to it at 115200 baud via a terminal utility such as “screen” on Mac or Linux, and you’ll be hacking around in OpenWrt Linux in no time.

Note that this setup is very different from a Raspberry Pi: MIPS ≠ ARM, for one. The RPi has a lot more performance and RAM, has hardware floating point, and is more like a complete (portable) computer with its HDMI video out port. The benefit of the Carambola 2 is its built-in WiFi, built-in flash, and its low power – more on that tomorrow.

Meet the Owon SDS 7102V – part 2

In Hardware on May 5, 2013 at 00:01

Today’s post continues where we left off yesterday. Here are the front-panel controls:

Nice and tidy. Absolutely effective, as far as I could establish in my first impressions. As with all modern scopes, there are lots of features behind all those buttons, and many of them lead to “soft menu’s”, i.e. menu’s shown on screen (on three sides sometimes: right, left, and bottom). That’s what the right and bottom buttons next to the screen are for. There’s one “multipurpose” rotary encoder knob, which is used when selecting from the occasional menu popping up on the left.

The only downside is that you can end up moving your hands around a lot while setting things up and while making adjustments. Coming from a different brand, I had some trouble remembering where averaging, FFT, trigger settings, etc. were, but that’s bound to get easier over time as muscle memory sets in. Because operating any complex instrument with lots of knobs and features really is about motions and muscle memory. It just takes a bit of time and practice.

One remarkable feature of this scope is its very deep 10 megasamples acquisition depth (it’s adjustable, from 1,000 samples up). This makes it very easy to take a single snapshot of an event, and then to zoom in to see specific events in full detail.

One use would be to decode serial communication signals such as UARTs and I2C data packets. There is no built-in decoding, so this needs to be done manually. Then again, you can save all 10 million samples to a USB stick so with some software it would be possible to perform such decoding automatically on a standard PC or Mac, albeit after-the-fact.

Power consumption is very low: 0.77W standby, 18W when turned on.

You might be wondering how this oscilloscope compares to the Xminilab and the Hameg HMO series – which are about a fifth and five times as expensive, respectively. But with such an extreme price range, it’s impossible to answer this question other than: the more you pay, the more you get. Pretty obvious, and also pretty useless as guideline, I’m afraid.

Would I buy the Xminilab if I had no more than $100 to spend? Yes. While it’s limited and does require a lot more ingenuity and patience, it can still help to understand what’s going on, and to address problems that couldn’t be solved without a scope.

Would I recommend the Owon for serious electronics use? Definitely. It lets you capture all the info you need, and “see” what’s going on – both analog and digitally – for frequencies up to dozens of MHz. With much larger display & more memory than the Rigol DS1052E.

Would I purchase a Hameg HMO series again, even though it’s so darn expensive? Yes. The software, the math features, the logic analyser, and the serial decoding – it all adds up, yet it’s still half the price of the “low end” Agilent models. And, not to be ignored: its (cropped but informative) screenshots are perfect for the 604 pixel width of this weblog!

I’ll explore the capabilities of the Owon SDS 7102V scope in more practical scenarios in the weeks to come. Stay tuned…

Meet the Owon SDS 7102V

In Hardware on May 4, 2013 at 00:01

Here’s another “loaner” from David Menting, this time it’s his scope, the Owon SDS 7102V – which is sales-speak for a dual-channel 100 MHz digital storage oscilloscope:

This unit is available in the Netherlands from EleShop, for € 450 incl VAT, which makes it only marginally more expensive than the ubiquitous Rigol DS1052E with 320×240 display and 50 MHz bandwidth.

This thing is amazingly thin (total size is 7 x 34 x 16 cm), yet packs an 800 x 600 pixel color LCD screen to present a really detailed display (click to see the full size image):

In a way, more is better. But keep in mind that the 8-bit ADC’s typically used in modern “affordable” scopes can only measure 256 different voltage levels full-scale. To really benefit from 512 or more vertical pixels resolution, you either need a 9-bit ADC or some sort of oversampling and averaging. Having said that, I would definitely consider 320×240 as low end nowadays – this screen is a huge improvement, in displaying much finer detail as well as in helping estimate voltage levels at a glance.

Here’s an example of just how much screen real-estate this scope has:

You might recognise the two waveforms above as the 10 MHz and 25 MHz signals generated by my signal generator – same as used in this recent weblog post.

Tomorrow, I’ll show you the front panel and I’ll add some comparative notes…

Instrument limits

In Hardware on May 3, 2013 at 00:01

Last week’s post illustrated some limitations of electronic measuring equipment. In this case, I was using the TTi TG2511 Arbitrary Waveform Generator (which I have yet to use for “arbitrary” waveforms) and the Hameg HMO2024 Digital Storage Oscilloscope.

The TG2511’s rise and fall times are specified in the neighbourhood of 10 ns, which has a fairly atrocious effect on a 25 MHz “square wave” signal:

(the scope’s own rise time is under 2 ns)

Both are excellent instruments, but already fairly high-end for hobbyist use. To put it in perspective: the total cost of this sort of equipment is more than a hundred JeeNodes with sensors! Add to that the fact that you only need the higher specs of these instruments once in a while (how often depends of course on your level and depth of interest), and it’s pretty obvious that it can be very hard to justify such expenses.

I’ve always been annoyed by this. And I’ve always been on the lookout for alternatives:

That’s the Xminilab, mentioned recently, and a sine-wave generator from eBay. The total cost for both is around €100.

Unfortunately, lower-end equipment really does have lower-end specifications. The measurements made yesterday could not have been done with the above, for example: sine waves are not square waves, and the 2 megasamples/second of the Xminilab scope is not fast enough to analyse rise times at 1 MHz, let alone 10 MHz.

Tomorrow, I’ll explore (“review” is too big a word for it) a more affordable modern oscilloscope, to show what can and cannot be done with it.

Autotransformer

In Hardware on May 2, 2013 at 00:01

The other day, someone gave me an autotransformer – a hefty 10 kg of metal and wires:

Made by Philips, probably well over half a century ago (even before Philips had a logo?):

AC mains did not include grounding at the time, just 2 banana jacks spaced 19 mm apart:

So what does it do? Well, an autotransformer (a.k.a. Variac) allows you to generate an adjustable AC voltage from the fixed AC mains voltage. At the time, AC mains was 220V – nowadays, it’s 230V in Europe, so the output should now reach 260/220*230 ≈ 272 VAC.

Here’s the schematic, similar to the one printed on the side of this device:

(this isn’t fully variable, like the unit above, but the taps are a first approximation)

One way to explain what’s going on – at least as first approximation – is that it works like a transformer, but with a variable number of turns on the secondary side. Think of the incoming voltage as generating an alternating magnetic field of a certain strength, with X Volts per turn. The “tap” (which is a mechanical wiper) makes contact with one of the turns of all the turns laid out in a circular fashion, creating a circuit with a variable number of turns. The more turns, the higher the output voltage.

The intriguing bit is that the output voltage can actually exceed the input voltage, by adding a few more spare turns at the top – or equivalently: by placing the input voltage on a tap and not entirely at the end of the coil.

Note that the output of such an autotransformer is not isolated from the input, unlike regular transformers with separate primary and secondary coils.

The other difference is that part of the energy is not transferred as magnetic flux, but directly through the shared windings. It merely acts “more or less” like a regular transformer, in practical use.

I’m very pleased with this gift, which will allow me to explore the effects of a varying AC mains voltage on all sorts of appliances, power supplies, etc. – from very low voltages to somewhat over the normal 230 VAC.

What if the supply is under 3.3V?

In AVR, Hardware on May 1, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

To follow up on a great suggestion from Martyn, here’s a post about the different trade-offs and implications of running an ATmega at lower voltages.

The standard Arduino Uno, and all models before it, have always operated the ATmega at 5.0V – which used to be the standard TTL levels used in the 7400 series of chips used in the 1960’s and 1970’s. The key benefit of a single standardised voltage level being that it made it possible to combine different chips from different vendors.

To this day, even though most semiconductor logic has evolved from bipolar junction transistor to CMOS, the voltage level has often been kept at 5V, with slightly adjusted – but compatible – voltage levels for “0” and “1”, respectively.

Nowadays, chips operate at lower voltages because it leads to lower power consumption and because it is a better fit for batteries and LiPo cells. In fact, lots of new chips operate at 3.3V and will not even tolerate 5.0V.

The ATmega328p is specified to run at a very wide range, from 1.8V all the way up to 5.5V. Which is great for ultra low-power use, supporting different battery options, and even for energy harvesting scenario’ such as a solar panel charging a supercap, for example.

But there are still many trade-offs to be aware of!

The first one is the system clock rate, which is limited (see also this older post):

If you look closely, you’ll see that 16 MHz is out of spec for 3.3V, the way the JeeNode is running, that is. In practice, this has never caused any known problems, but lowering the voltage further might just be too much.

The good news is that it’s not really the crystal oscillator which is causing problems, but the main circuitry of the ATmega, and that there’s a very easy fix for it: when running at voltages below 3.3V, you should set the ATmega’s pre-scaler to 2, causing the system clock to run at 8 MHz. When running even lower, perhaps under 2.4 V or so, set the pre-scaler to 4, i.e. run the system clock at 4 MHz. This also explains the presence of the divide-by-8 fuse bit: when you need to start up at low voltages, you can force the ATmega to always power up with a clock pre-scaler of 8, and then adjust the pre-scaler under software control after power-up, once the voltage has been verified to be sufficient. Without this setting, an ATmega would not be able to reliably start up at 1.8V, even if it’s meant to run much faster most of the time.

Note that the RF12 driver will still work at 4 MHz, but not less: the interrupt service time will be too slow for proper operation at any slower rate.

Another important issue to be aware of when running a JeeNode at voltages under 3.3V, is that the MCP1702 voltage regulator will no longer be able to regulate the incoming voltage. It can only reduce the input voltage for regulation, so when there is no “headroom” left, the regulator will just pass whatever is left, minus a small “dropout” voltage difference. Hence its name LDO: Low-DropOut.

The problem is that all LDO regulators start consuming (i.e. wasting) more idle current in this situation. See this weblog post for the measured values – which can be substantial!

To avoid this, you should really disconnect the LDO altogether, or at least its ground pin.

A third aspect of running at lower voltages, is that you need to verify that all the parts of the circuit continue to work. This applies to sensors as well as to the RFM12B radio – which should only be operated between 2.2V and 3.8V.

Actually, some experiments a while back showed that the radio could work down to 1.85V, but I suspect that things like transmit power will be greatly reduced at such supply levels.

Lastly, when the supply voltage is lowered, you need to keep some secondary effects in mind: the ADC will operate against a lower reference voltage as well, so its scale will change. One ADC step will be just under 3.3 mV when the supply is 3.3V, but this drops to under 2.0 mV per step with a 2.0V supply.

To summarise: yes, an ATmega/ATtiny can run at voltages below 3.3V, and even an entire JeeNode can, but you need to reduce the system clock by switching the pre-scaler to 2 or 4, and you need to make sure that all parts of your setup can handle these lower voltages.

Meet the Manson NSP 3630

In Hardware on Apr 30, 2013 at 00:01

It’s always nice to explore more equipment, to see how it behaves in the lab. I already have a very nice dual-voltage lab power supply, but this one is interesting due to its relatively low cost (€90 + shipping), fairly high power, and very convenient small size:

It’s the Manson NSP 3630, available from Reichelt in Germany by mail-order. At 27 x 15 x 7 cm, it really should easily fit in most home labs. With many thanks to David Menting for letting me play with it a bit and report some first impressions.

The display is quite simple, yet still nicely readable:

Power consumption, without any load is 0.07W when turned off with the power switch on the back of the unit, and about 2.0W when turned on, without load.

There are two (optical encoder) rotary knobs to adjust the maximum voltage and current, respecively, over a range of 0.7 .. 36V and 0 .. 3A – i.e. plenty for most situations.

A drawback with this particular supply, is that it’s a bit of a hack to pre-set the current limit. You can turn it down during use to reduce the limit to the point where the voltage starts dropping, but if you want to set it up ahead of time, then the way to do it is to short out the power supply while adjusting the knob, to see the value it displays.

This is a switched-mode power supply, which explains why it is so small and requires only a small fan, but it does lead to some residual noise on the output. Hooking it up to the scope, still under no-load conditions, you can see that the output varies between about +10 mV and -20 mV of “ripple” above and under the preset value, respectively (5V in this case):

To produce this image, the scope was set to “peak-detect” mode, which captures the high and low value at each point in time, and the trace is drawn in “envelope” mode, which is a variation of persistent display showing the most extreme values ever reached as long as the scope is kept on. The last trace is the one shown in the middle, while the top and bottom lines are the largest variations ever reached – I think I left it running for a minute or so.

It’s a pretty good result, actually, for a switching power supply. Variations of this kind should not cause any problems for most digital circuits, which usually can tolerate fairly large variations on the power supply lines.

Three laws – part 3

In Hardware on Apr 29, 2013 at 00:01

Yesterday’s post was about Kirchoff’s Current Law.

Now let’s look at the second version of that law, Kirchhoff’s Voltage law:

This law says something about the voltages in a circuit: voltages cancel out, regardless of which way you follow a path in the circuit, i.e.:

V1 - V2 - V3 = 0    (hence V1 = V2 + v3)

But also:

V3 - V4 - V5 = 0    (hence V3 = V4 + V5)

And:

V1 - V2 - V4 - V5 = 0    (hence V1 = V2 + V4 + V5)

The signs are based on how the arrows are drawn: voltages are always relative, so it all depends on the direction of each of those arrows. Since V2 and V3 are opposite to the direction of “following” a single path through the circuit, they end up negative in the above equation. Same for V4 and V5.

Now this version of Kichhoff’s law is really useful. If each of the resistors has the same value (it doesn’t matter what the value is), then we can reason about the voltages in different parts of the circuit, even when only V1 is known at the start.

Let’s look at this circuit again in terms of voltages, with V1 set to 3V:

Since V1 = V2 + V3, and all resistors have the same value, it’s a safe guess that the voltage over both will be the same. A more exact reasoning is to include the currents, and since they are the same for the two resistors on the left, we know that the voltages will be the same (Ohm’s law, regardless of the value of these resistors – as long as they are the same).

Perhaps a bit more surprising is that V4 is 0V. This is again a consequence of Ohm’s law: since the pins on the right are not connected, no current will flow. With no current, the voltage over a resistor is always 0V (Ohm’s law, again).

Since V4 is 0V, and V2 = V4 + V5 as we saw above, V5 must be 1.5V, the same as V2.

Note how a voltage over a resistor can be zero, and over two open pins can be non-zero.

If we use a multi-meter with a really high input resistance (any modern multi-meter will do, usually they have 10 MΩ or more), to make sure no current starts flowing, then we can indeed measure the voltage to be half of the 3V between top and bottom, i.e. 1.5V.

The main point to take away from this, is that the three laws are intimately inter-connected. Given known resistors, which is often the case, Ohm’s law dictates the relationship between voltage and current, and with the two variants of Kirchhoff’s law, it is usually possible to “reason your way into” the different points in a circuit, given an externally applied power supply.

One last example: what is the equivalent resistance of two resistors of 1000 Ω in parallel? Well, say we apply voltage V1, then the current through one resistor will be V1/1000. The same current will go through the other resistor, since it too has V1 on both pins. So the total current of the two in parallel will be 2 x V1 / 1000 = V1 / 500. What is the resistance when we apply V1 and see a current V1 / 500 flowing? Again, Ohm’s law: R = U / I, i.o.w. R = V1 / (V1 / 500) = 500. So the general answer is: the equivalent resistance of two resistors in parallel is half their resistance. A direct consequence of Ohm’s and Kirchhoff’s laws.

Get used to the three laws, and with a bit of practice, the rest should fall into place!

Three laws – part 2

In Hardware on Apr 28, 2013 at 00:01

After Mr. Ohm yesterday, let’s see what Mr. Kirchhoff has to say.

Kirchhoff’s First Law is about current. In a nutshell – what goes in, must come out:

I’ve drawn resistors, but that’s really irrelevant here – each component could be anything.

The current I1 must be the same as the current I2, It does not matter what I3 is in this case (assuming the two pins next to it are not feeding or drawing any outside current).

Also, if I3 is zero, i.e. if the pins are not connected to anything at all, then the current through the leftmost resistors is identical. In this case, they are essentially in series, with the resistor on the right not doing anything at all (no current = no voltage drop = Ohm’s Law).

This makes it possible to reason about that point in the middle, where the three resistors meet. The currents at that point must cancel out: that’s what Kirchhoff’s Current Law says.

Suppose all three resistors are 1 kΩ, and the current I1 is 1 mA:

If the two pins on the right are left open, no current will flow there. So the same current I1 (which is also the same as I2) will flow through both resistors on the left. Total voltage drop from top to bottom will be 1 mA x 1 kΩ = 1V on the top resistor and another 1V on the bottom one, for a total voltage of 2V across the left two pins.

Or to put it more practically: if you place a 2V supply across those left two pins, then 1 mA will flow. The voltage in the center point will be halfway, i.e. at 1V.

What will happen when we short the pins on the right?

Again, there’s 1 mA flowing in from the top, so there will be 1 mA coming out the bottom. The bottom-left and right resistor will together see a current of 1 mA going through them. Since they are both the same 1 kΩ, it should not come as a surprise that each resistor will get half the current, i.e. 0.5 mA each. Total voltage from top to bottom will be 1.5V.

This isn’t such a great example in terms of practical use, since normally the reasoning goes the other way around: what current will flow when I apply voltage X to the entire circuit?

That’s the other version of this law, described tomorrow.

Three laws – part 1

In Hardware on Apr 27, 2013 at 00:01

It’s always a puzzle to predict just what will happen when you hook up some components.

But as mentioned in the what-if series, it’s really useful to be able to do so, to avoid surprises and damage. Also for questions such as: Why does a higher voltage cause a higher risk of damage in one case and less so in the other? Why do I need a resistor in series, and of what value? What if I don’t have the right resistor or a different voltage?

Lots of complex issues, but the simplest and most important case usually is static analysis and DC (direct current) voltages, i.e. when only one or two states are involved, and not so much the switching and AC (alternating current) behaviours.

You just need to get familiar with three “laws” of electricity:

Ohm’s Law – given two of: voltage, current, and resistance, we can predict the third.
Kirchhoff’s Current Law – current always adds up: what goes in, must come out.
Kirchhoff’s Voltage Law – how voltages “spread” across interconnected components.

That and learning what the basic behaviour is of resistors, diodes, capacitors, etc, and you’ve got all the knowledge you need to “see” what a circuit does, before even building it and trying it out. And by this I really mean literally “visualising” what is going on – it only takes a little practice to turn this into a very intuitive skill.

You just have to grasp the essence of those three laws. So let’s get on with it, eh?

Ohm’s Law

This is by far the most important one. It says everything about resistance. The unit of resistance is – not surprisingly – the “Ohm”: a resistor of 1 Ohm will let 1 Ampère of current flow when you apply 1 Volt of electric potential difference over it. The formula is:

U = I x R

(U = voltage, I = current, R = resistance)

Same law, different uses, by simple algebraic manipulation: I = U / R, and R = U / I. If you know two of the units, you can calculate the 3rd.

What happens when I touch both poles of a car battery?
My skin resistance will be some 100 kΩ, so I = U / R = 12 / 100,000 = 0.000,12 A = 120 µA. A tiny current, I wouldn’t sense a thing, so the answer is: “nothing happens”.
What happens when I place a metallic nail across that same 12V car battery?
Let’s say the resistance of that nail is 0.1 Ω, i.e. almost a short, so I = U / R = 12 / 0.1 = 120 A, a huge amount of current. The nail will heat up like crazy, it might even melt!

Same battery, very different outcomes.

And it’s not just useful to predict such extreme cases. It also helps understand why some hookups are inherently safe: if my power supply delivers no more than 5V, and I am playing with resistors of 1 kΩ or more, then no matter how I hook things up (apart from shorting things out), there will never be more than I = U / R = 5 / 1,000 = 0.005 A = 5 mA of current through my circuit. A 1 kΩ resistor in series with just about any component will “limit” the current to 5 mA, which virtually prevents damage to just about any component.

Another example: suppose I am using a 12 V power supply, and want to turn on an LED with it. Most LED’s glow nicely at 20 mA. So if I put a R = U / I = 12 / 0.020 = 600 Ω resistor in series with the LED, I can be certain that the LED won’t get damaged. Better still, if I only have a 1 kΩ = 1000 Ω resistor, I can predict that it’ll probably work just fine in this same circuit as the current will be at most I = U / R = 12 / 1,000 = 12 mA. Using a 100 Ω resistor would be a bad idea (max current 120 mA), and using a 10 kΩ resistor probably also wouldn’t work (1.2 mA might be too little to make the LED light up).

These are all approximations, but they are extremely useful – even as such.

Some consequences of the simple ” U = I x R ” formula Georg Simon Ohm gave us:

twice the voltage => twice the current
twice the resistance => half the current
twice the current => twice the voltage drop

One thing to take away from all this, is that it’s not a bad idea to buy some 100 Ω, 1 kΩ, and 10 kΩ resistors. Having a bunch of spare resistors can often come in handy, as a way to limit the current (and hence avoid damage), and these three values are often all you need to try out a few things in circuits running at 1.5 .. 12V.

Tomorrow, we’ll give the stage to Gustav Kirchhoff!

What if I mix 3.3/5.0V – part 3

In Hardware on Apr 26, 2013 at 00:01

Welcome to the weekly What-If series, also available via the Café wiki.

There’s still much more to say about all this – as can be expected. One of the suggestions made in the comments was to use a few diodes in forward direction. Since these each have about 0.65V drop, three of them ought to bring down the voltage from 5.0V to 3.3V.

Time to hook up the signal generator and scope again. Be prepared for some surprises!

As I mentioned in my original post, the “official” way to handle this, is to use a “level converter” chip, which is based on some active circuitry, i.e. some transistors or MOSFETs. The resistor solutions described yesterday are less accurate, as you’ll see…

Here is a 1 MHz square wave @ 5V (yellow) feeding yesterday’s 4.7 kΩ + 10 kΩ resistive voltage divider to produce a 3.3V signal (purple):

That’s quite a different signal coming out! A typical capacitive charge / low-pass effect.

Note that the signal generator has a ≈ 10 nS rise-time, i.e. the edges are not completely vertical, and that the Hameg scope probe has a 14 pF loading capacitance, according to the specs. So some of these effects are artefacts of this measurement setup.

Let’s raise the frequency to 10 MHz (the horizontal scale is now a very fast 10 ns/div):

Hardly a square wave, and no well-defined 0-to-3.3V transitions either, as you can see.

Now let’s try this circuit:

The reasoning being that the diodes will “drop” the voltage from its high 5V level to 3.3V:

Quite an asymmetric effect, although lowering the resistor to 1 kΩ ought to improve it.

The above is again a 1 MHz square wave input, and here’s the same at 10 MHz:

This final setup is so far off the desired voltage levels that it probably won’t work.

Given these outcomes, I’m inclined to stick with a single 10 kΩ resistor in series. Or perhaps drop it to 1 kΩ to get better rise and fall times. Active MOSFET-based level-shifting circuits are starting to make a lot more sense now – they exist for a reason!

What if I mix 3.3/5.0V – part 2

In Hardware on Apr 25, 2013 at 00:01

Welcome to the new weekly What-If series, also available via the Café wiki.

Yesterday’s post was about mixing 3.3V logic levels with 5V logic levels.

The real trouble, apart from things not working, is damaging some component, of course. And in electronics, almost all damage comes from overheating. At some point (well over 100 °C, usually), chips really do get “fried” and irrevocably damaged occasionally.

The trick is to avoid overheating. This in often easy to do by limiting the current that can flow. How do you limit the current? Simple: make sure there are some resistors in series!

But first, let’s examine what’s really going on when we connect a 5V logic “1” to an input which handles only 3.3V logic levels:

On the left, the typical circuit inside a digital chip at each I/O pin. The essential ingredients are two ESD protection diodes to VCC and GND, respectively, and the MOSFET input gate.

The diodes are placed in the “blocking” direction, i.e. they normally do nothing but block the current. The MOSFET gate is a very high impedance input, essentially it acts just like a capacitor, in fact. The rest of the input circuitry can be ignored for our purposes.

So normally, input signals on such a pin just “float” and follow whatever voltage is applied. Until the voltage is too high, or too low, that is.

On the right, I’ve redrawn the exact same circuit, but “lifting” the input well above VCC level. To make this clear, I’ve drawn the input pin above the VCC pin, as an intuitive way to represent voltage as height in the diagram.

Now you can see what happens above VCC + 0.65 or so: the top diode will start to conduct in this situation. So if the input is set to 5V, and VCC is 3.3V, then the diode will become a conductor and try to pull either 5V down or 3.3V up, to reach equilibrium again.

This is a danger sign. The amount of current flowing will rise as long as these voltages are more than about 0.65 V apart. If both power supplies are very strong, there could be several amps of current – the 5V supply could even start powering the 3.3V circuit!

And that’s where the damage-through-heat comes in: a 1 A current over a diode with a 0.65 V difference leads to 0.65 W of heat being dissipated. Far more than these tiny on-chip diodes can handle. In fact, they really are only designed to carry up to a milliamp or so. The result: a “blown” on-chip diode, and since the voltage difference continues to exist, the damage will probably propagate to other diodes and components on the chip.

There are a few ways to prevent this. One is to use special “level-converter” chips, designed to take one voltage on the input, and then generate a different voltage on the output.

But there are much simpler ways to deal with such small differences, especially when the pins are all close together and on the same board:

On the left, a traditional 4.7 kΩ + 10 kΩ resistive “voltage divider”, which takes one voltage and divides it down to a lower voltage. This works, but in this case we can even get by with a single resistor, as shown on the right.

The reason the single resistor works, is that current will start to flow through the diode as before, but now also through the 10 kΩ resistor. Since the circuit seeks equilibrium, in this case, there will be about 5.0 – 3.3 = 1.7 V across resistor + diode, i.e. ≈ 1 V across the resistor. With a 10 kΩ resistor, it only takes 0.1 mA of current to generate a corresponding voltage drop, so that’s when equilibrium will be reached. These current levels are completely harmless and can easily be sustained by the on-chip diode.

So there you have it: we’ve explained why direct connections might lead to overheating, and how a 1..10 kΩ resistor in series can prevent it, while still allowing the circuit to work.

All this required, was some theory and a basic understanding of the internal circuitry.

PS. These resistor solutions are sensitive to noise and capacitive loading (they act as low-pass filters), so this only works well when signal lines are short, a few cm or so. For reliable high-speed signaling over longer distances, a level-shifter chip would be a better way to go.

What if I mix 3.3V and 5V?

In Hardware on Apr 24, 2013 at 00:01

Welcome to the new weekly What-If series, also available via the Café wiki.

As you probably know, mixing 3.3V logic with 5V logic is usually a bad idea, but why and what if you need to do it anyway?

This topic is too complex for a single post, but let’s just start and see where it leads to:

VCC in these examples is the supply voltage, i.e. either 3.3V or 5.0V, depending on which chip we’re looking at. The goal being to connect a mix of these.
Digital I/O pins work by treating everything below a certain voltage as “0” and everything above another voltage as “1”. In between, the levels are undefined and could be interpreted either way, depending on temperature, stray capacitances, moon phases, who knows…
For the ATmega328, for example, everything between -0.5V and 0.3 x VCC is treated as “0” and everything between 0.6 x VCC and VCC+0.5V as “1”.
For 5V signals, that translates to: under 1.5V is “0” and over 3.0V is “1”, respectively.
Also relevant, is that unloaded output pins tend to be very close to the 0V and VCC ground and power supply levels, respectively.

So mixing is in fact not a problem at all for the following scenario: 3.3V levels for output signals, tied to 5V levels for the input signals. If all you need, is to read logic levels on say a 5V Arduino Uno from a 3.3V JeeNode, then just tie the signals together and you’re all set.

Connecting a 3.3V level output pin to a 5V level input pin works fine.

The problem occurs in the other direction: a “1” output on a 5V logic level is about 5V, whereas the maximum allowed input level for a “1” on a chip powered by 3.3V is 3.3+0.5, i.e. at most 3.8V.

Hooking these together without taking care of the problem will lead to problems, such as overheating chips and even smoke or fire (although this is almost impossible with simple battery- or USB-powered hookups).

Tomorrow I’ll describe the cause of these problems, along with some simple solutions.

New series – What If?

In Hardware, News, Software on Apr 23, 2013 at 00:01

Questions are very useful: “what would happen if…” is the foundation of science, after all.

Conjectures and Refutations is a famous book by the late philosopher Sir Karl Popper. I could not possibly summarise it (heck, I haven’t even read it), but what I take away from what I’ve read and heard about it, is that theories can be judged on their predictive value. A theory in itself is no more than an intellectual exercise, but its real value lies in being able to apply it to what-if questions. The stronger a theory, the better it should predict outcomes. The way to “refute” a theory, is to come up with an example where it fails. Rinse and repeat, and you’ve captured the essence of science.

Want to predict what will happen when you place a 100 Ω resistor across a 9V battery? That’s easy, given the proper theory: take Ohm’s Law (i.e. a theory which has stood the test of time), and apply it – a current of ~~≈ 11~~ 90 mA will flow. Actually a bit less due to the internal resistance of the battery, which goes to show how strong theories can be refined further, leading to even more accurate predictions.

The what-if question is a great way to experiment, especially in electronics and electro-mechanics, because it lets you be prepared and avoid silly (and sometimes catastrophic) outcomes, such as a damaged component, a harmful burn, or even an explosion.

This approach lends itself to all sorts of practical questions:

What if I short out a 3x AA battery pack?
What if I connect my chip the wrong way around?
What if I have to use a 12V power supply instead of 5V?

But also issues as varied as:

What if I omit a certain component from my circuit?
What if I unplug the Raspberry Pi without shutting it down?
What if I wanted to use HouseMon in combination with MySQL?

Properly phrased, what-if questions are essential for practical experiments, and – by extension – also the key to building useful circuits and automated installations.

A useful variation of the what-if question is to help predict “bad” outcomes and estimate the risk of an experiment, such as: can shorting out my power supply cause real damage?

Starting tomorrow, I’m launching a new series on this weblog, titled “What-If Wednesday”. As far as I’m concerned, it can run as long as there are interesting questions I can answer, so please feel free to suggest lots of topics in the comments below. These weekly posts will be tagged What-If, and I’m also setting up a new wiki page to collect them all.

Sooo… please help me out folks, and send in some nice what-if questions!

Cheap power analysis

In Hardware on Apr 21, 2013 at 00:01

Remember this screen shot?

It was a carefully captured analysis of the power consumption of a JeeNode, running the RoomNode sketch, and sending / receiving wireless RFM12B packets. There’s a fantastic amount of info in there, to help understand which part of the code and which activity is drawing the most power. It was a great help at the time to reduce power consumption, allowing these nodes to run well over a year on a couple of AA batteries.

Trouble with this, is that you need an expensive piece of equipment, called an oscilloscope. Long-time readers might remember that I’ve written extensively about this. These things cost anywhere from a few hundred Euro, to thousands, or even tens of thousands for high-end units. I ended up settling for a Hameg HMO2024, which is a great instrument, but with a pretty hefty price of well over €1000.

So how would you go about analysing the power consumption of your sketch without plunking down this sort of cash? Well, there really are not that many alternatives, you have to see the current-vs-time graph to be able to understand what’s going on.

Luckily, there is a fairly capable little unit from Gabotronics, called the Xminilab. It pushes an ATXmega (note the “X”) to its limits, allowing it to capture quite a bit of information, just like its bigger brothers. It even includes things like FFT analysis, an 8-channel Logic Analyser, and an AWG Signal Generator! Last but not least, the software is open source.

Interested in how capable this $69 device is? Well, check this out:

Do you recognise the waveform? The Xminilab has captured a packet transmission, a bit like the one shown at the start of this post (it’s a different sketch, i.e. radioBlip2, hence a different pattern). It may not look like much, but it should be sufficient to see the effect of changes in the code and to optimise power consumption with it.

So, do you need a scope? IMO, anyone wishing to explore electronics should have one. Whether second-hand or the above-mentioned Xminilab, it really helps to be able to see things in a way where our human senses fall short – such as these brief events. It’s the most versatile instrument in the lab, if you ask me – even with a 128×64 pixel LCD screen.

PS. I don’t recommend the even lower-cost $49 Xprotolab (which I also have). It has the same functionality, but with its tiny OLED display it really is too hard to read, IMO.

Home automation, LowPower, AC Mains

Automated + manual 230V

In Hardware on Apr 20, 2013 at 00:01

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

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

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

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

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

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

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

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

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

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

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

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

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

(9)50 days and counting

In AVR, Hardware, Software on Apr 18, 2013 at 00:01

The new JeeNode Micro has joined the ranks of the test nodes running here to determine battery life in real time. The oldest one has been running over 2 and a half years now:

That LiPo battery has a capacity of 1300 mAh, and since it’s still running, this implies that the average current draw must be under 1300/24/950 = 57 µA, including self-discharge.

The other two battery tests now running here are based on the new JeeNode Micro v3, i.e. this one – using a boost converter:

… and another one using a coin cell. Here’s a picture of a slightly older version:

The boost version is running off a rechargeable AA battery, of type Eneloop, which I use all over the house now. These batteries hold 1900 mAh, but there’s a substantial penalty for running off one AA cell with a boost converter:

energy is not free, i.e. drawing 10 µA at 3.3V means we will need to draw 30 µA at 1.1V, even if we could use a 100% efficient boost converter
real-world efficiency is more like 70..80% at these levels, so make that 40..45 µA
the boost converter has some idle current consumption, probably 10..20 µA, so this means we’ll draw 50..65 µA even if the JeeNode Micro only uses up 10 µA at 3.3V (actually, it’s 3.0V in the latest JNµ)

This would translate to 1900/.065/24/365, i.e. ≈ 3-year life. Or perhaps 2, if we account for the Eneloop’s 85% per year self-discharge.

The coin cell option runs off a CR2032 battery, which is rated at about 225 mAh, i.e. considerably less than the above options. Still, since there are no boost converter losses, this translates to 225/0.010/24/365, i.e. ≈ 2.5 years of life if the JNµ draws only 10 µA.

These figures look excellent, but keep in mind that 10 µA average power consumption is a very very optimistic value, particularly when there are sensors hooked up and packets are being sent out. I’d be quite happy with a 6-month battery life for a single AA or a coin cell.

For reference, here is an earlier post about all these power calculations.

Here are the current reports I’m getting via HouseMon:

That’s just about 50 days off a coin cell. Let’s see how it holds up. The nice bit in these tests is that the new nodes now report several different voltage level measurements as well (this also consumes some energy!). They haven’t dropped much yet, but when they do, I hope that we’ll be able to use the drop as a predictor.

Onwards!

JeeNode Micro start-up power

In AVR, Hardware on Mar 29, 2013 at 00:01

The JeeNode Micro v3 includes a P-channel MOSFET to control power to the RFM12B radio. This isn’t just a new gimmick – the goal was to “fix” the RFM12B wireless radio’s startup power consumption, which can prevent an ultra-low power source from ever building up a high enough supply voltage for a JeeNode to start up.

Now that the JNµ is in production, it’s time to measure how well such an approach works. Get ready for a bunch of scope screenshots, all based on the same circuit as before:

… except that now the entire JeeNode Micro is in there, and I’m using a 10 Ω resistor.

I’ll be applying a 1 Hz ramp signal going from 0.0 to 3.0V using the power booster behind a signal generator, to see exactly what amount of current is being drawn. In all the images below, the yellow trace is the input voltage (i.e. a simulated power supply), and the blue trace is the voltage over the 10 Ω resistor – that means 1 vertical division on the blue trace corresponds to 0.5 mA when the display shows 5 mV/div:

The above image is just a baseline: a simple blink sketch which never enables the radio, and which then toggles some I/O pins every 500 ms. As you can see, the ATtiny84 comes out of power-on reset at about 1.4V and ends up drawing about 3.5 mA at 3.0V.

Fuses are set to low=C2 high=D7 ext=FF, i.e. BOD disabled, startup asap on RC @ 8Mhz.

Now let’s look at the same setup with the JNµ running radioBlip2.ino:

This time, the sketch enables the MOSFET to power up the radio, measures the battery voltage, tries to send out a packet (this will fail at 1.4V), and goes into deep sleep. A short but very quick (and high!) blip before power consumption drops to almost zero.

The third measurement is with a sketch doing nothing but powering down right away:

#include <JeeLib.h>

void setup () {
    cli(); // disable all interrupts
    Sleepy::powerDown();
}

void loop () {}

Which produces this result:

I’ve bumped the scope sensitivity up to its maximum of 1 mV/div (i.e. 100 µA/div) and am now adding a lot of averaging to try and keep the displayed noise levels low. The “blip” is the ATtiny getting out of reset and powering down completely.

As last test, I repeated the above, but now using a sweep of 10 s (0.1 Hz), and filtering the signal through the lowest low-pass setting available, i.e. 5 Hz. This loses the important spike at 1.4V, which is of course still there, but improves the readout of the baseline:

As you can see, the power consumption now never rises above ≈ 60 µA – that’s a ten-fold improvement over what we get with the RFM12B connected to power in the standard way.

The shape of this curve is quite interesting: it’s essentially resistive (since it’s more or less linear), but the current starts at 1.2V, i.e. after overcoming two extra diode drops.

This is the power-up “hump” which any ultra-low power supply based on solar cells or other energy harvesting techniques will need to overcome, so that the ATtiny can switch itself into power down mode and let the supply voltage rise further.

I think that’s an excellent result, and am looking forward to trying a few things out!

Wild goose chase

In AVR, Hardware, Software on Mar 25, 2013 at 00:01

Sometimes, when messing with stuff, you end up in a blind alley which makes no sense…

This happened to me a few days ago, as I was trying to get a good setup going for programming the new JeeNode Micro v3.

The code in the IDE was working, I was able to program the JNµ via avrdude on the command line, but for some crazy reason, the same thing just kept failing when launched through the new 1.5.2 Arduino IDE. Getting that to work would make all the difference in the world, since it means you don’t need to install anything other than the IDE (on any platform) and then simply drop in the ide-hardware folder.

Very odd: a Flash Board which works on one Mac with avrdude, but fails with the IDE, which also uses avrdude. Time to set up the scope in Logic Analyser mode! Lots of wires, lots of configuration to identity all the signals, and then the fun starts: locating the spot in the data stream which would allow me to see what was going on.

Here is a peek at the SPI bus, decoded where it is reporting the ATtiny84 signature bytes:

Looks ok. Next, instead of looking at the SPI bus, I looked at the 9600 baud serial data:

It’s a slower time scale, since the bit stream is not as fast, thus allowing to capture more information (2 M samples are not that much when sampling at fixed time intervals, since you have to sample often enough to reliably decode the data stream).

I even suspected the power supply lines, and had a look at VCC as an analog trace:

And although it’s not very clean, this wasn’t the problem either. Drat…

Since the verification was failing, I decided to capture the data read-back in the second half of the programming process. The way to do this, is to set the trigger on the RESET line going low at the start, and then delaying the capture by about 4 seconds. As you can see in that last screenshot, this is the point where avrdude switches from writing data into flash memory to reading the data back.

And sure enough, the data read back was wrong. Not much, but just some bits flipped – consistently, and reproducably!

It wasn’t a hardware problem after all! A wild good chase: final episode tomorrow…

JeeNode Micro breakout

In AVR, Hardware on Mar 24, 2013 at 00:01

While messing around with a bunch of JeeNode Micro’s here, I decided to create a little convenience breakout board for it:

Sooo many ways to mess up – it definitely helps to avoid silly mistakes! This particular board doesn’t do that much, but it’s still a nice convenience when you’re drowning in cables and trying to debug some of the nastier bits, such as the Flash Board ISP programmer:

The above setup was the result of what turned out to be a wild goose chase – stay tuned…

Programming the JNµ – at last!

In AVR, Hardware, Software on Mar 21, 2013 at 00:01

Yesterday’s post shows that it the JNµ can be easily be programmed using the standard Arduino IDE, if you get all the pieces right (isn’t that always the case?):

The easiest way to get the connections right, is to assemble a custom cable (more):

What about the software setup? Well, that too is now very simple:

download and install a copy of the Arduino IDE 1.5.2
create a folder called “hardware” inside your IDE’s “sketchbook” folder
download or – preferably – clone the new ide-hardware package from GitHub
rename it to “jeelabs” (!) and move it inside the “hardware” folder

The new jcw/ide-hardware project on GitHub was adapted from the arduino-tiny project on Google Code. I didn’t want to wait for that project (it hasn’t been updated for over 6 months), and decided to create a fork on GitHub instead. I did find two other such forks – rambo/arduino-tiny and james147/arduino-tiny, but neither of them appears to offer a major advantage – and since I had to rearrange things to make it work with the IDE 1.5.x structure, there does not seem to be much point in basing things off those forks.

The result of all these steps is that you now have the following new options:

use the Tools -> Programmer menu to select “Arduino as ISP”
select “JeeNode Micro” from the Tools -> Boards menu to build for that setup
use the Tools -> Burn Bootloader menu to set up the fuses
use the standard “Upload” button to upload a sketch using this ISP-based setup:

Those two warnings are harmless, and can be ignored (I don’t know how to avoid them).

That’s it!

Update – Fixed a problem with setting fuses, make sure you use latest code from github.

Programming the JNµ – again

In AVR, Hardware on Mar 20, 2013 at 00:01

Given that the JeeNode Micro is based on an ATtiny84 and not the standard ATmega used in Arduino’s and clones, it has always been quite tricky to make things work on the JNµ.

No more:

The new (and still somewhat experimental) Arduino IDE 1.5.2 adds much better support for other process cores, making it possible to set up things as shown above, and then you can just use the “Upload” button to get things loaded into a JeeNode Micro.

It’s all based on setting up a JeeNode (or other 3.3V-level Arduino clone) to run as ISP programmer, and then a few wires to hook it up to a “target” JeeNode Micro. The IDE now includes an ISP programmer setup, but I tend to use the Flash Board for this – in combination with the isp_flash.ino sketch, which was recently updated to run at 9600 baud i.s.o. 19200, to make it compatible with what the IDE expects by default:

For more information about ISP programming, see this post and tag on this daily weblog.

Tomorrow, I’ll describe the steps needed to set things up. Stay tuned…

Direct relay switching – final

In Hardware on Mar 19, 2013 at 00:01

To conclude this little excursion into relay switching, here is the final circuit:

I’ve re-wired everything to use two DIO pins, and removed the extra 10 Ω resistor:

Bottom side:

The sketch can now switch both I/O pins using a single instruction, and avoid the brief shorting out of the I/O pins on the ATmega:

void setup() {
  digitalWrite(5, 0);
  digitalWrite(6, 0);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
}

static void setLatch (bool on) {
  // change both I/O pins in the same clock cycle
  if (on)
    PORTD |= bit(5) | bit(6);
  else
    PORTD &= ~ (bit(5) | bit(6));
}

void loop() {
  setLatch(true);
  delay(1000);
  setLatch(false);
  delay(1000);
}

This also gets rid of the inductive kickback, or rather, it “diffuses” that effect into the slow capacitor charge and discharge ramps. All in all, I think this setup is a viable circuit for low-power switching of this tiny relay.

I’ve ordered a few more of these units, and intend to try them out with live 230 VAC mains switching. Note that this is pushing it, and that it will most definitely not meet all rules and regulations for mains separation and isolation – but for just controlling small lights, and other small devices such as power adapters and chargers, I think it’s still usable, and am willing to try it – at least for personal use around the house here at JeeLabs.

Onwards!

Direct relay switching with a cap

In Hardware on Mar 18, 2013 at 00:01

Let’s explore this direct relay switching a bit further …

As suggested by @tmk in one of the comments, it is also possible to drive this thing with a single I/O level change by inserting a capacitor in the circuit, i.e. using just 2 I/O pins:

The idea is that the (opposite) charge and discharge currents pulses will be sufficient to make the latching relay switch state. The electrolytic cap takes the place of the pulse software, which can now be simplified to just switch high and low:

static void setLatch (bool on) {
  if (on) {
    bitSet(PORTD, 6); // D.6
    bitSet(PORTC, 2); // A.2
  } else {
    bitClear(PORTD, 6); // D.6
    bitClear(PORTC, 2); // A.2
  }
}

The extra 10 Ω resistor in series with the cap is used to measure the current in the circuit and show it on the scope:

I’ve added the integral of the current in red, which allows calculating the total charge consumed by this circuit when switching the relay. A quick visual estimate tells me that the surface under the current pulse is about 50 ms x 50 mV, and since I’m measuring over 10 Ω, that corresponds to 50 ms x 5 mA = 250 µC. The actual integral is more like 350 µC. This corresponds to drawing 350 µA for one second, every time the relay is switched – which would presumably be done only a few times a day, so this is still within the capabilities of a battery-powered JeeNode.

There’s a strange hump at the start – here it is again, zoomed in:

I suspect that it is caused by relay contact bounce, and the change in inductance as the latching relay core toggles to its alternate state. The relay’s inductance is about 95 mH, according to my low-cost LCR meter – i.e. a 40 Hz resonant frequency combined with that 100 µF cap, so this can’t be a resonance issue (that would have to be in the 25 ms range).

Tomorrow, the last post about this topic, with the final circuit and code…

Direct relay switching – part 2

In Hardware on Mar 17, 2013 at 00:01

Yesterday’s post turns out to uncover a lot of trouble spots and mistakes on my end w.r.t. switching small relays. Get ready for some scope shots ahead, to see what’s going on…

But first, the code I’ve been using:

void setup() {}

static void setLatch (bool on) {
  pinMode(5, OUTPUT);  // DIO2
  pinMode(15, OUTPUT); // AIO2
  pinMode(6, OUTPUT);  // DIO3
  pinMode(16, OUTPUT); // AIO3

  digitalWrite(5, on ? 0 : 1);
  digitalWrite(15, on ? 0 : 1);
  digitalWrite(6, on ? 1 : 0);
  digitalWrite(16, on ? 1 : 0);

  delay(3);
  
  pinMode(5, INPUT);
  pinMode(15, INPUT);
  pinMode(6, INPUT);
  pinMode(16, INPUT);
}

void loop() {
  setLatch(true);
  delay(1000);
  setLatch(false);
  delay(1000);
}

Basic idea: set the pins as outputs, set the levels right, wait 3 ms, then set the pins as input again, i.e. in high-impedance mode, to stop driving the relays.

There are two very serious problems with this code. The first one is that the I/O pins are set to inputs at the end. This means there is no good path for the inductive kick energy to go, leading to this very nasty waveform across the relay – same as shown yesterday:

Note the extreme voltage levels across the coil – way beyond the ± 3.3V you’d want to see in a good 3.3V totem-pole configuration.

It turns out that there is a surprisingly simple solution for this – don’t make the I/O pins inputs, but put them all the same output level, so that no current flows through the relay (as before), but with the I/O pins still being outputs, i.e. able to conduct current.

Here’s is the entire pulse again, at maximum scale this time:

(the lines are so thick because the input is set to peak-detect mode in the scope)

No more funny business! A fairly clean on and off transition, just a bit of “sagging” as the two I/O pins in parallel struggle (successfully) to supply the required current. It looks like the inductive kickback is now absorbed by the output pins which are all set to “0”, i.e. conducting to GND.

I’m surprised by how well this seems to work. I’m guessing that the CMOS switches in the ATmega’s pin driver are able to conduct in both directions when enabled, and that the ESD protection diodes are absorbing any voltage excursions outside the 0 .. 3.3V range.

But a much bigger problem probably, is that the original sketch was shorting out the DIO and AIO pins against each other – producing a very bad intermediate voltage level:

The time scale is completely different now, and as you can see, the voltage level goes through a strange middle state. This is caused by the fact that the digitalWrite() code is very slow, compared to the actual speed of the ATmega. It’s taking 4 µs to process each call, and as the first one is set to one value, the other pin connected to it can still be in the other state. So this is – briefly – shorting out two I/O pins, set to different values!

Very very bad – this may well reduce the lifetime of the ATmega µC. As it turns out, my choice of I/O pins makes it impossible to set both I/O pins simultaneously. But the least I can do without re-soldering, is to use the much faster bitSet() and bitClear() calls – even though this makes the code slightly harder to understand:

static void setLatch (bool on) {
  if (on) {
    bitSet(PORTD, 5); // D.5 = DIO2
    bitSet(PORTC, 1); // A.1 = AIO2
  } else {
    bitSet(PORTD, 6); // D.6 = DIO3
    bitSet(PORTC, 2); // A.2 = AIO3
  }

  delay(3);

  bitClear(PORTD, 5); // D.5 = DIO2
  bitClear(PORTC, 1); // A.1 = AIO2
  bitClear(PORTD, 6); // D.6 = DIO3
  bitClear(PORTC, 2); // A.2 = AIO3
}

The switching times are now dramatically closer together, more like 0.12 µS in fact:

Note that you’re looking at the superposition of both the rising and the falling switching waveforms in this case, as an easy way to see both in one screen shot.

For more information about inductive kickback and protection diodes: there’s an article by Douglas Jones – it’s full of useful information, even though it’s geared towards driving DC motors and stepper motors. The same principles apply when driving the coil in a relay.

So the conclusion seems to be that this specific relay could be driven from 4 I/O pins, without requiring any further circuitry. And since it’s a latching relay, this can easily be done on battery power: it merely takes a 3 ms pulse to make it switch, i.e. about the same amount of energy as sending out one RF12 packet!

Direct relay switching

In Hardware on Mar 16, 2013 at 00:01

There are small relays which are just weak enough to be switched directly by the ATmega’s I/O pins, even at 3.3V. I’ve been chasing and trying out these types of relays for some time, especially the latching types which only require power to switch, not to stay on.

Today, I received a very nice surprise package from @eljonco, who sent me a nice little latching relay (from eBay) which I’ve immediately mounted on a Proto Board:

Bottom side connects DIO2 + AIO2 to one side of the coil, and DIO3 + AIO3 to the other:

Why both? Because one pin drive is not strong enough to make these units switch at 3.3V:

…whereas driving them both in parallel works, resulting in a clear clicking sound and a very nasty “inductive kick-back” switching pulse across the coil on power-off:

There are horrific things going on here, electrically speaking, which I’ll look into later.

For now, let me just explain what’s going on and how this single-coil latching relay is being switched, using four I/O pins (port 2 and 3 on a JeeNode in this case):

The relay core can be switched with a brief pulse, reversing the polarity to reverse the action. So we connect it to two different I/O pins and drive it as an H-bridge. When both pin levels are the same (or when the I/O pins are floating), nothing happens. By putting one pair in “0” state and the other in “1” state, current flows through the coil.

So to turn the relay on, the actions are:

set DIO2 = AIO2 = 0
set DIO3 = AIO3 = 1
wait 3 ms
set DIO3 = AIO3 = 0 (same as DIO2 and AIO3), or make them float, i.e. inputs

To turn it off, we simply exchange the 0’s and 1’s in the above.

More on this tomorrow. Stay tuned…

Unwanted RF

In Hardware on Mar 15, 2013 at 00:01

Houten is not a good place to be if you want to analyse signals in the 100 MHz range …

After looking into some switching regulator artefacts for a while, I’ve concluded that there is nothing wrong with my circuit after all. It’s all due to a nearby FM broadcasting tower!

(367 m high and about 10 km away: the Gerbrandytoren in Lopik – for the Dutch readers)

Getting rid of RF electromagnetic waves is hard. You need a Faraday cage, but you also have to prevent all unwanted RF from entering via measurement and power cables – and it has to work at all the frequencies you’re examining!

I doubt I’ll find a way to get rid of this, but the least I can do is to measure it:

Whoa – nice FM antenna!

Now let’s do the right thing and use a coax cable with internal 50 Ω termination in the scope turned on, and the input sensitivity increased to 1 mV per division:

Again, nice antenna. The “noise floor” is now 20 dB (100x) lower – a much cleaner signal:

And finally, just to make sure it’s really the loop that is picking up the signal, let’s replace that loop by a 50 Ω terminator on the input side as well:

Ah, now we’re getting to the bottom of this – a 30 .. 35 dB reduction:

Note that we’re still picking up very weak FM signals (no cable shielding is perfect). But it’s clear that the incoming signals are coming from antenna-type pick-up of electric fields, not some fault in the measuring setup, or that switcher I was investigating.

Let’s just hope I never have to really chase and analyse signals in this frequency range!

Hot spots on a JeeNode USB

In Hardware on Mar 13, 2013 at 00:01

Recently, a blower door test was done here at JeeLabs, as a way to measure – not guess – how air currents are affecting the house, and what sort of insulation measures would be most effective. This was a fascinating and very extensive test, combined with a thorough scan of the entire house – inside and outside – using a high-end thermal imaging camera.

While the guys from Bergenbos were doing their tests, I asked them to take some close-ups of a JeeNode which had been running RF12demo for a while (i.e. not in sleep mode):

Fantastic resolution, as you can see. No big surprises, but nice pictures nevertheless…

What’s a measly 2 cm?

In Hardware on Mar 12, 2013 at 00:01

As promised, one last post about decoupling capacitors. Unlike yesterday, this one is about that 0.1 µF ceramic capacitor again – the kind which gets used all over the place in through-hole designs such as the JeeNode:

Let’s compare the 200 kHz .. 20 MHz sweep signal absorption when connected far away from the cap (white), i.e. with long leads, vs. connected right next to the cap (yellow):

Whoa! – a substantial effect at higher frequencies if we include the long leads!

If you try to think about this in a simple “DC electricity” way, then 2 cm of extra wire is nothing: let’s for the argument’s sake assume that electricity travels at the speed of light. Then 30 cm = 1 ns, i.e. 2 cm is less than 70 picoseconds. A 16 MHz frequency has a 62.5 ns period, i.e. 19 meter wavelength, which completely dwarfs those measly 2 cm wires.

But propagation is not what’s messing things up here, not with those “low-end” 16 MHz ATmega’s I’m experimenting with anyway. The effect shown above comes from any wire adding some parasitic impedance (and capacitance) to the circuit. Plus some transmission line effects, probably. As you can see, those little extra 2 cm cause a noticeable degradation of the 0.1 µF cap’s decoupling capability.

This also applies to traces on a PCB, by the way. The guideline to add de-coupling caps as close as possible to the source of the switching disturbances is a serious matter!

With thanks to Martyn, for helping me understand the issues presented in these posts.

PS. Part of the impedance increase in all the screen shots made in the last few posts has been identified as a bad cable from my signal generator to the test setup. Doh! – with a much better cable (90% coax with clips at the end), the extra rise towards 20 MHz is gone. Still, this does not significantly affect the general shape or outcome of these experiments.

Resonator and crystal

In Hardware on Mar 11, 2013 at 00:01

Today, some more experiments with a sweep frequency to see how different components respond to it, beyond the cap-which-is-also-an-inductor of yesterday.

The first one I’d like to show is the 16 MHz resonator used in JeeNodes:

As you can expect it has a very sharp impedance change at its 16 MHz frequency:

(The bottom half is a greatly zoomed-in section from the far right of the entire sweep)

The blue area sticking out the back is the current through the resonator. As you can see, there is a very noticeable yet narrow range of frequencies at which things change. Plus a little parasitic inductance, indicated by a modest rise in signal amplitude near the 20 MHz end of the range.

An even more pronounced frequency-dependent component is the crystal, as used in just about every digital device around us these days. Crystals can have several different “modes” of oscillation, and can in fact resonate on different frequencies if the oscillator circuit around it is not designed properly.

Here, you can in fact see two modes of oscillation: a series-resonant “dip”, followed by a parallel-resonant “peak”. Note that this is a 10 MHz crystal, taken from an RFM12B module, with the total sweep scale from left to right being only 9.99 .. 10.01 MHz:

The resonant frequency seems to be about 150 ppm low, which is not surprising, since the crystal is not being driven by a real oscillator at all, nor with the proper capacitive loading – it’s simply “resonating along” with the frequencies applied to it.

These pictures as not just gimmicks. If you think about it, the behaviours shown above in a way almost define what these resonators and crystals do. It is precisely this “little” effect on impedance which allows us to create oscillators that resonate at very specific frequencies. Without them, we’d still be living in Tesla’s and Marconi’s age of sparks: maybe enough to get some morse code across, but a far cry from fitting dozens of HD television channels into separate adjacent frequency bands – or a fiberoptic cable, for that matter.

Tomorrow, I’ll have one final surprising result to show you w.r.t. “parasitics” …

It’s no longer a capacitor!

In Hardware on Mar 10, 2013 at 00:01

Yesterday’s post was about plotting the response of a decoupling capacitor versus frequency. It might not seem like much, but this is in effect exactly what a Spectrum Analyser with “Tracking Generator” does! You put a signal with a known frequency and amplitude into a circuit, and you look at the amplitude of the signal that comes out. As you saw, these plots give instant insight in what an analog circuit is doing to signals. And if we were to somehow also measure the phase shift of the signal, we’d in fact have a Vector Network Analyser – an instrument which usually costs more than an average car!

But let’s go back to decoupling…

First, let me show you the exact circuit setup I’ve been using:

The green dotted line is the AWG signal generator, and it has an internal resistance of 50Ω. You can ignore the 1Ω resistor, it was intended to measure current through the cap, but it turns out that the 50Ω helps us get the same sort of information.

Imagine this circuit hooked up next to a digital chip, with high-frequency “noise” reaching the top of the cap. As you can see in yesterday’s plot, the 0.1 µF cap becomes more and more a conductor as the frequency increases – which is exactly what we want, because that means the remaining voltage will consist of just the remaining low frequency changes, which are more easily dealt with by the power supply source.

Another way to look at this circuit is as a low-pass RC filter. It lets the lower frequencies through, and shorts the higher frequencies to ground.

The plots so far have all been from 1 kHz to 1 MHz. Let’s now raise the frequency sweep range a bit – from 200 kHz to 20 MHz (just ignore the blue trace):

Now that is odd – the amplitude starts to rise again with frequencies nearing 20 MHz! In fact, there seems to be a “saddle point” roughly in the middle. This is about 2 Mhz (the scale is still logarithmic, so every 5 divisions is now a factor 10 with these sweeps).

What’s going on here?

The answer is that all electrical circuits and components have parasitic effects. In this case, the capacitor also has some inductance. An inductance (i.e. a coil which generates a magnetic field) is just the opposite of a capacitor: it’s impedance rises with frequency.

So this 0.1 µF cap is in fact not able to short out high frequencies at all – it leaves them unaffected. Note that with an ATmega running at 16 MHz, we’re very solidly in that range of frequencies where the decoupling cap is becoming less effective!

To give you an idea how odd these caps behave: let’s add a 0.01 µF capacitor in parallel. You’d expect the result to be equivalent to a 0.11 µF cap – with the saddle point simply moving to a different place on the plot, right? Not quite:

They each do their thing and have their effects super-imposed, generating a double saddle. That, by the way, is why the more demanding circuits use exactly this very same approach to decouple various frequencies at the same time – just put some different caps in parallel.

Tomorrow, I’ll take a few other familiar components through this sweep setup…

Electronics, JeeDay

Frequency sweep

In Hardware on Mar 9, 2013 at 00:01

This is the continuation of yesterday’s post about decoupling capacitors. As promised, some more information now about a test setup which can visualise some interesting – and quite surprising – effects.

The first part of the idea is to generate a “sweep” across a frequency range, i.e. a signal which increases in frequency from 1 kHz to 1 MHz within 10 seconds, and then repeats:

Such a signal can be generated with a “frequency generator”, in my case this AWG.

The second part is to inject this signal into the “Device Under Test” – i.e. a 0.1 µF ceramic capacitor in our case – and let an oscilloscope “sweep” across in lock-step with that signal:

Since the frequency increases with time, we end up with a display of the frequency on the X axis versus the signal amplitude on the Y axis:

The scope was set to display in peak-detection mode, to make the display “fill” with a band of the oscillating signal. The second signal is used to trigger each scan, which takes 10 seconds to complete (plus one second on each side for the previous and next sweeps).

As you can see, the amplitude of what gets through the cap decreases. Decreases? – yes, well, I simplified things a bit. There’s a resistor in series and the setup is actually measuring the voltage over the cap. As its impedance decreases, it shorts out the signal more and more. I’m deliberately skimming over some details to keep things short for this weblog post.

Looks like all is peachy, right? Not so fast…

First, let’s change the way things get measured a bit. Instead of linearly increasing the frequency from 1 kHz to 1 MHz, I’m going to switch to a logarithmic scale. This means that every 3.33 seconds, the frequency gets increased by a factor of ten by the AWG. So while the previous image had the frequency increase by some 100 kHz per division, now we have 33.3 KHz in the middle of the screen instead of 500 KHz:

It’s exactly the same result, but it doesn’t emphasise the higher frequencies as much. Note that we’re not really interested in the exact values, more in the shape of these curves – so I’ll omit the on-screen info from now on.

So why is that frequency response flattening out in such a clear way? Stay tuned…

Update – All arrangements have been made: JeeDay will be held in Houten, with excellent train access, on Friday evening April 19th and Saturday all-day April 20th.

Decoupling caps

In Hardware on Mar 8, 2013 at 00:01

As I wait for some fresh inspiration (oh, and some more JeeNode Micro v3’s) to arrive, let’s go into something that has intrigued me for a long time:

> What’s that “decoupling” stuff all about when designing electronic circuits?

The following information comes from a fantastic discussion with martynj, exploring ways to make this visible on the scope. I really learned a great deal – thank you, sir!

As you probably know, all chip datasheets have these little capacitors connected near the main chips, “for decoupling”. You’ll often see schematics with several of them:

What is decoupling? And decoupling what exactly?

Well, the problem is that power supply lines can get very noisy – lots of fluctuations you don’t really want, and if they get really bad, the chips will start to malfuction, mistaking a “0” for a “1” level or vice-versa. Not to mention the fact that high frequency signals will radiate into free air, turning a circuit on a PCB into an illegal transmitter – whoops!

Let’s not go into the “deeper” stuff: parasitic capacitance & inductance, dielectrics, etc. Instead, let’s just run some experiments with these humble little 0.1 µF “caps”:

As you’ll soon see, they are not capacitors at all – obnoxious little buggers, they are!

But first, the basic idea: due to digital switching, chips tend to generate a lot of very sharp current transitions. On an ATmega running at 16 MHz, these pulses are likely to be most pronounced at around 16 or 32 MHz, i.e. both the up and the down flanks of the main clock causing all semiconductors inside to switch.

Drawing a lot of current very abruptly is like suddenly pulling on a pendulum: it doesn’t immediately follow your request, but lags and has some trouble meeting the requested change. And when released, it tends to overswing, making the problem even worse.

Same with current changes – the power supply can’t quite match it, and so the voltage near the chip drops (and later overshoots) while trying to keep up. It’s the same effect as the lights dimming briefly when turning on a very power-hungry appliance in the house. It’s all about inductance if you really want to know, but let’s just ignore that for now.

Capacitors near the chip are like tiny (but very responsive!) reservoirs of energy, and they can be very effective in compensating for this dip.

So the general advice is: put decoupling caps between VCC and GND, as near the chip as possible, and the cap will “dampen” the demand to give the much longer connections to the power supply time to replenish the energy. Capacitors are great for this – and the closer they are to the consumer, the better they can handle even extremely brisk “spikes”.

Another way of saying this is: capacitors have an infinite resistance at 0 Hz (DC), i.e. they do not leak DC power, but as the frequency increases, they pass more and more current. This “frequency-dependent resistance” is actually called impedance – so as frequency increases, the cap’s impedance decreases. Spikes are – by definition – high-frequency. And the lower the impedance, the more these spikes get… s(h)orted out!

Tomorrow I’ll describe a little test setup to clearly demonstrate the effect of higher and higher frequencies being more and more absorbed by that 0.1 µF capacitor shown above.

Programming the JNµ v3 – part 1.5

In AVR, Hardware on Mar 5, 2013 at 00:01

After having created the cable, I was going to set up the AVRISP MkII programmer…

Things didn’t work out as planned, alas. When having some problems (unrelated, and due to a wrong part choice, as it turned out), I wanted to make sure that the AVRISP was really set up properly, and decided to install AVR Studio 6.0 …

Hm. Since I don’t have any computers running Windows, this had to be done in a virtual machine (running under Parallels in my case). Easy, right? Yeah, well, I do keep an image around for cases like these, so I downloaded the installer from Atmel, and a little later it was indeed running. Lost some 4 GB of disk space (nuts), and it installed all sorts of stuff as part of the deal (nuts), but hey, that’s how software should be… apparently (nuts!).

Plugging in the AVRISP, I got a message from AVR Studio that I had to upgrade its firmware (it worked fine with avrdude, but hey, who am I to argue). This was not an option, but a requirement (nuts).

So I proceded with the upgrade… piece of cake, right?

Whoops! As part of the upgrade, the device drops off the USB bus, at which point Parallels ceased to recognise it. Unrecognised devices can’t be attached to a Windows VM.

So the end result is: a “bricked” AVRISP programmer, which can probably only be restored on a non-VM install of Windows. Nuts!

I’m going to switch to the Flash Board, which works and has a normal upgrade process:

Note that I’m not using the on-board EPROM or button. A few wires could also be used.

It’s easy to use as a programmer, when you’re used to the Arduino IDE and avr-gcc way of doing things: install the flash.ino sketch on a JeeNode, insert this thing on top, and you end up with an ISP programmer which is recognised by avrdude by using the parameters “-p stk500v1” and “-B 19200”, and the serial port as “-P …”.

So much for closed source & lock-in – stuff I can’t control. ISP mode resumes tomorrow!

JNµ battery tests

In AVR, Hardware on Mar 4, 2013 at 00:01

With the LiPo battery “blipping” along happily for years now, I’ve started two new tests, based on the JeeNode Micro v3. Here’s the boost unit, running an updated radioBlip2.ino:

This one converts the incoming 1.2 .. 1.4 V from a single-cell Eneloop AA battery to roughly 3.0 V, as you can see in this overview in HouseMon (using an updated “radioBlip” driver):

The other new node runs off a CR2032 coin cell, which is struggling a bit to maintain a stable voltage each time a packet gets sent out, as indicated by the 3.20 -> 3.08 V drop. In case you’re wondering how a node can report its battery voltage after already having sent the data, simple: measure the voltage and send it out in the next packet.

The technique used to measure one’s own battery voltage was described in a post last year. Measuring the battery voltage in this way does not consume very much power in itself, since the ATtiny is placed in a special low-power “ADC-only” sleep mode while doing so:

The energy used for the measurement is the area under those last four little “blips” after the main packet transmission: there’s almost no penalty in performing this measurement before and after each packet transmission. Over time, hopefully the trend of the before + after voltages can be used as predictor for the amount of life left in them little coin cells…

PS – The main change in the radioBlip2 sketch, apart from adapting it to work on the ATtiny, is that the packet now includes a “sender ID” byte. This way all the battery test nodes can re-use the same node ID here at JeeLabs – since the number of ID’s used is starting to become a concern (there are 30 unique ID’s in each net group). For nodes like these, which only send, it’s no problem at all to “re-use” node ID’s this way.

Update – I’ve added a “BOOST” option to report the battery input voltage, which is much more useful. It’s measured with a jumper from PWR to the AIO pin (PA0, analog 0).

Programming the JNµ v3 – part 1

In AVR, Hardware on Mar 3, 2013 at 00:01

The new JeeNode Micro v3 announced yesterday does some very subtle things w.r.t. how it deals with the SPI bus during ISP programming (don’t you love those silly acronyms?). I’ll have a lot more to tell about this in a future weblog post, but for now let’s just focus on getting a new sketch into the ATtiny84 chip!

As mentioned yesterday, there is no longer a standard 2×3 ISP header on this board. It’s just a 4-pin header, with GND and VCC obtained from the 8-pin header on the side of the board. For reference, here is the ISP header pinout as most ISP programmers expect it:

In my case, I wanted to use the modified AVRISP mkII programmer, so I’ve set up a little cable + breadboard hack, as follows:

The 2×3 to 6-pin (actually 5-pin) header was constructed from an Extension Cable. Here is the hookup, using 2×3 long header pins to connect the 2 female ends together:

And here’s the breadboard side of things, in close-up:

Note the sixth wire (providing or sensing VCC power), which goes to either +3V or PWR on the main header. This flexibility will in fact turn out to be quite convenient when dealing with direct-power vs boost-power versions of the JeeNode Micro.

So much for the hardware side of things. The software side turned out to be a lot trickier, and I’d like to take a little more time to work out the best way to do things. After a short intermezzo tomorrow, will come part 2 – stay tuned!

Meet the JeeNode Micro v3

In AVR, Hardware on Mar 2, 2013 at 00:01

There’s a new kid in town, the JeeNode Micro v3 with ATtiny84 + optional boost converter:

(Can you spot the differences? That’s without and with buck/boost converter…)

It’s even shorter than the v2, and has all the components on one side again:

The main reason for the reduced size is the reduced number of header pins. One of the biggest changes in that regard, is that v3 no longer has a full 2×3 ISP header – just the 4 data pins. The idea is that GND and +3V can be connected to the 8-pin “port+” header.

As it so happens, there’s a fifth pad on the bottom side of the PCB which connects to GND. This can be put to good use for experimentation, by connecting some headers as follows:

Note that the 6th pin was removed from the female header – this is very easy to do: just pull on the pin from the bottom with some pliers and it’ll slide out.

That leaves just power to be connected up for SPI programming. More details tomorrow…

Taking the JNµ to 3.0 V

In AVR, Hardware on Mar 1, 2013 at 00:01

As mentioned in yesterday’s post, lower supply voltages lead to lower power consumption.

There’s a new JeeNode Micro v3 revision coming which applies this logic to try and get the power consumption as low as possible. It also has changed slightly in its pinout:

The main physical changes are: it’s now 16 x 43 mm, and the ISP pins are no longer 2×3.

Let’s just focus on the power side of things for now, though. The JNµ v3 can be operated from several power sources:

Direct power: this runs without regulation, and requires a 2.2V .. 3.8V power source
Boost power: using the same circuit as the AA Power Board, runs from 0.9V .. 5.0V

The boost power circuit is very flexible as you can see, but it adds a certain amount of quiescent power consumption of its own, making the whole setup draw more idle current than when it is directly powered. What you do get with the boost power hookup, is that it’ll try to stay running as long as possible, down to a 0.5 V input under ideal conditions, so this thing will squeeze the last drop of energy out of its power source. Great for “empty” AA’s!

Boost power supplies are very clever and useful circuits, but they can’t break the laws of physics: a 100% efficient boost supply will draw 15 mA when asked to generate a 3.3 V @ 5 mA output from a 1.1 V input source. The current it draws will be triple that which it produces (more like four times, in fact, since the real circuit is far from 100% efficient).

Note that – in the light of yesterday’s story – it would really make no sense to pump up the voltage to say 5V, only to end up with a more wasteful circuit. That’s not just a quadratic increase, those losses would in fact be proportional to the third power of the voltage!

With a boost circuit, it really pays to work with as low an output voltage as possible. Which is why the JeeNode Micro v3 now comes with a 3.0V version of the boost chip, not 3.3V.

Let’s do the math, assuming a 100% efficient boost supply:

a 3.0 V booster draws 3.0 / 3.3 ≈ 91% of the current in comparison to a 3.3 V one
running at 3.0 V instead of 3.3 V consumes ≈ 83% of the power (with a resistive load)
combined, that means we’ll be using 3.0 ^ 3 / 3.3 ^ 3 ≈ 75% of the power at 3.0 V
so the total power consumed is 25% less at 3.0 V compared to what it’d take at 3.3V

That translates to 3 more months on a battery lifetime of 1 year – quite a bit!

This doesn’t just apply to the boost regulator: coin cells often have a 3.0V rating, and so do 2 alkaline AA batteries in series. Note also that 2 rechargable AA batteries will still work fine, as these will supply 2.4..2.6 V, well within the direct power range of the JNµ v3.

Note that for all the standard JeeNodes, nothing changes: these will continue to be populated with 3.3V regulators. One key reason for this is that they are already operating slightly beyond their specs (“overclocked”) with the clock running at 16 MHz. We shouldn’t push our luck with these settings, which are standard in the Arduino world. So the JN, JN SMD, and JN USB will all continue to be operated at 3.3V – no changes!

As for the many different JeePlugs: these all run at 3.3V, and the chips used on these plugs are normally qualified to run at either 3.0 .. 3.6V or 2.7 .. 3.3V, so we’re still fully in range.

Is it all win, then? Well, yes, but note that the noise margins are slightly reduced at 3.0V, which can slightly affect the accuracy of analog pin measurements and the cable lengths at which I2C chips still operate reliably. These effects are going to be minimal, I expect, but it’s something to watch out for.

Update – As pointed out in the comments, the above calculations are not correct. There is a small effect on booster circuit efficiency in all this, but the power savings are closer to 20% than 25% – not quite 3 months per year, as I claimed.

Dropping below 3.3 V

In AVR, Hardware on Feb 28, 2013 at 00:01

One of the departures from the Arduino world has always been that JeeNodes operate at 3.3 V, whereas the standard Arduino’s all ran at 5 V. Things are changing, with the ARM-based “Arduino Due”, for example, which also runs at 3.3 V. There’s not really a choice: ARM chips all run at 3.3V or less (3.6V max actually, which leaves a nice safety margin).

So what’s this trend towards lower voltages all about, eh?

Well… you may have seen an older post in the Easy Electrons series (whoa, over two years ago.. time flies!). If you think about it for a moment, all the electric energy pumped into a circuits will end up being converted into some other form of energy: a teeny tiny bit of radiated RF energy in the case of a JeeNode, but mostly heat, really.

Odd as it may seem, all that electronic stuff is just a way to turn current into heat. There is a purpose for this, since we’re usually interested in the side effects: some physical sensing and some computation, leading to the information we’re interested in. But the electricity consumption is just an (unavoidable) side-effect.

Whenever we can lower the voltage and/or current consumption, we’ll end up consuming less power as a result (W = I x V). Lowering the voltage on a circuit often leads to a dramatic reduction in power, since part of a circuit is always resistive. Ohm’s law says that voltage = resistance x current, or to put it differently: current = voltage / resistance. So halving the voltage (V) over a resistor also halves the current (I) it draws. The effect: half the voltage leads to a quarter of the power consumption, in purely resistive circuits:

Unfortunately, you can’t just use 0.1 V to power a circuit: bipolar semiconductors such as diodes and transistors have a 0.6V threshold voltage, anything below that renders them useless. In the real world, running digital circuits at under 1.0 V is rarely done. Even that 1.8 V level down to which an ATmega and ATtiny can be operated is pushing some limits.

Another reason is that lower voltages make capacitive effects more dominant. The lower you go, the longer it takes to charge or discharge a capacitor. Which explains why the ATmega’s maximum clock speed must drop to 4 MHz with a supply voltage of 1.8 V.

But lowering the clock speed is somewhat self-defeating, as this means that the ATmega and ATtiny have to remain powered-up longer before going back into deep-sleep mode! Lots of trade-offs. Still: a low supply voltage is often a good idea – generally speaking.

Tomorrow, I’ll describe the choices made for the next revision of the JeeNode Micro…

Small oops on the LED Node v2

In Hardware on Feb 23, 2013 at 00:01

The new LED Node v2 has been re-done slightly, by fixing the labels of the FTDI connector on the back side, but unfortunately Mr. Murphy pulled another one on me by making me ignore another issue at the time these new boards were ordered.

The current release of the LED Node v2 has a “disconnected ground plane”, meaning that some large copper areas on the back are not attached to ground!

The circuit is correct, in the sense that the board will function as is, but for better noise suppression and higher range of the on-board RFM12B radio, it’s best to make a small modification. Sooo… time to get out the hobby knife and start scratching!

Here is the back of the LED Node v2, unmodified (the silk screen may differ slightly):

What you have to do is scratch off the solder mask, without cutting the trace:

The result will be a bit of bare copper on both the trace and the ground plane next to it. Then, apply a bit of solder to connect everything together. Note that doing so may require quite a bit of heat, as the ground plane is hard to heat up – just keep your soldering iron on the spot until the solder flows freely:

That’s it. The ground of the circuit and the ground plane are now electrically connected, at least under the RFM12B module.

While I’m at it, here’s another modification – unlike the previous “mod”, this one should not be done in a standard setup, with 12V feeding the LED strips as well as the LED Node itself. This is a change you need only consider if you are using voltages higher than 12V, i.e. for 24V LED strips, or when running off batteries which go up to 14V or more.

The reason for this change, is that the MCP1702 regulator of the LED Node is rated only up to about 13V. Anything higher will damage it, even if applied briefly – I’ve seen several cases of this in the past.

The solution is to cut the trace between the power connector and the LED Node, but keep in mind that you then have to power the LED Node logic from the FTDI connector or one of the PWR pins on the headers at all times:

Just use a sharp hobby knife to cut through the trace this time:

So much for hacking the LED Node!

Solar fingernails

In Hardware on Feb 11, 2013 at 00:01

A couple of weeks ago, I described a little indoor solar energy test setup, based on a couple of fingernail-sized CPC1824 solar cell chips, with 0.47 Farad supercaps for storage:

It has been an interesting setup to keep running for a while, and now that 20 days have passed, it’s sort of intriguing to see how well, or badly, these solar energy cells performed. To summarise, here is what the four different test were about:

One CPC1824, very lightly loaded with 20 MΩ, i.e. a 0.15..0.20 µA current draw
One CPC1824, lightly loaded with 2 MΩ, i.e. a 1.5..2.0 µA current draw
One CPC1824, moderately loaded with 0.2 MΩ, i.e. a 15..20 µA current draw
Two CPC1824’s in parallel, moderate load with 0.2 MΩ, again 15..20 µA current draw

In addition, there is a top-up voltage cycling once per ≈ 2 hours, to prevent any the supercaps from discharging much further than about 2.7V. This is not a realistic situation if this setup were to be used for real, but I wanted to prevent a total discharge of the supercaps, to try and find out whether the supercaps would get better (i.e. less leaky) over time, as the constant charge conditions those membranes full of useable electrons.

Here are the results of 20 days, superimposed one upon the other:

(click two times to see it in full scale – X axis is in minutes since midnight UTC)

#1 = blue, #2 = bright green, #3 = orange (dotted), #4 = red (longer dots)
the last day is marked in black for all four cases
around noon, all cells fall into the shadow, so energy generation almost stops
note how only the blue lines stay above 3.0V (except in the first 2..3 days)

This was a wintery mix of sunny and cloudy days, which has a huge effect on the charge / discharge curves. Looks like indoor solar with these tiny cells is not going to work…

One conclusion is that only the lightest load of 0.15..0.20 µA allows the supercap to retain a decent amount of charge through each night. On the other end of the range: with two solar cells in parallel, a 15..20 µA load might be able to stay alive for a few hours each day.

Ehm, well, just maybe – this will really depend on the startup power consumption curves!

HouseMon

HouseMon resources

In AVR, Hardware, Software, Musings, Linux on Feb 6, 2013 at 00:01

As promised, a long list of resources I’ve found useful while starting off with HouseMon:

JavaScript – The core of what I’m building now is centered entirely around “JS”, the language behind many sites on the web nowadays. There’s no way around it: you have to get to grips with JS first. I spent several hours watching most of the videos on Douglas Crockford’s site. The big drawback is the time it takes…

Best book on the subject, IMO, if you know the basics of JavaScript, is “JavaScript: The Good Parts” by the same author, ISBN 0596517742. Understanding what the essence of a language is, is the fastest way to mastery, and his book does exactly that.

CoffeeScript – It’s just a dialect of JS, really – and the way HouseMon uses it, “CS” automatically gets compiled (more like “expanded”, if you ask me) to JS on the server, by SocketStream.

The most obvious resource, http://coffeescript.org/, is also one of the best ways to understand it. Make sure you are comfortable with JS, even if not in practice, before reading that home page top to bottom. For an intruiging glimpse of how CS code can be documented, see this example from the CS compiler itself (pretty advanced stuff!).

But the impact of CS goes considerably deeper. To understand how Scheme-like functional programming plays a role in CS, there is an entertaining (but fairly advanced) book called CoffeeScript Ristretto by Reginald Braithwaite. I’ve read it front-to-back, and intend to re-read it in its entirety in the coming days. IMO, this is the book that cuts to the core of how functions and objects work together, and how CS lets you write on a high conceptual level. It’s a delightful read, but be prepared to scratch your head at times…

For a much simpler introduction, see The Little Book on CoffeeScript by Alex MacCaw, ISBN 1449321046. Also available on GitHub.

Node.js – I found the Node.js in Action book by Mike Cantelon, TJ Holowaychuk and Nathan Rajlich to be immensely useful, because of how it puts everything in context and introduces all the main concepts and libraries one tends to use in combination with “Node”. It doesn’t hurt that one of the most prolific Node programmers also happens to be one of the authors…

Another useful resource is the API documentation of Node itself.

SocketStream – This is what takes care of client-server communication, deployment, and it comes with many development conveniences and conventions. It’s also the least mature of the bunch, although I’ve not really encountered any problems with it. I expect “SS” to evolve a bit more than the rest, over time.

There’s a “what it is and what it does” type of demo tour, and there is a collection on what I’d call tech notes, describing a wide range of design docs. As with the code, these pages are bound to change and get extended further over time.

Redis – This a little database package which handles a few tasks for HouseMon. I haven’t had to do much to get it going, so the README plus Command Summary were all I’ve needed, for now.

AngularJS – This is the most framework-like component used in HouseMon, by far. It does a lot, but the challenge is to understand how it wants you to do things, and altough “NG” is not really an opinionated piece of software, there is simply no other way to get to grips with it, than to take the dive and learn, learn, learn… Let me just add that I really think it’s worth it – NG can be magic on the client side, and once you get the hang of it, it’s in fact an extremely expressive way to create a responsive app in the browser, IMO.

There’s an elaborate tutorial on the NG site. It covers a lot of ground, and left me a bit overwhelmed – probably because I was trying to learn too much as quickly as possible…

There’s also a video, which gives a very clear idea of NG, what it is, how it is used, etc. Only downside is that it’s over an hour long. Oh, and BTW, the NG FAQ is excellent.

For a broader background on this sort of JS frameworks, see Rich JavaScript Applications by Steven Sanderson. An eye opener, if you’ve not looked into RIA’s before.

Arduino – Does this need any introduction on this weblog? Let me just link to the Reference and the Tutorial here.

JeeNode – Again, not really much point in listing much here, given that this entire weblog is more or less dedicated to that topic. Here’s a big picture and the link to the hardware page, just for completeness.

RF12 – This is the driver used for HopeRF’s wireless radio modules, I’ll just mention the internals weblog posts, and the reference documentation page.

Vim – My editor of choice, lately. After many years of using TextMate (which I still use as code browser), I’ve decided to go back to MacVim, because of the way it can be off-loaded to your spine, so to speak.

There’s a lot of personal preference involved in this type of choice, and there are dozens of blog posts and debates on the web about the pro’s and con’s. This one by Steve Losh sort of matches the process I am going through, in case you’re interested.

Best way to get into vim? Install it, and type “vimtutor“. Best way to learn more? Type “:h<CR>” in vim. Seriously. And don’t try to learn it all at once – the goal is to gradually migrate vim knowledge into your muscle memory. Just learn the base concepts, and if you’re serious about it: learn a few new commands each week. See what sticks.

To get an idea of what’s possible, watch some videos – such as the vim entries on the DAS site by Gary Bernhardt (paid subscription). And while you’re at it: take the opportunity to see what Behaviour Driven Design is like, he has many fascinating videos on the subject.

For a book, I very much recommend Practical Vim by Drew Neil. He covers a wide range of topics, and suggests reading up on them in whatever order is most useful to you.

While learning, this cheatsheet and wallpaper may come in handy.

Raspberry Pi – The little “RPi” Linux board is getting a lot of attention lately. It makes a nice setup for HouseMon. Here are some links for the hardware and the software.

Linux – Getting around on the command line in Linux is also something I get asked about from time to time. This is important when running Linux as a server – the RPi, for example.

I found the linuxcommand.org resource which appears to do a good job of explaining all the basic and intermediate concepts. It’s also available as a book, called “The Linux Command Line” by William E. Shotts, Jr. (PDF).

There… the above list ought to get you a long way with all the technologies I’m currently messing around with. Please feel free to add pointers and tips in the comments, if you think of other resource which can be of use to fellow readers in this context.

JeeNode, Home automation, HouseMon, DIJN

Dive Into JeeNodes

In AVR, Hardware, Software, Linux on Feb 1, 2013 at 00:01

Welcome to a new series of limited-edition posts from JeeLabs! Read ’em while they last!

Heh… just kidding. They’ll last forever of course, as does everything on this thing called internet. But what I’m going to describe in probably a dozen posts or so is the following:

Hm, that doesn’t quite explain it, I guess. Let me try again:

So this is to announce a new “DIJN” series of weblog posts, describing how to set up your own Wireless Sensor Network with JeeNodes, as well as the infrastructure to report a measured light-level somewhere in your house, in real time. The end result will be fully automated and autonomous – you could take your mobile phone, point it to your web server via WiFi, and see the light level as it is that very moment, adjusting as it changes.

This is a far cry from a full-fledged home monitoring or home automation system, clearly – but on the other hand, it’ll have all the key pieces in place to explore whatever direction interests you: ready-made sensors, DIY sensors, your own firmware on the remote nodes, your own web pages and automation logic on the central server… it’s up to you!

Everything is open source, which in this context matters a lot, because that also means that you can really dive into any aspect of this to learn and explore the truly magical world of Physical Computing, Wireless Sensor Networks, environmental sensing and control, as well as state-of-the art web technologies.

The focus will be on describing every step needed to implement this from scratch. I’ll cover setting up all the necessary software and hardware, in such a way that if you know next to nothing about any of the domains involved, you can still follow along and try it out – whether your background is in software, electronics, wireless, or none of these.

If technology interests you, and if I can bring across even a small fraction of the fun there is in tinkering with this stuff and making new things up as you g(r)o(w) along, then that would be a very nice reward for everyone involved, as far as I’m concerned.

PS. “Dijn” is also old-Dutch for “your” (thy, to be precise). Quite a fitting name in my opinion, as this sort of knowledge is really yours for the taking – if you want it…

PPS. For reference: here is the first post in the series, and here is the overview.

HouseMon

Blink Plug meets NG

In Hardware, Software on Jan 29, 2013 at 00:01

Last month, I described how to hook up a JeeNode with a Blink Plug to Node.js via SocketStream (“SS”) and a USB connection. Physical Computing with a web interface!

That was before AngularJS (“NG”), using traditional HTML and ~~Java~~CoffeeScript code.

With NG and SS, there’s a lot of machinery in place to interface a web browser with a central Node process. I’ve added a “blink-serial” module to HouseMon to explore this approach. Here’s the resulting web page (very basic, but fully dynamic in both directions):

The above web page is generated from this client/templates/blink.jade definition:

There are two more files involved – client/code/modules/blink.coffee on the client:

… and briqs/blink-serial.coffee, which drives the whole shebang on the server:

I’m not quite happy yet with the exact details of all this, but these 3 files are all there is to it, and frankly I can’t quite imagine how a bidirectional real-time interface could be made any simpler – given all the pieces involved: serial interface, server, and web browser.

The one thing that can hopefully be improved upon, is the terminology of it all and the actual API conventions. But that really is a matter of throwing lots of different stuff into HouseMon, to see what sticks and what gets messy.

Onwards!

PS – What’s your take on these screenshots? Ok? Or was the white background preferable?

PPS – Here’s another test, code inserted as HTML – suitable for copying and pasting:

# Define a single-page client called 'main'
ss.client.define 'main',
  view: 'index.jade'
  css: ['libs', 'app.styl']
  code: ['libs', 'app', 'modules']

Update – Yet another approach, using a a WordPress plugin (no Jade / Stylus support?):

# Define a single-page client called 'main'
ss.client.define 'main',
  view: 'index.jade'
  css: ['libs', 'app.styl']
  code: ['libs', 'app', 'modules']

Bad LiPo charge chip

In Hardware on Jan 26, 2013 at 00:01

(Not planned this way, but still a nice follow-up on yesterday’s Junk USB post…)

While thinking about some minor tweaks for the JeeNode USB board, I wanted to try out a different LiPo charger chip – mostly to reduce costs, given than not everyone using the JN USB would be interested in the LiPo charge capability (it’s also fine as a JeeNode-with-built-in-USB-BUB after all).

So I had a look at the MCP73832T – in fact, Paul Badger and I went ahead and had a new board made with it:

DSC 3220

The good news: as a LiPo charger, it works absolutely fine.

The bad news: without an attached LiPo battery, it’s not usable.

It turns out that this chip uses some sort of charge/discharge cycle. This is what happens without LiPo attached:

SCR34

IOW, it’s delivering 4.2V for a while, and then dropping the voltage to see whether the LiPo itself will fill in the gaps. A pretty clever way to figure out the state of the attached battery, if you ask me.

One way to use the chip without attached LiPo would be to bypass the Vin and Vout pins of the chip, i.e. just disable it altogether via a (solder-) jumper. Drawbacks: 1) you have to remember this, and act accordingly, 2) this means PWR would be 4.2V with LiPo attached, and 5V without, and 3) when bypassed, there would be no over-current protection for the USB port.

Especially that 3rd issue is bad – JeeNodes are about tinkering with stuff, and JN USB’s are about tinkering while attached to a computer USB port. Without over-current protection, tinkering can damage your computer – scary!

There is one more way to solve this, but it’s not very practical: add a big electrolytic cap which sort of takes the place of a battery. I used a 6800 µF (which pulls too much current on power-up, BTW). The result:

SCR36

A voltage on the PWR pin which carries 3.8 .. 4.2V, with a 10 Hz ripple. Not great, but good enough to make the JeeNode’s internal regulator work. Except that a 6800 µF capacitor is huge and highly impractical, of course!

Sooo… back to the MAX1555 it is. That chip works differently: it senses the charge current and the output voltage.

Note to self: don’t replace chips without testing all essential modes they’ll be used in.

And good bye Mr. Murphy, how considerate of you to drop by once in a while…

Junk USB power

In Hardware on Jan 25, 2013 at 00:01

The P1 JeeNode which was recently hooked up to my smart meter stopped working – or maybe I switched USB adapter and never checked?

First thought was to check it out, and although that provided some useful insight, it didn’t solve the problem: node blinking furiously and – more importantly – no data packets!

Well, it turns out that this thing was the problem:

That’s not a Texas Instruments unit, or rather: it’s probably from a rejected batch which found its way to the “surplus” market again (got it from Pollin in Germany, long ago).

Hooking it up to the scope tells the whole story at a glance – first the unloaded output:

Not stellar, but not shocking either. Let’s zoom in on the start of the voltage bumps:

Mweh… nasty. But here’s the same output with a JeeLink plugged in:

Whoa, right… totally useless as a “5V supply”. Ready for the garbage bin… plunk!

Solar… again

In Hardware on Jan 20, 2013 at 00:01

These dark and cold winter days are not really effective for solar energy: the entire month of January will probably not generate more ~~power~~ energy than two peak days in July!

Still, it’s a good baseline to try things with. And one of the experiments I haven’t given up on is making nodes run off solar power, using a supercap to hold the charge. Maybe they’ll not last through the night, but that’s fine – there are still various uses (especially outdoor) where being able to run during daytime with nodes that never need to have their batteries changed would be really nice.

In previous attempts, I’ve always immediately tried to power the actual node, but now I’d like to try something simpler: a solar cell, a supercap, and a resistor as load. Like this:

I’m using a tiny solar cell by Clare again, the CPC1824, with the following specs:

Not much, but then again, it’s a cell which is just the size of a fingernail. As SOIC-16 package, and with the specs of the available current next to it:

In fact, I’d like to try this out with 4 different resistive loads:

one cell, 2x R = 20 MΩ = 0.2 µA current draw at full output
one cell, 2x R = 2 MΩ = 2 µA current draw at full output
one cell, 2x R = 200 KΩ = 20 µA current draw at full output
two cells in paralel, 2x R = 200 KΩ = 20 µA current draw at full output

There may be a flaw in this approach, in that the leakage of the supercap could completely overshadow the current draw from the resistors. But my hope is that supercaps get better over time when kept charged. Hmmm… not sure it applies if they run down every night.

So the second part of the idea, is to alternate solar cell use and dumb charging – just to measure how that affects output voltage over time. One hour, DIO will be on, and put the supercap on about 2.7V, the other hour it’ll be off and the solar cell takes over. With a bit of luck, the output voltage changes might show a pattern, right?

I think it’s worth a try and have made a setup with 4x the above – more tomorrow…

P1 revisited

In Hardware on Jan 13, 2013 at 00:01

The P1 port connection I set up recently for picking up data from the utility company’s smart meter isn’t working reliably yet, so I dove a bit deeper into it.

Here’s how I now think the P1 interface is implemented inside that smart meter:

There’s no way to ascertain whether a PNP or NPN transistor is used, without opening the box (impossible without breaking a seal, so definitely not an option!). But given that NPN is more common, the above circuit is my best guess.

The resistance was measured between the DATA and GND pin. The resistance between DATA and REQUEST is usually over 1 MΩ, which indicates that the phototransistor is open. Makes sense: pull the data low regardless of the REQUEST line state, and pull it high when the internal IR LED in that optocoupler is lit. That also explains the awkward inverted TTL logic levels provided by this interface.

What you can see is that the REQUEST line is really nothing but the power supply to the isolated side of the optocoupler. But the surprise is the value of that pulldown resistor!

Let’s do the math: when REQUEST is 5V, and the phototransistor is conducting, it’ll have about a 0.2V collector-to-emitter voltage drop, leaving 4.8V to feed the 180 Ω resistor (I measured 4.75 V, so yeah, close enough).

Whoa… 4.8 V over 180 Ω is 26 mA, a pretty hefty current draw in µC terms!

My conclusions from all this are: there’s no external pull-up or pull-down needed after all, and my hunch is that it’ll work just as fine with REQUEST powered by 3.3V (reducing the current somewhat). All you have to make sure when working with this P1 interface, is that your REQUEST pin can supply those 25-odd milliamps.

If the above is accurate, then nothing forces us to actually use that resistor, by the way. We could simply connect the REQUEST and DATA pins and leave GND dangling. In fact, by re-using the phototransistor in a different way, one could even make it work in active-high mode again (only if no other P1 devices are connected, evidently).

Note that this is for the Landis & Gyr E350 (PDF) smart meter I have – others may differ!

Flukso with RFM12B

In Hardware, Linux on Jan 12, 2013 at 00:01

Some exciting new developments going on…

You’re looking at the final prototype of the latest Flukso meter, which can be connected to AC current sensors, pulse counters, and the Dutch smart metering “P1” port. Here’s the brief description from that website:

Flukso is a web-based community metering application. Install a Fluksometer near your fuse box and you will be able to monitor, share and reduce your electricity consumption through this website.

The interesting bit is that it’s all based on a Linux board with wired and wireless Ethernet, plus a small ATmega-based add-on board which does all the real-time processing.

But the most exciting news is that the new version, now entering production, will include an RFM12B module with the JeeNode-compatible protocol. A perfect home automation workstation. Yet another interesting aspect of this, is that Bart Van Der Meersche, the mastermind behind Flusko, is working on getting the Mosquitto MQTT broker running permanently on that same Flukso meter.

Here’s the basic layout (probably slightly different from the actual production units):

Flukso runs OpenWRT, and everything in it is based on the Lua programming language, which is really an excellent fit for such environments. But even if Lua is not something you want to dive into, the open-endedness of PubSub means this little box drawing just a few Watt can interface to a huge range of devices – from RF12 to WiFi to LAN, and everything flowing in and out of that little box becomes easily accessible via MQTT.

PS. I have no affiliation with Flukso whatsoever – I just like it, and Bart is a nice fellow :)

Audio

Audio DAC

In Hardware on Jan 11, 2013 at 00:01

Last year, I got one of these little low-cost audio Digital-to-Analog Converters on eBay:

Takes digital SPDIF coax in, and produces analog left and right channels out. I got them before the bigger picture of the audio chain in the living room got fleshed out, and in the end I don’t really need this type of converter anymore.

Besides, there was some hiss and hum with these, so it’s not really high-end anyway.

Here’s what’s inside:

That’s a Cirrus Logic CS8416 “192 kHz Digital Audio Interface Receiver”, which apparently has all the smarts to detect and decode a range of serial bit formats, plus a Cirrus Logic CS4344 “10-pin, 24-Bit, 192 kHz Stereo D/A Converter” to generate the L/R audio signals.

I’m a bit surprised by the hiss/hum issues, since the audio DAC is specified as -90 dB THD+N and 105 dB Dynamic Range, which to me sounds like it should be pretty good. Maybe not audiophile level, but hey… neither are my ears, anyway!

Picking up P1 data

In Hardware on Jan 1, 2013 at 00:01

Just in time for 2013, I hooked up the smart meter which was installed a month ago:

This connects DIO4 to the output of the P1 port, which has the following pinout:

The circuit is as follows:

The request pin has to be pulled to 5V (it very likely just powers the isolated side of the built-in optocoupler). The 10 kΩ signal pull-up is needed to improve the rising flank of the signal, and the 10 kΩ resistor to the I/O pin prevents problems when the input signal rises above the 3.3V powering the ATmega.

Tomorrow, I’ll describe the software that goes along with this.

RFM12B startup power consumption

In Hardware on Dec 29, 2012 at 00:01

For quite some time, I’ve wanted to know just how much current the RFM12B module draws on power-up. Well, time for a test using the power booster described recently:

So the idea is to apply a sawtooth signal to the RFM12B, rising from 0 to 3V at the rate of say 10 Hz, and to measure the voltage drop across a 100 Ω resistor at the same time. This will have a slight effect on measurement accuracy – but no more than 2%, so I’m ok with it.

Here is the outcome:

The yellow trace is VCC, the supply voltage – from 0..3V. The magenta trace is the current consumption, which turns out to be 0..650 µA. As you can see, the current draw quickly rises between 1 and 2V, and then continues to increase sort of linearly.

Note that this power consumption can’t be reduced: we don’t have the ability to send any commands to the RFM12B until it has started up!

This type of analysis can also be done using the X-Y mode on most oscilloscopes:

It’s essentially the same picture as before, because the sawtooth is a straight line, and so voltage rise is the same thing as time in this case. Here’s what happens when the input signal is switched to a sine wave:

As expected, the essence of the curve hasn’t changed one bit. Because it really doesn’t matter how we vary VCC over time. But there’s an intriguing split in the curve – this is most likely caused by a different current consumption when VCC is rising vs when it is dropping. Keep in mind that the changes are occurring at 10 Hz, so there’s bound to be some residual charge in the on-board capacitors of the RFM12B module.

Anyway. It’s a bit of a silly distraction to do things this way, but now I do have a better idea of how current consumption increases on startup. This relatively high 0.65 mA current draw was the main reason for including a MOSFET in the new JeeNode Micro v2, BTW.

Assembling the LED Node v2

In AVR, Hardware on Dec 28, 2012 at 00:01

After yesterday’s little mistake, here’s a walk-through of assembling the LED Node v2:

Note that the LED Node comes with pre-soldered SMD MOSFETs so you don’t have to fiddle with ’em.

The LED Node is really just a JeeNode with a different layout and 3 high-power MOSFET drivers, to control up to 72W of RGB LED strips through the ATmega’s hardware PWM. Since there’s an RFM12B wireless module on board, as well as two free JeePorts, you can do all sorts of funky things with it.

As usual, the build progresses from the flattest to the highest components, so that you can easily flip the PCB over and press it down while soldering each wire and pin.

Let’s get started! So we begin with 7 resistors and 1 diode (careful, the diode is polarised):

Be sure to get the values right: 3x 1 kΩ, 3x 1 MΩ, and 1x 10 kΩ (next to the ATmega).

(note: I used three 100 kΩ resistors i.s.o. of 1 MΩ, as that’s what I had lying around)

Next, add the 4x 0.1 µF capacitors and the IC socket – lots of soldering to do on that one:

Then the MCP1702 regulator and the electrolytic capacitor (both are polarised, so here too, make sure you put them in the right way around), as well as the male 6-pin FTDI header:

Soldering the RFM12B wireless radio module takes a bit of care. It’s easiest if you start off by adding a small solder dot and hold the radio while making the solder melt again:

Then solder the remaining pins (I tend to get lazy and skip those which aren’t used, hence not all of them have solder). I also added the 3-pin orange 16 MHz ceramic resonator, the antenna wire, the two port headers, and the big screw terminal for connecting power:

Celebration time – we’ve completed the assembly of the LED Node v2!

Here’s a side view, with the ATmega328 added – as you can see it’s much flatter than v1:

And here’s a top view of the completed LED Node v2, in all its glory:

You can now connect the FTDI header via a USB BUB, and you should see the greeting of the RF12demo sketch, which has been pre-loaded onto the ATmega328.

To get some really fancy effects, check out the Color-shifting LED Node post from a while back on this weblog. You can adjust it as needed and then upload it through FTDI.

Next step is to attach your RGB strip (it should match the 4-pin connector on the far left). Be sure to use fairly sturdy wires as there are up to 2 amps going through each color pin and a maximum of 6 amps total through the “+” connector pin!

Lastly, connect a 12V DC power supply (making absolutely sure to get the polarity right!) and you will have a remote-controllable LED strip. Enjoy!

Murphy strikes the silkscreen

In Hardware on Dec 27, 2012 at 00:01

Uh, oh – silly mistake time! Here’s an excerpt of the new LED Node v2:

TOP: BOTTOM:

These are the top and bottom view of the FTDI connector in the middle of the board, flipped horizontally.

The bottom view has the “GND” label on the wrong pin!

Drat. Will do a re-spin with the corrected silkscreen, but the first few units will be like this so make sure you use the alignment shown on the top of the board.

The good news is that connecting the FTDI cable or BUB the wrong way is harmless.

JavaScript

Connecting a Blink Plug to a web browser

In Hardware, Software on Dec 23, 2012 at 00:01

Here’s a fun experiment – using Node.js with SocketStream as web server to directly control the LEDs on a Blink Plug and read out the button states via a JeeNode USB:

This is the web interface I hacked together:

The red background comes from pressing button #2, and LED 1 is currently on – so this is bi-directional & real-time communication. There’s no polling: signalling is instant in both directions, due to the magic of WebSockets (this page lists supported browsers).

I’m running blink_serial.ino on the JeeNode, which does nothing more than pass some short messages back and forth over the USB serial connection.

The rest is a matter of getting all the pieces in the right place in the SocketStream framework. There’s no AngularJS in here yet, so getting data in and out of the actual web page is a bit clumsy. The total code is under 100 lines of CoffeeScript – the entire application can be downloaded as ZIP archive.

Here’s the main client-side code from the client/code/app/app.coffee source file:

(some old stuff and weird coding in there… hey, it’s just an experiment, ok?)

The client side, i.e. the browser, can receive “blink:button” events via WebSockets (these are set up and fully managed by SocketStream, including reconnects), as well as the usual DOM events such as changing the state of a checkbox element on the page.

And this is the main server-side logic, contained in the server/rpc/serial.coffee file:

The server uses the node-serialport module to gain access to serial ports on the server, where the JeeNode USB is plugged in. And it defines a “sendCommand” which can be called via RPC by each connected web browser.

Most of the work is really figuring out where things go and how to get at the different bits of data and code. It’s all in ~~JavaScript~~ CoffeeScript on both client and server, but you still need to know all the concepts to get to grips with it – there is no magic pill!

Tomorrow, I’ll describe how I created this app, and how to run it.

Update – The code is now on GitHub.

Meet the LED Node v2

In Hardware on Dec 14, 2012 at 00:01

The LED Node has been around for a while, but I wasn’t 100% happy with it. In principle, the LED Node v1 is a JeeNode plus 1.5 MOSFET Plugs plus an optional Room Board.

There is a small but significant difference with regular JeeNodes (apart from their very different shape), in that all three MOSFETs are tied to pins with hardware PWM support. This is important to get flicker-free dimming, i.e. if you want to have clean and calm color effects. Software PWM doesn’t give you that (unless you turn all other interrupt sources off), and even with hardware PWM it requires a small tweak of the standard Arduino library code to work well.

The neat thing about the LED Node is the wireless capability, so you can control the unit in all sorts of funky ways.

But I didn’t like the very sharp pulses this board generates, which can cause problems with color shifts over long strips and also can produce a lot of RF interference, due to the LED driving current ringing. The other thing which didn’t turn out to be as useful as I thought was the room board part.

So here’s the new LED Node v2:

The big copper areas on the left are extra-wide traces and cooling pads, dimensioned to support at least 2 Amps for each of the RGB colors, for a total of 6 A, i.e. 72 W LED strips @ 12 V. But despite the higher specs, this board will actually be lower profile, because it uses a different type of MOSFETs. They are surface mounted and come pre-soldered so you don’t have to fiddle with them (soldering such small components on relatively large copper surfaces requires a good soldering iron and some expertise).

This new revision has the extra resistors to reduce ringing, and replaces the room board interface with two standard 6-pin port headers: one at the very end, and one on the side. These are ports 1 and 4, respectively, matching a standard JeeNode and any plugs you like. If you want, you could still hook up a Room Board, but this is now no longer the only way to use the LED Node.

Wanna add an accelerometer or compass to make your LED strips orientation aware? Well… now you can! And then place them inside your bike wheels? Could be fun :)

Details to be posted on the Café wiki soon, as well as in the Shop.

Audio

The world of audio

In Hardware on Dec 13, 2012 at 00:01

There’s a huge world out there which I’ve never looked into: audio. And it has changed.

It used to be analog (and before my time: vacuum tubes, or “valves” as the British say).

Nowadays, it’s all digital and integrated. The common Class-D amplifier is made of digitally switching MOSFETs with some cutoff filters to get rid of the residual high-frequency this generates. Leaving just the “pure” audible portion to drive the speakers.

With the recent switch to a new small TV, away from the Mac Mini, for our TV & music system, I lost the original hook-up we had, which was a (far too cheap) little analog amplifier driving (far too expensive) speakers we’ve had here for a long time.

So now we have this TV with built-in tiny 2.5W speakers blasting to the rear – a far cry from the sound we had before. And no music playback capability at all in the living room right now. Not good!

Our needs are simple: CD-quality music (we’re no audiophiles) and decent TV sound. I am going to need a setup soon, as the Christmas vacation time nears.

Trouble is: the sound source for our music is on the Mac Mini server, which is in an impossible place w.r.t. the TV and the speakers. So my first thought was: an Airport Express. It can play over WiFi, and has optical audio output. But… the AE draws 4W in standby. And turning it on for each use is awkward: waiting a minute or more to get sound from the TV is not so great.

The other options for music are an Apple TV or a specially-configured Raspberry Pi.

The only remaining issue is how to get sound from line-level analog audio or (preferably) digital audio to the speakers. I ended up choosing something fairly simple and low-end, a component from miniDSP called “miniAMP”:

DSC 4302

This takes all-digital I²S signals and produces 4x 10W audio. It needs a 12..24V @ 4A supply, i.e. a simple “brick” should do. But that’s just half a solution: it needs I²S…

This is where the “miniDSP” component comes in (the SOIC chip at the top is a PIC µC):

DSC 4301

So the whole setup becomes as follows – and I’ll double up the miniAMP (one for each channel) if the output is not powerful enough:

Screen Shot 2012 12 12 at 23 11 57

The miniDSP takes 2x analog in, and produces up to 4x digital I²S out. The nice part is that it’s fully configurable, i.e. it can do all sorts of fancy sound processing:

Screen Shot 2012 12 12 at 23 21 17

This is perfect for our setup, which includes old-but-incredibly-good separate speakers for the highs and the lows. So a fully configurable cross-over setup is just what we need:

Screen Shot 2012 12 12 at 23 23 11

The way this works is that you set it up, burn the settings into the DSP front-end via USB, and then insert it into the audio chain.

It’s tempting to start tinkering with this stuff at an even lower level, but nah… enough other things to do. Although I do want to look into auto shut-off at some point, to further lower power consumption when no audio is being played. But for now this will have to do.

Fourier analysis

In Hardware on Dec 8, 2012 at 00:01

The three scope shots shown yesterday illustrated how the output signal moves further and further away from the “ideal” input sine waves, near the limits of the AD8532 op-amp.

This was all based on a vague sense of how “clean” the wave looks. Let’s now investigate a bit deeper and apply FFT to these signals. First, the 500 KHz from my frequency generator:

SCR09

You can see that peak #1 is the 500 KHz signal, but there’s also a peak #2 harmonic at 1 MHz, i.e. twice that frequency, and an even weaker one at 1.5 MHz.

My frequency generator is not perfect, but let’s not forget to put things in perspective:

peak #1 is at roughly 10 dBm
peak #2 is at roughly -40 dBm, i.e. 50 dB less

First off: I really should have set to scope to dBV. But the image would have looked the same in this case – just a different scale, so let’s figure out this dBm thing first:

0 dBm is defined as 1 mW of power
the generator was set to drive a 50 Ω load, but I forgot to enable it
therefore the “effective load” is 100 Ω (off by a factor of two, long story)
the signal is swinging ± 1 V around a 2V base level, i.e. 0.707 V (RMS)
so the signal is driving ± 7.07 mA into the load (plus 14.14 mA DC)
power is I x V, i.e. 7.07 mA x 0.707 V x 2 (for the termination mistake) = 10 mW

Next thing to note is that dB and dBm (decibels) use a logarithmic scale. That’s a fancy way of saying that each step of 10 is 10 times more or less than the previous. From 0 to 10 dBm is a factor 10, i.e. from 1 mW to 10 mW. From 10 to 20 dBm is again a factor 10, i.e. 10 mW to 100 mW, etc. Likewise, -10 dBm is one tenth of 0 dBm (0.1 mW) etc.

The 500 KHz signal (peak #1) is therefore 10 mW (10 dBm), and the 1 MHz harmonic is roughly 100,000 times as weak at 0.1 µW (-40 dBm). It looks like a huge peak on the screen, but each vertical division down is one tenth of the value. The vertical scale on screen covers a staggering 1:100,000,000 power level ratio.

That 500 KHz sine wave is in fact very clean, despite the extra peaks seen at this scale.

Now let’s look at the same signal, on the output of the op-amp:

SCR10

Not too bad (the second peak is still less than 1/30,000 of the original). Which is why the output shape at 500 KHz still looks very much like a pure sine wave.

At 1 MHz, the secondary peaks become a bit more pronounced:

SCR05 . SCR06

And at 2 MHz, you can see that the output harmonics are again a lot stronger:

SCR07 . SCR08

Not only has the level of the 2 MHz signal dropped from 9.23 dBm to 6.59 dBm, the second harmonic at 4 MHz is now only a bit under 1/100th the main frequency. And that shows itself as a severely distorted sine wave in yesterday’s weblog post.

In case you’re wondering: those other smaller peaks around 1 MHz come from public AM radio – there are some strong transmitters, located only a few km from here!

Anyway – I hope you were able to distill some basic intuition from this sort of signal analysis, if this is all new to you. It’s quite a valuable technique and all sort of within reach now, since most recent scopes include an FFT capability – the bread and butter of the analog electronics world…

Let’s now get back to digital again. Ah, bits and bytes, sooo much simpler!

Op-amp limits

In Hardware on Dec 7, 2012 at 00:01

Let’s look at that AD8532 dual op-amp mentioned yesterday and start with its “specs”:

Screen Shot 2012 11 24 at 22 54 50

The slew rate is relatively low for this unit. Its output voltage can only rise 5V per µs. In a way, this explains the ≈ 0.1 µs phase shift in the image which I’ll repeat again here:

SCR17

As you can see, the 500 KHz sine wave takes about 200 ns to rise 1 division, i.e. 0.5V, so it’s definitely nearing the limit of this op-amp. Let’s push it a bit with 1 and 2 MHz sine waves:

SCR19

SCR20

Whoa! As you can see, the output cannot quite reproduce a 1 MHz input signal faithfully (there’s an odd little ripple), let alone 2 MHz in the second screen, which starts to diverge badly in both shape and amplitude. The vertical scale is 0.5V per division.

Sine waves are “pure frequencies” – in a vague manner of speaking. It’s the natural way for things to oscillate (not just electrical signals, sine waves are everywhere!). The field of Fourier analysis is based on one of the great mathematical discoveries that all repetitive signals (or motions) can be re-interpreted as the sum of sines and cosines with different amplitudes and frequencies.

You don’t have to dive into the math to benefit from this. Most modern oscilloscopes support an FFT mode, an amazing computed transformation which decomposes a repetitive signal into those sine waves. One of the simplest uses of FFT is to get a feel for how “pure” signals are, i.e. how close to a pure sine wave.

Unfortunately, I have too many FFT scope shots for one post, so tomorrow I’ll post the rest and finish this little diversion into signal analysis. It’ll allow us to compare the above three signals in a more quantitative way.

Power booster

In Hardware on Dec 6, 2012 at 00:01

The trouble with the Arbitrary Waveform Generator I use, is that it has a fairly limited output drive capability. I thought it was broken, and returned it to TTi, but they tested it and couldn’t find any problem. It’ll drive a 50 Ω load, but my habit of raising the signal to stay above 0V (for single-supply uses) probably pushed it too far via that extra DC offset.

I’d like to use a slow ramp as sort of a controllable power supply for JeeNodes and the AA Power Board to find out how they behave with varying input voltages. A simple sawtooth running from 0.5V to 4V would be very convenient – as long as it can drive 50 mA or so.

Here’s one way to do it:

Volt follower

This is an op-amp, connected in such a way that the output will follow exactly what the input is doing – hence the name buffer amplifier or “voltage follower”.

Quick summary of how it works – an op-amp always increases its output when “+” is above “-“, and vice versa. So whatever the output is right now, if you raise the “+” pin, the output will go up, until the “-” pin is at the same value.

It seems pointless, but the other property of an op-amp, is that the input impedance of its inputs is very high. In other words: it draws nearly no current. The input load is negligible.

The output current is determined by the limits of the op-amp. And the AD8532 from Analog Devices can drive up to 250 mA – pretty nice for a low-power supply, in fact!

Here’s the experimental setup (only one of the two op-amps is being used here):

DSC 4273

Here you can see that the input voltage is exactly the same as the output:

SCR17

(yellow = input signal, blue = output signal, a 500 KHz sine wave between 1V and 3V)

Well, almost…

As you can see, there’s a phase shift. It’s not really a big deal – keep in mind that the signal used here is a high-frequency wave, and that shift is in fact less than 0.1 µs. Irrelevant for a power supply with a slow ramp.

Tomorrow I’ll bombard you with scope shots, to illustrate how this op-amp based voltage follower behaves when gradually pushed beyond its capabilities. Nasty stuff…

Keep in mind that the point of this whole setup is to drive more current than the function generator can provide. As a test, I connected a 100 Ω resistor over the output, and sure enough nothing changes. The AD8532 will simply drive the 10..30 mA through the resistor and still maintain its output voltage.

The beauty of op-amps is that all this just works!

But there is a slight problem: the AD8532 can drive up to 250 mA, but it’s not short-circuit proof. If we ever draw over 250 mA, we’ll probably damage it. The solution is simple, once you think about how op-amps really work (from the datasheet):

Screen Shot 2012 11 24 at 20 26 21

The extra resistor limits the output current to the safe value, but the side-effect is that the more current you draw, the less “headroom” you end up with: if we draw 100 mA, then that resistor will have a 2V voltage drop, so the maximum output voltage will be 3V when the supply voltage is 5V.

If you look at my experimental setup above, you’ll see a 22 Ω resistor tied to each output.

That’s it. This simple setup should make it possible to explore how simple circuits work with varying supply voltages. A great way to simulate battery limits, I hope!

Ringing MOSFETs

In Hardware on Dec 5, 2012 at 00:01

The LED Node uses MOSFETs to drive the red, green, and blue LED strings, respectively.

Here’s the circuit (note that the LED strips must also include current-limiting resistors):

JC s Grid page 39

Well… in the LED Node v1, input pin B and resistor R2 are missing, and R1 is 10 kΩ.

This leads to a fair amount of electrical trouble – have a look:

SCR31

The yellow line is the input, a 6V signal in this case (not 3.3V, as used in the LED Node). The blue line is the voltage over the MOSFET. The input is a 1000 Hz square wave with 20% duty cycle, i.e. 200 µs high, 800 µs low.

When the input voltage goes low, the N-MOSFET switches off. In this case, I don’t use an actual LED strip as load, but a 1 Ω power resistor, driven from a 2V power supply line to keep the heat production manageable during these tests. So that’s 2 A of current going through the MOSFET, and when it switches off that happens so quickly that the current simply has nowhere to go (the power supply is not a very nice conductor for such high-frequency events, alas).

As you can see, this signal ringing is so strong in this case, that the voltage will overshoot the power supply by a multiple of 2V.

Here are the leading edge (MOSFET turns on & starts to draw 2 A) and the trailing edge (MOSFET turns off & breaks the 2 A current) of that cycle again, in separate screenshots:

SCR34 SCR36

The horizontal time scale is 1 µs per division.

The vertical scales are 0.5 V and 5 V (!) per division for the input (yellow) and MOSFET voltage (blue), respectively. Note the 30V overshoot when turning that MOSFET off!

This has all sorts of nasty consequences. For one, such high frequency signals will vary across the length of the LED strip, which will affect the intensities and color balance.

But what’s much worse, is the electromagnetic interference these signals will generate. There’s probably a strong 5..10 MHz component in there. Yikes!

There are various solutions. One is to simply dampen the turn-on / turn-off slopes by inserting a resistor in series between the µC’s output pin and the MOSFET’s gate. If you recall the schematic above, I switched the output signal to pin B, made R1 = 1 MΩ and R2 = 1 kΩ. Here’s the effect – keeping all other conditions the same as before:

SCR35 SCR37

What a difference! Sure, the flanks have become quite soft, but that ringing has also been reduced to one fifth of the original case. And those soft flanks (about 2 µs on the blue line) will probably just make it easier to dim the LED strips to very low levels.

The little hump at about 1V is when this particular MOSFET starts to switch – these units were specifically selected to switch at very low voltages, so that they would be fully switched on at 3.3V. This helps reduces heat generation in the MOSFETs – an important detail when you’re switching up to 2 Amps. And indeed, the STN4NF03L MOSFETs used here don’t get more than hand-warm @ 2A – pretty amazing technology!

The new LED Node v2 will include those extra resistors in the MOSFET gate, obviously. And that 1 kΩ value for R2 seems just about right.

The other resistor (R1) is a pull-down, it only serves to avoid unpleasant power-up spikes – by keeping the MOSFET off until the µC enables its I/O pins and starts driving it.

In case you’re wondering about the ringing on the yellow input trace: there’s something called the Miller effect, which amplifies the capacitance between the drain and the gate, causing strong signals on the output to leak back through to the gate. The input signal from my signal generator has a certain impedance and can’t fully wipe them out.

Oh, by the way, have a nice Sinterklaas! :)

Meet the Color Plug

In Hardware on Dec 4, 2012 at 00:01

Yet another plug designed by Lennart Herlaar:

DSC 4291

It contains the TAOS TCS3414 color sensor. JeeLib now includes a new ColorPlug class which simplifies reading out this chip, as well as a colorDemo.ino sketch:

Screen Shot 2012 12 03 at 15 17 47

Sample output:

Screen Shot 2012 12 03 at 14 03 40

One nice use for this sensor and code is to determine the color temperature of white light sources, such as incandescent lamps, CFL’s, and LED’s. I’m trying to find a pleasant replacement for a few remaining warm white halogen lights around the house here and such a unit (especially portable) could be very handy when shopping for alternatives.

Hardware description in the Café to follow soon, as well as in the JeeLabs shop.

Onwards!

Meet the Precision RTC Plug

In Hardware on Dec 3, 2012 at 00:01

Here’s another new board, the Precision RTC Plug – this is is a revision of a design by Lennart Herlaar from almost a year ago – my, my, this year sure went by quickly:

DSC 4292

The current RTC Plug from JeeLabs will be kept as low-end option, but this one reduces drift by an order of magnitude if you need it: that’s at most ≈ 1 second per week off over a temperature range of 0 .. 40°C. Or one minute per year.

Drift can go up to twice that for the full -40 .. +85°C range, but that’s still one sixth of the crystal used in the original RTC Plug. Considerably better than this, in fact, if you need the extended temperature range. Here’s a comparison between both plugs, from the datasheet:

Screen Shot 2012 12 02 at 12 58 23

The way the Precision RTC works is with a Temperature Compensated Crystal Oscillator (TCXO): once a minute, the approximate temperature is determined and the capacitance used by the crystal oscillator is adjusted ever so slightly to try and keep the 32,768 Hz frequency right on the dot. Since the chip also knows how long it has been running, it can even apply an “aging” correction to compensate this small effect in every crystal.

The temperature can be read out, but it’s only specified as accurate to ± 3°C.

No need to use any special software for this, all the normal clock functions are available through the same code as used with the original RTC Plug. If you want to use fancy functions, or perhaps calibrate things further for an even lower drift, you can access all the registers via normal I2C read and write comands.

The board will be added to the shop in a few days, and the wiki page on the Café updated.

Meet the JeeNode Micro v2

In Hardware on Dec 2, 2012 at 00:01

Just in yesterday, haven’t even had the time yet to assemble it!

DSC 4294

Dig that JeeLabs logo on there! :)

As you can see, the shape and layout have not changed much in this revision:

JMv2 traces

Here’s the main part of the new JeeNode Micro v2 schematic:

Screen Shot 2012 12 01 at 16 23 13

Several major changes:

the power to the RFM12B module is now controlled via a MOSFET
the PWR pin is connected to the +3V pin with 2 diodes
there’s room for an optional boost regulator (same as on the AA Power Board)
and there’s even room for a RESET button

When you look at the PCB’s, you’ll see that the extra headers have all been removed, there is just one 9-pin header left – the “IOX” signal from v1 now controls power to the RFM12B.

Through a sneaky placement of the ISP header, there is still a way to connect a single-cell AA or AAA battery to opposite ends of the board.

This extra power control is intended to reduce the current consumption during startup, but I haven’t tried it yet. The idea is that the RFM12B will not be connected to the power source before the ATtiny starts and verifies that the voltage level is high enough to do so. After that, it can be turned on and immediately put to sleep – in practice, its power probably never needs to be turned off again.

The other main change has to do with the different power options:

2.2 .. 3.8V through the +3V pin, intended for 2-cell batteries of various kinds
3.5 .. 5.1V through the PWR pin, for 5V and LiPo use
0.9 .. 5.1V through the PWR pin when the boost regulator is present

The latter might seem the most flexible one, but keep in mind that the boost regulator has a 15 .. 30 µA idle current draw, even when the rest of the circuit is powered down, so this is not always the best option (and the extra switching supply components add to the cost).

As you can imagine, I’ll be running some final tests on all this in the next few days – but the new unit is now available for pre-order in the shop (“direct power” version only for now, the boost version will be available later this month). Design files are in the Café.

Picking up the P1 bus

In Hardware on Nov 30, 2012 at 00:01

With the smart meter installed, I just couldn’t resist a quick readout check of the serial data of the public “P1 port”. It’s an (inverted) TTL serial signal @ 9600 baud, even parity, 7 bits with data coming out the moment you put some voltage of the “request” line.

That request line is probably nothing other than the power feed of the optocoupler inside the unit, since the output voltage more or less matches the voltage I feed it. So this could probably be operated at 3.3V as well as 5V.

A good test case for the Hameg HMO2024 scope, which has serial bus decoding built-in:

SCR39

The green bars indicate correct parity. Not only is decoding a breeze this way, the latest scope firware update also added a “Bus Table” so that you can view the decoded data as a list and even dump it to a USB stick. Here’s the first part of what came out – as a CSV file:

  "Bus Table: BUS1 (UART: CH1, L, 9600,7,E,1)"
  Frame,Mark,Start time[s],Length,Data,State
  1,,7.90800e-6,1,'/',OK
  2,,1.04791e-3,1,'X',OK
  3,,2.08791e-3,1,'M',OK
  4,,3.12791e-3,1,'X',OK
  5,,4.16791e-3,1,'5',OK
  6,,5.20791e-3,1,'X',OK
  7,,6.24791e-3,1,'M',OK
  8,,7.28791e-3,1,'X',OK
  9,,8.32791e-3,1,'A',OK
  10,,9.36791e-3,1,'B',OK
  11,,10.40791e-3,1,'C',OK
  12,,11.44791e-3,1,'E',OK
  13,,12.48791e-3,1,'0',OK
  14,,13.52791e-3,1,'0',OK
  15,,14.56791e-3,1,'0',OK
  16,,15.60791e-3,1,'0',OK
  17,,16.64791e-3,1,'4',OK
  18,,17.68791e-3,1,'6',OK
  19,,18.72791e-3,1,'0',OK
  20,,19.76791e-3,1,'9',OK
  21,,20.80791e-3,1,'9',OK
  22,,21.84791e-3,1,0x0D,OK
  23,,22.88791e-3,1,0x0A,OK
  24,,23.92791e-3,1,0x0D,OK
  25,,24.96791e-3,1,0x0A,OK
  26,,26.00791e-3,1,'0',OK
  27,,27.04791e-3,1,'-',OK

Pretty trivial to decypher, so I whipped up a Tcl script for my trusty JeeMon swiss army knife (whatever works, right?):

Screen Shot 2012 11 29 at 18 08 52

And here’s the result of one scope capture (serial numbers were altered a bit):

  /XMX5XMXABCE000046099

  0-0:96.1.1(30313337323430332020202020202020)
  1-0:1.8.1(00003.540*kWh)
  1-0:1.8.2(00011.199*kWh)
  1-0:2.8.1(00000.000*kWh)
  1-0:2.8.2(00004.667*kWh)
  0-0:96.14.0(0002)
  1-0:1.7.0(0000.35*kW)
  1-0:2.7.0(0000.00*kW)
  0-0:17.0.0(999*A)
  0-0:96.3.10(1)
  0-0:96.13.1()
  0-0:96.13.0()
  0-1:96.1.0(3131323838323030303336383037303132)
  0-1:24.1.0(03)
  0-1:24.3.0(121129160000)(00)(60)(1)(0-1:24.2.0)(m3)
  (00014.684)
  0-1:24.4.0(2)
  !

(probably took some committee years of work to come up with this sort of gibberish)

Four electricity counter totals (night/day and consumed/produced, respectively), then two actual power consumption/production levels, then the gas meter readout. Note that the meter does not know the separate consumption and production levels – it only sees the total, but it can detect whether the flow is positive or negative.

Easy stuff. Access to the values used for our electricity and gas bill at last!

PS. This will also allow comparing and calibrating the results obtained by other means: three 2000 pulse/kWh counters attached to a JeeNode and three current transformers attached to the Flukso Meter. They each measure different things, but it’s all hooked up in such a way that the total consumption or production can be calculated with each setup.

Smart metering

In Hardware on Nov 29, 2012 at 00:01

JeeLabs has entered the 21st century…

The electricity company just installed a new “smart meter” – because they want to track consumed and produced electricity separately, something the total count on the old Ferraris-wheel meter cannot provide:

DSC 4279

See that antenna symbol on there? Its green LED is blinking all the time.

At the bottom on the right-hand side is an RJ11 jack with a “P1” connection. This is a user-accessible port which allows you to get readings out once every 10 seconds. It’s opto-coupled with inverted TTL logic, generating a 9600 baud serial stream from what I’ve read. Clearly something to hook up one of these days.

The gas meter hanging just beneath it was also replaced:

DSC 4280

Why? Because it sends its values out periodically over wireless to the smart meter, which then in turn sends it out via GPRS to the utilities company.

Apparently these gas counter values are only reported once an hour. Makes sense, in a way: gas consumption is more or less driven by heating demands, and aggregated over many households these probably vary fairly slowly – depending on outside temperature, wind, humidity, and how much the sun is shining. Not nearly as hard to manage as the electricity net, you just have to keep the gas pressure within a reasonable range.

Electricity is another matter. And now it’s all being monitored and reported. Not sure how often, though – every 2 months, 15 minutes, 10 seconds? How closely will big brother be watching me? First internet & phone tracking, and now this – I don’t like it one bit…

Welcome to the 21st century. Everything you do is being recorded. For all future generations to come.

Snooping with an Optocoupler

In Hardware on Nov 28, 2012 at 00:01

The thing with OpenTherm, is that the amount of current going through the wire is used by the boiler to send messages to the thermostat.

The reverse path, i.e. from thermostat to boiler, is signalled by voltage changes, which are considerably easier to detect. So let’s save that for later.

There is a small complication, in that the polarity of the wiring between boiler and thermostat is not defined, so either one of them could be “”+” and “-“, respectively. Of course once you’ve hooked things up, that polarity never changes again.

Can we measure the current going through a wire, without knowing in which direction it is flowing? We know it’ll be 5..7 mA for one signalling state and 20..25 mA for the other.

Here’s what I came up with:

JC s Grid page 47

There are two optocouplers in there, with the diodes connected in opposite ways. Depending on the direction of the current, one of them will block and the other one will light up – once the voltage over the 82 Ω resistor exceeds about 1V, i.e. at ≈ 12 mA.

For documentation purposes, the actual build:

DSC 4272

The voltage drop over this circuit is at most just over 1V, which may or may not interfere with proper operation of the boiler and thermostat. Testing will be needed to find out.

The first advantage of this circuit is that it works with either polarity without needing a bridge rectifier (which would introduce yet another voltage drop). In addition, the output signal is galvanically isolated from the OpenTherm loop, i.e. “floating”. That means it can be connected in whatever way is needed.

The second part of an “OpenTherm snooper” – if it ever materialises – will be to measure the voltage between the wires and hopefully also to self-power the rest of the circuit. Note that the optocoupler LED lights up when a high current is passing through, and this is also the state where the photo transistor is drawing more current through the 10 kΩ resistor.

Here’s the diode voltage (yellow) and output (blue), using the same ± 10V @ 50 Hz signal as yesterday. The vertical zero axis is one division down from the centre, for both traces:

SCR96

Note how the output triggers on both positive and negative excursions of the input signal due to the anti-parallel LEDs, which is why it ends up having twice as many pulses. So the first half is one LED turning on and off, and the second half is the other LED – both lead to the common OUT pin being pulled down. For OpenTherm use, there’d never be both polarities – only one LED would be active, depending on how the circuit is connected.

The pulse-width asymmetry you see is an artefact of the way the sine wave is applied (using a 150 Ω resistor). This will not happen with a 7..25 mA current toggle and 82 Ω. And while the MCT62 is not one of the fastest optocouplers, especially with a 10 kΩ collector pull-up, I expect that the resulting pulses will still be accurate enough.

So far so good. I haven’t built the rest yet – just doodling and trying to figure it all out.

Sensing with an Optocoupler

In Hardware on Nov 27, 2012 at 00:01

The OpenTherm setup keeps me thinking…

I haven’t given up on the OpenTherm Gateway yet, but I’ve also been toying with related ideas for some time to try and just listen in on that current/voltage conversation using a self-powered JeeNode, which then reports what it sees as wireless packets.

It’s all based on Optocouplers, so here’s a first circuit to try things out:

JC s Grid page 47

A very simple test setup, which I’m going to feed a ±10V sine wave @ 50 Hz, just because the component tester on my oscilloscope happens to generate exactly such a signal. The 1 kΩ resistor is internal to the component tester, in fact. Here’s what comes out:

SCR93

The yellow trace is the voltage over the IR LED inside the optocoupler, the blue trace is the voltage on the OUT pin. VCC is a 3x AA Eneloop battery pack @ 3.75V – what you can see is that the LED starts to conduct at ≈ 0.8V, and generates just enough light at 0.975V for the photo transistor to start conducting as well, pulling down the output voltage. With 1.01V over the LED, it already generates enough light for the output to drop to almost 0V.

In other words: within a range of just 41 mV at about 1V, the optocoupler “switches on”.

So much for the first part of this experiment. My hope is that this behavior will be just right to turn this MCT62 optocoupler into a little OpenTherm current “snooper” – stay tuned…

Watts, Amps, Coulombs

In Hardware on Nov 26, 2012 at 00:01

Sometimes I see some confusion on the web regarding the units to measure power with.

Here’s a little summary, in case you ever find yourself scratching your head with this stuff:

Electric potential is sort of a “pressure level” when using the water analogy, expressed in Volts (V)
Current is the flow of electrons, and is expressed in Amperes (A)
Charge is the “amount of electricity”, and is expressed in Coulombs (C)
Power is the product of volts and amperes, and is expressed in Watts (W)

Another measure of power is Volt-Amperes, this is not the same as Watts in the case of alternating current with reactive loads, but let’s not go there for now…

To summarise with the water analogy:

Volts = how high has the water been pumped up
Amps = how much water is flowing
Coulombs = the amount of water
Watts = how much energy is being used (or generated)

You can probably guess from this list that pumping water up twice as high (V) takes twice as much energy, and that pumping up twice as much (A) also takes twice as much energy. Hence the formula:

    Watt = Volt * Ampere

Other equations can also help clarify things. They all add time into the mix (in seconds).

Current is “charge per second”:

    Ampere = Coulomb / second

This is also the way I estimate average current consumption when diving into ultra-low power JeeNode stuff: using the oscilloscope to integrate (sum up) all the instantaneous current consumptions over time, I get a certain Coulomb (or micro-coulomb) value. If that’s a periodic peak and the system is powered-down the rest of the time, then the estimate becomes: X µC used per Y sec, hence the average current consumption is X / Y µA. The advantage of working with Coulombs in this way, is that you can add up all the estimates for the different states the system is in and still arrive at an average current level.

Another one: power consumption is the amount of energy consumed over time. This is often expressed in Watt-hour (Wh) or kilowatt-hour (kWh):

two 100 W lightbulbs running for 5 hours = 2 x 100 x 5 = 1000 Wh = 1 kWh
one LED strip drawing 2 A at 12 V for 3 hours = 2 x 12 x 3 = 72 Wh

And then there’s the “mAh” unit used with batteries, i.e. milli-ampere-hour. Quite simple again, once you get used to this metric system, and realise that you also need the voltage:

2 AA batteries of 1.5V @ 2000 mAh each provide 2 x 1.5 x 2000 = 6000 mWh = 6 Wh
a 5 mA load on batteries of 2000 mAh will run for 2000 / 5 = 400 hours

Battery capacities are roughly as follows for the most common types:

an AA cell has 2500 mAh @ 1.5V = 3.75 Wh
an AA rechargeable cell has 2000 mAh @ 1.2V = 2.4 Wh
an AAA cell has 1000 mAh @ 1.5V = 1.5 Wh
an AAA rechargeable cell has 800 mAh @ 1.2V = 0.96 Wh
a CR2032 coin cell has 200 mAh @ 3V = 0.6 Wh

Wanna be able to run for a week on a coin cell? Better make sure your circuit draws no more than 200 / (24 x 7) = 1.2 mA on average under optimal conditions.

Wanna make it run a year on that same coin cell? Stay under 22 µA average, and it will.

With 2 or 3 AA batteries, you get an order of magnitude more to consume, so if you can get the average under 200..220 µA, those batteries should also last a year (ignoring the fact that batteries always have some self-discharge, that is).

The difference between 2, 3, or 4 AA batteries in series only affects the voltage you get out of them. Chips do not run more efficiently on more voltage – on the contrary, in fact!

For low-power use: run your circuit on as low a voltage as possible, but no lower (wink).

Bi-directional signalling and power

In Hardware on Nov 25, 2012 at 00:01

It looks like the OpenTherm gateway is sensitive to noise and wiring lengths. All my attempts to move the gateway upstairs, next to the boiler/heater, failed. Somehow, this:

  THERMOSTAT  <=>  GATEWAY  <=>  10 m wire  <=>  HEATER

… is not the same as this!

  THERMOSTAT  <=>  10 m wire  <=>  GATEWAY  <=>  HEATER

The OpenTherm documentation (PDF) specifically allows up to 50 meters of untwisted wiring, but I’m clearly running into some issue here.

Time to drag the scope downstairs and hook it up between gateway and heater:

SCR87

The yellow trace is the voltage between the two wires, while the blue trace is the current through those wires. I used a 1 Ω resistor and measured the voltage drop, but had to switch to the most sensitive scale (since I’m using the standard x10 probe), hence all that noise.

Still, you can see the magic of the way the OpenTherm protocol works:

in rest, there’s 6V between the wires and about 6 mA of current flowing (a 1 kΩ load)
this is used by the thermostat to power itself (by keeping a capacitor charged)
when the thermostat sends data, it briefly reduces its current draw
since the boiler (or gateway) is feeding a constant current, this makes voltage go up
that voltage change is then detected and decoded by the boiler / gateway
about 40 ms later, the boiler / gateway then sends a reply
it does this by briefly forcing more current down the wire
this in turn can be detected by the thermostat, which then decodes that reply
there’s a small residual ripple, as the thermostat tries to maintain its 7V idle level

I was going to perform the same measurement on the other side of the gateway, i.e. the connection to the thermostat, but for some reason the gateway really doesn’t like me touching anything or connecting any wires to it (let alone a grounded scope probe). Maybe some noise is picked up and feeding back into one of the PIC’s I/O pins, and completely throwing it off. Luckily, the whole gateway always resets properly when left alone again.

I also sometimes see the thermostat indicating a fault (even just by touching the wire with the scope probe) – so it seems to be getting some power, but it’s definitely not happy.

Maybe the gateway’s output circuit is too sensitive, due to some high-impedance parts in the circuit? That would explain why even just using some long wires two floors down prevents the gateway from working.

Hm, not good – especially since I only wish to monitor the wire, not control it…

Update – these problems are caused by a floating ground. More on this once I get it all sorted out. With many thanks to Schelte Bron for dropping by and helping analyse this!

It’s a current source!

In Hardware on Nov 24, 2012 at 00:01

Let me answer yesterday’s question first: “Is this circuit actually useful for anything?”

You bet: this is called a Current source.

The circuit will deliver a constant current by varying the voltage drop, even when the load varies. You can see this in the fairly flat curve on the Component Tester screenshot included yesterday: no matter what level positive voltage you apply to this thing, it’ll draw about 2 mA (just ignore the negative end of the scale).

Actually, I cheated a bit. The real two-transistor current source circuit looks like this:

Curr source

By moving that 10 kΩ resistor away from the load, and tying it directly to “+” the circuit works even better. I’ve simulated it with an external power supply to drive that resistor separately, and get this CT screen:

SCR84

Totally flat! – And that 2 mA current level is set by the 330 Ω resistor, by the way.

One use for this could be a constant-current LED driver (although its efficiency would be very low – you really need a switching circuit with an inductor to get good efficiency).

So how does this mind-bending circuit actually work?

The key point to note, is that the emitter-to-base junction is essentially a diode (which is probably why transistors are drawn the way they are!). And it has a fixed forward-drop voltage of about 0.65V. As long as the base is less than 0.65V above the emitter voltage, the transistor will be switched off. As soon as the base is raised higher, current will flow through that forward diode and the transistor will start to conduct.

This is also why you always need a current limiting resistor: the base voltage cannot rise above 0.65V, it’ll simply conduct more current. Until the current limits are exceeded and the transistor is destroyed, that is…

First, imagine that the leftmost transistor is absent: then the 10 kΩ will pull up the base of the rightmost transistor and cause it to fully conduct. The circuit now essentially acts as the load in series with the 330 Ω resistor. With a maximum load (a short-circuit), the whole supply voltage will end up across that 330 Ω resistor.

But…

With the leftmost transistor in place, something special happens: as soon as the voltage over the 330 Ω resistor rises above 0.65V, the leftmost transistor will start to conduct, pulling the base of the rightmost transistor down. It will continue to do so until the voltage over the 330 Ω resistor has dropped to 0.65V again. Because at some point the base of the rightmost transistor will be pulled so low that it no longer fully conducts – thus reducing the current through the 330 Ω, and thus lowering the voltage drop across it.

You’re seeing a neat little negative feedback loop in action. These two transistors are going to balance each other out to the point where the 330 Ω resistor ends up having a voltage drop of exactly 0.65V – regardless of what the load is doing!

To get 0.65V over 330 Ω, we need a 0.65/330 = 1.97 mA current.

And so that’s what this circuit will feed to the load. As you can see in that last scope capture, the regulation is extremely good between 0.65 and 9V.

By simply varying the 330 Ω value, we can set any desired fixed current level.

The reason I’m bringing this up, is that this circuit is in fact used in the OpenTherm gateway – see this schematic (look for the upside-down PNP version). With some extra circuitry to set the resistor to either 100 Ω or 28 Ω (100 Ω in parallel with 39 Ω). So the gateway is driving either 7 mA or 25 mA through the thermostat.

Welcome to the magical world of electronics – it’s full of clever little tricks like this!

Mystery circuit

In Hardware on Nov 23, 2012 at 00:01

Here’s a little puzzle for you – what does this circuit do?

DSC 4257

That’s two BC549 NPN transistors and two resistors. Let me draw the schematic:

Mystery

Better still, here’s what it shows when hooked up to my Component Tester:

SCR83

Horizontal scale: -10 V .. +10 V, vertical: -10 mA .. +10 mA.

Bonus question: is this circuit actually useful for anything?

Tackling OpenTherm

In Hardware on Nov 18, 2012 at 00:01

Another project I’ve been meaning to tackle for a very long time is to monitor the central heating and warm water system. Maybe – just as with electricity – knowing more about what’s going on will help us reduce our fairly substantial natural gas bill here at JeeLabs.

The gas heater is from Vaillant and it’s connected to a Honeywell ChronoTherm – this is a “modulating” thermostat which automatically chooses its set-points based on the time of day and the day of the week. It all works really well.

The heater upstairs and the thermostat in the living room are connected by a two-wire low-voltage connection, using the OpenTherm protocol. There’s not that much “open” about this protocol, but people have hacked their way in and have discovered all the basic information being exchanged between these units.

A while back, I got a free PCB (thx, Lennart!) of a circuit by Schelte Bron, called the OpenTherm Gateway, and since all the required components were listed and easily available from Conrad, I decided to give it a go. Here’s the whole thing assembled:

DSC 4244

The documentation is very well done: schematics, parts list, troubleshooting, and more.

This is a “gateway” in that it sits between the heater and the thermostat, so it can not only listen in on the conversation but actually take over. Things you can do with it is to adjust the set-point (i.e. desired room temperature), feed in the temperature from an outside sensor, set the ChronoTherm’s clock, and probably more. I’m only interested in monitoring this stuff for now, i.e. reading what is being exchanged.

The gateway is based on an 8-bit PIC controller, and has some funky electronics to do its thing – because the way these signals are encoded is pretty clever: there are only two wires, yet the heater actually powers the thermostat through them, and supports bidirectional I/O (hint: it uses voltage and current modulation).

One little gotcha is that this gateway brings out its interface as an RS232-compatible serial port. And to my surprise, I found out that I don’t even have any laptops to read out these +/- 12V level signals anymore!

So the next task was to get things back into “normal” logic levels. Simple, although it’s a bit of a hack: remove the on-board MAX232 level converter chip, and insert wires to bring out the original 5V logic levels instead:

DSC 4250

(bare wire + green clip = GND, read wire + yellow clip = RX, white wire + white clip = TX)

Step two: hook it up to a USB-BUB, set to handle 5V logic levels:

DSC 4251

Step three: plug the USB cable into my laptop to pick up the data coming in at 9600 baud.

As you can see, this has wires dangling all over – just to check that the gateway works:

  OpenTherm Gateway 3.2
  T80190000
  B40193900
  T10010A00
  BD0010A00
  T80000200
  B40000200
  ...

Yeay, looks like we’re getting something! Coming up next: making sense of this data…

Ultra-low power op-amp

In Hardware on Nov 17, 2012 at 00:01

Op-amps are one of the building blocks of the modern analog electronics industry.

Here’s an interesting one, the MAX4470 .. MAX4474 series:

Screen Shot 2012 11 14 at 13 09 51

Simple layout, again in a tiny SMD package:

DSC 4269

The other members of this family are dual and quad versions, if you need more op-amps.

This chip is nice because of its phenominally low current consumption: 750 nA at 5V. It gets even better: at 3.3V, I measured a ridiculously low 190 nA!

Here are some more specs from the Maxim datasheet:

Screen Shot 2012 11 14 at 13 14 17

Might not be the highest-performance op-amp out there, but still – this thing could be quite handy to implement comparators, voltage followers, oscillators, amplifiers, filters, and more. Especially when the “power budget” is really really low.

PS. I’m assuming this chip isn’t oscillating with the above test setup, but in normal use you really need to tie the input pins to something to avoid that.

Nanoampere regulator

In Hardware on Nov 16, 2012 at 00:01

The TPS78233 from Texas Instruments looks like a standard LDO linear voltage regulator:

Screen Shot 2012 11 14 at 00 57 17

It takes an input voltage up to 5.5V and regulates it down to 3.3V (the above image from the datasheet is the 2.7V regulator). Not a spectacular voltage range, but it has a very nifty trick up its sleeve:

This regulator only draw 450 nA, i.e. 0.45 µA, when unloaded!

That’s about a quarter of the current consumption of the already-spectacular MCP1702 and MCP1703 used in JeeNodes – a ridiculously low 2.5 microwatts.

Here’s a little test setup (yep, those SMD’s are small – can you see the two 10 µF caps?):

DSC 4258

To get a sense of this level of current consumption: 3x AA batteries of 2000 mAh would last 5 centuries (ehm, well, except for their pesky self-discharge) – which is a bit silly, of course.

To get another idea: when I measure the output voltage with a multi-meter, the current consumption “jumps” to about 750 nA. Why this relatively big change? Because most multi-meters have a 10..11 MΩ input impedance, and 3.3V over 11 MΩ is… 300 nA!

In case you’re wondering: measuring minute currents is easy with Dave Jones’ µCurrent.

The fascinating thing about the TPX82xx series is that it achieves this extremely low idle current while still being able to regulate and supply up to 150 mA. Furthermore, that enable pin might come in very handy for certain ultra-low energy harvesting scenario’s.

But I’m not going to replace the regulator on JeeNodes for a number of reasons:

The MCP1702 can handle input voltages up to 13V (vs only 5.5V for the TPS78233).
There’s no through-hole version, so this would not work for standard JeeNode kits.
Those extra savings only kick in when you get everything into the few-µA range, and so far, things like Room Nodes still draw a few dozen µA’s.
In many cases, when the max is 5.5V anyway, no regulator will be needed at all (note that running only the RFM12B on it may create a problem with signal levels).

But hey, it’s good too know that these chips exist. A few microwatts… wow!

Microwave interference?

In Hardware on Nov 15, 2012 at 00:01

To get more options with remote nodes, I wanted to get this DCF77 clock working again, broadcasting the current time of day once a minute:

3311819588 20f3b58d12 o

Last time I tried (long ago), it didn’t work – but I’ve been running the OOK Relay for ages now, and since it still had the DCF77 receiver hooked up, I decided to have another go.

Sure enough – all it was is a broken wire… doh!

Now there are time-of-day packets in the air again, here at JeeLabs – sent by ookRelay2:

Screen Shot 2012 11 13 at 12 24 29

It works really well – at last – and will come in handy soon enough, I expect.

But the curious thing is those 3 missed packets at 12:13, 12:16, and 12:19.

Could it be the microwave? It was just around the time I was heating up something…

More investigation needed.

Watts up?

In Hardware on Nov 14, 2012 at 00:01

Ok, so all the solar panels are in place and doing their thing (as much as this season allows, anyway). But seeing that live power usage on my desk all day long kept tempting me to try and optimise the baseline consumption just a tad more…

Previous readings have always hovered around 115 Watts, lately. Since the JeeLabs server + router + internet modem use about 30 W together, that leaves roughly 85 W unaccounted for. Note that this is without fridges, boilers, heat circulation pumps, gas heaters, or other intermittent consumers running. This baseline is what we end up consuming here no matter what – vampire power from devices in “standby” and other basic devices you want to keep running at all times, such as the phone and internet connection.

It’s not excessive, but hey: 100 W day-in-day-out is still over 850 kWh on a yearly basis.

Well, today I managed to get the baseline down waaay further:

DSC 4242

That’s including the JeeLabs server + router + modem. So the rest of the house at JeeLabs is consuming under 40 W. Perfect: I’ve reached my secret goal of a baseline under 50 W!

Here’s how that “idle” power consumption was reduced this far:

I turned off an old & forgotten laptop and Ethernet switch, upstairs – whoops!
I removed another gigabit Ethernet switch under my desk (more on that later)
the 10-year old Mac Mini + EyeTV + satellite dish setup has been dismantled and replaced by a small all-in-one TV drawing 0.5W in standby (the monitor is re-used)
I’m switching to DVB-C (i.e. coax-based) reception, available from the internet modem by upgrading to the cheapest triple-play subscription with “analog + digital” channels
that means: no settop box, just the internet modem (already on anyway) and a new low-end but modern Sharp 22″ TV / DVB-C / DVD-player / USB-recorder

As it turns out, the Mac Mini (about 10 years old) plus the master-slave AC mains switch controlling everything else were drawing some 20 W – day in day out. Bit silly, and far too much unnecessary technology strung together (though working, most of the time).

The other biggie: no more always-on Ethernet switches, just the WRT320N wireless router in front of the server, with a second wired gigabit connection to my desk. That’s two really fast connections where it matters, everything else uses perfectly-fine WiFi.

The main reason for having an Ethernet switch near my desk was to allow experimenting with JeeNode-based EtherCards, Raspberry Pi’s, and so on. But… 1) that switch was really in the wrong place, it would be far more convenient to have Ethernet in the electronics corner at JeeLabs, and 2) why keep that stuff on all the time, anyway?

So instead, I’m now re-using a spare Airport Express as wireless-to-wired Ethernet extension router. Plug it in, wait a minute for it to settle down, and voilá – instant wired Ethernet anywhere there is an AC mains socket:

DSC 4243

And if I need more connections, I can route everything through that spare Ethernet switch.

It’s not the smallest solution out there, but who cares. Why didn’t I think of all this before?

High-side switching

In Hardware on Nov 12, 2012 at 00:01

If low-side switching is so troublesome, then why not just flip everything around, right?

High side partial

Not so fast. The I/O pin is tied to a microcontroller running at 3.3 or 5V, so its voltage level will vary between 0 and a few volts. Whereas “+” is more likely to be 5V, 12V, or even 24V.

This means that to keep the PNP transistor switched off, we need to keep the base voltage at nearly the same level as that “+” line. Unfortunately, this is impossible – not only could high voltages on I/O pins of a µC damage them, there is also some protection circuitry on each pin to protect against electrostatic discharge (ESD). If you were to look inside the µC chip, you’d find something like this on each I/O pin:

Esd

What that means is that if you try to pull an I/O pin up to over VCC+0.7V, then that topmost diode will start to conduct. This is no problem as long as the current stays under 1 mA or so, but it does mean that the actual voltage of an I/O pin will never be more than 4V (when running on 3.3V). Which means that PNP transistor shown in the first image will always be on, regardless of the I/O pin state.

We’ll need a more complex circuit to implement a practical high-side power-on switch:

Npn pnp

The workhorse, i.e. the real switch, is still the PNP transistor on the right. But now there’s an an extra “stage” in front to isolate the I/O pin from the higher voltages on the base of that PNP transistor. There’s now essentially a low-side switch in front of the PNP.

When I/O is “0”, no current flows into the base of the NPN transistor, which means it won’t conduct, and hence no current flows into the base of the PNP transistor either.

When I/O is “1”, the NPN transistor will conduct and pull its collector towards ground. That leaves a 10 kΩ resistor between almost ground (0.4V) and almost high (“+” – 0.7V), since the base-to-emitter junction of a transistor is more or less a forward-conducting diode. So the base of the PNP transistor is pulled down, and the PNP transistor is switched on. The resistor values are not too critical here – making them both 10 kΩ would also work fine. But they have to be present to limit both base currents.

A similar circuit can be created with two MOSFETs. With the proper choice of MOSFETs, this will in fact be a better option, because it can handle more current and will have less power loss (i.e. heat). The resistors will need to be placed differently.

Note that all circuits can be analysed & explained in the same way, as long as there are no feedback loops: step-by-step, reasoning about the effect of each stage on the next.

Low-side switching

In Hardware on Nov 11, 2012 at 00:01

Yesterday’s post brought up some good comments, which I’d like to expand on a bit.

To summarise, this is about how to switch power to an electric circuit using an I/O pin.

Yesterday’s solution worked for me, but would fail if the voltage range is not as nicely predictable, i.e. trying to control say between 2 and 12V with an I/O pin which supplies 1.8 to 3.3V. In this case, the 0.7V diode drop of the base-to-emitter junction of a transistor won’t always be of much help.

Let’s examine some approaches. First, what is perhaps the most obvious way:

Low side

With a “normal” (BJT) NPN transistor, you feed it some current by making an I/O pin high, and it’ll conduct. There needs to be a resistor in series, large enough to limit the current, but small enough to drive the transistor into saturation (10 kΩ should work for loads up to say 25 mA, you can reduce it to switch more current).

With an N-MOSFET, you pull the gate up, again by setting an I/O pin high. In this case there should be a resistor to pull the gate down until the I/O pin is set up as an output, to prevent power-up glitches. This resistor can be much larger, 1 MΩ or more. MOSFETs need almost no current (“flow”), they just need voltage (“pressure”) to function.

The benefit of these circuits is that you can easily switch 5V, 12V, or even 24V – with an I/O pin which remains at very low voltage levels (say 1.8 to 3.3V)

In a perfect world, these would both be fine, and be very convenient: “1” is on, “0” is off.

Unfortunately, a transistor is not a perfect switch, so there will be some residual voltage drop over it (0.2..0.4V for the BJT, under 0.1V for the MOSFET). Also, the selected MOSFET has to switch on at low voltages – many types need 4V or more to fully switch on.

One problem with these “low-side” switches (i.e. in the ground wire), is that the circuits will start to float: with a small voltage drop over the transistor, all signal levels to this circuit will be raised slightly, and sometimes unpredictably. So if the circuit has any other connections to the microcontroller (or anything else, for that matter), then these levels will vary somewhat. It’s like shaking hands with someone while standing on a treadmill :)

What’s even worse: when the power is switched off, the circuit ends up being tied to its power supply “+” side, but disconnected from ground – this can cause all sorts of nasty problems with electricty finding its way through other connected pins.

Having said that: if the circuit to be switched has no other outside connections, then either of these setups will work just fine. One example is LEDs and LED strips – which is why the MOSFET Plug uses N-MOSFETs exactly as outlined here. All you need to do is stick with “Common Anode” type RGB LED’s, i.e. tie all the “+” pins (anodes) together to the power supply, and let the MOSFETs do the switching between the “-” pins (cathodes) and GND.

For anything more elaborate, we need “high-side switching” – coming up tomorrow!

LowPower, Electronics, Solar

Switching with a lower voltage

In Hardware on Nov 10, 2012 at 00:01

The SMA Bluetooth relay described yesterday has to switch the power to the RN-42 module using an I/O pin on the ATmega. Currents are fairly small: up to about 50 mA.

I tried directly powering the RN42 from two I/O pins in parallel, but it looks like they don’t have enough current drive capacity for this purpose. So the task is to find a simple way to switch on power somehow.

The simplest solution would seem to be a P-MOSFET in the “high side” supply, i.e. between PWR and the RN-42’s supply pin, but there is a problem: PWR will be somewhere between 3.3 and 5V (actually it’s more like between 3.6 and 4.0V with the 3xAA Eneloop batteries I’m using), but the I/O pin on the ATmega won’t be more than 3.3V – since the ATmega sits behind a 3.3V voltage regulator. I tried the P-MOSFET, before realising that it’d always be driven on – the I/O pin voltage is sufficiently low to switch the MOSFET on, even with a logic “1” – not good!

MOSFETs are driven by voltage whereas transistors are driven by current, so an obvious thing to try next is to use a PNP transistor in more or less the same configuration. Voltage differences wouldn’t be so critical, if no current flows. Also, there’s the extra base-to-emitter voltage drop or so that each normal transistor has. Still, a simple PNP transistor might switch on if the difference in voltage is large enough – this can be overcome with a PNP Darlington transistor, which is simply two PNP transistors, cascaded in a certain way. The property of these things – apart from their high amplification (hFE) – is that you need to drive the base with a slightly larger voltage. A lower voltage in this case, with PNP types. Could also have used two discrete PNP transistors.

Here’s the circuit:

Screen Shot 2012 11 07 at 15 15 47

And sure enough, it works. I happened to have an SMD “BCV 28” lying around:

DSC 4238

The 10 kΩ resistor in series with the base limits the drive current to under 1 mA – more than enough to drive the Darlington into saturation, i.e. the state where the collector-to-emitter voltage drop is at its lowest.

That’s it. Every 5 minutes, a reading arrives on the central JeeLink, as shown by JeeMon:

Screen Shot 2012 11 07 at 15 21 56

Drat, cloudy again! Oh well, just the usual gray November day…

Using watchdog resets

In AVR, Hardware, Software on Nov 9, 2012 at 00:01

The Bluetooth readout node running the “smaRelay” code is ready to go:

DSC 4237

As mentioned yesterday, I’ve decided to take the easy way out and completely power down the Bluetooth module and go through a full powerup/connect/readout cycle about once every 5 minutes.

The advantage for me of a battery-powered unit, is that I don’t have to locate this thing near a power outlet – it can be placed out of sight, unobtrusively doing its work.

I seem to have developed an allergy for power cables and wall warts all over the place…

The power on/off logic held a little surprise, about which I’ll report tomorrow.

Here’s is the new part of the updated smaRelay.ino sketch:

Screen Shot 2012 11 07 at 14 27 33

Quite a different use of the watchdog here:

on powerup, go into low-power mode and wait for 5 minutes
prepare the watchdog to perform a reset in 8 seconds
power up Bluetooth, connect to the SMA, and read out some values
then power down Bluetooth and power up the RFM12 radio
send out a data packet over RF12
lastly, turn the radio off and power down
let the watchdog do the reset and make this sketch start over

This approach has as “benefit” that it’ll fail gracefully: even if anything goes wrong and things hang, the hardware watchdog will pull the ATmega out of that hole and restart it, which then starts off again by entering an ultra-low power mode for 5 minutes. So even if the SMA is turned off, this sketch won’t be on more than about 1% of the time.

Here’s the energy consumption measurement of an actual readout cycle:

SCR80

The readings are a bit noisy – perhaps because I had to use 1 mV/div over a 1 Ω resistor (the 10 Ω used before interfered too much with this new power-switching code).

As you can see, the whole operation takes about 4 seconds. IOW, this node is consuming 153 milli-Coulombs every 300 seconds. That’s 0.5 mC/sec, or 0.5 mA on average. So the estimated lifetime on 3x AA 1900 mAh Eneloops is 3800 hours – some 5 months.

Update – The first set of batteries lasted until March 18th, 2013 – i.e. over 4 months.

Good enough for now. Deploy and forget. Onwards!

Bluetooth power consumption

In Hardware on Nov 8, 2012 at 00:01

The Bluetooth module in yesterday’s setup has a nasty power consumption profile:

SCR78

The yellow line is total power consumption, which to over 60 mA at times, and the smaRelay.ino sketch is querying the SMA inverter roughly every 10.5 seconds. The drop in baseline is the ATmega going to sleep as it waits for the next period, so you can clearly see what the Bluetooth module is doing – while kept on and connected to the SMA in fact.

I’m not sure that the Hameg’s math integral function is up to summing such fast-changing values, but it’s the best I’ve got to measure power consumption here at JeeLabs at the moment (well, either this or tracking the discharge on a hefty electrolytic capacitor).

Note the baseline consumption of about 5 mA, and the frequent but highly irregular brief power consumption pulses. That’s BT doing its frequency hopping thing, I assume.

Anyway, my goal was to get an estimate of the average power consumption, so here we go:

two cursors were used to peg the integral (summed) value over one cycle
charge usage over one 10.5 second period turns out to be 134 millicoulombs
that’s 134 / 10.5 ≈ 12.75 mC per second, i.e. 12.75 mA average

Whoa… not much of a candidate for battery-power this way!

That leaves a couple of options:

just power it via a USB adapter and move on
explore the RN-42’s low-power mode, which is claimed to go as low as 300 µA
completely turn off power to the RN-42

I’m inclined to go for the latter. I don’t really need solar PV readings that often, since the SMA accumulates its daily and total generated power anyway. And during the night, all this reading and reporting activity is also quite useless.

That would also solve – or rather: work around – the intermittent problems present in the current code, in which the sketch stops relaying after a few minutes. It always seems to get stuck after a while, waiting for incoming data from the Bluetooth module.

One readout every 10 minutes would probably be plenty for me, and since the SMA has a time-of-day clock which can be read out over BT, I can stop readouts during the night (or even simpler: add an LDR and switch off when it’s dark).

It looks like powering up, establishing a connection, and reading out one set of values can be done in under 6 seconds, so that leads to a 1% duty cycle. Let’s say 200 µA on average – this ought to run a year on 3x AA Eneloops.

Sometimes, sophisticated solutions are just distractions – whatever works, right?

Relaying SMA data as RF12 packets

In Hardware, Software on Nov 7, 2012 at 00:01

Yesterday’s post shows how to read out the SMA solar PV inverter via Bluetooth. The idea was to install this on the Mac Mini JeeLabs server, which happens to be in range of the SMA inverter (one floor below). But that brings up a little dilemma.

Install a potentially kernel-panic-generating utility on the main JeeLabs server? Nah…

I don’t really care whether this issue gets fixed. I don’t want to have the web server go down for something as silly as this, and since it’s a kernel panic, there’s no point trying to move the logic into a Linux VM – the problem is more likely in Apple’s Bluetooth / WiFi stack, which will get used no matter how I access things.

The alternative is to implement a little “SMA Relay” using a JeeNode with a Bluetooth module attached to it, which drives the whole protocol and then broadcasts results periodically over RF12. That way I can figure out and control it.

I tried to use the SoftwareSerial library built into the newer Arduino IDE releases, but ran into problems with lost bytes – even with the software UART speed down to 19200 baud.

So I ended up first debugging the code on an Arduino Mega, which has multiple hardware UARTs and allows good ol’ debugging-with-print-statements, sending out that debug info over USB, while a separate hardware UART deals with all communication to and from the Bluetooth module.

Once that worked, all debugging statements were removed and the serial Bluetooth was switched to the main (and only) UART of the JeeNode. The extra 10 kΩ R’s in the RX and TX lines allow hooking up a USB BUB for re-flashing. The BUB will simply overrule, but needs to be removed to try things out:

DSC 4236

(the Bluetooth module I used in this setup is Sparkfun’s BlueSMiRF Silver)

Next step was to add a little driver to JeeMon again, the aging-but-still-working Tcl-based home monitoring setup at JeeLabs. Fairly straightforward, since it merely needs to extract a couple of 16-bit unsigned ints from incoming packets:

Screen Shot 2012 11 06 at 10 39 10

And sure enough, data is coming in (time in UTC):

… and properly decoded:

Screen Shot 2012 11 06 at 10 33 08

The ATmega code has been added as example to JeeLib on GitHub, see smaRelay.ino.

I’m still debugging some details, as the Arduino sketch often stops working after a few minutes. I suspect that some sort of timeout and retry is needed, in case Bluetooth comms get lost occasionally. Bluetooth range is only a few meters, especially with the re-inforced concrete floors and walls here at JeeLabs.

Anyhow, it’s a start. Suggestions and improvements are always welcome!

New Flukso meter at JeeLabs

In Hardware on Nov 1, 2012 at 00:01

The Flukso is a little open-source box which can read out a couple of CT current clamps and/or pulse counters to provides electricity / gas / water consumption details – via a JSON/REST interface, either locally or on the Flukso site (private or shared, your call):

Flm02a top

The design is based on the Dragino, and includes an ATmega piggy-back board with extra circuitry specifically for reading out current clamps. It’s not every day that you see designs which can actually deal with power outages in such a way that the last readings get saved to EEPROM in the last few milliseconds – as the system is going down! – but that’s exactly what the Flukso does, showing its great attention to detail.

The Flukso meter’s designer, Bart Van Der Meerssche, is also the driving force behind the Electro:camp meetings, so we had some opportunities to chat and dream about the future these past few days. Lots of interesting options and wild ideas floating around. With Linux in the equation, a lot more sophistication becomes feasible.

To have a better test situation, I’ve decided to add a Flukso setup to JeeLabs, which is in fact trivial since it can connect over WiFi. Power consumption is under 3 W:

DSC 4231

I added the three current clamps as follows (consumption only, no PV solar yield for now):

One 50 Amp CT clamp for the RCD-protected groups 1..3
One 50 Amp CT clamp for the non-RCD-protected groups 4..7
One 50 Amp CT clamp for the induction cooker, group 9

The total should match what I’m measuring with my other 2 pulse counters.

The daughterboard is a prototype with on-board RFM12B (software is work-in-progress).

The other news is that the pulse counter wiring has been fixed, so this is now correct:

DSC 4227

That’s an early morning with heavy clouds. Hey, where’s that sun when you need it!

Debugging with a scope

In Hardware, Software on Oct 30, 2012 at 00:01

Good, but not perfect… I was curious about the actual current consumption of this latest version of the homeGraph.ino sketch. So here’s another timing snapshot:

Annotated capture

This has trace persistence turned on, collecting multiple samples in one screen shot.

As you can see, the radio is turned on for ≈ 75 ms in this case (different JeeNode, slightly different watchdog timer period). Then after 30..35 ms the sketch goes to sleep again.

The second case is when nothing has been received after 150 ms: the “radioTimer” fires, and in this case the sketch turns off the radio as well, assuming there will be no packet coming in anymore.

But the interesting bit starts on the next packet coming in after one has been omitted. The logic in the code is such that the radio will be left on indefinitely in this case. As you can see, every late arrival then comes 100 ms later than expected: same radio-off + power down signature on the right-hand side of the screen capture, just much later.

Here is the code again:

Screen Shot 2012 10 21 at 22 41 49

And the main loop which calls this code:

Screen Shot 2012 10 21 at 22 06 18

That “if (!timingWasGood) …” code is probably wrong.

But it’s not so easy to fix, I’m afraid. Because the timing gets even more tricky if two or more packets are omitted, not just occasionally a single one. Sometimes, the radio doesn’t get switched off quickly – as you can see in this 30-minute capture at the end of the day, when power levels are starting to drop:

SCR56

Maybe I need to try out a software PLL implementation after all. The other reason is that there seems to be a fair amount of variation in watchdog clock timing between different ATmega’s. For one, I had to use 2800 as value for recvOffTime, with another 3000 worked a lot better. A self-locking algorithm would solve this, and would let us predict the next packet time with even more accuracy.

But this is still good enough for now. Normally the radio will only be on for about 100 ms every 3s, so that’s a 30-fold power reduction, or about 0.6 mA on average for the radio.

This still ought to run for a month or two on a 3x AA battery pack, at least for daytime use. Which brings up another idea: turn the whole thing off when it’s dark – the display is not readable without light anyway.

Oh well. Perfection is the enemy of done.

Final HomeGraph setup

In Hardware, Software on Oct 29, 2012 at 00:01

This concludes my little gadget to track home energy use and solar energy production:

DSC 4219

The graph shows production vs total consumption in 15-minute intervals for the last 5 hours. A summary of this infomation is shown at the bottom: “+” is total solar production in the last 5 hours, “-” is total energy consumption in that same period.

The actual consumption values are not yet correct because the home energy pulse counter is wired incorrectly, but they will be once that is fixed. The total home consumption is currently 1327 – 1221 + 7 = 113W, since the home counter is currently driven in reverse.

The graph is auto-scaling and I’m storing these values in EEPROM whenever it scrolls, so that a power-down or reset from say a battery change will only lose the information accumulated in the last 15 minutes.

Power consumption is “fairly low”, because the backlight has been switched off and the radio is turned off between predicted reception times. The mechanism works quite well when there is a packet every 3 or 6 seconds, but with longer intervals (i.e. at night), the sketch still keeps the receiver on for too long.

A further refinement could be to reduce the scan cycle when there are almost no new pulses coming in – and then picking up again when the rate increases. Trouble is that it’s impossible to predict accurately when packets will be skipped, so the risk is that the sketch quickly goes completely out of sync when packet rates do drop. The PLL approach would be a better option, no doubt.

But all in all, I’m quite happy with the result. The display is reasonably easy to read in daylight, even without the backlight. I’ll do a battery-lifetime test with a fresh new battery once the pulse counter wiring has been fixed.

The code has become a bit long to be included in this post – it’s available as homeGraph on GitHub, as part of the GLCDlib project. I’m still amazed by how much a little 200-line program can do in just 11 KB of flash memory, and how it all ends up as a neat custom gadget. Uniquely tailored for JeeLabs, but it’s all open source and easy to adapt by anyone.

Feel free to add a light sensor, a PIR motion detector, an RTC, whatever…

Onwards!

Who needs a server?

In Hardware, Software on Oct 25, 2012 at 00:01

With all those energy pulses flying through the air, we don’t even need a central setup to display this information on a little self-contained Graphics Board display – like so:

DSC 4214

The “homeGraph.ino” sketch which drives it has just been added to GitHub:

Screen Shot 2012 10 21 at 15 20 54

There’s room for a little graph, but it’ll have to wait until the home usage counter has been rewired to measure the proper value (the value shown above is in fact the surplus).

Goodbye Mousetrap

In Hardware on Oct 24, 2012 at 00:01

With the new “homePower” setup now in place and working, it is time to say goodbye to a good companion – this ATmega168-based mousetrap which started it all, 4 years ago:

DSC 4206

Note the dead spider :) – this thing has been soaked a few times, with water dripping from the kitchen on the next floor, yet all it took was a clean wipe, some time to dry, and it just resumed its duties over and over again:

DSC 4210

Very few problems other than that corrosion (probably also inside the mini 3-pin jacks):

DSC 4207

Less than a dozen resets / power cycles over all these years.

This is the predecessor of what eventually became the JeeNode, based on an RBBB by Modern Device. It works on 5V and uses resistor-based level converters for the RFM12B.

The gas measurements have been erratic for some time now, no doubt due to those bad contacts, so I’m going to look for another way to read those values.

And with it ends also the life of the node on the other side, a modified Arduino Mini plugged into the Mac Mini server using an FTDI cable:

DSC 4208

Also based on perf board with Kynar wire-wrapping wire to connect it all together:

DSC 4209

The code used between these two nodes was based on an early version of the RF12 driver protocol, and since it all worked perfectly, I never saw a need to change it. But I’m still going to miss these periodic packets in the logfiles:

  L 09:05:02.167 usb-FTE50C3P HM3 45 43 17 151 73 20 6 0 242 200 0 0 0 0
  L 09:05:07.363 usb-FTE50C3P HM3 45 44 18 151 80 20 6 0 242 200 0 0 0 0
  L 09:05:12.290 usb-FTE50C3P HM3 45 45 19 151 47 19 6 0 242 200 0 0 0 0
  L 09:05:17.361 usb-FTE50C3P HM3 45 46 20 151 200 19 6 0 242 200 0 0 0 0
  L 09:05:22.720 usb-FTE50C3P HM3 45 47 21 151 240 20 6 0 242 200 0 0 0 0
  L 09:05:27.646 usb-FTE50C3P HM3 45 48 22 151 49 19 6 0 242 200 0 0 0 0

Goodbye, dear nodes, and thank you for those nearly 4 years of perfect service!

PS – Don’t forget Elektro:camp next Friday and Saturday!

Solar at last

In Hardware, News on Oct 20, 2012 at 00:01

As mentioned recently, last step was getting the SMA 5000TL inverter and hooking it up:

DSC 4200

DSC 4203

Here’s the before-and-after shot of the hookup:

DSC 4190

DSC 4192

Three pulse-counters to help me measure what comes in, what goes out, and the induction stove (measured separately). Still a minor wiring error, but that’ll be fixed soon.

So that’s the end of the story for now. Let the sun shine!

▶ View 22 Comments

Solar Railway Station

In Hardware on Oct 19, 2012 at 00:01

On a recent trip to Germany, we visited Uelzen, about 100 km north of Braunschweig. Its railway station was “upgraded” (pimped?) some 12 years ago by an Austrian artist called Friedensreich Hundertwasser in what looks very Gaudi-like in style and appearance:

PA175185

He was interested in organic shapes, creating round and uneven fairy-tale like interiors:

PA175215

But the reason I’m mentioning all this, is that the station also includes this display panel:

PA175218

The roof is covered with solar panels, and has been generating electricity for the community since 1997. Almost half a megigawatt-hour produced so far, and still generating just under 8 Kilowatt on a half-cloudy October day.

Way to go! So gibt mann das gute Vorbild!

PS. Calculating back from the figures shown, this would appear to be just 42 m2 of panels, which seems off by an order of magnitude. Oh, wait… that’s not accounting for the panel’s conversion efficiency, I’m guessing that to be somewhere in the 10% range for those panels.

Going solar – almost there!

In Hardware on Oct 15, 2012 at 00:01

It’s been over two years ago since I started looking for ways to collect solar energy on the roof, here at JeeLabs.

And then reality set in… the roofs of the houses in this street are covered with shingles from the late 70’s, and as we found out they contain asbestos – yuck! Then, earlier this year, we were told that nothing could be done on the roof unless those shingles were first officially removed by a specially-equipped third party:

So now at last, those “bad” shingles have been replaced and panels have been mounted:

DSC 4177

That little bulge is a “Solar tube” which brings extra sunlight into the stairway.

That’s 2 x 5 panels on this side, and 3 x 4 on the other roof:

DSC 4183

(the 10 panels you saw in the first picture are mounted on the roof to the far left)

For a total of 22 x 240 = 5280 Wattpeak. Not that they will ever all generate full power at the same time, because these two roofs are facing west and east, respectively. But hey, together they should still give us more than our annual 3100 kWh consumption. JeeLabs is about to become a net electricity producer!

Just one more step: wait for the SMA 5000 inverter to arrive and get it hooked up…

▶ View 20 Comments

Mechanical relays

In Hardware on Oct 13, 2012 at 00:01

Hm… with such a nice switching 5V pulse, it’s sad to tear down yesterday’s circuit again.

One more experiment then. Let’s switch a little relay (the one used in the Relay Plug) at 10 Hz, and give it a serious beating. I’m going to put my dual power supply to work and put 5V @ 3A straight across the relay’s contacts. In other words, let’s see what happens when we switch the full 3A across those tiny relay contacts.

At first sight, it all looks reasonably ok:

SCR46

That’s 5V across the relay while it’s open, and about 0.3V when it closes. So these contacts seem to have a resistance of about 0.1 Ω. The overshoot when the relay opens up again is probably in the power supply, as it recovers from just having been shorted out at 3A. Note that any inductance in the wiring will have this same effect. Inductance is a bit like a flywheel – it wants to keep going after such massive current (i.e. magnetic field) changes.

It’s quite impressive to see how this little relay rattles away at ≈ 10 Hz, working just fine.

But those transitions look quite different when we zoom in:

SCR47

You’re seeing a mix of arcing and contact bounce, as all mechanical switches do.

Note that the switch hasn’t quite closed yet – there is still about 1.5V between the contact points, 30 µs after switching – due to contact bounce. This drops to 0.3V after some 400 µs, at which point the contacts are really firmly closed.

Here’s a much better example, this time using a 10 Ω resistor in series so the power supply just delivers 5V @ 0.5A without going into current-limiting mode:

SCR50

Opening is again not quite what it seems, once you zoom in:

SCR48

Two things happening here: the mechanical release of the switch (less resistance as the pressure on the contact decreases, followed by some arcing), and then a fairly linear ramp and some overshoot as the power supply recovers its 5V setting after having been shorted out. Think of a stretched rubber band, and how it “overreacts” when released.

So as you can see, a relay does some nasty things while switching on and off!

Digital opto switching

In Hardware on Oct 12, 2012 at 00:01

While on the subject of optocouplers, there’s another type besides “analog” ones and “digital” ones (which include a comparator), and that’s the opto-relay. Again with several kilovolts of isolation.

The Avago ASSR-1611 is an interesting one, for example, because it uses MOSFETs:

Screen Shot 2012 10 07 at 14 11 47

Basically, it lets you switch up to 60V at a few amps. To see how it performs, while I still have that linear ramp circuit up and running, I hooked it up – as a big mess-o-wires:

DSC 4173

It’s getting pretty crowded in there. The ASSR-1611 is on the left. Here’s its schematic:

Screen Shot 2012 10 07 at 14 07 07

The interesting bit is that there are diodes in there, so it can deal with alternating current when hooked up differently, i.e. by using pins 4 and 6 instead of 5 and 6.

First thing to notice, is that this thing behaves in a strange way when switched at 1000 Hz:

SCR43

It “sort of” triggers … slowly (keep in mind that turning on translates to shorting the output to ground, as before). And then it decides to turn off again very quickly. For some reason this repeats about 10 times per second.

To slow the triangle wave rate way down, I used a 10 µF capacitor instead of 0.1 µF:

SCR44

Aha! Much better. At about 0.7 mA (purple voltage over 1 kΩ = 0.7V), this solid state relay switches on, and once the current drops back to almost 0, it switches off. Note how these readings match the specs nicely: turning on, i.e. the blue line dropping to 0, takes a few ms, whereas turning off is virtually instant.

At a few Euro each, these chips are not really cheaper than mechanical relays, but when you only need to switch a few dozen Volt at a few Amps, then this solution still has the benefit that it switches far more cleanly – with no arcing or mechanical wear. And it’s totally quiet, of course…

Optocoupler current transfer

In Hardware on Oct 11, 2012 at 00:01

The past few days were about generating a linear ramp, in the form of a triangular wave, and as you saw, it was quite easy to generate – despite the lack of a function generator.

The result was a voltage alternating between about 0.6V and 3.0V in a linear fashion. Here’s why…

I want to see how the MCT62 optocoupler passes a signal through it. More specifically, how a linearly increasing voltage would come out. Let’s look at that chip schematic again:

Mct621

So the idea is to apply that linear ramp through a current-limiting resistor into the opto’s LED. Then we put the photo-transistor in a simple 5V circuit, with again a current limiting resistor between collector and 5V – like this:

JC s Grid page 35

From left to right:

apply a triangle wave to the LED, which varies from 0.6 to 3.0V
there’s a 1 kΩ rsistor in series, so the maximum current will stay well under 3 mA
the phototransistor is hooked up as a normal DC amplifier
there’s another 1 kΩ pullup, so this too cannot draw more than 5 mA current

Prediction:

when the LED is off, the output will stay at 5V, i.e. transistor stays off
until the input rises above the 1.2V threshold of the (IR) LED, not much happens
as the voltage rises linearly, so will the current through the LED
depending on the transfer function the transistor current will rise accordingly
and as a consequence, the output voltage will drop

So if that behavior is linear, then the output voltage should drop linearly. Let’s have a look:

SCR42

the YELLOW line is the triangle wave, as generated earlier
the PURPLE line is the voltage over the leftmost resistor
the BLUE line is the voltage on the transistor’s collector output
the RED line is the derivative of the BLUE line
the zero origin for all these lines in the image is at two divisions from the bottom

First of all, the purple line indeed rises slowly once we start rising above 1.0V, and it stays roughly 1.2V under the input signal (yellow line).

The blue line is the interesting one: it takes a bit of input current (i.e. LED light) for the transistor to start conducting, but once it does, the output voltage drops indeed. Once we’re above 2.0V, the blue line becomes quite linear. As indicated by the fact that the red line is fairly flat between horizontal divisions 5 and 7.

So in this range (and probably quite a bit above), we have a linear transfer from input current to output current. Or voltage … it’s all the same with resistors.

In terms of current, we can use the purple line: it’s flat with a diode current between 0.7 and 1.7 mA (and probably beyond).

The output voltage only drops to just over 2V, so the phototransistor is still far from reaching saturation (“conducting all out”).

So what’s the point of all this, eh?

Well, one thing this illustrates is that you can get a pretty clean signal across such an optocoupler, as long as you stay in the linear range of it all. There is no real speed limitation, so even audio signals could be sent across reasonably well – without making any electrical connection, just a little light beam!

It’s not hard to imagine how this could be done with discrete components even, sending the light to a glass fiber over a longer distance.

You can call it wireless signal transmission, albeit of a different type: optical!

Pretty good triangles

In Hardware on Oct 9, 2012 at 00:01

As of yesterday, we now have a “triangular wave generator”. Whee!

Except that I don’t want a voltage between 1.25V and 3.75V but slightly lower. One way to accomplish this is to lower the reference “1/2 Vcc” voltage used by the comparator and integrator circuits. So I added a 22 kΩ resistor in parallel on one half of the voltage divider:

+5V  <=>  10 kΩ  <=|=>  (10 kΩ and 22 kΩ in parallel)  <=>  GND
                   |
                  TAP

This online calculator says that the parallel value is 6.875 kΩ. Here’s the resulting signal:

SCR38

It’s now slightly asymmetric (we’re discharging faster than we’re charging), but more importantly, the signal now runs from about 0.6V to 3.0V, which is more in sync with what I need (more on that in an upcoming post).

Notice that on these screen shots, the waveforms look very nice and straight, although it’s hard to see just how linear those ramps really are.

This is where a scope with good math functions comes in. If you recall from mathematics, the derivative of a straight line is a constant. Or to put it differently: the straighter the line is, the closer its derivative should be to a constant value. Positive for upward slopes, and negative for downward slopes. Let’s zoom in a bit:

SCR37

(the red line’s origin is centered vertically, the yellow line is at 1 division from the bottom)

That red line is the scope’s calculated derivative of the yellow line (it’s really just a matter of calculating differences between successive points). As you can see, the upward slope is pretty straight from 1.3V to 2.9V. The downward slope less so, IOW the capacitor discharge is not quite as linear. The signal was averaged over 128 samples in this last screen.

Excellent. I now have the signal I need to perform my experiment. Stay tuned.

Triangular wave generator

In Hardware on Oct 8, 2012 at 00:01

Let’s build an oscillator, now that we can generate linear ramps. But to get there, we’ll need a second op-amp circuit (1/2 Vcc is the middle of two 10 kΩ R’s between Vcc and GND):

JC s Grid page 34

This is a comparator with hysteresis, or Schmitt trigger. Same rules as yesterday, of course.

In contrast to yesterday’s setup, there is no negative feedback here, but a resistor between “OUT” and “+”. So in this case, when the output rises, it’ll cause “+” to rise even more, instead of bringing it closer to the “-” input.

This circuit doesn’t work towards an equilibrium, it’s unstable. Let’s start with the output being VCC, i.e. +5V. What will the input need to be to make it change?

the desired change can only happen, when the “+” input drops below 2.5V
with OUT at +5, that’s 2.5V over 20 kΩ, i.e. 125 µA
to pull “+” under 2.5V, we need to draw at least 125 µA out through the 10 kΩ resistor
that’s 1.25V under 2.5V, i.e. with the IN level under 1.25V

So when IN drops under 1.25V, the op-amp has a change of heart so to speak, and starts bringing OUT down in an attempt to bring “+ and “-” back to the same level. The silly thing is that it can’t, because lowering OUT is never going to raise the “+” back up to 2.5V (still with me?). So the output just keeps keeps dropping all the way to its minimum, which will be more or less equal to 0V.

Let’s review what happened: we started dropping the input level, and once it reached 1.25V, the output violently flipped from +5V to 0V.

Now the situation is reversed: how far do we need to raise the input to make the output go up again? Well, that’ll be 3.75V – using the same reasoning as before, but now based on 2.5V (the “-” pin) + 1.25V (the voltage over the 10 kΩ resistor.

So what this circuit does is flip between 0 and 5V, at trigger points 1.25V and 3.75V.

Now the magic part: we tie the input of this circuit to the output of yesterday’s circuit, and vice versa, creating a control loop. If you look back at yesterday’s scope image, you’ll see that the triangular wave flips at… 1.23V and 3.72V. What a coincidence, eh? Nah… it’s all by design. The comparator drives the integrator by feeding it 0 and 5V levels, and it switches when the integrator output reaches 1.25V and 3.75V. Since the capacitor requires a little time to charge, this ends up being a nicely controlled oscillator. Perfect!

Here’s my test circuit (for a complete schematic, check this website, for example):

DSC 4170

Tomorrow, I’ll change the signal slightly and I’ll examine how linear those ramps are.

Triangular waves

In Hardware on Oct 7, 2012 at 00:01

For an upcoming experiment, I’m going to need a slowly rising voltage, and with my signal generator currently out for a check-up, it’s time to dive into some electronic circuitry again. Let’s try to generate a sawtooth or triangular wave signal with a few basic components. After my search for a simple sine wave generator, I’m happy to report that generating “ramp voltages” is actually a lot simpler.

The reason for this is that all you need to generate a linear ramp, is a constant current into a capacitor. This automatically produces a linear voltage ramp. The electrical notation for such a circuit is:

JC s Grid page 34 copy

The voltage over that capacitor will rise linearly over time. It looks so simple! (well, apart from figuring out how to build a constant current source, perhaps)

But that’s only half the story. What to do once the capacitor has been fully charged up? We need to discharge it again, clearly. One way to do this, is to put a transistor or MOSFET across the cap and periodically make it turn on (briefly!) to discharge the circuit again. Ok, so now we need a periodic pulse as well. Hmmm…

There is another solution: op-amps. The op-amp is a truly amazing little building block. What we need here, is to use two op-amps in different configurations: one as an integrator and one as a comparator.

Let’s start with the integrator, because that explains how we can get a linearly varying voltage out of the circuit:

JC s Grid page 34

An op-amp has two properties, both crucial for explaining this little 3-component circuit:

both inputs are very high resistance, so virtually no current flows in or out
the output is constantly adjusted to try and keep both inputs at the same voltage

That second property can also be described as: when “+” is higher than “-“, the output will go up (towards Vcc, the supply voltage), when it’s lower, the output will go towards 0 (the ground voltage in a single-supply setup).

Here we’re tying “+” to half Vcc, in this case 2.5V, so you can think of the op-amp as trying to do whatever it can to keep the “-” pin at 2.5V as well.

Let’s start with everything in perfect balance, then “+”, “-“, and “OUT” will all be at +2.5V, and the capacitor will have no charge. Now let’s take the input to +5V:

a constant current starts flowing into the resistor, since the other side is +2.5V
this current drives the “-” pin up, so the output will go down
how far down? well as much as needed to cancel out that incoming current
IOW, the same current is going to go into the capacitor, which starts to charge up
as the charge builds up, less current starts to flow into the capacitor
“no way” says the op-amp, and so it pulls its output lower
so a constant current flows into the cap, and the output drops lower and lower
at some point near 0V the op-amp reaches its limit, and the mechanism breaks down

To give a water analogy: think of pouring water into a glass at a constant rate while trying to keep the surface of the water the same. You have to gradually lower the whole glass to make this work. As you do, the glass (cap) will contain more and more water (voltage). You’ve integrated (collected) the water flow into the glass!

If we keep the input voltage high, nothing more will happen: the cap will end up being fully charged, and the op-amp can no longer do anything to keep the “-” input from rising all the way to the input voltage.

When we now drop the input voltage to 0V, the reverse happens. Current flows through the resistor in the other direction, and the cap starts discharging. Again, the op-amp will do whatever it can to maintain that “-” at 1/2 Vcc. It does this by raising its output pin causing the capacitor to discharge with that same constant current rate. And sure enough, the voltage over the capacitor drops linearly. Until we hit the limits, and the process stops.

Here’s the effect in action, as seen on an oscilloscope (R = 4.7 kΩ, C = 0.1 µF, and the op-amp is an OPA2340):

SCR35

The blue line is the input signal, the yellow line is the triangular wave output. Neat, eh?

Tomorrow, I’ll add an op-amp as comparator to make this circuit oscillate all by itself.

Murphy goes opto

In Hardware on Oct 6, 2012 at 00:01

It looks like Mr. Murphy has found some time to mess with things again…

The Optocoupler Plug is a little board to let you isolate two I/O pins. When you drive one end with a small voltage to light up a little LED inside, it shines that light onto a sensitive photo-transistor which then starts conducting. It’s effectively a tiny switch, driven by light.

The nice thing about light is that it lets you avoid an electrical connection. So this thing allows you to detect a (small) input voltage without actually making a connection to it. These units support over a thousand volt of isolation – perfect when messing with AC mains coupled circuits, for example.

But the Optocoupler plug is actually two plugs in one, because you can also use it as an output by using it in reverse: then, the two I/O pins on a port can be used as output to turn on the LEDs, and the phototransistors can then control some output circuit without having to actually connect to it.

Here’s the “dual-mode” configuration of the Opto-coupler Plug:

Jumpers

In one mode, it can be used as input (with current limiting resistors on the right), in the other it’s an output (current-limiting resistors on the left, and solder jumpers on the right).

The unit I picked for this board is an MCT62:

Mct62

Then we recently switched over to a HCPL-2631, without thinking much about it:

Opto 2631

Whoops! Different pinout, but also entirely different beast: the MCT62 contains a pair of independent simple “analog” type optocouplers. The HPCL-2631 on the other hand is a “digital” model with some built-in amplification. Which means that this thing needs a power supply, and to stay within the 8-DIP pinout, this can only be realised by tying a common “ground” together and re-using the other as supply voltage.

There’s a lot more to describe about this apparently simple device, but for now all I can say is “we messed up!”. Fortunately, only four people have been affected by this so far, and we’ve contacted each one of them to resolve the problem and send a replacement out. To each of you, my apologies for the confusion and for wasting your time if you’ve been trying to get those faulty Optocoupler Plug kits to work.

With thanks to Jupe Software for reporting the issue, and saving others more grief!

Pssst … this is post # 1111 !

ARMs on Foam

In Hardware, Linux, ARM on Sep 29, 2012 at 00:01

One of the things I’d really like to do is hack on that Laser Cutter I described recently.

The electronics is based on a LaOS Board, but I’d like to see what you can do with an embedded Linux board such as a Raspberry Pi in this context – driving that LaOS board, for example. Because adding Linux to the mix opens up all sorts of neatness.

So here’s my new prototype development setup:

DSC 4163

That oh-so-neat foam board acts as base, with two PCB’s fastened to it using, heh … remember these?

DSC 4164

They’re called “splitpennen” in Dutch. Long live foam board and splitpennen!

This is a pretty nifty setup, in my opinion. Tons and tons of ways to implement features on this combo, and there’s plenty of power and storage on both boards to perform some pretty neat tricks, I expect.

Anyway – this is more a big project for cold winter days, really. It’ll take a long time before anything can come out of this, but isn’t it incredible how the prices of these things have reached a point where one can now dedicate such hardware to a project?

ARM to ARM upload

In Hardware, Software, ARM on Sep 27, 2012 at 00:01

After yesterday’s basic connection of an LPCXpresso 1769 board to the Raspberry Pi, it’s time to get all the software bits in place.

With NXP ARM chips such as the LPC1769, you need a tool like lpc21isp to upload over a serial connection (just like avrdude for AVR chips). It handles all the protocol details to load .bin (or .hex) files into flash memory.

There’s a small glitch in that the build for this utility gets confused when compiled on an ARM chip (including the Raspberry Pi), because it then thinks it should be built in some sort of special embedded mode. Luckily, Peter Brier figured this out recently, and published a fixed version on GitHub (long live open source collaboration!).

So now it’s just a matter of a few commands on the RPi to create a suitable uploader:

    git clone https://github.com/pbrier/lpc21isp.git
    cd lpc21isp
    make
    cp -a lpc21isp ~/bin/

Next step is to get that board into serial boot mode. As it turns out, we’re going to have to do similar tricks as with the JeeNode a few days ago. And sure enough, I’m running into the same timing problems as reported here.

But in this case, the boot load process is willing to wait a bit longer, so now it can all easily be solved with a little shell script I’ve called “upload2lpc”:

# export the two GPIO pins to the shell
echo "18" >/sys/class/gpio/export >&/dev/null
echo "23" >/sys/class/gpio/export >&/dev/null

# use them as output pins
echo "out" >/sys/class/gpio/gpio18/direction
echo "out" >/sys/class/gpio/gpio23/direction

# pull ISP low and prepare for reset
echo "0" >/sys/class/gpio/gpio23/value
echo "1" >/sys/class/gpio/gpio18/value

(
  # it is essential to delay the reset pulse for lpc21isp
  sleep 0.3
  # pulse reset low
  echo "0" >/sys/class/gpio/gpio18/value
  sleep 0.1
  echo "1" >/sys/class/gpio/gpio18/value
  # set ISP line high again
  echo "1" >/sys/class/gpio/gpio23/value
) &

echo "Uploading... "
lpc21isp -debug0 -bin $1 /dev/ttyAMA0 115200 12000 \
  && echo "Done." || exit 1

The result? We can now reset the LPCXpresso from the Raspberry Pi and upload some blink code to it:

    $ sudo ./upload2lpc blink.bin
    Uploading...
    Done.

Yippie: it resets, it uploads, it blinks – and it does so consistently! Onwards! :)

Update – For best results, also add a “sleep 0.1” between those two last echo 1’s.

ARM to ARM serial connection

In Hardware, Linux, ARM on Sep 26, 2012 at 00:01

After connecting a JeeNode to a Raspberry Pi, let’s do the same with the LPCXpresso I mentioned a while back. Let’s do it in such a way that we can upload new code into it.

With an LPC1769, this is even simpler than with an ATmega328, because the serial boot loader is built-into the chip out of the box. No need to install anything. So you can always force the chip back into serial boot loader mode – it can’t be “bricked” !

But the process is slightly different: you have to pull down a specific “ISP” pin while resetting the chip, to make it enter serial boot loader mode. So we’ll need one more GPIO pin, for which I’ll use the RPi’s GPIO 23. The wiring is even cleaner than before, because this time I planned a bit more ahead of time:

DSC 4156

Except that this runs into the same problem as before. The LPCXpresso does not have the essential 3.3V regulator next to the ARM chip, it’s on the part that has been cut off (doh!). So again, I’m going to have to add an SMD MCP1703 regulator:

DSC 4157

(that little critter is between pins 1 and 2, and upside down, to get the pinout right)

Here’s the complete hookup:

DSC 4159

First step is again to make sure that Linux isn’t doing anything with the serial port:

remove the two args referring to /dev/ttyAMA0 in the file /boot/cmdline.txt
add a hash (“#”) in front of this line in /etc/inittab to comment it out:
```
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
```
make the system aware of the changes in inittab with: kill -1 1 (or reboot)

Tomorrow, I’ll go into actually uploading to that LPC1769 ARM board. Stay tuned!

Note – As of October 1st, VAT prices in the Netherlands will increase from 19% to 21%. As a consequence some adjustments will also have to be made in the JeeLabs Shop. Up or down depends on many obscure factors, including exchange rates, current costs, stock levels, and the wish to stick to decently rounded values – so if you want to avoid any surprises and were planning to order stuff, please keep that switch-over date in mind.

Linux real-time hickups

In Hardware, Software on Sep 24, 2012 at 00:01

To give you an idea why a simple little Linux board (the Carambola on OpenWrt in this case) is not a convenient platform for real-time use, let me show you some snapshots.

I’ve been trying to toggle two I/O pins in a burst to get some data out. The current experiment uses a little C program which does ioctl(fd, GPIO_SET, ...) and ioctl(fd, GPIO_CLEAR, ...) calls to toggle the I/O pins. After the usual mixups, stupid mistakes, messed up wires, etc, I get to see this:

SCR18

A clean burst on two I/O pins, right? Not so fast… here’s what happens some of the time:

SCR19

For 10 ms, during that activity, Linux decides that it wants to do something else and suspends the task! (and the system is idling 85% of the time)

If you compare the hex string at the bottom of these two screenshots, you can see that the toggling is working out just fine: both are sending out 96 bytes of data, and the first few bytes are identical.

The situation can be improved by running the time-critical processes with a higher priority (nice --20 cmd...), but there can still be occasional glitches.

Without kernel support, Linux cannot do real-time control of a couple of I/O pins!

▶ View 21 Comments

Upload to JeeNode fixed

In Hardware, Linux on Sep 23, 2012 at 00:01

Ok, I finally figured out what caused yesterday’s upload problem. It’s indeed timing.

But not quite as I thought, and I missed a hint in the scope signal capture yesterday (at 322 ms after the reset). My premature conclusion was that resetting the GPIO pin and then starting up avrdude was taking too long, so the boot loader would give up before receiving the proper starting character over the serial line.

But that doesn’t quite make sense. Looking at the screen shot again, we can see that the RF12demo greeting (blue line) starts about 800 ms after the RESET pin gets pulled low. Even though OptiBoot is supposed to wait a full second after power-up. And there are two handshake attempts well within that period.

The other subtle hint was in the not-quite-equidistant characters being sent out (yellow line). Why would handshake chars be sent out in such a repeatable yet irregular pattern?

Having written an avrdude replacement in Tcl for some experiments I did with JeeMon a while back, I decided to try and extend it a bit to toggle the reset pin right before sending out the data. That way no delay would interfere, so the reset would happen moments (probably mere milliseconds) before starting the boot loader serial handshake. I didn’t really want to start hacking on avrdude for such a “simple” task as toggling a GPIO pin on the Raspberry Pi. Besides, that replacement code is only 70 lines of Tcl, if all you have to deal with is the basic stk500 protocol understood by the boot loader.

Controlling the GPIO pin also turned out to be pretty straightforward:

Screen Shot 2012 09 20 at 23 59 50

But no matter what I tried, and no matter what timing delays I inserted, the darn thing just wouldn’t upload!

Then, just for the heck of it, I tried this variation – reversing the open and reset order:

Screen Shot 2012 09 21 at 00 01 18

And lo and behold – now it works: repeatedly and reliably!

Here’s the scope’s serial protocol analyser, showing a proper upload in progress:

SCR32

You can see data being sent to the JeeNode, and the 0x14h reply sent back to the RPi.

So was this all about timing? Yes and no. Let’s revisit yesterday’s list of pulses again:

Screen Shot 2012 09 21 at 00 06 02

A single pulse 322 ms after reset, and then several pulses at 673 ms (presumably the first boot loader protocol handshake character). The problem is really that first pulse – it’s not a valid character but a glitch!

What I think is happening is that the JeeNode resets, the glitch at 322 ms causes the boot loader to give up and launch the sketch, and then all subsequent boot handshake characters get ignored. Looks like opening the serial port produces a glitch on the transmit output pin.

By first opening the serial port and then doing the GPIO18 reset, the problem is avoided, and then it all works.

Thank you JeeMon – I hadn’t expected to fire you up again, but you’ve saved my day!

Timing troubles with upload

In AVR, Hardware on Sep 22, 2012 at 00:01

Since the Raspberry Pi can now reset a JeeNode, I assumed that uploading would be a piece of cake. Hmmm… maybe not quite.

The trouble is timing, and ~~I’m currently~~ I was pulling my hair out on this one:

the plan is to reset the JeeNode and then have avrdude upload new code to it
this works automagically when opening a serial port causes DTR to go low
but here, we don’t have DTR or RTS, this is a basic serial port on GPIO pins
what we do have, is a GPIO pin 18 which can be pulled low to force a reset

At the moment, there seems to be a major problem with timing:

SCR31

Here’s how to decode this screen shot:

the YELLOW line is serial from RPi to JeeNode
the BLUE line is serial from JeeNode to RPi
the MAGENTA line is the reset pulse on the GPIO pin

The way I test this, is via a shell script which first toggles reset using /sys/class/gpio/…, and then launches avrdude to perform the upload, using these commands:

echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value
sleep 0.1
echo 0 >/sys/class/gpio/gpio18/value
avrdude -pm328p -carduino -P/dev/ttyAMA0 -D -Uflash:w:test.hex:i
echo 18 >/sys/class/gpio/unexport

Here’s what actually happens, I think:

the GPIO pin is correctly pulsed high and then dropped low after 0.1 s
the scope triggers on that falling edge, presumably same time as the ATmega resetting
after 323 ms, I see a 30 µs blip on the outgoing serial pin
after 674 ms, it looks like avrdude sends out it’s “0” wakeup character
after about 750 ms, the JeeNode starts sending the RFM12demo greeting
after 946 ms, the second “0” wakeup goes out
after 1197 ms, the third and final “0” goes out

In other words: it looks like avrdude is starting to send the 0’s too late! – and as a result, the JeeNode’s boot loader passes control to the sketch and never enters the upload cycle. After a few seconds, avrdude then gives up:

avrdude: ser_recv(): programmer is not responding

Note that reset and serial communication both work properly, as verified several times.

Trouble is, apart from redoing all in a single app, I see no way to reduce the startup time of avrdude. The SD card is perhaps not the fastest, but it’s no slouch either:

# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   248 MB in  2.00 seconds = 123.77 MB/sec
 Timing buffered disk reads:  50 MB in  3.05 seconds =  16.40 MB/sec
#

Is a reset + upload via GPIO not possible? I’m not giving up, but it sure ain’t workin’ yet!

Update – Problem solved, stay tuned for the explanation tomorrow…

Resetting a JeeNode from a RPi

In Hardware, Software on Sep 21, 2012 at 00:01

Now that the JeeNode talks to the Raspberry Pi, it’d be interesting to be able to reset the JeeNode as well, because then we could upload new sketches to it.

It’s not hard. As it so happens, the next pin on the RPi connector we’re using is pin 12, called “GPIO 18”. Let’s use that as a reset pin – and because this setup is going to become a bit more permanent here, I’ve made a little converter board:

DSC 4149

This way, a standard JeeLabs Extension Cable can be used. All we need is a board with two 6-pin female headers, connected almost 1-to-1, except for GND and +5V, which need to be crossed over (the other wire runs on the back of the PCB to avoid shorts).

This takes care of the hardware side of resets. Now the software. This is an example of just how much things are exposed in Linux (once you know where to find all the info).

There’s a direct interface into the kernel drivers called /sys, and this is also where all the GPIO pins can be exposed for direct access via shell commands or programs you write. Let’s have a look at what’s available by default:

$ sudo ls /sys/class/gpio/
export  gpiochip0  unexport
$

The “export” entry lets us expose individual GPIO pins, so the first thing is to make pin 18 available in the /sys area:

sudo echo 18 >/sys/class/gpio/export

That will create a virtual directory called /sys/class/gpio/gpio18/, which has these entries:

$ sudo ls /sys/class/gpio/gpio18/
active_low  direction  edge  power  subsystem  uevent  value
$

All we’ll need is the direction and value of that pin. Let’s first make in an output pin:

sudo echo out >/sys/class/gpio/gpio18/direction

Now, we’re ready to reset the JeeNode. I found out that the pin needs a negative transition (from 1 to 0) to do this, so the following three commands will do the trick:

sudo echo 1 >/sys/class/gpio/gpio18/value
sudo echo 0 >/sys/class/gpio/gpio18/value
sudo echo 1 >/sys/class/gpio/gpio18/value

And sure enough, the JeeNode resets, and the terminal I have running in another window shows the RF12demo startup message again:

Screen Shot 2012 09 18 at 14 32 09

We’re in control – shell over sketch!

Serial hookup JeeNode to Raspberry Pi

In Hardware on Sep 20, 2012 at 00:01

One way to connect an RFM12B to a Raspberry Pi is to simply plug in a JeeLink, using the built-in USB capabilities of the RPi. But that’s a bit of a detour – why go through USB?

Since the JeeNode’s FTDI connector can use 5V power and has TX/RX pins at 3.3V logic level, it’s actually a perfect match for directly connecting to a Raspberry Pi. Let’s do it.

I’ll be using the command shell on the RPi, using a network SSH connection, but this could also be done from the console with a keyboard, of course.

There are a couple of hurdles we’ll need to overcome. First one is to figure out which pins to use on the RPi’s 26-pin I/O connector. I found a good schematic on elinux.org:

Screen Shot 2012 09 16 at 17 26 45

We’re going to use 4 pins: 5V, Ground, TXD, and RXD. But first, let’s figure out how to reach those pins in Linux. I found out that the serial port we need is “ttyAMA0”:

$ ls -l /dev/ttyAMA0 crw-rw—- 1 root tty 204, 64 Sep 16 17:13 /dev/ttyAMA0 $

That port is only accessible by users in access group “tty” (and root). So first, let’s make sure user “pi” can access it, by adding ourselves to that group:

sudo usermod -a -G tty pi

Now logout and log back in to make these changes take effect.

> Note: not all RPi Linux distro’s are set up in the same way. If ttyAMA0’s group is “dialout” instead of “tty”, chances are that you’re already a member (type “id” to find out). In that case, skip the above usermod command.

But that’s not all. By default, there’s a “getty” process running on this serial port:

$ ps ax | grep getty 2126 tty1 Ss+ 0:00 /sbin/getty –noclear 38400 tty1 2127 tty2 Ss+ 0:00 /sbin/getty 38400 tty2 2128 tty3 Ss+ 0:00 /sbin/getty 38400 tty3 2129 tty4 Ss+ 0:00 /sbin/getty 38400 tty4 2130 tty5 Ss+ 0:00 /sbin/getty 38400 tty5 2131 tty6 Ss+ 0:00 /sbin/getty 38400 tty6 2132 ? Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100 2292 pts/0 S+ 0:00 grep getty $

This lets you connect to the serial port and login. Very convenient, but in this case we don’t want to log in, we want to take over control of this serial port for talking to the JeeNode. So we have to disable getty on ttyAMA0:

edit the file /etc/inittab as root (I used “sudo vi /etc/inittab”)
change this line: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 to #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. I.e. comment it out, and save these changes.
run the command “sudo kill -1 1” to pick up these inittab changes

And that’s it. There is no longer a process trying to respond to our serial port.

> Note: again, this may not be needed if you don’t see “ttyAMA0” listed in the ps output.

You also have to make sure that the kernel doesn’t log its console output to this serial port. Look in the file “/boot/cmdline.txt” and remove the text console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 if present. Then reboot.

Now we’re ready for a quick loopback test:

DSC 4143

Connect a single jumper as indicated (a little jumper block would also work), connecting RXD with TXD. This means that everything sent out serially will be sent back and received serially as well. A very convenient test that we’ve got all the Linux stuff set up properly.

Oh, wait – first let’s get the utility installed which lets us type to the serial port:

sudo apt-get install screen

Now we can test the serial port, at last:

$ screen /dev/ttyAMA0 57600 …

You should see a blank screen, and whatever you type in should show up on the screen. If this is indeed the case, then there is data going out and back into the serial port. To really make sure, disconnect the jumper and the echoing will stop. Excellent. Almost there.

Screen is a very convenient utility, but you need to remember how to get back out of it. The key sequence is CTRL+A followed by “\” (the backslash key).

For now, you can leave it running, or start it up again later. The last step is to hook up the JeeNode. This requires 4 wires:

DSC 4144

Note carefully the order of these female-to-female jumper wires, top to bottom:

on the RPi: green, white, black, gap, blue
on the JeeNode: gap, green, white, blue, gap, black

I used a JeeNode, pre-loaded with the standard RFM12B sketch, and set to receive packets from my main home monitoring setup here at JeeLabs. I also enabled “collect mode (“1c”) so that it wouldn’t try to acknowledge packets, just lurking and reporting what comes in. And sure enough, it works:

Screen Shot 2012 09 16 at 17 17 17

Easy! (once you know how to overcome all the software and hardware hurdles, that is…)

Update – additional contributed notes.

▶ View 15 Comments

Laser cutter electronics

In Hardware, Software on Sep 19, 2012 at 00:01

The last part of this mini series about a low-cost semi-DIY laser cutter describes the electronics and firmware:

DSC 3506

In the middle is an MBED microcontroller based on an ARM Cortex M3 chip (NXP’s LPC1768). It runs at 96 MHz, has 512 KB flash, 32 KB RAM, USB, and an Ethernet controller on board (but not the magjack).

The whole thing sits on the custom LaOS board, which includes an SD card socket, an I2C bus, some opto-isolators, power-supply interface (+5V and +24V), and two Pololu stepper drivers (or nearly compatible StepSticks).

There’s room for 1 or 2 more stepper drivers, a CAN bus interface, and more connectors for extra opto-isolated inputs and outputs. The on-board steppers can be omitted with the step/direction pins brought out if you need to drive more powerful motors.

The MBED was briefly mentioned in a previous post, and can also be replaced by a suitably modded LPCXpresso 1769 board, at less than half the price.

The software is open source and has just been moved from the MBED site to GitHub. Note that at this point in time, the software is still based on the “mbed.ar” runtime support library, which is unforunately not open source. Work is in progress to move to a fully open source “stack”, but that’s not the case today – the Ethernet library in particular hasn’t been successfully detached from its MBED context yet.

Ethernet connectivity is based on the lwIP code, which in turn is the big brother of uIP. Big in the sense that this supports a far more capable set of TCP/IP features than would be possible with an 8-bit microcontroller and its limited memory. Having 512 KB flash and 32 KB RAM in this context, means that you don’t have to fight the constraints of the platform and can simply focus on getting all the functionality you want in there.

Right now, the LaOS firmware drives the steppers, using a Gcode interpreter adapted from gbrl, and includes support for Ethernet (TFTP, I believe) and the SD card. It also requires the I2C control panel. As a result, you can send a “job” to this thing via VisiCut, and it’ll save it on the SD card. The I2C-based control panel then lets you pick a job and start it. Quite a good workflow already, although there are still a fair number of rough edges.

(Note that if you listen very carefully, you can hear all the pioneers on this project scream for more volunteers and more help, on all sorts of levels and domains of expertise :)

What excites me about all this, apart from those über-cool laser cutting capabilities of course, is the potential to take this further since all the essential bits are now open source – and it’s not even really tied to a specific brand of laser.

So there you have it. It cuts, it burns, it smells, it’s yearning to be taken to the next level :)

What’s in a laser cutter

In Hardware on Sep 18, 2012 at 00:01

Let me describe this thing I ended up with:

mechanics: the main part is a solid bright red metal box with a few compartments:
1. left = X-Y table
2. right = electronics
3. back = laser tube
electronics: the LaOS main board and an ATmega168 as I2C-connected control panel
water reservoir + circulation pump, for cooling, must be on when the laser is on
air pump (noisy aquarium type) – for “air assist”, keeps the fumes away from the lens
exhaust ventilator, mounted on the back, pushes the smelly & smoky air out

The pumps and ventilator are manually turned on from the front panel with separate switches. Not perfect, since this leaves room or operator error, but hey – it works.

Here’s a peek inside, with some packaging plastic still in place:

DSC 3512

The shiny plate height can be adjusted using 4 connected screws turning in tandem.

You can see a little fluorescent light in the top center, and the air exhaust underneath it.

A 35 Watt infrared laser is serious stuff (it actually requires a few hundred Watt to generate that sort of power). Once focused, that beam can do major harm – cutting through stuff is what it’s supposed to do, after all.

Safety comes in the form of a reed relay which triggers when the lid of this thing is lifted (top right above), another one when the lid of the laser on the back is open, and a mains power switch with a key. The lid for the electronics is locked (from the X-Y compartment). The transparent viewing area is of a special type which blocks laser light, and the whole thing is made of fairly solid steel.

The beam is invisible (scary, eh?), but a tiny red “pointer” laser is mounted inside, showing roughly where the beam will hit. Extremely useful while doing dry runs – which in turn is very easy to do: just start the laser with the lid open, and you can see where it’s going to cut. Given that the cutting area is only about 20×30 cm, that’s not a luxury – you really have to check whether the material is properly placed. Here’s that last mirror, deflecting the beam down into the final focusing lens:

DSC 3489

(Note: that’s not smoke, but the red panel’s reflection on the aluminium work surface)

The hollow tube is the “air assist”, blowing air to push the smoke away from the beam.

All the mirrors come pre-aligned and secured with a bit of hot glue. No need to tweak.

On the side is that little pointer laser. Since it’s tilted, the position of the spot is not exactly where the laser will hit, depending on how far into the material you place the focus spot. Focusing is actually quite simple: the laser comes with a little (lasered) acrylic piece, the side of which has a specific length. To focus, you place that on the work piece, and then lower or raise the object until the plastic spacer aligns with this metal mirror mount.

Raising / lowering the work piece is done manually. The whole thing sits on a (fixed size) “honeycomb” bed, which in turns sits on a manually adjustable metal “table”. Adjustment is done with a screw sticking through the bottom of the laser – and in fact the very first thing you need to cut is a piece of wood to act as large adjustment ring, which can then be grabbed from the front of the laser. Bit hard to explain, but then again this isn’t meant as assembly instruction – I just want to give you an impression of what sort of issues you have to deal with in such a setup. On the plus side: pioneering is fun! – with lots of opportunities to come up with clever improvements :)

Tomorrow, I’ll describe the electronics. This board (and the software developed for it) replaces the original board, which I’m told was hard to use, came with crude Windows-specific software, and was impossible to hack on and improve. The LaOS board has a microntroller, two stepper motor drivers, an Ethernet port, and various other bits and bobs needed to deal with everything in the HPC laser. It’s actually quite general-purpose.

Hello, Laser Cutter!

In Hardware, News on Sep 17, 2012 at 00:01

Yep, it has finally happened… it all started in July, when I got this (without the electronics board) and this (called the LaOS board).

The laser arrived like this:

This summer, a couple of early adopters in the Netherlands got together to figure out all the pesky little details that come up when you’re really just in pioneering mode. Make no mistake: this thing is far from ready for mainstream use. The laser itself is quite nice and ready to go, and definitely workable as far as all the mechanics go. But the electronics and software are still work-in-progress (I’m using the VisiCut software – which includes a driver that talks directly to the laser’s firmware over Ethernet).

Nevertheless – early as it may be, the total cost is less than €1,500 and you end up with an A4-sized laserable workspace which can cut up to 5 mm wood panels and 6 mm acrylic (engraving is more involved, but getting there). One of the first things we tried was this:

Sure enough, the circle is a snug fit and turns perfectly. Excellent alignment!

I’ll describe a few more details of this setup in the coming weblog posts, but also want to point out that you too can end up with such a laser cutter (just make sure to arrange for ventilation – you’ll quickly get very tired of the burning smell and fumes).

There’s a project by the designers of the replacement electronics, called LaOS (Laser Open Source) – and it’s definitely the best place to go right now if you want to find out what’s going on. Warning: the site is currently undergoing a messy transition to a new wiki – I’ve helped out a bit and am sure they’d love to see more people join in the effort of making this thing more practical for the non-hacker crowd.

One little gotcha: these 35 W laser cutters are produced in China and then tested/resold by a company in the UK, and they are really large and heavy. Having one shipped from the UK to you is fairly expensive, because of the delicate glass laser tube (several hundred Euro, most likely). We got around that by getting organised and doing a “group buy”, with one person actually volunteering to go to the UK, load his car up with a bunch of laser cutters, and driving back (!). Still pricey, but less so, and I think the UK vendor is in fact willing to make arrangements when enough units are being purchased and shipped at the same time. Anyway – it’s an aspect to keep in mind.

But oy, oy, oy, this personal fabbing is fun :)

One million packets

In AVR, Hardware, Software on Sep 15, 2012 at 00:01

Minutes after this weblog post goes live will be a new milestone for one of the JeeNodes.

This thing has been running for over two years, sending out nearly one million test packets:

Here are the entries from the data logged to file on my central server, minutes ago:

1:40   RF12-868.5.3 radioBlip age       740
1:40   RF12-868.5.3 radioBlip ping      999970

The counter is about to reach 1,000,000 – just after midnight today, in fact.

These log entries come from a JeeNode with a radioBlip sketch which just sends out a counter, roughly every 64 seconds, and goes into maximum low-power mode in between each transmission. That’s the whole trick to achieving very long battery lifetimes: do what ya’ gotta do as quickly as possible, then go go bck to ultra-low power as deeply as possible.

The battery is a 1300 mAh LiPo battery, made for some Fujitsu camera. I picked it because of the nice match with the JeeNode footprint.

Bit the big news is that this battery has not been recharged since August 21st, 2010!

Which goes to show that:

lithium batteries can hold a lot of charge, for a long time
JeeNodes can survive a long time, when programmed in the right way
sending out a quick packet does not really take much energy – on average!
all of this can easily be replicated, the design and the code are fully open source

And it also clearly shows that this sort of lifetime testing is really not very practical – you have to wait over two years before being sure that the design is as ultra-low power as it wast intended to be!

If we (somewhat arbitrarily) assume that the battery is nearly empty now, then running for 740 days (i.e. 17,760 hours) means that the average current draw is about 73 µA, including the battery’s self-discharge. Which – come to think of it – isn’t even that low. I suspect that with today’s knowledge, I could probably set up a node which runs at least 5 years on this kind of battery. Oh well, there’s not much point trying to actually prove it in real time…

One of the omissions in the original radioBlip code was that only a counter is being sent out, but no indication at all of the remaining battery charge. So right now I have no idea how much longer this setup will last.

As you may recall, I implemented a more elaborate radioBlip2 sketch a while ago. It reports two additional values: the voltage just before and after sending out a packet over wireless. This gives an indication of the remaining charge and also gives some idea how much effect all those brief transmission power blips have on the battery voltage. This matters, because in the end a node is very likely to die during a packet transmission, while the radio module drains the battery to such a point that the circuit ceases to work properly.

Next time, as a more practical way of testing, I’ll probably increase the packet rate to once every second – reducing the test period by a factor of 60 over real-world use.

Waiting a couple of years for the outcome is a bit silly, after all…

Another embedded ecosystem

In Hardware on Sep 14, 2012 at 00:01

(This post follows up on Reinhard’s clearvoyant comment yesterday..)

The ARM microcontrollers described in the past few days are a big step up from a “simple” ATmega328, but that’s only if you consider hundreds of kilobytes of flash storage and tens of kilobytes of RAM as being “a lot”.

Compared to notebooks and workstations, it’s still virtually nothing, of course.

But there’s another trend going on, with bang-for-the-buck going off the charts nowadays: small embedded Linux systems with integrated wired and/or wireless Ethernet. These are often based on Broadcom and Atheros chipsets – the same as found in just about every network router and gateway nowadays.

One particularly nice and low-cost example of this is the Carambola by 8devices:

Main image 3 40

It has 8 MB flash + 32 MB RAM (megabytes!), on-board WiFi, and runs OpenWrt Linux.

There are I2C and SPI interfaces, which can also be used as general-purpose I/O pins, so this thing will interface to a range of things right out of the box.

One gotcha is that the 2×20 pins are on a 2mm grid, not 0.1″. Small size has its trade-offs!

The board will draw up to 1.5 W @ 3.3V (i.e. roughly 500 mA), but that can easily be reduced to about 0.4 W for a blank board with no wired Ethernet attached.

Here are some more specs, obtained from within Linux on the Carambola itself:

Screen Shot 2012 09 13 at 21 02 59

As you can see, this unit (like many routers) is based on a MIPS architecture. And it’s actually quite a bit faster that the Bifferboard I described a while back.

Like most low-end ARM chips, these systems often lack hardware floating point (its all implemented in software, just like an Arduino does for the ATmega’s). Don’t expect any number-crunching performance from these little boards, but again it’s good to point out that boards like these are priced about the same as an Arduino Uno.

One of the benefits of Linux is that it’s a full-fledged operating system, with numerous tools and utilities (though you often still need to cross-compile) and with solid full-featured networking built in. The amount of open source software available for Linux (on a wide range of hardware) is absolutely staggering.

Among the drawbacks of Linux in the context of Physical Computing, is that it’s not strictly real time, so programming for it follows a different approach (busy loops for timing are not done, for example). Don’t expect to accurately pulse an I/O pin at a few hundred Hz or more, for example. Linux was also definitely not made for ultra-low power use, such as in remote wireless nodes which you’d like to keep up and running for months or years on a single battery – there’s simply too much going on in a complete operating system.

The other thing about Linux is that it can be somewhat intimidating if you’ve never used it before. Part of this comes from its strong heritage from the “Unix world”. But given the current trends, I strongly recommend trying it out and getting familiar with it – Linux is very mature: it has been around for a while and will remain so for a long time to come. With boards such as the Carambola illustrating just how cheap it can be to have a go at it.

Interesting times. Now if only new software developments would keep up with all this!

The ARM ecosystem

In Hardware, Software on Sep 13, 2012 at 00:01

Yesterday’s post presented an example of a simple yet quite powerful platform for “The Internet Of Things” (let’s just call it simple and practical interfacing, ok?). Lots of uses for that in and around the house, especially in the low-cost end of ATmega’s, basic Ethernet, and basic wireless communication.

What I wanted to point out with yesterday’s example, is that there is quite a bit of missed potential when we stay in the 8-bit AVR / Arduino world. There are ARM chips which are a least as powerful, at least as energy-efficient, and at least as low-cost as the ATmega328. Which is not surprising when you consider that ARM is a design, licensed to numerous vendors, who all differentiate their products in numerous interesting ways.

In theory, the beauty of this is that they all speak the same machine language, and that code is therefore extremely portable between different chips and vendors (apart from the inevitable hardware/driver differences). You only need one compiler to generate code for any of these ARM processor families:

arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710 arm710c arm7100 arm720 arm7500 arm7500fe arm7tdmi arm7tdmi-s arm710t arm720t arm740t strongarm strongarm110 strongarm1100 strongarm1110 arm8 arm810 arm9 arm9e arm920 arm920t arm922t arm946e-s arm966e-s arm968e-s arm926ej-s arm940t arm9tdmi arm10tdmi arm1020t arm1026ej-s arm10e arm1020e arm1022e arm1136j-s arm1136jf-s mpcore mpcorenovfp arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-a15 cortex-r4 cortex-r4f cortex-r5 cortex-m4 cortex-m3 cortex-m1 cortex-m0 cortex-m0plus xscale iwmmxt iwmmxt2 ep9312 fa526 fa626 fa606te fa626te fmp626 fa726te

In practice, things are a bit trickier, if we insist on a compiler “toolchain” which is open source, with stable releases for Windows, Mac, and Linux. Note that a toolchain is a lot more than a C/C++ compiler + linker. It’s also a calling convention, a run-time library choice, a mechanism to upload code, and a mechanism to debug that code (even if that means merely seeing printf output).

In the MBED world, the toolchain is in the cloud. It’s not open source, and neither is the run-time library. Practical, yes – introspectable, not all the way. Got a problem with the compiler (or more likely the runtime)? You’re hosed. But even if it works perfectly – ya can’t peek under the hood and learn everything, which in my view is at least as important in a tinkering / hacking / repurposing world.

Outside the MBED world, I have found my brief exploration a grim one: commercial compiler toolchains with “limited free” options, and proprietary run-time libraries everywhere. Not my cup of tea – and besides, in my view gcc/g++ is really the only game in town nowadays. It’s mature, it’s well supported, it’s progressing, and it runs everywhere. Want a cross compiler which runs on platform A to generate code for platform B? Can do, for just about any A and B – though building such a beast is not necessarily easy!

As an experiment, I wanted to try out a much lower-cost yet pin-compatible alternative for the MBED, called the LCPXpresso (who comes up with names like that?):

MFG EA XPR 003

Same cost as an Arduino, but… 512 KB flash, 64 KB RAM, USB, Ethernet, and tons of digital + analog I/O features.

Except: half of that board is dedicated to acting as an upload/debug interface, and it’s all proprietary. You have to use their IDE, with “lock-in” written on every page. Amazing, considering that the ARM chip can do serial uploading via built-in ROM! (i.e. it doesn’t even have to be pre-flashed with a boot loader)

As an experiment, I decided to break free from that straight-jacket:

DSC 3832

Yes, that’s right: you can basically throw away half the board, and then add a few wires and buttons to create a standard FTDI interface, ready to use with a BUB or other 3.3V serial interface.

(there’s also a small regulator mod, because the on-board 3.3V regulator seems to have died on me)

The result is a board which is pin-compatible with the MBED, and will run more or less the same code (it has only 1 user-controllable LED instead of 4, but that’s about it, I think). Oh, and serial upload, not USB anymore.

Does this make sense? Not really, if that means having to manually patch such boards each time you need one. But again, keep in mind that the boards cost the same as an Arduino Uno, yet offers far more than even the Arduino Mega in features and performance.

The other thing about this is that you’re completely on your own w.r.t. compiling and debugging code. Well, not quite: there’s a gcc4mbed by Adam Green, with pre-built x86 binaries for Windows, Mac, and Linux. But out of the box, I haven’t found anything like the Arduino IDE, with GUI buttons to push, lots of code examples, a reference website, and a community to connect with.

For me, personally, that’s not a show stopper (“real programmers prefer the command line”, as they say). But getting a LED to blink from scratch was quite a steep entry point into this ARM world. Did I miss something?

Two more notes:

Yes, I know there’s the Maple IDE by LeafLabs, but I couldn’t get it to upload on my MacBook Air notebook, nor get a response to questions about this on the forum.
No, I’m not “abandoning” the Atmel ATmega/ATtiny world. For many projects, simple ways to get wireless and battery-operated nodes going, I still vastly prefer the JeeNode over any other option out there (in fact, I’m currently re-working the JeeNode Micro, to add a bit more functionality to it).

But its good to stray outside the familiar path once in a while, so I’ll continue to sniff around in that big ARM Cortex world out there. Even if the software exploration side is acting surprisingly hostile to me right now.

Interesting gateway

In Hardware on Sep 12, 2012 at 00:01

A while back, I came across this product, called the “mbed Internet of Things Gateway”:

Gateway

It’s an ARM microcontroller with an Ethernet port, a µSD storage slot, and an RFM12B wireless transceiver. Very nicely packaged in an extruded-aluminium case with laser-cut front and back panels. Here’s what’s inside:

DSC 3833

Not that much circuitry, as you can see – because all the heavy-lifting is done by the MBED board on the left.

That’s a 32-bit microcontroller, with built-in Ethernet and USB, plenty of I/O pins, and lots of features to connect to SPI, I2C, CAN, and other types of devices. Not to mention the 512 KB flash and 32 KB RAM memory – plenty to implement some serious functionality.

MBED comes with an intriguing “cloud-based” compiler and build environment, which is surprisingly effective. Here’s how it works, out of the box:

plug the MBED into USB and it’ll present itself as a memory disk with one HTML file on it
double-click that file to go to the MBED web site
you get a web-based equivalent of a standard Windows IDE, plus a large code sharing community
create your project online, enter your own code, and hit the compile button
if the code compiles successfully, you end up with a file in your download folder
copy that file to the MBED’s USB drive
press on the MBED’s reset button, and that’s it … uploaded and running!

This is a very elegant workflow. No need to install any software to develop for MBED. And you can continue work wherever you are, as long as internet works and you have your MBED with you. You do need to sign up and register a (free) account on that MBED site – in return, they’ll do all the compiles for you.

This board is an exciting development. The cost is higher than with just a JeeNode + EtherCard, but there is also a lot more possible when you don’t have to fight the ATmega328’s strict flash and RAM memory constraints.

I’ll have more to say about this hardware and software tomorrow – stay tuned…

Delayed power-up with P-MOSFETs

In Hardware on Sep 11, 2012 at 00:01

This is a follow-up to the Delayed power-up post, this time using some P-MOSFETs (in SOT-23 SMD form, i.e. tiny). The way I’m testing these, is by using a 1 kΩ resistor as simulated load, and hooking things up as follows:

JC s Grid page 32

These components were not selected for this purpose, in fact, I picked units with a very low switching threshold voltage, so that they can reliably be switched on from an I/O pin, even if we were to run at just 1.8V.

Here are the characteristics of the Philips BSH203 P-MOSFET:

Screen Shot 2012 09 10 at 13 06 34

Just over 1 Ω resistance when driven low by 1.8V, so with a 50 mA load, the voltage drop over this MOSFET will be just over 50 mV.

When placed in the Component Tester, and zooming in on the interesting bit, we get:

SCR11

Each major horizontal division is 2V, so this thing switches on at about 0.5V.

For comparison, the characteristics of the Vishay SI2333 P-MOSFET:

Screen Shot 2012 09 10 at 13 13 27

And in this case, the Component Tester shows this (sorry, can’t zoom in with this setup):

SCR12

A slightly higher turn-on voltage, but note that the ON resistance is considerably lower at 1.8V: only 0.05 Ω. Not surprising, when you consider that this MOSFET can probably switch over 5 A (without self-destructing from the heat dissipation).

Here’s what these tiny components look like, with wires soldered on for “debugging”:

DSC 3828

Looks like either of these will do the trick, when switched from an I/O pin anyway.

Function generator weirdness

In Hardware on Sep 10, 2012 at 00:01

Fighting my lab instruments… not good :(

The TG2511 Arbitrary Waveform Generator in my lab is very flexible, and does all the usual things one would expect of a modern signal generator, i.e. setting the shape, frequency, and amplitude of its output signal.

But there’s some weirdness w.r.t. the amplitude. The built-in impedance is quoted as being 50 Ω, no doubt the reasoning being that if you terminate the cable with 50 Ω as well, then a standard coax cable will have the least possible signal degradation (ringing, reflections, and such).

There is a setting to adjust for the assumed load, so that the instrument can adjust its amplitude accordingly. The default is to assume a 50 Ω load at the end of the cable:

DSC 3826

But this is where I get mightily confused. Here’s what I see with the scope set in high impedance mode:

SCR07

That in itself is actually correct: the output amplitude is twice the expected value, since there is no 50 Ω terminating resistor. So let’s add it in (it’s an option inside the scope):

SCR08

Huh? – Why isn’t the amplitude 3 Vpp, and ends up being only half that value?

But there’s something even stranger, and far more inconvenient about the TG2511. After a few minutes, I often get a message about the output signal being overloaded:

DSC 3827

Doesn’t make sense. I’m never loading the output with more than 50 Ω, i.e. well within specs. Sometimes this happens even when I completely disconnect the load. Even more suspect: the green “OUTPUT” doesn’t always match what’s happening. Sometimes the light is off, yet the output signal is still present!

In fact, I get this screen in the most unexpected situations. Maybe the TG2511’s output stage is broken? Yuck.

I have contacted the supplier for advice.

Delayed power-up

In AVR, Hardware on Sep 9, 2012 at 00:01

To recall yesterday’s reasoning, I’m looking for a way to keep the RFM12B from starting up too soon and drawing 0.6 mA before the microcontroller gets a chance to enable it’s ultra-low power sleep mode.

The solutions so far require an extra I/O pin, allowing the microntroller to turn power on and off as needed, with the extra detail that power stays off until told otherwise.

But all I’m really interested in, is to keep that RFM12B from powering up too soon. After that, I never need to power it down again (and lose its settings) – at 0.3 µA, the RFM12B’s sleep mode will be just fine.

One solution is to use a dedicated chip for this, which can reliably send out a trigger when a fixed voltage threshold has been exceeded. That would still need a MOSFET, though, so this increases the cost (and footprint) of such a solution.

The other way would be to create a low-speed RC network, gradually charging a cap until a threshold is reached and turns on the MOSFET switch. Lower cost, no doubt, but in fact not flexible enough in case of a very slow power-on voltage ramp, as in the case of a solar cell charging a supercap or small battery. There is just no way to determine how long the delay needs to be – it might take days for the power rail to reach a usable level!

Yet another option is this little gem (thanks for the initial suggestion, Martyn!):

JC s Grid page 32

No I/O pin, no pull-up, nothing!

This trick takes advantage of what was originally considered a drawback of MOSFET switching: the fact that the gate voltage has to reach a certain level before the MOSFET will switch. Assuming that voltage is say 1.5V, then the MOSFET will be turned off as long as the power rail has not yet reached 1.5V, and once it rises above that value, it’ll automatically switch on. Magic!

Does it work? Well, I’m still waiting for some P-MOSFETs to arrive, but I’ve done a little test with an N-MOSFET, connected the other way around and using a 1 kΩ resistor as load. We can look at that combination as a component which has only two pins: a power rail and ground.

If the circuit works as expected, then when applying an increasing voltage, no current will flow until the threshold has been reached, and then it’ll switch on and start drawing current.

As it turns out, this is very easily observable using a Component Tester – like the one built into my scope:

SCR06

The horizontal scale is the applied voltage (from about -5V to +5V), the vertical scale is the current through that component (from about -5 mA to +5 mA). The straight slanted line is characteristic of a 1 kΩ resistor.

But the interesting bit is that little dent: from under 0V to about 1.5V, the circuit draws no current at all. Once 1.5V or more are applied, the circuit starts conducting, and behaving like a plain 1 kΩ resistor again.

Woohoo, this might actually work: just a single P-MOSFET would be all that’s needed!

Switching with a P-MOSFET

In AVR, Hardware on Sep 8, 2012 at 00:01

One reason for yesterday’s exploration, is to figure out a way around a flaw of the RFM12B wireless radio module.

Let me explain – the RFM12B module has a clock output, which can be used to drive a microcontroller. The idea being that you can save a crystal that way. Trouble is that this clock signal has to be present on power-up, even though it can be configured over SPI in software, because otherwise the microcontroller would never start running and hence never get a chance to re-configure the radio. A nasty case of Catch 22 (or a design error?).

In short: the radio always powers up with the crystal oscillator enabled. Even when not using that clock signal!

The problem is that an RFM12B draws about 0.6 mA in this mode, even though it can be put to sleep to draw only 0.3 µA (once running and listening to SPI commands). In the case of energy harvesting, where you normally get very tiny amounts of energy to run off, this startup hurdle can be a major stumbling block.

See my low-power supply weblog post about how hard that can be, and may need extra hardware to get fixed.

So I’m trying to find a way to keep that radio powered down until the microcontroller is running, allowing it to be put to sleep right away.

For ultra-low power use, yesterday’s PNP transistor approach is not really good enough.

This is where an interesting aspect of MOSFETs comes in: they make great power switches, because all they need is a gate voltage to turn them on or off. When on, their resistance (and hence voltage drop) is near zero, and the voltage on the gate doesn’t draw any current. Just like a water faucet doesn’t consume energy to keep water running or blocked, only to change the state – so do MOSFETs.

But many MOSFETs typically require several volts to turn them on, which we may or may not have when running at the lower limit of 1.8V of an ATmega or ATtiny. So the choice of MOSFET matters.

Just like yesterday, we’ll need a P-channel MOSFET to let us switch the power supply rail:

JC s Grid page 32

Note the subtly different placement of the resistor. With a PNP transistor, it was needed to limit the current through the base (which then got wasted, but that current is needed to make the transistor switch). With a MOSFET there is no current, but now we need to make sure that the MOSFET stays off until a low voltage is applied.

Except that now R can be very large. It’s basically a pull-up, and can be extremely weak, say 10 MΩ. That means that when pulled low, the leakage current will be only 0.3 µA.

The trick is to find a P-MOSFET type which can switch using a very low gate voltage, so that it can still be fully switched on. I’ve ordered a couple of types to test this out, and will report once they arrive and measurements can be made.

All in all, this is a very nice solution, though – just 2 very simple components. The main drawback is that we still need to reserve an I/O pin for this.

Tomorrow, I’ll explore a refinement which does not even need an extra I/O pin.

Switching with a PNP transistor

In Hardware on Sep 7, 2012 at 00:01

This is an exploration to find out what circuit can be used to switch small electronic loads using a digital I/O pin.

The simplest solution by far, is to use the I/O pin to directly drive the circuit. This works great for low currents, such as an LED with series resistor. But there are limits to how much current you can draw:

Screen Shot 2012 09 06 at 22 49 12

As you can see, from the datasheet, drawing 5 mA will already cause a voltage drop of about 0.2V, so the load will not get the full supply voltage. With larger loads, the drop becomes even more pronounced.

Another approach is to use a PNP transistor, as follows:

PNP drop

Here’s how it works, in case you’re not familiar with them PNP transistor thingies:

pulling the input pin down towards 0V, will turn the PNP transistor on
when on, the transistor will conduct and supply power to the load
leaving the pin floating or pulling it up, will cause the PNP transistor to turn off

In my setup, I’m using a very light load for now. The following measurements will be different as the load increases, but not as substantially as with the raw I/O pin drive. A circuit like this could easily drive a 100..250 mA load, if the base resistor has the right value – as we’ll see.

Time to try this out. I am quite interested in how the voltage drop over the transistor depends on the exact voltage placed on the base junction. Or rather: how much current I’ll need (since the resistor passes a known current once we know the voltage drop.

So as input, I’m using a 10 Hz sawtooth signal, which varies from 0 to 3V. Due to the way things are hooked up, it starts at 3V below the 3.3V power rail, i.e. 0.3V, and then rises to the level of the power rail.

Here are the results with a 10 kΩ resistor – both signals have been inverted, as I’m measuring relative to +3.3V:

SCR01

(oops, ignore the yellow trigger point baseline)

At the start, the transistor is turned on strongly, and then the input voltage falls to zero (yellow trace). As you can see, the voltage drop over the transistor increases non-linearly as it gradually turns off. With only 1V driving it, the voltage drop increases from about 40 mV to 100 mV, i.e. 0.1V. With even less, it starts to switch off and gets the full power supply voltage (so nothing reaches the load).

Now let’s do some math. I used my transistor tester to determine that this particular BC557 PNP transistor had 0.8V drop over its base-to-emitter junction, and that its current amplification factor (hFE) is about 220x.

In other words: with 1.0V on the input, there is 1.0-0.8 = 0.2V on the 10 kΩ resistor. Ohm’s law (E = I x R, or I = E / R) implies that the current through the resistor will be 0.2V / 10kΩ = 20 µA. This current is essentially “wasted”, but given the 220 factor, it will allow the transistor to drive up to 20 µA x 220 = 4.4 mA. Not so great…

Update – not sure what I was smoking at the time I wrote the above paragraph. That’s 1.0V below VCC, roughly the switching threshold of this transistor when used with a 1 kΩ load. I’m not sure what point I was trying to make here, other than that a 20 µA base current is not enough to switch an RFM12B.

But if we pull the input to almost ground level, as would be the case with a digital I/O pin, then the base current increases to (3.3 – 0.8) / 10,000 = 250 µA, supporting a load of up to 250 µA x 220 = 55 mA.

If power waste is not an issue, we could reduce the base resistor to 1 kΩ, and get over 500 mA load switching capability (assuming the transistor is powerful enough). The base current will then be around 2.5 mA, a value which an ATmega I/O pin can still easily supply.

But what if power use is important, i.e. if we can’t afford to waste those 20 µA or more?

Here’s the same circuit, with a 100 kΩ resistor instead:

SCR03

Note how the emitter-to-collector voltage drop (blue line) rises. With 3V input differential, i.e. almost pulled to ground, the drop over the transistor is still under 0.15V, but we’ll need to keep the input voltage at least 1.5V below the power supply voltage to make this work. So in very low-voltage / low-power scenario’s (i.e. running off two almost-depleted AA cells), this might become tricky.

The current losses are now only 1/10th, i.e. 25 µA when the power supply is 3.3V and the input is tied to ground. Then again, in the ultra-low power world that wasted 25 µA is not really such an impressive figure.

Still, for switching loads which draw up to a few hundred milliamps, this circuit using just a PNP transistor and a resistor is really quite practical. If you use a 1 kΩ resistor, the base current will be well with the I/O pin’s capabilities, and the transistor will usually have enough drive to switch its load.

The only other drawback is that the transistor will always add a small voltage drop of perhaps 50 .. 200 mV.

There is a third solution using MOSFETs, with its own set of trade-offs. To be continued…

Current clamp

In Hardware on Sep 5, 2012 at 00:01

To continue where I left off before the summer, let’s examine what a current clamp like this one does:

DSC 3354

You put it around a single wire in your AC mains cabling and it’ll generate a voltage proportional with the current going through it. This unit has a built-in burden resistor, which means you get a ± 1V (AC!) output when the current through the wire is 30 A. So let’s have some fun and look at a couple of different loads, eh?

Let’s start off with an old-fashioned 25W incandescent light-bulb, which is a resistive load:

SCR28

Note the vertical scale – these voltage levels are tiny. The scope caclulates the Root Mean Square (RMS) voltage as being 3.52 mV in this case. That’s the voltage you’d need to draw as direct current to dissipate the same amount of power as this alternating current (let’s ignore phase shift and “reactive” vs “true” power for now).

Sure enough, a 75W light bulb draws three times as much power (note the different vertical scale):

SCR29

Here’s a 2W LED light bulb, which uses an electronic circuit to pulse small amounts of energy from AC mains:

SCR30

Again, note how this minute RMS reading corresponds quite accurately to the specified wattage.

Now let’s take a vacuum cleaner, which is an inductive load, and quite a lot beefier too:

SCR31

The “blips” are switching artifacts from the TRIAC control included in this unit. From the RMS value, my estimate would be that it draws about 1500W. Here’s the same vacuum cleaner, with its power throttled back to minimum:

SCR32

As with the LED light, you can see the electronics kicking in and pulsing AC mains to throttle power back to around 500W.

Conclusion: a current clamp is a safe way to measure current in an AC mains wire, and it more or less reproduces the measured current as a small output voltage. Very small in fact, for light loads. To accurately determine the RMS value of a load as small as our 2W LED light, we’re going to have to read out this signal in the sub-millivolt range, and do so at perhaps 1000 HZ to collect enough readings per 50 Hz cycle.

Tizio LED transplant

In Hardware on Sep 4, 2012 at 00:01

For some time now, there have been two of these Tizio lamps in the house. A gorgeous design and very practical:

DSC 3517

As so many lamps from last century, they come with a halogen incandescent light bulb:

DSC 3507

Lifetimes are great (I don’t think I ever replaced one), but efficiency less so. So I decided to replace them anyway:

DSC 3509

These are simple 1.2W warm-white LED lights with built-in rectifier and current limiting resistors. Here’s the result:

DSC 3508

The transplant ended up being very simple, the UV filter glass is no longer needed, the power consumption has dropped from ~~50W~~ 35W to ~~12W~~ 5W, and – if all is well – these LEDs will never need to be replaced again.

Easy peasy! Now if only all our incandescent lights had equally simple alternatives…

New HYT131 sensor

In Hardware, Software on Jun 30, 2012 at 00:01

The SHT11 sensor used on the room board is a bit pricey, and the bulk source I used in the past no longer offers them. The good news is that there’s a HYT131 sensor with the same accuracy and range. And the same pinout:

DSC 3353

This sensor will be included in all Room Board kits from now on.

It requires a different bit of software to read out, but the good news is that this is now standard I2C and that the code no longer needs to do all sorts of floating point calculations. Here’s a test sketch I wrote to access it:

Screen Shot 2012 06 30 at 00 23 28

And here’s some sample output (measurements increase when I touch the sensor):

Screen Shot 2012 06 28 at 15 39 55

As you can see, this reports both temperature and humidity with 0.1 resolution. The output gets converted to a float for display purposes, but apart from that no floating point code is needed to use this sensor. This means that the HYT131 sensor is also much better suited for use with the memory-limited JeeNode Micro.

It’ll take a little extra work to integrate this into the roomNode sketch, but as far as I’m concerned that’ll have to wait until after the summer break. Which – as far as this weblog goes – will start tomorrow.

One more post tomorrow, and then we “Northern Hemispherians” all get to play outside for a change :)

Update – I’ve uploaded the datasheet here.

Assembling the EmonTX

In Hardware on Jun 29, 2012 at 00:01

The guys at OpenEnergyMonitor – hi Glyn and Trystan! – have been working on a number of open source energy monitoring kits for some time now. With solar panels coming here soon, I thought it’d be nice to try out their EmonTX unit – which is partly derived from a bunch of stuff here at JeeLabs. Here’s the kit I got recently:

DSC 3351

Following these excellent instructions, assembly was a snap (I added the 868 MHz RFM12B wireless module):

DSC 3352

Whee, assembling kits is fun! :)

I had some 30A current clamps from SeeedStudio lying around anyway, so that’s what I’ll be using.

The transformer is a 9 VAC type, to help the system detect zero crossings, so that real power factors can be calculated. Unfortunately, this transformer doesn’t (yet) power the system (but it now looks like it might in a future version), so this thing also needs either FTDI or USB to power it.

Here are my ~~first~~ updated measurement results, using the voltage_and_current.ino sample sketch in EmonLib:

    0.27 4.17 260.39 0.02 0.06 
    -0.02 0.71 260.77 0.00 -0.03 
    0.03 0.71 260.74 0.00 0.04 
    -0.02 0.71 260.56 0.00 -0.03 
    0.02 0.71 260.63 0.00 0.03 
    -100.93 105.81 260.88 0.41 -0.95 
    -97.68 102.16 260.94 0.39 -0.96 
    -99.07 104.42 260.98 0.40 -0.95 
    -97.15 102.57 260.74 0.39 -0.95 
    -97.69 102.29 260.91 0.39 -0.95

The values printed out are:

realPower
apparentPower
Vrms
Irms
powerFactor

These readings were made with a clamp on one wire of a 25W lightbulb load – first off, then on. The mains voltage estimated from the 9V transformer is a bit high – it’s usually about 230V around here. My plan is to measure and report two independent power consumers and one producer (the solar panel inverter), so I’ll dive into this in more detail anyway. But that’ll have to wait until after the summer break.

Speaking of which: the June discount ends tomorrow, just so you know…

Update – I have disconnected the burden resistors, since the SCT-013-030 has one built in. See comments.

TK – Measuring milli-ohms

In Hardware on Jun 28, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Today, I’d like to present a nifty new arrival here at JeeLabs, called the Half Ohm:

DSC 3348

It’s a brilliant little tool (with a cute name). What it does is convert milliohm to millivolt, and it works roughly in the range 0 .. 500 mΩ. Hence the name. On the back is a coin cell, and there’s a tiny on-off switch. Luckily, it’s hard to forget to turn the thing off because there’s a bright red LED while it’s powered up.

Milliohms are tricky. Fortunately, Jaanus Kalde, who created this tool has it all explained on his website.

So what can you do with a milliohm meter? Well, measure the resistance of your test leads, for one:

DSC 3349

That’s 22.8 mΩ, i.e. 0.0228 Ω. Not surprising, because (almost) every conductor has some resistance.

Being able to measure such low resistances can be extremely useful to find shorts. For example, when using longer test leads, I can see that their own resistance is 74 mΩ. And with that knowledge, we can measure PCB traces:

DSC 3350

Turns out that in this case I got about 112 mΩ, which means that this little 5 cm stretch of copper on the PCB has 37 mΩ resistance. And sure enough, the other ground pins have less resistance when when the path is shorter, and more when the path is longer. This is very logical – note also that between the GND pins I’ll be measuring relatively low values because of the relatively “fat” ground plane, which reduces overall DC resistance.

To find shorts, we simply measure the resistance between any two points (with no power connected, of course). If the measured value is close to 75 mΩ, then it’s a short. If it’s well above say 150 mΩ, then it’s definitely not a short.

To locate a short circuit, we can now simply move probes towards the direction of lowest resistance.

Looks like the Half Ohm will be a great help for this type of hard-to-isolate problems!

PS. No need to do the subtraction in your head if you have a multimeter which supports relative measurements.

Edge interrupts

In AVR, Hardware, Software on Jun 27, 2012 at 00:01

To continue yesterday’s discussion about level interrupts, the other variant is “edge-triggered” interrupts:

JC s Grid page 22

In this case, each change of the input signal will trigger an interrupt.

One problem with this is that it’s possible to miss input signal changes. Imagine applying a 1 MHz signal, for example: there is no way for an ATmega to keep up with such a rate of interrupts – each one will take several µs.

The underlying problem is a different one: with level interrupts, there is sort of a handshake taking place: the external device generates an interrupt and “latches” that state. The ISR then “somehow” informs the device that it has seen the interrupt, at which point the device releases the interrupt signal. The effect of this is that things always happen in lock step, even if it takes a lot longer before the ISR gets called (as with interrupts disabled), or if the ISR itself takes some time to process the information.

With edge-triggered interrupts, there’s no handshake. All we know is that at least one edge triggered an interrupt.

With “pin-change interrupts” in microcontrollers such as the ATmega and the ATtiny, things get even more complicated, because several pins can all generate the same interrupt (any of the PD0..PD7 pins, for example). And we also don’t get told whether the pin changed from 0 -> 1 or from 1 -> 0.

The ATmega328 datasheet has this to say about interrupt handling (page 14):

Screen Shot 2012 06 26 at 23 08 46

(note that the “Global Interrupt Enable” is what’s being controlled by the cli() and sei() instructions)

Here are some details about pin-change interrupts (from page 74 of the datasheet):

Screen Shot 2012 06 26 at 23 13 01

The way I read all the above, is that a pin change interrupt gets cleared the moment its associated ISR is called.

What is not clear, however, is what happens when another pin change occurs before the ISR returns. Does this get latched and generate a second interrupt later on, or is the whole thing lost? (that would seem to be a design flaw)

For the RF12 driver, to be able to use pin-change interrupts instead of the standard “INT0” interrupt (used as level interrupt), the following is needed:

every 1 -> 0 pin change needs to generate an interrupt so the RFM12B can be serviced
every 0 -> 1 pin change can be ignored

The current code in the RF12 library is as follows:

Screen Shot 2012 06 26 at 23 19 59

I made that change from an “if” to a “while” recently, but I’m not convinced it is correct (or that it even matters here). The reasoning is that servicing the RFM12B will clear the interrupt, and hence immediately cause the pin to go back high. This happens even before rf12_interrupt() returns, so the while loop will not run a second time.

The above code is definitely flawed in the general case when more I/O pins could generate the same pin change interrupt, but for now I’ve ruled that out (I think), by initializing the pin change interrupts as follows:

Screen Shot 2012 06 26 at 23 23 28

In prose:

make the RFM12B interrupt pin an input
enable the pull-up resistor
allow only that pin to trigger pin-change interrupts
as last step, enable that pin change interrupt

Anyway – I haven’t yet figured out why the RF12 driver doesn’t work reliably with pin-change interrupts. It’s a bit odd, because things do seem to work most of the time, at least in the setup I tried here. But that’s the whole thing with interrupts: they may well work exactly as intended 99.999% of the time. Until the interrupt happens in some particular spot where the code cannot safely be interrupted and things get messed up … very tricky stuff!

Level interrupts

In Hardware, Software on Jun 26, 2012 at 00:01

The ATmega’s pin-change interrupt has been nagging at me for some time. It’s a tricky beast, and I’d like to understand it well to try and figure out an issue I’m having with it in the RF12 library.

Interrupts are the interface between real world events and software. The idea is simple: instead of constantly having to poll whether an input signal changes, or some other real-world event occurs (such as a hardware count-down timer reaching zero), we want the processor to “somehow” detect that event and run some code for us.

Such code is called an Interrupt Service Routine (ISR).

The mechanism is very useful, because this is an effective way to reduce power consumption: go to sleep, and let an interrupt wake up the processor again. And because we don’t have to keep checking for the event all the time.

It’s also extremely hard to do these things right, because – again – the ISR can be triggered any time. Sometimes, we really don’t want interrupts to get in our way – think of timing loops, based on the execution of a carefully chosen number of instructions. Or when we’re messing with data which is also used by the ISR – for example: if the ISR adds an element to a software queue, and we want to remove that element later on.

The solution is to “disable” interrupts, briefly. This is what “cli()” and “sei()” do: clear the “interrupt enable” and set it again – note the double negation: cli() prevents interrupts from being serviced, i.e. an ISR from being run.

But this is where it starts to get hairy. Usually we just want to prevent an interrupt to happen now – but we still want it to happen. And this is where level-interrupts and edge-interrupts differ.

A level-interrupt triggers as long a an I/O signal has a certain level (0 or 1) and works as follows:

JC s Grid page 22

Here’s what happens at each of those 4 points in time:

an external event triggers the interrupt by changing a signal (it’s usually pulled low, by convention)
the processor detects this and starts the ISR, as soon as its last instruction finishes
the ISR must clear the source of the interrupt in some way, which causes the signal to go high again
finally, the ISR returns, after which the processor resumes what it had been doing before

The delay from (1) to (3) is called the interrupt latency. This value can be extremely important, because the worst case determines how quickly our system responds to external interrupts. In the case of the RFM12B wireless module, for example, and the way it is normally set up by the RF12 code, we need to make sure that the latency remains under 160 µs. The ISR must be called within 160 µs – always! – else we lose data being sent or received.

The beauty of level interrupts, is that they can deal with occasional cli() .. sei() interrupt disabling intervals. If interrupts are disabled when (1) happens, then (2) will not be started. Instead, (2) will be started the moment we call sei() to enable interrupts again. It’s quite normal to see interrupts being serviced right after they are enabled!

The thing about these external events is that they can happen at the most awkward time. In fact, take it from me that such events will happen at the worst possible time – occasionally. It’s essential to think all the cases through.

For example: what happens if an interrupt were to occur while an ISR is currently running?

There are many tricky details. For one, an ISR tends to require quite a bit of stack space, because that’s where it saves the state of the running system when it starts, and then restores that state from when it returns. If we supported nested interrupts, then stack space would at least double and could easily grow beyond the limited amount available in a microcontroller with limited RAM, such as an ATmega or ATtiny.

This is one reason why the processor logic which starts an ISR also disables further interrupts. And re-enables interrupts after returning. So normally, during an ISR no other ISRs can run: no nested interrupt handling.

Tomorrow I’ll describe how multiple triggers can mess things up for the other type of hardware interrupt, called an edge interrupt – this is the type used by the ATmega’s (and ATtiny’s) “pin-change interrupt” mechanism.

… and pies

In Hardware on Jun 25, 2012 at 00:01

This post follows up on yesterday’s first dive into the Raspberry Pi computer.

I switched to a beta of the next Debian release, called Wheezy. Full screen detect out of the box now:

DSC 3343

Those stripes are artifacts – that’s Moiré kicking in when using CCD pixels to take a picture of TFT LCD pixels.

The idea is to turn this thing into a permanent fixture on the back of this panel – right above my workbench:

DSC 3346

This is using a separate 5V and a 12V supply for now, but I’d like to explore a range of other options:

no keyboard or mouse normally attached
using a USB WiFi dongle instead of wired Ethernet
powered from a single 12V @ 2A DC power brick
add a step-down switching regulator to generate 5V
maybe: relays to control power to display and computer
a PIR motion sensor plus light sensor to detect presence?
a JeeNode USB, perhaps used as central node or as OOK relay
and maybe also a rechargeable 6V or 12V battery as UPS

The latter depends on whether this setup will become part of the permanent home automation system at JeeLabs.

As switcher I’ll use a no-name brand from eBay – it delivers 5V at over 1 A and draws about 8 mA without load:

DSC 3345

Lots of pesky little details need to be worked out, such as how to get a Sitecom WLA-1000 USB WiFi dongle working, how to set up what is essentially “kiosk mode”, and how to control the display backlight. I’d also like to hook up an RFM12B directly to the main board, to see how convenient this is and what can be done with it.

There’s a nice article at next.kolumbus.no about setting up something quite similar. Long live the sharing culture!

Total system cost should be roughly €100..150, since I recovered the screen from an old Dell laptop.

Onwards!

Raspberries …

In Hardware on Jun 24, 2012 at 00:01

Recently got a Raspberry Pi here. Add keyboard, mouse, display, and USB power adapter and there it goes:

DSC 3341

Oh yes, I did have to put Debian 6 (Squeeze) on a 2 GB SD memory card first, using these instructions.

Note that my 1280×720 screen size isn’t auto-detected, but it’s good enough for now. This is the whole system:

DSC 3342

Next step – switch over to Ethernet:

plug in an Ethernet cable, it automatically registers via DHCP
log in via SSH, get rid of the greeting (simply create ~/.hushlogin)
set up password-less SSH access, yada, yada, yada

Done. Now I can unplug the keyboard and mouse, and insert a JeeLink. It’s recognized right out of the box:

Screen Shot 2012 06 23 at 15 13 48

Does it work? Let’s check with JeeMon (using a runtime built for ARM, of course):

download the “jeemon-sheeva-deb6.zip” from https://jeelabs.org/pub/jeemon/
unzip and copy the “jeemon” executable to /usr/local/bin/

Here’s a quick look at some stats and then a check that JeeMon works:

Screen Shot 2012 06 23 at 15 09 54

Looks good. Now let’s see if the JeeLink is accessible:

Yup. Done. Total setup time: 5 minutes (plus another 10 for the SD card). Well done, Raspberry Pi!

This draws 14 W in total, including 11 W for the display (when on) and 0.4 W when Ethernet is plugged in.

Low power – µA’s in perspective

In AVR, Hardware on Jun 23, 2012 at 00:01

Ultra-low power computing is a recurring topic on this weblog. Hey – it’s useful, it’s non-trivial, and it’s fun!

So far all the experiments, projects, and products have been with the ATmega from Atmel. It all started with the ATmega168, but since some time it’s now all centered around the ATmega328P, where “P” stands for pico power.

There’s a good reason to use the ATmega, of course: it’s compatible with the Arduino and with the Arduino IDE.

With an ATmega328 powered by 3.3V, the lowest practical current consumption is about 4 µA – that’s with the watchdog enabled to get us back out of sleep mode. Without the internal watchdog, i.e. if we were to rely on the RFM12B’s wake-up timer, that power-down current consumption would drop considerably – to about 0.1 µA:

Screen Shot 2012 06 22 at 22 03 30

Whoa, that’s a factor 40 less! Looks like a major battery-life improvement could be achieved that way!

Ahem… not so fast, please.

As always, the answer is a resounding “that depends” – because there are other power consumers involved, and you have to look at the whole picture to understand the impact of all these specs and behaviors.

First of all, let’s assume that this is a transmit-only sensor node, and that it needs to transmit once a minute. Let’s also assume that sending a packet takes at most 6 ms. The transmitter power consumption is 25 mA, so we have a 10,000:1 sleep/send ratio, meaning that the average current consumption of the transmitter will be 2.5 µA.

Then there’s the voltage regulator. In some scenarios, it could be omitted – but the MCP1702 and MCP1703 used on JeeNodes were selected specifically for their extremely low quiescent current draw of 2 µA.

The RFM12B wireless radio module itself will draw between 0.3 µA and 2.3 µA when powered down, depending on whether the wake-up timer and/or the low-battery detector are enabled.

That’s about 5 to 7 µA so far. So you can see that a 0.1 µA vs 4 µA difference does matter, but not dramatically.

I’ve been looking at some other chips, such as ATXmega, PIC, MSP430, and Energy Micro’s ARM. It’s undeniable that those ATmega328’s are really not the lowest power option out there. The 8-bit PIC18LF25K22 can keep its watchdog running with only 0.3 µA, and the 16-bit MSP430G2453 can do the same at 0.5 µA. Even the 32-bit ARM EFM32TG110 only needs 1 µA to keep an RTC going. And they add lots of other really neat extra features.

In terms of low power there are at two more considerations: other peripherals and battery size / self-discharge.

In a Room Node, there’s normally a PIR sensor to detect and report motion. By its very nature, such a sensor cannot be shut off. It cannot even be pulsed, because a PIR needs a substantial amount of time to stabilize (half a minute or more). So there’s really no other option than to keep it powered on at all times. Well, perhaps you could turn it off at night, but only if you really don’t care what happens then :)

Trouble is: most PIR sensors draw a “lot” of current. Some over 1 mA, but the most common ones draw more like 150..200 µA. The PIR sensor I’ve found for JeeLabs is particularly economical, but it still draws 50..60 µA.

This means that the power consumption of the ATmega really becomes almost irrelevant. Even in watchdog mode.

The other variable in the equation is battery self-discharge. A modern rechargeable Eneloop cell is quoted as retaining 85% of its charge over 2 years. Let’s assume its full charge is 2000 mAh, then that’s 300 mAh loss over 2 years, which is equivalent to about 17 µA of continuous self-discharge.

Again, the 0.1 µA vs 4 µA won’t really make such a dramatic difference, given this figure. Definitely not 40-fold!

As you can see, every microamp saved will make a difference, but in the grand scheme of things, it won’t double a battery’s lifetime. There’s no silver bullet, and that Atmel ATmega328 remains a neat Arduino-compatible option.

That doesn’t mean I’m not peeking at other processors – even those that don’t have a multi-platform IDE :)

Disk storage

In Hardware on Jun 19, 2012 at 00:01

I recently stumbled across this ad in Byte Magazine of August 1980:

What a bargain! – Now compare it to this one at NewEgg (yeah, no enclosure or power supply, I know):

Screen Shot 2012 06 17 at 02 23 12

(note how this drive has more RAM included as cache even than the total storage on that 1980’s disk!)

Let’s ignore inflation and try to compare storage prices across this 32-year stretch:

$4995 for 26 MB is $192 per megabyte
$170 for 3 TB is $57 per terabyte – six extra zero’s
in other words: storage has become ≈ 3.37 million times cheaper

Then again, hard drives are so passé … it’s all SSD and cloud storage, nowadays.

The amazing bit is not merely the staggering size increase and price reduction, but the fact that this happened within less than a lifetime. Bill’s, Steve’s – anyone over 50 will have witnessed this, basically.

Might be useful to think about this when putting our work in context of… a few years down the road from now.

Simple digital oscillator

In Hardware on Jun 18, 2012 at 00:01

As described in this recent post, it should be possible to create a simple fixed frequency oscillator using just a few low-cost components. This could then be used as interrupt source to wake up an ATmega every millisecond or so.

Here’s a first attempt, based on a widely-used circuit, as described in Fairchild’s Application Note 118:

Screen Shot 2012 06 16 at 13 08 02

I used a CD4049 hex inverter, since I had them within easy reach:

DSC 3336

The two resistors are 10 kΩ, the capacitor is 0.1 µF – and here’s what it does:

SCR27

The yellow trace is VOUT, the blue trace is V1. Pretty stable oscillation at 456 Hz.

Unfortunately, the current draw is a bit high with these components: 140 µA idle, and 450 µA when oscillating! There would be no point, yesterday’s approach will take half as much current using just a single 0.1 µF cap.

If someone has a tip for a simple 0.5 .. 1 KHz oscillator which consumes much less power, please let me know…

Low-power waiting – interrupts

In AVR, Hardware on Jun 17, 2012 at 00:01

Following yesterday’s trial, here is the code which uses the pin-change interrupt to run in a continuous cycle:

Screen Shot 2012 06 15 at 17 57 02

The main loop is empty, since everything now runs on interrupts. The output signal is the same, so it’s working.

Could we somehow increase the cycle frequency, to get a higher time resolution? Sure we can!

The above code discharges the cap to 0V, but if we were to discharge it a bit less, it’d reach that 1.66V “1” level more quickly. And sure enough, changing the “50” loop constant to “10” increase the rate to 500 Hz, a 2 ms cycle:

SCR24

As you can see, the cap is no longer being discharged all the way to 0V. A shorter discharge cycle than this is not practical however, since the voltage does need to drop to a definite “0” level for this whole “cap trick” to work.

So how do we make this consume less power? Piece of cake: turn the radio off and go to sleep in the main loop!

Screen Shot 2012 06 15 at 19 50 10

The reason this works, is that the whole setup continuously generates (and processes) pin-change interrupts. As a result, this JeeNode SMD now draws about 0.23 mA and wakes up every 2 ms using nothing more than a single 0.1 µF cap tied to an I/O pin. Mission accomplished – let’s declare (a small) victory!

PS. Exercise for the reader: you could also use this trick to create a simple capacitance meter :)

Low-power waiting

In AVR, Hardware on Jun 16, 2012 at 00:01

This continues where yesterday left off, trying to wait less than 16 milliseconds using as little power as possible.

First off, I’m seeing a lot of variation, which I can’t explain yet. I decided to use a standard JeeNode SMD, including regulator and RFM12B radio, since that will be closer to the most common configuration anyway.

Strangely enough, this sketch now generates a 704 µS toggle time instead of 224 µs, i.e. 44 processor cycles per loop() iteration. I don’t know what changed since yesterday, and that alone is a bit worrying…

The other surprise is that power consumption varies quite a bit between different units. On one JN SMD, I see 1.35 mA, on another it’s only 0.86 mA. Again: I have no idea (yet) what causes this fairly substantial variation.

How do we reduce power consumption further? The watchdog timer is not an option for sleep times under 16 ms.

The key point is to find some suitable interrupt source, and then go into a low-power mode with all the clock/timing circuitry turned off (in CMOS chips, most of the energy is consumed during signal transitions!).

Couple of options:

run the ATmega off its internal 8 MHz RC clock and add a 32 KHz crystal
add extra circuitry to generate a low-frequency pulse and use pin-change interrupts
connect the RFM12B’s clock pin to the IRQ pin and use Timer 2 as divider
add a simple RC to an I/O pins and interrupt on it’s charge cycle
use the RFM12B’s built-in wake-up timer – to be explored in a separate weblog post

Option 1) has as drawback that you can’t run with standard fuse settings anymore: the clock will have to be the not-so-accurate 8 MHz RC clock and the crystal oscillator needs to be set appropriately. It does seem like this would allow short-duration low-power waiting with a granularity of ≈ 30 µs.

Option 2) needs some external components, such as perhaps a low-power 7555 CMOS timer. This would probably still consume about 0.1 mA – pretty low, but not super-low. Or maybe a 74HC4060, for perhaps 0.01 mA (10 µA) power consumption.

Option 3) may sound like a good idea, since Timer 2 can run while the rest of the ATmega’s clock circuits are switch off. But now you have to keep the RFM12B’s 10 MHz crystal running, which draws 0.6 mA … not a great improvement.

Option 4) seems like an option worth trying. The idea is to connect these components to a spare I/O pin:

JC s Grid page 17

By pulling the I/O pin low as an output, the capacitor gets discharged. When turning the pin into a high-impedance input, the cap starts charging until it triggers a transition from a “0” to a “1” input, which could be used as pin-change interrupts. The resistor value R needs to be chosen such that the charge time is near to what we’re after for our sleep time, say 1 millisecond. Longer times can then be achieved by repeating the process.

It might seem odd to do all this for what is just one thousandths of a second, but keep in mind that during this time the ATmega can be placed in deep-sleep mode, consuming only a few µA’s. It will wake up quickly, and can then either restart another sleep cycle or resume its work. This is basically the same as a watchdog interrupt.

Let’s first try this using the internal pull-up resistor instead, and find out what sort of time delays we get:

Screen Shot 2012 06 15 at 17 22 53

(several typo’s: the “80 µs” comment in the above screen shot should be “15 µs” – see explanation below)

This code continuously discharges the 0.1 µF capacitor connected to DIO1, then waits until it charges up again:

SCR23

With the internal pull-up we get a 3.4 ms cycle time. By adding an extra external resistor, this could be shortened. The benefit of using only the internal pull-up, is that it also allows us to completely switch off this circuit.

We can see that this ATmega switches to “1” when the voltage rises to 1.66V, and that its internal pull-up resistor turns out to be about 49 kΩ (I determined this the lazy way, by tweaking values on this RC calculator page).

Note that discharge also takes a certain amount of time, i.e. when the output pin is set to “0”, we have to keep it there a bit. Looks like discharge takes about 15 µs, so I adjusted the asm volatile (“nop”) loop to cycle 50 times:

SCR22

In other words, this sketch is pulling the IO pin low for ≈ 15 µs, then releases it and waits until the internal pull-up resistor charges the 0.1 µF capacitor back to a “1” level. Then this cycle starts all over again. Easy Peasy!

So there you have it: a single 0.1 µF capacitor is all it takes to measure time in 3.4 µs ms increments, roughly. Current consumption should be somewhat under 67 µA, i.e. the current flowing through a 49 kΩ resistor @ 3.3V.

Tomorrow, I’ll rewrite the sketch to use pin-change interrupts and go into low-power mode… stay tuned!

Waiting without the watchdog

In AVR, Hardware on Jun 15, 2012 at 00:01

The watchdog timer in the ATmega has as shortest interval about 16..18 milliseconds. Using the watchdog is one of the best ways to “wait” without consuming much power: a fully powered ATmega running at 16 MHz (and 3.3V) draws about 7 mA, whereas it drops thousandfold when put to sleep, waiting for the watchdog to wake it up again.

The trouble is: you can’t wait less than that minimum watchdog timer cycle.

What if we wanted to wait say 3 ms between transmitting a packet and turning on the receiver to pick up an ACK?

Short time delays may also be needed when doing time-controlled transmissions. If low power consumption is essential, then it becomes important to turn the transmitter and receiver on at exactly the right time, since these are the major power consumers. And to wait with minimal power consumption in between…

One approach is to slow down the clock by enabling the built-in pre-scaler, but this has only a limited effect:

Screen Shot 2012 06 14 at 16 39 58

The loop toggles an I/O bit to allow verification of the reduced clock rate. The above code draws about 1.6 mA, whereas the same code running at full speed (16 MHz) draws about 8.8 mA. Note that these measurements ended up a bit lower, but that was as 3.3V – I’m running from a battery pack in these tests, i.e. at about 4.0V.

The I/O pin toggles at 2.23 KHz in slow mode, vs 573 KHz at full speed, which indicates that the system clock was indeed running 256 times slower. A 2.23 KHz rate is equivalent to a 224 µs toggle cycle, which means the system needs 14 processor cycles (16 µs each) to run through this loop() code. Most of it is the call/return stack overhead.

So basically, we could now wait a multiple of 16 µs while consuming about 1.6 mA – that’s still a “lot” of current!

Tomorrow, I’ll explore ways to reduce this power consumption further…

Code vs. power consumption

In AVR, Hardware on Jun 13, 2012 at 00:01

I’ve been wondering for some time whether the power consumption of an ATmega varies depending on the code it is running. Obviously, sleep modes and clock rate changes have a major impact – but how about plain loops?

To test this, I uploaded the following sketch into a JeeNode:

Screen Shot 2012 06 12 at 21 34 50

Interrupts were turned off to prevent the normal 1024 µs timer tick from firing and running in between. And I’m using “volatile” variables to make sure the compiler doesn’t optimize these calculations away (as they’re not used).

The result is that the code pattern does indeed show up in the chip’s total current consumption:

SCR20

The value displayed is the voltage measured over a 10 Ω resistor in series with VCC (the JeeNode I used had no regulator, and was running directly off a 3x AA battery pack @ 3.95V).

What you can see is that the power consumption cycles between about 8.4 mA and 8.8 mA, just by being in different parts of the code. Surprising perhaps, but it’s clearly visible!

The shifts in the second loop are very slow – due to the fact that the ATmega has no barrel shifter. It has to use a little loop to shift by N bits. To get a nice picture, those shifts are performed only 5,000 times instead of 50,000.

The high power consumption is during the multiplication loop, the low consumption is during the shift loop.

In the end, I had to use a lot of tricks to create the above oscilloscope capture, because there was a substantial amount of 50 Hz hum on the measured input signal. Since the repetition rate of the signal I was interested in was not locked to that 50 Hz AC mains signal, most of the “noise” went away by averaging the signal over 128 triggers.

The other trick was to use the scope’s “DC offset” facility to lower the signal by 80 mV. This allows bumping the input sensitivity all the way up to 2 mV/div without the trace running off the screen. An alternative would be to use AC coupling on the input, but then I’d lose the information about the actual DC levels being measured.

What else can we deduce from the above screen shot?

loop 1 takes 93.48 ms for 50,000 iterations, so one cycle runs in ≈ 1.8 µs
loop 2 takes 108.52 ms for 5,000 iterations, so one cycle runs in ≈ 21.8 µs

As you can see, shifts by a variable number of bits do take quite a lot of time on an ATmega, relatively speaking!

Update – As noted in the comments, a shift by “321” ends up being done modulo 256, i.e. 65 times. If I change the shift to 3, the run times drop to being comparable to a multiply. The power consumption effect remains.

Jumping to conclusions

In Hardware on Jun 12, 2012 at 00:01

Yesterday, I made an effort to remove some glitches which I thought were due to the switching regulator used inside the ±15V DC-DC converter. To be honest: it didn’t really make any sense when I saw this on the scope…

It’s always easy to draw some conclusion – it’s a bit harder to avoid uttering complete nonsense…

Here’s the signal with the power supply turned off, and only the ground cable still connected:

SCR19

Clearly the same signal – it appears even when the 1 meter ground cable isn’t tied to anything: it’s an antenna!

In other words: I’m probably just picking up one of the FM transmitters in this region. I should of course have turned on the scope’s built-in 20 MHz bandwidth filter. There was no reason to look for frequencies that high with a switcher in the 60..100 KHz region. And the fact that neither a bypass capacitor nor various inductors made much difference should have been a clue. How embarrassing.

Onwards, quickly!

Switching glitches

In Hardware on Jun 11, 2012 at 00:01

The dual power supply described yesterday had a nasty spike every 5 µs. I tried damping them with one of these:

Varkensneus

(they are called “varkensneus” – pigs nose – in Dutch, ’cause that’s what they look like, seen from the end)

But the results were not very substantial when adding one to the supply output. When I added one on both the input and the output of the 7812 regulator, things did improve a bit further:

SCR15

The yellow trace is the output with ferrite core between the DC-DC converter output and the 7812 linear regulator input, and the blue trace is from a second ferrite core added at the end, i.e. the linear regulator’s output pin.

Note the scale of this oscilloscope capture: 10 nsec/div, so this is a 100 MHz high frequency signal of about ± 200 mV. The second ferrite core almost halves these spike’s amplitudes.

In conclusion: these are very brief ± 100 mV glitches, super-imposed on the +12V supply output voltage – i.e. about ±1% of the regulated supply output voltage. The glitches don’t change much with a 1 kΩ load, i.e. 12 mA.

It’s an artifact of the switching inside the DC-DC converter – looks like there’s not much more I can do about it!

Dual power supply

In Hardware on Jun 10, 2012 at 00:01

To generate a sine wave of ±10V for the Component Tester project, I’m going to need a suitable power supply.

The first option would be to take a dual-windings 12 VAC transformer, add a bridge rectifier, two beefy electrolytic capacitors, and violá: ±12V, right?

Not so fast… this is called an unregulated supply. It has a couple of drawbacks: 1) the voltages will actually be considerably larger than ±12V, 2) the voltages will change depending on the current drawn, and 3) the voltages can have a lot of residual ripple voltage. Let’s go through each of these:

Voltage levels – a 12 VAC transformer generates a 50 Hz alternating current (60 Hz in the US) with an RMS voltage of about 12 VAC. For a sine wave, this corresponds to a peak voltage which is 1.414 times as high, i.e. 17 Volts peak to peak. With a bridge rectifier, you end up topping each of the two caps to 17V DC.
Regulation – or rather: lack thereof. Since the input is a sine wave which only peaks at 17V, the caps will be charged up to this value only a couple of dozen times per second. In between, current drawn will simply discharge them, causing the voltage to drop. Large current = much lower voltage.
Ripple voltage – this variation on the power supply is called ripple. It’ll be either the same frequency of AC mains, or double that value – depending on the rectification circuit used. So that’s a 50..120 Hz signal on top of what was supposed to be a fixed supply voltage (that’s why bad audio amplifiers can “hum”).

There’s a very simple solution to all these issues: add 2 linear regulators to generate a far more stable supply voltage (one for the positive and one for the negative supply). The most widely used regulator chips are the 78xx series (+) and the 79xx series (-). You give them a few more Volts than what they are designed to deliver, add a few caps for electrical stability, and that’s it. In this case, we need one 7812 and one 7912 to get ±12V.

But I’m not so fond of power line transformers in my circuits, because you have to hook them up to AC mains on one side – that’s 230 VAC, needing lots of care to prevent accidents. Besides, we only need a few dozen milliamps for this Component Tester anyway.

So instead, I decided to use a DC-to-DC converter – a nifty little device which takes DC in and transforms it to another level of DC. The nice thing is that there are “dual” variants which can automate both positive and negative voltages at the same time.

I picked the Traco TMA0515D, which generates up to 30 mA @ ±15V, using just 5V as input. Its efficiency is specified as about 80%, so the 900 mW it supplies will need about 1.125W of input power. At 5V, that translates to 225 mA, well within range of a USB port – how convenient!

Here is the circuit I’ve built up:

JC s Grid page 20

As you can see, it uses very few components. And the output is galvanically isolated from the input supply – nice!

Such DC-DC converters are surprisingly small, at least for low-power units like this one (black block on the left):

DSC 3304

With a bit of forethought, almost everything can be connected together with its own wires:

DSC 3305

It worked as expected (caveat: the 78xx and 79xx pinouts are different!), but there were two small surprises:

the unloaded DC-DC converter output was about ±25V, these units are clearly not internally regulated!
the outputs from this assembled unit are indeed + and – 12V, but with some residual switching noise:

SCR13

That DC-DC converter appears to be based on a 100 KHz switching regulator (5 µs between on and off transitions), and these spikes are making it all the way to the output pins, straight through those linear regulators!

It probably won’t matter for a component tester operating at 50..1000 Hz, but this too should be fairly easy to fix – by inserting a couple of ferrite beads for example: small inductors which filter out such high frequency “spikes”.

With analog circuitry, stable and smooth power supplies tend to be a lot more important!

Solar top-up, full sun

In Hardware on Jun 9, 2012 at 00:01

Yesterday’s setup described a circuit with the JeeNode running on an AA Power Board and a little solar cell to top up the charge when there was sufficient light.

Since today was a warm day here with lots of sunlight, I thought it’d be nice to establish an outdoor baseline:

DSC 3302

From left to right (see how useful it is to have a whole bunch of multimeters?):

the voltage of the solar cell is 2.7V right now
the current supplied by it is 0.76 mA
the current drawn from the AA cell is 20 µA
IOW: less than an hour of sunlight is enough for a day

This is running the radioBlip2 sketch (including the recent survival tweaks), with the same modified JeeNode (no regulator, 100 µF cap) as used in many recent experiments here at JeeLabs.

Note that these values add up reasonably well:

the 2.7V from the solar cell ends up being distributed as follows: 0.65V forward drop over the 1N4148 diode, 0.75V voltage drop over the 1 kΩ resistor, and 1.3V over the (almost fully-charged) Eneloop
battery draw is 20 µA, and I’ve independently measured about 4.8 µA idle current draw from the JeeNode (i.e. w/o the MCP1702 regulator), so losses and efficiencies are actually quite good

Here’s the same setup in the shade (still bright sunlight outside) – sorry for the bad readouts:

DSC 3303

The cell voltage now drops to 2.0V and the current it supplies is down to ≈ 0.14 mA.

For comparison, some indoor charge currents from the solar cell:

near the white LED strips at my workbench: 60 µA
behind the window, but not in the sun: 80 µA
behind the window, in (modest) sunlight: 400 µA

With a Room Board attached and a permanent indoor setup, these figures will change, but it all looks promising!

Eneloop with solar top-up

In Hardware on Jun 8, 2012 at 00:01

Here’s another idea in the continuing search for long autonomous JeeNode run times:

JC s Grid page 19

The basic circuit is an Eneloop AA(A) cell, driving the AA Power Board to boost its voltage to 3.3V. There’s a 1 kΩ in series with the battery, as well as a Schottky diode to limit the voltage drop to about 0.3V during times “high” current consumption. I’ll explain why later on.

On the input side is a really simple circuit: a solar cell with a series diode, simply feeding the Eneloop battery when there is solar energy available.

The solar cell I’m using is that same 4.5V @ 1 mA cell I’ve been using all the time in my recent experiments. It is surprisingly good at generating some electricity indoor, even behind the coated double-glazing we have here.

The 1 kΩ resistor in series will let me measure the actual current flowing across it – 1 µA will read out as a 1 mV drop (that Ohm’s law again, of course!). So with a charging current of up to say 200 µA, this conveniently matches the 200 mV lowest range of most multimeters. And 0.2V is not a dramatic voltage drop, so the circuit should continue to work – almost the same as without those measurement resistors included.

A similar 1 kΩ resistor has also been inserted between the battery and the AA Power Board, but in this case we have to be more careful: a JeeNode will briefly pull 25 mA while in transmit mode, and the 1 kΩ resistor would effectively shut off input power with such currents. So I added a diode with minimal forward drop in parallel – it’ll interfere with my readings, but I’m really only interested in the ultra-low power consumption phases.

Here’s my “flying circus” concoction:

DSC 3301

I’ve added some wires to easily allow clipping various meters on.

Now, clearly, 4V is way over the 1.3V nominal of an Eneloop battery. But here’s why this setup should still work:

this solar cell is so feeble that its voltage will collapse when drawing more than a fraction of a milliamp
solar cells may be shorted out – doing so switches them from constant-voltage to constant current mode

As for the Eneloop, my assumption is that it doesn’t really care much about being overcharged at these very low power levels. In the worst case of continuous sunshine for days on end, it’ll be fed at most 1 mA, even when full. That will probably just lead to a tiny amount of internal heating.

So let’s try and predict how this will work out, in terms of battery lifetimes…

I’ll take a JeeNode + Room Board as reference point, which draws about 60 µA continuous, on average (50 µA for the PIR, which needs to remain always-on). That’s on the 3.3V side of the AA Power board. So with a (somewhat depleted) AA battery @ 1.1V, than means the battery would have to supply 180 µA with a perfect boost regulator.

Unfortunately, perfect boost regulators are a bit hard to get. The chip on the AA Power Board does reasonably well, with about 20 µA idle and about 60..70% conversion efficiency. Let’s just batch those together as 50% efficiency, then the continuous power draw for a Room Node would be about 360 µA. Let’s round that up to 400 µA.

An Eneloop AA battery has about 1900 mAh capacity, but it loses some energy due to self-discharge. The claim is that it retains 85% over 2 years, so this battery can effectively give us about 1600 mAh of power.

The outcome of this little exercise, is that we ought to get some 4000 hours run-time out of one fully-charged AA cell, i.e. 166 days, almost six months. Not bad, but a little lower than I would have liked to see.

If the solar cell were to generate 4 hours per day @ 0.5 mA, when averaged over an entire year (that might be optimistic), then that’s 4 x 365 x 0.5 = 730 mAh. That comes down to an average current of 83 µA.

IOW, roughly one fifth of the total power needs could be supplied by the solar cell. Not enough for total autonomy, but still, it’s a start. Note that most of these last figures were pulled out of thin air at this stage: I don’t know yet!

Yet another idea would be to add an extra diode from the solar cell straight to the JeeNode +3V pin. IOW, when there is sufficient sunlight, we off-load the boost circuit altogether and charge up a capacitor of say 100..1000 µF on the JeeNode itself. No more losses, other than the AA Power Board’s quiescent current consumption.

TK – Cheap power supply

In Hardware on Jun 7, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(I won’t call this a “lab power supply, for reasons explained below)

In a weblog post a while ago, I took apart a standard computer power supply unit (PSU). Now, instead, let’s do the opposite and turn it into a useful tool for experimentation with electrical circuits:

DSC 3330

What you see here is a neat little way to repurpose any standard ATX power supply. Just snip off most of the wires, except for that 20-pin connector, and assemble this neat little ATX adapter board by Benjamin Jordan:

DSC 3331

It’s available as a simple kit with a few basic components and all the connectors and binding posts.

The reason this is convenient is that it makes it somewhat easier to work with an ATX power supply (especially if it gets mounted on or near that power supply). There are push-buttons to toggle the supply on and off (except for the 5V standby voltage on the rightmost blue post, which is always on). There’s a LED to indicate whether the power supply is on (red) or in standby mode (green), and there’s an orange LED to indicate that power is OK.

All the main voltages are nicely arranged on binding posts, with matching ground return posts (all tied together internally), and there are holes to get to those same voltages via alligator clips – this is clearly for experimentation!

The is no high voltage anywhere, so the stuff is completely safe in terms of voltage. But there is still a risk:

DSC 3332

The currents available in most PC power supplies are phenomenal: 25 and 35 Amps on the 3.3V and 5V voltage rails, respectively. That’s what modern CPU’s and memory chips and all the supporting logic need, nowadays. The +12V supply is also pretty powerful, and normally used for all those terabyte disk drives people seem to be using.

This means that no matter how we touch it, it wont hurt us – anything under 40V is considered safe since our skin resistance prevents any serious amount of current flowing. But an electrical short circuit can (and will!) still easily vaporize thin copper traces on a low-power PCB. In other words: this is totally safe in terms of voltage, but the currents caused by shorts can generate sparks and enough heat to destroy components, wires, and PCB’s.

The above PCB itself is ok – its wide and thick gold-plated copper traces were designed to carry heavy currents.

What this means is that this setup is indeed a very cheap way to get lots of useful voltages for experimentation, but that it’s not the same thing as a “laboratory power supply” which also needs to have adjustable current limits.

Here are the voltages I measured coming out of this thing:

+5V standby, actual value, unloaded: 5.16 V
+3.3V, actual value, unloaded: 3.39 V
+5V, actual value, unloaded: 5.19 V
+12V, actual value, unloaded: 12.01 V
-12V, actual value, unloaded: -11.35 V

Close enough, and more importantly: most are slightly high. That means we could add very precise low-dropout regulators to get the voltages exactly right or we could add a current sensing circuit and limiter, to get that extra feature needed to turn this into a cheap yet beefy lab power supply.

TD – New Solid State Disk

In Hardware on Jun 5, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

After the recent server troubles (scroll down a bit), I had to replace one of the 500 GB Hitachi drives in the Mini.

I decided to switch to a 128 GB SSD for the system disk, with up to 6x faster transfer rates:

DSC 3233

It came with an interesting USB-to-SATA adapter included. Which looks like this inside:

DSC 3231

And on the bottom:

DSC 3232

(sorry: no teardown of the SSD, it’s probably just a bunch of black squares anyway!)

The scary part was replacing the disk in the Mac Mini’s “unibody” Aluminium case – as explained on YouTube.

But I definitely wanted to keep the server setup in a single enclosure. First lots of disk formatting, re-shuffling, and copying and then I just went ahead and did it. The good news: it worked. The system disk is now solid state!

DSC 3235

I had hoped that the most accessible drive would have to be replaced, but unfortunately it was the top one (when the Mini is placed on it feet) – so a full dismantling was required – look at all those custom-shaped parts:

DSC 3236

The other thing I did was to add an external 2 TB 2.5″ USB drive, to hold all Time Machine backups for both these server disks as well as two other Macs here at JeeLabs. This drive wil spin up once an hour, as TM does its thing.

Summary: the JeeLabs server now maintains a good up to date image of the entire system disk at all times, ready to switch to, and everything gets backed up to an external USB drive once an hour (these backups usually only take a minute or so, due to the way Time Machine works). All four VM’s get daily backups to the cloud, as well as now being included in Time Machine (Parallels takes care to avoid huge amounts of disk file copying).

That means all the essentials will be stored in at least three places. I think I can go back to the real work, at last.

There’s plenty of room for growth: 8 GB of RAM and less than half of the system disk space used so far.

Onwards!

Boost revisited

In Hardware on Jun 4, 2012 at 00:01

The AS1323 boost converter mentioned a while back claims an extra-ordinarily low 1.65 µA idle current when unloaded. At the time, I wasn’s able to actually verify that, so I’ve decided to dive in again:

Screen Shot 2012 05 17 at 15 28 15

A very simple circuit, but still quite awkard to test, due to its size:

DSC 3224

Bottom right is incoming power, bottom left is boosted 3.3V output voltage. Input voltage is 1.65V for easy math.

The good news is that it works, and it shows me an average current draw of 4.29 µA:

SCR03

The yellow line is the output voltags, with its characteristic boost-decay cycle. For reference: the top of the graph is at 3.45V, so the output voltage is roughly between 3.30 and 3.36V (it rises a bit with rising supply voltage).

The blue line is the voltage over a resistor inserted between supply ground and booster ground. I’m using 10 Ω, 100Ω, or 1 kΩ, depending on expected current draw (to avoid a large burden voltage). So this is the input current.

The red line is the accumulated current, but it’s not so important, since the scope also calculates the mean value.

Note that there’s some 50 Hz hum in the current measurement, and hence also in its integral (red line).

Aha! – and here’s the dirty little secret: the idle current is specified in terms of the output voltage, not the input voltage! So in case of a 1.65V -> 3.3V idle setup, you need to double the current (since we’re generating it from an input half as large as the 3.3V out), and you need to account for conversion losses!

IOW, for 100% efficiency, you’d expect 1.6 µA * (3.3V / 1.65V) = 3.2 µA idle current. Since the above shows an average current draw of 4.29 µA, this is about 75% efficient.

Not bad. But not that much better than the LTC3525 used on the AA Power Board, which was ≈ 20 µA, IIRC.

More worrying is the current draw when loaded with 10 µA, which is more similar to what a sleeping JeeNode would draw, with its wireless radio and some sensors attached:

SCR07

Couple of points to note, before we jump to conclusions: the boost regulator is now cycling at a bit higher frequency of 50 Hz. Also, I’ve dropped the incoming voltage to a more realistic 1.1V, i.e. 1/3rd of the output.

With a perfect circuit, this means the input current should be around 30 µA, but it ends up being about 52 µA, i.e. 57% efficiency. I have no idea why the efficiency is so low, would have expected about 70% from the datasheet.

Further tests with 1.65V in show that 1 µA out draws 6.72 µA, 10 µA out draws 29.6 µA, 100 µA out draws 261 µA, 1 mA out draws 2.51 mA, and 10 mA out draws 30.9 mA. Not quite the 80..90% efficiency from the datasheet.

My hunch is that the construction is affecting optimal operation, and that better component choices may need to be made – I just grabbed some SMD caps and a 10 µH SMD inductor I had lying around. More testing needed…

For maximum battery life, the one thing which really matters is the current draw while the JeeNode is asleep, since this is the state it spends most of its time in. So minimal consumption with 5..10 µA out is what I’m after.

To keep things in perspective: 50 µA average current drawn from one 2000 mAh AA cell should last over 4 years. A JeeNode with Room Board & PIR (drawing 50 µA, i.e. 200 µA from the battery) should still last almost a year.

Update – when revisiting the AA Power Board, I now see that it uses 25 µA from 1.1V with no load, and 59 µA with 10 µA load (down to 44 µA @ 1.5V in). The above circuit works (but does not start) down to 0.4V, whereas the AA Power Board works down to 0.7V – low voltages are not really that useful, since they increase the current draw and die quickly thereafter. Another difference is that the above circuit will work up to 2.3V (officially only 2.0V), and the AA Power Board up to at least 6V (which is out of spec), switching into step-down mode in this case.

Component Tester quality

In Hardware on Jun 3, 2012 at 00:01

Will all this effort to create a good sine wave for use as Component Tester, and all the testing on it, I might as well put the CT to the test which started it all, i.e. the one built into my Hameg HMO2024 oscilloscope.

Nothing easier than that – just hook up a probe to the signal it generates on the front panel, and do an FFT on it:

SCR89

(yeah, a green trace for a change – the other channels were tied up for another experiment…)

Ok, but not stellar: 1.6% harmonic distortion on the 3rd harmonic – more than with the Phase Shift Oscillator.

The frequency is also about 10% high, although that’s usually not so important for a Component Tester.

PS. The ∆L units should be “dB”, not “dBm” – Hameg says they’ll fix this oversight in the next firmware update.

TK – Multimeter accuracy

In Hardware on May 31, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Once you get into calibration stuff, it’s hard to stop. I recently bought this DMMCheck from voltagestandard.com:

DSC 3314

The nice thing about this unit is that it’s fully self-contained (with a 9V battery on the back) and that it has all the bits and pieces on board to check a multimeter’s (DC) voltage, (DC) current, and resistance measurements.

It comes with a calibration report – the voltage has been trimmed to exactly 5V, but the rest will have slightly different values due to component and temperature tolerances. Also, it was calibrated at 70°F (21.1°C):

DSC 3315

Here are my HP 34401A measurements, with only 15 minutes warm-up (it’s now about 23.5°C here at JeeLabs):

DSC 3316

DSC 3317

DSC 3319

DSC 3318

Very close – more than close enough to start checking the VC170 multimeter I described recently, for example:

DSC 3323

DSC 3322

DSC 3320

Easily within spec. Note that a VC170 only has 400 µA + 400 mA ranges, and 1 mA only shows 2 decimal points.

Here’s a higher-spec VC940, which I find unconvincing – I use it rarely anyway, due to its slow refresh rate:

DSC 3324

Here’s a very low end Extech MN15 – it performs worse than the VC170 and can only display values up to 1999:

DSC 3328 DSC 3325 DSC 3327

And finally, as flash from the past, a cheap analog multimeter – this one is probably over 30 years old:

DSC 3329

We’ve sure come a long way, from trying to guess the value while not mixing up all those scales!

This reaffirms my choice of using the VC170 for day-to-day use, with the high-end HP 34401A used for top accuracy and for long-running experiments (handheld multimeters always auto-shutdown much too quickly).

As you can see, the DMMCheck is an superb little tool to quickly do a sanity check of your multimeter(s). There’s now also a DMMCheck Plus with extra signals to check AC voltage + current, and even frequency + duty cycle.

If you take lots of measurements over the years, it’s well worth getting something like this to verify your DMM.

This all relates to a discipline called metrology (no, not “meteo”, but “metrics”) – i.e. the science of measurement.

Zero voltage diode

In Hardware on May 30, 2012 at 00:01

Two weeks ago, user @tmk commented on the weblog post about diodes with a pointer to a Zero Volt Diode.

Here’s the circuit, by Wilf Rigter:

200px NsmailCA

I couldn’t quite wrap my head around it, so I re-drew it in a different way – it’s still the same circuit:

JC s Grid page 15 copy

The key is that a MOSFET can switch a voltage with nearly no voltage drop, i.e. a signal on its gate can turn it from near-infinite to near-zero resistance. There’s no “bipolar junction” involved, therefore no 0.6V .. 0.8V threshold.

I’m not going to explain the circuit, but I’ve built it up and did some measurements to show its behavior:

DSC 3223

Since a supercap has all sorts of odd behavior w.r.t. deep discharge and such, I replaced it with a 6800 µF electrolytic cap for this experiment, in parallel with a 1 kΩ resistor to simulate a load of a few mA.

Instead of the solar panel, I’m using a 2.9V power supply, limited to supply at most 10 mA. In other words, when connected to the capacitor, it will reduce its voltage a bit while the charging current is high, and then end up as 2.9V once the capacitor has been fully charged up. This makes it similar to a solar cell with limited capacity.

Enough talking. Let’s see how this thing behaves, while tracking a number of voltage levels at the same time:

SCR70

There’s a lot to describe here:

the RED line is the voltage from the power supply, i.e. Vsolar
the YELLOW line is the voltage over the capacitor, i.e. Vcc
the GREEN line is the voltage between drain and source of the MOSFET
the BLUE line is the voltage on the gate of the MOSFET
all signals have their zero origin at 2 divisions from the bottom
power was turned on after 2 seconds from the left edge of the screen
power was turned off again about 5 seconds later

The RED line is actually the YELLOW line minus the GREEN line.

The first thing to note is really the whole point of this circuit: the voltage on the capacitor (YELLOW) rises up to 2.84V, while the input voltage (RED) reaches 2.90V, so there’s only a 0.06V voltage drop over that FET while it conducts. That’s a ten-fold improvement over a silicon diode, and three-fold over a Schottky diode.

I’m using a BC557 for the PNP transistor, a BC549 for the NPN transistor, and a VN2222 as MOSFET, just because I happened to have those lying around. That MOSFET in particular is not a great fit here, really.

The other peculiar thing about this circuit, is that the MOSFET is used for current flowing through it in the wrong direction, from drain to source! But most MOSFETs won’t mind, they really act a bit like (controllable) resistors.

The most interesting bit is the GREEN signal, i.e. the voltage over the MOSFET. At input levels under about 1.5V it does conduct, but with a substantial voltage drop – first from the built-in diode conducting, and then gradually the MOSFET turns on and its low resistance takes over, with a total voltage drop of some 30..60 mV.

When the input voltage is completely switched off, the MOSFET goes into high impedance mode within a fraction of a second, which can be deduced from the fact that the GREEN and YELLOW lines meet up and overlap.

Lastly, once the voltages drop below about 0.4V, the gate voltage on the MOSFET rises a bit, but this is not enough to turn it on, and also not very important since the whole circuit is now essentially “dead”.

Here’s the second event in greater detail, i.e. when the input voltage drops – or in this case, gets switched off:

SCR71

The MOSFET is switched off within milliseconds, with the cap now holding a higher voltage than the input.

The result of it all is that the capacitor soaks up almost all the voltage it can get, with no diode forward voltage drop involved. When the input voltage drops, the circuit disconnects it from the cap so it’ll retain its charge. Brilliant!

Update – Wanted to get a bit more info on-screen, so here’s another scope capture (oops, green is now yellow):

SCR16

It better displays the elegant “swirly” charge ramp, with an odd little 64 mV bump on the MOSFET when the cap is full (maybe that’s the power supply switching to constant voltage mode). Given that the cap voltage reaches 2.82V and is loaded down by a 1 kΩ resistor, we can deduce that the current through the MOSFET must be 2.82 mA at that point, and therefore that its resistance is 23 Ω in this circuit (64.57 mV / 2.82 mA, Ohm’s law again!).

It’s about survival

In AVR, Hardware, Software on May 29, 2012 at 00:01

When running off solar power, ya’ gotta deal with lack of (sun-) light…

As shown in a recent post, a 0.47F supercap appears to have enough energy storage to get through the night, at least when assuming that the day before was sunny and that the nights are not too long.

There are still a couple of issues to solve. One which I won’t go into yet, is that the current approach won’t start up properly when there is only a marginal power budget to begin with. That’s a hard problem – some other time!

But another tactic to alleviate this problem, is to try and sail through a low-power situation by reducing power consumption until (hopefully) more energy becomes available again, later on.

Here’s my first cut at implementing a “survival strategy”, using the radioBlip2 sketch:

Screen Shot 2012 05 15 at 14 00 12

It’s all in the comments, really: when power is low, try to avoid sending packets, since turning on the transmitter is by far the biggest power “hog”. And when power is really low, don’t even measure VCC – just slow down even more in maximally efficient sleep mode – I’ve set the times to 5 and 60 minutes. The 1-hour sleep being a last effort to get through a really rough night…

But I’ve also added some kamikaze logic: when running low, you don’t just want the sketch to go into sleep mode more and more and finally give up without having given any sign of life. So instead, when the sketch is about to decide whether it should send a packet again, it checks whether the voltage is really way too low after what was supposedly a long deep-sleep period. If so, and before power runs out completely, it will try to send out a packet anyway, in the knowledge that this might well be its last good deed. That way, the central node might have a chance to hear this final swan song…

The thresholds are just a first guess. Maybe there are better values, and maybe there is a better way to deal with the final just-about-to-die situation. But for now, I’ll just try this and see how it goes.

One last point worth mentioning: all the nodes running this sketch can use the same group and node ID, because they are transmit-only. There is never a need to address packets sent towards them. So the BLIP_ID inside the payload is a way to still disambiguate incoming packets and understand which exact node each one came from.

Re-using the same node ID is useful in larger setups, since the total number of IDs in a group is limited to 30.

I’ll do some tests with the above logic. Let’s hope this will keep nodes alive in long and dark winter ~~days~~ nights.

Re-thinking solar options

In AVR, Hardware, Musings on May 28, 2012 at 00:01

So will it ever be possible to run a JeeNode or JeeNode Micro off solar power?

Well, that depends on many things, really. First of all, it’s good to keep in mind that all the low-power techniques being refined right now also apply to battery consumption. If a 3x AA pack ends up running 5 or even 10 years without replacement, then one could ask whether far more elaborate schemes to try and get that supercap or mini-lithium cell to work are really worth the effort.

One fairly practical option would be a single rechargeable EneLoop AA battery, plus a really low-power boost circuit (perhaps I need to revisit this one again). The idea would be to just focus on ultra-low power consumption, and move the task of charging to a more central place. After all, once the solar panels on the roof of JeeLabs get installed (probably this summer), I might as well plug the charger into AC mains here and recharge those EneLoop batteries that way!

Another consideration is durability: if supercaps only last a few months before their capacity starts to drop, then what’s the point? Likewise, the 3.4 mAh Lithium cell I’ve been playing with is rated at “1000 cycles, draining no more than 10% of the capacity”. With luck, that would be about three years before the unit needs to be replaced. But again – if some sort of periodic replacement is involved anyway, then why even bother generating energy at the remote node?

I’m not giving up yet. My KS300 weather station (868 MHz OOK, FS20’ish protocol) has been running for over 3 years now, I’ve never replaced the 3x AA batteries it came with – here’s the last readout, a few hours ago:

     :41   KS300 ookRelay2 humi             77
     :41   KS300 ookRelay2 rain             469
     :41   KS300 ookRelay2 rnow             0
     :41   KS300 ookRelay2 temp             18.2
     :41   KS300 ookRelay2 wind             0

And the original radioBlip node is also running just fine after 631 days:

    1:32   RF12-868.5.3 radioBlip age       631
    1:32   RF12-868.5.3 radioBlip ping      852330

Even the JeeNode Micro running on a CR2023 coin cell is still going strong after 4 months:

    1:42   RF12-868.5.18 radioBlip age      139
    1:42   RF12-868.5.18 radioBlip ping     188449

So ultra-low power is definitely doable, even with an Arduino-compatible design.

No worries – I’ll keep pushing this in various directions, even if just for the heck of it…

Reverse diode current

In Hardware on May 27, 2012 at 00:01

After measuring the forward voltage drop over a diode, I should also have measured the reverse leakage current, i.e. how much current the diode lets through when it’s supposed to be blocking. I never did until now, because I couldn’t detect any current in a quick check I did a while back. Time to build a better setup – here’s what I used:

JC s Grid page 17

The voltmeter’s own 10 MΩ or so internal resistance will skew the readings by 10%, but that’s no big deal.

It turns out that the reverse leakage current is pretty small when applying 5V:

1N4004 – a high power diode: 1.3 mV = 1.3 nA
1N4148 – a low power diode: 3.4 mV = 3.4 nA
BAT34 – a Schottky diode: 50 mV = 50 nA

That’s nanoamps, i.e. milli-milli-milli-amps. The Schottky diode does indeed leak a tad more than the others. Here are the specs of that BAT34 diode – note that the reverse current could even be used as temperature sensor!

Screen Shot 2012 05 14 at 17 15 55

FWIW, I found a minuscule “RB751S” SMD Schottky diode, about 1 mm long, which does a bit better at 7.0 nA:

DSC 3221

It was quite a challenge to get some wires soldered onto it. I used the core of 30 AWG Kynar “wirewrap” wire:

DSC 3222

Anyway – the BAT34 is good enough: 50 nA leakage is acceptable while dealing with circuits which consume µA’s.

Through the night on a supercap!

In Hardware on May 26, 2012 at 00:01

Yeay! – The JeeNode made it through the night on a 0.47F supercap, for the first time ever at JeeLabs:

Screen Shot 2012 05 15 at 10 59 19

Sorry for the awkward / missing scale, here’s some context:

vertical is voltage: 50 = 2V, 100 = 3V, 150 = 4V, 200 = 5V
blue is VCC before sending, green is VCC after sending
graph runs from 11:45 yesterday to 10:45 the next morning, i.e. 23 hours
that’s two VCC measurements and one packet transmission every minute

The supercap had been charged by the solar cell for 3 days, no load. When connecting the JeeNode (BOD set to 1.8V, on-board 100 µF i.s.o. regulator, already running), I placed it in a cardboard box to block out the light:

the first upward blip is at 12:45, during 5 minutes of exposure to sunlight
then back into the box until 18:30, depleting the supercap for a few hours
after that, the node was kept in the light to try and charge up enough for the night
at 20:00, the charge had gone up to 4.42V and 3.86V, respectively
at around 6:30 the next morning, the lowest point was reached: 3.44V and 2.88V
from then on, the cell started charging again from the morning light (no direct sunlight yet)
looks like about 10% of the packets never arrived (probably mostly due to collisions)

At noon, the cap voltage had risen to 4.9V (note that the RFM12B is now operating above its official 3.8V max).

So there you have it: one packet per minute powered by solar energy, harvested indoor near a window.

Update – FWIW, this setup lasted a second day, but then it died again… we’re not done yet!

Different op-amps

In Hardware on May 25, 2012 at 00:01

One last experiment I wanted to do after the recent sine wave circuits, was to compare a few different op-amps.

I’m including the original one here as well – the LM358, running at ±13.6V:

SCR64

Here’s the LT1413, running at ±14.4V:

SCR65

And here’s the NE5532ANG, running at ±15.3V:

SCR66

In each case, the supply voltage was adjusted until the output sine wave was ±10 V, with all other components identical. Note the slight difference in oscillation frequency.

What’s also interesting, is the mean output voltage: it should be 0V with an ideal circuit. Looks like the NE5532ANG performs best – within 1%. It’s described as being an “Internally Compensated Dual Low Noise Operational Amplifier”. Second harmonic is at -51 dBm, i.e. 0.28% harmonic distortion – an excellent signal!

As a quick test with that last op-amp, I reduced the supply voltage to ±2.5V – the effect was a slightly higher frequency of 522 Hz, a much lower output of 2.14 Vpp, i.e. ±1.07V, but relatively far off-center: 240 mV. Harmonic distortion rises to 3.5% in this case. But that’s not surprising: the NE5532ANG is only specified down to ±3V, and it’s not a “rail-to-rail” op-amp, which means it cannot generate an output voltage too close to its supply voltage (with a ±5V supply, distortion drops back to 1.25%).

Lots of op-amps. Lots of trade-offs.

Ok enough op-amp chit-chat for now, I’ll stop :)

Toolkit, Analog

TK – Frequency Meter

In Hardware on May 24, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Another post about frequencies – this time I’ve assembled a DFD4A from Almost All Digital Electronics:

DSC 3124

It’s a low-cost frequency counter which goes all the way up to 3 GHz. Here it’s measuring a 10 MHz signal from my Frequency Generator, while synchronized to the Rubidium frequency standard.

As you can see, it’s spot on – the last digit flips between 0 and 1 every so often, that’s all.

As with the Capacitance Meter I assembled recently, this kit comes with detailed build instructions. Except that this time I didn’t really want to build it, so I got the pre-built version instead, including the connectors and (fully) plastic enclosure. The front plate already has all the right cutouts, and a printed piece of paper (!) glued to the front. Works ok, but I suspect that it’ll get dirty over time.

The unit came with all the parts, I just had to solder a few components and wires in place after inserting all the switches and BNC connectors.

One thing missing was the 9V battery clip – but not to worry, I have a couple of those lying around anyway.

The reason to get this particular unit was its high frequency range of well over the 868 MHz and 2.4 GHz frequencies I may want to measure here at JeeLabs. The main difference with a professional unit is probably the fact that it doesn’t have many input signal options:

HF measures from 0 to 30 MHz, with 5 Vpp max into a high impedance input
UHF measures from 10 to 3000 MHz over a 50 Ω input (max 15 dBm)

No way to directly measure the 868 MHz output from an RFM12B, I suspect – i.e. it probably won’t be sensitive enough to measure 0 dBm.

The slow measurement mode continuously collects data for one second, so you get 1 Hz resolution on the HF range and 100 Hz resolution on the UHF range (since that’s essentially just a ÷ 100 prescaler).

The fast measurement mode runs 10 times per second, i.e. a gate time of 0.1s – so this gives 10 Hz resolution on HF and 1000 Hz (1 KHz) resolution on UHF.

It’s a bit odd that the display shows more significant digits than are being measured in all but FAST + HF mode, but no big deal – the current mode is clearly visible from the switch settings.

Knowing that the counter is very accurate (for now – it’ll no doubt gradually drift slightly), it’s time to find out how accurate the TG2511 AWG’s frequency is when not synchronized to the Rubidium standard:

DSC 3125

That’s only 0.4 ppm off and well within spec – excellent!

TD – LED flashlight

In Hardware, News on May 22, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode will be a short one, it’ll become clear why halfway down this page…

This is a little bargain LED flashlight, nothing to it really:

DSC 3228

Three AAA (not AA) cells, a toggle button, 24 + 4 white LEDs, and that’s it. Press the button once, and the 4 LEDs on the side turn on, press again to light the 24 on the top, and again to turn it off.

Quite a bright light BTW. The 4 LEDs draw 190 mA, with 16 it rises to 270 mA. That’s perhaps 4 hours of use with 16 LEDs before the batteries run out.

The circuit is as ridiculously simple as can be – one 4.7 Ω resistor and a switch:

DSC 3229

That “metal” reflector is actually plastic with a chrome finish. The PCB is one-sided, no doubt to lower the cost:

DSC 3230

(it won’t take much bending to create a short with that top wire!)

Using Ohm’s law (V = I x R), we can deduce that the LED’s forward voltage is 4.5 – X = 0.190 x 4.7 – in other words, X = 4.5 – 0.190 x 4.7 = 3.6V. Note that the light intensity will vary considerably with battery voltage and that this lamp won’t work at all with 3 AAA EneLoop batteries which only supply 1.2V to 1.3V when fully charged.

The reason I’m opening up this trivial little gadget is not to marvel at the deep electronic engineering that went into it, but to show how custom plastics and a custom case makes something quite practical and nice to the touch. The top and bottom have a rubbery feel to them. The bottom has a little plastic hook in it, which can be folded out.

The bigger news today is a bit of a mess, unfortunately.

Last night I decided to upgrade the JeeLabs server from Mac OSX 10.7.3 to 10.7.4 – that update had been out for a few days, worked fine on two other machines here, so it seemed safe to apply the update to the server as well.

It failed.

This server is connected via wired Ethernet, and I usually only look at the GUI via a VNC-like “Screen Sharing” mechanism built into Mac OSX. It works well, because that connection is re-established even when the machine is in an exclusive “Updating…” mode, so you get to track progress even while the system is busy replacing some of its own bits and pieces. No screen needed, even though part of admin interface sometimes uses the GUI.

Last night, the server failed to come back online. Which is a major hassle, because then I have to move it to another spot to hook up a mouse, keyboard, and monitor to see what’s going on. Never happened before.

Trouble is (probably), that I turned the darn thing off forcefully. I knew that all the VM’s had been properly shut down, and I heard the characteristic reboot “pling”, so I thought it was waiting for a GUI response… or something.

Then the trouble started. Hooked it up, did a restart: no go. So I restarted it in recovery mode, and did a disk check/repair of all the disks. Guess what: the startup disk with all VM’s could not be repaired… whoops!

Time to kick my backup strategy in gear. I have two in place: local hourly Time Machine backups to a second drive, and daily backups for all VM’s to the cloud.

To make a very long ~~night~~ story short: the local hourly backups are fine, but they do not include the VM’s (whole-file backups of a VM disk every hour is not really practical). And the daily backups? Well, they are indeed all there – I can get any day in the past 3 months back, for any of the 4 VM’s. Awesome.

But Turnkey Linux does things a bit differently. Very clever in fact: it only backs up the minimum. The Linux Debian packages for example: these are not backed up, but re-installed from some other source. The rest is a well thought-out mix of full and incremental backups, and it all works just as expected.

Except that my VM’s are about two years old now, and no longer the latest base images used by Turnkey Linux. No problem, they say: you can get the latest, and then recover your own stuff on top of that.

So I spent about 6 hours trying to work out how to get my VM’s back up from the Amazon S3 storage. No joy. I can see all the files being restored, but the result is not a working VM. At some point, package installs & updates hang, with either udev restart problems or bootdisk image generation problems.

And now the crazy bit: the JeeLabs weblog + forum + café sites are all back up again (phew!). I restored from Time Machine to a freshly freed disk partition, and restarted the Mac – it’s alive! Right now, the server is running from the new disk partition, but with the 4 VM disk images still on the damaged partition. So apparently they did not get any damage, although the Mac file system structure on that disk seems to be hosed.

I’ll spend some time thinking about how to clean up this mess, and how to avoid it in the future. The good news is that I lost no data – just a lot of time and some hair. Yikes … this really was uncomfortably close to the edge!

The moral: test the backup strategy regularly. It can still break, even when not changing anything!

Update – All systems are “go” again.

Update 2 – Final diagnosis: one of the 2 internal disks was getting too hot, leading to intermittent failure, so it was hardware after all – unrelated to the 10.7.4 software. And it was probably all my fault, because I placed a (fairly warm) router on top of the Mac Mini. I’m going to replace the failed system drive with with an SSD.

Producing a beefier signal

In Hardware on May 21, 2012 at 00:01

Let’s move on, now that we have a clean sine wave. The goal is to produce a ±10V sine wave to use for constructing a Component Tester. The sine wave produced so far was merely ±65 mV.

I re-used the same circuit as yesterday, but with slightly different settings. First of all, I replaced the op-amp by an LM358, which can handle higher voltages. Next, I halved all the R’s to 5 kΩ and doubled all the C’s to 0.2 µF. This reduces the loading of the feedback loop – it shouldn’t really affect the frequency.

To increase the output voltage, I connected the oscillator output signal to a non-inverting op-amp circuit:

Screen Shot 2012 05 13 at 18 04 33

In a nutshell: this circuit tries to keep Ve as close to zero as possible at all times. IOW, the op-amp will constantly adjust its output so that the tap on the Rf:Rg voltage divider tracks the Vin voltage on the “+” input pin.

Using Rf = 10 kΩ, and Rg = 470 Ω, its gain will be about 22x. The nice property of this circuit is that it has a very high input impedance, so there is virtually no current draw from the oscillator.

And sure enough, the output of this op-amp is a sine wave with many volts of output swing. Now it’s simply a matter of cranking up the supply voltages to ±13.6V and bingo, a ±10V sine wave:

SCR64

Very clean. Better even than the original circuit – the 2nd harmonic is now -49 dB w.r.t. to the base frequency. That’s just 0.35% of harmonic distortion – excellent!

That second op-amp came for free, since an LM358 DIP-8 package has two of them anyway. So the first op-amp is oscillating (at about 470 Hz) and the second op-amp brings the output level to ±10V.

It’s quite a mess on the mini-breadboard I used, but who cares – that’s what prototypes are for:

DSC 3215

One last check is needed to make sure that the LM358 is suitable. A component tester measures the effects of an unknown component in series with a 1 kΩ resistor. So in the worst case, with a simple wire as “unknown component”, the maximum current through that resistor will be ±10 mA. Luckily, according to the specs, an LM358 can supply at least 10 mA, and typically up to 20 mA on its output.

So that’s it: our Component Tester will need a ±13.6V supply, an LM358, and a few R’s and C’s. That supply voltage is not critical, as long as it’s stable – the output level could be adjusted to ±10V via a trimpot.

Welcome to the world of analog electronics!

A better sine wave

In Hardware on May 20, 2012 at 00:01

After the pretty bad sine wave trial of the last two days, it’s time to try another circuit:

Screen Shot 2012 05 13 at 15 55 30

This is a “Phase Shift Oscillator” from the same op-amp book as the other one. I used half a TLV2472.

This one is actually a bit simpler to explain: the op-amp is set up with 25..50x amplification, i.e almost a comparator (with 50x amplification, a 50 mV input above or below the 2.5V will drive the output to its limit). And indeed, the output signal of the op-amp looks somewhat like a heavily clipped sine wave:

SCR59

The 3 resistors and 3 capacitors create 3 RC “low-pass” filters in series, removing all the higher frequencies, i.e. harmonics. A fairly clean sine wave comes out at the end, as you can see here:

SCR58

The only problem is that the signal level has been reduced from a ±2.5 V level to ≈ ±65 mV, a 40-fold reduction!

So the op-amp itself has to amplify that level back up to produce the clipped ±2.5V signal again.

The frequency is determined by “phase shifts”. Each RC filter changes the phase of its input signal, and it will be by 60° at a certain frequency, so that 3 of them in series will then shift it by 180°. Since the signal is fed back to the “-” pin of the op-amp, that’s exactly the proper signal to generate the opposite output, i.e. shifted 180° out of 360°. This analog stuff gets complicated – don’t worry too much about it: just pick R and C values to get the right frequency, and make all of them the same.

I used 0.1 µF caps i.s.o. 10 nF caps, i.e. 10x larger than the original circuit. With these values, the oscillation in my setup turned out to occur at just about 440 Hz, i.e. a pure musical “A” tone!

I did have to increase the gain (1.5 MΩ / 55.2 kΩ = 27 in the above setup) to force oscillation. I changed RF to 1 MΩ and RG to 22 kΩ, for a gain of 47. This RG value is a bit low, it loads down the last RC section quite a bit.

What you’re seeing here is a classical example of a negative feedback loop, which ends up in a very stable state of oscillation. It oscillates because we’re delaying the feedback signal by about 2.27 ms through the RC chain. So the op-amp constantly overshoots around its mid-point (the 2.5V applied to the “+” input), but does so in a very controlled way. The amplitude can’t increase any further, since the op-amp is clipping at its limits already, and the amplification factor is large enough to keep boosting the swing up to that limit. You can see the startup ramp and stabilization when powering up:

SCR61

Here’s the FFT spectrum analysis of the generated sine wave:

SCR60

A clean signal compared to the previous experiment. The 2nd harmonic is ≈ 42 dB below the fundamental wave, the rest is even lower. Using this calculator, we can see that this represents about 0.8% harmonic distortion.

The only issue is that the signal is much weaker than the ±10V needed for a standard Component Tester.

But hey, let’s declare success for now – we’ve got a clean sine wave!

▶ View 22 Comments

Generating a sine wave – part 2

In Hardware on May 19, 2012 at 00:01

After yesterday’s failed attempt to generate a clean since wave, I started experimenting a bit further. How could the Op-amp book be so wrong about the quadrature oscillator circuit?

The nice thing about op-amps in DIP-8 packages, is that most of them use the same pinout, so it’s very easy to swap them out and test different brands and types. The TLV2472 only supports up to 6V as power supply, most of the other ones go much higher – usually above 30V, i.e. ±15V.

Here’s the list of op-amp chips I tried (yeah, got quite a bunch of them in my lab, for various reasons):

TLV2474
LM358N
LM833N
NE5532ANG
OP2340
NJM14558D
MCP6023
LT1413

All of them had similar behavior, i.e. clipping at both limits of the voltage range, except for the LT1413:

SCR56

Still nowhere near a sine wave, BTW. But what’s more interesting, is the the voltage swing of this signal was just 4.5 Vpp, while the op-amp was being driven from a ±15V power supply in this particular case. So for some reason, it was “oscillating” at 1.25 KHz (about 8x higher than the other mode).

I have no idea what was going on. When trying to reproduce this a second time, I couldn’t get this behavior back. I suspect a loose connection, or perhaps some odd interaction due to the breadboard.

I’m not really interested in tracking down this issue, since it looks like this quadrature oscillator circuit is not suitable for a Component Tester – not without some sort of amplitude regulation anyway.

So there you have it – analog circuits also need to be debugged, as you can see!

Update – this issue has now been resolved, see the comments on yesterday’s weblog post.

Generating a sine wave

In Hardware on May 18, 2012 at 00:01

After the recent pretty disappointing results with a transformer-based Component Tester, I’d like to try and generate a ± 10 V sine wave at approximately 50 Hz in some other way. Using as few components as possible.

This is where we enter, eh, squarely into the analog electronics domain. Yes, we could generate it with an ATmega, but frankly that sounds like a bit of overkill, would require a fair amount of filtering to remove residual switching effects, and besides we’d still have to amplify it up to 10 Vpp.

Time to introduce some new circuitry!

One of the most incredible electronic building blocks invented in the second world-war era was the Operational Amplifier, or “op-amp” in short.

There’s way too much to say about this amazingly universal circuit, which even has its own schematic symbol:

180px Op amp symbol svg

A positive and negative power supply pin, a positive and a negative input, and an output pin. That’s it.

I’ve only just started exploring op-amps, really – one superb resource on the web comes in the form of a free eBook from 2002 on the Texas Instruments site, titled “Op Amps For Everyone”, by Ron Mancini.

In his chapter on Sine Wave Oscillator, he mentions a “Quadrature Oscillator” built from two op-amps:

Screen Shot 2012 04 18 at 01 08 17

It uses very few components. This one was dimensioned for about 1.6 KHz, so I started with capacitors ten times as large, i.e. 0.1 µF, to lower the oscillation frequency. Here’s the result, using a TLV2472 dual op-amp:

DSC 3056

SCR53

Yeah, right. Clipping like crazy, i.e. overshooting into the limiting 0V and 5V power lines. The FFT shows it’s not anywhere near a pure sine wave, even though the shape vaguely resembles one:

SCR54

A pure sine wave would have a single peak at the oscillating frequency.

Here’s the cosine output, again showing that it’s running way outside its linear range:

SCR52

So yeah, we’re generating a 160 Hz signal, but it’s no sine wave and it would be useless as Component Tester.

Oh well, it was still an interesting first trial!

TK – Frequency accuracy

In Hardware on May 17, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is again a bit of a side excursion, about checking the quality of a measuring instrument)

I recently visited a friend who had to get his frequency meter’s calibration verified to a fairly high precision. Thinking of the Rubidium clock I got from eBay, he came up with the idea of using a transfer standard.

The thing with accuracy, is that you have to have an absolute reference to compare against. One option is to go to a “calibration lab” and have them test, adjust, and certify that your instrument has a certain accuracy. Awkward, expensive, and usually a bit over the top for “simple” hobby uses.

So the other way to do things, is to “transfer” the calibration in some way. Buy or build a device which can keep the desired property stable, calibrate it to some standard, move it to where the instrument needing calibration is located, and compare the two. Or vice versa: match to instrument, then compare with a standard.

The latter is exactly what we ended up doing. First we created a little Arduino daughter board with a “VC-TCXO” on it: that’s a “Temperature Compensated Xtal Oscillator” which can be fine-tuned through a voltage. Here’s the setup, created and built by Rohan Judd:

DSC 3082

On the left, an SPI-controlled digital potmeter, on the right a VC-TCXO running at 10 MHz.

Via a sketch, the VC-TCXO was fine-tuned to produce exactly 10.000,000 MHz readout on the frequency counter we wanted to verify. This was done at about 18°C, but a quick test showed that this VC-TCXO was indeed accurately keeping its frequency, even when cooled down by more than 10°C.

I took this device back home with me, and set up my frequency generator to use the Rubidium clock as reference. So now I had two devices on my workbench at JeeLabs, both claiming to run at 10 MHz …

Evidently, they are bound to differ to some degree – the question was simply: by how much?

Remember Lissajous? By hooking up both signals to the oscilloscope, you can compare them in X-Y mode:

SCR26

Channel 1 (yellow) is the VC-TCXO signal, some sort of odd square wave – I didn’t pay any attention to proper HF wiring. Channel 2 (blue) is the sine wave generated by the frequency generator.

The resulting image is a bit messy, but the key is that when both frequencies match up exactly, then that image will stay the same. If they differ, then it will appear to rotate in 3D. It’s very easy to observe.

The last trick needed to make this work is simply to adjust the frequency generator until the image does indeed stop rotating. This is extra-ordinarily sensitive – the hard part is actually first finding the approximate setting!

After a bit of searching and tweaking, and after having let everything warm up for over an hour, I got this:

DSC 3080

IOW, the frequency I transferred back to JeeLabs with me was 9.999,999,963 MHz. We’re done!

To put it all into perspective: that highlighted digit is 0.1 ppb (billion!). So the frequency counter appears to be 3.7 ppb slow. Assuming that the transfer standard did not lose accuracy during the trip, and that my Rubidium clock is 100% accurate. Which it isn’t of course, but since its frequency is based on atomic resonance properties, I’m pretty confident that it’s indeed accurate to more than 0.1 ppb.

The real story here, though, is that such breath-taking accuracy is now within reach of any hobbyist!

First solar results

In AVR, Hardware on May 16, 2012 at 00:01

Some first results from trying to run a JeeNode off a 24 x 32 mm indoor solar cell…

In each of the cases described below, I’m using a JeeNode without regulator and with 100 µF cap hooked up, with fuses and settings as described in this post. The cap should have enough energy to cushion the dip from a small packet transmission. I’m using the latest radioBlip2 sketch, which now sends out the following 7-byte payload:

Screen Shot 2012 05 14 at 13 33 17

The benefit of this version, is that the sketch reports not just the battery level but also how far the battery level drops after sending out a packet once a minute. That value is sent out in the next packet, so it always lags.

To get started, I connect the JeeNode to a BUB, which charges the 100 µF cap to 5V (and runs the RFM12B slightly above spec). Then I disconnect and hook it up to the solar setup. This way I don’t have to deal with startup problems yet – which is an entirely different (and tricky) problem.

Yesterday’s elaborate setup didn’t get very far, unfortunately. Two different runs gave me just a few packets:

    L 09:16:01.571 usb-A600dVPp OK 17 1 0 0 0 1 209 0
    L 09:18:07.445 usb-A600dVPp OK 17 3 0 0 0 1 86 51
    L 09:19:10.308 usb-A600dVPp OK 17 4 0 0 0 1 86 50

    L 09:24:12.477 usb-A600dVPp OK 17 1 0 0 0 1 206 0
    L 09:25:15.707 usb-A600dVPp OK 17 2 0 0 0 1 86 210

Values are 20 mV steps, offset by 1V – the actual battery voltage is: 1 + 0.02 * X (where X is the reported value).

In the above runs, the battery is 86 (2.72V) before sending, and 50 (2.00V) after. That’s pretty close to the edge, I’m not sure why the drop is so large.

Another test with a 0.47 Farad supercap, charged for about 3 days to get the charge “deep” into the supercap, seems to fare a little better:

    L 09:43:06.943 usb-A600dVPp OK 17 19 0 0 0 1 210 52
    L 09:44:10.771 usb-A600dVPp OK 17 20 0 0 0 1 175 210
    L 09:45:14.549 usb-A600dVPp OK 17 21 0 0 0 1 175 146
    L 09:46:18.339 usb-A600dVPp OK 17 22 0 0 0 1 175 147
    L 09:47:22.100 usb-A600dVPp OK 17 23 0 0 0 1 175 147
    ...

That’s 4.50V and 3.94V before and after transmission, respectively. But a 0.47F supercap has a lot less energy in it than that 3.4 mAh Lithium cell used in the first tests above, so it’ll probably run down a lot faster.

After one hour, voltages drop to 4.28V and 3.72V. Two hours: 4.14V and 3.60V. Five hours: 3.92V and 3.36V. I’m not sure this will work, unless the node sends less at night perhaps or always restarts reliably the next day.

To be continued…

New solar setup

In Hardware on May 15, 2012 at 00:01

Time for another experiment, this time combining my small solar panel with the 3.4 mAh Lithium battery which seems to work so well. The circuit I’m going to try is as follows:

JC s Grid page 16

Here’s the construction, cozily attached to the back of the solar cell:

DSC 3128

Same solar cell, I think it can supply up to 4.5V @ 1 mA in full sunlight.

The tricky bit is that the rechargable lithium cell needs to be treated with care. For maximum life, it needs to be hooked up to a voltage source between 2.8V and 3.2V, and the charge current has to be limited.

Note that the 1 kΩ resistor is put in series with the battery not only to charge it, but also when taking charge out of it. Seems odd, but that’s the way the datasheet and examples show it. Then again, with a 10 µA current draw the voltage drop and losses are only about 10 mV. A diode bypass could be added later, if necessary.

The diode after the regulator has the nice effect of dropping the 3.3V output to an appropriate value, as well as blocking all reverse current flow. There is no further circuitry for the regulator, since I don’t really care what it does when there is too much or too little power coming from the solar cell. Let’s assume it’s stable without caps.

It all looks a bit wasteful, i.e. linearly regulating the incoming voltage straight down to 3.3V regardless of PV output levels and discarding the excess. But given that this little 3V @ 3.4 mAH battery has already supported a few days of running time when fully charged, maybe it’s still ok.

I’ll let this charge for a day or two.

Forward voltage drop on a diode

In Hardware on May 14, 2012 at 00:01

With all this tinkering with solar panels, little batteries, supercaps, etc, you often need to prevent current from leaking away. The usual approach is to insert a diode into the circuit.

Diodes conduct current in one direction and block the current in the opposite direction.

Well, that’s the theory anaway. In real life, diodes only conduct current once the voltage is above a certain level, and they tend to leak minute amounts of current when blocking the reverse voltage.

For ultra-low power use and the low voltage levels involved, you need to be careful about the type of diode used. A regular 1N4148 silicon diode has a forward drop of about 0.65V, quite a bit when supplies are 2..3V!

The Schottky diode has a much lower voltage drop. It’s usually specified as 0.3..0.4V, but it really depends on the amount of current passed through it.

To see the properties of the BAT43 Schottky diode I’ve been using, I created this simple test setup:

JC s Grid page 18

A 10 Hz “sawtooth” voltage is used to create a signal rising from -3V to +3V in a linear fashion, 10 times a second. This means that the current through the 100 kΩ resistor will go from -30 µA to +30 µA. We can then watch the voltage over the diode, and how it goes from a blocking to a conducting state:

SCR45

The yellow trace is the sawtooth signal applied to the circuit. The blue trace is the voltage over the diode. Note the difference in vertical scale.

You can see that with negative voltages, the diode just blocks. As it should. With positive voltages up to 1.2V, i.e. a current up to 12 µA, the voltage drop over the diode is under 0.15V, rising slowly to about 0.175V at 30 µA.

Changing the resistor to 10 kΩ to increase the current by a factor of 10, we get this:

SCR49

Same picture, different scale. At 300 µA, the voltage drop is now about 0.23V, and it’s fairly flat at that point.

For comparison, here’s a run-off-the-mill 1N4148 “standard” silicon diode:

SCR50

Again: different vertical scale. About 0.53V at 300 µA. More importantly, it’s already 0.4V at 60 µA.

So when losses matter at low voltages and low currents, it’s better to use Schottky diodes.

Watching it go down

In AVR, Hardware, Software on May 13, 2012 at 00:01

Now that there’s low-power vccRead() code to measure the current power supply voltage, we can finally get a bit more valuable info from the radioBlip sketch, which sends out one packet per minute.

So here’s a new radioBlip2 sketch which combines both functions. To support more test nodes, I’m adding a byte to the payload for a unique node ID, as well as a byte with the measured voltage level:

Screen Shot 2012 05 09 at 18 28 02

As a quick test I used a JeeNode without regulator, running off an electrolytic 1000 µF cap, charged to 5V via a USB BUB, and then disconnected (this is running the RFM12B module beyond its 3.8V max specs, BTW):

DSC 3127

Here’s a dump of the received packets:

    L 16:56:32.032 usb-A600dVPp OK 17 1 0 0 0 1 209
    L 16:57:35.859 usb-A600dVPp OK 17 2 0 0 0 1 181
    L 16:58:39.543 usb-A600dVPp OK 17 3 0 0 0 1 155
    L 16:59:43.029 usb-A600dVPp OK 17 4 0 0 0 1 134
    L 17:00:46.323 usb-A600dVPp OK 17 5 0 0 0 1 115
    L 17:01:49.431 usb-A600dVPp OK 17 6 0 0 0 1 98
    L 17:02:52.314 usb-A600dVPp OK 17 7 0 0 0 1 82
    L 17:03:55.016 usb-A600dVPp OK 17 8 0 0 0 1 66
    L 17:04:57.526 usb-A600dVPp OK 17 9 0 0 0 1 50

Or, more graphically, as voltage – showing 8 minutes before the sketch runs out of juice:

Screen Shot 2012 05 09 at 19 06 19

This consumes only marginally more power than without the VCC measurements: the original radioBlip sketch lasted 1 minute longer under similar conditions, i.e. one extra packet transmission.

TK – Voltage accuracy

In Hardware on May 10, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is a bit of a side excursion, about checking the quality of a measuring instrument)

“Ah, but is it any good?” – that’s the inevitable question to ask when getting a precise instrument, right?

I’m referring to the 6.5 digit 34401A HP (now Agilent) multimeter I got my hands on, recently. This translates to: better than 1 ppm (part per million), i.e. 10,000 times more accurate than one percent!

This is the sort of thing the members of the volt-nuts mailing list ponder about, I would imagine.

In my case, with now over half a dozen ways to measure voltage here (numerous hand-held multimeters, mostly), I just wanted to know which one to trust most and to what extent.

The solution comes in the form of a transfer voltage standard – an item you can order, gets shipped to you, and which then gives a certain level of confidence that it will provide a fixed voltage reference. As it turns out, Geller Labs offer just such a thing at low cost – it’s called the SVR 2.0:

DSC 3078

Put 15V on its input (left), wait 30 min, and the output pins (right) will produce exactly 10.00000 Volt – magic!

Each board is “burned in” (kept turned on) for 200 hours and calibrated at the temperature you specify (I asked for 21°C). You even get the measured temperature coefficient at that spot (mine is 1.7 ppm/°C), so you can in fact predict the voltage it will generate at a slightly different temperature. Now that’s serious calibration!

My bench-top multimeter will indeed go down to 1 ppm in 6-digit mode, i.e. steps of 10 µV when measuring 10 V:

DSC 3079

And guess what – after a 30-minute warm-up (both the 34401A and the SVR), it’s spot on.

No last-digit jitter, nothing. A constant 10.000,00 readout. The current room temperature is 21.1°C, heh.

Think about it for a second: as hobbyist, you can order a precision second-hand instrument from eBay, Google around a bit to find a little voltage standard, have ’em shipped from different parts of the planet, get them here within two weeks, hook up some wires, wait 30 minutes, and they match to 0.000,1 % precision.

Given that this instrument is from the 90’s, I’m massively impressed. This 34401A HP thing rocks!

Voltage? Current? Resistance? Game over – for me, this is more than enough precision for serious use.

Not long enough

In Hardware on May 9, 2012 at 00:01

My second solar setup did not fare well:

DSC 3086

Started during the day, with the supercap charged up in bright daylight behind a window, it was able to power the JeeNode for about 16 hours – and then in the middle of the night it gave up:

    L 02:36:44.743 usb-A600dVPp OK 17 30 4 0 0
    L 02:37:48.074 usb-A600dVPp OK 17 31 4 0 0
    L 02:38:51.402 usb-A600dVPp OK 17 32 4 0 0
    L 02:39:54.725 usb-A600dVPp OK 17 33 4 0 0

Times are in UTC and we’re in the CEST time zone, so this was two hours later – i.e. around 4:30 AM.

I left it there for another few days, but unfortunately once dead this setup never recovers. The main reason for this is probably that the RFM12B starts up in a very power hungry mode (well, relatively speaking anyway) with a 0.6 mA current consumption – because it starts with the crystal oscillator enabled.

Maybe the self-leakage of the supercap was still too high, and would be (much) lower after a few days in the mostly-charged state, so I’m not ruling out using supercaps just yet. But as it stands, not getting through even a single night is not good enough – let alone being used in darker spots or on very dark winter days.

More experimentation needed!

TD – Soldering iron

In Hardware on May 8, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today, I’m going to take a quick peek inside the soldering iron from Conrad, which was suggested as low-end soldering option for a first toes-in-the-water electronics toolkit:

Opening up the base is trivial, just remove 4 screws after taking off a couple of rubber caps:

DSC 3123

On the right: the AC mains feed, with 2 live/neutral wires and the green/yellow ground.

On the bottom: again 2 wires plus the green/yellow ground (as crucial safety feature).

First thing to remark is that there is no temperature sensor in the soldering iron. In other words, this is an adjustable unit, but it’s not temperature-controlled – the 150..450°C scale around the rotating knob is bogus.

Just removing the knob and a washer around the potmeter is enough to examine the board up close:

DSC 3121

A couple of resistors, caps, an inductor, and a little transformer – that’s all. Oh, and a little TRIAC in a TO-92 housing (just beneath the transformer). Here’s the other side:

DSC 3122

A plain single-sided low-cost PCB. No surprises here – this is a very low-cost unit, after all.

So how does it work? Well, it’s basically a simple dimmer. But instead of dimming an incandescent lightbulb, it dims the heater coil inside the iron. The way this works is that the start of each AC mains cycle gets switched off – and then only after a specific time does the TRIAC start conducting. The whole circuit is essentially an adjustable delayed pulse generator, synchronized to the AC mains zero crossings.

Here’s what it looks like on the scope (as measured via a differential probe for isolation):

SCR33

The entire AC mains cycle is 20 ms (50 Hz), half a cycle is therefore 10 ms, and in this mid-range setting, each half of the sine wave is switched on after about 5 ms, i.e. halfway into the sine, at the peak voltage in this case.

Does it work? Sure, turning the knob will definitely adjust the tip temperature – but not very directly. Instead of a feedback loop, we merely control the amount of power going into the iron, and assuming a fairly steady heat dissipation, the iron will then stabilize more or less around a specific temperature. Just like a lightbulb, such a circuit will “dim” a soldering iron just fine this way.

The only drawback is that it’s not tightly controlled. When using the iron and pushing it against a thick copper wire or a big copper surface, the iron will cool off. Real temperature control requires a feedback loop which senses this change and counteracts the effect by pushing more power in when needed.

For simple uses, the crude approach is fine, but if you plan to solder under lots of different conditions (through-hole, SMD’s, PCB ground planes, thick copper wires) then a more expensive type might be more convenient.

How low can it go?

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

While experimenting with various alternate power sources for a JeeNode, I was curious as to just how low it could go in terms of voltage and still function as a simple wireless transmit node.

Made the following mods to push things a bit more than usual:

adjusted the fuses to set the brownout level to 1.8V iso 2.7V (efuse: 0x06)
changed the RFM12B’s low-battery level to 2.2V iso 3.1V (rf12_control: 0xC040)
removed the voltage regulator from a JeeNode, and keep just the electrolytic cap
changed the radioBlip sketch to run at 8 MHz, i.e. 16 MHz clock % 2

This is the same setup as with the Tiny Lithium discharge setup described a few days ago, BTW.

Here’s the JeeNode-under-test (JUT?) – the cap I used here is again 100 µF:

DSC 3070

One pair of wires is from the power supply, the other from the multimeter.

And then it’s just a matter of hooking it up to a power supply and gradually lowering the supply voltage.

And the result is … 3.0, 2.9, 2.8, 2.7, 2.6, 2.5, 2.4, 2.3, 2.2, 2.1, 2.0, 1.9, 1.85 Volt still works!

Anything lower than that and the sketch stops sending out packets once a minute – but then again, that’s probably just the brownout detector of the ATmega kicking in!

To get it back up, I re-connected the power supply at 2.1 V and the node started its blips again… lower didn’t work, my hunch is that the RFM12B’s clock circuit needs that slightly higher voltage level to start oscillating.

Measuring capacitance

In Hardware on May 6, 2012 at 00:01

Capacitors are all about storing and releasing charge. The main difference with batteries is that this charge is stored directly as electrical energy, whereas a battery converts to / from chemical energy in some form.

In an ideal capacitor, charge and discharge follow an exponential curve. Charging takes place when connected to a fixed supply via a resistor, discharging is a matter of placing a resistor across the capacitor:

Rc circuit 07

(image copied from www.technologyuk.net)

The “time constant” is the level when the discharge reaches 36.8% or the charge reaches 63.2% of the original voltage. It can be calculated using the formula: T (seconds) = R (ohm) x C (farad).

This property makes it easy to measure the value of a capacitor: charge it up to a known voltage, then discharge it through a known resistor and measure the time it takes for the voltage to drop to 36.8% of the original voltage.

This is the approach taken by this capacitance meter kit by Radio Hobby Store:

DSC 3084

There is excellent documentation including very detailed assembly instructions, leading to this:

DSC 3085

And sure enough, it works as expected – measuring a 10 µF cap in this case.

The only two drawbacks I found is that it doesn’t measure caps larger than 50 µF, and that there is no on-off switch. With a tool like this, you tend to want to use it from time to time and put it away after use. Without the switch, you have to disconnect the battery each time – a bit awkward and inconvenient.

This meter is based on a pre-flashed PIC controller. There’s one button to calibrate its zero value, and a convenient “auto-zero” mechanism, which keeps adjusting for exactly 0 pF when no capacitor is connected.

Measuring VCC via the bandgap

In AVR, Hardware, Software on May 4, 2012 at 00:01

The ATmega’s (and ATtiny’s for that matter) all have a 10-bit ADC which can be used measure analog voltages. These ADC’s are ratiometric, meaning they measure relative to the analog reference voltage (usually VCC).

On a 5V Arduino, that means you can measure 0..5V as 0..1023, or roughly 5 mV per step.

On a 3.3V JeeNode, the measurements are from 0 to 3.3V, or roughly 3.3 mV per step.

There’s no point connecting VCC to an analog input and trying to measure it that way, because no matter what you do, the ADC readout will be 1023.

So can we figure out what voltage we’re running at? This would be very useful when running off batteries.

Well, there is also a “bandgap reference” in each ATmega/ATtiny, which is essentially a 1.1V voltage reference. If we read out that value relative to our VCC, then a little math will do the trick:

suppose we read out an ADC value “x” which represents 1.1V
with 5V as VCC, that value would be around 1100 / 5000 * 1023 = 225
whereas with 3.3V as VCC, we’d expect a reading of 1100 / 3300 * 1023 = 341
more generally, 1100 / VCC * 1023 = x
solving for VCC, we get VCC = 1100 / x * 1023

So all we have to do is measure that 1.1V bandgap reference voltage and we can deduce what VCC was!

Unfortunately, the Arduino’s analogRead() doesn’t support this, so I’ve set up this bandgap demo sketch:

Screen Shot 2012 04 22 at 21 44 43

Sample output, when run on a JeeNode SMD in this case:

Screen Shot 2012 04 22 at 21 47 20

There’s a delay in the vccRead() code, which helps stabilize the measurement. Here’s what happens with vccRead(10) – i.e. 10 µs delay instead of the default 250 µs:

Screen Shot 2012 04 22 at 21 51 15

Quite different values as you can see…

And here’s the result on an RBBB with older ATmega168 chip, running at 5V:

Screen Shot 2012 04 22 at 21 53 44

I don’t know whether the 168’s bandgap accuracy is lower, but as you can see these figures are about 10% off (the supply voltage was measured to be 5.12 V on my VC170 multimeter). IOW, the bandgap accuracy is not great – as stated in the datasheet, which specifies 1.0 .. 1.2V @ 25°C when VCC is 2.7V. Note also that the bandgap reference needs 70 µs to start up, so it may not immediately be usable when coming out of a power-down state.

Still, this could be an excellent way to predict low-battery conditions before an ATmega or ATtiny starts to run out of steam.

TK – Equivalent Series Resistance

In Hardware on May 3, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Equivalent Series Resistance, or ESR, is the resistance of a capacitor. Huh? Let me explain…

A perfect capacitor has a specific capacitance, no resistance, and no inductance. Think of a capacitor as a set of parallel plates, close to each other, but isolated. When you apply a voltage, electrons flow in on one side and electrons flow out on the other side until the voltage (potential difference) across the plates “pushes back” enough to prevent more electrons from flowing. Then the flow stops.

It’s a bit of a twisted analogy, but that’s basically what happens. A capacitor acts like a teeny weeny battery.

But no real capacitor is perfect, of course. One of the properties of a capacitor is that it has an inner resistance, which can be modeled as a resistor in series with a perfect capacitor. Hence the term “ESR”.

Resistance messes up things. For any current that flows, it eats up some of that energy, creating a voltage potential and more importantly: generating waste heat inside the capacitor.

ESR is something you don’t want in hefty power supplies, where big electrolytic capacitors are used to smooth out the ripple voltage coming from rectified AC, as provided by a transformer for example. With large power supplies, these currents going in and out of the capacitor lead to self-heating. This warms up the electrolyte in the caps, which in turn can dramatically reduce their lifetimes. Caps tend to age over time, and will occasionally break down. So to fix old electronic devices: check the big caps first!

Measuring ESR isn’t trivial. You have to charge and discharge the cap, and watch the effects of the inner resistance. And you have to cover a fairly large capacitance range.

This ESR70 instrument from Peak Instruments does just that, and also measures the capacitance value:

DSC 3055

It’s protected against large voltages, in case the capacitor under test happens to still have a charge in it (a cap is a tiny battery, remember?). The clips are gold-plated to lower the contact resistance – and removable, nice touch!

In this example, I used a 47 µF 25V electrolytic capacitor, and it ended up being slightly less than 47 µF and having an ESR of 0.6 Ω as you can see.

It this cap were used in a 1A power supply to filter the ripple from a transformer, then its ESR could generate up to 0.6 W of heat – which would most likely destroy this little capacitor in no time.

Fortunately, big caps have a much lower ESR. It measured 0 (i.e. < 0.01 Ω) with a 6800 µF unit, for example.

As with last week’s unit, this is not an indispensable instrument. But very convenient for what it does.

Tiny Lithium – packet test

In AVR, Hardware on May 2, 2012 at 00:01

This post continues where the Tiny Lithium discharge post left off…

To summarize: a tiny ML614 rechargable Lithium cell of a mere 3.4 mAh is used to power a JeeNode running the radioBlip sketch, which is going to send out one small packet per minute (the period is actually slightly longer).

I charged the battery overnight from a 3.0V power supply and through a 1 kΩ resistor, as described in the datasheet. As expected, the battery voltage without load is now indeed 2.97V

The test is really simple, but it’s going to take a little while: connect, see packets come in, with a counter being increased for each packet, and then just wait for the whole thing to stop sending. Here we go:

DSC 3072

The range will need to be good, since packets have to cross a reinforced concrete floor to reach my receiver.

Here’s the log of packets I got (the first packet seems to have been missed):

L 12:08:51.628 usb-A600dVPp OK 17 2 0 0 0 L 12:09:54.592 usb-A600dVPp OK 17 3 0 0 0 L 12:10:57.556 usb-A600dVPp OK 17 4 0 0 0 ... L 23:58:57.898 usb-A600dVPp OK 17 167 2 0 0 L 00:00:00.777 usb-A600dVPp OK 17 168 2 0 0 ... L 23:59:32.169 usb-A600dVPp OK 17 6 8 0 0 L 00:00:34.988 usb-A600dVPp OK 17 7 8 0 0 ... L 23:58:57.821 usb-A600dVPp OK 17 101 13 0 0 L 00:00:00.609 usb-A600dVPp OK 17 102 13 0 0 ... L 23:59:01.058 usb-A600dVPp OK 17 197 18 0 0 L 00:00:03.818 usb-A600dVPp OK 17 198 18 0 0 ... L 23:58:45.821 usb-A600dVPp OK 17 37 24 0 0 L 00:00:51.318 usb-A600dVPp OK 17 39 24 0 0 ... L 13:18:55.865 usb-A600dVPp OK 17 34 27 0 0 L 13:19:58.670 usb-A600dVPp OK 17 35 27 0 0 L 13:21:01.474 usb-A600dVPp OK 17 36 27 0 0 L 13:33:35.035 usb-A600dVPp OK 17 48 27 0 0 L 13:37:46.210 usb-A600dVPp OK 17 52 27 0 0 L 13:43:00.171 usb-A600dVPp OK 17 57 27 0 0 L 13:56:36.450 usb-A600dVPp OK 17 70 27 0 0 L 13:57:39.232 usb-A600dVPp OK 17 71 27 0 0 L 14:06:01.520 usb-A600dVPp OK 17 79 27 0 0 L 14:20:40.504 usb-A600dVPp OK 17 93 27 0 0 …silence…

As you can see, this “battery” packs enough energy to send out 27 x 256 + 93 = 7005 packets – of which 398 were not properly received (mostly in the last days). IOW, it was still sending after 5 days!

The node kept going even though several of the last packets were not received – so transmit power probably dropped off quite a bit, but the sketch was still running properly until the very end.

Note: once moved to measure the supply voltage (still about 2.5V), packets started coming in again – perhaps because of improved reception from the new location, or a slight warm-up of the battery.

This little cell just doesn’t want to give up!

Indoor solar energy

In Hardware on May 1, 2012 at 00:01

The amount of solar energy available indoor is very limited… a very small fraction of outside, I’m sure.

Still, this unit has been running in the house here for a few years now, and not near a window either:

DSC 3074

It’s a attractive goal: gadgets which you buy (or build) once and then use essentially forever!

We don’t use the alarm clock mode of this thing, so the beeper never goes off, but it does listen for the DCF77 clock standard transmitter in Germany once a day to stay in sync. It’s also slightly glow-in-the-dark, so this clock remains readable at night.

The fact that this clock works so well tells me that, with proper care, we should be able to run simple nodes inside the house with a solar cell of perhaps a few square centimeters, just like this clock.

And, whether battery- or supercap-powered, that’s precisely what I’d like to get going…

As with the AC-mains connected ultra-low power supply, I suspect that reliable startup will be the hardest part. Such an energy source will have very little spare energy and charge up very slowly, so when the JeeNode comes out of power-up (or brownout) reset, it’ll have to be careful to not cut off the hand that is feeding it, so to speak.

Tiny Lithium discharge

In Hardware on Apr 30, 2012 at 00:01

The tiny rechargeable Lithium batteries I mentioned recently are another way to try and retain some charge overnight, just like the supercap mentioned last week.

First thing to do was to charge it up for a day, using a 1 kΩ resistor and a 3.0V supply:

Screen Shot 2012 04 22 at 17 14 55

I adjusted the radioBlip sketch, to switch back to 8 MHz (because the ATmega will be running well below 3.3V):

Screen Shot 2012 04 22 at 18 12 35

And I used these fuse settings:

efuse 0x06 = BOD 1.8V
hfuse 0xDE = OptiBoot (512b)
lfuse 0xCE = fast 16 MHz resonator startup

This should allow a JeeNode to work all the way down to 1.8V (the RFM12B radio only officially supports down to 2.2V but usually still works a bit below that). I also used a JeeNode with no regulator, and added a 100 µF cap to handle the peak currents during packet transmission (100 µF is a bit excessive – less probably also works fine):

DSC 3071

And sure enough, even with 2.75 V left in the battery, it starts up fine and starts sending out packets.

Unfortunately, I accidentally shorted out the battery while fiddling with the cables – so the charging process needs to be repeated for duration tests :(

Elektro:Camp

In Hardware on Apr 29, 2012 at 00:01

Elektro:Camp is a convention on Smart Metering, Smart Home, Smart Grid and Smart Ideas, in a BarCamp style.

October 2011, I attended this really interesting get-together about smart metering, monitoring, home automation, and more. Very heavy on technology. It’s basically a few rooms filled with lots of human ingenuity for two days :)

The Elektro:Camp event is scheduled twice a year in various locations, and is coming up again very soon:

Elektro camp 2012 05 final web

You can find out more and sign up on this website.

Lots of people signed up already, from all over Europe.

Due to a silly scheduling mistake, I can’t make it this time, unfortunately. But if you like the stuff on this weblog, then you’ll most likely also be delighted with everything being presented and discussed at Elektro:Camp!

Tiny solar cell – part 2

In Hardware on Apr 28, 2012 at 00:01

The tiny solar cell chip presented a couple of days ago has been doing some indoor sun-bathing:

DSC 3073

I’ve left it alone for some 3 days, just to give it a chance to charge up the 0.47 F supercap as far as possible. The voltage after all that time (partly sunny on most days) is now only just over 2.78 V, so this isn’t really going to work indoor, I’m afraid. Nor outside during the winter, probably – it’s just too weak.

The other solar cell I tried is also a very small one, rated at about 5V but only 1 or 2 mA, IIRC:

DSC 3083

It’s currently in the shadow, but during these same 3 days it has had its share of sunlight (still indoor, and again behind double-glazing). Much better: about 4.75V on the second day, and unchanged since then.

This might actually do the trick. I’ll wait for another experiment to finish and will then hook up the JeeNode running my radioBlip sketch to see how it goes.

Component Tester revisited

In Hardware on Apr 27, 2012 at 00:01

In January, I described the concept of a Component Tester, and how it can help understand what various types of components are doing.

In theory, you can just hook up a small transformer to generate the signal needed for the CT, i.e. a 50 Hz ±10V sine wave. Here is the circuit again, which is delightfully simple as you can see:

That secondary voltage is a bit high, though. Here’s what I get with two 6.3 VAC in series, i.e. 12.6 VAC:

SCR20

Half that would be fine. But it’s not really a sine wave, as you can see from the many harmonics in an FFT:

SCR19

And it shows – here’s what you get when placing a 1 µF electrolytic capacitor under test:

SCR21

Yikes, what a mess! With a (clean) sine wave, that would have been a (clean) oval!

I don’t think it makes sense to build a CT this way. Not with this particular small transformer anyway…

TK – Semiconductor Analyzer

In Hardware on Apr 26, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Today’s episode is about a little gadget called the DCA55 Semiconductor Analyzer from Peak Electronics:

DSC 3053

It’s a nifty little self-contained unit, which identifies a range of 2- and 3-pin semiconductors, their pinouts, and some useful characteristics:

NPN and PNP Bipolar Junction Transistors and Darlingtons
Various types of MOSFETs and Junction FETs
Low-power thryristors and triacs
Diode and diode networks, as well as LEDs

The convenient bit is that you just hook up all the pins, press ON, and this gadget will figure it out, all by itself.

Here’s a BC549C transistor, i.e. a very common high-gain NPN transistor:

DSC 3051

And here’s an example from the datasheet, showing all the info you get:

Screen Shot 2012 04 17 at 18 10 49

I wouldn’t call this unit indispensable – most of this can also be derived with a battery, a few resistors, and a multimeter – but it’s darn convenient, if you regularly re-use stuff from your spare parts bin, as I often do.

Tiny solar cell

In Hardware on Apr 25, 2012 at 00:01

Got a tip from Lennart Herlaar a long time ago about a tiny CPC1824 solar cell from Clare with 4V output:

CPC1832N sml

It’s packaged as a SOIC-16 chip, so clearly the light collecting capabilities of this thing will be limited. But with all this ultra-low power stuff going on here at JeeLabs, I thought I’d give it a whirl anyway. It’s trivial to hook up:

Screen Shot 2012 04 22 at 15 27 51

In bright sunlight, you get over 4V with a 100 µA short-circuit current according to the datasheet.

I added a BAT34 Schottky diode in series (which has a low voltage drop) and placed it all on a little breadboard together with a 0.47 F supercap – the solar chip is mounted on a little SOIC breakout board:

DSC 3069

The initial voltage was under half a volt, but rising (very) slowly and steadily while exposed to light.

Let’s just leave this thing exposed to light near a south-facing window for a week or so, eh?

TD – Solar light

In Hardware on Apr 24, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

The other day, Ard Jonker pointed me to this item available at the Dutch Lidl stores for €12.95:

DSC 3066

A solar LED light you put in the floor outside, which automatically lights up when it gets dark.

It’s about 14 cm in diameter, and 6 cm deep – let’s have a look inside:

DSC 3067

A solar cell, with two white LEDs, held in place by two screws yearning to be removed:

DSC 3075

The red leads connect to an on/off switch which can be accessed from outside. The batteries are 800 mAh, according to the specs, and look like standard replaceable AAA cells. The PCB has a chip on the other side:

DSC 3076

Hey – not bad, two ~~NiCad~~ NiMH’s and a little chip to drive the LEDs. This could easily accommodate a JNµ!

The DIP-8 chip in there seems to have logic for turning the LEDs on only when it’s dark (weak solar cell voltage, I assume). It does a bit more though, as this scope trace of one of the LED shows:

SCR25

Probably some sort of charge-pumping, to drive the LEDs beyond the 2.5V supplied by the batteries. The power consumption is about 9.5 mA, so these lights should last through the night if there is enough sunlight during the day to fully recharge the batteries.

Neat. This could make an excellent power source plus enclosure for a JeeNode Micro, but note that the big metal ring is essential – it presses the glass and rubber seal tight against the rest of the enclosure “cups”.

Supercap discharge – part 2

In Hardware on Apr 23, 2012 at 00:01

Yesterday, I charged a 0.47F 5.5V supercap to 5.1V and kept charging it for 24 hours to reduce the leakage current.

Actually, I lowered it to 5.01V in the last hour – there’s a slight memory effect, so right after lowering the voltage actually rises when power is disconnected.

Next step is to measure the supercap’s self-discharge time from 5.00V to 1.84V (i.e. 36.8% of 5V) – that’ll give the time constant of the RC circuit (the real capacitance, in parallel with an imaginary internal current leakage resistor). Note that this is not the same as the ESR of a cap, which is about charge & discharge current losses.

Ok, let’s disconnect the power supply and track the voltage readings in high-impedance mode. It is 10:17 here, and the voltage has just dropped to 5.00V – with the power supply removed.

…

Time passes. Unfortunately, waiting for the voltage to drop to 1.84V (i.e. 36.8% of 5V) would take a bit long, so let’s throw some math at this and come up with a quicker way to measure leakage current:

for T = R x C, we need to measure a drop to 36.8% (i.e. a factor 0.368) of the original voltage
since the charge decay curve is exponential, we can estimate when 0.5 T will happen
this turns out to be the square root of 0.368, i.e. a factor of 0.607
so with a drop to 0.607 x 5V = 3.033V, we know 0.5 x T
let’s repeat that trick one more time, to get at 0.25 x T
my trusty on-screen calculator tells me that the square root of 0.607 is 0.779
so if we wait for a drop to 0.779 x 5V = 3.894V, we’ll know 0.25 x T
four times that duration, and we have T, the RC time constant we’re after

Good. That means I only need to wait for the supercap charge to drop by roughly 1V i.s.o. over 3V.

…

More time passes. It’s now 0:26 after midnight, and the voltage has dropped to 3.98V – i.e. not yet the 3.894V we need to reach, but hey, let’s call it a day anyway.

That’s over 14 hours total, i.e. over 50,000 seconds = 0.25 x T, so the calculation now becomes:

200000s = R x 0.47F
R = 200000 / 0.47 ≈ 425 kΩ
so at 5V, the internal discharge current is 5V / 425kΩ ≈ 12 µA

Hmmm…. that amount of leakage is three orders of magnitude higher than with a 47 µF electrolytic cap, but it might still be usable as power source for a JeeNode or JeeNode Micro. Here’s my reasoning:

suppose the JN/JNµ draws 12 µA on average – a tough target, but it should be feasible
then we’re effectively draining the supercap twice as fast as its self-discharge
it looks like the supercap can hold a charge down to 1.8V for 56 hours on its own
note that 1.8V is too low for RFM12B use, but the microcontroller would still work
with the added load from the JN/JNµ, this halves to 28 hours, i.e. slightly over a day
so the challenge will be to fully recharge the supercap to 5V at least once a day

A solar cell might just do it – assuming it’s large enough to overcome a dark and cloudy winter day. And the good news is that supercaps can charge up very fast, so a short period of bright light could be enough.

Update – There’s a lot more to supercaps than this…

As suggested by @jpc in a comment yesterday, I had a look at some documentation from Panasonic, in particular Part 2. And sure enough, they show that a supercap can be modeled as a whole set of capacitors in parallel, each with their own – often substantial – series resistance. It takes a while to “reach them” with charge, so to speak. Which explains why a long charge time increases the charge and voltage:

Screen Shot 2012 04 22 at 14 09 04

And which also explains why the supercap tends to drop quickly at first:

Screen Shot 2012 04 22 at 14 06 39

Having seen the discharge tail off much more than expected (i.e. flatten out and retain voltage), I can confirm that a supercap behaves considerably differently from a plain electrolytic capacitor.

The good news, is that for our intended purpose, this might actually work out quite well: a solar cell, keeping the supercap charged up fairly well most of the time, with just night-time JeeNode activity to drain the charge a bit, and occasional dark days, expecially in wintertime.

Update #2 – Three days have passed, and the voltage is still 3.23V, so T will be over 6 days, and the corresponding discharge rate even lower than estimated above. Bit of a puzzle – the discharge tails off considerably, apparently. Which is good news in fact, because that leaves more charge for a JeeNode to use. I’m ending this experiment for now: real-world testing with a JeeNode sending packets will be more useful.

To be continued…

Supercap discharge

In Hardware on Apr 22, 2012 at 00:01

Now that I have this super-high-impedance multimeter, it’s time to revisit the venerable supercap:

DSC 3057

That’s a whopping 0.47 Farad, the size of a little coin cell, and as you can see, this unit is rated 5.5V (most supercaps are 2.7V, I suspect that this is actually made of two 1F 2.7V units placed in series).

The beauty of a supercap is that it’s like a little battery, but with fewer limitations – you can’t really overcharge it, for one, because it doesn’t turn electric energy into chemical energy. There is no conversion: put 5V on it, and it’ll draw current and gobble up electrons until it reaches 5V, then it’ll stop.

So for example for solar-powered ultra-low power nodes, this could be a pretty nice solution. Solar cell -> diode -> supercap -> JeeNode. Max charge rate while the sun shines, and then it simply stops once the supercap is full. Only thing is to not exceed that 5.5V maximum, for which supercaps are very sensitive.

But there’s a problem. Supercaps can have a substantial self-discharge rate. When I connected 5.3V to it, the voltage immediately jumped to 5.3V, but when I disconnected that cable, it also dropped back to around 4.7V in just a few seconds – a normal capacitor sure isn’t supposed to work that way!

As it turns out, supercaps tend to “learn” to keep charge better over time. The longer you expose them to a voltage, the lower their self-discharge rate becomes. The isolation barrier needs time to build up, apparently (I’ve had this supercap on the shelf for over a year). Which is great, because presumably these cells would be kept charged most of the time, with the node only depleting them slightly when sending out a packet. So ideally, all we really need is for the supercap to retain enough energy overnight.

It’s time to put these unique components to the test!

The first encouraging fact is that indeed, when fed 5.1V for a couple of minutes, the discharge no longer jumps as radically when disconnected. It now drops to 5.03V in a few seconds, but tends to hold its value after that. So it does indeed look like these supercaps can be “taught” to better retain their charge.

This test is going to take some time. First thing I’m going to do is to just keep the supercap charged to 5.1V (note that the power supply voltage calibration is pretty good – slightly less so for the low mA’s):

DSC 3058

Let’s just leave it there to stabilize for about 24 hours. Stay tuned…

What does a BJT do?

In Hardware on Apr 21, 2012 at 00:01

And while we’re at it, let’s compare a regular transistor (a.k.a. BJT) to yesterday’s MOSFET.

Again a smal test setup, but this time it also needs a 10 kΩ resistor between input signal and base:

Screen Shot 2012 04 10 at 13 14 35

The reason for that extra resistor, is that the base of an NPN BJT is essentially connected to ground via what looks like a forward-biased diode. So the voltage on the base doesn’t normally rise above 0.7V. Without current limiting resistor, the transistor would get damaged (and perhaps also the source circuit into it).

Compare this to yesterday’s screen shot and you’ll see that a BJT behaves like a MOSFET, sort of:

SCR14

The main difference is that the switching point is much lower, around 0.7V – which happens to be just about the point where the base-to-emitter junction starts to conduct.

Here’s the same as X-Y graph (with again the X axis adjusted to 500 mV/div for full scale):

SCR15

Compared to the MOSFET, the switch-over is steeper, i.e. more like a digital on-off switch. Note also that although the base-to-emitter voltage will be at 0.7V, the collector-to-emitter voltage is in fact below that, almost zero!

What might not be immediately apparent from the above plot, is that a transistor has a much more linear behavior (even if steeper, i.e. with more amplification). In that small range between about 0.65V and 0.75V, it’s in fact a great linear amplifier – which is what transistors were initially used for, and on a huge scale.

A simple way to describe them is that BJTs are current-driven, whereas MOSFETs are voltage-driven.

For a nice article about how to use BJT’s for signal amplification, see this page on the PCBheaven website.

The BJT was at the start of the semiconductor revolution, decades ago. The MOSFET added a new and very different component, perfect for switching enormous loads with amazingly little power loss.

For the dual-voltage supply of a few days ago, either a MOSFET or BJT will probably work. With the BJT, there will be a higher residual voltage – so a check is needed to make sure it switches properly with a feedback pin voltage of only 0.41V. The MOSFET has no such issues, it’s essentially a controllable resistor: no bipolar junctions or diode-like behavior in sight.

What does a MOSFET do?

In Hardware on Apr 20, 2012 at 00:01

In a previous post, I mentioned using a MOSFET to short out a resistor. So how does that work?

Well, a MOSFET is like a voltage-controlled switch. To be more precise, an N-channel enhancement type MOSFET is like an infinite resistance when the gate-to-source voltage is zero, and turns into a very low resistance when the gate-to-source voltage is a few volts positive.

To examine this in more detail, I created a test setup like this:

Screen Shot 2012 04 10 at 03 22 50

By applying a linear ramp voltage on the gate, we can see what it does with varying voltages. When open, the output should be 5V, and when conducting, it should drop to almost 0V. Let’s examine this in real life:

SCR08

The blue line is the input voltage on the gate (by definition a sloped straight line), and the yellow line is the voltage on the output (i.e. between drain and resistor). Let’s try and read this:

the gate voltage takes 10 divisions to reach 3V, so that’s 0.3 V/div
the MOSFET starts conducting at around 1.8V and is fully on at ≈ 2.4V
at slightly over 2.1V, the drain-to-source resistance is about 1 kΩ

The red trace is the derivative of the output, so the output change is maximal at just over 2.2V.

There’s no linear behavior, in terms of gate-to-source voltage (the derivative is never constant, except in the fully-open and fully-closed regions), but what you can see is that the MOSFET will switch just fine with a logic signal (anything switching between under 1.8V and over 2.4V will work perfectly).

There are more ways to look at this. Here’s an X-Y plot, with the linear ramp on the horizontal axis:

SCR10

Note that – if you think about it – in X-Y mode, it doesn’t really matter what sort of signal is placed on the gate as long as it has the same voltage range. Here’s a sine wave to illustrate this perhaps somewhat surprising property:

SCR11

It’s a good exercise to try and understand exactly why the two above screenshots are the same.

Lastly, here is a zoomed-in measurement, to get more precise data using the scope’s cursor features:

SCR12

As you can see, a 0.33V change on the gate is all it takes between the “almost-OFF” and “almost-ON” states.

I’ll leave it as exercise for the reader to plot the resistance of this particular MOSFET at different gate voltages. With a bit more setup, the scope’s math functions should in fact be able to display that plot on-screen.

So there you have it: a MOSFET switches on voltage, and a scope + function generator makes it easy to see that behavior. Note that even without these instruments, with nothing more than a potentiometer and a multimeter, you could in fact derive exactly the same information. It would merely be a bit more work.

TK – Resolution vs accuracy

In Hardware on Apr 19, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

This episode is not about an instrument you will normally need, but about using a high-end unit.

Once you get into measuring instruments, there’s a trap – the kick of going after models which have more and more resolution and accuracy. First, let me explain the difference – i.e. roughly speaking:

resolution is the number of digits you can measure
accuracy is how close that value is to the real value

So you could have a 3-digit multimeter which is spot-on, and in most scenarios it’d probably be much more useful than a 5-digit multimeter which delivers meaningless results because it’s not properly calibrated.

The trouble with this search for perfection is that it can be addictive – see the time-nuts site for one example of keeping track of the EXACT time. Over the top for most mortals, but hey, I can relate to this sort of craziness :)

And recently I fell into the same trap. I’ve got quite a few hand-held multimeters, but when someone pointed out some eBay offers of a 6.5 digit HP/Agilent bench-top multimeter, I simply couldn’t resist and bought one:

DSC 3050

An amazing instrument – above it’s measuring between 1.8 and 2.0 µV with the probes shorted out. It’s a second-hand unit, probably from the 90’s, so it’ll be out of calibration by now. I could send it to a calibration lab, where they tweak the thing until it’s back to its sub-ppm accuracy, but that might well cost as much as what I paid for it. So for now I’ll just assume its accuracy is decent, perhaps in the 5-digit range. More than good enough for the experiments at JeeLabs anyway. This is all for fun, after all.

One of the interesting specs of this multimeter is a selectable input resistance of over 10,000 MΩ on DC ranges up to 10V. This extremely high value is great for measuring the leakage of a capacitor. Let’s try it:

first, a 47 µF 25V cap is charged to slightly over 5V for a few minutes
then, the power supply is disconnected and it starts discharging
finally, we measure the time it takes to discharge from 5V to 3.16V
this was determined to be well over six hours (I stopped waiting!)

I picked this voltage range because 3.16V is 63.2% of 5V, so the measured time corresponds to the time constant of the T = R x C formula for capacitor discharge. In other words:

20000 s = R x 47 µF
therefore, the internal leakage resistance R = 20000 / 47 ≈ 425 MΩ
this translates to an internal leakage current of under 5 V / 425 MΩ ≈ 12 nA

So without even having an instrument which can measure such extremely low currents, we can arrive at an estimate of the leakage of this particular 47 µF 25V electrolytic capacitor, and under 12 nA is not bad!

Update – see the comments below, the leakage is even lower because the discharge should be measured to 1.84V iso 3.16V – so it’s well under 10 nA for this capacitor, in fact!

Two voltages

In Hardware on Apr 18, 2012 at 00:01

For a sensor I’ve been fooling around with, I needed a supply which can switch between 5V and 1.4V, supplying up to about 200 mA.

There are several ways to do this, but I decided to use the MCP1825 adjustable voltage regulator:

Screen Shot 2012 04 07 at 13 05 57

The trick is to create an adjustable voltage divider, using a MOSFET to short out one of the resistors:

Screen Shot 2012 04 07 at 13 12 03

When off, the MOSFET does nothing, with R2 and R3 in series. When on, R3 is essentially shorted out.

The regulator varies its output voltage (top of R1) such that the level between R1 and R2 always stays at 0.41V:

Screen Shot 2012 04 07 at 13 16 18

So the task is to come up with suitable values for R1, R2, and R3. Let’s start with the 5V output and R1 = 10 kΩ:

5V = 0.41V x (10 kΩ + R2) / R2
then 5 x R2 = 0.41 x (10,000 + R2) = 4,100 + 0.41 x R2
and 5 x R2 – 0.41 x R2 = 4,100, i.o.w. 4.59 x R2 = 4,100
that would make R2 = 4,100 / 4.59 = 893 Ω

Now for the 1.4V output level (where R2′ is R2 in series with R3):

1.4V = 0.41V x (10 kΩ + R2′) / R2′
then 1.4 x R2′ = 0.41 x (10,000 + R2′) = 4,100 + 0.41 x R2′
and 1.4 x R2′ – 0.41 x R2′ = 4,100, i.o.w. 0.99 x R2′ = 4,100
that would make R2′ = 4,100 / 0.99 = 4141 Ω

But that’s not quite right, because R2 and R2′ have to be in the range 10 .. 200 kΩ. This is easy to fix by making R1 = 220 kΩ. Then the above values all increase by a factor 22 as well – bringing both R2 and R2′ nicely in range:

for 5V: R2 = 19.6 kΩ
for 1.4V: R2′ = 91.1 kΩ

IOW, two resistors of 19.6 kΩ and 71.5 kΩ in series would work, whereby the 71.5 kΩ resistor can be shorted out with the MOSFET to take it out of the loop.

These are not very convenient values, for resistors in the E12 series – let’s try and improve on that. After all, we can choose these values any way we like, as long as their relative values stays the same. With 15 kΩ and 54.7 kΩ, R1 would have to be 168 kΩ. That’s not so bad, we could use 15 kΩ, 56 kΩ, and 68 kΩ in series with 100 kΩ, resp.

Or, better still, perhaps: 19.6 kΩ ≈ 10 + 10 kΩ, and 71.5 kΩ ≈ 33 kΩ + 39 kΩ. With R1 kept at 220 kΩ. This needs 5 resistors in total to get the desired results. Now let’s try it out for real, eh?

DSC 3037

Yippie – it works! Voltages with 200 mA load are 1.38 V and 4.89 V, respectively – close enough.

With 5 V input, the output is still 4.86 V @ 200 mA, proving that the MCP1825 is indeed a low-dropout regulator. The switching edges look clean on the oscilloscope, with rise and fall times of ≈ 30 µs (1 µF cap charge/discharge).

Onwards!

Lithium theatrics

In Hardware on Apr 16, 2012 at 00:01

As an alternative to supercaps, I recently ordered a Lithium rechargeable battery from Digikey:

ML614 TZ21

It’s not quite what you might think, though: its size is only 6.8 x 1.4 mm, with a tiny 3.4 mAh capacity :)

Got ten of them, as part of a larger order, and they came packaged as follows:

DSC 3039

So far so good, but now the crazy part. These batteries were sent out in a separate 23x23x5 cm box:

DSC 3040

With a warning label …

DSC 3041

… and another warning label:

DSC 3042

The max discharge current of these things is 1.5 mA according to the specs. I doubt they’ll even go up to 15 mA when shorted! By the way, does that dented corner qualify as “damaged” ? … I want my money back! :)

Get real – or better still, read Bruce Schneier‘s works!

PS. Please don’t get me wrong: fire risks are very real – it’s just that the above cells have virtually no energy…

TK – Resistors

In Hardware on Apr 12, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Yet another useful package from Conrad (NL #418714) – a set of 390 resistors from 10 Ω through 1 MΩ:

DSC 3048

Resistors come in specific values and are based on a logarithmic range, i.e. you’ll see them organized as “E6”, “E12”, or “E24”, meaning that they are split up into 6, 12, or 24 values per decade, respectively.

Here’s some info about what’s in that above box:

Screen Shot 2012 03 29 at 13 11 35

This is actually mostly a subset of the E6 range (which is 10, 15, 22, 33, 47, 68) – see this Wikipedia article about preferred numbers for how and why things are organized that way.

The point is that you can never have enough resistors, which can probably be considered to be the most elementary components in electronics. Whether for limiting the current through a LED or creating a voltage divider, these things just tend to get used all over the place.

But what if you need a different value? Well, that’s often trivial: by using two resistors, either in series or in parallel, it’s often possible to get real close to the value you’re after.

The formula for two resistors in series is simply the sum of their values:

    Rseries = R1 + R2

The formula for two resistors in parallel is slightly more complicated:

    Rparallel = (R1 x R2) / (R1 + R2)

(this can easily be explained using Ohm’s law, I’ll be happy to write a post about this if you’re interested)

Here’s an online calculator which will find the proper values – although I recommend doing the math yourself, at least initially, because it will help you get a good grasp of how resistors work together.

TD – Infrared Remote

In Hardware on Apr 10, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Steve (@tankslappa) recently sent me two spare IR remotes he had lying around. Very joyfully and gratefully accepting his generous gift, I decided to tear one down to see what makes these things tick:

DSC 3043

Frightfully little, I’m afraid. Just a single SOIC-20 type IC! Marked “DUSUN021” and “1003” (3rd week 2010):

DSC 3044

The switches are custom-designed, using a silicone mat with buttons, each of them holding some sort of little carbon-lined conducting pad. When pressed, they connect two traces on the PCB and that’s it!

Oh, wait, the other side has two more components and some simple battery clips:

DSC 3045

The electrolytic cap just helps the battery supply power for IR LED, I presume, while the other component is a ~~cap~~ 3.45 MHz resonator, and part of the frequency-generating circuit.

Here is a scope trace of the emitted IR light when pressing a single button:

SCR03

This was picked up with an AMS302 light sensor, BTW. You can see the two pulse trains, i.e. the button press gets repeated twice. Perhaps not as easy to see, is the fact that “ON” is not represented by a simple IR pulse, but by a pulse train. This allows the receiver to filter out noise and random pulses, by filtering and detecting pulses only when modulated in this way.

As you can see in the zoomed-in section, the pulse train consist of turning the IR LED on and off at a 36 KHz rate.

This is within the detection range of the TSOP34838 IR receiver, as used on the Infrared Plug, even though that receiver is optimized for 38 KHz modulation. Don’t be put off by the term “modulation” in this context, BTW – it simply means that the 38 KHz frequency used to drive the IR LED is turned on and off in a certain pattern.

Each key has its own pattern. This remote appears to use the RC5 protocol. Here’s a snapshot of one keypress using the TSOP34838 chip, which detects, demodulates, and then outputs a clean logic signal:

SCR07

I’ve enabled the tabular pulse search listing, which gives us information about the encoding used by this remote:

829 µs for a short “OFF”
953 µs for a short “ON”
1738 µs for a long “OFF”
1752 µs for a long “ON”

Decoding such a pulse train is fairly easy, and as you can see, the component count for such IR transmissions is extremely low and hence very low-cost. Which also explains the popularity of this system!

PS. I’ve switched to light oscilloscope screen shots as a trial. The colors are not as pronounced, but it seems to be a little easier on the eyes. Here’s the same info, in the dark version as it shows on-screen:

SCR06

Do I need an oscilloscope?

In Hardware on Apr 9, 2012 at 00:01

As I’ve mentioned before, an oscilloscope is a pretty nifty piece of test equipment. It can also be very expensive.

The following comment in my series on oscilloscopes is still a good summary of what it’s all about, IMO:

Oscilloscopes are the “printf” of the electronics world. Without a “scope” you can only predict and deduce what’s happening in a circuit, not actually verify (let alone “see”) it. Here’s what an oscilloscope does: on the vertical axis, you see what happens, on the horizontal axis you see when it happens. It’s a voltmeter plus time-machine.

That doesn’t mean you can’t get anything done in Physical Computing without one. A simple multimeter is a lot cheaper and will get you a long way in figuring out the electrical behavior of a circuit – not to mention finding shorts and connection mistakes. So the first thing to get is a multimeter, not a scope. Always.

The trouble is that ATmega’s are so friggin’ darn fast. We can’t observe events on their time scale, and more importantly: many problems will zoom past us and get lost before we have a chance to see anything!

So I’m going to revise my advice about oscilloscopes somewhat: if you solder together kits and basic components, then yeah, a multimeter is plenty. But if you hook up non-trivial chips and need to debug the combination of hardware and software, then you really need all the help you can get. Be it a logic analyzer for digital signals, buses, and pulse-trains, or a scope to investigate the electric behavior of a fast circuit.

Note that a logic analyzer can be a lot cheaper than a scope. The reason being that they are electrically much simpler – they just need to collect a bunch of digital logic levels (rapidly), whereas a scope needs to collect much richer signals (ranging from millivolts to hundreds of volts, and with all sorts of signal processing to make sure you’re seeing the real thing and not some artifact of the instrument itself).

If you’ve been following this weblog a bit, you’ll have seen quite a few scope screen shots in some of the posts. One of the most important uses for my scope here at JeeLabs is to figure out power consumption while trying to optimize a JeeNode’s ultra-low power mode. Power consumption is an analog thing, so that’s where a scope comes in. And when you look at the amount of detail a modern scope can show, it’s clear that this level of insight really comes from such an instrument. See the recent Watchdog tweaking and Room Node analysis for some examples.

Does that mean you have to shell out a few thousand dollars to do something similar? Not at all.

First of all, visualization isn’t everything. A couple of years ago, I used one JeeNode to measure the power consumption of another JeeNode, see the Power consumption tracker post, and the software for it. Less insight perhaps, and no geeky screen shots, but plenty of info to try and optimize the power consumption by trial-and-error. Just tweak your sketch and measure, over and over again.

Second point I’d like to make, is that such power measurements are fairly slow, so any scope will do. Even a 10 MHz model will be able to accurately display changes from one microsecond to the next.

There are a couple of ways to get such a “low-end” scope (don’t let that term fool you, any oscilloscope can be extremely useful as long as things don’t change too fast):

Look for a second-hand unit, lots of them can often be found on eBay.
Consider getting a USB-connected scope such as the DSO-2090.
For PC’s there is software to create a basic scope using the sound card.
Check out the ultra-tiny Xmegalab, its under $50 (plus shipping).

These last two options are lower cost, but more limited since they don’t really include a full “front-end” to handle a wide range of input voltages. For circuits with only a few volts, they may still be sufficient.

Normal “sweeping” analog scopes are ok, but storage scopes (analog or digital) are considerably better because you can “capture” an event and keep it on the screen to investigate. Such a feature will cost more though.

Here’s an example of how a €100 second-hand Tek 475 (analog & non-storage) scope can be used to measure that same power consumption as in the Watchdog tweaking post – it’s the same waveform:

DSC 3023

Two essential tricks were used: 1) the watchdog is firing at ≈ 60 Hz, so the scope trace fires constantly, and 2) it triggers on one pulse but displays the next one, using x10 horizontal magnification.

The above screen shows 2 mA and 200 µs per division. The vertical scale could have been zoomed in further, but for the horizontal scale I’m sort of at the limit unless I start using delayed sweeps. Here’s the whole unit:

DSC 3014

No storage, no screen capture, no USB, so this was done by darkening the room and holding a camera in front of the scope. It took a couple of tries, but hey – it is possible to estimate power consumption this way!

What I’m trying to say is that you too can do this sort of work with an investment of €100 to €150.

If you intend to do more with electronics (and let me assure you: this sort of fooling around is geek heaven, and addictive!) – then consider holding off just a bit longer if need be, and save up for a Rigol or Owon scope. These “DSO’s” are mature, have tons of useful features, and they can store lots of detail (that’s the “S” in DSO).

Is this a case of “if you have a hammer then everything starts looking like a nail”? All I know is that my insight in ultra-low power consumption and optimization has increased significantly since getting an oscilloscope.

Electricity consumption

In Hardware on Apr 8, 2012 at 00:01

Came across this graphic a while ago – US energy cost and consumption over the years:

Screen Shot 2012 03 27 at 18 44 08

For comparison, in 2012, electricity here costs ≈ €0.21 (i.e. $0.28) per kWh, including taxes.

Our usage (i.e. Liesbeth’s and mine) was about 3000 kWh in 2011. That includes electric cooking, but note that heating and warm water is provided through natural gas.

That puts us in the late 1950’s w.r.t. US electricity consumption levels – yo, Elvis! :)

I’ve started to get involved in a local initiative (see this Dutch website if you’re interested – “duurzaamheid” is all the rage these days, it seems), with all sorts of simple and not-so-simple ways planned 1) to consume less, 2) to switch to renewable sources, and 3) to fall back to natural resources for the rest. It’s not an all or nothing game, more a way to plot a practical trajectory for improving things over the next couple of years.

Here’s the JeeLabs neighborhood:

Luchtfoto

Lots of space to catch some sunlight on all those rooftops – but careful with that chimney’s shadow!

Now that solar energy has become so cheap (Wp prices including inverter have dropped below €1.70), we’re finally getting together with a couple of neighbors here to actually make it happen. This year, and hopefully before the summer is gone again!

The aim is to try and get 4000 to 5000 Wp onto our roof (16..21 panels of 100×160 cm), which would cover for our entire yearly electricity needs, even without pushing for further savings. For the 52°N latitude of the Netherlands, panel + inverter efficiencies are estimated in the 80..85% range, nowadays.

That’s just half the story, gas consumption is the other biggie – but hey, ya gotta’ start somewhere, eh?

Trying to measure capacitor leakage

In Hardware on Apr 7, 2012 at 00:01

Capacitors have a “leakage current”, i.e. when you charge them up fully, the leakage current will cause them to slowly lose that charge. I was wondering about this in the context of an ultra-low power JeeNode, which has a 10 µF buffer cap right after the voltage regulator. Does its leakage affect battery lifetimes?

Time to do a quick test – I used the 47 µF 25V cap included with JeeNode kits these days:

DSC 2981

So how do you measure leakage currents, which are bound to be very small at 3.3V? Well, you could charge up the cap and then insert a multimeter in series in its most sensitive range. This multimeter goes down to 0.1 µA resolution, although its accuracy is specified as 1.6 % + 5 digits, so the really low values aren’t very precise.

A simpler way is to use the RC time constant as a basis. The idea is that a real-world cap can be treated like a perfect cap (which would keep its charge forever) plus a resistor in parallel. That resistor merely “happens” to be situated inside the cap.

What I did was charge the cap from a 3x AA battery pack which was just about 4.0V, then disconnect the battery and watch the discharge on the oscilloscope:

SCR02

As you can see, it took 500 seconds for the charge in the capacitor to drop by some 2.5V – note the exponential decay, which matches the assumption that the leakage comes from a fixed resistance.

Can we derive the leakage from this? Sure we can!

The formula for RC discharge is:

    T = R x C

Where T (in seconds) is the time for the cap to discharge by 63.2 percent, R is the discharge resistor (in ohms), and C is the capacitor size (in farads).

Above, it took 500 seconds to drop from 3.98 V to 1.48 V, which by pure accident is almost exactly 63.2 %, so T = 500 and C = 0.000,047 – giving us all the info needed to calculate R = 500 / 0.000,046 = 10638298 ≈ 10.6 MΩ.

Using ohm’s law (E = I x R), that means the leakage current at the start is 4 V / 10.6 MΩ = 0.376 µA.

The good news is that such a result would not be of any concern with ultra-low power JeeNodes – the regulator + ATmega + RFM12B use an order of magnitude more than that, even when powered down.

But the bad news is that this result is in fact completely bogus: to measure the charge, I placed the oscilloscope probe over the cap, and it happens to have 10 MΩ internal resistance itself. So basically the entire discharge behavior shown above was caused by the probe i.s.o. the capacitor’s own leakage!

So it looks like I’ll need a different setup to measure real leakage, which is probably in the nanoamp range…

Hameg scope update

In Hardware on Apr 6, 2012 at 00:01

The Hameg HMO2024 scope just got a firmware upgrade – wow, it just keeps getting better and better.

Support for up to 6 calculated values (was 2), based on any of the input channels – now with optional statistics:

SCR61

And one of the things I really missed dearly – the ability to see all decoded serial data in tabular form:

SCR62

The top two traces show the SCL and SDA data in analog form, the next group is the color-coded serial data, and at the bottom is the list of packets. As you scroll through the table, the traces adjust to show the related information. Still shown at the bottom are the 6 auto-measured items I configured in the first screen.

Last big new feature is the capability to search through stored traces, again with a table to help navigation:

SCR63

It’s all firmware, evidently, but I hadn’t expected the development to keep on moving the capabilities of this oscilloscope forward to such an extent. And these aren’t just gimmicks, such features can be extremely useful!

TK – Burden voltage

In Hardware on Apr 5, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Two weeks ago, I extolled the virtues of the multimeter for measuring various electrical units.

With voltages, things are very simple: you’ve got two probes, and you can stick them anywhere in your circuit to measure the voltage potential difference between two points. The input impedance of any modern multimeter is usually 10 MΩ or more, which means the load caused by measuring is neglegible in just about all cases.

Let’s apply Ohm’s law: 10 MΩ over 1V is just 0.1 µA current, and over 230V it’s still just 23 µA current.

But with current measurements, things change: a multimeter in current measurement mode is essentially a short. You place the probe pins between the supplier and consumer of current to measure the Amps, milliamps, or microamps. That also means you can’t just go probing around at random: sticking the probes between + and – of a power supply, or even just a battery, basically creates a short. The result is a huge current, which will blow the internal fuse of the multimeter. Very often, the fuse is a 500 mA type (to protect a 400 mA range).

That’s why the VC170 (left) is better than the VC160 (right) – voltage and current are on different jacks:

DSC 2979

But there’s another aspect of current measurement with multimeters to be aware of: burden voltage.

When measuring current, multimeters insert a small resistance in series with the load, i.e. between the two probe pins, and then work by measuring the voltage drop across them (Ohm’s law, again!).

So placing multimeter between current supplier and consumer actually introduces a small voltage drop. How much? Well, that depends both on the multimeter and on the selected range.

Here’s the VC170 with a 1 mA current through it – in its 400 mA range:

DSC 2977

I used the VC160 multimeter to measure the voltage over the VC170 multimeter, which is in current measurement mode. This is one example why having several multimeters can come in handy at times.

Not bad – roughly 1 mV to measure 1 mA, so the burden resistor in this unit for the 400 mA range is somewhere around 1.3 Ω. Note also that with 400 mA, the voltage drop will rise to over 500 mV!

Let’s repeat this with the VC170 in µA range, i.e. measuring up to 4000 µA:

DSC 2978

Hmmm… the voltage drop with 1 mA is now 100 mV, i.e a 100 Ω burden resistor. Not stellar.

Why is this a problem? Let’s take an example from the JeeNode world: say you want to measure the current consumed by the JeeNode once it has started up and entered some sort of low-power state in your sketch. You expect to see a few µA, so you place the multimeter in µA mode.

The JeeNode starts up, powered from say a 3.6V 3x AA battery pack with EneLoops. It starts up in full power mode, briefly drawing perhaps 10 mA. You’ve got the multimeter in series, which in µA mode means that you’ve got a 100 Ω resistor in series with the battery.

The problem: at 10 mA, a 100 Ω resistor will cause a 1V drop (BTW, make sure you can dream these cases of Ohm’s law, it’s an extremely useful skill). That comes out as 100 V/A burden voltage.

So the battery gives out 3.6V, but only 2.6V reaches the JeeNode. Supposing its ATmega is set to the default fuse settings, then the brown-out detector will force a reset at 2.7V – whoops! You’re about to witness a JeeNode constantly getting reset – just by measuring its current consumption!

In the 400 mA range, the voltage drop at 10 mA will be 13 mV and affect the circuit less (1.3 V/A burden voltage).

The good news is that the multimeter still does auto-ranging. As you can see in the above example, 1 mA is shown with 2 significant decimals, so it’s still possible to read out ± 10 µA in this mode (don’t assume it’ll be accurate beyond perhaps ± 30 µA, though).

Can this problem be avoided? Sure. Several ways:

stick to the higher current ranges, even if that means you can’t see low values very precisely
add a Schottky diode in forward mode over the multimeter – this will limit the voltage drop to about 0.3V, even during that brief 10 mA startup peak
get a better instrument – this is easier said than done, most multimeters have a 1..100 V/A burden voltage (!)
look at Dave Jones’ µCurrent adapter, which converts low currents to a decent ± 1V range with only 0.07 V/A burden voltage

One caveat with Dave’s solution is that it is never in stock. I’ve been trying to get one for years without luck. He occasionally gets new ones made, but they tend to sell out within nanoseconds, AFAICT!

TD – PC Power Supply

In Hardware on Apr 3, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Well, not a very “deep” teardown, just opening it up and looking inside a conventional 400W PC power supply:

DSC 3003

When turned on, but not powered up, the power cunsumption is a substantial 2.8 W. IOW, that’s your computer when turned off. But the nasty surprise was that even with the mechanical switch in the off position, it still draws 0.04 W? Oh well, the sticker says “2006”, so let’s assume things have improved since then.

Here’s the top view inside:

DSC 3004

Two large heatsinks with two fans blowing air across, the bottom fan is on the outside of the case.

These caps scare me, I had it powered up briefly, so I’d probably get a jolt if I were to touch them now:

DSC 3005

Two small transformers in there, on the right. And here are three more:

DSC 3006

One last toroidial one in where the main circuitry appears to be – note the one-sided PCB with jumpers:

DSC 3007

And that board at the right is filled with varicaps, etc – noise and surge suppression, no doubt:

DSC 3008

Found a schematic of a 200 W supply on this website:

Atxps

Go to the website for the full-size view. Looking at the number of transformers, this supply is probably similar. The basic idea is simple: generate a high-frequency AC signal, and feed it through some transformers for galvanic isolation and to produce the much lower voltages at much higher currents. A high frequency is used i.s.o. 50 Hz because transformers are more efficient that way. There’s a feedback mechanism to regulate the output voltages.

The TL494 chip (which is not necessarily the same as used in this particular supply) is the heart of a PWM Power Control Circuit, which seems to drive it all. It generates pulses, and varies the ON-time as a way to regulate the generated output voltages. I think.

What I never understood is how you can regulate multiple voltages with what looks like only one feedback loop. In the schematic, the +12 and +5 V outputs are brought together as a single regulating signal through 2 resistors. What if the power draw from those 12V and 5V sections differ widely over time?

Anyway, go to that website mentioned earlier to read more about how it all works. I’m sure it does since there must be hundreds of millions of these on the planet by now…

Update – This particular unit will turn on without adding 10 Ω resistors, as sometimes suggested for lab use of such PSU’s. Voltage unloaded is 3.39V, 5.18V, and 11.99V, so close enough – with a little extra to compensate for wire losses. Big downside for lab use of such a “raw” PSU, is the nearly unlimited current that will flow with a short-circuit – guaranteed to vaporize lots of things! One solution would be to add basic current sensing and MOSFETs to switch off when pre-set values are being exceeded. With proper dimensioning, the added current drop need not be more than perhaps 100 mV, so the generated voltages would still be “in spec”. The + and – 12V would make a nice ±10V supply for analog experiments with dual-supply op-amps, for example.

Meet the Heading Board replacement

In Hardware on Apr 2, 2012 at 00:01

The Heading Board has been sold out for some time now. I’ve not been reordering it because it’s a bit quirky (needing the IRQ pin as well) and probably also not really all that sensitive.

To continue to offer a solution, I’ve decided to switch to the Modern Device 3-axis Compass Board instead:

DSC 2982

As you can see, it has a port-compatible header footprint on one side. The other side is for use with a 5V system, such as an RBBB or Arduino. Which is why there is also a 3.3V regulator on there.

The board is slightly smaller than a standard JeePlug and does not have port headers on both sides to support daisy chaining, but apart from that it’s totally JeeNode-/port-compatible. You can simply put it on the end of the chain if you want to mechanically stack this along with other I2C-enabled plugs.

Be careful about the orientation: it not the same as other plugs and there’s no “dot” next to the “P” pin.

I’ve added a very basic implementation in JeeLib to access the HMC5883 chip on this board, with demo:

Screen Shot 2012 03 29 at 15 47 17

Sample output:

Screen Shot 2012 03 29 at 15 45 34

This new board has now been added to the JeeLabs shop.

75 days and counting

In AVR, Hardware on Mar 30, 2012 at 00:01

The JeeNode Micro based on the ATtiny84 is getting more and more use around here. One of the ways it can be powered is via a CR2032 coin cell on its back:

I’ve got one with the radioBlip sketch running here, to see how long it will last on a single coin cell.

Well… today it passed the 75-day mark – celebration time!

Onwards!

TK – Basic tools

In Hardware on Mar 29, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Today just some more general notes about stuff which you probably already have: screwdrivers, pliers, tweezers, that sort of stuff. None of this is electronic – but some details do tend to matter in this context.

The toolkit I picked for this series is item 814892 from Conrad, or rather 046027, which is the multimeter plus this set, as a package deal:

814892 BB 02 FB EPS

Don’t expect top-of-the-line professional tools – just stuff which ought to work nicely. The idea is that if any of those tools break, then apparently you’re using it a lot, so maybe now’s a good time to get a better-quality version of that particular tool! – and the rest still comes in handy. By then, you’ll already have some experience, and you’ll be better equipped to pick a good brand which meets your need. It may sound crazy, but by the time you’ve managed to break all of these tools, you’ll have gained plenty of experience with each of them (or you’re handling them too roughly). Either way, it’s still worth the initial expense!

One of the tools you’ll use a lot are side-cutters, to snip off the wires of resistors, caps, etc. after having soldered these components into your circuit or onto your board. The one in this set works, but also illustrates the kind-of-average build quality of these items:

DSC 2948

The jaws will cut just fine, but they are not 100% parallel – it’ll cut better near the end (which is what matters most anyway), than inside where these cutters don’t fully close. But hey – they do work.

Other items in this toolbox are: various types of screwdrivers (flat, philips, and torque), hex spanners, and such. Nothing spectacular, but they come in small sizes – very convenient for electronics use.

There’s a little magnetic LED light (yawn), a loupe (oh so handy, at times, with SMD), and some less common utilities like a magnet on a telescopic pointer and a long “gripper” – useful to get screws accidentally dropped in some hard-to-reach spots, I suppose.

Furthermore there are two types of tweezers in this collection, a straight “reverse-action” type which opens when squeezed, and one bent to the side. Both can be extremely useful, for very different purposes: the straight one acts like a weak clip, since it springs back closed when released. It can be used to gently hold something in place while you’re soldering or measuring it (it does conduct heat, so don’t put it too close to the spot you want to solder).

The standard tweezer is an excellent example of a prolongement du corps – an extension of your body, letting you do more than you’d think possible. I prefer this “angled” type with a bend in it over straight models. It takes very little time to learn to pick up and manipulate tiny SMD components with it. I remember quite well how amazed I was when trying this for the first time with sub-millimeter SMDs – felt a bit like being a neuro-surgeon :)

None of these items are very special. You probably have most of them already. Otherwise, just be sure to get at least the side-cutters, the standard tweezers, and a loupe (or small magnifying glass) … even if you don’t do SMD.

Lissajous is tea for two!

In Hardware on Mar 26, 2012 at 00:01

When you have two nearly identical sine wave signals and you want to compare them, one technique is to plot one against the other, creating what is known as a Lissajous curve.

Lissajous curves make nice images, and even nicer videos because of the phase shifts.

So let’s take two signal generators and try it out, eh?

On the X-axis, I’m going to plot a 10 MHz sine wave from the new AWG, described on this weblog a few days ago. The frequency accuracy and stability of its output signal is within 1 or 2 ppm, according to the TG2511 specs.

On the Y-axis, let’s connect a second 10 MHz sine wave from a cheap DDS, also described on this weblog a few months back. This has a simple crystal so I’d expect 50 to 100 ppm frequency accuracy, i.e. within ≤ 1000 Hz.

When you connect these to an oscilloscope and put it in X-Y mode, you get pictures like these:

SCR40

SCR41

SCR42

The more the two signals are in phase, the more the result will look like a straight line, slanted at 45° (from the bottom left to the top right). When exactly 180° out of phase, it will show a straight line from top left to bottom right. Everything in between create ovals, and when the signals are 90° out of phase (either lagging or leading), the result is a perfect circle.

So the big thing about Lissajous curves is that they let you compare the relative phase of two sine waves.

In practice, signals from different sources will tend to change phase over time, i.e. “drift” as one sine wave is slightly slower or faster than the other. This creates a way to precisely compare two frequency generators: measure how long it takes for the phase to go from 0° to 180° (or 360°, which is 0° again), and you get an idea how long it takes for one signal to catch up (or lag) one full sine wave over the other. Trouble with this approach is that sometimes these cycles are too fast to see, let alone time manually.

With an adjustable frequency source, there’s also another way: adjust a known frequency until the shape stays the same, and you’ll have “measured” the frequency of the other signal in terms of the adjusted one since they must now be equal. It’s very much like tuning a musical instrument by ear and adjusting for a “zero beat”.

That’s what I did, and I ended up with the following result for this test setup:

DSC 2967

IOW, the cheap DDS is running 0.03% slow – i.e. about 300 ppm! And it’s not even very stable, because very soon the DDS starts drifting again: an indication that it’s not holding its frequency really accurately either. This is not really surprising for such a low-cost unit off eBay – it’s still a useful signal source: lots of useful experiments and measurements can be done with such a fairly decent 0.03 % accuracy level, after all.

Ok, this concludes my first exploration into signal-processing – enough signal theory for now!

Noise levels

In Hardware on Mar 25, 2012 at 00:01

Triggered by the recent signal generator checks, and those FM radio stations creeping into the signal yesterday, I wanted to do another test to see how and when this happens, using a series of scope FFT snapshots.

Here’s a 50 Ω coax cable of 2m length hooked up, with 50 Ω termination on both sides but no signal. The scale is 5 dBm per division, and I’ve zoomed into this very low range with a baseline of about -105 dB. The following 200 MHz wide FFT measurements were all done with the scope input set to max sensitivity, i.e. 1 mV/div:

SCR35

Note the slight FM radio station RF signal pickup, even with a fully terminated coax cable!

Same thing, but disconnected on one end, i.e. only one 50 Ω terminator inside the scope:

SCR36

I don’t know why there’s a peak at 25 MHz – the signal generator was completely powered down.

Here’s the spectrum with no coax at all, i.e. nothing connected to the scope, but its 50 Ω shunt still enabled:

SCR37

When also adding an external 50 Ω terminator, the lower frequencies drop ever so slightly further:

SCR38

And here’s what happens when the 2m 50 Ω coax cable is attached back on, without the 50 Ω termination:

SCR39

As you can see, the coax cable now acts as antenna, picking up a few more signals at 38.45 MHz and 46.38 MHz. And FM reception shooting up to 20 dB above the noise floor. Even though it’s shielded!

The slight drop in noise across the screen from 0 to 200 MHz is probably nothing more or less than the scope’s bandwidth: a 200 MHz scope is specified as having a 3 dB drop at 200 MHz, which fits amazingly well with what all the above screen shots are showing.

These tests confirm the superb signal processing specs of the Hameg oscilloscope front end: a -105 dB noise floor @ 1 mV/div maximum sensitivity. For even lower noise levels (and a higher frequency range, as would be needed for 868 MHz and 2.4 GHz RF measurements), probably only a “real” spectrum analyzer will do better.

Whee… with a multi-meter probe wire attached as antenna, I can easily pick up all major AM radio stations:

SCR45

Tomorrow, I’ll close off with one more post about signal processing: accurate frequency measurements.

Update – As with yesterday’s post, these FFT’s were produced with the Rectangle window function. As a bonus, here’s the frequency spectrum produced by the noise generator in my new AWG:

SCR60

Down by 30 dB at 50 MHz, but a pretty good source of white noise at lower frequencies. The AWG can add an adjustable amount of this noise to the generated waveforms – can be useful to see how well a filter, demodulator, or other detector behaves, for example.

RF Shielding

In Hardware on Mar 24, 2012 at 00:01

As shown in yesterday’s post, once you’re looking at signals in the high MHz range, it’s easy to make mistakes. Looking at that screen shot again, you can see a whole bunch of 90..100 MHz spikes:

SCR32

These are in fact local FM radio stations – being picked up by my clunky scope probe hookup to the AWG. In other words it’s an antenna: radiated RF signals are accidentally being received by the probe and mixed in with the conducted 25 MHz signal. The way to get rid of these is to use “shielding” to keep those radio waves out.

Here’s the same signal, using a 50 Ω coax cable all the way between signal generator and oscilloscope:

SCR34

No more weird stuff, just the 25 MHz multiples – indicating that there’s a slight distortion in the generated 25 MHz sine wave. This is normal for any signal generated by a direct digital synthesizer, because the waveform is created through through a digital-to-analog converter, fed at 125 million samples per second in this case. IOW, it’s an approximated sine wave (20 datapoints per sine wave @ 14-bit resolution).

So the big change is that the FM radio stations are gone, and that the signal’s noise level is now in fact a few dB cleaner than before – as you can see from the slightly lower tail towards 200 MHz.

I did have to use a small trick to make these graphs comparable: the second one has the scope’s 50 Ω internal terminator enabled, so that the path from signal source to signal destination is now done by the book: a 50 Ω source (in the AWG), feeding a 50 Ω coax cable, terminated by 50 Ω at the destination (in the scope). This does “attenuate” (i.e. reduce) the signal level by half, so I had to raise the baseline by 3 dB on the second FFT screen shot to make the height of the 25 MHz peak identical in both screens.

One other minor difference is that the second graph is smoothed over 256 samples i.s.o. 64 – cleaning up the resulting line slightly more.

So you see… it’s possible to do RF-type stuff without understanding all the details – which I certainly don’t, yet – and get decent results. The 25 MHz wave coming into the scope is very clean: the first harmonic is some 50 dB below the signal itself, which means that the first harmonic has 100,000 times less energy than the main signal.

Tomorrow, another post about this topic: cables, termination, and noise…

Update – As John Beale pointed out in the comments below, the FFT baseline is caused by the choice of FFT windowing function. Here’s the 50 Ω coax example again, using a Hanning window:

SCR59

Much better for comparing relative dB differences between peaks.

(Tomorrow’s post will also use the default Rectangle window, sorry about that…)

Arbitrary Waveform Generator

In Hardware on Mar 23, 2012 at 00:01

Earlier this week, I described how a fixed frequency can be used to stabilize others.

Well… as part of my continuing drive to set up a more complete workbench here at JeeLabs, I’ve decided to get another piece of equipment which relies on this mechanism, called an “Arbitrary Waveform Generator” (AWG) or “function generator” or “signal generator” – three names for essentially the same instrument, as far as I can tell.

An AWG produces a repetitive electrical signal, such as a sine wave or a square wave. Very roughly speaking, you can think of sine waves as “pure analog” and square waves as “pure digital” frequencies.

The unit I picked is a fairly advanced one, the TG2511 from TTi (Thurlby Thandar Instruments), in the UK:

DSC 2966

(Check out that box underneath – as a reference it now makes a lot more sense, eh?)

It produces sine waves and square waves up to 25 MHz, and has tons of other waveforms built in, including ramp, triangle, pulse, noise, and more. In fact, since it’s an AWG, you can load any waveform shape into it, and it’ll reproduce it at up to 125 Mega-samples per second and 14-bit resolution (it goes up to 6 MHz in this mode).

Two other major capabilities of such a unit are: the ability to “sweep” across a range of frequencies and being able to “modulate” the generated signal with another one in numerous ways: AM, FM, PM, PWM, and FSK.

As with the Hameg HMO2024 oscilloscope and the GW-Instek GPD-2303S power supply, this thing can be remotely controlled over USB. So it can be driven from a computer to perform complex and/or lengthy tests.

This model does more than I need, but there was a good “price burner” offer at Distrelec, so I decided to go for it. Function generators are not the most important instruments for an electronics lab, but they are extremely useful to learn about all sorts of analog electronics, and to illustrate various concepts and effects “for real”. Note that for lower frequencies, you can generate rough arbitrary waveforms with simply an ATmega and a few resistors.

Here’s the FFT spectrum of its 25 MHz sine wave – a few spikes at 25 MHz multiples, as expected, plus a bunch of 90..105 MHz spikes which also appear when the AWG output is off (more about those tomorrow):

SCR32

Such an AWG is not limited to strictly analog uses, by the way. This unit should also be able to generate a serial bit-stream, like an RS232 message, for example. Such patterns can be loaded via USB on the front panel.

I intend to put this instrument to good use here at JeeLabs, not in the least to create good examples for future weblog posts and to illustrate relevant electronics concepts in that huge playground called Physical Computing.

TK – Multimeter

In Hardware on Mar 22, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

One of the tools you don’t strictly need, but which I very strongly recommend getting, is a multimeter.

A multimeter measures stuff. I picked the Voltcraft VC170, Conrad’s own (re-)brand (item 124403):

DSC 2947

Actually, my suggestion for this series would be to get item 046027, which includes a whole set of additional tools for only €12 extra. It won’t break the bank, and it gets you various screwdrivers, tweezers, a simple loupe, a lamp, and a few more items.

Anyway, back to the multimeter. Trust me – this is one of those lab instruments which will enable you to learn more about electricity than anything else. And this is one of those cases where a small amount of money will go a huge way – this particular unit lets you measure voltage, current, resistance, frequency, and more. The VC170 even does non-contact AC mains sensing, to detect live wires from a short distance.

I’ve got over half a dozen multimeters by now. Low-cost as well as expensive / more accurate ones. My favorite one is this VC170 (or rather, its predecessor, the VC160 which I’ve been using for several years now). Why? Because it’s very small, it’s fast and responsive, and it offers an excellent set of trade-offs.

Some more expensive ones are very sluggish (but also produce considerably more accurate 5-digit readings), some beep very annoyingly all the time, and some don’t have the sensitivity you need. Of all the multimeters I have, I end up using my trusty VC160 most of the time. It does what I need, and it doesn’t fill up my desk.

You can’t really go wrong with this. You’ll want more than one multimeter if you really get into electronics. Here’s a not-too-contrived example: measuring incoming and outgoing voltages of a power regulator at the same time, as well as incoming and outgoing currents – that’s 4 multimeters! So by the time you want a more advanced one, this first unit will still come in handy in certain use cases.

The good news is that one is fine for a huge range of situations. This one will measure up to 230 VAC mains (with a small caveat, see below), and all the way down to fractions of a µA of current (ultra-low power, anyone?).

Learning how to make the most of a multimeter is a story far beyond this initial Thursday Toolkit series. But it’s really easy to get started and learn along the way. Even just fiddling with a resistor, or a capacitor and a resistor, and measuring what happens in various hookups can be a great way to understand Ohm’s law, and all the basics of electronic circuits. Do two resistors in series draw more or less current? What is the resistance of two resistors in parallel? How much voltage are my near-dead batteries giving out, and how are they performing under load? Is that power supply doing what it’s supposed to do? And perhaps most important of all: are the proper voltages being applied to the different parts of my circuit? Trivial stuff with a multimeter – you can simply measure it!

Multimeters are very robust, especially auto-ranging ones like this, which can take any voltage and figure out all by themselves whether it’s over 100 V or in the millivolt range. But there are ways to break things. Big currents always tend to cause trouble, and even the best multimeter won’t be pleased if you push a few amps through it while it’s trying to measure microamps. Which is why the above set of input jacks is actually quite nice: voltage and current are very different quantities, and you have to hook up the measuring cables in specific ways to measure the different types of units. But mess-ups do happen… I’ve blown fuses inside my multimeters a few times – fortunately, they are easy to replace.

All multimeters have trade-offs. This one gets many of them right though, and does auto-ranging.

Then again, this multimeter seems to be at its limit when asked to measure 230 VAC, i.e. AC mains around here. It displays “OL” (overload). But it can measure 230 VAC just fine when using the “Select” button to fix it to the maximum range before doing the measurement.

The other thing is not to get carried away by the 4-digit display. You’ll be able to measure 3999 vs 4000, but that’s not an absolute accuracy, i.e. you shouldn’t expect to be spot on when measuring 3.999 V versus 4.000 V – the accuracy is only about 1.5 %, so it might well be 3.940 V, or 4.060 V. The only purpose this serves, is to show you slight fluctuations – fairly accurately. So it might be off a bit, but you will be able to see small dips and increases in voltage, current, resistance, etc.

And to be honest: 1.5 % accuracy is actually pretty amazing for such a low-cost instrument, if you compare it to the old analog multimeters which you had to read out by estimating the position of their needle!

The VC170 added a function I’ve dearly missed on the VC160: frequency measurements. Its specs says that it works up to 10 MHz, but a quick test here tells me that it’ll work up to at least 25 MHz with a 1 Vpp signal (wait for tomorrow’s post to find out how I tested that). The frequency range is in fact very convenient for microcontroller debugging of timing loops, for example – I’ll go into this in a future post.

So much for the multimeter. If you solder electronic circuits together, all I can say is: get one!

TD – Cost Control

In Hardware on Mar 20, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Over two years ago (gosh, time flies), I reported about a low-cost AC metering device called Cost Control:

It seems to be available from several sources, not just Conrad and ELV, under different brand names. Not sure they are identical on the inside, but the interesting bit is that they transmit on 868 MHz and seem to go down to fairly low power levels as well as all the way up to 16A:

DSC 2976

So let’s have a look inside, eh? Here’s the back side of the PCB:

DSC 2971

No much to see, other than a thick bare copper wire, which probably acts as the shunt resistor.

The rest appears to be built around 3 main chips, two of which are epoxied in, so I can’t see what they are:

DSC 2970

Flipping this thing over, we can see the different sections. I had expected a special purpose AC power measuring chip, but it looks like this thing is built around a quad LM2902 op-amp:

DSC 2972

Note the discrete diode soldered on the flip side – the topmost solder joint looks pretty bad!

The rest of the analog circuitry and the MPU of some kind running at 4-something MHz is here:

DSC 2974

The 24LC02 is a 2 Kbit I2C EEPROM, for the node ID and some calibration constants, I presume.

And here’s the wireless transmitter, running off a 16 MHz crystal:

DSC 2975

Being 16 MHz, it’s a bit unlikely that this is a HopeRF RFM12B (or its transmit-only variant), alas. The blob at the center bottom goes to an antenna wire on the other side of the board.

Would love to be able to decode the wireless signal (1 packet every 5s, very nice!). Either that, or find out how they are measuring the power from 1..3600W – the remote actually displays in tenths of a Watt.

PS – See also this forum discussion about decoding.

Pick a frequency – any frequency

In Hardware on Mar 19, 2012 at 00:01

A week ago, there was a post about various clock options and their accuracy.

These clocks generate a stable pulse or sinewave, basically. But what if you need a different frequency?

Suppose you get a very accurate 1 pulse-per-second (i.e. 1 Hz) signal from somewhere, but you want to keep track of time in microseconds? IOW, you need a 1 MHz clock, preferably just as accurate. One way to do this, is to use a “Voltage Controlled Oscillator” (VCO). It can be any frequency really – the idea is to divide its output down to 1 Hz and then compare it with your reference clock. If it’s either too slow or too fast, adjust the voltage used to set the precise frequency of the VCO, and bingo – within no time (heh, so to speak), your VCO will be “locked” onto the reference and generate its target frequency, at just about the same accuracy as the 1 pps reference.

My Rubidium clock came with a 63.8976 MHz VCO as part of the bargain:

DSC 2920

With no control voltage it generates a sinewave-ish very high frequency signal from just a 3.3V power supply:

SCR27

That frequency is not as awkward as it looks: 638976 = 3 * 13 * 16384, so you can get 100 Hz out of it with a few simple dividers, as well as any integral fraction of that (including 1 Hz). Another way of going about this is to divide the clock by a simple power of two, say 256 or 4096, and then pass the resulting square wave to an ATmega’s timer/counter input. I haven’t hooked up this VCO to the Rb clock yet, since there’s a bit more logic involved – look up “phase locked loop” (PLL) if you’re interested.

Another source of very stable clock signals is the GPS navigation system (see also this note). Their clocks ~~are~~ used to be made a little bit jittery for civilian use, but this averages out over time, so you can still lock onto it and get a very accurate long-term reference. Look up Allen variance to find out more about short- vs long-term stability – it’s fascinating stuff, but as with most things: once you get into the details it can become quite complex.

To summarize: with a VCO you can produce any frequency you like given some stable reference. So I’m happy with my 10 MHz @ 10 ppt atomic clock, for those rare cases when I’ll need it. And for its geek factor, of course…

Do all these extreme accuracies matter? Well, apart from TDMA, think of it this way: an 868 MHz RFM12B wireless radio with 1 ppm accuracy may be off by 868 Hz. That’s no big deal because the RFM12B’s receiver uses Automatic Frequency Control (AFC) to tune itself into the incoming signal, but with bandwidths in the kilohertz range, you can see that all of a sudden a couple of ppm isn’t so academic any more!

Detecting a blinking LED

In Hardware on Mar 18, 2012 at 00:01

There are several scenarios where it’d be nice to detect the pulse of a blinking LED – especially low-power, because then we can sense it with a long-lasting battery-powered setup, such a JeeNode or JNµ.

Fortunately, that’s fairly easy to do. I used this test setup to try things out:

Screen Shot 2012 03 16 at 12 53 12

The left-hand side is a test pulse, generating 10 ms pulses once a second to simulate a typical indicator light. It’s simple enough with no further explanation needed.

The right-hand side of the above circuit is the actual pulse sensor we’re trying to implement. It’s a voltage divider with on the upper half a fixed resistor (well, a trimmer, but we only have to adjust it once) and the lower half is a Light Dependent Resistor (LDR) – like these two examples:

DSC 2968

We want to generate one electrical pulse for each incoming light pulse, in such a way that it could trigger an ATmega’s digital input pin. With a clean pulse we could then set up a pin-change interrupt and keep the ATmega asleep most of the time.

The trouble is that LDR’s and voltage dividers are analog i.s.o digital. One way would be to constantly read out the signal as analog input. But this sort of polling and continuous ADC use eats up quite a bit of power – a digital signal would be a lot better as it’d allow us to use pin-change interrupts.

No worries. A digital signal is also a voltage, but it has to stay under a certain limit to be treated as digital “0” and above another limit to act as digital “1”. Here are the specs from the ATmega328 datasheet:

Screen Shot 2012 03 16 at 13 05 15

With a JeeNode running at 3.3V, we get: “0” ≤ 1V and “1” ≥ 2V. Note that in theory voltages between 1 and 2V will have indeterminate results, but in practice the signal will work fine as long as it doesn’t stay forever within that gray zone.

The trick is to make that LDR sensor as sensitive as possible. The LDR which I used is a fairly standard one (same one as included with the Room Board) and rises to over 1.5 MΩ resistance when dark. Let’s assume 1 MΩ as extra margin, then we could use 470 kΩ as upper resistor of the above resistor divider, and the resulting signal would be about 2.2V when dark.

The way I maximized the dark-state resistance was to place it in a small black plastic cap, as shown in the above photograph. This is essential, as you’ll see.

Now the actual pulse detection: the resistance of an LDR drops (quite dramatically) in the presence of light, so the trick is to place it close enough to the blinking LED that we want to “read out”. I placed my blinking test LED a few millimeteres from the black cap (which is open at the end, of course);

DSC 2969

Here’s a scope snapshot of the LED pulse (channel 1, yellow trace) and the detected signal (channel 2, blue trace):

SCR47

You can see the LDR signal dropping when light is detected, and that the LDR actually needs a bit of time to react. For 10 ms pulses, it’s plenty fast enough, though.

This configuration is probably ok – the voltage swings from about 1.8V (a marginal “1”) down to 0.7V (a clean “0”). The whole setup really depends on first getting the dark resistance as high as possible (i.e. shielded from any stray light) and pulling it down enough during the LED blink (i.e. close enough to pick up a good LED signal).

When the LED is inserted inside the plastic tube, the signal becomes much stronger – but recovery is slower:

SCR48

It all hinges on the pull-up resistor, really. Which is why the best way to create this sensor is to use an adjustable 1 MΩ trimpot, and tweak it. You won’t need an oscilloscope or even a multimeter to get optimal results:

very important: shield the LDR from stray light as well as you can
pick as high a resistance as possible which still gives a “1” signal (between 100 kΩ and 1 MΩ)
place the LDR + shield near enough to the LED to generate a “0” pulse
tweak and iterate the above steps until it works reliably under all conditions

For minimal power consumption, the pull-up resistor should be as large as possible. Example: with an optimal pull-up of 1 MΩ and the LDR’s dark resistance about 1 MΩ as well, the quiescent current draw will be (Ohm’s law: I = E/R) 3.3 V / 2 MΩ = 1.65 µA, an excellent value for ultra-low power nodes. During the LED light pulse, this will increase to at most twice that (i.e. if the LDR resistance were to drop completely to 0 Ω).

Note that a more sensitive sensor design will be needed if you want to actually measure the length of the pulse with a decent accuracy, but for simple counting purposes where incident light can be kept out, there is nothing simpler than this LDR + pull-up trimmer, probably.

Update – More info about LDR’s on the LadyAda site.

▶ View 18 Comments

Another PIR sensor

In Hardware on Mar 17, 2012 at 00:01

Someone drew my attention to a very small PIR sensor on eBay:

DSC 2962

The size is great, of course – but the current consumption isn’t: I measured 1.9 mA idle current @ 5V.

The other inconvenience, in the context of JeeNodes, is that this sensor expects a 5..9V supply voltage.

Using my new accurately adjustable power supply, I was able to establish that it actually works all the way down to 3.6V – with current consumption down to 1.3 mA. But that’s still far from the 50 µA current consumption of the PIR sensor used in the Room Board, so this rules out ultra-low power battery nodes. The detection range is specified as 2 to 3 m, not stellar but probably enough for many uses.

Here are the two sides of this really tiny sensor (whoops, I accidentally cracked the lens):

DSC 2963

DSC 2964

The chip marked 7144-1 appears to be a 4.4V LDO regulator, with excellent < 5 µA idle current and 0.06 V drop-out voltage under light load, but that seems to point to a circuit which really expects to run at 4.4V internally.

I have no idea what this spec means on the eBay page:

It’s definitely not referring to the idle power consumption of this sensor. Too bad!

Should we try and design our own PIR sensor? I wonder what that would take – some way to stabilize on an average detector level, and then detecting changes in that value? Using an ultra-low power op-amp?

TK – Soldering Iron

In Hardware on Mar 15, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

The very first tool you’ll need – inevitably – when going beyond breadboards and wire jumpers to hook stuff together, i.e. when building things which need to become more or less permanent, is a soldering iron.

A soldering iron is just a heater which gets hot enough to melt solder. For the solder used in electronics, the iron’s tip is usually kept at between 275°C and 375°C. That’s more than hot enough to give you a serious burn when touched. So the whole idea of a soldering iron is really to get that heat in the right place, while giving you a way to hold the thing and manipulate it fairly precisely.

There are tons of different models, costing from €10 to €1000. The idea here is to pick one which doesn’t burn a hole in your pocket (heh, turned off, I mean :) – The target I’ve set myself for this initial Thursday Toolkit series is to be able to get all the tools you need for having oodles of fun with various Physical Computing projects for a total of under €150.

That rules out a lot of soldering irons, and forces use to focus on two essential features, i.e. that the soldering iron has enough heat to work well, and also has some sort of basic temperature control. A soldering iron which is too cold will be an awful time-consuming hassle, but one which is too hot will burn and damage electrical components, and will oxidize the solder much too quickly. The big fat uncontrolled “after-burners” used by electricians and plumbers are not suitable here.

As mentioned in the initial post, I decided to buy all the tools at Conrad, item 588417 in this case:

DSC 2940

(just the iron and the two tubes at the left are included – the rest was ordered separately)

What I like about this 45W unit is that it has a solid base and sort of a temperature control, letting you regulate how much heat gets generated. This is definitely a low-end unit. Another option, with a better (smaller!) soldering iron, is the Aoyue 936 (here’s a link to a Dutch shop carrying this particular model).

The Conrad unit is a soldering iron heated at 230 VAC. Let’s have a look in close up:

DSC 2942

It’s all about heat, and keeping it away from your hand. You hold it like a big pencil or marker, and after an hour or so of use, you’ll note that the middle of that thing gets warm, but not too hot – which is the whole idea. The metal part is the hot end, as you’ll quickly find out once you touch it and get a nasty burn. Trust me, you will get burned at least once – it comes with the hobby…

As I said, this is a low-end unit. One of the compromises is that the hot end is fairly large – so holding this thing steady and accurately placing the tip where you want it takes some practice. But no worries – everyone starts out this way, and many of us keep on working with such a unit for years. It works fine.

The other compromise is that this unit isn’t really controlled by a thermostat, it’s really just trying to keep the tip at a somewhat constant temperature, based on thermal flow in free air. Let’s take it apart:

DSC 2945

The shiny metal barrel is the heater. Some nichrome wire, wound inside an isolated jacket no doubt. Much like toasters, hair driers, etc – but only 45W. In the middle sits a big metal core, with the pointy tip we’ll be soldering with. Its main task is to conduct the heat to the tip, and being such a large piece of metal, it’ll keep a reasonably constant temperature, even when the tip touches the copper and wires of the circuit being soldered.

There are two heat-insulated wires to the heater, powered from AC mains. The third wire is ground, and is attached directly to the barrel. This provides three types of safety: 1) if the heater breaks down, it’ll cause a short to ground and blow your AC mains fuse instead of electrocuting you, 2) if you accidentally burn through a wire carrying AC mains current (such as the soldering iron’s own!) it’ll also blow a fuse, and 3) the tip of the soldering iron is at ground potential, so any static electricity around your circuit will be conducted safely away from the sensitive electronic parts.

Then there’s the base, where the hot soldering iron is kept between your soldering work. Note the metal spring / holder, which keeps soldering iron itself hot, but tries to stay reasonably cool to the the touch on the outside. You’re not going to get burned touching it – just a quick reminder that there’s something very hot inside!

And then there’s this thing:

DSC 2943

That’s actually a synthetic sponge. It’ll probably make more sense once you soak it in water:

DSC 2944

Part of the skill needed to solder stuff together, is to keep a good clean soldering tip. Solder tends to oxidize, so over time you’ll get in the habit if wiping that scorching hot tip clean and applying fresh solder. The wet sponge is one way to clean that tip – it’ll sizzle and scorch a bit, but it works fine.

So much for the venerable soldering iron. Get one, don’t go overboard on features (a small size is great, but it’ll cost ya’). Far more important is to get a decent one and practice, practice, practice! – I won’t go into the actual soldering skills here, there are plenty of articles, books, and weblogs on internet, so my suggestion would be to just google around a bit. And then: practice – there’s no magic pill around that.

Next week, I’ll go into one of the best other investments you can make – apart from the soldering iron.

Accurate power supply

In Hardware on Mar 14, 2012 at 00:01

My existing lab power supply delivers 30V @ 3A, which is more than enough for normal use, but it uses linear fine + coarse potentiometers, which are in fact not optimal for really fine adjustments. I’ve been using it a lot, and I really have been wanting something more convenient for quite some time.

So I decided to get a second and more high-end unit, the GW-Instek GPD-2303S:

DSC 2950

It even comes with a “calibration certificate”, FWIW:

DSC 2951

There are many lab power supplies out there, and I intend to come up with a really good option for low end use in the context of the Thursday Toolkit series, but I’ve got enough future projects piled up here to justify this instrument for JeeLabs. Everything other than the ultra-low power experiments will benefit from this.

BTW, if you’re looking for a DIY design which is coming along very nicely, check out the EEVblog episode list, where Dave Jones has over ~~half~~ a dozen fascinating videos about how he is designing a really nice Arduino-compatible power supply, with all the bells and whistles you might be after: finely programmable voltage and current range, an LCD display, rotary switches for adjustment, etc. Here’s the first one in the series.

The GPD-2303S delivers 2x 30V @ 3A, i.e. up to 180W of controlled DC power. There’s a 3-channel unit with extra 2.5/3.3/5V output, even a 4-channel unit, but I’ve got enough supplies here now to cover such needs.

Note that lab power supplies are designed to “float” w.r.t. ground. The reason for this is described in my two weblog posts here and here. So you can hook them into your setup in any way you like. Even doing some totally crazy stuff like a adding a 50V DC component to AC mains would be possible…

Anyway. The nice thing about this supply (even though its shape is a bit deep for my workspace), is that it includes two independent supplies which can be used in series (double the voltage) or in parallel (double the current) to get 0..60V or 0..6A capability, and that both voltage and current can be controlled and measured very accurately (not quite down to the 1 mV/mA levels as they claim, but close).

This power supply is not a really high-end one, though (which would cost even more), since there is no remote sensing, for example. So small losses over the cabling are not compensated for. I’m not too worried, because with large currents I’m usually not really concerned about 10 mV error.

More important is that it’s a linear power supply with only 1..2 mV ripple, and that the current limit can accurately be set to very low levels. By setting it to 50 mA, say, you can avoid most damage when hooking up things the wrong way – as so often happens while messing around with circuits.

Also very nice is that this unit is programmable – meaning that you can control it fully via USB. That opens the door to all sorts of stress and limits testing, i.e. plotting the effects of a slow voltage ramp on a circuit, for example.

Sooo… with this new addition to JeeLabs, I hope to stay out of Mr. Murphy’s path a bit more!

TD – KAKU remote switch

In Hardware on Mar 13, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode is about the “KlikAanKlikUit” remotely controlled AC mains switches, a.k.a. KAKU.

I’m going to look at two different units, the older/smaller/cheaper PAR-1000 supporting 16 different addresses, and the newer YC-3500 supporting up to 256 different addresses and switching up to 3500W:

DSC 2956 DSC 2955

Here’s the PAR-1000, once opened (you need a TX9 torque screwdriver for both units):

DSC 2957

There’s a .22 µF X2 cap as transformer-less power supply, in series with a 100 Ω resistor (hidden in black heat shrink tubing, bottom right, next to it). According to this calculator, you can get up to 12.2 mA out of that, when using a bridge rectifier (which is under the cap, using discrete 1N4007 diodes).

The measured power consumption is 0.58 W. Note that due to the way these transformer-less power supplies work, this power is always consumed, whether the relay is turned on or not.

There’s an interesting post-production “mod” in this unit, on the relay, i.e. top middle in the above image. After removing the tiewrap and glue, this interesting part emerges – in series with AC mains:

DSC 2960

I’m guessing some sort of overheating protection for the relay, a PTC resistor?

Here’s the copper-side of the PAR-1000’s PCB, with what looks like lots of solder flux residue:

DSC 2959

And here’s the YC-3500, in a slightly larger enclosure and using a relay which can switch up to 16A:

DSC 2958

Same 100 Ω resistor but beefier 0.33 µF X2 cap, bringing the maximum current to 18.2 mA. Measured power consumption is 0.81 W – what a waste for an always-on device which is merely switching another device!

Here’s the underside of the YC-3500’s PCB:

DSC 2961

Both single-sided non-epoxy PCB’s have SMD’s on one side and through-hole parts on the other, but the amount of solder on the SMD side suggests to me that everything has either been soldered on by hand or glued on and wave-soldered. The extra solder on the left increases the PCB’s current carrying capacity, BTW.

These 433 MHz units respond to simple packets using the On-Off-Keying (OOK) protocol. There’s no way to control them directly, other than via RF – and even if there were, there would be no way for a home automation system to know their state since these units are receive-only. The relay is off after power loss. There’s an LED to indicate the actual on/off state. The choice of 24V relays is wise – needs much less current than 5V and 12V ones.

Note the 433 MHz antenna – a single loop of copper wire in one case, and a loop plus coil in the other!

Summary of clock options

In Hardware on Mar 12, 2012 at 00:01

Tracking time is as old as… well, time itself really. FWIW, I stopped wearing a wristwatch about a year ago. When traveling, I often don’t have a convenient way to tell the time with me. I like it that way because it pushes me to leave a bit earlier and enjoy the journey a bit more, instead of stressing out to reach some location on earth at some particular point in time. “Onthaasten” as the Dutch say (“un-hurry”).

That wristwatch was one of the most beautiful time-pieces I ever owned, and darn accurate – less than a minute off per year. More than accurate enough for day-to-day use without ever adjusting it (except for DST).

Still, time is everything. Cell phones make very efficient use of bandwidth (and energy) by using time-division multiple access (TDMA), i.e. taking up specific time slots to get a transmitter to talk to the receiver it wants to reach, without collisions. It’s a common technique in many advanced networks, not just with cell phones.

TDMA requires all parties to be aware of time. No wonder that cell-phone towers need the Rubidium clock I described in the past two days. If your timing is off, you end up jamming others, and to avoid that the system then needs to introduce wider gaps around each slot. More gaps = more time & energy wasted, as each unit has to wait longer in receive mode to be certain it picks up the entire packet, and more gaps = more unused bandwidth.

For good timing, you need to have every node in sync within a millisecond or so. Perfect timing means a receiver can turn on exactly when the transmitter starts, and switch off right after the end. But the need for exact time is bad news for the simplest ultra-low power nodes, which tend to use an RC-controlled watchdog timer for the sleep modes. On an ATmega, watchdog accuracy is only about 10% in the worst case:

Screen Shot 2012 03 10 at 14 50 24

Ok, time to get into some terminology…

one percent (%) is 1 per 100, of course
one part per million (ppm) is 0.0001 percent
one part per billion (ppb) is 0.0000001 percent
one part per trillion (ppt) is 0.0000000001 percent

It’s easy to make mistakes with so many zero’s, so let’s approach it from another angle: a year has about 31.5 million seconds, so let’s specify time accuracy in the amount of error over a year. And let’s not fuss over 50%, I’ll round things up or down a bit for convenience.

My trusty old Seiko Lasalle wristwatch:

estimated 1 min/year, i.e. an astoundingly good 2 ppm

ATmega watchdog accuracy:

worst case: 10 % = can be over a month per year off
if supply is 3.3V ± 0.1V and temp is 25°C ± 10°C: 1 % = within 3 days per year

The 16 MHz resonator used in a JeeNode:

0.5 %, i.e. less than 2 days per year off

The crystal normally used in RBBB’s, Arduino’s, RTC’s etc:

50 ppm, i.e within half an hour per year

The more accurate crystal used in a JeeLink:

10 ppm, i.e. within 5 minutes per year

The Precision RTC Plug, which will be released later:

2 ppm, i.e accurate within 1 minute per year

The calibrated Temperature Compensated Crystal Oscillator (TCXO), mentioned recently:

0.1 ppm, i.e. within 3 seconds per year

And then that new Rubidium clock:

10 ppt, off by no more than 0.3 milliseconds per year

Cesium clocks can do even better, by the way:

0.01 ppt, no more than 0.3 microsecond per year

And how’s this Quantum Logic Clock, mentioned in one of the recent comments:

less than 0.3 nanoseconds off per year!

The clocks mentioned so far all try to be spot on as best as they can. That’s what a clock is for, after all.

But that’s not all there is. Next week I’ll describe how a fixed reference can be used to stabilize any frequency.

Rubidium Clock – part 2

In Hardware on Mar 11, 2012 at 00:01

After yesterday’s intro of my “get your own atomic clock”, which is really just doodling, here’s the next step:

DSC 2952

The clock, and the PCB panel it came attached to, has been placed in an all-plastic enclosure along with a little 15V @ 1.7A switching power supply. This thing needs quite a bit of power and actually gets quite hot. Nevertheless, I expect that placing it inside this relatively small plastic enclosure will not be a problem because much of the heat seems to be generated simply to keep the Rubidium “physics package” inside at a certain fixed temperature. For that same reason, I suspect that the heat sink on which this clock is mounted is not so much meant to draw heat away, but to maintain a stable temperature and improve stability.

Speaking of stability… here are the specs of this unit from eBay:

Screen Shot 2012 03 10 at 13 26 51

To get an idea: 10 to the power -11 frequency stability is less than 0.3 milliseconds per year error!

This particular unit (they are not all identical, even when called “FE-5680A”) also needs a 5V logic supply.

I haven’t yet decided how to bring out various signals, so I’ll hook up the 50Ω BNC connector on the back first and wait with the rest. Also needed: a LED power-on light, LED indicators for the “output valid” and “1 pulse-per-second” signals (via a one-shot to extend the 1 µs second pulse), and a 7805 regulator. Here’s the front – so far:

DSC 2953

I don’t intend to keep this energy-drain running at all times, but it’ll be there at the flick of a switch to generate a stable 10 MHz signal when needed. One of the things you can do with it is calibrate other clocks, and compare their accuracy + drift over time and temperature.

Geeky stuff. For a lot more info about precise time and frequency tracking, see the Time Nuts web site.

Tomorrow, I’ll describe some of the trade-offs w.r.t. time for JeeNodes and wireless sensors.

Now THAT’s a clock!

In Hardware on Mar 10, 2012 at 00:01

Triggered by a video on EEVblog of a Rubidium frequency standard and its teardown, I decided to get one myself. These things are available from eBay for around €40 these days, as recalls from cellphone towers, apparently:

DSC 2919

It’s about the size of a hard drive, it’s completely closed, and there really is nothing to it – connect power, wait a few minutes for things to stabilize, and out comes a 10 MHz signal – a perfect black box:

SCR25

There’s a capacitor in the output circuit, so the resulting signal is AC-coupled and hence centered around 0V and 1.5 V peak-to-peak. There’s also a 1 pulse-per-second (PPS) output signal, with a 1 µs pulse (at first I thought it didn’t work, but the pulse is really there).

The big deal about such a Rubidium-based atomic clock is its accuracy. More on this tomorrow…

Thursday Toolkit

In Hardware on Mar 8, 2012 at 00:01

Welcome to a second new initiative on this weblog: a weekly series about tools, i.e. the stuff you can use to design and create stuff, in the context of Physical Computing, that is. Again, you can bookmark this Toolkit link to find back all the related posts on this weblog, now and later.

People regularly ask about what to get, how to get started, and sometimes I see comments indicating that maybe a few basic extra investments might help understand and fix a problem much quicker.

Tools can be anything: the soldering iron you use, various electronics “lab instruments”, but also the software you use, and even the computer setup you work with. There is no “best” answer. It’s all matter of goals, interest levels, amount of involvement, and of course budget.

What I’d like to do is start off this series from scratch. I vividly remember the time when I re-booted my interest in electronics a few years ago and started JeeLabs to get into Physical Computing. It was very confusing. Do I get the best tools money can buy? Sure, dream on, but if going broke is not an option, what do I get first? When should I buy specific items? Which items are risk-free? Is really everything required? What’s “everything”, anyway? What would be the absolute minimum? Is this the start of never-ending upgrades?

Unknown

The good news is: you can start having immense fun, and learn, and build stuff for less than the price of an Xbox. To draw on a theme from Alice in Wonderland: you can pick the red pill or the blue pill, it’s all up to you. The red pill is: watch videos, play games, surf and consume, follow the pack, compare yourself (and keep up) with others. The blue pill is: launch yourself into a new adventure, find out what so many explorative minds before you have invented, discover the gift of boundless learning, and start contributing to change the path of the future – your own, of your friends, of your community, or maybe even of your whole world. It’s all possible, these journeys are totally real (and indeed also non-virtual). Today. Now!

The even better news is, that these make incredibly nice gifts (note that gifts are not tied to a particular time of year – the best time to give IMO, is when you feel like it and can turn it into a genuine act of generosity).

Thinking about how to start off this series (which, incidentally, will be open for guest writers, so feel free to suggest topics or contribute with posts), I decided to take on the role of someone who really wants to dive into Physical Computing and has to start from scratch: knowing nothing, having nothing, eager to learn, willing to buy what’s needed – or indeed, having received some sort of starter set as a gift.

I came up with a list of items: some tools, and a fun kit to build, which can catapult you into this world of technical invention and creation. It’s meant as a suggestion – no more. Whatever works for you, ok?

Next question was – how to make this meaningful, i.e. how can people get hold of this stuff, if they simply want to get started? I decided to select appropriate items from Conrad, a mail-order shop with outlets all over Europe, which has been in the business of supplying all sorts of electronics and hobby products for many decades. You’ll find cheaper stuff in China, and you may be served better by a local company you already know, but if you really start from scratch, Conrad is a fine mail-order source of hobby-oriented products for the Europe region. And although I don’t know them as well, I suspect that Jameco has a similar audience in the US.

I do not have even the slightest affiliation with Conrad – I just order from them once in a while (and know from experience that returns and cancellations are handled in a courteous and responsive manner). Their website is not the fastest or the most convenient, but hey, it works.

Here is a list of what I found and will be discussing in the upcoming installments. Unfortunately, it appears that these item numbers are not identical across different countries – these links are to Conrad’s Dutch site:

indispensable: a soldering iron + some extras (item 588417)
just about indispensable: multi-meter + screw drivers, pliers, etc (item 046027)
essential, because we only have two: a third hand (item 588124)
consumables, better never run out of this: leaded solder (item 812803)
nice to “undo” soldering mistakes: desoldering wick (item 588243)
convenient and cheap: solder cleaner (item 588371)

Cost so far: € 86.04, including VAT and free shipping (Dutch prices, other countries should be similar).

That leaves plenty of spare cash in our sub-Xbox budget to buy one more thing: a delightful robotic kit (item 191451) – the same as used for the TwitLEDs project. Total expenses: € 146.03 (over 40% of which is that robot).

588417 GB 00 FB EPS 046027 BB 00 FB EPS 191164 LB 00 FB EPS

The coming weekly posts are going to describe these items in detail, and explain why less is too little and more is not essential. Feel free to pick alternatives, but don’t omit too many of these items. Even that robot (or some starter project) is essential. Walk first, then run. But as you’ll see, even walking is fun!

My reasoning for this approach is as follows: when starting out, you need enough to get going, to be able to really learn and get used to everything, and to build up the skills which will allow you to step up to more advanced tools – but only then, and only if you decide that you want to take it further!

Nobody in their right mind would start learning to play the violin on a Stardivarius. Well.. I have to admit that my well-documented recent oscilloscope acquisition sure feels like a “Strad”. And I’m glad I didn’t get it any sooner, or skipped the Rigol trial, because I would probably have had no idea how to make use of it otherwise.

So this series will be about picking tools, making the very most of them, and focusing on the world beyond.

It’s not the tools that matter. It’s what they enable. And it’s for everyone who’s interested, from age 7 to 77.

Update – ALthough this will slightly exceed the total budget, I recommend also getting a large set of resistors, such as Conrad’s 418714. I’ll go into this in one of the upcoming Toolkit posts.

Tuesday Teardown

In Hardware on Mar 6, 2012 at 00:01

Welcome to a new initiative on this weblog: a weekly series about taking something “interesting” apart and peeking under the hood. I’m calling it the Tuesday Teardown series, and since they’ll all be tagged “Teardown”, that link you see will bring up all posts, accumulating as we walk down this path.

The idea is to look at some neat existing technology and find out how things were engineered, which is after all often a highly creative process, reflecting the outcome of a lot of problem-solving and deep insight about the design and production of all sorts of products. Since this weblog is all about creativity, technology, and exploration, it seemed like an obvious fit to look at how “stuff” was made.

This series of posts is also a departure in that I’ll be passing the microphone to guests once in a while. There is plenty of technology – both excellent and awful – to be able to keep this weekly topic alive for a long time… if you have suggestions, would like to contribute a complete story, or simply want me to translate or do part of the writing for you – please get in touch!

To start off, here’s a little dive into an amazing piece of engineering: a vintage-2005 Apple Power Mac G5 (2x 2.5 GHz PowerPC, each dual-core), which a friend and I recently took apart, after it had suffered a catastrophic breakdown – as you’ll see.

Here’s the shiny new Power Mac, as presented in the marketing brochures (it’s about 50x50x20 cm):

Powermac g5 Overview featurette expansion 20100727

The interesting bit is that at the time, these CPU’s were hitting the limits of personal computer cooling capabilities, yet Apple wanted to really keep noise levels down. As a result, an elaborate set of cooling zones was created, each with quiet cooling fans operating independently and adapting to demands.

I wasn’t really interested in the top part (drive bays and expansion slots), or the middle part (motherboard and memory expansion). I wanted to see the CPU cooling solution:

DSC 2923

This is an oblique top view of the cooling unit, sitting on top the two CPU boards – which are separate from the big motherboard (no doubt easier to service and upgrade this way). The whole unit looks and behaves like a mini car radiator, and indeed, it uses what seems to be the same sort of thick blue-ish liquid coolant (glycol) as you’d put in your car (or your fridge, as cooling blocks).

The whole Power Mac can draw over half a kilowatt, and no doubt quite a bit of that goes to these CPU’s when maxed out. Since all of it ends up as heat, this really is an impressive feat of engineering.

Trouble is… after a few years, things tended to fail. In a pretty ugly way, in this case:

DSC 2927

Massive leakage. Taking the board with it, to the point where the solder joints got corroded:

DSC 2926

Interesting detail – look at the immense number of capacitors on there. Here’s the other side:

DSC 2925

Oh, and this isn’t a run-of-the-mill double-layer PCB either – check it out:

DSC 2930

Even 7 years later, “awesome” only barely covers the level of engineering that must have gone into this.

PS. I also extracted the power supply, rated 600W, to see whether that could be re-used at JeeLabs somehow. But the PSU didn’t really like me – my first attempt at powering it up beyond the default standby state produced fireworks inside and a smelly puff of smoke. It probably needed a certain load to function properly. Oh well.

Meet the RBBB Pro

In AVR, Hardware on Mar 5, 2012 at 00:01

The Real Bare Bones Board by Modern Device is a neat little Arduino clone (it was my inspiration for the JeeNode, in fact). The RBBB is easy to build, very small, and very popular, at JeeLabs as well.

Now, there’s also a ready-made “pre-assembled” 5V model, based on the SMD version of the ATmega328 which has two additional analog-in pins (note that they are not general purpose I/O pins!):

DSC 2936

Well labeled for use either way, and very convenient for breadboard use. Here’s the bottom view:

DSC 2937

The headers and DC power connector are included, but not soldered on – for maximum flexibility:

DSC 2938

Fully compatible with the RBBB, but considerably flatter if you omit the DC connector.

I’ve added it to the JeeLabs shop and it’s available now. It’ll probably be used in future projects here as well.

Alternative USB interface

In Hardware on Mar 4, 2012 at 00:01

I ran out of USB BUB interface boards in the shop the other day (all my fault, not paying attention), so these last few days a slightly different version is being sent out. This is an earlier, but nearly equivalent, design by Lennart Herlaar – and as it so happens, I had a bunch of them lying around – a perfect susbtitute until the BUB’s by Modern Device are back in stock next week.

Here’s the USB FTDI Board in close-up:

DSC 2934

As with the BUB, you need to solder on the 6-pin FTDI connector for use with JeeNodes and RBBBs:

DSC 2935

The “settings” for this board is to pass the 5V supply voltage from the USB connector (solder jumper, already installed), and to set the logic levels jumper to work with 3.3V, as required by the JeeNode (or 5V for RBBB use). It’s not that critical, really.

Sooo… slightly different unit and shape, but does the same job as before, i.e. connecting up to USB for power, as well as serial-over-USB uploading and debugging.

Component Tester – part 2

In Hardware on Feb 1, 2012 at 00:01

After yesterday’s introduction, we’re ready for some more insight…

To summarize: a straight line going through (0,0) represents a purely resistive effect. The slope of the line is related to actual resistance. With resistors, once you know the voltage, you know the current (and vice versa).

Here’s a diode, i.e. a component with very specific properties (this shows why it’s called a semiconductor!):

DSC 2904

With negative voltages, it just blocks (horizontal line, infinite resistance). With positive voltages it’s essentially a short circuit (vertical line, almost zero resistance). Note the “knee”: a diode starts conductiong at about 0.7V.

Here’s a blue LED:

DSC 2905

Very much like a diode (the “D” in LED stands for diode, after all). Except that the knee is higher, at around 3V.

Here are three zener diodes of 3.3V, 5.1V, and 9.1V, respectively:

DSC 2913 DSC 2914 DSC 2912

Note first of all that these diodes were connected in reverse compared to the diode and LED shown earlier, so the graphs are rotated by 180° compared to those. A zener is a regular diode, in that it conducts normally at around 0.7V. The difference is that when it’s blocking, it will at some point “avalanche” and start conducting anyway. This very specific voltage is what makes zeners special. But note how that avalanche knee is round and inaccurate for low voltage types. Zeners for less than 6V or so are not very precise for regulating the voltage – but 9.1V is fine.

Neat, huh? Each type of component has its distinctive analog signature when viewed on a CT!

So far, you’d be forgiven to conclude that a Component Tester is simply a hardware function plotter. With the horizontal axis being the voltage applied, and the vertical axis being the current flowing through the component.

Ah, but wait… here’s a 1 µF capacitor, showing that capacitors are fundamentally different beasts:

DSC 2906

This is where things start to go crazy. No current at maximum and minimum voltage? Lots of current at zero volts? Positive and negative current at that zero-volt position? What’s going on here?

The thing to keep in mind is that this is not simply a function of voltage vs current. We’re applying a sine wave – a voltage which very uniformly and smoothly varies between -10V and +10V. Think of a swinging pendulum, oscillating over and over again in a constant pattern.

Note also that the component is being driven through a 1 kΩ resistor, limiting the maximum current through it. So we’re looking at the capacitor while it’s in fact part of a circuit – i.e. a 1 kΩ resistor in series with our 1 µF cap.

Let’s start at the right. The capacitor is fully charged to +10V, and our voltage is starting to decrease. When the voltage is +9V, the cap is still +10V, so it starts sending out charge in the form of current to try and regain the balance. So a positive current flows out when the voltage is at +9V. If that voltage stayed at +9V, it would soon stop, since the charge drops, and the capacitor reaches +9V equilibrium again. But as this happens, the voltage keeps on dropping. In fact, it drops faster and faster, so more and more current leaks out while catching up.

At 0V, the rate of descent (dare I say slope or derivative?) is maximal, as you can see when you look at a sine wave. So at that point, the capacitor is leaking charge as fast as it can – at the rate of 4 mA in this case.

The voltage doesn’t stop dropping, though. I keeps on dropping to -10V, although it’s slowing down again. So the current still flows out of the cap, but slower and slower. At -10V, the voltage is no longer dropping at all, and the charge will have caught up – no more current, i.e. 0 mA.

Now the roller coaster ride repeats the other way around. The capacitor has -10V charge (lack of charge, if you wish to look at it that way), and voltage is about to start rising again. This time, charge has to be fed into the cap to try and equalize voltages, and so the current is now negative.

And sure enough, the lower negative side of the circle goes through the same changes. Until we reach +10V again.

So what you’re looking at is not a function, but the path of a point in space, racing around a circular path (ok… oval, since you insist). That point in space leaves a trail on the screen, and that’s the resulting image.

Phew! Still there?

The reason this happens, is due to the fact that a capacitor has state (or memory, if you like). It will respond to an external voltage differently, depending on the amount of charge it currently holds. Applying +5V to an empty cap will generate a different current than applying +5V to a capacitor which is currently charged up to +10V, or whatever. Current will start to flow to balance things out, but this requires time.

Very loosely speaking, you could say that capacitors “live in the time domain”. Unlike resistors – which just resist the same way under any circumstance.

Here’s the trace of an inductor (the secondary coil of a small transformer in this case):

DSC 2907

Hey, it looks like inductors also have state! And yes indeed, they do. Capacitors and inductors are very similar, electrically. They both “live in the time domain”, although through very different mechanisms.

The state of a capacitor is its current charge level, i.e. the “amount of electricity” inside it at any particular time.

The state of an inductor is the magnetic field level it has created. When you send an electric current through a coil, that coil becomes an electro-magnet, and starts generating a magnetic field around it. When the current stops, the magnetic field wants to keep going. But it can’t and it starts fading – while it does, an electric current is generated in the ~~opposite~~ same direction. This effect (plus a little resistance) is what causes the tilted shape shown above.

As you can see, it has the same weird effect: no current at maximum or minimum voltage, and either positive or negative current at zero volts.

The point of these little demos was to show how current and voltage stop being linearly inter-related with caps and inductors. Because they mess with time. The charge which came in today could come out tomorrow, for example.

With constant voltages, capacitors and inductors are boring. But when their time effects are pitted against voltages which change over time, then nifty things can happen. It’s probably fair to say that the discovery of DC (direct current) brought electricity to the world, whereas AC (alternating current) brought electronics to the world.

For measuring DC, you can get by with a voltmeter. For AC, you need a voltmeter-over-time, a.k.a. an oscilloscope.

I hope this gives you a feel for what’s going on in electronic circuits. The behaviors shown here are universal, i.e. caps will behave like this every time, no matter what else sits around them, and getting an intuition about how these components react to voltages is a fantastic way to figure out all sorts of more complex circuits.

There’s tons more to explore about signals and circuits: filters, phase effects, crazy stuff called “complex numbers” (values with a “real” and an “imaginary” part, go figure!), switching perspectives from the “time domain” to the “frequency domain”, and Fourier transforms. None of this matters, if all you want is to turn on a lamp or work with digital signals. But if you’ve ever wondered how electronic stuff really works: trust me… it’s fascinating.

Is anyone interested in any of this? I’d love to write a series about it one day, where intuition comes first, insight a close second, and where all the mathematics involved will become totally obvious (seriously!).

PS. Here’s my intuitive summary of what R’s, C’s, and L’s do (and what makes each of them unique):

Resistors turn electrical energy into heat (no way back with a resistor)
Capacitors turn voltage differences into electric charge (and back)
Inductors turn electrical current flow into magnetism (and back)

Component Tester

In Hardware on Jan 31, 2012 at 00:01

Hameg scopes have often included a “Component Tester” (CT) and mine’s no exception. It’s a really nifty way to identify a component and understand its basic characteristics. It requires a sine wave signal and an oscilloscope:

Screen Shot 2012 01 27 at 19 32 29

Don’t fret too long about the above circuit (copied from this PDF, which I found via Google). It’s just to show that setting up something like this is very easy – but you do need an oscilloscope with X-Y capability.

The basic idea is to apply a sine wave of say 10 VAC @ 50 Hz to the part you want to identify, and to then display voltage over versus current through that component.

My scope has the equivalent of the above simple CT circuit built in:

DSC 2908

Two pins, on which a 50 Hz voltage is applied which varies between +10V and -10V in the form of a pure sine wave. For some reason, the scope won’t let me take screen dumps to USB in this mode, so I’ll use camera shots.

Here’s what you see with nothing connected (note the full scale: ±10 V on X and ±10 mA on Y):

DSC 2900

The horizontal axis shows the applied voltage, and as you can see, no current is flowing. Because air insulates!

Let’s short the two pins with a copper wire (I’ve reduced the image scale to reduce this weblog post’s length):

DSC 2901

Of course: no matter what voltage we try to put between the pins, the wire will force it to 0V, and will simply pass -10 .. +10 mA of current. As you can see in the schematic, there’s a 1 kΩ resistor in series to limit the current.

These two images of open vs shorted set the stage. Now let me insert a couple of different components, so you can see how they behave when subjected to this 10 Vpp sine wave. First, let’s insert a 1 kΩ resistor:

DSC 2902

Make sense? Now have a look at a 10 kΩ resistor:

DSC 2903

So what we have so far, is resistance varying from zero ohm (shorted) to infinite ohm (open), with two values in between. It all ends up as a straight line, with the slope varying from horizontal to vertical. That’s it: resistance!

If you want an explanation: this is Ohm’s law, visualized. Voltage and current are proportional, i.e. V = I x R.

So much for the basic stuff. Tomorrow, I’ll show you a couple of considerably more interesting components.

Capacitive power supply – part 2

In Hardware on Jan 30, 2012 at 00:01

Yesterday, I tried to get to grips with how a capacitive power supply works. Real samples are a bit messy, though.

So let me try something else this time, and simplify a bit:

JC s Doodles page 32

The setup is very similar, but I’m leaving out the zener diode and the rest, and more importantly, I’m going to feed a real 50 Hz sine wave signal into this circuit, using my little sine wave generator.

Here again, because scopes need to measure with a common ground, I’m placing that common ground in between the resistor and the cap, and I’m using the scope’s internal “invert” feature to treat this as if the channel 1 probe were connected the other way around. Here’s what we get with this new setup:

SCR19

The vertical scale of the resistor was adjusted to display the same amplitude for the resistor as for the capacitor.

the yellow line is the voltage over the capacitor
the blue line is the voltage over the resistor
the red line is the sum of the yellow and blue lines

The scale of the red line is not quite accurate, but its shape is. So the red line is in essence the input signal.

So what’s going on here?

As you can see, all these signals are 50 Hz sine waves. That’s quite remarkable already. Obviously the red line is a 50 Hz sine wave, since that’s what we’ve been feeding in. But so is the voltage over the capacitor, the voltage over the resistor, and hence also the current through this circuit!

What you see, is a set of sine waves which differ only in phase and in amplitude:

the voltage over the capacitor (yellow) lags the input signal (red): it’s forever trying to catch up
the current through the capacitor, i.e. the voltage over the resistor (blue), is leading in phase

And something else, as we saw yesterday: the current through the capacitor is related directly to the slope of the capacitor’s voltage change (i.e. its derivative). When the yellow line is steepest, the blue line is at its highest.

Let’s throw one more calculation into the mix: power. Power is input voltage (red) times input current (blue):

SCR20

Looks very sine wave’ish again! There is some amplitude variation, which can probably be attributed to signal asymmetry or amplitude differences between the different sine waves. The phase of this wave is different from the ones already shown, but note that it’s also twice the frequency, i.e. 100 Hz.

Let’s step back for a moment. With a purely resistive circuit (as used in a resistive transformer-less supply), the current and voltage would be in lock step, i.e. sine waves with exactly the same phase, and the power consumption would be maximal (high current at times of high voltage).

With this capacitive setup, currents get “moved around”. That means power consumption will be less than when voltage and current match up (since this gives the largest possible results).

I’ll include one more screenshot, this time using the same vertical scale for all signals (except power):

SCR21

This puts things more in perspective: the voltage over the capacitor (yellow) is slightly lagging the input signal (red) now. And the input current (blue) is out of phase w.r.t. the input signal (red). So the power consumption (red x blue) is substantially lower than with a resistive circuit: when the current is maximal, the input voltage is only a fraction of its maximum range. IOW, we’re drawing current when it “costs” little.

This is why a capacitively coupled supply is cheaper: the electricity company charges us for real power (i.e. V x I). We’re being charged for what happens inside a pure resistor.

But we’re doing a lot more: we’re taking charge out of the AC mains line on one half of the cycle and pushing it back on the other half. It might seem as if that doesn’t use up energy, but it does: current through a wire causes resistive losses (in the form of heat), and “returning” that energy one half cycle later causes those losses again! So the electricity company sees its electricity turn into waste heat, and they can’t charge us for it.

Here’s a thought experiment: suppose you had a huge capacitor, and hooked it up directly to AC mains, next to the electricity meter. According to what we’ve seen, it’ll track the 230V cycles, with current exactly 90% out of phase with AC mains voltage. Huge currents would flow at the time of zero volts. You’d be charged relatively little for the large out of phase current that flows (not quite zero because a practical capacitor has some internal losses that look like a resistive component from the outside). But your garden would be nicely heated by that current in the resistance of wires between the electricity company and your meter…

You can read more about “real”, “reactive”, and “apparent” power on Wikipedia.

(with a tip of the hat to Martyn for helping me understand this stuff a little better)

Capacitive power supply

In Hardware on Jan 29, 2012 at 00:01

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

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

Capacitive AC DC 2

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

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

To interpret the graph, you need some info:

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

Here’s the scope capture:

SCR97

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

So what are we seeing here?

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

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

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

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

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

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

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

This is where it gets interesting.

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

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

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

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

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

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

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

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

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

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

Can’t be done

In Hardware on Jan 27, 2012 at 00:01

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

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

Screen Shot 2012 01 25 at 01 57 45

The good news is that it works as intended and that I’ll be using this circuit for some projects.

The bad news is that they won’t be available as kits in the shop. Ironically, this was the first time where I actually had a batch of kits all wrapped up and ready to go, ahead of time.

But the reality is that I can’t pull it off. For two different reasons:

The circuit is connected to live AC mains @ 230 VAC and that means there is a serious risk if you build this stuff, try it out, and then hurt yourself because of some mistake. And even after that, there is the risk that the whole circuit is not properly protected, exposing these voltages (even just humidity and condensation).
The other risk is that once everything works, it gets built-in for permanent use and becomes part of your house. What if it gets wet or malfunctions for some other reason, and your house burns down?

As supplier, I’d be liable (rightly so, BTW – there is no excuse for selling stuff which might be dangerous).

The hardest part of all is that even if an accident has nothing to do with this Low-power Supply, I still have to prove that this stuff is safe under any circumstance and that it complies with all regulations!

I’m not willing to go there. Life’s too short and I don’t have the pushing power to go through it all.

Having said this, I do intend to use this supply myself and create all sorts of nodes for use here at JeeLabs. Because I know the risks, I know which failsafe features have been built into the supply, and I’m ok with it:

DSC 2894

The design is available in the Café, to document what I’ve done and for others to do whatever they like with it.

I’m not happy about this decision, in fact I hate it. I’m really proud of finding out that it is possible to create sensor nodes which run off just 12 mW of AC mains power. But the right thing to do is to stop here.

Tektronix 475

In Hardware on Jan 26, 2012 at 00:01

Oh boy, I’ve been bitten by the collector’s bug…

Couldn’t resist an excellent offer on Marktplaats (the Dutch equivalent of eBay) for a fully operational analog scope built in the late 70’s. The Tektronix 475 is, ehm… slightly larger than the Hameg HMO2024:

DSC 2892

Then again, they are quite comparable – both are specified as 200 MHz bandwidth. Check ’em out:

DSC 2893

The Tek will need to be re-calibrated, but as far as I can tell all the functions work and all the switches, knobs, and indicators are in good order. The previous owner said he had used it for a long time, but not intensively.

First thing I had to try was the analog clock, of course:

DSC 2886

Apart from that? Oh, I don’t know. I’ll refurbish and re-calibrate it one day, there’s lots of info about this classic workhorse out on the web, and I really would like to learn how to diagnose and repair stuff. Even old stuff.

This is a single-beam unit, meaning it can’t show two signals at the same time. Newer and more advanced models are dual-beam, but this one has to either “alternate” between the two beam displays, or “chop” them up and draw bits of one and the other in an interleaved fashion. It’s also not a storage scope, so you’ve got to look very carefully if you want to see one-shot events – the display on the screen shows only as long as the phosphor glow lasts!

Fantastic engineering. Electronics, mechanical, operation, documentation, service – everything!

Would I have bought the Hameg if I’d had this one at the time? You bet – the “S” in DSO is a game changer, especially with microcontrollers and physical computing. But that huge Tek brick is more endearing :)

Heh, I’ve never before collected anything in my life – this is fun!

The PWR vs the +3V pin

In AVR, Hardware on Jan 25, 2012 at 00:01

JeeNodes and plugs use 6-pin headers with the following pin assignment:

(there’s usually a big printed dot near the PWR pin for orientation)

There has been some confusion about what PWR is w.r.t. +3V and how to use it, so let me elaborate a bit.

First: “+3V” is the main regulated power reference for most chips and circuits. And to make it more complicated: it’s actually 3.3V, not 3.0V. The “+3V” label merely identifies the pin (VCC would be too confusing).

The ATmega on the JeeNode, as well as most (but not all) chips on attached plugs run on this 3.3V voltage level. It is also the reference level for all digital I/O (0 = 0V, 1 = 3.3V), as well as for the ADC when used for analog inputs (1023 steps of 3.22580645161 millivolt each).

As for the other supply pin: “PWR” is usually a higher voltage from which +3V is derived.

There’s a voltage regulator on the JeeNode which can take any input voltage on “PWR” up to about 13V as input and which produces the 3.3V regulated voltage on the “+3V” pin.

The JeeNode regulator has some limits: it’s can’t supply more than 250 mA and it can’t dissipate more than about 600 mW. It’ll shutdown if either of these are exceeded (and it’ll get damaged if you feed it more than 13V). These figures are fairly limiting: if you run a JeeNode off 12V on the PWR pin, then it actually won’t be able to supply more than 70 mA. With 5V on the PWR pin, the limit will be current, not power dissipation, i.e. 250 mA max.

That’s for a JeeNode with through-hole components, i.e. an MCP1702 regulator in a TO-92 package. With the JeeNode SMD and JeeNode USB, you get even less power from the regulator: at most about 250 mW of heat dissipation. That’s 150 mA @ 5V, and only 28 mA @ 12V. In short: the JN SMD and JN USB are not really meant to be powered from more than 5V – or at least not without an extra external regulator (on the plus side: the MCP1703 supports up to 16V on the PWR pin). Note also that the JeeNode USB doesn’t support more than 7V on the PWR pin, due to limitations of the on-board LiPo charger – but that should not be an issue since it’s really only meant to be powered from 5V via USB.

As you can see, there are several limiting factors as to what voltage is supported on the PWR pin. Keep in mind that JeeNodes were designed for ultra-low power consumption, and the regulator was selected for its extremely low idle current draw, not its “high-end” characteristics.

But that’s not all…

One trap for the unwary is with the JeeNode USB: it doesn’t actually feed 5V to the PWR pin when connected to USB but only 4.2V. This is due to the LiPo charger circuit, which allows a LiPo battery to be connected between PWR and GND. With a LiPo battery, the JeeNode USB becomes a very convenient stand-alone unit: low-power untethered operation while not connected to USB, and automatic LiPo charging while connected to USB. It even has a voltage divider on board to monitor the LiPo battery voltage (tied to PC6, i.e. analog 6 in Arduino-speak).

The trouble here is that when you connect plugs to the JeeNode USB, you won’t get the full 5V you might expect. This affects all those plugs which don’t run entirely off +3V but expect some higher voltage on PWR.

And here’s another tricky situation…

With the AA Power Board, you can run JeeNodes off a single AA cell. In this case, there isn’t a voltage higher than 3.3V anywhere in the circuit – so what to do with the PWR line? Well, there’s a solder jumper on the AA board to let you decide: it’s normally open, but you can connect it to either +3V or to the battery “+” (i.e. 1.2..1.5V). Obviously, this setup will be even less suited for plugs which expect a higher voltage than 3.3V to operate.

As you see, the +3V pin is solidly specified as always being 3.3V, but the PWR pin level can be all over the map.

The following plugs are especially affected:

the LCD Plug will work, when used with a 3.3V display (as shipped by JeeLabs), but will only be suitable with 5V displays if PWR carries 5V
the Graphics Board assumes that PWR is 5V, because the display needs it (it’ll probably still work with 4.2V, but PWR should not be above 5V)

Most plugs will be fine, though, since they only use the +3V supply. The only issue here is to make sure that the total current consumption off +3V is not too high.

Using a JeeNode with an unregulated power supply

The maximum allowed voltage on the PWR pin is about 13V. Unfortunately, many 12V power bricks are fairly badly calibrated, and often deliver substantially more than 12V under no-load conditions. You could easily damage the JeeNode’s on-board regulator with a cheap 12V power brick – better use a 5V or 9V brick.

If you do want to power a JeeNode off 12V (perhaps you need 12V on the rest of the circuit for LEDs, relays, or motor power), then the best approach is to insert a 5V regulator and feed that 5V level to PWR. This can easily be done with a “7805” regulator chip, which is available from many electronics parts sources.

Too much heat

In Hardware on Jan 24, 2012 at 00:01

To avoid switching noise near the work bench, I wanted to drive my LED strips from a plain ol’ transformer -> bridge -> capacitor supply. It would have to supply about 2A @ 12V for my LEDs. Here’s the setup:

DSC 2878

Ignore the diodes at the top, these were 1N4004 diodes which weren’t quite up to the task. The ones at the bottom right are Schottky diodes for a lower voltage drop, rated at 5A. The capacitor is 2200 µF, but ripple isn’t an issue.

Alas, the heat from this thing is excessive. I even went for an artsy swiss-cheese design:

DSC 2879

Trouble is the transformer (and surprisingly not the diodes!) – I measured them both, with everything closed:

DSC 2877

Diodes heated up to 75°C – but the transformer went all the way up to well over 90°C within the hour! AC mains consumption is 50W, so this silly thing is eating up half the power while trying to behave like a stove…

The transformer is a cheap 2x6V @ 2.5A unit I had lying around (draws 3.7W, even without any load). I’ll keep this as a high-ripple 12..20 VDC power brick for testing – but it definitely can’t be used continuously @ 2 Amps!

PS. If you’d like to meet up – I’ll be presenting JeeStuff at HackersNL coming Thursday evening in Utrecht.

Flash from the past

In Hardware on Jan 23, 2012 at 00:01

A while back, Jeroen mentioned on the forum that he had an ancient GM5655 Philips oscilloscope, and since he lives in Houten we thought it’d be fun to put it side-by-side with my new Hameg scope I keep generating screen shots with in this weblog (ad nauseam for some, I suspect…). Here’s his vintage 1955 hardware (from a web image) – just imagine how attractive that must have looked to geeks back then:

GM5655

It’s single-channel unit, with a sweep generator which can go “all the way” up to 30,000 Hz. The horizontal deflection can also be driven externally, making this scope X-Y capable. Vertical sensitivity is up to 60 mV/cm, horizontal up to 100 mV/cm. No positioning, no magnification, nothing. This is as basic as a scope can be.

Jeroen dropped by a few days ago and we had a go at it. Unfortunately, we couldn’t get it to work. The horizontal deflection appears to be broken (not just the sweep generator, since it also didn’t respond to external signals). Most probably one or more of the “tar capacitors” has failed. It’s always them capacitors with old equipment…

Neither of us felt confident enough to go about messing with this thing while powered on (vacuum tubes, and especially the CRT, run on high voltage). But the least we could do is open it up and marvel at how things were constructed back then. No semiconductors and no printed circuit boards – pretty amazing, if you think about it.

It’s a pretty scruffy unit, once you open it up!

DSC 2863

Note the big tar caps and the “flying” construction, especially around the rotary switches:

DSC 2864

Here’s the other side, with what looks like just the vertical input circuit:

DSC 2867

Here’s the top view, with 6 vacuum tubes in total:

DSC 2869

The bottom view, with one more tube and what looks like a bunch of electrolytic power supply caps to me:

DSC 2871

All this was manually assembled, so each unit had to be tested and debugged, since it wouldn’t take much to hook up things incorrectly. The invention of the printed circuit board not only creates a mechanical platform to hold everything in place (especially for low-voltage semiconductors), it also acts as a self-documenting area during assembly, since all the spots are already marked with what goes where.

Amazing stuff – I’m tempted to get a (somewhat more modern) analog scope off eBay, just for the fun of it :)

More accurate 10 MHz

In Hardware on Jan 22, 2012 at 00:01

To follow up on yesterday’s post, here’s a similar TCXO oscillator which is considerably more accurate:

DSC 2862

It’s a 10.000 MHz unit which has been calibrated and claims a 0.1 ppm accuracy. That’s 10 MHz ± 1 Hz, i.e. 7 digits. Here’s the output signal, which appears to be AC coupled:

SCR90

Not bad for a low-cost unit. I got it from the RFcandy shop. Current consumption is 0.94 mA @ 5V.

Once you start looking into this stuff, all sorts of things pop up on the web. There’s a group of amateurs who call themselves Time-Nuts (terrific name!) and who aim to keep track of time as accurately as they can – with pretty amazing results. In a comment yesterday, John Beale pointed me to a web page with info about the Rubidium clocks now available cheaply on eBay.

I found this page most entertaining, summarizing the history of accurate time-keeping in a few slides.

Precision time, anyone?

In Hardware on Jan 21, 2012 at 00:01

The RTC Plug uses a DS1340 chip to keep track of time. It has its own on-board coin cell and 32 KHz crystal, so that it can keep running when power to the JeeNode is switched off.

The 32,768 Hz crystal is rated at 20 ppm, with 3 ppm aging in the first year. A year has about 3600 * 24 * 365.25 = 31557600 seconds. With 20 ppm, the RTC Plug can be some 630 seconds off at the end of the year, i.e. close to one minute per month – worst case, that is. It’s fine for lots of uses, but evidently not all…

Here’s a new plug prototype, designed by Lennart Herlaar:

DSC 2860

It’s based on the DS3231 chip, which includes a “TXCO”, i.e. a Temperature Compensated Xtal Oscillator. There are many ways to improve the stability of a crystal oscillator, but this one is pretty nifty because it’s low-power (unlike an oven-based technique, which puts the crystal in an controlled temperature environment). The idea is that the chip periodically measures the ambient temperature, and then adjusts the capacitive loading of the crystal according to a calibrated function of temperature. IOW, it knows how to compensate its on-board crystal.

The DS3231 is specified at 2 ppm for temperatures 0 .. 40°C, i.e. ten times more accurate than the above crystal. So this clock will stay on time with an error of at most one minute per year, i.e. about a second per week.

For something, eh… slightly better – you could consider a Rubidium Frequency Standard with 50 ppt accuracy, i.e. well under a millisecond per year error. But don’t expect to run it off a coin cell – it draws about 11 Watt :)

If there’s enough interest, this plug could be added to the shop…

Seeing glitches

In Hardware on Jan 20, 2012 at 00:01

There’s one dirty little secret about most digital storage oscilloscopes (DSOs) which puts them way behind the capabilities of their analog brethren: screen update rate.

For a scope to present a trace on screen, it has to do a lot of signal processing. After all, 1 GSa/s means its acquiring 1 billion data values per second. And although we’re not able to really see that with our eyes, we do see things that stay on the screen for a few milliseconds.

One trick is to turn on persistence. On analog scopes, that’s a pretty nifty feature whereby the image generated from the beam hitting the screen is made to stay visible for a while. Either via a phosphor coating which keeps on glowing for a while, or by constantly re-sending the same beam pattern to keep the visual display going.

Digital scopes can simulate this. All they need to do is leave the pixels on their LCD display as is, right?

Unfortunately, it’s a lot more complicated than that. If you just refresh the screen a few times a second, then you’re still going to miss a huge amount of detail. Let’s take a periodic 1 MHz signal: to display everything measured, the display needs to be updated 1,000,000 times per second, which means each “sweep” would only remain visible for 1 µs. That won’t do – our slow eyes wouldn’t see a darn thing, especially glitches which occur very infrequently. So what a DSO does, is simulate persistence by merging new sweeps into what’s being shown, and then take old sweeps out of the picture a bit later (try implementing that – efficiently – !).

To test this stuff, I used the following sketch (which is based on this pin flipping trick):

Screen Shot 2012 01 17 at 12 28 39

It generates pulses at ≈ 1 MHz, but every once in 10,000 pulses, it messes up the timing. Note that interrupts are turned off, so this thing is as stable as the clock it’s running on (a JeeNode with a 16 MHz resonator in this case).

One glitch every 10,000 pulses at ≈ 1 MHz means there are 100 glitches per second. That should be constantly visible on the screen, right? Well… not so on my scope. I enabled 10s persistence, i.e. sweeps will fade after 10s:

SCR89

That’s two glitches (the actual display is a bit erratic, but the position of the glitch pulses is absolutely repeatable).

IOW, this scope is showing only one out of every 500 pulses on the screen, on average!

This is why DSO manufacturers report a “waveform/sec” value in their specs. In this case, we are getting 2,000 waveforms per second, even though a scope could theoretically sweep 500,000 times per second on this.

An analog scope would have no problem whatsoever with this. To show the same two pulses in each sweep, it could trigger a new sweep 500,000 times per second, or maybe even “only” 100,000 but that would still show 10 glitches per second, i.e. a nearly constant visual display of the glitches. Fifty times more often than my DSO, anyway.

That 2,000 wf/s figure is an optimistic one, BTW. With more channels enabled, or things like signal stats calculated or the math function applied, this value can drop substantially. Meaning you’ll see even less glitches.

What this tells me, is that the Hameg needs about 500 µs of processing time to get 1 channel of acquired data onto the screen in its most basic form.

Don’t get me wrong: technically that’s an astonishing achievement. It’s not just copying a few bytes and setting a few pixels. It’s (always!) performing the emulated-persistence trick – because with persistence turned off, I still see a glitch every few seconds, which means that the LCD display is showing the glitch for a substantial fraction of a second – much longer than the 1 µs (or even 500 µs) sweep rate would suggest. Besides, you can see that fading is also implemented, so it’s not just drawing pixels but actually fooling around with color intensities.

There are some scopes which get much higher waverform/sec rates, such as the Agilent 2000X (50,000 wf/s) and the Agilent 3000X (1,000,000 wf/s) series. But they are twice the price, and even have lower specs in other areas.

Does it matter? Not for me. Being aware of this is good, though – far more important than fixing it. Note also that IF – that’s a very big if – you know what you’re looking for, then there are usually other ways to find these things. In this case, triggering on a negative pulse width under 900 ns captures all those glitchy pulses, for example.

As so much in life, it’s all about trade-offs. Analog / digital, brands, and of course… your needs and budget.

The beat still goes on

In Hardware on Jan 19, 2012 at 00:01

Recently, the radioBlip sketch reached yet another milestone: it’s been running for 500 days on one LiPo charge!

Seems like a good time to start a new duration test, this time with a JeeNode Micro:

DSC 2857

Since I don’t want to have to wait yet another 500 days, I decided to up the ante:

DSC 2858

The JeeNode Micro includes holes for a CR2032 3V battery holder, so why not try that for a change, eh?

The sketch was modified slightly, to set the proper clock divider on startup:

Screen Shot 2012 01 16 at 19 37 00

I’ve set it up as node 18, and it’s been blipping happily:

Let’s see how many days that little JNµ can dance the Sputnik shuffle…

Putting the JNµ to sleep

In AVR, Hardware, Software on Jan 18, 2012 at 00:01

The Sleepy::loseSomeTime() code in the Ports library was never tested on a JeeNode Micro. Turns out that only a minor library difference kept it from working (the arduino-tiny library has its own version of millis(), etc):

Screen Shot 2012 01 14 at 23 55 34

So now, the JNµ can be put to sleep as well. Here’s the jouleTest sketch I used, tweaked to run on the JNµ as well:

Screen Shot 2012 01 14 at 23 55 09

And sure enough, about once every 10 seconds it shows that familiar packet-transmit current consumption:

SCR88

The blue line is the AC-coupled supply voltage, a 3x AA Eneloop battery pack in this case. It supplies about 3.8V, but when running off a 1000 µF cap, it looks like this continues to work down to 1.8V (well below the RFM12B’s minimum 2.2V specs) – although with only about half the transmit power by then.

This current use fingerprint is almost identical to the ATmega328 running this same code. Not surprising really, since it’s the RFM12B which determines most of the power consumption, not the ATmega vs ATtiny difference.

Onwards!

Pushing the scope limits

In Hardware on Jan 17, 2012 at 00:01

After having become reasonably familiar with the new Hameg HMO2024 oscilloscope, I wanted to find out just what its limits are. Came up with this screenshot:

SCR85

There’s quite a bit of information in here.

First of all, these scopes can do double-rate sampling when you don’t activate all the channels. Channels 1 and 2 share some hardware, and so do 3 and 4, so by enabling only one of each block, the scope can actually double its sampling rate to 2 GSa/s i.s.o. 1 GSa/s and also “stack” its memory depth to 2 MB per channel, i.s.o. 1 MB. Or to put it another way: a 4-channel oscilloscope can be used as a 2-channel unit with twice the specs.

I switched the acquisition to display in “sample-and-hold” mode instead of the normal Sin X interpolation mode, so the steps shown above represent the real sampling that’s taking place. As you can see, there are 4 steps per division, with 2 ns/div, so that’s indeed 2 billion samples per second.

The top was zoomed out as far as I could while still showing the fastest supported 2 ns divisions in the detail window, which ends up being 50 µs/div. Running the scope timebase any slower will cause it to reduce its sample rate so it can still capture the required 12 horizontal divisions full of sampling data. In this case we see 12 x 50 µs = 600 µs of data on the screen, while the detail view is zoomed in to 2 GSa/s (25,000x).

That’s 1.2 million samples of data – a hefty pile of bits flying around in this thing while it’s running!

But there’s actually more, because of the stacked memory. When I pan across the 50 µs/div display, I can see that data was collected from 575 µs before the trigger point to 525 µs after the trigger point. Which is 1100 µs of collected data, IOW that’s 2.2 MB of acquired sample data – again, more than the specs in the brochure!

The vertical signal acquisition hardware is also very impressive. This is one of the few scopes I know of which will go down all the way to 1 mV per division. That’s real sampling, not some sort of digitally enhanced sensitivity, as you can see from the fact that the data steps really are 1 pixel in the vertical direction.

It might not seem important to go down that low, but it’s quite useful actually when measuring voltage drop over a shunt resistor. Which is what I’ve been doing quite a bit to display current usage of JeeNodes while in ultra low-power sleep. The other benefit is that you can still go down to 10 mV/div with the standard 1:10 probes that come with the scope (I’ve got a few 1:1/1:10 switchable no-brand probes for when I really need the extra sensitivity).

The red line is created by using the “Quick Math” function, subtracting the channel 3 signal from channel 1 in this case. The nice thing is that the math function supports 20x more magnification than the input channels. So with some trickery, this scope can display down to 50 µV/div: subtract a spare channel set to “GND” from the input signal, and magnify the resulting math output 20x. It’s a coarse (digital) way of magnifying the display, but still.

The actual data shown above is what the scope displays with no probe connected, BTW. This is the residual noise in the scope’s input circuitry and it really is impressively low-noise – just a quarter millivolt peak-to-peak.

At the other end of the range, the scope will go up to 10 V/div, i.e. 80V full scale. That’s ≈ 6 orders of magnitude of usable range on each channel. Wow… Hameg (and R&S) did some pretty serious engineering to achieve this.

PS. I’m ready to ditch my DSO-2090 USB scope – it’s unlikely that I’ll use it with this HMO2024 now at hand.

Update – same for the Logic Analyzer – a LAP-16032U, if you’re interested in it, let me know.

Another AA booster

In Hardware on Jan 16, 2012 at 00:01

Out of curiosity, I’ve been doodling around with the AS1323 boost regulator chip, as suggested by someone in the comments. It’s not super efficient, but it does claim an extraordinarily low quiescent current of 1.6 µA.

Hooking up such a tiny chip is quite a challenge:

DSC 2856

The trouble is that this stuff can’t be spread out too much – the specs say that both input and output caps have to be within 5 mm of the chip. So I tied it to a pcb – mostly for stability – and then wired everything up around it.

Without any load, this thing operates in quite an efficient mode:

SCR81

The yellow trace is the voltage drop across a 10 Ω low-side resistor, the blue trace is the output, but AC coupled, i.e. showing only the ripple voltage.

The red line is the math function to integrate total power use in Coulombs – more on that later.

If you look at the top overview graphs, you can see the current blips which are over 160 ms apart, i.e. this thing is activating only 6 times a second. And each current pulse lasts only about 150 µs. The peak current on the input side, i.e. drawn from the battery, is about 12.5 mA.

Let’s put a 1 kΩ load on the 3.3V output line:

SCR83

I’ve adjusted the scale a bit. The switcher is now operating at about 11 KHz. The peak current drawn is almost 18 mA, but note also that the current never drops to 0 anymore – the baseline of that yellow trace is 2 divisions down from the top, so that’s about 6 mA (as expected, since the load is always drawing current).

Now let’s push it and change the output load to 100 Ω, i.e. about 33 mA @ 3.3V. To make that work, I had to change the input sense resistor to 1 Ω:

SCR84

The baseline for the yellow trace is now halfway, same as for the blue line.

I also added a third probe, the green line monitors output voltage, which is indeed steady at 3.3V (both red and green lines are based at the bottom of the screen). Note the huge peak current draw on the battery: over 290 mA!

Let’s try to understand what’s going on in this last case. First of all, with a 1 Ω sense resistor, a 190..290 mA current draw creates a voltage drop of around 0.25V – which means the battery voltage isn’t really reaching the switching regulator. The battery was measured to be at 1.37V, so the switcher is getting only about 1.1V on average. The datasheet says that it will only be 70..75% efficient on such an input voltage, when generating the 3.3V output.

The 100 Ω output load draws about 33 mA. That’s at 3.3V, so a perfect step-up regulator would need to draw 3x as much when running off 1.1V, i.e. 100 mA. A 70% efficient switcher would draw about 150 mA (0.70 x 150 ≈ 100). What I’m seeing here is more like a 40% efficient switching result (0.40 x 250 = 100) – hm, not sure why…

The other way to determine average current consumption, is to do some Coulomb counting…

In the first screenshot, each blip uses about 900 nanocoulombs (the red line rises 4.5 divisions over the entire width of of the screen). With 6 blips per second, we use 5.4 µC each second, i.e. 5.4 µA average current draw (not quite the 1.6 µA I expected, but still very impressive for an unloaded step-up regulator).

The second graph is trickier. We need to figure out the Coulombs increase per repetitive cycle. My guess would be around 820 nC. Multiply by the switching frequency of 11.25 KHz, and you get 9.2 mC per second, i.e. 9.2 mA average battery current to deliver about 3.3 mA @ 3.3V.

Gotta be a bit careful here. It turns out that the battery (which is a bit old), still delivers 1.44V at this lower power level. Also, since I’m using a 10 Ω current sense resistor in this case, there’s 92 mV wasted in that resistor. That leaves about 1.35V going in. A perfect switcher would draw 3.3V / 1.35V * 3.3mA = 8.07 mA. We’re pulling 9.2 mA, which is about 87% efficiency. That seems a bit optimistic, since the AS1323 doesn’t really go much further than 80%. Oh well, there are probably several measurement errors in my quick and dirty test setup.

For the third case with the 100 Ω load, I end up with a figure of 215 mC/s, i.e. an average current draw of 215 mA. Better than before but still under 50% efficiency.

One more datapoint: with a 100 kΩ load, the switching frequency goes to 120 Hz, while still using about 800 nC per cycle, i.e. ≈ 100 µC per second, or 100 µA. Again, pretty good for what is essentially a 33 µA load @ 3.3V – even if all these estimates are off by perhaps 25%.

So this chip might work quite well for bursty ultra-low power contexts such as a mostly-sleeping JeeNode!

Manual V-scoring

In Hardware on Jan 14, 2012 at 00:01

V-scoring is a low-cost way to cut up printed circuit boards. I use it in combination with routing to get al ’em plugs made out of larger panels. It consists of slightly cutting into the PCB material from both sides – when done properly, the resulting boards can be snapped off quite easily by hand.

Recently someone gave me a really neat breakout panel for SOIC and TSSOP IC’s. These are useful to try out SMD chips on a breadboard. Except that the board I got was still panelized…

Can’t look a gift horse in the mouth, and since I don’t have a mini bandsaw or such, I had to find another way.

As it turns out, it’s quite easy to do the v-scoring by hand:

DSC 2853

The basic idea is to lightly scratch all the lines about three times, and once there’s a decent groove, just take the hobby knife and cut two more times, pressing down fairly hard. Rinse and repeat for all the cuts on both sides, and things will come apart by pressing down firmly. Here’s what I ended up with after about 15 minutes:

DSC 2854

The edges can be a bit rough, as usual with v-scoring, but those rough bits can easily be scratched off with the knife.

And this is what it’s all about:

DSC 2855

Tiny chips, ready for breadboard use!

Solder fumes

In Hardware on Jan 13, 2012 at 00:01

Have you noticed that solder fumes always tend to rise up into your nose? As the type of solder I’m using is particularly irritating, I decided to do something about it, ending up with a very low-tech solution…

Normal fume extractors (Dutch link) tend to suck the air in, filtering it through a carbon filter to actually remove the fumes from the air, but I find them a bit unwieldy. Yet another power cable to clutter my workbench.

Here’s my solution:

DSC 2852

A small 12V brushless PC fan, which happens to still start up and rotate reliably at 3.6V, as provided by three Eneloop AA batteries. Stuck to a battery pack (with on/off switch) using hot glue, which also doubles as weighted base for it all. The fan is slanted slightly downwards, to better cover the area on the table.

The result is whisper quiet and generates a micro breeze which gently diverts the solder fumes away from my nose. This particular fan draws only 30 mA @ 3.6V, so it’ll last some 70 hours on a single battery pack. And since these are rechargeable batteries of which I keep a constant supply, that’s plenty for me.

Long live re-use!

Ground noise

In Hardware on Jan 12, 2012 at 00:01

To try and improve noise levels during measurements (and as general ESD precaution), I went “green”:

DSC 2851

That’s a green ESD mat, covering almost the entire workbench. It’s hooked up to the radiator for grounding. Note that the mat only provides a “dissipative” connection to ground, the surface still has several MΩ’s of resistance. It’s just to get rid of static electricity and to offer a clean protective working surface. Got the mat from Farnell, BTW.

Here’s what I see when pushing a scope probe onto the mat:

SCR77

A clear 50 Hz pattern of a couple of volts (the amplitude increases when the probe is pushed more firmly onto the mat). This is with a standard 10 MΩ high impedance probe. The big puzzle is: where does this come from?

My explanation for now, is that the scope ground is “floating” a bit, due to the different devices hooked up to the house wiring. Note that the mat is tied to the radiator, not to the ground of AC mains. Since there isn’t any current flowing through the heating system (I hope!), I’m inclined to trust it more as being the “real” ground potential.

It’s no doubt completely harmless. Measuring AC current between these two ground levels with my most sensitive multimeter (a Voltcraft VC940), I see a very occasional blip of up to 0.20 µA flowing. Well under a microwatt.

To give an idea how crazy things can get, here’s the mat with nothing connected – turning it into one big antenna:

SCR79

Who knows, maybe one day we could harvest even this sort of energy, eh?

Frequency generator

In Hardware on Jan 11, 2012 at 00:01

A long time ago, I got this DDS-60 kit, which is a small circuit based on an AD9851 DDS chip:

DDS 60 top 400a

It has everything on board to generate a sine wave from 0..30 MHz, and my intention was to hook it up to a JeeNode (as part of a long term plan of mine to set up a more extensive wirelessly-controlled electronics lab):

DSC 2850

Never got it to work at the time, but now with the new scope, there really is no excuse anymore. First check, as indicated in their build instructions, is to verify that the crystal oscillator is feeding a 30 MHz clock into the chip:

SCR71

Looking good. Very impressive rise and fall times, BTW.

When driven at 30 MHz, the AD9851 output frequency is settable in steps of 0.006984919 Hz. In other words, a multiplier of 1000 will generate a sine wave of ≈ 7 Hz.

Here’s the output when programmed to generate 10 MHz (multiplier 1431655765, i.e. 9999999.9977 Hz):

SCR72

Whoa… it’s 10 MHz, but a far cry from a sine wave. Ah, but that’s not really surprising: this thing uses DDS to synthesize a sine wave, as recently described on this weblog. With 30 MHz sample rate, i.e. 3 samples per wave, it’s not really possible to create a decent 10 MHz sine wave (not even a symmetrical shape in fact, as you can see).

But the AD9851 has a trick up its sleeve: it includes a “6x” multiplier option, which causes it to internally generate a reference frequency which is 6x the incoming clock, i.e. 180 MHz in this case.

Using that, and adjusting the frequency setting to work at 180 MSa/sec, we get a much better approximation:

SCR73

Still not perfect, but by analyzing the FFT of this signal, we can find out what’s going on:

SCR74

This output signal is made up mostly of a 10 MHz sine, with another peak at 90 MHz.

Unfortunately, the output circuit on this board isn’t working yet (this is what probably threw me off when trying this circuit before), so I can’t test the effect of the 60 MHz low-pass filter yet. It won’t filter out the 30 MHz residue visible in that last picture, but should definitely reduce the frequency components over 60 MHz.

Ok, all the important bits seem to work – I “only” need to troubleshoot that analog back end a bit more.

Update – I found the problem: the SMD trimpot was fractured, i.e. no contact. I’ve replaced it with a fixed 220 Ω resistor for now – this brings the output to ≈ 680 mVpp (or 350 mVpp into 50 Ω) – the sine wave output is now considerably cleaner, but several of the frequency peaks ≥ 90 MHz are still present:

SCR76

I suspect that the 30 MHz clock is “feeding through” somewhere, perhaps better decoupling would avoid that.

Fritzing

In Hardware on Jan 9, 2012 at 00:01

The quickest way to describe what Fritzing is about, is to quote the first paragraph on their site:

Fritzing is an open-source initiative to support designers, artists, researchers and hobbyists to work creatively with interactive electronics. We are creating a software and website in the spirit of Processing and Arduino, developing a tool that allows users to document their prototypes, share them with others, teach electronics in a classroom, and to create a pcb layout for professional manufacturing.

It has been around for a while, evolving and improving at a steady pace. Here’s a screen shot of the main window:

Medium getting started 1

The neat bit is that support has now been added for the JeeNode, as well as support for the main two prototyping / extension mechanisms, the JeePlug and the Carrier Card. Just search for the “JeeLabs” keyword:

Fritzed jee

So now you can use Fritzing to design and document projects, and create printed circuit boards for them!

Low-power blink test

In Hardware, Software on Jan 8, 2012 at 00:01

Here is a new snoozeBlink sketch which can run off the new experimental 12 mW Low-power Supply:

Screen Shot 2011 12 28 at 14 48 03

It does all the right things to start off in low-power mode and puts the ATmega to sleep, even as the LED blinks!

The LED is a normal red LED with a forward voltage of about 1.6V and with a 470 Ω series resistor. The result:

SCR03

(lots of noise because I’m using the default 1:10 probe and the scope at its most sensitive 1 mV/div setting)

Voltage over the 100 µF reservoir cap in blue, current consumption in yellow. You can see the startup dip when the cap reaches about 6V, then the 2s wait, and then the LED blink at about 2 Hz with a 10% duty cycle. There’s not much energy to spare – the reservoir cap doesn’t even get a chance to fully re-charge between blinks.

After about 4 seconds, I turned off the power to find out what would happen. Yet there’s still enough energy left to get two more full blinks, and then an aborted blink as the reservoir cap voltage drops below 3V.

Note how the power consumption is just 3 mA while the LED is turned on. The ATmega itself is hardly ever running (the very brief 10 mA peaks got filtered out in this scope capture).

It can even be made to flash with a 26 mA LED current (omitting the resistor) for 16 ms @ 2 Hz. In this case the reservoir cap voltage varied from 9.4 to 4.4 V, again leaving very little energy to spare. Maybe one day this can be refined to drive a TRIAC, which needs very frequent but brief pulses (a BT137, BTA312, or L6004L3?).

But there’s actually something extra-ordinary going on with that power-up sequence – let’s investigate:

SCR04

The BIG surprise? This is running on a standard JeeNode with standard bootstrap – no power-up troubles at all!

Let me try and interpret everything happening in that last image:

the initial very high blip (over 25 mA) is the JeeNode’s on-board 10 µF capacitor charging up
the 65 ms @ 3.2 mA is the clock startup delay, as defined by the default fuse setting
up to this point, the reservoir cap has lost some 2V of its charge
the next blip is the boot loader passing control immediately to the sketch (!)
then there’s the 32 ms loseSomeTime() call in setup(), with the ATmega finally powered down
the last blip at the right-end side of the screen puts the RFM12B into low-power sleep mode

So what’s going on, and above all why is the boot loader problem gone, after all that trouble it gave me before?

The only explanation I can think of lies in the one change I made since then: I’m now using OptiBoot v4.4 … and it probably does the right thing, in that it skips the boot loader on power-up and only goes through a boot-loader sequence on reset. This is the well known ladyada fix. I guess my previous boot loader setup wasn’t using that.

This is really good news. It means you just need a recently-flashed ATmega and you can continue to use the normal FTDI upload mechanism while fooling around with this ultra low-power stuff. Even the 10 µF cap and regulator on the JeeNode can be left in when powering it from the new Low-power supply.

Getting ready for OptiBoot 4.4

In AVR, Hardware, Software on Jan 7, 2012 at 00:01

Ok, it’s official – starting this week, all new ATmega’s here will be flashed with the OptiBoot 4.4 boot loader.

It’s going to take a while for all current inventory units to “flush through the system” so to speak (both DIPs and SMDs), but at some point this month all ATmega’s will be running the same boot loader as the Arduino Uno. Faster, smaller, and – hopefully – no more troubles with Windows being unable to upload sketches through FTDI.

One of the things I’ve done is to turn one of the new JeeNode Blocks into a dedicated Portable ISP Programmer for DIP-28’s. It’s the same isp_repair2 sketch as before (modified for the Block’s minor pin allocation diff’s):

DSC 2847

Note the 16 MHz resonator behind the ZIF socket. Here’s the wiring:

DSC 2848

There’s no 10 kΩ pull-up resistor for RESET, because ATmega’s have a (weak) built-in pull-up.

To avoid the delay-on-hardware-reset, I’ve added a push-button which briefly shorts +3V and GND together through a 10 µF electrolytic cap. Enough to force the JeeNode Block into a hardware reset. There’s a 10 kΩ resistor across the cap to discharge it afterwards. This is really quick because the reset occurs on button press i.s.o. release.

The savings are minimal – just 1..2 seconds more for the standard bootstrap – but for production, it matters. Total flash time, including boot loader, RF12demo sketch, and setting all the fuses is now just a few seconds:

insert DIP chip
close ZIF socket
press button
wait for two LED blinks
open ZIP socket
remove programmed chip
rinse and repeat…

When a serial port is connected via FTDI, you can see the progress of it all:

Screen Shot 2012 01 04 at 20 01 42

Now let’s just hope that this version of OptiBoot doesn’t lead to the same mess as the previous one.

If you have older JeeNodes or other ATmega328 boards running previous bootstrap loaders, I suggest looking at the recent ISP programmer post and the older summary. You might consider bringing all units up to date, because with a mix of boot loaders you end up constantly using the wrong one in the IDE and having to adjust board types each time.

Just be careful when messing with boot loaders. If the process goes wrong and you pick the wrong fuse settings, then you can end up with a “bricked” unit (only a high-voltage programmer can recover from such a state).

But apart from that: enjoy the doubled 115.2 Kbaud upload speed and the 1.5 Kb extra space for sketches!

LowPower, ISP

ISP Programmers – part 2

In AVR, Hardware on Jan 5, 2012 at 00:01

In yesterday’s post, I presented my latest ISP programmers, based on the isp_repair2 sketch.

I made a few small improvements to that sketch:

the RFM12B is powered down at the end, so that the unit only consumes a few µA’s once done
the programming rate has been improved by getting rid of those horribly slow digitalWrite() calls, etc.
updated RF12demo and OptiBoot to the latest version (v8 and v4.4, respectively)

Furthermore, I switched from the funky switches to plain jumpers, with the following layout:

Isp pins

Another change is that the default with no jumpers is now to burn RF12demo w/ OptiBoot for use with a 16 MHz resonator – this is a good default for JeeNodes, JeeNode USB’s, and JeeNode SMD’s. To select the other options, just hook this up to USB, change the jumpers, and watch the serial output report on reset.

This is the output with no jumpers and no target board attached:

This is the output after a normal programming cycle (again, the default case, no jumpers installed):

Programming takes only a few seconds. Note that this programmer is fully self-contained and includes its own LiPo battery, so all you need to do is press the 6 pins on the ISP header pads. The neat thing is that due to the normally-discharged cap on the target board, the brief power dip caused by touching the ISP pads will generate a hardware power-on reset in the programmer, which then immediately starts its programming cycle.

So the the whole workflow is now as follows:

grab this thing – and let’s call it a “Portable ISP Programmer” (PIP!)
press the pins against the ISP header of the unit to be re-flashed
watch the initial LED blink on the programmer as it comes out of reset
wait 2..3 seconds
watch the second LED blink, indicating that it has successfully completed programming

There is no power switch, since the programmer enters total power down when done. To re-charge, plug the programmer into a USB port and wait for the “charge” LED to turn off. Note that pressing the reset button also works, but that it adds a small boot loader delay before the isp_repair2 sketch gets started.

This has become so convenient, that I can now take any old JeeNode lying around here, and reset it to a well-known state in just a few seconds, before re-using it for some project or experiment.

LowPower, ISP

ISP programmers

In AVR, Hardware on Jan 4, 2012 at 00:01

ISP (re-)programming is going to become more important in the future, so I’ve built a few more of these:

DSC 2844

The problem was to come up with a robust way to connect to the target board, but I think I’ve found a solution:

DSC 2843

Take a 4-pin header, slightly enlarge the holes in the plastic, and then gently-but-forcefully press a couple of Pogo pins in there. I’m using the type with a large head with sharp edges. Here’s the whole assembly:

DSC 2839

After that, it’s a matter of attaching all the wires and tying / glueing things together:

DSC 2841

These units are all refurbished ones with a defective radio, since that’s not needed here.

DSC 2840

The ZIP straps hold the battery and wires in place. The hot glue does the rest:

DSC 2842

These programmers are considerably more effective than you might think – tomorrow, I’ll explain why…

Bit-banged I2C timing

In Hardware, Software on Jan 3, 2012 at 00:01

The JeeNode Ports library has supported software-based I2C right from the start. There are some limitations to this approach, but it’s been very useful to allow connecting lots of I2C-based plugs on any of the 4 JeeNode “ports”.

I’ve always suspected that the timing of this software “bit-banging” was off. Well… it’s waaaaay too slow in fact:

SCR65

That’s a JeeNode talking to an RTC Plug over I2C, set to 400 KHz. Except that it’s talking at a mere 40 KHz!

The code works, of course. It’s just far from optimal and wasting time. The main reason for this is that the Arduino’s digitalWrite(), digitalRead(), and pinMode() calls take a huge amount of time – due to their generality. A second problem is that the delayMicroSeconds() call actually has a granularity of 4 µs.

As a quick test, I hard-coded the calls in the Ports.h header to use much more efficient code:

Screen Shot 2011 12 24 at 16 25 56

The result is that I2C can now run at over 300 KHz, and it still works as expected:

SCR66

It can even run at over 600 KHz, which is beyond the official I2C specs, but it works fine with many I2C chips:

SCR67

Except that this now requires a pull-up resistor on SDA (i.e. the AIO pin). The rise-time of the data pulses is now too low to work reliably off the internal ATmega pull-up resistors. I used a 1 kΩ resistor, as pull-up to 3.3V:

SCR68

Note the glitch at the end – it’s probably from emulating open-collector logic with the ATmega’s three-state pins.

Pull-ups are also a very good idea with shorter bus lines, because they also lower the impedance of the wire, reducing noise. These tests were all done with the RTC Plug stuck directly into the Port 1 header, BTW.

Here’s the SDA signal on a 5 µs/div scale – via 4 Extension Cables back to back, i.e. 65 cm – with 1 kΩ pull-up:

SCR70

And without – showing abysmal rise times and lots of crosstalk, making I2C on this hookup totally useless:

SCR69

I’ll need to figure out how to properly implement these software optimizations one day, since that means we can’t just use the generic I/O pin calls anymore. There are several cases: different speeds as well as different ports (including “port 0” which uses A5 and A6, the official I2C pins – but still in bit-banged mode).

All in all, this software-based I2C works fine, with the advantage of supporting it on any two I/O pins – but it could be optimized further. The other thing to keep in mind is that the SCL clock line is not open-collector, but driven by a normal totem pole output pin, so this doesn’t support I2C clock stretching for slow (or busy) slaves.

Tempus fugit …

In AVR, Hardware, Software on Dec 31, 2011 at 00:01

Another year is about to end, and the next one is already anxiously waiting to carry us along into the future…

A fitting moment to get that Dutchtronix clock working (a lot easier than this geek version):

DSC 2832

I bought this little kit long ago, not realizing that a low-end USB scope front-end can’t deal with it. Besides, it turns out that it didn’t work back then because of some bad solder joints (ground planes and 15W soldering irons don’t go well together – even my current soldering iron has trouble heating up some of those pads!).

Anyway, this is as far as the Hameg HMO2024 will go:

SCR60

Recognizable, but a far cry from what analog scopes can do. That’s what you get when digital sampling, waveform refresh rates, and vector drawing clash (bumping up the sampling rate causes a fuller, but flickering, image).

This design was from 2007, I think – which goes to show that fun stuff (especially clocks) can be time-less!

I wish you a healthy, safe, and happy 2012 – with lots of opportunities to tinker, learn, and create.

Update – for another example of how such X-Y displays differ between analog and high-end vs low-end DSO’s, see this video on Dave Jones’ EEVblog.

Anatomy of a Room Node transmission

In Hardware on Dec 30, 2011 at 00:01

Now that my analysis capabilities have improved, it thought it’d be interesting to see the power consumption profile of a Room Node, running the roomNode.ino sketch. Here’s an annotated capture of a motion event:

Annotated room packet

The yellow line is the current consumption of the entire room node. I’ve added some annotations, although there are still a few things I’m not so sure about, such as the 2.5 ms delay between SHT readout and XMIT start.

The red line is the integral of the yellow line, i.e. the total amount of energy consumed as time progresses. It took about 3 ms between the end of the packet transmission and the first ACK packet header byte coming in – this thumb-twitching with the receiver enabled accounts for about 1/3rd of the power consumption!

There is almost always room for improvement with this sort of stuff. The closer you look, you more you find things to optimize. For example, I noticed that there were blips every 32 mS or so (it’s slightly irregular):

SCR54

This is zoomed in on both axes. The noise level is a bit higher, perhaps due to the 2 mV/div setting of the scope.

That’s over 1 ms @ 0.8 mA, at about 30 times per second on average. I don’t know what it is – it’s not the PIR sensor, which was removed during this measurement. Not a lot of energy per blip, but it does add up: ≈ each uses 1.1 µC, i.e. some 2,000 µC per minute. Whereas the first screen shows that a transmission takes only 130 µC.

So there you go: vampire power at microwatt levels!

Update – Ah, wait – of course! – it’s the Scheduler class in the Ports library! When idling, it lets time pass in steps of 0.1s (or rather 96 ms), and there’s no other way to do this than with 32 and 64 ms watchdog timer steps. I told you – there are no show-stoppers in this game, it works on logic and insight, all the way down!

Finished Low-power Supply

In Hardware on Dec 28, 2011 at 00:01

The Low-power Supply described previously on this weblog now has a PCB – and it’s about as small as a JNµ:

DSC 2827 Version 2

Here’s an assembled unit, ready for testing and hooked up to power a JeeNode (w/ disabled bootstrap):

DSC 2831

And here’s the whole test setup I had to create to check this thing out:

DSC 2830

Lots of stuff involved, including high-voltage probe and 230V isolation transformer (to the right, out of view).

Here’s a demonstration of how it works – summarized as one elaborate scope capture:

SCR42

Green is the mains voltage (235 Vrms), purple is the charge building up on the 100 µF reservoir capacitor, yellow is the regulated output, and blue is the JeeNode’s current consumption (measured as voltage drop over 10 Ω). Note how some of the voltages measured here differ more by than four orders of magnitude!

Anyway, that zoomed-in image is the clear signature of the second 8-byte RFM12B packet transmission. Current consumption varies from 23 to 26 mA. It’s a relatively coarse image, since it has been zoomed in 4,000 times.

The 3.3V supply level is reached ≈ 2s after power-up, with another 2.5s needed to fully charge the reservoir cap. You can see from the purple dips that this supply could sustain at least one packet transmit per second.

No surprises here, but it’s good to see that the PCB design works as intended. Next step: implement deep sleep on the ATtiny84 – hopefully this’ll take just some minor adjustments to the Sleepy::loseSomeTime() code.

Bussed SPI – a first test

In Hardware on Dec 26, 2011 at 00:01

It’s time to try out that “bussed SPI” idea, which could turn the 2×4-pin SPI/ISP connector into a real bus for up to 8 high-speed devices. What I came up with as test case, is to hook up two SPI RAM chips, write different values to each of them, and then read them back to check that the values are correct.

Let’s dive in, which in this electro-world means: grab a breadboard and a bundle of wire jumpers!

DSC 2825

At the top, a red USB BUB (v1), and a JeeNode underneath a Bridge Board to bring all the necessary connections onto the breadboard. On the breadboard, from left to right: two 23K256 static RAM chips in 8-pins DIP, and a 74AHC595 shift register as 16-pin DIP package. Apart from the jumper wires, some pull-up resistors, and the scope probes, there are also lots of 0.1 µF decoupling caps. At 8 MHz, they are crucial (as I found out, eventually).

This was (approximately) the code I used for testing (combined with the code in this post):

Screen Shot 2011 12 18 at 00 52 21

Here is a scope trace of the result (yes, it’s the same screenshot I posted a few days ago):

SCR30

There are two decoded SPI signals: MOSI at the top and MISO at the bottom.

What you can see, is that the bytes 0x38 and 0x39 are being read back from one SRAM, immediately followed by the command to write 0x3C and 0x3D – these values then get read back on the next iteration. The values 0x3A and 0x3B end up in the other SRAM. You can also see the slave select setup via the B0 pin for SRAM #1 (0xFD), and a different value for SRAM #2 (0xFB). Note how this needs a mere 2 µs extra to switch SPI slaves.

In short: it all seems to work!

I’ll have to do a lot more testing of course, to find out how reliable this is at this high 8 MHz speed, and how this works out across multiple boards, all stacked up together. But if it does, then this might become a very handy new convention for little “stacker” boards on top of a JeeNode. Look Ma, no extra pins!

The SPI bus: tamed, at last?

Trying to improve on the SPI bus

In Hardware on Dec 24, 2011 at 00:01

Yesterday’s experiment was done with a very specific purpose (yeah, sometimes I do things for a purpose…).

I’m trying to overcome a major drawback of the SPI bus. But to explain this, allow me to go on a little detour first. The I2C bus is an extremely convenient design, because it only needs 4 wires to connect several chips together:

350px I2C

Each chip sees the same information, but it works because each chip has been set up to respond only to a specific address on the bus. And that address happens to be conveniently located at the start of each I2C message.

But although the I2C bus is slow, usability is where the SPI “bus” suffers in comparison:

350px SPI single slave

With one chip, there’s no problem: one “slave select” (SS), a “serial clock” (SCLK), a “master-out slave-in” (MOSI) pin for outgoing data, and a “master-in slave-out” (MISO) for incoming data (brilliant naming – no confusion!).

The trouble is with multiple chips, i.e. slaves. The SCLK, MOSI, and MISO pins can be shared, but not the “slave select”. Each slave will need a separate pin to select it. And that makes it impossible to use it as a real bus…

If only there were a way to get multiple slave selects onto a single pin…

And that’s where yesterday’s post comes in. Suppose we had all the SPI signals, as well as power, as well as two chip selects. Like, eh… the SPI/ISP connector, using B0 and B1 as the two select signals – how convenient!

So here’s the idea: first we send a byte over SPI with B0 set low and then we send the actual data with B1 set low. The B0 transfer is used to select one specific slave, and the B1 transfer then takes place only with that slave.

The good news is that a 74HC595 shift register has all the functionality needed to perform this task, by using the three-state enable pin as a gate to turn the shift register outputs on or off. Here’s the schematic for it all:

Screen Shot 2011 12 17 at 22 40 47

The idea is to put this simple circuit on each slave board. On each one, a different output from the shift register gets jumpered. In the above schematic, for example, QD (the 4th bit) has been wired up as slave select.

Here’s code for trying out this idea, optimized to only send data on B0 when a different slave is being selected:

Screen Shot 2011 12 17 at 23 47 07

The following code also needs to be executed to set things up properly on power-up:

    // init PB0 and PB1 as outputs, set high
    PORTB |= bit(1) | bit(0);
    DDRB |= bit(1) | bit(0);

Anyway. So much for theory… stay tuned!

PS. Season’s greetings to everyone. This weblog will continue on auto-pilot for the next two weeks. Enjoy!

Decoding SPI with a shift register

In Hardware on Dec 23, 2011 at 00:01

Here’s a fun experiment – adding 8 very fast output pins via SPI, using just a 74AHC595 shift register:

JC s Doodles page 31

This is the “spiCycle” test sketch I used to try out the above hardware:

Screen Shot 2011 12 15 at 18 43 23

It sends bytes to the shift register, with only bit 0 set, then only bit 1, etc. At the end, a zero byte is sent to clear all bits again, which is why the loop runs to 9 i.s.o. 8. Here’s the output, as seen on the scope via a logic probe:

SCR25

The yellow trace is SCK. The blue trace is PB0 (Arduino digital 8), which is used as chip select for the shift register. The purple lines are the 8 outputs of the shift register. You can see the “1” bit rippling across all 8 pins.

As you can see, there’s plenty of “ringing” on these signals, which is not surprising, given that it’s a bus running at 8 MHz (and it was all set up on a breadboard using jumper wires). Setting these 8 bits takes just 2 µS!

Note that the number of output bits can easily be extended by “cascading” multiple shift registers, so this is in fact a way to add lots of output pins to an ATmega which can be set very, very quickly.

There’s one oddity in there which I can’t explain – for some reason, the PB0 select pin is being pulled low longer and longer as the loop repeats (see the blue line “low” states).

Tomorrow, I’ll explain the point of this exercise…

My scope story – conclusion

In Hardware on Dec 22, 2011 at 00:01

As it so happens, my scope finally arrived – and was immediately given a central place on the JeeLabs workbench:

DSC 2823

It’s phenomenal. You’ve seen plenty of analog signal traces on this weblog recently, but this one includes a logic analyzer (up to 11 channels) and serial protocol decoding + triggering. Here’s an example with bi-directional SPI:

SCR30

(these screenshots are slightly fuzzier than the real thing, because I had to resize the images to fit this weblog)

Light blue is the bus decoding, yellow is the analog SPI clock (with lots of over- and under-shoot), and purple is for the logic analyzer POD. Small gotcha: on a 4-channel scope, it’s either analog channel 3, or the 8-wide logic probe – never both at the same time. But on the plus side: if you only use 2 analog channels, then the scope can re-purpose the unused channels to double its max sample rate to 2 GSa/s, and its memory depth to 2 MB each.

That first photo shows the same SPI clock, BTW – it’s what 8 MHz on jumper wires + a breadboard looks like!

As it turns out, I ran into two problems while pushing the HMO722 unit loaned to me by Rohde & Schwarz. One of them was a mis-interpretation of the screen display on my side, while the other one uncovered a limitation of (only) the HMO722. In both cases, the support from R&S was very impressive: quick, knowledgeable, and best of all… effective. In this day and age, that’s exceptional – and laudable.

Here’s another capture, triggering in RS232 / UART mode on the character 0x1D, as decoded at 115.2 Kbaud on the TX line. You can see a small sketch upload (green) and the beginning of the verification read-back (yellow):

SCR36

I’ve not seen this feature in low-end logic analyzers yet. It’s probably a separate FPGA, able to decode various protocols to generate the desired trigger signal, and – being an MSO – it also ties into analog acquisition.

Note that this can be done without logic probe. It was enabled here (the two purple lines) but it’s not essential, since serial protocol decoding + pattern-based triggering can also be performed with just the analog channels. The serial data single-shot storage limit is around 2.5 Kbyte (all data is sampled and stored as a bit stream).

One more thing I really love about this scope: it’s totally quiet (thank you Hameg, for following Apple’s lead!).

I can only repeat: this HMO series is the most modern in its class IMO and has an excellent price / performance ratio, with features matching some Tektronix and Agilent scopes at twice the price. If you don’t want to settle for a USB scope or one of the Rigol’s, then get the Hameg HMO724 (or one of the others, with a higher b/w front-end).

A scope is not for everyone, of course. And this one even less so, no doubt. Keep in mind that the landscape will be completely different again two years from now. So if you don’t plan to use it much, better hold on to your cash.

But if you do need a scope now, then I hope these last few posts can help you make up your mind…

PS. A comparison in German between the Hameg and Agilent scopes can be found here (written by Hameg).

Getting an oscilloscope – part 2

In Hardware on Dec 21, 2011 at 00:01

This post continues where yesterday’s post leaves off, w.r.t. my adventures with oscilloscopes.

Last October, I decided to get a “real” scope. There were plenty of experiments (ongoing and planned), which would justify getting a new instrument for. Besides, Dave Jones’s review and teardown of in particular the Agilent InfiniiVision 3000 X series scopes got me completely drooling, while at the same time knowing I’d never be able to afford (let alone justify) buying such a high-end (for me!) oscilloscope.

The most popular unit by far probably, is the Rigol 1052E and its cousin the 1052D with logic analyzer. The former is called a “DSO” (Digital Storage Oscilloscope), while the latter is a more recent trend called the “MSO” (Mixed Signal Oscilloscope). The market price for these two seems to be around €400 and €900, respectively.

MSO’s are more pricey than DSO’s, and in a way it’s not easy to justify the price difference, particularly if you consider that USB-connected Logic Analyzers such as the ZeroPlus and Openbench Logic Sniffer can be had for a fraction of that price difference. My main reason for exploring MSO’s can be summarized in one word: knobs.

But before I explain, let me describe the Rigol scope and how it worked out for me.

As it so happened, a good friend was willing to lend me his Rigol DS5062CA, which appears to be the predecessor of the DS1052E. It’s very similar, in looks and in functionality:

DSC 3557

The specs of this scope are actually really good: 60 MHz bandwidth and a whopping 1 GSa/s sample rate. This means you really will get more than enough samples to get a very accurate view of a 60 MHz sine wave on screen, and probably also of a 5 .. 10 MHz square wave.

If you’ve been following this weblog in October and November, then you’ll have seen dozens of blue screen shots in the various posts, all taken from this Rigol scope (using a camera, as this unit has no front-side USB).

Since I really wanted to learn as much as I could about a scope like this, I spent a lot of time exploring all its features, including signal filtering, trigger delays, zooming in, measurements, cursors, maths, all the way to FFT. My first conclusion has to be that there is an incredible amount of functionality in such an instrument. This little unit is a perfect example of what sets a DSO apart from classical analog scopes. It’s a different ball game.

But the second unexpected outcome of this learning process, is that it convinced me completely that “knobs” are dramatically more convenient than any computer-based emulation using keyboard and mouse. Within a few weeks, motor memory sets in: you intuitively push the right buttons and turn the right knobs, while analyzing a signal and looking for the best way to visualize it. You can keep your eyes on the screen and on the circuit, while resting one hand on the controls and adjusting things. I’ll never go back to a USB-connected solution.

So the search was on – a scope, preferably with a built-in logic analyzer.

I had already figured out two things: 1) scope prices are unbounded, and 2) I’ll buy one once, and never again. This insight was an agonizing one: I knew I was going to spend way more money than I was comfortable with (for both reasons #1 and #2) and I also knew I’d be stuck with my choice forever, for better or for worse.

I’ll spare you all my deliberations. Everyone will attach a different weight to different aspects. In my case, I did want a “better than 320×240 display” and a bandwidth of ≥ 100 MHz, to cater for (vague) future needs.

As already documented on this weblog, I ended up going for the Hameg HMO722 .. HMO2024 series, now produced by Rohde & Schwarz. The bandwidths run from 70 to 200 MHz, as 2- or 4-channel units. Here’s the HMO722, on loan from R&S until my unit arrives:

DSC 2819

It’s interesting how the controls are organized slightly differently from the Rigol, and how relatively long it took me (already!) to re-learn and re-internalize the placement and menu structure. As with a photo camera, you really have to go in the deep end and completely familiarize yourself with all the different corners of the equipment to the point that – after that – you can fully focus on the experiment, the circuit, and its signals.

My conclusion? I’m very happy with this choice, and I’m not saying this to mask any form of buyer’s remorse – there is none. I ended up going for the high-end model: 200 MHz, 4-channel. And I’d do it again tomorrow.

So what would you do, if you’re considering getting a scope? Here are my – unsolicited – suggestions:

budget €100 – don’t get anything and don’t worry too much – you can have lots if fun without one
budget €250 – get something like a DSO-2090: 2-channel, very decent software – or check out this list
budget €400 – get the Rigol DS1052E, it’s popular and it’ll give you the most bang for the buck, IMO
budget €900 – get either a Rigol DS1052D, or a DS1102E w/ separate logic analyzer (such as the OLS)
budget €1700 – get the Hameg HMO724, superb features, can also act as 4-channel logic analyzer
budget €2600 – get the Hameg HMO2022 w/ options, or the HMO2024 (which is what I chose)
budget €4000 – don’t despair, there’s one just right for you too (there are no doubt newer lists)
budget €7000 – go for it, get that 4-channel 350+ MHz Agilent 3000-X series MSO, with lots of options

If I had to pare the list down further, I’d make it a choice between the Rigol DS1052E and the Hameg HMO724.

Stay tuned for the last part of this series, tomorrow.

Getting an oscilloscope

In Hardware on Dec 20, 2011 at 00:01

(Note – a better title would probably have been: “How I picked an oscilloscope”, since YMMV!)

Oscilloscopes are the “printf” of the electronics world. Without a “scope” you can only predict and deduce what’s happening in a circuit, not actually verify (let alone “see”) it. Here’s what an oscilloscope does: on the vertical axis, you see what happens, on the horizontal axis you see when it happens. It’s a voltmeter plus a time-machine.

Most modern oscilloscopes are digital. One advantage is that they can store the observation, long enough for us sluggish humans to look at the captured signal and ponder about it. For things which happen only rarely, that is crucial. But even when you’re examining things that are periodic, like the shape of a waveform, the scope gives you time to think regardless of the time scale of the event.

If you’re into soldering, then you really need at least one multimeter. Any one will do, even the cheapest one. If you’re into electronics, to the point of trying out new circuits, then you should consider getting an oscilloscope. And lastly, if you’re into pushing limits of any kind with these circuits, then you must have an oscilloscope. Let me add for completeness, that if you are only working with digital chips, interconnecting them in your projects but not really operating at the upper range, then you might want to get a Logic Analyzer first. A logic analyzer is similar to a scope, but only cares about (multiple) 0/1 signals, not actual voltage levels – their analog input circuitry is simpler than scopes, but they usually need to sample over much longer periods of time to be useful.

In this 3-part post, I’ll describe how I started out and where I ended up, with also a bit of “why” thrown in.

My first purchase, 3 months after I started with JeeLabs, was a DSO-2090 USB oscilloscope front end for a PC:

DSC 2820

It samples at 100 MSa/s and is quoted as having a 40 MHz bandwidth. Realistically, these figures tell me that it’ll give a good view of sine waves up to 20 MHz, and square waves up to say 3 .. 5 MHz. It cost me €239 at Conrad.

Such a “USB scope” does all the analog stuff in the box, and then pushes the digitized data over USB to the host PC to do the rest of the work, including presenting an oscilloscope-like display on the screen. The DSO-2090’s software is fairly good (Windows-only, not very convenient for me).

First off, let me say that I’ve got over 2 years of excellent mileage out of this thing. It’s 100x better than no scope.

The limitations I ran into were as follows:

It’s tied to USB, and hence needs to be close to the computer or notebook. This wasn’t always convenient for me. A second aspect is that the whole thing is not “galvanically isolated” – signal ground is USB ground. For my recent 230V AC mains experiments, that simply wasn’t practical anymore.
Emulating a scope on screen, while tempting due to the available screen real-estate, is not as great as I had thought. It’s downright tedious to rotate a knob on-screen using a mouse, and if you don’t, then you have to figure out a bunch of keyboard shortcuts (and remember them next time around!).

Which led me to get this tiny unit as add-on – a DSO Nano (v1), sized and shaped a bit like a mobile phone:

Dsc 2123

At US$ 90 from SeeedStudio, I didn’t expect this 1-channel 1 MSa/s scope to replace my DSO-2090, it was more a way to get a very portable unit, and a convenient little box on the desktop.

The DSO Nano trades screen size (dropping back to 320×240) for battery-powered unthethered operation. There are now more capable (and more pricey) models with 2 analog channels.

It’s a neat little box, but I underestimated the fact that the controls are even more limiting, and that a 1-channel unit very much reduces the number of things you can do with it. It’s probably fine for audio work, but with a scope, capturing the right signals at the right time is crucial, and a 1-channel unit doesn’t offer many options for triggering. In the end, I decided that the unit was not for me, and have since re-sold it.

Two years pass…

Yes, it actually took me about two years to realize that I wasn’t getting nearly as much out of my DSO-2090 as I ought to. I had also bought a Logic Analyzer around the same time (a ZeroPlus LAP-16032U), but it too was mostly sitting on the shelf collecting dust, again because having a USB device with Windows software connected to my Mac in the wrong place wasn’t truly convenient.

Last October, I decided that it was time for a change – stay tuned for the rest of this story in tomorrow’s post.

The JeeNode, as seen from 15.24 km

In AVR, Hardware on Dec 19, 2011 at 00:01

(that’s 50,000 feet, or 9.47 miles – if those units mean more to you)

This post was prompted by a message on the forum, about what this whole “JeeNode” thing is, really.

Here are a JeeNode v6 and an Arduino Duemilanove, side by side:

DSC 2826

Let me start by saying, tongue-in-cheek: it’s all Arduino’s fault!

Because – let’s face it – the core of each Arduino and each JeeNode is really 95% the same: an Atmel AVR ATmega328P chip, surrounded by a teeny little bit of support circuitry and placed on a printed circuit board. So part of the confusion comes from the fact that the Arduino introduced its own conventions, moving it further away from the underlying common ATmega technology.

The differences between an Arduino Duemilanove and a JeeNode v6 – which resemble each other most – are:

the JeeNode has a “skinnier” shape, incompatible with Arduino “shields”
the Arduino runs at 5V, whereas the JeeNode runs at 3.3V (this carries through to all I/O pins)
the JeeNode includes a wireless radio module, called the RFM12B by HopeRF
the Arduino includes an FTDI <-> USB interface, while the JeeNode relies on an external one

There are many other differences, of course – so let’s continue this list a bit:

the Arduino’s “eco-system” is far, far bigger than the JeeNode’s (translation: everyone who finds out about JeeNodes probably already knows about the Arduino platform, and usually already has one or more of ’em)
this carries through to articles, websites, books, and discussion forums – Arduino is everywhere
you can do lots of stuff with an Arduino without ever touching a soldering iron, whereas the JeeNode is really not usable without some soldering (even if just to solder on a few pin headers)
different pinouts… it’s one big conspiracy to confuse everyone, of course! (just kidding: see below)

My reasons for coming up with the JeeNode have been documented in the past on this weblog, and can be summarized as: 1) running at 3.3V for lower power consumption and to better match modern sensors and chips, and 2) supporting a simpler form of expandability through the use of “plugs” – little boards which can be mixed and matched in many different combinations.

On the software side, JeeNodes remain fully compatible with the Arduino IDE, a convenient software environment for Windows, Mac, and Linux to develop “sketches” and upload them to the board(s).

The biggest stumbling block seems to be the way pins are identified. There are 4 conventions, all different:

Atmel’s hardware documentation talks about pins on its internal hardware ports, in a logical manner: so for example, there is a port “D” with 8 I/O pins numbered 0..7 – the sixth one would be called PD5.
Then there is the pin on the chip, this depends on which chip and which package is being referred to. On the 28-pin DIP package used for an ATmega328P, that same PD5 pin would be identified as pin 11. That’s the 11th pin, counting from the left side of the chip with pin 1 at the top.
The Arduino run-time library has software to control these pins. For a digital output pin, you can set it to “1” for example, by writing digitalWrite(5,1). This resembles PD5, but it fails for other pins (PB0 is “8” in Arduino-land, and PC1 is “1” if used as an analog input, or “15” if used otherwise – go figure…).
The JeeNode organizes several pins as part of 6-pin “Ports” (no relation to Atmels terminology!), each of them having 1 digital and 1 analog-or-digital pin.

The thing about JeeNode Ports is that there are 4 of them, and they can all be used for plugs in the same way. To support this, there’s a Ports library which lets you define port objects. This is an abstraction layer on top of the Arduino runtime. The reason is that it lets you associate a port object with a header on the JeeNode:

    Port myport (2);

Then you can connect your hardware / sensor / plug / whatever to the header marked “P2” on the JeeNode, and access it as follows:

    myport.digiWrite(1);

This happens to be the same pin as in the examples above, i.e. PD5 of an ATmega, pin 11 of the 28-pin DIP chip, and digitalWrite(5,1) on an Arduino. This also means that there are numerous ways to perform the same action of setting pin 11 of the chip to a logical “1” (i.e. 3.3V or 5V):

the “raw” C-level access, using Atmel’s register conventions and definitions (fastest, by far):

    PORTD |= 1 << 5;  // or ...
    PORTD |= _BV(5);  // same thing
    bitSet(PORTD, 5); // same thing, using an Arduino macro

the Arduino way of doing things:
```
    digitalWrite(5, 1);
```
the JeeNode Ports library way of doing things, as shown above:
```
    Port myport (2);
    myport.digiWrite(1);
```
… let’s throw in an extra bullet item, since every other list in this post appears to come in fours ;)

The one (minor) benefit you get from using the Ports approach on a JeeNode, is that if you attach your hardware to a different port, say port 3, then you only need to change a single line of code (to “Port myport (3);” in this case). The rest of the code, i.e. everywhere where its pins are being read or written, can then remain the same.

For an overview of all pinout differences, see also this weblog post. For full details, see the JeeNode PDF docs.

Meet the Low-power Supply

In Hardware on Dec 18, 2011 at 00:01

Now that everything is working, I want to have a ready-to use printed circuit board for it. Came up with this:

Screen Shot 2011 12 09 at 18 34 14

It’s tiny – about 48 x 12 mm – even though it’s based entirely on through-hole parts. The idea is to build it up, add wires, and then encapsulate the whole thing in heat-shrink tubing to reduce the number of contact points.

It can not be repeated enough: when tied to AC mains, the ENTIRE circuit carries AC mains voltage levels!

I have a couple of configurations in mind (see yesterday’s post for the schematic):

with C1 a 10 nF X2 cap and C4 replaced by a wire, this delivers an average of 0.3 mA on 230 VAC mains
with C1 a 22 nF X2 cap and C4 replaced by a wire, this delivers an average of 0.3 mA on 115 VAC mains
with both C1 and C4 22 nF caps, this supplies 0.3 mA on 230 VAC with no direct connection to AC mains
with C1 and C4 replaced by a wire, this supply can be used with 10..24V DC in – which is great for testing
with C1 and C4 each replaced by a 220 kΩ resistor, and R1 by a 1N4007 diode, this becomes a somewhat less efficient (but lower-profile) resistive version, again delivering up to 0.3 mA at 230 VAC

With C4 replaced by a wire, this circuit will have its “GND” output tied directly to the “N” input. This is important when powering the AC current monitor, which needs to have one side of its shunt at 0V relative to AC mains.

Note that no matter what, even with C1 and C4 both included, faults can develop in this circuit which cause the “low voltage” output of the circuit to end up directly tied to an AC mains “live” line. This is not, and will never be, a “safe” circuit. It can only be used safely while enclosed in a plastic box, with no contacts or parts sticking out.

In all cases, the on-board regulator will be activated once the input voltage rises to about 6V. This is the key to being able to power up a JeeNode or JeeNode Micro with their on-board RFM12B module.

A power supply which draws 12 mW!

In Hardware on Dec 17, 2011 at 00:01

It’s been a challenge to get all the bits of the AC current monitor ready, but the last hurdle has now been taken.

In a nutshell: the AC current monitor is a small unit based on a JeeNode Micro, which periodically broadcasts information about the current consumption of an attached appliance. It’s hooked up to 230V, so it’d be a bit silly to run it off batteries. It would be equally silly if it were to draw lots of power, and since it has to be permanently on, I wanted to get its power consumption really, really low – under 0.1 Watt. That goal has now been reached.

According to this calculator, the following setup draws only 12 mW @ 230V and will supply 0.3 mA @ 3.3V:

DSC 2821

Here is the schematic:

Screen Shot 2011 12 09 at 02 54 33

It’s a transformer-less capacitive power supply, combined with an LT1121 low-power 3.3V linear regulator. C4 can be omitted. This regulator has a shutdown pin, which is tied to the input voltage via a voltage divider. As a result, the output of this supply switches on only once the 100 µF reservoir capacitor has charged up to 6V (it’ll continue charging to 12V, at which point the zener diode kicks in). Here is the power-up behavior w/o D2, and no load:

SCR85

The blue line is the voltage over the reservoir cap, and the yellow line is the regulated output. If you look very closely, you can even see the 50 Hz cycles “pumping up” the reservoir once every 20 milliseconds.

By itself, this isn’t good enough yet to drive my test JeeNode (no bootstrap, brief wakeup activity every 10s):

SCR90

Very odd behavior, as the regulator and the RFM12B start pulling more current than is coming in, preventing the output from ever reaching more than 1.8 V (I used a 470 µF reservoir cap in this test).

The final trick was to add a diode from the regulator output to the shutdown pin. This positive feedback causes the regulator to very quickly snap out of shutdown mode. So once the reservoir cap reaches about 6V, the regulator switches on, at which point the shutdown pin is quickly pulled high to finish the job and keep it on:

SCR96

This is running from 150 VAC using the new AC power box. At lower voltages, the trickle current becomes too weak to reliably turn on. At 230V, on the other hand, the whole startup process is even quicker and very robust.

I have not yet been able to measure the power draw of this supply. Due to its design it will always draw the same amount (predicted to be 12 mW), regardless of load. The feed capacitor (C1) is a 10 nF X2 type.

Here’s the final proof – a JeeNode, powering up in a few seconds and sending out a test packet every 10 seconds:

SCR99

Many thanks to martynj – his weblog comments and great suggestions by email made this result possible.

Good – now I can sprinkle dozens of these around the house and still use no more than one Watt extra!

Messy signals

In Hardware on Dec 16, 2011 at 00:01

Digital circuits work with 0’s and 1’s, right?

Well, yes, but that doesn’t mean the analog voltages and currents are necessarily very “clean”. To fabricate a somewhat extreme example, I connected a JeeNode without regulator and without 10 µF capacitor to a 3x AA battery pack, and made it run this simple loop:

Screen Shot 2011 12 01 at 17 07 09

Sleep for 3 seconds, then send an SPI command to the RFM12B wireless module. Note that the RFM12B is not set to receive or transmit mode – the ATmega just sends it 2 bytes over SPI.

Let’s look at the variation in voltage and the current consumption (this shows the benefit of an MSO, BTW):

SCR65

The ATmega wakes up, sends four 16-bit commands over SPI (the compressed timeline is a bit misleading) and powers off again. The whole process takes less than 200 µs. The four SPI transfers are: wake up the RFM12B, send it the 0xFE00 soft reset, and then two more to send the RFM12B back to sleep. You can even see the ≈ 0.6 mA baseline increase while the RFM12B is awake and idling. The SPI bus runs at 1 MHz in this example i.s.o. 2 MHz, because the ATmega is running off its 8 MHz internal RC oscillator, but the sketch was compiled for 16 MHz.

The current spikes are not so important. It’s normal for switching signals to consume relatively much energy (that’s why turning off the clock saves so much power). The problem here, is that these current fluctuations have such a large impact on the supply voltage – one of the spikes causes the supply to briefly drop more than 0.25V!

This is why “decoupling” capacitors are used around digital chips, even a lowly ATmega consuming just a few milliamps (it’s running at 8 MHz here, BTW). There is a 0.1 µF cap on the JeeNode board, but it’s not enough.

Here’s the same circuit, with both signals in close up:

SCR57

Nasty stuff. I’m not 100% convinced that the real waveforms look exactly like this (the scope and probe might be distorting it a bit), but there’s no question that each SPI pin change has a substantial impact on the supply rail.

Here’s the same, with a 0.1 µF capacitor added near the battery pack:

And with a 470 µF electrolytic cap (both showing just the scope’s measurement results):

Note that the 0.1 µF cap has much more effect, relatively, than the 470 µF one. It’s better for HF noise reduction.

Does it matter? Yes, probably. Although all these setups work fine, the variation in voltage is fairly large, and could cause problems when operating at lower voltage levels, nearer the specified limits. Also, such currents might generate a fair bit of Electromagnetic Interference (EMI).

By adding more capacitors very near to the power consumers, i.e. the ATmega and RFM12B, this can be reduced. Such decoupling capacitors will act like little charge buffers, helping the supply cope with such sudden changes.

There’s much more to it than that (there always is). At switching frequencies of 1 MHz and above, the impedance of a wire starts to matter a lot. In fact, it’s amazing that digital circuits work at all – even without any HF design!

I’ll investigate further, but for now just remember: when in doubt, add caps … everywhere.

AC Power Box

In Hardware on Dec 14, 2011 at 00:01

Finally got around to finishing the low-power steppable AC mains transformer – yeay!

DSC 2818

The box I had picked was almost too small, so it’s a pretty tight mess in there:

DSC 2817

Main parts used (and yes, that board is kept in place with hot glue!):

2×11 rotary switch – DigiKey # 360-2353-ND
2x28V @ 20 mA transformer (2x) – DigiKey # MT2129-ND
2x18V @ 65 mA tarnsformer – DigiKey # MT2122-ND
230V 3W signal lamp – RS Components # 3393254

The circuit is as described on that “Transformers – part 2” link listed above, except that I’ve added a 3W 230V incandescent light bulb in series with the primary windings (thx for the tip, Martyn!). They draw 13 mA when glowing, but when cold the filament resistance is only 2 kΩ – which is great, because this way over 85% of the AC mains will go to the transformer while it is unloaded, or very lightly loaded. Once the load increases, the light bulb acts as a PTC, lights up, and reduces the voltage left for the transformer. It’s an extra precaution – I’ll need to test it with a dummy load to see what happens to the voltage when drawing more current.

Also, I’ve decided not to ground a center tap on the secondary windings after all. The reason is that I want to be able to tie this to a regular oscilloscope probe (not just the new isolated differential probe). This automatically grounds one side (and would interfere with a grounded center tap), so the safe way to use this thing will be to stay in the lower voltage ranges. That means this setup is now simply an isolation transformer, like my other one.

Anyway, the point of this all is to have 10 different voltage steps to test with. Here’s how they came out:

17.8 Vrms
30.0 Vrms
35.5 Vrms
47.0 Vrms
58.3 Vrms
64.3 Vrms
75.6 Vrms
92.3 Vrms
119.6 Vrms
147.7 Vrms

This was measured with a 100 kΩ resistor over the output, to create a very light load. Unloaded, the maximum voltage will rise slightly further – to 155 Vrms.

Now maybe 155 Vrms doesn’t sound like that much, but that “rms” stands for root mean square. That’s sort of an average value. The peak voltage at the crest of this particular waveform is actually 240 V. On the scope, this is displayed as a wave with an amplitude of 480 Vpp peak-to-peak.

Speaking of waveforms – in my setup, it’s not really a sine wave that comes out:

SCR80

The FFT analysis shows that there are all sorts of harmonics in there:

SCR78

(a pure sine wave would only have that very first 50 Hz peak at the left, as far as I understand FFTs)

But hey, it’s a great setup to test low-power transformer-less power supplies. The lower voltage ranges are safe, currents are limited to tens of milliamps, it’s isolated, and the output voltage ought to collapse when loaded by more than 20..30 mA (this still needs to be verified).

Noisy workbench!

In Hardware on Dec 9, 2011 at 00:01

It never occurred to me that RFI would be an issue, but it sure is. There’s lots of electromagnetic interference around my workbench here at JeeLabs. And it’s messing up my scope experiments – here’s a baseline:

SCR27

That’s the signal, picked up by an unconnected probe lying on the table. The pane at the top is the raw signal, synchronized to the AC mains line frequency. The pane at the bottom is a Fast Fourier Transform – which has always fascinated me as a kid (yeah, I was born a geek) – the X axis is frequency instead of time. This analyzes a signal and decomposes it into a set of sine waves (every periodic signal can be treated as a sum of sine waves).

The peak at the left is “zero”, or rather, 50 Hz. There’s a weak peak at 128 KHz and a surprisingly strong peak at 675 KHz (update: probably a nearby 100 kW AM transmitter). That’s the noise the probe is picking up.

This was with my LED light strip powered from the (linear) 12V lab power supply. With a switched 12V supply, still powered on 100%, i.e. no PWM, I get a couple of extra spikes:

SCR28

Looks like this SMPS is switching at about 55 KHz. So I think I’m going to drive these LEDs with a conventional linear power supply – unregulated, to keep losses low.

I’m averaging the FFT results to get a clean readout. This is possible because the signals I’m after are repetitive and constantly present. Now let’s change the scale a bit and look again at the probe’s pickup with no lights on:

SCR24

Pretty clean – but watch what happens with the little fluorescent light of the magnifying glass I use for soldering:

SCR25

It’s a pretty hefty 30 KHz transmitter! (the strong odd harmonics indicate a square wave, i.e. on/off switching)

The moral of this story: if you want to measure weak signals, clean up your desk – electromagnetically, that is!

RFM12B low-power startup

In AVR, Hardware on Dec 8, 2011 at 00:01

The startup saga continues. Too many inter-related issues, I need to simplify…

Before tackling the power-ramp startup scenario, i.e. starting up a JeeNode (or JeeNode Micro) on a slowly-charging capacitor, I wanted to make absolutely certain that the sketch is set up to get the best low power mode as quickly as possible after a hardware power-on reset.

Time to create a test setup:

DSC 2816

This is a JeeNode running off 3.6 .. 3.9 V battery power, driving a MOSFET plug using this sketch:

Screen Shot 2011 11 30 at 17 08 54

In other words: power up for 2.5 seconds, power down for 0.5, then rinse and repeat. The JeeNode sitting upright at the bottom right is the Device Under Test (DUT). It’s a JeeNode without regulator, with a little test board to pass the ground connection through a 10 Ω resistor. This lets me measure current (or rather: voltage drop) as well as the voltage of the power supply.

Here is the behavior of a standard ATmega, with standard fuses and a sketch to init & power down the RFM12B:

SCR36

There’s a 1.5s startup delay as the boot loader listens for incoming commands, before it passes control to the current sketch. The lower half of this screen shot shows that point, i.e. right when the sketch is given control. Within about 250 µs, the RFM12B is put to sleep. The vertical scale is 2 mA/div (Ohm’s law, 10 Ω resistor).

Note the time scale: the lower portion is zoomed in 1000x w.r.t. the top.

After lots of experimentation, with the boot loader disabled, I managed to get startup a lot quicker, using a lot less energy. The code used was as follows (with these fuse settings: EXT = 0x06, HIGH = 0xDB, LOW = 0xC2):

Screen Shot 2011 11 30 at 18 22 47

Here is a screenshot with all the traces properly labeled and with measurement units added:

SCR50

Note again the horizontal time scale (top left). Here’s how to identify the different portions of these graphs:

the first blip is when the ATnega comes out of power-on reset
the second blip is for the rf12_initialize() and rf12_sleep() calls
the third blip is the first time loop() is run, which then quickly goes to sleep again

The big surprise (and disappointment) here, is the time between blips 1 and 2, where the average current consumption is about 0.75 mA (between the white cursor lines). This is caused by the RFM12B starting up (a bit irregularly) with the crystal oscillator enabled, instead of in power down.

The problem is that the RFM12B can’t be accessed in the first 30 ms or so after power up (probably because it’s still busy getting out of its own hardware reset). That’s a shame, since the ATmega can go to sleep in ≈ 250 µs.

The point of this all, is to make a JeeNode (or JNµ) start up with a capacitor powered from AC mains, using as low a current trickle as possible. But unless I can find a way to shut that RFM12B down very early on, it looks like a 1 mA or so trickle will be needed to overcome this initial power “hogging” behavior.

I’m not (yet?) willing to throw more hardware at the problem, but that would be one way to work around it: use an I/O pin and a MOSFET to power the RFM12B, after the voltage is high enough to be able to overcome this dip.

In the previous post, I managed to get a JeeNode started with what I though was a 10 µA trickle, but it now looks like I was off by two orders of magnitude in those tests. It’s easy to lose track of details while making changes!

Conclusion: an AC mains power supply with 1 mA trickle is an option, but I’m not ready to give up … yet!

How grounding works – part 2

In Hardware on Dec 7, 2011 at 00:01

After yesterday’s post, here are some more details about grounding do’s and dont’s …

First, let me reiterate that there is no such thing as a fixed “0 volt” level. Voltages are measured as “potential differences“. You can only have a voltage between points A and B – even if there is virtually no current flow.

Warning: from here on, I’m just going to invent an explanation for how ground works and how to deal with it. If I’m wrong, please correct me. The point is to try and get my intuition across – because IMO it’s not complicated.

The solution presented yesterday was to use a “star grounding” approach: all the big power consumers get their own power and ground wires to the power supply. As was explained there this prevents big currents from “raising the ground floor”, i.e. reducing the way ground level changes end up messing with low-power signals.

Here’s a delightfully simple and practical rule: tie all the big power consumers directly to the power supply, and do whatever you like with the rest. There’s still a risk of “ground loops” (which is a nightmare in audio circuits, because it can leads to audible hum), but it’s not nearly as important as getting the big currents under control.

So if ground levels can vary, how come this doesn’t lead to trouble when connecting multiple devices?

Well, the simple answer is: they could, but the trick is to avoid currents going through ground connections. Now, before all this gets too confusing, let me make the distinction more explicit with an image from Wikipedia:

Screen Shot 2011 11 25 at 00 46 12

The differences are quite subtle:

signal ground denotes the return path for low-power, eh… signals
chassis ground is the mechanical frame, if it is made of a conducting material
earth ground is that rod in the ground I mentioned before

During my recent scope experiments, I’ve been quite puzzled by all this. How do you prevent damage when you tie sensitive circuits together, all at different potentials, different power supplies, and different grounding points?

Observation #1: voltages don’t cause damage, it’s the resulting current that does.

So as long as a circuit is high-impedance, you don’t really have to worry about damage. Poking around with a scope probe (which is usually 1..10 MΩ) won’t be a problem (unless you exceed the maximum voltage rating).

Observation #2: electricity only flows when there is a return path.

This is a biggie. Imagine a heavy power supply with lots of voltage and current capability to cause lots of damage:

Power1

A power supply is normally galvanically isolated from AC mains. This means it has no connection to it and no current can flow. Tying the “–” side of the supply to the chassis and enclosure will not change this. Likewise, tying this “chassis ground” to “earth ground” will not cause any current to flow. So far, so good!

Let’s look at two such installations, and let’s assume the second one is actually quite sensitive – such as a scope:

Power2

Again, tying its “GND” probe line to both chassis and earth ground will – in itself – not cause current to flow.

So far so good. Now let’s look at the bigger picture – since both appliances are tied into the same AC mains:

JC s Doodles page 28

As shown in part 1, if there are large currents flowing through AC mains wiring, then there will be a voltage drop in the wires (red box), which means the different power inputs will start to “float” relative to each other.

Observation #3: the ground wire normally carries NO current!

This is the crucial bit which makes grounding sane. When there’s no current, there’s no voltage drop. In a 3-wire system, now common in most parts of the world, that ground wire is nice as reference and as fail-safe.

First the fail-safe: as you saw, it is common to tie all chassis and signal grounds to the “G” wire, which in turn is normally tied to earth ground somewhere in the basement (in one spot only). If there is ever a short between the other current-carrying (and dangerous) wires of AC mains and this “G” wire, then two things happen: 1) currents in the “L” (live) and “N” (neutral) wires no longer cancel, and 2) a current will start to flow through the “G” wire.

This is where the RCD or “RRCB” enters the picture. In modern house wiring setups, it kicks in the moment a current difference larger than 30 mA is detected between L and N. So what this does is shut down power as soon as 30 mA or so starts flowing through the “G” wire. An excellent safety device – it must have saved countless lives.

Observation #4: electricity takes the path of least resistance (or inductance in the case of HF).

So if the “G” wire normally carries no current and up to 30 mA during a fault, why is it as thick as “L” and “N”?

One reason that it’s an extra safety – if the RCD doesn’t trip, then the fuse will blow. But another reason is to keep the resistance of the “G” wire much lower than the resistance of say a probe’s “GND” tied to the “–” of the power supply. If there’s a fault current and it decides that it’s easier to go through the probe’s “GND” wire, then it could send a damaging spike through it (again, the scope is a very sensitive low-current device).

So the effect of that green-and-yellow “G” wire running through the house, is to create a splendid 0 V reference (when everything is operating properly) and to act as fail-safe if L or N are brought in contact with it.

G is not there to carry current, but to tie all isolated, i.e. floating, power supplies in all devices together!

If you review observation #2 in this light, then each appliance has its own isolated power supply and the current it produces always goes back “into it”, so to speak. To put it differently: each power supply takes care of its own electrons. The common ground connection merely “secures” one side of each supply to a safe reference point – and ties it firmly to all the conducting surfaces around us. The more surfaces we tie to “G”, the more we can be assured that faults will trip an RCD or a fuse – and leave us happily intact to tell stories like this and write weblog posts.

How grounding works

In Hardware on Dec 6, 2011 at 00:01

I’ve often wondered how “ground” works.

Let me explain: ground is of course the zero voltage reference level, which we implicitly think of when talking of a 3.3V or 5V signal, for example. You can only measure voltage between two points – it’s a relative concept.

But we all (well, I do, anyway) loosely talk about 0V and “ground” as if it’s an obvious thing. Not so, if you talk to electricians or engineers involved with power circuits.

First of all, there’s no such thing as a single ground potential. You can push a metal rod into the ground and think you’ve hit a solid reference but you might be surprised what two such metal rods pushed into the ground at some distance will do in a thunderstorm!

So why is grounding and ground level so tricky?

The problem is resistance. Every copper wire has some resistance. And where current flows in a resistance, you get a voltage drop (Ohm’s law, again – it’s everywhere!).

Let’s take a simple circuit, and let’s stay in the domain of JeeNodes and Physical Computing:

JC s Doodles page 26

A 3.3V power supply feeds a JeeNode, which in turn controls a lamp. In normal low-power cases, things behave exactly as you’d expect. Ground is tied to the power supply, but both the JeeNode and the lamp are also connected on one side to ground, i.e. 0V.

I’ll redraw this to make the wiring resistance explicit:

JC s Doodles page 26 1

Those resistance values will be very small, let’s say about 10 milliohm, i.e. one hundredth of one ohm.

Now imagine that you’ve got a super-powerful 33 Watt lamp instead, which draws 10 A. And assume the power supply is a big fat one which can supply those currents, and that the Relay Plug is also a beefy souped-up version.

With the lamp off, and the JeeNode drawing about 10 mA, the voltage drop over R1 and R2 will be around 0.00001 V (10 µV). Virtually undetectable.

Let’s turn the lamp on. Now a 10 A current will flow through R1, R2, R3, and R4. That means the voltage drop over each one will be 0.1V – so the JeeNode, for example, will be running at 3.1V now!

But that’s not all. Since the “ground” level of the JeeNode, i.e. the wire between R2 and R4 is now floating 0.1V above the power supply ground, everything the JeeNode does starts to float. The signal to the relay will switch between 0.1 and 3.2V – it’ll never be 0V (to ground) in fact.

For a relay plug, that doesn’t really matter – it’ll still switch on and off as intended. But for things like analog signals and ADC/DAC conversions, this really messes things up. If you don’t plan for it, all your analogRead() measurements could easily be 0.2V off, that’s a 6% error.

Now imagine driving the lamp with a big fat MOSFET instead and using PWM. It’s not hard to see that the JeeNode is almost literally going to be in a roller-coaster ride as the switching ends up affecting everything!

Remember seeing the lights dim briefly when a big heater is turned on? That’s due to cable resistance (and inductance) and floating grounds, in essence. So forget about an absolute ground – there’s no such thing.

Does that mean we can’t measure properly? Of course we can. Because there are some simple ways to deal with these resistance effects. The first obvious trick is to use fat wires for stuff that draws a lot of current. This lowers the resistance, and hence the voltage drop. Reduced voltage drop is why cables are sometimes much thicker than strictly needed w.r.t. current-carrying capacity.

But that doesn’t mean you need to waste copper all over the place. Have a look at this design:

JC s Doodles page 26 3

Same circuit, but the JeeNode’s “ground level” is back in the microvolt range, even though it’s still switching 10 A. That’s because the current drops caused by the lamp currents no longer affect the JeeNode. R1 and R2 carry just 10 mA for the JeeNode again, even when the lamp is on: thin wires from power supply to JeeNode are ok.

Tomorrow, I’ll try to apply some common-sense to AC mains and multi-device grounding…

Types of memory for an ATmega

In AVR, Hardware on Dec 5, 2011 at 00:01

There are a number of types of memory in (and for) the ATmega.

Flash memory is the place where compiled sketches end up. This memory has an important property: it retains its contents even when power is off, yet it’s modifiable (even by the ATmega itself – that’s how the boot loader works). An ATmega328 has 32 KByte of flash memory, enough to store fairly substantial sketches. When an ATmega is powered up, it starts executing the code stored in its flash memory.

RAM memory is the work memory where variables, buffers, strings, and other bits of data reside which get used and changed by the running sketch. The contents of RAM memory is lost when power is turned off, but access to the data kept here is extremely efficient. RAM is limited to 2 Kbyte on an ATmega328, and often a scarce resource, especially since all strings also need to stored there (these get copied from flash on startup).

EEPROM memory is the “configurable” memory available to a sketch. It’s very similar to flash, but not used for code – only data can be stored in EEPROM, and you need to call specific routine to read and write data (i.e. copy them to/from RAM). EEPROM memory retains its contents, which makes it very suitable for configuration settings, encryption keys, i.e. data which needs to be retained. There are 2 KByte of EEPROM in an ATmega328.

That’s it as far as built-in memory goes. The are many other types of memory (some far larger than the above), but they all have to be connected to the ATmega as “external memory” through its I/O pins. External memory is slower (sometimes dramatically so), and requires more code to work with.

There are three common ways to use external memory: I2C, SPI, and parallel (links / images from Wikipedia).

I2C memory uses the “I2C bus” protocol to talk to external hardware. The I2C bus is also known as the “Two Wire” bus, because it requires only 2 I/O lines (plus ground and power, i.e. 4 wires). The I2C bus is several orders of magnitude slower than the above three types of memory, but one advantage is that it is very low cost, and that I2C-capable chips are small and available in many shapes and sizes. The main types of I2C memory chips are SRAM (static RAM, same as in the ATmega) and EEPROM (also same as in the ATmega). The most common sizes are in the order of kilobytes, or dozens of kilobytes. Adding I2C memory such as the Memory Plug for JeeNodes, is cheap and simple. It’s also relatively slow – requiring in the order of a few milliseconds to write out a page of 32 bytes.

350px I2C svg

SPI memory uses the “SPI bus”, which needs 3 I/O pins shared among all SPI devices, plus 1 I/O “chip select” pin per device. It can be one or two orders of magnitude faster than I2C. The choice of SPI memory chips is more limited than I2C, but the memory chips are usually larger (such as the 2 Mbyte chip used in a JeeLink). The advantage of SPI over I2C is speed, but it’s still a serially-connected solution, and therefore still an order of magnitude slower than the ATmega’s built-in memory.

350px SPI single slave svg

Parallel memory uses many I/O pins together to get address and data information exchanged at a higher speed. This option is not really practical with an ATmega328, which has a limited number of I/O pins. It’s the way “real CPU’s” work, connecting the processor with external memory using over a hundred I/O pins.

One more memory type is worth mentioning here, because it’s easy to interface with an ATmega:

SD and µSD cards are a form of external flash memory, used widely in digital camera’s, for example. They offer by far the largest memory sizes (2 GByte and up) for a very low cost. The reason these cards can be used, is that the SD standard supports an SPI fallback mode, which means that they can be connected in the same way as other SPI memory chip solutions. Two caveats: 1) some initial handshaking will be needed to put an SD card into SPI mode, and 2) SD and µSD cards tend to be slow in SPI mode, i.e. nothing like SPI-capable memory chips.

In case you think that cheap and ample memory storage has always been so convenient: here are some flashes from the past of funky technologies used decades ago – check out mercury, drums, tubes, cores, and bubbles!

Update – see also this weblog post about RAM usage.

Generating sine waves with DDS

In AVR, Hardware on Dec 4, 2011 at 00:01

This is a topic I’ve covered before, in a post of about a year ago, but given the recent post about a sine wave generator, and yet another opportunity to learn and show the new scope in action, here goes…

The first step towards Direct Digital Synthesis (DDS), is to generate a rapidly-adjusted analog signal through a Digital-to-Analog Converter (DAC). One way to do so is to use a resistor ladder network, tied to a number of digital output pins. The idea is that all these pins are either 0 or 1 using fixed voltage levels, so with the proper resistors, you get a signal where bit N has the proper weight in the final signal to represent the voltage 2^N.

With 8 output bits, you get an 8-bit DAC which can output voltages 0 .. 3.3V in 256 steps, i.e. ≈ 13 mV each.

The next step is to approximate a sine wave by rapidly adjusting the output bits to the values of a sine wave. This toneGen sketch from the 2010 weblog post does precisely that:

This lets us generate an decent sine wave by stepping voltages in the proper sequence, looping forever:

SCR31

The trouble is the “glitching” and the step-wise behavior of the signal:

SCR32

This last image shows a small portion of the signal near zero, greatly magnified – and it’s quite a mess!

Fortunately, this is usually very easy to fix with a low-pass filter (even just a single R-C filter), since these artifacts are at a much higher frequency than the generated sine wave itself. But let’s not go into such details for now.

The AD9851 chip used in the Sine Wave Generator works the same way, but it has one more clever trick up its sleeve, which lets it generate arbitrary frequencies using a single fixed crystal-based master clock.

Let’s start from a 1 MHz clock, and use a 1000-element lookup table for the sine wave. Then every microsecond, a new value is looked up, and after 1000 lookups we can start over. The result would be a 1000Hz sine wave.

Now suppose we want a 500 Hz sine wave, driven by the same 1 MHz clock source: we can simply re-use the same table entry twice, before moving on to the next. Likewise, for a 1 Hz sine wave, we’d re-use the same table entries 1000 times, before moving on to the next table entry.

How about 300 Hz? Ah, yes, that’s a bit tricky. We’d need to re-use the same table entry 3 1/3rd times, which is not really meaningful. But what we can do, is represent the step time as a fractional value, i.e. 0.3. The 1st “step” is 0.3, the 2nd 0.6, the 3rd 0.9, the 4th 1.2, etc. The fractional part is called the “phase”, BTW.

And now the big trick: ignore the fractional part while deciding which table entry to use!

This causes the table entries to be used in sequence, but possibly with a slight jitter as the stepping progresses in such a way that the full table will be cycled through exactly fast enough to produce the desired frequency.

So 1 Hz output is produced with a 0.001 step, and 500 Hz is a 0.500 step. I.e. frequency = 1000 x step.

The same mechanism can also be used to generate frequencies higher than the 1 KHz you get when stepping through each of the 1000 table entries with a 1 µs step rate. All you need to do is allow the fractional step rate to be larger than 1. Stepping through the table with rate 100.000 (i.e. skipping the next 99 entries each time) will generate a 100 KHz sine wave, albeit with only 10 data points per wave. So its amplitude changes will not be as fine-grained, but its frequency will be exact. Again, same formula: frequency = 1000 x step – easy!

This is the basis on which a DDS chip such as the AD9851 can adjust its frequency output. It’s based on very fast hardware with a very fast DAC: the input clock can be up to 30 MHz, and it even has a built-in 6x clock multiplier, so the “sine wave table stepping” can be based on a 180 MHz clock, which is equivalent to a 5.56 ns step time!

For completeness: an Arbitrary Waveform Generator (AWG) works similar to a DDS in that it also synthesizes a wave by running samples through an DAC from a table, but now the table may contain anything, not just a pure sine wave. The entries in the table describe one full wave. In this case, stepping is not possible (neither fractional nor skipping) because then you’d no longer be creating the proper waveform. Instead, an AWG really has to accurately control its step time from table entry to table entry to produce the desired frequency. This is more complicated – also because the wave table is RAM, not just a fixed ROM with sine wave coefficients.

So much for DDS and AWG … onwards!

Same RFM12B’s, but flatter

In Hardware on Dec 3, 2011 at 00:01

This is to announce that from now on JeeNodes will be fitted with a different type of RFM12B wireless module:

DSC 2681

Previous module on the left, new module on the right.

The difference? It’s just a bit flatter, that’s all. As you can see, it’s the same board – with a low-profile crystal:

DSC 2682

For most purposes, the change is irrelevant. The module is electrically identical: same pinout & commands, same RF12 library, etc. But in some scenarios, the lower profile might be useful, i.e. when the MPU is also SMD.

This is also why the flat model is going to used with the new JeeNode Micros.

New oscilloscope

In Hardware on Dec 2, 2011 at 00:01

Get ready for more oscilloscope screen shots after yesterday’s sneak preview…

These come from a Hameg HMO0722, which is techno-babble for “70 MHz bandwidth, 2-channel oscilloscope”:

SCR02

It’s the “little” brother of a series of 8 scopes, covering 70..200 MHz bandwidths in 2- and 4-channel versions.

There are three aspects of this series which make it stand out, IMO:

The display: full VGA, 640×480, with lots of room for graph detail and informational text
The software: this thing is packed with features, such as the above one-button “Quick View” mode
The hardware: small, quiet, fast-sampling, sensitive, deep memory, and an optional logic analyzer

I’m not going to do a full review here – I wouldn’t even know how to do that, but more importantly, this isn’t really a story about a specific scope, but more an impression of the sort of capabilities you can find in a modern digital oscilloscope nowadays. FWIW, the HMO series costs from ≈ €1300 .. €3400 – depending in part on what options are included (the logic analyzer adds €345 .. €690, for example) – pretty hefty price tags!

The above screen shot was made via a USB stick, which is why it can be shown here in jaw-dropping resolution. The automatic measurements shown above are extremely convenient, with lots of attention to detail and precise tags / markers. Note that this mode is “live”, i.e. it tracks the signal while the scope is running.

The sampling rate is the maximum 2 GSa/sec in this case (a 1 KHz signal from one of the test pins). That means you can stop the scope and zoom in to see considerable detail: 2 samples per ns, 100 ns/div, 12 div/screen is 2400 ADC samples, just for this single screen. When only one channel is active, the scope cleverly re-uses the spare channel’s memory to store 2 million samples (looks like it’s actually a bit more).

Here is the zoom function, pushed to the limit (the top is an overview pane, the bottom shows the details):

SCR04

There are 4 sample points per division (the rest is merely interpolated), but as you can see when moving the horizontal trigger time, it really has one sample every 500 picoseconds. Note the rise time, which seems to be about 10 ns for this 70 MHz model. Zooming back out gives me slightly more than 1 ms, so there really are over 2 million samples available to look at: one “up” and two “down” flanks of the 1 KHz square wave.

There’s a catch, however. Such extreme acquisition rates would require phenomenal amounts of processing power if you wanted to capture everything and display up to 2000 waveforms per second, as this model claims. Usually, this scope will not go fill its memory to the limit, but trade refresh speed for sampling depth (it’s all configurable). This reduces the “blind time” when the scope isn’t capturing but busy processing and presenting the information.

So much for raw power. Speaking of power: this scope draws 22 Watt when in use, and 0.4 Watt in standby.

Here’s a more meaningful measurement – the 3.3V supply ripple from an AA Board driving a JeeNode:

SCR09

(No, I didn’t smash up the screen – the above image was doctored to remove some empty space.)

The other feature I want to highlight here is the logic analyzer option. Since I don’t have the logic probe yet, the only way to capture logic signals is via the analog scope channels – which luckily is supported just fine:

SCR66

You’re looking at a short burst of SPI commands sent to an RFM12B. This is just SCK and MOSI, since I have only 2 analog probes to read this in with. The rest of the buffer is empty, since the bursts are sent only every 3 seconds.

Here again, the settings were adjusted to store as much as possible in sample memory. I found out by trial and error that the 2 ms/div setting was the maximum usable to reliably decode this 1 MHz SPI stream. The sampling rate is shown as 250 kSa/sec, which seems odds (4 µs resolution isn’t possibly enough to detect flanks in a 1 MHz signal). Maybe the hardware is playing tricks and storing 8 bits per byte? It’d explain the “20 MSa” value.

Then again, the top pane only displays 24 ms, and it appears to be the entire dataset. Which is 24,000 bits of decoded data @ 1 MHz, i.e. a couple of thousand bytes from the SPI stream. Enough for most purposes, especially since you can trigger on a specific serial bit pattern and then start capturing there (another add-on).

I’m not too concerned with ultra-deep logical analyzer storage. It’s easy to toggle an I/O pin in software where it gets interesting, and then trigger on that. There’s also a “B trigger” feature, as a way to cascade triggers.

Other supported protocols: UART, I2C, and parallel (requires the logic probe to acquire more signals).

This is not my own scope, BTW. I recently ordered another one from this series, but was given this unit on loan by Rohde & Schwarz (tops!) – it turns out that the scope is in short supply and has a delivery time of many weeks.

So much for gushing over an oscilloscope – geek stuff!

RF12 power optimization

In AVR, Hardware, Software on Dec 1, 2011 at 00:01

Here’s a small evolutionary change to the RF12 driver, to squeeze one more drop of power consumption out of it.

This is the code for which I’m trying to optimize power consumption:

Screen Shot 2011 11 19 at 11 31 16

The Sleepy::loseSomeTime() call is the big power saver. It puts the ATmega into a total power down mode, except for the watchdog timer, which is used to get it back out of this comatose state. So we’re sleeping for 10 seconds.

Around it are the rf_sleep() calls needed to put the RFM12B into low-power mode as well.

And lastly, the rf12_sendWait(3) call does something pretty nifty: it puts the ATmega into full power down mode between each byte sent to the RFM12B while transmitting. This requires a non-standard fuse setting in the ATmega – it only works with a ceramic resonator or the internal clock oscillator, not with a crystal: wake up out of power down within a few clock cycles.

The most efficient mode turns out to be with the ATmega running at 8 MHz off the internal RC oscillator (which starts up really fast). With default Arduino’ish settings, you have to use mode 2, i.e. a less extreme power down mode so it can wake up fast enough.

Here’s one complete transmission of a 8-byte payload (scope details to follow tomorrow):

SCR33

Each vertical division is 5 mA current draw (the voltage drop across a 10 Ω series resistor). You can see the ATmega turn on, drawing 5 .. 9 mA, and the RFM12B in transmit mode consuming about 23 mA.

The red line is pretty advanced stuff: it integrates the current over time – which is equivalent to the amount of charge consumed. At the end of the trace, this leads to a result of 7.22 microcoulombs per packet sent. One way to interpret this (thanks, Jörg – see comments), is that you could send one packet per second on an average current of less than 8 µA (hm, I think that should be 80 µA).

The “blips” are when the ATmega wakes up and feeds another byte to the RFM12B. In detail (edited image):

SCR16

These blips take about 32 µS @ 5 mA, which is what it takes to communicate with the RFM12B on the SPI bus at 2 MHz. The reason is that the RFM12B supports a 2.5 MHz maximum SPI rate (it turns out that this limitation only applies for data read from the RFM12B module).

The blips repeat 18 times, every 162 µS. Why 18? Well, an RF12 data transmission looks as follows:

RF12 packets

That’s 9 bytes of overhead, plus the 8 payload bytes, plus a trailing interrupt to shut down the RFM12B once the transmission is over.

For completeness – in case you think I can’t count blips: there’s one more activity peak at the start. That’s the call to rf12_canSend(), to check that the RFM12B is ready to start a transmission (which then takes 250 µs to start).

This is probably the limit of what you can push out of power savings with an ATmega (or ATtiny) and an RFM12B. Well, apart from: 1) sending less data, 2) increasing the transmit data rate, or 3) decreasing transmitter power.

When re-using the same code with “rf12_sendWait(2)” and running with normal fuse settings at 16 MHz using a ceramic resonator, it uses only slightly more charge – 7.70 µC, i.e. 7% more. So while this was a nice exercise, it’s not really a major improvement.

All in the name of nanowatt ~~yak~~ power s(h)aving…

LowPower, AC Mains

All power-up puzzles solved?

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

As reported in a recent post, there were startup problems when powered from a 0.4 mA trickle-fed capacitor.

In short: it didn’t work…

The problem with a trickle-feed supply is not that the voltage level will ramp up very slowly (the brown-out detector and power-on reset circuitry should be able to handle that). The problem is that the circuit needs to draw less current than the trickle at all times – because otherwise the capacitor won’t ever reach its full charge level.

One problem was the MCP1702 voltage regulator, which has a large current draw before the input voltage reaches 3.3V where it can start regulating. So I removed the regulator, and created a setup which limits the capacitor charge to around 3.8V – thinking that without the regulator, the ATmega would at some point start up and immediately put itself and the RFM12B into sleep mode, letting the supply voltage rise a bit further.

Strangely enough, it didn’t work at all. I kept seeing a start-up spike of several milliamps. Here’s the current consumption on power-up (the scope shows the voltage over a 10 Ω resistor in series with the power supply):

DSC 2796

That’s over 10 milliamps, for well over a second – Huh?

And then it finally dawned on me: the boot loader! The ATmega is set to look for an upload right after power-up or reset, which is what the boot loader is all about. Guess what it does: look for incoming commands on the serial port for roughly one second, before passing control to the main sketch stored in the ATmega.

Clearly, the boot loader is running at full power. Whoops!

So the first conclusion is that in this context, we can’t use a boot loader. The solution is to change the high fuse from 0xDA to 0xDB with an ISP programmer. It’ll make it harder to upload code, but there’s no other way.

Great. I thought that would solve the problem. But that’s not all. The default fuse settings also cause the ATmega to wait for 65 milliseconds on power-up. This is for crystals to get up to a stable oscillation. Unfortunately, that means the ATmega is spending 65 ms in a higher-power mode on startup.

So I changed the fuses to use the 1K / 14 CK startup mode (power-up / reset). The way I read this, it means that the ATmega will power-up after 1024 + 14 clock cycles once it comes out of hardware reset, and after 1024 clock cycles when coming out of sleep mode.

Furthermore, the divide-by-8 prescaler fuse bit needs to be set, because the ATmega will power up with a 2.7 V supply voltage (the BOD level). At that level, running at 16 MHz is way out of spec, and no doubt very unreliable.

So all in all, the following fuse settings are required:

BOD level = 2.7V, i.e. don’t power up before the supply has reached 2.7V
enable ÷ 8 pre-scaler on startup (can be disabled in software later)
make the clock start up in low-power 1K / 14 CK mode
disable the boot loader, jump immediately to the main sketch

Here is the power consumption with these changes (note the 40x X scale and 5x Y scale differences):

DSC 2798

There’s still a 0.65 mA current draw during start-up. Unfortunately, this one is nasty: it’s caused by the RFM12B module, which powers up in this mode. Best thing I can do is put the RFM12B to sleep as soon as possible, but that can’t happen before the ATmega has started up fully. So basically, there’s a 0.65 mA current draw which we can’t get rid of (other than adding extra circuitry to control the RFM12B’s power – but see also below).

What this means, is that I’ll have to settle for a 1 mA trickle feed supply for now. It’s enough to keep charging the buffer cap, and this way things ought to finally get past that power-up hurdle.

And guess what? It works!

DSC 2801

The cap charges until the supply reaches 2.7V, then the ATmega snaps out of reset and puts the RFM12B to sleep.

The interesting thing now, is to check whether that MCP1702 current anomaly on startup really was a problem. So I switched back to a standard JeeNode, and tried it with the above fuse settings.

Hey, it still works! So we could go back to a 12V zener charging a 100 µF cap. This puzzle has come full circle!

More good news – it looks like there is a sneaky way to avoid the 0.65 mA power-up current draw of the RFM12B: make the ATmega start up at 1.8V instead of 2.7V – the RFM12B isn’t pulling much current at that level. So if we turn it off right away then the RFM12B will be put to sleep before it gets a chance to draw too much current.

Does this work? You bet. Here is by far the craziest low-power setup I’ve ever been able to get going:

DSC 2803

That’s a 100 µF cap charged using a 10 µA trickle. You can see the 1.8V bump where the ATmega kicks in, inits the RFM12B, puts it to sleep, and later on sends 2 packets. This is a standard JeeNode, but with special fuse settings:

internal 8 MHz RC oscillator, fastest startup
don’t enter the boot loader
brown-out level is set to 1.8V

The fuse settings are: extended = 0x06, high = 0xDB, low = 0xC2.

Fascinating how everything affects everything, eh?

Update – ~~I’m having some doubts about this last result. Will need to triple-check my calculations on this one.~~ That last report is most definitely incorrect, there’s no way to get the RFM12B to start up with a 10 µA trickle – it starts up with the crystal oscillator active, which means that it’ll draw at least 0.6 mA until put to sleep.

Who needs MOSFETs?

In Hardware on Nov 29, 2011 at 00:01

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

Much simpler and cheaper!

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

DSC 2795

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

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

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

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

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

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

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

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

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

Sine Wave Generator

In Hardware on Nov 28, 2011 at 00:01

Frequency generators used to be very expensive. No more (for basic uses). Nowadays, a single chip does all the hard work. It runs off a fixed stable crystal oscillator, and it generates a sine wave of any frequency you want.

Here’s one I purchased off eBay recently – for under €40, including shipping:

DSC 2780

Just hook it up to a 12V power brick and it’ll generate the sine wave on its BNC output connector. The push buttons let you move to a specific digit and increment or decrement that position. I haven’t figured out what the rightmost button does (the labels are in Chinese).

Here’s a 10 MHz signal, on the Rigol DS5062CA scope:

DSC 2779

And here’s a 50 MHz sine wave, the maximum supported by the frequency generator:

DSC 2778

Note that the amplitude is a bit lower. This is a 60 MHz scope, which means it’ll drop off 3 dB at 60 MHz. Decibels are a logarithmic scale, and “6 dB” is a funny way of saying “half” (so 3 dB is 71%). So in effect, the scope will still show the 50 MHz sine wave nicely, but it won’t be accurate in amplitude.

Scope bandwidth is a subtle thing. Once you know your scope has bandwidth X, you might be tempted to think that all is well up to that value, for any signal you look at. It doesn’t work that way, however (and far be it from scope vendors to tell you about that) – here’s a wake-up call: an ideal square wave requires infinite bandwidth to display accurately! The reason is that scopes aren’t inherently limited by bandwidth, but by how fast their input circuits can track an input signal (capacitance stores charge, and that hampers the way signals move around). So another way to look at how fast a scope can track a changing signal is to look at its rise time – which is usually also included in the specs. A perfect square wave has zero rise time, which no scope can match.

Before I veer too far off topic, let me just mention a rule of thumb, which says that if you want to accurately view square waves (such as logic signals!), then you need a scope with a bandwidth which is 10 times as high as the frequency of the signal you want to examine. To accurately view a 1 MHz logic signal, you need a 10 MHz scope – to display a 20 MHz square wave properly, you need a 200 MHz scope (this is unrelated to the “Nyquist frequency” BTW, which says that you need to sample with at least twice the rate of the signal to pick it up).

So this Rigol DS5062CA scope is suitable for sine waves up to 60 MHz if you can live with some amplitude loss, and it will show square waves fairly accurately up to 6 MHz, i.e. a 160 nS cycle time. It will sample up to 1 Gs/s, i.e. once every nanosecond (!), and it’ll display results down to about 5 ns/div, so the above samples you see are a bit deceptive: there are 320 pixels across, i.e. about 25 pixels per division, but only 5 measurements per division.

What this means is that the 50 MHz sine wave you’re seeing above is looking very nice, but mostly interpolated.

Fortunately, digital storage scopes usually have a couple more tricks up their sleeve. This one is more accurate:

DSC 2781

I’ve turned off the grid and enabled “Analog” mode, which is a way to emulate the CRT beam of an analog scope – it only lights up where actual measurements have been made, and it’ll keep a few previous sweeps on the screen. Note that it’s slightly early w.r.t. triggering, which was set to exactly 0V. This is as good as it gets with this scope.

Anyone interested in “Direct Digital Synthesis”, i.e. how this nifty sine wave generator works?

LowPower, AC Mains

Ultra low power supply

In Hardware on Nov 27, 2011 at 00:01

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

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

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

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

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

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

Screen Shot 2011 11 17 at 16 46 14

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

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

JC s Doodles page 24

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

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

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

Transformers – part 2

In Hardware on Nov 21, 2011 at 00:01

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

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

Transformers in series

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

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

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

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

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

DSC 2797

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

Transformers!

In Hardware on Nov 20, 2011 at 00:01

(No, not comic strips or movies…)

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

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

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

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

JC s Doodles page 25

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

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

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

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

Zeners – success!

In Hardware on Nov 19, 2011 at 00:01

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

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

DSC 2783

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

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

Screen Shot 2011 11 17 at 03 22 27

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

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

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

DSC 2784

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

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

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

DSC 2786

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

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

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

Zeners?

In Hardware on Nov 18, 2011 at 00:01

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

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

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

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

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

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

Zener knee

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

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

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

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

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

DSC 2777

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

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

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

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

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

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

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

AC Mains measurements

In Hardware on Nov 17, 2011 at 00:01

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

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

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

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

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

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

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

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

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

DSC 2776

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

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

DSC 2773

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

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

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

Screen Shot 2011 11 15 at 23 05 28

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

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

DSC 2775

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

Onwards! (with caution)

Wait… make that 470 µF

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

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

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

DSC 2752

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

Screen Shot 2011 11 03 at 01 09 37

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

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

Let’s zoom in a bit further…

DSC 2753

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

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

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

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

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

Running off a 6800 µF cap

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

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

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

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

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

JC s Doodles page 21

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

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

DSC 2745

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

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

DSC 2746

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

Screen Shot 2011 11 02 at 17 30 23

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

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

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

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

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

Take a look at this scope snapshot:

DSC 2747

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

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

Neat huh?

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

JC s Doodles page 21

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

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

DSC 2750

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

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

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

▶ View 21 Comments

A “beefy” power supply

In Hardware on Nov 14, 2011 at 00:01

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

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

DSC 2743

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

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

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

DSC 2736

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

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

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

DSC 2737

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

DSC 2738

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

DSC 2739

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

DSC 2741

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

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

DSC 2742

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

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

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

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

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

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

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

Capacitive transformer-less supply

In Hardware on Nov 13, 2011 at 00:01

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

This is an improved version, using a capacitor:

JC s Doodles page 20

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

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

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

DSC 2724

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

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

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

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

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

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

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

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

Meet the Slave Plug

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

While fooling around with the ATtiny85 for the first AC current measurement tests, I found that ATtiny85 to be a pretty neat little chip in and by itself.

So why not create a plug for it, eh? Here’s the new Slave Plug:

DSC 2707

It’s all through-hole, so that it’s easy to assemble and easy to replace the ATtiny85 (or other compatible unit).

There are just enough pins to act as a (daisy-chainable) I2C slave and to drive a 6-pin header with 3..4 I/O pins:

Screen Shot 2011 11 08 at 23 14 11

With some care, that header can be made compatible with JeeNode ports, which means that this plug could even be used to act as host for another plug. Sort of an offloaded task for the “main” JeeNode. Or perhaps stand-alone, just to drive that single plug. Note also that the ATtiny85 supports differential ADC and an optional 20x gain stage, so that full scale voltages down to ≈ 55 mV can be measured (using the internal 1.1V bandgap as reference).

Here’s the schematic:

Screen Shot 2011 11 08 at 23 12 50

Pin 1 of the side header can be tied to either PWR (to create a port) or to the ATtiny’s RESET (SJ1).

And the port’s IRQ pin can optionally be connected to the ATtiny’s RESET pin via a solder jumper (SJ2).

Using a fuse setting, the ATtiny’s RESET pin can be turned into an I/O pin, but this means you’ll need a high-voltage programmer to re-flash the chip and lose the normal ISP programmability.

I’ll add it to the shop shortly, along with the other new boards.

It’s called v2, because there has been an (SMD) Slave Plug before, but that never made it into the real world.

Pulsing the LED strip

In Hardware on Nov 11, 2011 at 00:01

With the new LED Node hookup there are some small color changes across the strip. Not a show stopper, but something I’d like to reduce as much as possible anyway, of course. Get ready for more oscilloscope shots…

I hooked up a flexible 5 m RGB LED strip (got plenty of those here), and instead of extending scope probes, decided to simply let the strip dangle on the table and bring the end back near the scope. Why make things any harder, eh?

Here’s is the blue LED pulse, which is the shortest one when trying to produce warm colors. Channel 1 (yellow) is hooked up to the power feed side of the LED strip and channel 2 (blue) to the end:

DSC 2759

Pulses are negative, because LEDs are connected between this signal and +12V. So low means on. Pretty nasty spikes, as you can see. Note also that the end of the strip doesn’t quite pull the blue LEDs down to zero.

Zooming out to see the bigger picture, you can see that the supply voltage (from my lab supply in this case) is also fluctuating due to what is probably the green LEDs being switched:

DSC 2762

Hm, I seem to be off with the voltages for some very strange reason. The supply is 12V, so I was expecting to see twice the amplitudes reported by the scope. After some pondering, it became obvious: there’s noting which will pull the blue LED signal to 12V, since there are three LED voltage drops! So I added a 100 kΩ resistor to +12V:

DSC 2764

Ignore the very slow rise times – a 100 kΩ resistor is a very weak pull-up. But it does explain the voltages seen.

What it means is that those “nasty spikes” seen before are probably not as serious as they seem. This is simply the +12V voltage rail – the odd thing is that the LEDs are placing the signal lines into a mid-level voltage range while nothing is connected (i.e. the MOSFET is open).

Anyway. There’s a small hickup as the MOSFET is brought into conductance, and there’s a large spike when it switches off again (without 100 kΩ). The average current draw from the power supply is 1.66 A in this setup.

Let’s zoom in into that switch-off spike at the end:

DSC 2755

We’re looking at 100 ns/div, i.e. a signal “ringing” at ≈ 10 MHz. This scope has a 60 MHz bandwidth, so I’m not 100% convinced that these results are in the LED Node + strip. The bottom line (a bit hard to see that it’s green) is a math operation, i.e. the difference between channel 1 and 2 – a 6V difference between both ends of the strip!

Then I connected +12V to both ends of the LED strip. The color change was dramatic. The reddish tint at the far end was gone (of course), and I couldn’t really see a reddish tint in the middle of the strip either.

More surprisingly, the current draw jumped to 1.82 A, i.e. some 10% more. It looks like the RGB strip is not dimensioned properly for carrying these types of currents, i.e. for driving a full 5 meter strip in one go.

Here are the two pulse tails with +12V on both ends:

DSC 2758

An even bigger difference, but about half the ringing frequency. Does this mean half the inductance?

It’s extremely difficult to capture the color effects in a photograph. These effects are far less visible in real life, let alone across the room (which has shades for which we seem to correct without any effort). But here goes:

DSC 2769

That’s, from top to bottom: the middle, end, and start of the strip. The +12V line is tied to both ends.

The colors are actually quite pleasant – but I’d still like to tweak it further. One change which comes to mind is to reduce the PWM frequency to perhaps 250 Hz, preferably in Phase Correct PWM mode, which would have the benefit that the blue and green LEDs don’t get switched on and off at the same time (unless their pulse widths are identical, which is unlikely for white tints).

All these scope traces makes one wonder how much RF noise other dimmed LED strips generate – I wouldn’t be surprised if that were the case even in commercial ones.

Onwards!

Pins, damned pins, and JeeNodes

In AVR, Hardware, Software on Nov 10, 2011 at 00:01

(to rephrase Mark Twain …)

There is confusion in the ATmega / Arduino / JeeNode world, as brought to my attention again in the forum.

It all depends on your perspective, really:

if you want to connect to pins on the ATmega chip, then you’re after “pin 6”, “pin 17”, and “pin 26”
if you want to understand the ATmega data sheet, then you’re after names like “PD4”, “MOSI”, and “PC3”
if you want to follow Arduino sketches, then you want “digital 4”, “digital 12 11″, and “analog 3”
if you want to plug into JeeNode ports, then you’d prefer “DIO1”, “MOSI on SPI/ISP”, and “AIO4”

They are all the same thing.

Well, sort of. If you’re looking at an SMD chip, the pin numbers change, and if you’re using an Arduino Mega board, some names differ as well. They might also be different if you were to look at older versions of the JeeNode. In short: it’s messy because people come from different perspectives, and it’s unavoidable. There is no relation between “pin 4”, “PD4”, “digital 4”, and “DIO4” – other than that they all mention the digit 4 …

For that same reason, diagrams are not always obvious. For example, this one is nicely informative:

Arduino To Atmega8 Pins

But it doesn’t help one bit when hooking up a JeeNode.

Likewise, this one doesn’t really help if you’re after the pins on the ATmega328 chip or Arduino pin #’s:

Screen Shot 2011 11 08 at 13 02 04

Then there’s this overview, but it’s incomplete – only the DIO and AIO pins are mapped to the rest, in a table:

JN colors

This one from TankSlappa uses the DIP chip as starting point (and creates new abbreviations for DIO1, etc, alas):

Affectation GPIO JeeNode

Each of these diagrams conveys useful information. But none of them seem to be sufficient on their own.

Can we do better? I’ll be happy to take suggestions and make a new – c o n v e n i e n t – one-pager.

Fixing the Arduino’s PWM

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

The LED Node presented a few days ago, with the software to drive it, has exposed a nasty little problem…

The light has a slight periodic flicker.

Not good, in fact this gets pretty irritating fairly quickly. But how can this be? Each of the RGB colors is dimmed using the ATmega’s hardware PWM, after all – and well above the 50 Hz rate which our eyes could detect!

Luckily, I recently borrowed a oscilloscope from a friend which allowed me investigate this further. This is a Rigol DS5062CA, a predecessor of the popular DS1052E.

So let’s dive in, shall we?

DSC 2727

Channel 1 is tied to the PWM output driving the MOSFET for the green LEDs, and likewise channel 2 is for blue. There is little point in connecting to the PWM for the red LEDs, because these were driven 100%, i.e. not pulsed. The output color is sort-of-warm-white for the PWM ratios used for this test.

The first surprise was the PWM cycle frequency, which turns out to differ for these two PWM channels. The blue LED’s PWM pulse cycles at twice the rate of the green LED’s PWM (shown as yellow trace).

Ah, but wait… it’s not an exact multiple!

This is very easy to see while the scope is auto-triggering, because no matter how I set it up, I can only get one of the channels to stabilize. The other one always keeps moving, meaning that its phase is constantly changing.

The scope has some measurement options, and as you can see the PWM frequencies are not exact multiples (actually, this readout was a bit erratic – sometimes the frequency did get reported as exact multiple).

So what’s happening, is that there is sort of a Moiré effect between the different LED colors, and the difference is small enough that it manifests itself as a slight but very annoying flickering of 1 or 2 Hz, roughly.

I’ve been using analogWrite() to set these PWM values, but it now looks like I’ll have to change the setup and configure the timers and PWM outputs myself. Surely there’s a way to make all the timers count at the same rate?

Here’s another check I did:

DSC 2729

In this snapshot, channel 1 is the same as before, i.e. the PWM output for the green LEDs, while channel 2 is the power supply voltage (AC-coupled, i.e. only showing the fluctuations). You can see how the green LEDs pull the 12V down when turned on, with the blue LEDs presumably pulling it down further twice as often.

Again, the scope’s measurement capabilities come in handy to see the scale of these variations. Nothing extreme really, although I might add a fat capacitor to try and dampen them. I suspect that the combination of the out-of-sync PWMs and these slight power level fluctuations are what’s causing the visible flicker.

As you can see, a Digital Storage Oscilloscope (DSO) – even a basic one! – can be a fantastic diagnostic tool.

There is one more issue with these RGB LED strips:

DSC 2728

If you look closely, you can see that the left side is slightly more yellow and the right side slightly more red. Which is odd, because both strips are driven from the same LED Node, for a total of 5 meter. My explanation for this is that the ≈ 1000 Hz PWM rate, especially the short blue pulses, are being dampened by the strip’s inductance while traveling from the LED Node’s MOSFETs through the left strip to the right strip.

I haven’t tried it, but one way to verify this would be to compare the power signal of the blue LED at the start and at the end of the LED strip. If my theory is correct, then the pulses should look different.

It’s a small effect, but it shows, and I don’t like it at all. I’ve got two ways to solve it, I think: 1) feed the PWM power signals separately to both LED strips, or 2) use two LED Nodes, each directly feeding their own LEDs.

Maybe it’s just the +12V supply line, in which case it’d be enough to connect +12V to the end as well. We’ll see.

Finicky things, them RGB LED strips!

Update – I’ve placed the LED Node between both strips. Color differences are now almost gone, but there’s still a shift-to-red towards the ends, i.e. the high PWM frequency is hampered by signal propagation.

▶ View 32 Comments

JeeNode USB problems

In Hardware on Nov 7, 2011 at 00:01

A new problem has surfaced with the JeeNode USB v3: it turns out that the most recent units have accidentally been assembled and shipped with a 3.0V regulator instead of the required 3.3V regulator.

This is a problem for two reasons:

all attached devices will run at 3.0V instead of 3.3V
the ATmega328 runs further out of spec at 16 MHz

The second (older) problem is that the original OptiBoot loader had a bug in combination with the FTDI interface as used on JeeNodes. This has affected a number of people over the past months, but was resolved before the summer by switching to a modified version of OptiBoot on all JeeNode USB’s and JeeLinks (the fix was to change the watchdog timeout from 500ms to 1s). This problem appears to only matter on Windows systems.

Still, these past few weeks, I was surprised to see yet more problem reports on the forum about “not being able to upload a new sketch” – which is how the OptiBoot bug manifested itself.

My hunch is that this new 3.0V regulator mixup can lead to the same problem, but for a different reason: when running at 16 MHz from 3.0V, the ATmega is running out of spec, or in other words: it’s being over-clocked.

Over-clocking works fine, mostly. But not always. It may depend on chip fabrication, operating temperatures, and maybe even on what the chip is doing.

In short: there are probably still a few dozen JeeNode USB’s out there which are not performing properly due to either the OptiBoot bug, or the wrong regulator (probably not both, because the OptiBoot bug was solved before the regulator mixup happened).

How to diagnose these problems

If you have a JeeNode USB which isn’t working as expected, you can take these steps:

try to upload a new sketch to it (set the board type to “Arduino Uno”)
if that doesn’t work, and you’re certain that you did it right, you can return it

If you can upload sketches (best chances are on Mac and Linux), then you can perform an additional test to check the regulator voltage, by uploading the following sketch:

Screen Shot 2011 11 06 at 21 22 03

This only works on the JeeNode USB, which has a voltage divider connected to analog pin 6.

Now open the serial console and watch the values, reported once a second:

with a good 3.3V regulator, they will be about 4200
with an incorrect 3.0V regulator, they’ll be ≈ 4600

The 4600 value comes from making an incorrect calculation, due to the assumption that the total input range is 6600 mV, whereas with a 3.0V regulator it is actually 6000 mV. If you change the 6600 to 6000 on a bad unit, it’ll again report about 4200, which is indeed the voltage on the PWR pin when powered from the USB bus through the LiPo charger (even when no LiPo battery is attached).

If you have the wrong regulator, you can of course also return it and I’ll repair it and send it back ASAP. In that case, please return it to the address listed on this page and include your own address so I can send it back.

So what happened?

Well, these units are being assembled in small quantities for me by a third party. Somewhere, someone messed up and placed the wrong chips on the board. These are SMD chips, so after such a mixup happens it’s pretty unlikely that anyone would spot it from the tiny lettering on the regulator. During programming, the power is supplied by the ISP programmer, i.e. the intended 3.3V. And during testing they will probably all have passed because the ATmega’s do tend to work correctly, even when over-clocked to 16 MHz @ 3.0V.

Sooo… I / we messed up, and delivered flawed units. For which I am really sorry, and for which I sincerely apologize. It shouldn’t have happened, but it did. Mr. Murphy decided to drop by, clearly.

I find this deeply embarrassing. I know how frustrating it is (who doesn’t?) when dealing with products which don’t work as expected – as promised, in fact. This post is obviously about damage control. Doing what is needed to address the issue. Not just for now, but also to make sure it won’t happen again. I’ve got some ideas on that, which I hope will have an effect – an invisible one, in that such mishaps will not happen again. Or much less.

Because, let’s face it: mistakes happen.

For a normal business, the way to deal with mishaps like these, is no doubt to improve the QC/QA procedures, install a sense of more accountability and stricter procedures, and basically “improve the system”. This is a slow and costly process. And the way to handle it is to scale up and amortize the expenses. Economies of scale.

But JeeLabs is not a normal business in this respect. Scale is not my goal, sustainability is. Which means that quality and durability is just as important to me as to anyone, but there are no others to “install a sense of more accountability” into. Like any business, I try to pick my suppliers with care, and work with them so we all perform as well as we can, but that’s about it. Problems must be solved at JeeLabs’ current scale of operation.

Maybe it can’t be done, maybe it can. But IMO it’s worth trying, because more small business-like “shops” are being started every day. So why not try and figure out how to produce stuff – good stuff – on a smaller scale?

Anyway. If you’ve got a flawed JeeNode USB, and want to have it fixed ASAP, please return it. New ones will be ready in three weeks, so if you’d rather use it and receive the replacement first, please let me know by email and I’ll send a replacement out once available. If so, there’s no need to send it back before the new one arrives.

Again, my apologies for the mixup. Products are fun – and producing quality products is hard.

Let’s use LEDs

In Hardware on Nov 6, 2011 at 00:01

For many years, we’ve had this fixture + Edison-type incandescent light tube above our front door:

DSC 2708

And it shows… my apologies for the dirty fixture (top) and light bulb (bottom).

That’s a 120 W lamp (it’s 120 cm long!), which used to be on for several hours each evening, day in day out.

Time to move on to a better solution:

DSC 2709

This is a standard RGB LED strip in an aluminum profile with diffuser. It draws about 15 Watt from a 12V LED supply, i.e. an immediate eight-fold improvement over the previous setup. And it didn’t cost me anything, because this unit came from my workbench, where I also switched to a different (LED-based) lighting setup.

It’s now also an excellent candidate for the new LED Node, which includes support for a PIR motion detector and an LDR light sensor. What I’d like is to have this light turn on very dimly once night falls, and then gently ramp up to full brightness when someone is actually at the door. Welcome!

Not there yet: I still need to implement the software – the Achilles’ heel of Physical Computing!

Running LED ticker

In Hardware on Nov 1, 2011 at 00:01

For a while, these “ticker tape” displays were quite the rage. They probably still are in shop displays where LCD screens haven’t taken over:

590996 BB 00 FB EPS

This one is powered from 12 VDC, and has a serial RS232 interface with a funky command structure to put stuff into its line- and page-memory. Lots of options including lots of scroll variations, blinking, and beeping.

Well, a friend lent me one a while back and we thought it’d be fun to add a wireless interface via a JeeNode.

Time to take it apart, eh?

It didn’t take long to figure out the way to hook up to it, and there was some useful info in this domoticaforum.eu discussion from a few years back.

I decided to use this P4B serial adapter from Modern Device to interface the JeeNode to the RS232 signals:

DSC 2702

It’s convenient because it plugs right into the FTDI connector, and it has the onboard trickery needed to generate “RS232’ish” voltages. The whole thing is mounted on foam board using double-sided tape and the JeeNode can easily be unplugged to upload a new sketch.

Here’s the whole “mod” on the back side of the display:

DSC 2701

There’s a wire to the +5V side of a large cap, used to drive the displays no doubt. The JeeNode’s internal regulator will convert that down to 3.3V, as usual.

The positioning of the JeeNode is tricky, because the entire enclosure (apart from the smoked glass at the front) is metal – not so good for getting an RF signal across. I decided to place the antenna at the far edge, since the end caps are made from plastic. Hopefully this will allow good enough reception to operate the unit while closed.

The serial pins are conveniently brought out on some internal pads, right next to the RJ11 jack used for RS232:

DSC 2703

I haven’t hooked up RX and TX yet, because I still need to find out which is which.

I’ve verified that I can communicate with the unit through a USB-BUB wired through to the P4B adapter, i.e. straight from my laptop.

Next step is to write a sketch for the JeeNode…

Permanent LCD display

In Hardware on Oct 31, 2011 at 00:01

Remember the re-using an LCD screen post?

Well, I’ve now built it into my lab corner at JeeLabs:

DSC 2698

The panel is hinged and swings to the left for access to other stuff, and everything has simply been screwed on. You can see the Acer Aspire One netbook mid-center, which is driving this display in mirroring mode right now.

Here’s the back, with 12V power, VGA, and DPMI connectors:

DSC 2700

You can see the (ugly) drilled cutout, with the backlight of the display shining through.

This display is going to be used mainly to experiment with basic in-house display of the data I’ve been collecting for so long, but it will also be available for a new oscilloscope I ordered recently, as well as other experiments which produce a VGA or DPMI signal, such as embedded Linux boards. A Raspberry Pi, perhaps?

A new life for an old discarded laptop display!

CC-RT: Pin assignments

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

Part 4 of the Crafted Circuits – Reflow Timer series.

Now that all the pieces of the circuit are known, more or less (I’ll assume that the MAX31855 can be used), it’s time to figure out whether everything will fit together. One issue I’d like to get out of the way early on, is pin assignments on the ATmega. There are 20 I/O pins: 14 digital, of which 6 PWM, and 6 digital-or-analog.

The best thing would be to make this as compatible with existing products as possible, because that simplifies the re-use of libraries. For this reason, I’ll hook up the RFM12B wireless module in the same way as on a JeeNode:

D.2 = INT0 = RFM12B INT
D.10 = SS = RFM12B CS
D.11 = MOSI = RFM12B SI
D.12 = MISO = RFM12B SO
D.13 = SCK = RFM12B SCK

5 I/O pins used up – let’s see how many the rest needs:

2 LED’s = 2 pins
2 buttons = 2 pins
buzzer = 1 pin
LCD + backlight = 7 pins
thermocouple = 3 pins
SSR output = 1 pin

Total 5 + 16 = 21 pins. Whoa, we’re running out of pins!

Unfortunately, we’re not there yet: the thermocouple chip consumes about 1 mA, so we need a way to power it down if we want a serious auto power-off option. That’s one extra pin.

Also, it would be very nice if this thing can be programmed like a regular Arduino or JeeNode, i.e. using D0 and D1 as serial I/O. That also would help a lot during debugging and in case we decide to use the serial port for configuration. Hm, another 2 pins.

And lastly, I’d like to be able to measure the current battery voltage. Drat, yet another (analog) pin.

All in all we seem to need 5 more pins than are available on an ATmega168/328 28-DIP chip!

The good news is that there are usually a few ways to play tricks and share pins for multiple purposes. One easy way out would be to just use an I/O expander (like the LCD-plug) and gain 5 I/O pins right away. But that’s cheating by throwing more hardware at the problem. Let’s look at some other options:

the SSR output can be combined with one of the LEDs, since a red LED will probably be used to indicate “heater on” anyway
the thermocouple chip is a (read-only) SPI chip, which means that its SCK and SO pins can be shared with those of the RFM12B
one way to free the button pins is to put the buttons on data lines used by the LCD – with extra resistors to let the LCD output work even while pressed
the buttons and LEDs could be combined, as on the Blink Plug (this is mildly confusing, since pressing a button always lights its LED as well), but this would prevent sharing the SSR output with the red LED
multiple buttons could be tied to a single analog input pin by adding some extra resistors, but this rules out the use of pin-change interrupts
yet another trick is to combine a high-impedance analog input (for measuring battery voltage) with a pin which is usually used as output, such as one of the LCD data pins

I’m inclined to adopt the first three tricks. That frees five pins – one can be used to power the thermocouple chip and two would be D0 and D1 to support standard serial I/O. We could have up to 5 push buttons this way.

So all in all, the 28-pin ATmega seems to be just right for the Reflow Timer. Depending on the complexity of the sketch, either an ATmega168 or an ATmega328 could be used. My current reflow sketch fits in either one.

With luck, the Reflow Timer can remain compatible with Arduino, RBBB, JeeNode, etc. and it will support sketch uploads in exactly the same way as with JeeNodes and RBBB’s, i.e. through an FTDI 6-pin header with a USB-to-FTDI interface such as the USB-BUB.

Let’s try and come up with a tentative pin allocation:

D.0 and D.1 = serial I/O via FTDI pins
D.2 and D.10 .. D.13 = RFM12B, as above
D.3 = LCD backlight (supports hardware PWM)
D.4 = buzzer
D.5 and D.6 = LED outputs (both support PWM)
D.8 and D.9 = thermocouple power and chip select
A.0 = battery voltage readout
A.1 .. A.5 and D7 = LCD (4 data + 2 control)
A.1 .. A.5 = shared with up to 5 push buttons

Several pins could be changed if this will simplify the board layout later – but hey, ya gotta start somewhere!

Note that I’m using D.X as shorthand for digital pins, and A.Y for analog pins, matching Arduino terminology (where A.Y can also be used as digital pin => D.(Y+14)).

The next step will be to work out more electrical details, i.e. figure out how to add some new features.

The AC current sensor node lives!

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

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

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

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

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

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

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

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

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

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

AC current node prototype

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

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

DSC 2680

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

Here’s the completed unit with a test hookup:

DSC 2690

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

Screen Shot 2011 10 17 at 21 18 07

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

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

Running on charge

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

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

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

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

Screen Shot 2011 10 17 at 20 03 56

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

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

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

  set_sleep_mode(SLEEP_MODE_IDLE);
  sleep_mode();

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

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

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

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

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

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

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

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

Here’s my very very sketchy estimate:

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

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

Progress!

Picking an ATtiny

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

The reason I’m using an ATtiny for the AC current measurement setup, is their differential ADC + gain, and because it is fairly easy to develop for them using the same Arduino IDE as used by, eh, well, Arduino’s and JeeNodes. There are good installers for Windows, Mac OSX, and Linux.

There are several very interesting alternatives other than ATmega and ATtiny, such as the Microchip Technologies PIC and the Texas Instruments MSP430 series. But while they each are attractive for a number of reasons, they either have only a development environment for Windows, or they don’t support standard gcc, or they just don’t offer enough of an advantage over the Atmel AVR series to justify switching. So for something like the AC current node, which doesn’t even need to run off a battery, I’d rather stick to the Arduino IDE and carry over much of what is already available for it. In terms of cost, the differences are minimal.

The trouble with the ATtiny85 I’ve been using for the AC current sensor is that it only has at most 6 I/O pins, while the RFM12B needs 5 to operate (with polling instead of interrupts, this could be reduced to 4).

I’ve tried hard to find tricks to re-use pins, so that the differential ADC pins can be used during measurements while still supporting the RFM12B somehow. I even considered using a 1-pin OOK transmitter instead of the RFM12B. But in the end I gave up – the hassle of finding a solution, figuring out how to support this in software, and still have a decent way of debugging this (read: ISP) … it didn’t add up.

It’s much easier to pick a chip which is slightly less I/O-pin limited, such as the 14-pin ATtiny84:

Screen Shot 2011 10 17 at 14 10 11

One drawback w.r.t. to the ATtiny85, is that it has no 2.56V bandgap reference, only 1.1V – but it does have differential ADC inputs with optional 20x gain stage, which is what made AC current measurements possible.

It turns out that the ATtiny84 has enough I/O pins (a whopping 11!) to support an SPI interface to the RFM12B as well as 2 complete JeeNode-like ports. There is in fact enough I/O capability here to hook up a Room Board.

The 8 Kb flash rom size is sufficient for the RF12 driver plus a bit of application-specific functionality. The 512-byte RAM is not huge, but should also be sufficient for many purposes (two full RF12 buffers will use up less than a third of what’s available). And lastly, there are 512 bytes of EEPROM – more than enough.

To be honest, I’ve been fooling around with this chip for some time, since it could be used to create even smaller PCB’s than the JeeNode. But it has taken me quite a while to get the SPI working (both hardware- and software-based), which was essential to support the RFM12B wireless module. The good news is that it now does, so this is what I’m going to use for the rest of the AC current sensor experiments – wireless is on the way!

Stay tuned …

No, wait. One more factoid: this weblog was started exactly 3 years ago. Celebration time – cheers!

Charging a supercap

In Hardware on Oct 24, 2011 at 00:01

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

JC s Doodles page 20

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

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

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

DSC 2687

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

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

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

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

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

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

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

Time for a cup of coffee…

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

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

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

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

DSC 2688

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

Funny Eneloop battery

In Hardware on Oct 23, 2011 at 00:01

I don’t know what happened…

DSC 2685

Weird wrinkled plastic wrapper. No leakage or bulge. The other side:

DSC 2686

Maybe this thing got short-circuited and became very hot? Maybe the wrapping has some heat-shrinking properties on purpose, to report this condition even if you look well after things have cooled down again?

I’ve been switching to Eneloop AA batteries everywhere since over a year now, due to the three nice chargers I’ve got. The advantage over NiCad and NiMh is that these really retain their charge for more than a year – perfect for wireless sensor nodes. When fully charged, each cell supplies 1.3V @ 1900 mAh. I’m also re-using these batteries over and over again in the wireless keyboards and mice we have (my mouse runs out once a month).

But that’s the end of the line for this one!

ELRO energy monitor decoding #2

In Hardware on Oct 22, 2011 at 00:01

Yesterday’s post showed how to try and figure out the data sent out by the ELRO wireless units. There’s a lot of guesswork in there, but the results did look promising.

The last guess was about how the data bytes are organized in the packet – which is usually the hardest part. Ok, so now if I treat these as low-to-high 8-bit bytes, then the two packets give me:

    12 1 231 4 16 0 0 213 81 17    hex: 0C 01 E7 04 10 00 00 D5 51 11
    12 1 232 4 16 0 0 214 81 17    hex: 0C 01 E8 04 10 00 00 D6 51 11

There’s not much more one can do with this, because all the packets contain the same information. Now it’s time to add a load to the monitor, so that it will report some more interesting values. I used a 75 W light bulb, so the instantaneous consumption reported should be around that value, and there will probably be a slowly-increasing cumulative power consumption reported as well.

Here are a bunch of packets, using the most recent decoding choices:

Screen Shot 2011 10 16 at 16 10 13

Great – the first four repetitions have again mostly zero’s, with a minor fluctuation in what is presumably the line voltage again. Looks like each reading gets sent out 15 (!) times or so. Or maybe a few more which aren’t recognized – the pulse width thresholds might still be off slightly.

And then values start coming in. Let’s see what this gives when decoded as bytes:

    200 8 1 231 0 32 0 0 216 81 33
    200 8 1 230 0 32 0 0 215 81 33
    200 8 1 230 0 32 0 0 215 81 33
    200 8 1 229 0 32 0 0 214 81 33
    200 8 1 230 32 32 243 2 236 82 33
    200 8 1 230 32 32 242 2 235 82 33
    200 8 1 229 32 32 240 2 232 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 240 2 232 82 33
    200 8 1 230 32 32 240 2 233 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 238 2 230 82 33

Hm. That fourth byte could indeed be the line voltage, but the rest?

Let’s try the 25 W lamp:

    200 8 1 229 10 32 246 0 214 82 33
    200 8 1 229 10 32 246 0 214 82 33
    200 8 1 228 10 32 246 0 213 82 33

Aha – 10 is ≈ 1/3rd of 32. And 246 is ≈ 1/3rd of 2*256+238. Maybe these are amps and watts, not cumulative values after all. No wonder it’s transmitting so often – a lost transmission will cause an inaccurate reading.

Here’s a 700 W load (my reflow grill):

    200 8 1 230 44 33 255 26 29 83 33
    200 8 1 230 44 33 246 26 20 83 33
    200 8 1 230 43 33 221 26 250 82 33

Checking the load with another meter tells me it’s more like 680 W and 2.89 A @ 231 V.

Well, well: the bytes 221 and 26, when interpreted as little-endian int are 6887, i.e. the wattage in 0.1 W steps!

Let’s try amps the same way. With no load, there were values 16 and 32, so probably bits 4..7 of that second byte are used for something else. Let’s try 43 and 33-32, little-endian: could it be 2.99 A?

If all these guesses are correct, then the 75 W lamp readings are: 0.32 A and 75.0 W, and the 25 W lamp readings are: 0.10 A and 24.6 W – hey, these are indeed all pretty much spot on, yippie!

Here’s the other unit with no load plugged in:

    102 12 1 232 0 16 0 0 210 81 17
    102 12 1 232 0 16 0 0 210 81 17

The first two bytes differ. Perhaps a unit ID with its own header checksum?

It looks like the 6-byte is either 16 or 32, perhaps indicating an auto-scale amps range. Also, note how the next to last byte changes from 81 to 82 to 83 on these readings. I suspect that the packet checksum is actually 16 bits.

Great, I think I can implement a decoder for them now. It would be nice to get the checksum validation right, but even without this it will be useful.

These two units are going to be used for some varying loads here at JeeLabs: probably the dish washer and the washing machine. Since they send out readings once every 10 seconds, that should give me sufficient info to correlate with the house meter downstairs.

The readout unit is of no use to me anymore, so I’ve taken it apart:

DSC 2683

Simple OOK receiver, and single-sided board. Not many surprises, really:

DSC 2684

There are low-cost temperature (an NTC ???) and humidity sensors in there, as well as a buzzer (you can set an alarm when a certain power level is exceeded).

The only interesting bit is that the power for the receiver is switched via a transistor, so presumably it synchronizes its reception timing to when the units transmit (the display supports up to 3 units).

One nasty habit of these ELRO units is that they send out a lot of packets: each one sends about 15 per every 10 seconds, and it looks like this takes well over one second per transmission. I’m glad they use the 433 MHz band, otherwise they’d cause quite a few collisions with all the wireless RF12 stuff going on at JeeLabs.

Onwards!

ELRO energy monitor decoding

In Hardware on Oct 21, 2011 at 00:01

I recently found this set at reichelt.de:

ELROEC11

The battery-powered receiver is a bit large and ugly (10×13 cm), but what I was after were the measurement units, which transmit wirelessly on the 433 MHz band, using OOK.

That was a good reason to dust off the ookScope project and adjust them to work with the latest Arduino IDE (sketch) and JeeMon (script).

Here is the result after over 1,000,000 pulses:

Screen

This is a histogram with counts on the horizontal axis and pulse widths on the vertical axis. Both are scaled in a somewhat peculiar logarithmic’ish way, but the main info is on the bottom status line: the packets contain 360 pulses (i.e. bit transitions) with maximum counts at pulse widths of 184, 360, and 460 µs.

I used very specific settings and thresholds to single out these packets:

Screen Shot 2011 10 16 at 14 28 48

So it only picks up packets with 360..362 bit transitions, and ignores all pulses under 40 µs (10 x 4 µs).

The two longer pulse widths might be the same “long” pulse, depending on whether that pulse comes after a short or a long pulse. Here are the first few pulse widths of a quick burst of packets (ignore the P and first int):

Screen Shot 2011 10 16 at 14 28 14

There’s clearly a pattern. If I apply the following translation:

pulse < 260 -> display as “-“
pulse 260..411 -> display as “.”
pulse > 411 -> display as “|”

… then this comes out (this is one long line, wrapped every 80 characters):

Screen Shot 2011 10 16 at 14 43 55

So it looks like there are short (< 260 µs) and long (> 411 µs) pulses, with always a pulse in the range 260..411 µs in between them. And if those dots contain no extra information anyway, then we might just as well omit them:

Screen Shot 2011 10 16 at 14 48 16

That leaves 181 bits of “data”, presumably. If I drop all packets which don’t end up with exactly 181 dashes and pipe symbols, then it turns out I get just a few patterns – here’s a group which changes halfway down, if you can spot the difference:

Screen Shot 2011 10 16 at 14 58 25

But there’s still too much regularity here, IMO. Note that there’s not a single run of three _’s or |’s in there (other than at the start of the line). In fact, all these are either _|’s or |_’s, back to back. So it looks like there are not 2 transitions per data bit, but 4. Let’s reduce the output further. I’ve replaced _| by “0” and |_ by “1” (assuming there are more 0’s than 1’s). I’ve also removed all duplicate lines, and inserted a count of them at the front:

Screen Shot 2011 10 16 at 15 16 03

Note the alternation of 1110 and 0001 in these lines. My hunch is that it’s a slowly varying measurement value, overflowing from 7 (binary 0111) to 8 (binary 1000). This would indicate that the bit order is low-to-high.

Note also that further down the packet, the bit pattern flips from 10 to 01, which is a difference of 1 in binary terms. That’s probably a checksum, and it’s not using exclusive or (since 4 bits have changed) but simple byte-summing. Furthermore, the checksum is 40 bits to the left of the changed value, so there are either 5 bytes from value to checksum, or 8 nibbles-plus-guard-bit units. Let’s try grouping them both ways:

Screen Shot 2011 10 16 at 15 32 18

There is no load right now. The 8-bit grouping is interesting, because then the value alternates between 231 (0b11100111) and 232 (0b11100100) … could this be the line voltage?

Tomorrow, I’ll continue this exploration – let’s see if the data can be extracted!

CC-RT: Choices and trade-offs

In Hardware on Oct 20, 2011 at 00:01

This is part 2 3 of the Crafted Circuits – Reflow Timer series.

There are many design choices in the Reflow Timer. The goal is to keep it as simple and cheap as possible, while still being usable and practical, and hopefully also convenient in day-to-day use.

Display and controls – there are several low-cost options: separate LEDs, 7-segment displays, a character LCD, or a graphics LCD. The LEDs would not allow displaying the current temperature, which seems like a very useful bit of info. To display a few numbers, a small character-based LCD is cheaper and more flexible than 7-segment displays (which need a lot of I/O lines). The only real choice IMO, is between a character-based and the graphics LCD. I’ve decided to go for a 2×16 display because A) fancy graphics can be done on a PC using the built-in wireless connection, and B) a character LCD is cheaper and sufficient to display a few values, status items, and menu choices. And if I really want a GLCD option, I could also use wireless in combination with the JeePU sketch.

For the controls, there’s really only one button which matters: START / STOP. The power switch might be avoided if a good auto-power implementation can be created in software. For configuration, at least one more button will be needed – with short and long button presses, it should be possible (although perhaps tedious) to go through a simple setup process. A third button might make it simpler, but could also slightly complicate day-to-day operation. So two or three buttons it is.

Temperature sensor – this is the heart of the system. There are essentially two ways to go: using an NTC resistor or using a thermocouple. The NTC option is considerably cheaper and can be read out directly with an analog input pin, but it has as drawback that it’s less accurate. In the worst case, accuracy might be so low that a calibration step will be needed.

Thermocouples don’t suffer from the accuracy issue. A K-type thermocouple has a known voltage differential per degree Celsius. The drawback is that these sensors work with extremely low voltages which require either a special-purpose chip or a very sensitive ADC converter. Since thermocouple voltages are based on temperature differences, you also need some form of tracking against the “cold junction” side of the thermocouple. Thermocouple-based sensing is quite tricky.

But the main reason to use them anyway, is mechanical: although there are glass-bead NTC’s which can withstand 300°C and more, these sensors come with short wires of only a few centimeters. So you need to somehow extend those wires to run from the heater to the Reflow Timer. And that’s where it gets tricky: how do you attach wires to that sensor, in an environment which will heat up well beyond the melting point of solder? And what sort of wire insulation do you use? Well… as it turns out, all the solutions I found are either very clumsy or fairly expensive. There’s basically no easy way to get a glass-bead NTC hooked up to the reflow timer in a robust manner (those wires out of the glass bead are also very thin and brittle). So thermocouple it is.

Thermocouple chip – for thermocouples, we’ll need some sort of chip. There seem to be three types:

dedicated analog, i.e. the AD597
dedicated digital, i.e. the MAX6675 or MAX31855
do-it-yourself, i.e. a sensitive ADC plus cold-junction compensator

The AD597 is used the the Thermo Plug and in my current reflow controller setup. It works well, with a voltage of 10 mV/°C coming out as analog signal. So with 250°C, we get 2.50V – this is a perfect match for an ATmega running at 3.3V. The only small downside, is that it needs an operating voltage which is at least 2V higher than the highest expected reading. If we need to go up to say 275°C (above what most ovens can do), then we’ll need a 4.75 V supply voltage for the AD597.

The MAX6675 doesn’t have this problem because the readout is digital, and works fine with supply voltages between 3.0 and 5.5V. But it’s a very pricey chip (over €14 incl VAT). Keeping these in stock will be expensive!

The MAX31855 is also a digital chip, and about half the price of the MAX6675. The main difference seems to be that it can only operate with a supply from 3.0 to 3.6V, which in our case is no problem at all (we need to run at 3.3V anyway for the RFM12B). I’ve no experience with it, but this looks like a great option for the Reflow Timer.

There is a slight issue with each of these chips, in that they do not exist in through-hole versions but only in a “surface mounted device” (SMD) style. The package is “8-SOIC”, i.e. a smaller-than-DIP 8-pin plastic chip:

8 SOIC sml

For people who don’t feel confident with soldering it might pose a challenge. There are no sockets for SMD, you really have to solder the chip itself. Then again, if you’re going to create a reflow setup for building SMD-based boards anyway, you might as well get used to soldering these size chips. Trust me, SOIC is actually quite easy.

(note: there is an all-DIP solution with the LT1025, but it needs an extra op-amp, so I’ve not checked further)

Battery

If we can use the MAX31855, then everything can be powered with 3.3V. This means that either 3x AA or 1x LiPo will work fine, in combination with a 3.3V regulator. I’ll stick with the MCP1702 regulator, even though it’s not the most common type, because of its low standby current – this will help reduce power in auto power-down mode.

But how much current do we need? To put it differently: how long will these batteries last? Let’s find out.

The prototype I have appears to use about 35 mA while in operation. Let’s take a safety margin and make that 50 mA in case we also need to drive an opto-coupler for the SSR option. And let’s say we use 2000 mAh AA cells, then we’ll get 40 hours of operation out of one set of batteries. Let’s assume that one reflow cycle takes 10 minutes, plus another 5 minutes for auto power-off, then we can use one set of batteries for 160 reflow cycles. Plenty!

We could even power the Reflow Timer with an AA Power Board, and still get about 50 cycles – but that would increase the cost and require some very small SMD components.

Let’s just go for the 3x AA setup, with either a DC or USB jack as possible alternative.

AC mains switching

For switching the heater, there are several options. The one I’m using now is a remote-controlled FS20 switch from Conrad (or ELV). It can be controlled directly by the RFM12B wireless module. An alternative would be the KAKU (a.k.a. Klik Aan Klik Uit or Home Easy) remote switch, which operates at 433 MHz and kan also be controlled directly from the RFM12B. The advantage of this setup is that you never need to get involved with AC mains – just place the remote switch between mains socket and heater (grill, oven, etc) and you’re done.

Another option is to use a Solid State Relay (SSR), which needs 5..10 mA of current through its built-in opto-coupler. I built this unit a while back to let me experiment with that. The benefit of such a configuration is that all the high-voltage AC mains stuff is tucked away and out of reach, and that the control signal is opto-isolated and can be attached to the Reflow Timer without any risk. Note that with SSR, the RFM12B module becomes optional.

Yet another option would be to use a mechanical relay, but I’d advise against that. Some heaters draw quite a bit of current (up to 10A) and will require a hefty relay, which in turn will require a hefty driver. Also, very few power relays can operate at 5V, let alone 3.3V – which means that a 3x AA powered approach would not work.

So, RF-controlled switch it is, with an extra header or connector to drive the LED in an SSR as option.

That’s about it for the main Reflow Timer circuit design choices, methinks.

CC-RT: Prototyping

In Hardware on Oct 19, 2011 at 00:01

This is part 2 of the Crafted Circuits – Reflow Timer series.

Now that the initial requirements of the Reflow Timer have been laid out, it’s time to design and build a first prototype of the whole setup. Normally, I’d do this with either a solder-less breadboard (shown on the left) or a soldered protoyping PCB (bottom view of an example shown on the right):

DSC 2691

But in this case, I’ll skip those since I already built up a system using a JeeNode, some plugs, and my favorite circuit hacking setup, which I call Projects On Foam:

DSC 2189

That’s a JeeNode mounted upside-down, with a few plugs: a Thermo Plug, a Blink Plug, and an LCD Plug with a 2×16 character LCD on top. In the bottom right is a 4x AA battery pack, stuck to the board with double-sided tape.

I’ve been using this setup for about a year now. There are some “features” listed which don’t actually exist, such as the calibration mode: the current sketch has fixed values, tweaked by trial and error for my specific grill. But apart from that, it works well: prepare grill, turn on, press start, wait for beep, open grill, turn off, done.

The reason to skim over this step in this series of posts, is that your setup will differ anyway, unless you intend to build exactly the same thing. But it’s still a crucial step to go through. This is where you get to test that your idea actually works, and where you create the setup needed to develop and test the software, i.e. sketch.

Having constructed this setup, I know it works. I also gained valuable experience with it – and I’m still not 100% satisfied (besides being a mish-mash of plugs stuck together on a foam board). The main issues are:

this is using an AD597 thermocouple chip, which needs at least 5V – hence the 4x AA
there is no provision for a mechanical or solid-state relay to switch the heater
I’d like to have more control over the backlight, i.e. dimming through PWM
it’d be nice to support an auto-power-down mode which draws virtually no current
the LCD plug could be omitted if we have enough I/O pins to drive the LCD directly
maybe the transistor driving the beeper can be omitted as well

Those last two items are all about reducing the number of components. Less components = lower cost = simpler build instructions = better chances of success = everybody happy :)

Tomorrow, I’ll go through the main choices / trade-offs.

Voltage levels

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

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

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

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

JC s Doodles page 19

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

Uh, oh – we’re in trouble!

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

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

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

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

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

Oh well. Not there yet, but progress nonetheless!

Finding a power source

In Hardware on Oct 16, 2011 at 00:01

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

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

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

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

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

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

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

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

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

JC s Doodles page 19 copy

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

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

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

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

▶ View 22 Comments

CC-RT: Initial requirements

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

Let’s get going with the CC-RT series and try to define the Reflow Timer in a bit more detail. In fact, let me collect a wish list of things I’d like to see in there:

The Reflow Timer should…

support a wide range of ovens, grills, toasters, and skillets
be self-contained and safe to build and operate
include some buttons and some sort of indicator or display
be created with through-hole parts as much as possible
(re-) use the same technologies as other JeeLabs products
be built on a custom-designed printed circuit board
use a convenient and robust mechanical construction
be very low-cost and simple to build

To start with that last point: the aim is to stay under € 100 as end-user price, including a simple toaster and whatever else is needed to control it. That’s a fairly limiting goal, BTW.

I’m sticking to “the same technologies” to make my life easy, both in terms of design and to simplify inventory issues later, once the Reflow Timer is in the shop. That translates to: an Arduino-like design with an ATmega328, and (for reasons to be explained next) an RFM12B wireless module.

Safety is a major concern, since controlling a heater tied to 220 V definitely has its risks. My solution to controlling an oven of up to 2000 W is the same as what I’ve been doing so far: use a commercially available and tested power switch, controlled via an RF signal. KAKU or FS20 come to mind, since there is already code to send out the proper signals through an RFM12B module. Range will not be an issue, since presumably everything will be within a meter or so from each other.

With wireless control, we avoid all contact with the mains power line. I’ll take it one step further and make the unit battery-operated as well. There are two reasons for this: if we’re going to uses a thermocouple, then leakage currents and transients can play nasty games with sensors. These issues are gone if there is no galvanic connection to anything else. The second reason is that having the AC mains cable of a power supply running near a very hot object is not a great idea. Besides, I don’t like clutter.

Having said this, I do not want to rule out a couple of alternatives, just in case someone prefers those: controlling the heater via a relay (mechanical or solid-state), and powering the unit from a DC wall wart. So these should be included as options if it’s not too much trouble.

To guard against heat & fire problems, a standard heater will be used with a built-in thermostat. The idea being that you set the built-in thermostat to its maximum value, and then switch the entire unit on and off via the remote switch. Even in the worst scenario where the switch fails to turn off, the thermostat will prevent the heater from exceeding its tested and guaranteed power & heat levels. One consequence of this is that the entire reflow process needs to unfold quickly enough, so that the thermostat doesn’t kick in during normal use. But this is an issue anyway, since reflow profiles need to be quick to avoid damaging sensitive components on the target board.

On the software side, we’ll need some sort of configuration setup, to adjust temperature profiles to leaded / unleaded solder for example, but also to calibrate the unit for a specific heater, since there are big differences.

I don’t think a few LEDs will be enough to handle all these cases, so some sort of display will be required. Since we’ve got the RFM12B on board anyway, one option would be to use a remote setup, but that violates the self-contained requirement (besides, it’d be a lot less convenient). So what remains is a small LCD unit, either character-based or graphics-based. A graphic LCD would be nice because it could display a temperature graph – but I’m not sure it’ll fit in the budget, and to be honest, I think the novelty of it will wear off quickly.

On the input side, 2 or 3 push buttons are probably enough to adjust everything. In day-to-day operation, all you really need is start/stop.

So this is the basic idea for the Reflow Timer so far:

JC s Doodles page 18

Ok, what else. Ah, yes, an enclosure – the eternal Achilles’ heel of every electronics project. I don’t want anything fancy, just something that is robust, making it easy to pick up and operate the unit. I’ve also got a somewhat unusual requirement, which applies to everything in the JeeLabs shop: it has to fit inside a padded envelope.

Enclosures are not something you get to slap on at the end of a project. Well, you could, but then you lose the opportunity of fitting its PCB nicely and getting all the mounting holes in the best position. So let’s try and get that resolved as quickly as possible, right?

Unfortunately, it’s not that easy. We can’t decide on mechanical factors before figuring out exactly what has to be in the box. Every decision is inter-dependent with everything else.

Welcome to the world of agonizing trade-offs, eh, I mean… product design!

New series: Crafted Circuits

In Hardware on Oct 13, 2011 at 00:01

I’m thrilled to announce a new series of posts for this weblog about how to craft, i.e. design and create, an electronic circuit based on all the neat Physical Computing stuff which has been flying across this weblog for several years now.

The purpose of these posts is to present and explain the complete process of producing a working product. It’ll be geared towards people who want to do this themselves, implementing designs of their own invention. Whether as a hobby for personal use, for teaching these skills to others, or to get rich and famous… whatever makes you tick!

Creating a complete product from start to finish is a major undertaking. But it’s also something I’m passionate about, so that’ll help stay on the path to completion. With as reward for me: a new product in the JeeLabs shop.

What

The product to be created will be a Reflow Timer kit – this is a circuit to control a heater in such a way that it can be used for reflow soldering. Hardware, software, PCB, assembly, enclosure – everything will be addressed.

It’s nothing new or earth-shattering, but it’s an excellent project for this series, because creating your own tools is a great way to extend your own capabilities. I’m all for empowerment. Given that reflow soldering is now within reach of any electronics hobbyist, and since I’ve already written many posts about this topic on the JeeLabs weblog, I feel confident that all the hurdles can be overcome.

And hurdles there will be, I assure you. Because creating a product is quite different from building a working one-off setup. Things like making it work under all sorts of real-world conditions, ease of assembly, repeatability, the availability and suitability of components for hobby use (since this will be a kit). Not to mention the 2,718,281 decisions which need to be taken.

Why

I’m doing this to share what I know and what I’ve learned so far, but also to learn new tools and try out new ideas. So while I’ll stick to several technologies which are already familiar (like the ATmega and RFM12B), you’ll also get to see me start with a new tool and struggle as I learn how to put it to use.

My second reason is to end up with a nice Reflow Timer. I love my prototype, but now I want a real product!

So my motivation is in fact two-fold: to expose the entire process and to end up with a neat new product.

How

While writing down a first outline for this series, it dawned on me just how huge the task might become, so I’m going to try hard and keep things manageable and moving forward. An unfinished product is not a product.

The plan is to create a series of posts (two dozen?) which document different aspects of this process, in the same order in which things get tackled. If you’re interested in reflow control, great – if not, please keep in mind that a lot of this should carry over to whatever electronics project you decide to work on yourself.

Ok, so much for raising expectations. Now let me lower them again to get our feet back on the ground:

I don’t know yet how often I’ll be able to come up with a new post for this series. It will to some degree depend on what sort of issues come up – there’s little point in writing a new post for the sake of continuity, when there’s not enough progress to stay ahead of the game and come up with tangible results.

I’m no “star” EE designer. I haven’t created lots of complex electronic products, and I don’t have sophisticated equipment to analyze tricky problems (neither hardware nor software). What I’ll be describing is what works for me, and what I think any enthusiastic hobbyist with a technical interest can accomplish with limited means.

Knowledge is not a pre-requisite, but something you can pick up along the way. As you’ll see, there’s an amazing amount of stuff you can accomplish nowadays, if you’ve got the interest to dive in and the time to push through.

As always, I welcome all tips, suggestions, and of course corrections. Let’s make this series as good as we can.

And lastly: the entire series will be listed on the Café website. I’ll abbreviate it as “CC-RT” from now on.

More sensitivity

In Hardware on Oct 9, 2011 at 00:01

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

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

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

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

DSC 2678

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

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

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

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

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

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

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

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

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

DSC 2672

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

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

iPad oscilloscope

In Hardware on Oct 7, 2011 at 00:01

While exploring the different ways to get to grips with the 50 Hz AC signal, I stumbled on video about oScope, an app for iPad and iPhone. It’s just €3.99, and samples with 16 bit @ 48 KHz.

It works via the audio input, which is a decent A/D converter for signals in the audio range. The neat bit is that it can also get its input via a USB audio adapter hooked up using the iPad’s camera adapter kit. And I happened to have all the required bits lying around:

DSC 2671

Woohoo – instant scope!

The horizontal and vertical are set with pinch-and-zoom, and the scale displays in the top left corner. Likewise, setting the trigger you just drag the red trigger line up or down.

Here’s a screen shot:

(it doesn’t quite come out at reduced size, but on-screen it’s gorgeous)

There’s also what appears to be an FFT power spectrum:

There’s also a (more expensive) app from ONYX Apps which can sample both audio channels and has a convenient auto-set mode (but no FFT):

The problem I have with all this is that the noise in my signal is gone. These samples were taken from the same 0.1 Ω shunt setup as in the previous days, so I’m not quite sure why the amplitude is different and why the signal is so noise-free. Perhaps there is some signal processing going in in the iPad.

But a real scope based on touch screen controls and such a large display sure would be phenomenal!

Back to basics

In Hardware on Oct 5, 2011 at 00:01

After all this messing around with 220V, and none of it working out so well, it’s time to simplify. I had a 17 VAC transformer lying around, so I decided to first get rid of all that risk. The goal remains the same: trying to reliably determine whether a low-wattage appliance is on or off. Here’s what I’m going to use:

DSC 2664

That’s a 75W lightbulb, hooked up to that AC power supply. It’s drawing 100 mA, as you can see. Unloaded, the voltage is a bit higher (as usual with transformers) – bit still harmless to experiment with:

DSC 2667

So now I can go back to a more convenient setup, and measure directly:

DSC 2668

Note that the light bulb is not on, but it does get hot to the touch. It’s still generating 20 V x 0.1 A = 2 Watts of heat, after all. Except that in this case the heat only rises, so it’s just the top of the light bulb which heats up.

It’s pretty odd that this draws only 3x as much current at 220V as at 20V. The reason for that is that the resistance of a lightbulb filament increases considerably when glowing. When a light bulb is turned on, it creates a “cold surge” which heats it up – at which point it’ll start drawing less current – a light bulb is a ~~NTC~~ PTC resistor!

Good, now we’re cookin’ again. I can hook up the USB scope at last:

Screen Shot 2011 10 04 at 14 19 58

Oooh… if that’s similar to the signal I’ve been measuring so far, then no wonder my amplitude algorithm was bad. Yikes… this thing is full of noise and spikes!

There are some nice features in the DSO-2090 software. Here’s the same waveform averaged over 128 scans:

Screen Shot 2011 10 04 at 14 43 22

Which shows that the signal indeed has non-repetitive noise superimposed on it.

Here’s something interesting. The purple line is an FFT spectrum analysis (the input signal was resized/moved):

Screen Shot 2011 10 04 at 14 26 40

There’s one spike in that spectrum. No idea what it is, but I bet that’s what’s messing up the sine wave.

Good. At least these different readings are consistent.

Time for a new mousetrap

In Hardware on Oct 1, 2011 at 00:01

It’s been a while. In December 2008, I posted about my setup for detecting the rotation of my electricity and gas meters. This was before the JeeNode even existed. It was built with an RBBB plus RFM12B with voltage dividers.

That setup has been running ever since, probably sending over a million packets around the airwaves here at JeeLabs. But it’s getting a bit old – and it’s still that dangling mess of wires. Besides, I’d really like to get a more up-to-date setup going: the current unit is still using the old v1 RF12 protocol, so it needs a specially-built receiver to pick up the packets. Then again, I don’t want to replace it before there is a sufficiently stable alternative.

First thing I did quite a while back was to get an extra electricity meter, if only to avoid the constant runs up and down the stairs. That way I can hook up a scope, and try things at my leisure:

DSC 2659

I also wanted to experiment with different sensors, so I tried the GP2S700HCP, which is a tiny SMD device:

DSC 2660

Unfortunately, the range is a bit low -it’s specified as 0.5 .. 5.5 mm. That translates to a fairly weak signal:

Screen shot 2011 06 29 at 02 16 43

About 150 mV swing on a 1.8 V signal, it seems. Hm… I might go for the venerable CNY70 after all. That’s the sensor most people seem to be using. I was hoping to find something smaller, because it would be easier to create a mounting solution for it.

Even better would be to try and detect the irregularities around the entire Ferraris wheel, and perhaps also to detect variations on the digits of the gas meter.

More tinkering needed…

It just blew apart

In Hardware on Sep 28, 2011 at 00:01

Got quite a scare the other day:

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

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

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

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

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

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

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

GLCD scope on 220V

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

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

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

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

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

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

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

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

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

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

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

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

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

Screen Shot 2011-09-26 at 15.52.38.png

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

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

Shielding!

In Hardware on Sep 23, 2011 at 00:01

Is it time for a tin foil hat?

Well, a recent comment mentioned common-mode voltage swings, and I think there’s a point there. With some resistance and impedance between the point I’m measuring and the power source downstairs, it’s easy to see how the whole thing swings widely in its “common mode”. Even the slightest leakage path to a non-swinging voltage potential could introduce a very substantial voltage difference.

Here’s a new test (it’s not the time to make mistakes!):

DSC 2635

What this does is place a ground plane underneath the whole circuit, sitting on (my all-time favorite) foam board. The foil is only attached to the JeeNode’s ground, nothing else.

And lo and behold – it really makes a difference!

The signal is 4 mV with nothing connected, and 7 mV with the power cable plugged in (but the switch still off). Turning the switch on has various effects, depending on whether the 100 W light bulb is plugged in.

With the light bulb included, the voltages I see are 80 .. 120 mV. Without, the voltages are 150 .. 400 mV. Still large swings, but nowhere near the consistent 650 .. 700 mV I was seeing before.

But what was more surprising (well… not in hindsight), is that these measurements depend on which way the power plug is plugged in. These old plugs are not polarized, so it’s easy to turn them around. It lets me put the measurement circuit in series with either the “live” or the “neutral” wire this way.

What I really like is that I’m back to 4 .. 7 mV readings when nothing is hooked up. That’s just one or two least significant bits, since the ATmega’s 10-bit ADC measures with ≈ 3 mV step sizes. It’s impossible to expect any better. This is also essential to get a decent shot at detecting low power levels.

Hm… this outcome is very awkward. A fully conducting enclosure might be best, but it’s also the most tricky one to deal with. This is after all still a dangerous 220 V hookup. A metal box inside a plastic box, perhaps? Yuck.

A shielded cable might help. Electrical signal amplification would introduce more (active i.e. power-consuming) complexity. Still, an op-amp with a super diode would allow using a capacitor to do the averaging.

A simpler direct connection

In Hardware on Sep 21, 2011 at 00:01

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

DSC 2633

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

DSC 2633 Version 2

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

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

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

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

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

▶ View 15 Comments

Direct connection summary

In Hardware on Sep 20, 2011 at 00:01

The different circuits described in the past few days all had problems (the first ACS Hall-effect hookup worked reasonably well, but was not sensitive enough for my purposes).

Here’s the circuit as it is now:

DSC 2631

Bottom side:

DSC 2632

(a slightly different layout would have avoided the overhang, had I known the complete setup in advance)

There are 3 independent circuits on there connected in series (so the same current passes through each of ’em):

JC s Doodles page 14

As you can see in the first image, there’s a little screw-less terminal block on the board. It lets me short out any combination of these setups – this was useful until everything had been built up, and also lets me rule out interference while focusing on a specific setup. Note also that this is an epoxy-based board, not the pressed-cardboard type which breaks easily and isolates less.

Let me just repeat that messing with AC mains voltages like this can be extremely dangerous. This circuit has all the wires completely exposed, and that’s intentional: I prefer to be reminded of the risks, instead of getting a false sense of security because it all looks ok! One way to deal with these risks is to completely stand back from the entire hookup and only transfer measurement data over wireless whenever applying power to this stuff.

Tomorrow I’ll describe a simpler setup to get to the bottom of the measurement anomalies I’ve been seeing so far. With many thanks for all your comments – there’s clearly a lot more to it than with simple logic level signals!

Direct 220V hookup

In Hardware on Sep 19, 2011 at 00:01

This next hookup is the most tricky one – measuring current draw via a direct connection to AC mains:

Direct connect

No more transformers, no more galvanic isolation. The 0.1 Ω resistor in series with the appliance generates 0.1 VAC of output for each 1A passed through it. The resistor handles up to 2W, which means it’ll be ok up to about 1000 W: the current will be 1000 / 220 ≈ 4.5 A, and the power generated as heat will be 0.45 V x 4.5 A ≈ 2 W.

Not that I intend to go that far. My main load test is still a 100 W light bulb.

The rest of the circuit is the same as before: one side connected to 1/2 VCC, the other end connected to an AIO pin. I’m using the same test sketch as before, sending out one reading per second.

So how does it perform? Not good, so far. Here’s the sketch running with no AC connected:

    reading:RF12-868.5.17:oneLong:value = 18070
    reading:RF12-868.5.17:oneLong:value = 14045
    reading:RF12-868.5.17:oneLong:value = 14117
    reading:RF12-868.5.17:oneLong:value = 13375
    reading:RF12-868.5.17:oneLong:value = 13359
    reading:RF12-868.5.17:oneLong:value = 38606
    reading:RF12-868.5.17:oneLong:value = 17196

That’s 13 .. 39 mV, and it’s all over the map. These readings are with no load but AC connected:

    reading:RF12-868.5.17:oneLong:value = 625570
    reading:RF12-868.5.17:oneLong:value = 631161
    reading:RF12-868.5.17:oneLong:value = 632028
    reading:RF12-868.5.17:oneLong:value = 632705
    reading:RF12-868.5.17:oneLong:value = 631796
    reading:RF12-868.5.17:oneLong:value = 632296
    reading:RF12-868.5.17:oneLong:value = 631882

Hm – 630 mV. Doesn’t make sense. Turning it off (still connected) gives this:

    reading:RF12-868.5.17:oneLong:value = 31128
    reading:RF12-868.5.17:oneLong:value = 30760
    reading:RF12-868.5.17:oneLong:value = 30961
    reading:RF12-868.5.17:oneLong:value = 30512
    reading:RF12-868.5.17:oneLong:value = 30292
    reading:RF12-868.5.17:oneLong:value = 34016
    reading:RF12-868.5.17:oneLong:value = 32847

And with the 100 W light bulb:

    reading:RF12-868.5.17:oneLong:value = 474201
    reading:RF12-868.5.17:oneLong:value = 475105
    reading:RF12-868.5.17:oneLong:value = 475399
    reading:RF12-868.5.17:oneLong:value = 474646
    reading:RF12-868.5.17:oneLong:value = 475105
    reading:RF12-868.5.17:oneLong:value = 474585
    reading:RF12-868.5.17:oneLong:value = 468425
    reading:RF12-868.5.17:oneLong:value = 463834

Now it’s 470 mV. I’m lost…

I understand how a very high-impedance circuit can pick up a signal even when not connected. But the above levels make no sense at all. On an open line, one could explain how noise pickup would completely throw off the ADC, especially when no load is plugged in.

But in this case, the input impedance towards the AIO pin is 0.1 Ω + 22 kΩ. As a test, I even removed the voltage divider, and connected the 0.1 Ω resistor directly between GND and AIO, well… with a 100 Ω resistor in series to avoid damaging the I/O pin. The only difference was that the off-state now reads as 4 mV, as expected. But load or no load, with AC connected, the reading still jumps to around 0.7 V.

Doesn’t look like the ATmega is broken, since it sends out packets and reacts to changes on its analog input pin.

I’ll look into filtering. I’ll also consider hooking up my scope, but this comes with a considerable risk – all those wires plugged into all sorts of things and a USB-powered scope which could easily fry my computer!

Perhaps there’s a bug in the sketch. A simple multi-meter hooked up across the 0.1 Ω resistor indicates levels between 4 and 12 mVAC – which seems about right.

▶ View 21 Comments

A 220 : 6.3 V transformer… backwards

In Hardware on Sep 17, 2011 at 00:01

A new day, a new setup:

The schematic of this new setup was shown yesterday.

Wait – a regular transformer AND it’s connected the wrong way around?

My first reaction when I saw this article was that this couldn’t possibly work. After all, a 220 -> 6.3 VAC transformer has a 35:1 step down ratio, so when connected in reverse, that would simply generate 7.5 kiloVolt!

The first reason this doesn’t happen, is that the transformer is connected in series with the load. It’s not measuring voltage but current. This is in fact exactly what a current transformer does.

The second reason why the high voltage never gets generated, is the 0.1 Ω (2W) resistor placed in parallel with the 6.3 V winding. With a 1000 W load, there’s 4.5 A going through the resistor, which leads to a 0.45 V voltage across the transformer. Together with the 1:35 step-up, that’s “only” 15 VAC or so on the “primary” side.

There is a risk, though: if the 0.1 Ω parallel resistor were to ever get disconnected during use, then the secondary winding will instantly turn into a little fuse, heat up, and blow. And while it does, a very high voltage spike might come out the other end!

Still, 15 V is far too much for an ATmega. But this voltage is not directly connected between the I/O pin and ground. Instead, one side is connected to a 22 / 22 kΩ voltage divider, which nicely puts the AC signal in mid-range for the ADC. When the voltage exceeds the ± 1.65 V (VCC/2) swing supported by the I/O pins, it will start to flow through the ESR protection diodes of the ATmega. With 22 kΩ on the other end to limit the current, these currents will be less than 1 mA – this is not high enough to do any harm.

Anyway, let’s see what comes out:

    $ jeemon examples/driver-demo
    ...
    reading:RF12-868.5.17:oneLong:value = 8180
    reading:RF12-868.5.17:oneLong:value = 7952
    reading:RF12-868.5.17:oneLong:value = 7886
    reading:RF12-868.5.17:oneLong:value = 8004
    reading:RF12-868.5.17:oneLong:value = 7364
    reading:RF12-868.5.17:oneLong:value = 32577
    reading:RF12-868.5.17:oneLong:value = 171745  <- 100 W light bulb
    reading:RF12-868.5.17:oneLong:value = 174525
    reading:RF12-868.5.17:oneLong:value = 175552
    reading:RF12-868.5.17:oneLong:value = 175254
    reading:RF12-868.5.17:oneLong:value = 175263
    reading:RF12-868.5.17:oneLong:value = 175193
    reading:RF12-868.5.17:oneLong:value = 175308
    reading:RF12-868.5.17:oneLong:value = 175101
    reading:RF12-868.5.17:oneLong:value = 174102
    reading:RF12-868.5.17:oneLong:value = 171595
    reading:RF12-868.5.17:oneLong:value = 89046   <- off
    reading:RF12-868.5.17:oneLong:value = 12378
    reading:RF12-868.5.17:oneLong:value = 8650
    reading:RF12-868.5.17:oneLong:value = 9568
    reading:RF12-868.5.17:oneLong:value = 9532
    ...
    reading:RF12-868.5.17:oneLong:value = 13413
    reading:RF12-868.5.17:oneLong:value = 12650
    reading:RF12-868.5.17:oneLong:value = 26564
    reading:RF12-868.5.17:oneLong:value = 111262  <- 1 W power brick
    reading:RF12-868.5.17:oneLong:value = 205944
    reading:RF12-868.5.17:oneLong:value = 209868
    reading:RF12-868.5.17:oneLong:value = 210105
    reading:RF12-868.5.17:oneLong:value = 210249
    reading:RF12-868.5.17:oneLong:value = 210311
    reading:RF12-868.5.17:oneLong:value = 210668
    reading:RF12-868.5.17:oneLong:value = 209933
    reading:RF12-868.5.17:oneLong:value = 210106
    reading:RF12-868.5.17:oneLong:value = 210014
    reading:RF12-868.5.17:oneLong:value = 209756
    reading:RF12-868.5.17:oneLong:value = 235024  <- off
    reading:RF12-868.5.17:oneLong:value = 52646
    reading:RF12-868.5.17:oneLong:value = 21260
    reading:RF12-868.5.17:oneLong:value = 10945
    reading:RF12-868.5.17:oneLong:value = 9046
    reading:RF12-868.5.17:oneLong:value = 9381
    reading:RF12-868.5.17:oneLong:value = 9236
    reading:RF12-868.5.17:oneLong:value = 8695
    reading:RF12-868.5.17:oneLong:value = 9015
    ...

How can this be? A jump from 8 mV to 175 mV for the light bulb, and then 210 mV for a much lighter load?

It gets even weirder:

    reading:RF12-868.5.17:oneLong:value = 8642
    reading:RF12-868.5.17:oneLong:value = 8567
    reading:RF12-868.5.17:oneLong:value = 11567
    reading:RF12-868.5.17:oneLong:value = 32239
    reading:RF12-868.5.17:oneLong:value = 122999
    reading:RF12-868.5.17:oneLong:value = 180108
    reading:RF12-868.5.17:oneLong:value = 180393
    reading:RF12-868.5.17:oneLong:value = 180469
    reading:RF12-868.5.17:oneLong:value = 180344
    reading:RF12-868.5.17:oneLong:value = 180702
    reading:RF12-868.5.17:oneLong:value = 180036
    reading:RF12-868.5.17:oneLong:value = 180432
    reading:RF12-868.5.17:oneLong:value = 180197
    reading:RF12-868.5.17:oneLong:value = 179220
    reading:RF12-868.5.17:oneLong:value = 174530
    reading:RF12-868.5.17:oneLong:value = 172794
    reading:RF12-868.5.17:oneLong:value = 32629
    reading:RF12-868.5.17:oneLong:value = 13266
    reading:RF12-868.5.17:oneLong:value = 7944
    reading:RF12-868.5.17:oneLong:value = 7909

This time, there is no load! I just turned on power without anything attached, i.e. an open circuit!

There’s something completely wrong here. My hunch is that this is either due to some extreme level of noise or an improperly-dimensioned burden resistor.

Noise might explain it, since the code tracks maxima, including any high-frequency spikes there might be. Maybe a digital low-pass filter could help, but I haven’t found a good source for calculating the coefficients of a FIR filter.

Further investigation will be required – this setup is useless!

SMD current transformer

In Hardware on Sep 16, 2011 at 00:01

Here’s another attempt to detect whether an appliance is on and consuming power.

This time I’m going to use a tiny SMD transformer (DigiKey part# 811-1193-1-ND). It has a 1:100 turn ratio, with 0.007 Ω resistance in the primary “coil” (I think it’s just a single loop), and rated up to 10 A.

The problem with this part, which rules it out for serious use, is that it’s only meant for frequencies in the range 50 kHz to 500 kHz. Whoops, that’ll be off by three orders of magnitude when used with 50 Hz AC mains…

Oh well, since I had one lying around, least I can do is try it – right? Here’s the setup:

The hookup is a bit odd, but will become clear in future posts. The SMD transformer is only a few millimeters square, between the green jumper block and the black mini-breadboard.

I’m using the current transformer (CT) as follows:

JC's Doodles, page 12.png

… except that this schematic is for another experiment, still pending. In this case, there is no 0.1 Ω resistor on the primary side (it wouldn’t make a difference, next to the primary’s 7 mΩ), but there’s a 100 Ω “burden resistor” on the secondary side. This matches the data sheet for getting a 1 V/A sensitivity. For info on CT’s and burden resistors, see this OpenEnergyMonitor page.

Here are some first results, using the same sketch as in yesterday’s post:

    OK 17 164 19 0 0
    OK 17 17 16 0 0
    OK 17 66 16 0 0
    OK 17 42 19 0 0
    OK 17 241 163 0 0   <- 100 W light bulb
    OK 17 107 95 0 0
    OK 17 49 93 0 0
    OK 17 77 94 0 0
    OK 17 134 94 0 0
    OK 17 244 93 0 0
    OK 17 7 94 0 0
    OK 17 151 93 0 0
    OK 17 27 93 0 0
    OK 17 124 90 0 0
    OK 17 119 24 0 0    <- off
    OK 17 125 24 0 0
    OK 17 36 16 0 0
    OK 17 246 15 0 0
    OK 17 109 16 0 0
    OK 17 33 18 0 0
    OK 17 50 16 0 0

These are raw bytes, i.e. a 32-bit long int, sent once a second and received via wireless. I’m powering the JeeNode with an AA Power Board and standing back during testing, the 220 VAC is now a bit too close for (my) comfort…

The average measurement value with no current is now about 16 x 256 = 4 mV.

The high value when the light has been turned on is about 94 x 256 = 24 mV, a 20 mV increase.

Not bad… but it’s less sensitive than the ACS714 Hall-effect sensor. I didn’t even try it with a 1 W load. This is a far cry from the claimed 1 V/A sensitivity, no doubt because the 50 Hz signal is so far off from the design specs of this SMD current transformer. Saturation effects, or something…

I’ll continue these experiments in the next few days with another current transformer which is designed to work at 50 Hz, as well as with a reversed 220 : 6.3 V PCB transformer. Stay tuned!

Power measurement (ACS)

In Hardware on Sep 14, 2011 at 00:01

The first try I’ll make at measuring AC mains power is with an Allegro ACS714 Hall-effect sensor (this one). I measures ± 5 Amps. It’s a bit expensive for wide-scale use, and it does require hook-up (i.e. AC mains pass-through). Hopefully a non-contact solution will present itself, eventually. For now, it’s a good baseline test.

The circuit provides 2.5 kV isolation, but of course that means nothing when everything is so close that you could easily touch the wrong pin by accident.

Here’s my setup:

Everything is connected to my home-made isolation transformer. Which means grounding adds no safety and to remind me of the risk at all times, I’m using old 2-wire cabling and old ungrounded connectors. Not used anywhere else around here, so a mixup is not possible (those old power plugs won’t fit in today’s grounded sockets). If you look very closely, you can see that the splice is secured with two zip-lock ties. Cables are short so they don’t get tangled up, but long enough to avoid pulling on them.

As I was preparing the setup, I found out that the ACS714 needs 4.5 .. 5.5 V to operate, so the JeeNode + AA Power Board shown here won’t cut it. Oh well, I’ll switch to a 4x EneLoop battery pack (which is 5.2V).

Since I’m only interested in low-power for this test (under 100 W), the output voltage is within range of an ATmega running at 3.3V (the ACS714 output is 185 mV/A, centered around 2.5V).

The initial test worked flawlessly: the light went on! :)

Next, the software. It’s always the software which requires most work.

Sensing power consumption

In Hardware on Sep 11, 2011 at 00:01

A small exploration of a circuit which went nowhere…

I’ve been looking for a low-cost way to detect whether an electrical appliance is drawing current. There would be several uses for that, from power-saving master/slave power strips, to helping figuring out what’s going on in the house by measuring the central meter, as I’m doing already.

Here’s my original (naïve) line of thought:

optocouplers are a great way to stay out of AC mains electrical trouble
many units will still work with currents down to well under 1 mA
all I want is detection – is a device ON or OFF?
the rest can be done with JeeNodes, wirelessly, as usual

Here’s the (pretty silly) first step, in series between power outlet and appliance:

JC's Doodles, page 11.png

A resistor to limit the current, and the opto-coupler to “light up” and produce a signal in a galvanically isolated manner. But don’t get your hopes up, this setup definitely won’t work!

First of all, the appliance will stop working, if the resistor is in the 100 kΩ range.
With resistance values much lower, the resistor will become a heater and self-destruct.
Besides, even a 100 W load will draw 0.5 A or so… way too much for the LED.
There’s also a small problem with the voltage being AC, not DC, but that’s easily solved with a diode.

It’s a pretty useful mental exercise to work through this and understand how voltage, current, and power interact. If you’re totally lost, you could check out this series of posts and this link.

Sooo… could this approach be made to work?

In this case, an indirect demonstration that it can’t possibly work is actually easier to argue: suppose there were a circuit with the opto-coupler’s LED in series between outlet and load. It only needs to cause a voltage drop of about 1.5V to get the IR led inside to light up. Now suppose the load draws 1000 W, i.e. nearly 5 A. Big problem: (due to P = E x I) the power consumed by the opto-coupler would be 7.5 W … an excessive amount of heat for such a tiny device (apart from the sheer waste!).

Even some form of magical “power reduction” would be tricky, since I do need to detect the power-OFF case, i.e. power levels down to perhaps 0.5 W of standby power consumption for modern appliances (some even less). For 220V, 0.5 W corresponds to an average current of only 2.2 mA.

Maybe there’s a clever way to do this, but I haven’t found it. Something with a MOSFET, mostly conducting, but opening up just a little perhaps 1000x per second, to very briefly allow the LED in an opto-coupler to detect the current (with an inductor to throttle it). Heck, an ATtiny could be programmed to drive that MOSFET, but now it’s all becoming an active circuit, which needs power, several components, etc.

The trouble with AC mains is those extremes – on the one hand you need decent sensitivity, on the other you need to deal with peak loads of perhaps 2000 W, with their hefty currents, and where heat can become a major issue. We’re talking about power levels ranging over more than three orders of magnitude!

Of course there is the current transformer. But those are a bit too expensive to use all over the place.

Another option would be to use a regular transformer in reverse, as in this article. With a little 220 => 6.3V transformer, the ratio would be 35:1. With 5A max, a 0.1 Ω resistor would have 0.5 W of heat loss and create a 0.5V difference, amplified up to 17.5 V. For a 2.2 mA “off” current (0.5 W standby), that voltage would drop to 7.7 mV, which is probably too low to measure reliably with the ATmega ADC. Still.. might be worth a try.

An interesting low-cost sensor is based on the Hall-effect to detect magnetic fields. Because wherever there is alternating current, there is a magnetic field.

With hall-effect sensors, the problem is again at the low end. Keep in mind that the goal is reliable detection of current, not measurement. Now, you could increase the sensitivity by increasing the intensity of the magnetic field – i.e. by creating a coil around the sensor, for example. Trouble is: since those wires need to also handle large power consumption levels, they are by necessity fairly thick. Thick wires make lousy coils, and are impossible to get close to the sensor.

There are other ways. Such as measuring light levels, in case of a lamp. Or heat in case of a TV (would be a bit sluggish). Or vibration in case of a fridge.

Maybe a hand-made 100-turn current transformer would work? That’s a matter of winding some thin enameled wire around a single mains-carrying insulated copper wire.

Hm… might give that a try.

The challenge is to find something reasonably universal, which does not require a direct galvanic connection to AC mains. It seems so silly: an ATmega can detect nanowatt levels of energy, yet somehow there is no practical path from AC power ON/OFF detection to that ATmega?

PS. A related (and more difficult) problem is “stealing” some ambient magnetic energy to power a JeeNode. You don’t need much while it’s asleep, but transmitting even just one tiny packet is another story.

▶ View 24 Comments

Low-end Linux

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

It’d be neat to use a very low-end embedded Linux system for running (part of) my home monitoring and automation system.

I’ve mentioned the BifferBoard before, twice in fact. With a BogoMips rating of 56, it’s as low end as it gets.

Unlike most low-end boards, which are ARM-based, the BifferBoard runs on a “S3282/CodeTek” which is 486SX-compatible, so many 32-bit Linux binaries will work as is. I’m running a fairly standard Debian Lenny on mine, very convenient. It needs 650 Mb, including a full gcc build chain.

IMO, there’s great value in such a low-power system. For one, with just 30 MB RAM and no swap support on the standard setup, you’re really forced to look at memory consumption. Running out of memory will cause a program to be terminated (it can easily be restarted with a watchdog shell script).

The other feature this board does not have is hardware floating point. It’s all emulated. Here’s what that means:

  $ ssh biffie jeemon tcl 'time {/ 1 2} 1000'
  36.735 microseconds per iteration
  $ ssh biffie jeemon tcl 'time {/ 1.0 2.0} 1000'
  336.717 microseconds per iteration
  $

Versus my lowly 1.4 GHz laptop:

  $ jeemon tcl 'time {/ 1 2} 1000'
  0.569055 microseconds per iteration
  $ jeemon tcl 'time {/ 1.0 2.0} 1000'
  0.546295 microseconds per iteration
  $

As you can see, it’s a whole different ballgame :)

Anyway, let’s try and get a bit more substantial code running on this setup. I’ll use JeeMon, since I’ve recently been doing some work to combine round-robin data storage with graphing in the browser:

Screen Shot 2011 09 07 at 17 10 29

The graphs on the right are 1-day / 1-week / and 2-month previews, but let’s ignore the actual graphs since there is not enough test data for them to be meaningful.

What I wanted to see, is whether this would run on a BifferBoard. Here’s my first attempt:

Screen Shot 2011 09 07 at 17 03 14

Whoops… out of memory. Not only that, it’s taking ages to generate the JSON data for each Ajax request coming from the browser. Here’s my laptop for comparison:

Screen Shot 2011 09 07 at 16 59 31

The laptop is generating data for 5 graphs (one is off-screen) in a fraction of a second, while the BifferBoard needs several minutes (before running out of memory).

Good. Because with such a slow process, it’s much easier to find the bottlenecks. It turned out to be in the round-robin storage module I recently coded (using a USB stick as mass storage device doesn’t help either). Two hours later, things started working a lot better:

Screen Shot 2011 09 07 at 19 02 40

Progress! Still too slow for practical use… at least it’s no longer running out of memory. But although the BifferBoard is no longer maxed out, it is struggling – here’s a “vmstat 3” display, with one line per 3s:

Screen Shot 2011 09 07 at 20 13 16

I now realize that with my current settings, all data streams are aggregated to a larger “bucket” every 5 minutes. This probably explains these periods of 100% CPU activity.

Memory use is reasonable (with all interactive SSH shells logged out):

  $ ssh biffie free
               total       used       free     shared    buffers     cached
  Mem:         30000      28248       1752          0        444       8040
  -/+ buffers/cache:      19764      10236
  Swap:            0          0          0
  $

There’s still a lot of floating point activity going on, because I store all data points as 64-bit doubles. This needs to be improved at some point. My hunch is that it will take care of the performance problem. But it’s nice to see that JeeMon can cope (sort of), even in such a very limited environment. A BifferBoard with JeeMon will definitely be sufficient as “slave” controller in a larger configuration.

Power consumption is pretty neat: 2.85 W under full load and 2.20 W when idle. Measured at the AC outlet, i.e. including 5V power supply losses.

There are numerous low-end Linux systems out there. If the above can be made to work reasonably well, then it should work with most of them… ARM- / PPC- / x86-based, whatever.

For now, that BifferBoard is a good way to keep me honest, and on edge :)

Re-using an LCD screen

In Hardware on Sep 5, 2011 at 00:01

This summer, someone gave me an old laptop which had stopped working. I couldn’t figure out what was wrong, so I decided to take it apart. Hehehe…

One of the parts coming out was a 15″ TFT LCD screen. Nothing stellar – 1280×800 – but still.

It turns out that there are several ways to get such a thing going again (thank you, Google). I ended up buying a DPMI/VGA interface board on eBay, complete with high-voltage supply and cables. It worked right out of the box:

DSC 2618

The display is not running at its native resolution here, because I couldn’t figure out how to force Win2000 to a specific screen resolution, but with Linux it did, so all is well.

I’d like to build a small & flat enclosure for this, hook it up to the Mac Mini, and hang it on the wall. Preferably with a distance sensor to control the whole thing so it only turns on when someone is standing directly in front of it. No need for a touch screen, a few buttons would be fine as home status display.

The whole combination runs off 12V, drawing 10 Watt when fully on and 0.3 W while asleep.

Yeay, reuse is fun!

The beat goes on

In Hardware on Sep 4, 2011 at 00:01

Today, a milestone was reached:

    $ jeemon examples/driver-demo/
    15:45:01.975 RF12demo config usb-A700fdxv RF12-868.5
    reading:RF12-868.5.3:radioBlip:ping = 493295
    reading:RF12-868.5.3:radioBlip:age = 365
    ^C

That’s nearly half a million packets, one every 64 seconds, all on a single LiPo battery charge:

Screen Shot 2011 09 03 at 15 51 53

The setup is very simple. A 1300 mAh LiPo battery (I just picked one up in a camera shop with a convenient size), attached to a JeeNode USB:

At 3.94 V the battery is still far from dead, so it’ll probably stay alive for quite a bit longer…

The sketch running on this node is:

Screen Shot 2011 09 03 at 16 14 28

(looks like I had lost the low-power stuff in the “radioBlip” code, now fixed on GitHub)

Lots of low-power nodes are holding out nicely here at JeeLabs, by the way. There are about half a dozen permanent room nodes, and with the latest roomNode sketch they just keep going. Some are running on 3x AA rechargeable EneLoop batteries, others use 3x AAA with even less juice, and all of them have been running with just a single charge since the beginning of this year.

ISP, RBBB

The Murphy brothers

In Hardware on Sep 2, 2011 at 00:01

Let’s get this out of the way first…

About a week ago, it came to my attention that Mr. Murphy has been having a good time again, this time with the RBBB board by Modern Device.

Turns out that some units were accidentally shipped with a 3.3V regulator instead of a 5V unit:

RBBB regulator mixup

The effect is not dramatic, in the sense that the RBBB will work just fine with either regulator. But as soon as you start hooking up stuff, you may get weird behavior. The worst case would be to hook up stuff with its own 5V power supply, since that means the attached device could potentially put a higher voltage on the IO pins than the 3.3V supply voltage of the ATmega.

So how do we fix this? Well, if you’ve got an RBBB from JeeLabs in the past months (probably anywhere from just before the summer break until now), please check the regulator voltage. Let me know if it’s the wrong one and I’ll send replacement 5V regulators.

(Note that the RBBB’s L4931 and the JeeNode’s MCP1702 regulators have different pinouts!)

As for the current batch of RBBB’s I still have here, the store gets a little bit more complicated: these are all wrapped and sealed by Modern Device, and the bags are too thick to be able to read that lettering on the regulator. I’ve opened up almost a dozen bags and found a few 3.3V units in the older batch, and none in the newer one. There’s not much more I can do than replace those I know about, and repeat that offer to replace any regulators you come across yourself.

FWIW, I suspect that this problem is gone by now.

But there’s a second member in the Murphy family, still dropping by occasionally, it seems…

As you may remember, I switched all SMD-based ATmega328’s over to use OptiBoot a couple of months ago. As it turns out, the standard OptiBoot loader included with the Arduino IDE 0022 isn’t reliable under Windows – my hunch is that there’s some timing problem with the combination OptiBoot <=> FTDI USB interface. It appears to be solved by changing the watchdog timer from 500ms to 1s, see the discussions here and here.

There’s now a new Arduino IDE 1.0beta2 out, and I’m getting some signals that we’re not alone with these OptiBoot troubles, so for now I’ll just stick to that modified 1s OptiBoot code which I’ve been using for several months now, and I’ll hold off switching to OptiBoot on the DIP version of the ATmega328, as used in JeeNode kits. Failing bootstraps are no fun if you don’t have an ISP programmer and no time to try out various tricks to emulate one.

In a nutshell: all SMD chips from JeeLabs use the 1s OptiBoot (which runs at 115,200 baud), while all the DIP chips get pre-loaded with the Duemilanove bootstrap (which runs at 57,600 baud).

I’ll revisit this when the dust settles.

Onwards!

All about Easy Electrons

In Hardware on Jun 29, 2011 at 00:01

Long-time readers will probably remember the Easy Electrons series of posts on this weblog – as the first post says: “a series which will cover various aspects of electronics from the viewpoint of a technology enthusiast with a non-electronics background.”

There have been 14 posts so far, covering everything from resistors and capacitors, to the basics of power consumption and heat, as well as diodes, transistors, and MOSFETs.

It’s been great fun to write, and the response to it has been absolutely overwhelming. Never did I expect that so many people would enjoy reading about these topics…

I tried to write these posts to convey my intuition on most of the topics covered. There’s a lot of theory out there on electronics, with as much maths and physics as you’re willing to muster, even. But none of that is really needed, if all you want is hook up some circuits with say a few sensors, some display, and a microcontroller such as the JeeNode, Arduino, or chipKIT.

So the point of the Easy Electrons series was really to try and bring across that essential understanding which can help avoid damaging stuff. It should after all be fun…

I say “was”, because I’ve decided to stop writing Easy Electrons installments. First of all, there’s a summer break coming up, but more importantly, I don’t really want to go too deeply into topics which are well covered by other sites on the web.

There are plenty of getting started sites, but the one I’d like to highlight is All About Circuits – it’s a goldmine of information, and it has a very active discussion forum area. Best of all, it’s not aligned to any particular supplier (as far as I can tell), so I would expect the information in it to be generally useful (and much broader and deeper than what I could possibly come up with). There are some ads on the site – to which I’m usually allergic, but they tend to be quite small and unobtrusive, IMO.

There’s bound to be info for everyone. I particularly liked Volume IV of their extensive documentation – filled with interesting experiments, with all the details and background info one could possibly need.

If all you want is to get started in electronics, perhaps because you have a computer software background, then skimming through the first 5 chapters, such as this section on voltage and current, ought to go a long way.

I’m not ruling out new posts which might still get tagged as part of the Easy Electrons series, but don’t wait for full-scale coverage of all electronics aspects one could think of. There’s no point duplicating what others are doing, and doing better and more thoroughly, in fact.

I’m delighted that there are such good resources, freely available to anyone with an internet connection. Would have loved to have had that access as a teenager!

So now I can focus my energy on exploring and blogging about all the new adventures ahead :)

JeeNode with a 32 KHz crystal

In AVR, Hardware on Jun 28, 2011 at 00:01

Another experiment: running a JeeNode on its internal 8 MHz RC clock while using the crystal input to run timer 2 as an RTC. This would allow going into a very low-power mode while still maintaining a much more accurate sense of time.

To this end, I modified a JeeNode SMD, by replacing the 16 MHz resonator with a 32 KHz crystal:

Dsc 2599

I didn’t even bother adding capacitors, these are probably not needed with this crystal (same as on the RTC Plug) since there is probably enough parasitic capacitance already.

The tricky part is the code, since the ATmega is now running in a not-so-Arduino-like mode. Could almost have used OptiBoot with this setup, but the only internal RC clock build for it is the LilyPad, which has an ATmega168.

I ended up using the ISP programmer. IOW, I now compile for “LilyPad w/ 328” and then bypass the bootstrap and serial-upload. Less convenient, but it works.

Here’s a quick test sketch which writes a dot on the serial line exactly once a second:

Screen Shot 2011 06 24 at 15.51.49

So this setup is working. It draws 4.10 ma, consistent with the recent current measurements: slightly less than with the 16 MHz resonator pre-scaled by two.

In idle mode, current use drops to 1.71 mA, not bad!

Now let’s power down with just the timer running as real time clock. There’s a special “power save” mode which does just that. The difference is that timer 0 will now be off, so there won’t be interrupts waking up the ATmega every 1024 µs (as side-effect, the millis() function will start to lose track of time):

Screen Shot 2011 06 24 at 16.15.04

A small adjustment is needed to make sure the serial port is finished before we go into low-power mode, hence the call to delay(3).

Hm, power consumption is still 0.67 mA – quite a bit, given that we’re really powering down most of the time.

Ah, wait. I forgot to turn off the radio. Doing that brings the reading down to 0.15 mA – and I forgot to turn off the ADC and other sub-systems. Now we’re down to … 0.05 mA, while still printing dots:

Screen Shot 2011 06 24 at 16.39.15

Note that these 1 second interrupts are very accurately timed, more so even than with the standard 16 MHz resonator. This could be used to perform time-domain tricks on the wireless side, i.e. waking up just in time whenever a “scheduled” packet is expected to come in – as described in yesterday’s post.

There’s probably more left to try. The delay is running on full power, waiting for the serial output to clear the USART. It could be done while in idle mode, for example. Anyway… that entire delay becomes superfluous when we stop sending out debugging output over the serial port.

So there you have it – a JeeNode running at ≈ 8 MHz, with a precise 32,768 Hz pulse feeding timer 2, in a way which supports low-power sketches while maintaining an accurate sense of time.

Wanna make a clock?

JeeLink, JeeNode, Techniques, Network

Time-controlled transmissions

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

Receiving data on remote battery-powered JeeNodes is a bit of a dilemma: you can’t just leave the receiver on, because it’ll quickly drain the battery. Compare this to sending, where nodes can easily run for months on end.

The difference is that with a remote node initiating all transmissions, it really only has to enable the RFM12B wireless module very briefly. With a 12..23 mA current drain, brevity matters!

So how do you get data from a central node, to remote and power-starved nodes?

One way is to poll: let the remote node ask for data, and return that data in an ACK packet as soon as asked. This will indeed work, and is probably the easiest way to implement that return data path towards remote nodes. One drawback is that if all nodes start polling a lot, the band may become overloaded and there will be more collisions.

Another approach is to agree on when to communicate. So now, the receiver again “polls” the airwaves, but now it tracks real time and knows when transmissions for it might occur. This is more complex, because it requires the transmitter(s) and receiver(s) to be in sync, and to stay in sync over time.

Note that both approaches imply a difficult trade-off between power consumption and responsiveness. Maximum responsiveness requires leaving the receiver on at all times – which just isn’t an option. But suppose we were able to stay in sync within 1 ms on both sides. The receiver would then only have to start 1 ms early, and wait up to 2 ms for a packet to come in. If it does this once a second, then it would still be on just 0.2% of the time, i.e. a 500-fold power saving.

Let’s try this out. Here’s the timedRecv.pde sketch (now in the RF12 library):

Screen Shot 2011 06 24 at 20.54.37

It listens for incoming packets, then goes into low-power mode for 2 seconds, then it starts listening again. The essential trick is to report two values as ACK to the sender: the time the receiver started listening (relative to that receiver’s notion of time), and the number of milliseconds it had to wait for the packet to arrive.

There’s no actual data processing – I’m just interested in the syncing bit here.

The sender side is in the timedSend.pde sketch:

Screen Shot 2011 06 24 at 20.58.17

This one tries to send a new packet each time the receiver is listening. If done right, the receiver will wake up at just the right time, and then go to sleep again. The ACK we get back in the sender contains valuable information, because it lets us see how accurate our timing was.

Here’s what I get when sending a new packet exactly 2,096 milliseconds after an ACK comes in:

Screen Shot 2011 06 24 at 20.39.33

Not bad, one ack for each packet sent out, and the receiver only has to wait about 6 milliseconds with its wireless receiver powered up. I’ve let it run for 15 minutes, and it didn’t miss a beat.

For some reason, send times need to be ≈ 2.1 s instead of the expected 2.0 s.

Now let’s try with 2,095 milliseconds:

Screen Shot 2011 06 24 at 20.37.17

Something strange is happening: there’s consistently 1 missed packet for each 5 successful ones!

My hunch is that there’s an interaction with the watchdog timer on the receiver end, which is used to power down for 2000 milliseconds. I suspect that when you ask it to run for 16 ms (the miminum), then it won’t actually synchronize its timer, but will fit the request into what is essentially a free-running counter.

There may also be some unforeseen interaction due to the ACKs which get sent back, i.e. there’s a complete round-trip involved in the above mechanism

Hmm… this will need further analysis.

I’m using a standard JeeNode on the receiving end, i.e. running at 16 MHz with a ceramic resonator (specs say it’s 0.5% accurate). On the sender side, where timing is much more important, I’m using a JeeLink which conveniently has an accurate 16 MHz crystal (specs say it’s 10 ppm, i.e. 0.001% accurate).

But still – even this simple example illustrates how a remote can receive data while keeping its wireless module off more than 99% of the time.

Current measurements

In AVR, Hardware on Jun 26, 2011 at 00:01

Wanted to check a few things w.r.t. current consumption of a JeeNode. The old way of doing this was a bit inconvenient, so I made a new test setup:

Dsc 2597

(old one on the left, new one on the right)

Sturdier, no need to disconnect the multimeter to short it out, and most importantly: high-side current sensing! That’s quite important, because multimeters can add a small voltage drop when used in current measurement mode, and that voltage drop will affect the serial I/O on the FTDI pins when placed in the GND line. Silly me, should have been on the PWR line all along!

The back side of the new connector is trivial:

Dsc 2598

The multimeter attaches to the top pins, bent apart for easy connection. The jumper shorts it out so this contraption can still be used when the multimeter is turned off.

Ok, time for some simple measurements:

ATmega full speed, doing nothing: 6.84 mA
ATmega full speed, with the RFM12B receiver on: 18.42 mA
ATmega powered down, only the RFM12B receiver on: 11.53 mA
ATmega full speed, with the RFM12B tranmitter on: 29.92 mA

Idle mode is a simple way to reduce power consumption without changing the logic of the code. It turns the MPU off until an interrupt occurs. Basically, you’re telling it “I’ve got nothing to do until something new happens”. It’s a pretty safe change, and well worth doing in any idle loop which isn’t directly polling I/O pins. The ATmega’s current consumption is slashed by more than half:

ATmega in idle mode, doing nothing: 2.80 mA

Another way to reduce power consumption, is to slow down the clock at which everything takes place, by setting the “clock pre-scaler”:

ATmega @ 16 MHz, doing nothing: 6.84 mA (as before)
ATmega @ 8 MHz, doing nothing: 4.35 mA
ATmega @ 4 MHz, doing nothing: 2.96 mA
ATmega @ 2 MHz, doing nothing: 2.02 mA
ATmega @ 1 MHz, doing nothing: 1.55 mA
ATmega @ 500 KHz, doing nothing: 1.28 mA
ATmega @ 250 KHz, doing nothing: 1.16 mA
ATmega @ 125 KHz, doing nothing: 1.09 mA
ATmega @ 62.5 KHz, doing nothing: 1.06 mA

Diminishing returns, clearly. Note that lowering the system clock in this way is not necessarily the best choice – getting something done N times faster and then powering down completely might be more efficient (see below).

One thing to watch out for: don’t go below 4 Mhz if you want to be able to use the RFM12B, or the processor will be too slow to process each byte.

When combining this, we get:

ATmega @ 4 MHz in idle mode, doing nothing: 1.48 mA
ATmega @ 62.5 KHz in idle mode, doing nothing: 1.03 mA

The advantage of this approach is that the clock is still running on the 16 MHz resonator (which probably draws most of that remaining current), so you’re still able to keep track of time – just more slowly.

A different approach is to go into real low power mode, and use the watchdog to get back out of this comatose state. The watch dog timer is less accurate, but depending on your application that may not be an issue.

Here’s the current consumption with the ATmega alternately in full speed and in power down mode:

ATmega 16 ms @ 16 MHz / 16 ms powered down, doing nothing: 3.49 mA
ATmega 8 ms @ 16 MHz / 16 ms powered down, doing nothing: 2.31 mA
ATmega 4 ms @ 16 MHz / 16 ms powered down, doing nothing: 1.39 mA
ATmega 2 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.80 mA
ATmega 1 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.46 mA

That last one does about the same amount of work as when running constantly @ 1 MHz, but with a third of the power consumption. Here is the corresponding sketch:

Screen Shot 2011 06 24 at 13.45.56

And it will continues to scale downward:

ATmega 100 µs @ 16 MHz / 16 ms powered down, doing nothing: 90.4 µA

Which still represents 100,000 active processor cycles per second…

And lastly, let’s take it into power down and run for just 1 ms per second, i.e. 0.1% of the time. I can’t measure this with the multimeter, because the power use jumps up every second, but the comatose period draws a mere 6.8 µA, which is consistent with what has been reported several times before (the watchdog is still active, and so is the brown-out detector).

Desktop power supply

In Hardware on Jun 25, 2011 at 00:01

Apart from a variable lab suppy (mine does 0..15V @ 0..3A), I’ve often wanted a simpler supply with just a few fixed voltages and say 500 mA. For experimentation, a weak supply which collapses under too much load is in fact better, because it can help avoid damage (which is almost always thermal and due to large currents).

Today, I decided to put something together, using parts which have been lying around here for some time.

It starts with an encapsulated switching AC/DC converter. I used a Traco 04115, i.e. 15V @ 4W. That addresses the AC mains side of things and limits the power involved in the circuit. Then I added 4 adjustable switching power supplies, which I got off eBay last year:

Dsc 2594

They are all running in parallel, using 15V as input. You’re looking at the bottom side of the box, BTW – the bottom plate of this particular box has nice little rubber feet.

The hardest part was deciding how to bring the power out of the box. I didn’t want large jacks – this thing is a dekstop power supply! But leaving wires with various valotages coming out and dangling all over the desk is also not such a good idea.

The solution I chose, was to bring out everything together via a 40 cm piece of 6-core cable:

Dsc 2595

The cable is squeezed behind one of the enclosure’s inner posts for strain relief (the AC mains cable has a knot in it for the same reason).

At the other end sits this thing – ready to take lots of jumper wires:

Dsc 2596

I still need to figure out how to attach labels to it. This is the pinout (with the cable pointing up):

Screen Shot 2011 06 23 at 18.34.21

No idea how yet, but it would be best if this were placed as label on top of the experimenter’s board in the middle, hiding the solder joints and clearly indicating which pin is what.

As it turns out, this power supply is considerably more powerful than I expected. The 15 V AC/DC converter will in fact go up to twice its rated power, i.e. over 500 mA, before the short-circuit protection sets in.

Due to the nature of switching regulators, the other voltages provide even more current: I was able to pull well over 1A continuously from the 3.3V supply. Although at those levels, the voltage did drop to 3.1 V.

Efficiency was not a primary goal, since this desktop supply is relatively low-power anyway, but the entire setup draws 0.7 W unloaded, and about 10 W when pulling 15V @ 500 mA out of it. I don’t expect to be loading this power supply down much, let alone getting into heat problems, even though the box is completely closed.

Oh, and in case you hadn’t noticed – another baby step in dealing with AC mains…

Alternating current

In Hardware on Jun 24, 2011 at 00:01

I’m not only interested in high-power AC mains switching, but also in the low-voltage / low-power side of things. So here’s another little step towards experimenting with that:

Dsc 2592

A simple 6V @ 58 mA transformer, soldered onto experimenter’s board and wrapped in a couple of heat-shrink layers. What comes out is a safe 6V @ 50 Hz signal.

Eh…

Open

Make that over 15 VAC (half the peak-to-peak value) and nowhere near a clean sinewave!

I suspect that this is what you’ll often get with low-grade / low-cost transformers. Even without any load, the transformer draws about 1.1 W and heats up to around 50°C, yuck!

Actually, the shape isn’t as bad as it looks. If you look carefully, you can see that it’s more or less one harmonic superimposed on the main sine wave. I won’t go into details (and risk exposing my ignorance), but that’s where Fourier transforms come in. The idea is that any repetitive waveform can be constructed from a set of sinewaves at a multiple of the original frequency (these are the harmonics, same as in music). By calculating the Fourier transform, you can decompose any repetitive waveform back into a sum of those basic waves.

Cool, now I have an excuse to try out the FFT feature on my oscilloscope!

Fft

The purple line shows a graph of the intensities of the different harmonics. It’s not really a continuous graph, since FFT is a discrete algorithm, but what it does show is that there are harmonics. If the input were a pure sine wave, there would only be a single peak, at the frequency of the sine wave itself. But in this example there’s a very strong second peak. Which produces this severely distorted waveform.

Here’s a better transformer for comparison (rated at 17 VAC):

Better

You can see that the harmonics are much weaker. Which translates to a much cleaner sine wave. Well, up to a point, anyway.

One reason why these voltages are much higher than the ratings, is that AC is specified as average – after all, the voltage is changing all the time, so it really is a matter of definition how you measure these values. For a sine wave, the average (or RMS in techno-speak) is about 0.7 times the peak value, or equivalently: the peak value is about 1.4 times the rated voltage.

For 6V, we should get 6 x 1.4 x 2 = 16.8 Vpp (a far cry from the above measurement!), and for 17V, the peak voltage should be 17 x 1.4 x 2 = 47.6 Vpp.

In both cases, the measured value is higher, perhaps because this is measured at no load. Although that first transformer really is way off.

Welcome to the world of alternating current, analog effects, distortions, and conversion losses!

TRIAC trials

In Hardware on Jun 23, 2011 at 00:01

To start some tests with TRIAC control of 220V AC mains devices, I’ve built a trivial setup – based on the S216S02 TRIAC, which goes up to 16A and includes a built-in opto-isolator and zero-crossing detector. That last part makes it unfit for dimming (that requires phase-controlled switching) but it should be fine for turning lights and heaters on and off.

The circuit is very simple, but I really wanted to have something that wouldn’t expose me to 220V no matter how much I start goofing around. Here’s the basic idea:

Dsc 2556

There’s a small heatsink on the TRIAC, since the datasheet says that it’ll only go up to 2A without one.

Now just Splice, Solder, and Seal:

Dsc 2558

And voilá – nothing fancy:

Dsc 2557

Trivial stuff, I added a 220 Ω resistor in series with the LED, making it switch reliably on 3.3V, with under 10 mA current, i.e. fine for an ATmega.

The ends of the power wire are attached to a plug and a receptacle, respectively – making this an extension cord.

Baby steps, as I overcome my fear of the ~~unknown~~, eh I mean 220V AC mains…

JeePlug, Power

Latching relays

In Hardware on Jun 22, 2011 at 00:01

The traditional relay looks like this (thank you Wikipedia):

Relay

A spring pulls on the vertical lever on the right (above its pivot), keeping the contact pushed agains the “NC” contact – hence the name: normally closed.

An electromagnet can pull the (iron) lever towards the left, against the “NO” contact – i.e. normally open, but closed once the electromagnet is powered.

Great invention. Perhaps the first example of electric amplification: using a small amount of electricity to switch a potentially much larger voltage or current.

For ultra-low power devices, ordinary relays have a drawback: you have to keep them energized as long as you want to keep the “NO” contact closed. With the Relay Plug, things are no different – the latest relays used on it have a coil resistance of about 125 Ω, and each of the two requires 40 mA @ 5V to stay “on”:

Dsc 2591

That amount of current consumption is not so convenient with batteries – when turned on, they wouldn’t last more than a day or two on a bunch of AA batteries.

Fortunately there’s an alternative, called a “bi-stable” or latching relay. It uses two coils to move that lever back and forth, with weak magnets in the relay set up in such a way that they’ll stay in place without using a spring as counter-force.

The benefit is that latching relays don’t need any power to stay in their current state (be it open or closed), you only need to give them a pulse to change their state from ON to OFF or from OFF to ON.

There are actually two types of latching relays:

dual coil, usually with a common pin which should be tied to ground
single coil, where changing the state is done by applying reverse voltages

Most dual coil latching relays can also be used in single-coil mode, by simply leaving that common pin floating.

In principle, the circuitry for a dual-coil latching relay is simple: you just need two relay drivers and then turn one or the other on briefly to make the relay change its state. The point being that you only need to pulse them very briefly, 10..100 msec should be enough.

Unfortunately, the Relay Plug isn’t usable for bi-stable relays, because it assumes a common PWR pin, not GND. It turns out that these relays are polarized. Thinking about this a bit more, this is actually quite logical: the force of the little latching magnet(s) need to be overcome with a magnetic field with a specific opposite orientation.

But there’s a surprising way out…

With single-coil plugs, the trick is to let current flow in different directions to set or reset the relay. IOW, either connect one pin to PWR and the other to GND (briefly), or vice versa. Hm, that sounds awfully like running an electric motor forwards or backward…

Now here’s the trick: instead of a Relay Plug, use the DC Motor Plug!

Dsc 2310 Large

It contains two H-Bridges which are intended to control two small DC motors (or one stepper motor), allowing them to run in either direction.

You even get 4 additional general-purpose I/O pins thrown in…

Now, instead of hooking up a motor, just hook up a relay, and only pulse the power briefly (by making both sides GND or PWR the rest of the time). With as added benefit that the DC Motor Plug will support two latching relays, and being an I2C device, it’ll also allow daisy-chaining with other I2C plugs.

Note that the chips used on the DC Motor Plug require at least 4.5V to operate, according to the data sheet. Maybe a slightly lower voltage will work – I haven’t tried it.

Update – DC Motor Plug is confirmed to work. The 5V relays I was testing this with appear to switch reliably with pulses down to 4 ms, using this test code (modified from the dcmotor_demo.pde) sketch:

Screen Shot 2011 06 22 at 16.33.58

MCP1702 current draw

In Hardware on Jun 21, 2011 at 00:01

The MCP1702 used in JeeNodes and other circuits here at JeeLabs is a nifty little voltage regulator. It’s not particularly good for high voltages (limited to about 13V), but it has a very low idle current. That’s very useful for low-power circuits, especially when trying to get months or even years of service out of one set of batteries.

Let’s find out how it’s performing. I’ve set up this little test circuit:

Screen Shot 2011 06 20 at 00.39.11

Well, it’s not really a test circuit at all – it’s in fact exactly what you need to use one of these things.

Putting 5V on the input (Vin), and leaving it a few minutes to settle, gives me a reading of 2.2 µA. Great, just what the specs say. It doesn’t really go up much with input voltage: 2.8 µA @ 12V. This is at no load.

With a 10 kΩ load, current draw rises to 338.1 µA, i.e. 330 µA for the resistor and about 8.1 µA for the regulator (assuming perfect calibration). That’s only 6 µA more, i.e. about 2% of the load.

Now let’s take the input voltage down, and see how this “low-drop” regulator behaves:

5.0 V -> 2.2 µA
4.0 V -> 2.2 µA
3.5 V -> 2.1 µA
3.3 V -> 2.1 µA
3.2 V -> 90.4 µA
3.1 V -> 84.1 µA
3.0 V -> 78.2 µA

Whoa… it sure doesn’t like being fed less voltage than it needs to supply a regulated output of 3.3V! The change is quite pronounced between 3.30 and 3.28V (I couldn’t get my power supply knob to adjust any more accurately).

For yesterday’s AA power board discussion that’s actually bad news, because it means that when the supply drops a mere 20 mV, it could cause the regulator to start wasting a fair amount of current (relatively speaking).

Let’s try something different: no power on Vin, but power on Vout instead.

This simulates connecting a battery to the +3V pin, and bypassing the MCP1702 voltage regulator altogether. Evidently, it’s not a good idea putting much more than 3.3V on there, since now we’re reverse feeding the regulator, something not all regulators are happy with:

3.40 V -> 1000 µA
3.35 V -> 500 µA
3.30 V -> 90 µA
3.25 V -> 90 µA
3.20 V -> 90 µA
3.10 V -> 84 µA

The conclusion seems to be: when using the AA Power Board in combination with a JeeNode, it might be better in certain cases to omit the regulator altogether if you’re aiming for minimal power consumption!

It’s not enough to short the regulator’s Vin and Vout, it really has to be taken out of the circuit. Fortunately, you don’t have to disconnect all three pins – just disconnect the ground pin (on the JeeNode v4..v6, that’s the one closest to the FTDI connector).

But if all you want to do is power the whole thing from some power source over 3.3V, such as a 3x AA battery pack or a LiPo battery, then all is fine… you’ll see that ultra-low 2.2 µA figure – as intended in this design.

Just beware of low voltages: weird things do happen!

One last refinement

In Hardware on Jun 14, 2011 at 00:01

With the high-side DC power switch circuit working, there’s room to tweak things just a teeny bit further.

Summary: we’re switching DC power on and off through a MOSFET, and measuring the voltage drop across that same MOSFET with a bit of amplification to get better readout sensitivity.

Let’s add one more feature: the ability to detect whether a disk is connected. But first, the complete schematic:

Screen Shot 2011 06 06 at 19.06.57

The R1 resistor protects the op-amp from negative voltages, which occur when the MOSFET (Q1) is open and a device has been attached.

R2 and R3 put the op-amp in 11x amplification mode, referenced to VCC.

The C1 capacitor was added to smooth out the analog readings a bit (R1 + C1 form a low-pass filter).

The R5 resistor makes it possible to detect whether there is anything connected to OUT or not: when Q1 is open, R5 creates a pull-up, forcing the “+” side of the op-amp to VCC, unless there’s a device attached. At 1 MΩ, the pull-up is so weak that any device will pull it down to ground potential (keep in mind that Q1 is open). When Q1 is closed, then R5 no longer matters since it gets shorted out.

And lastly, R4 was added as pull-up to avoid a startup glitch as the JeeNode is powering up (i.e. while DIO is still floating). Note that Q1 will conduct when DIO is low.

Here are some readings under different conditions. These are referenced to VCC and converted to mV x 11, i.e. 0.3V under VCC on the op-amp “+” pin reads out as 3300. The three values are low, high, and averages, sampled 50 times over a 5 second interval:

OFF, no device: 0 / 16 / 6
OFF, device switched off: 9 / 48 / 16
OFF, device switched on: 3280 / 3287 / 3280
ON, no device: 0 / 0 / 0
ON, device switched off: 0 / 0 / 0
ON, device switched on, start: 1267 / 2761 / 2348
ON, device switched on, stable: 925 / 1096 / 983

When OFF, there’s a clear difference between a device waiting to get power and no device at all, or one which has been physically switched off. When ON, the readout becomes proportional to the amount of current drawn.

According to the lab power-supply readout, the startup current goes to about 1A, and then once stable it drops back to about 380 mA. The device is a “Green Power” WD 500 Gb hard disk in a no-brand external USB enclosure.

This concludes the “high-side” experiment (all related posts have been collected on the wiki). For a stand-alone setup, it should work fine, but after all this floating ground trickery I’ve come to the conclusion that a COMMON ground setup will be more useful if this were ever to be turned into a plug…

Better resolution

In Hardware on Jun 13, 2011 at 00:01

Yesterday’s high-side DC power control circuit was not able to measure current in a very exact way. Each ADC step is about 3.3mv, and with a 0.1 Ω sense resistor, that translates to 33 mA steps (a bit less, now that the MOSFET turns out to have a slighty higher “on” resistance).

So let’s add an op-amp, to amplify the voltage:

Screen Shot 2011 06 05 at 18.27.58

That’s a standard way to amplify an input voltage by a factor of 11, so a 0.3V input should generate a 3.3V output voltage, which is nicely full-scale for the ATmega’s analog input when running at 3.3V.

But there’s a little mistake in this setup…

The voltage we’re measuring is not a small voltage above 0V, but a small voltage below 3.3V, so we’re in fact feeding the op-amp a voltage between about 3.0V and 3.3V. Amplified by 11 you get… something the op-amp can’t handle when powered from 3.3V, so it’ll simply return 3.3V all the time. Overflow!

Simple to fix though. Instead of tying that lower resistor to ground, we tie it to 3.3V as reference level. And lo and behold, I’m seeing a roughly 11x larger reading with the same setup as yesterday:

Dsc 2563

Now, the input voltage swings between about 2.4V and 3.3V, which is just fine as analog input.

The one thing to watch out for is that we’re sailing very close to the edge, or in op-amp speak: “close to the rail”. This circuit is working with an input voltage which is very close to the +3.3V power supply “rail”, and the output of the op-amp also needs to be able to swing up to that same +3.3V level. This requires some care in selecting a “RRIO” type op-amp (i.e. Rail-to-Rail Input and Output) – the chip I used here is the TLV2373, a dual op-aamp. It does fairly well, but the output can’t quite totally reach 0V or 3.3V. I suspect that most op-amps will have this problem: a tiny residual voltage on both sides of the output swing. Such is life, no op-amp is perfect.

Here is the test sketch I used for this experiment:

Screen Shot 2011 06 05 at 18.22.28

It’s set up for 4 channels, although this circuit only has one. This could be used as the basis for a 2-channel plug, since both the MOSFET and the op-amp are dual-channel.

The output measurements come in via wireless every 5 seconds, and a simple “1,21s” sent out to it (since this is node 21) will turn on the disk.

But this code doesn’t even come close to what I’d really like to implement: it needs to track power use, only switch off when a device is consistently below a preset level (could be different for each device), implement encryption to prevent unauthorized control, store settings in EEPROM, support configurable behavior after power loss, and power devices up in a staggered mode to reduce the load on the power supply, oh my – not there yet!

DC high-side control

In Hardware on Jun 12, 2011 at 00:01

Good news: the “high-side” DC power switch works!

Dsc 2561

On the bottom, a DC jack getting 12V power, on the right a cable with a DC plug powering an external USB disk.

The little board in the middle is sort of a breakout board for two SMD chips: a dual P-MOSFET and a low-drop -3.3V linear voltage regulator to power the JeeNode. The rest is boilerplate stuff, i.e. the JeeNode Experimenter’s Pack, a couple of resistors, and some electrolytic caps.

I’ve only tested it with a load of about 1A, but it should work up to 3A without any problem. What’s also nice is that as a high-side switch, it doesn’t really care what voltage is being used as power supply – anything between 3.5V and 16V should work just fine. That means this can also be used for 5V devices and even with devices powered off 1..4 LiPo-batteries. This simply fits between a DC power plug and its device – convenient!

The current consumption is 21 mA with the ATmega and receiver permanently on. Could easily be lowered a few mA by putting the ATmega in “idle” mode.

The current sensing capabilities are definitely working, but the resistance of the P-MOSFET is not quite 0.1 Ω: with a 390 mA current, I see about 90 mV across the MOSFET, indicating that its internal resistance when driven from a 3.3V JeeNode is more like 0.23 Ω. That’s on the high side (pardon the pun), because this would mean a 1A load will get about 0.23V less out of the power supply than it would with a direct connection – and 0.7V less when drawing 3A. Oh well, it’ll be ok for most devices, cheap power bricks don’t always supply exactly 12V anyway.

The question of course is how consistent this MOSFET resistance is. I suspect that there will be quite a bit of variation across different units. But that’s not necessarily a problem: we don’t really care about absolute currents, we just need to see how the device’s current consumption is relative to full power and idle modes, basically. And we can always calibrate the value with a multimeter or power resistor.

The other weak spot in all this is that the voltage levels measured with this setup are very low, and only cover a few percent of the ADC range. It would be nice to have a bit more resolution there.

Ok, let’s throw an op-amp into the mix…

Controlling the Dimmer Plug

In Hardware, Software on Jun 11, 2011 at 00:01

The Dimmer Plug contains an I2C chip which can control the brightness of up to 16 individual LEDs using hardware PWM. The advantage over the ATmega’s PWM is that there is no limitation to use only the DIO2, DIO3, or IRQ pin (the only ones which support hardware PWM), and of course that 16 individual LEDs can be controlled. In fact, since there are 3 solder jumpers, up to 128 LEDs can be controlled from a single I2C port (by daisy-chaining eight Dimmer Plugs).

Note that the output of the Dimmer Plug is only suited for driving single low-power LEDs with a series resistor. The default setup assumes that these LEDs are tied to 3.3V or 5V. For higher voltages and higher power, additional driver circuitry must be added (transistors, MOSFETs, or the ULN2803 8-wide driver, for example).

Here’s a demo setup:

Dsc 2559

(it’s not visible here, but the test LED has a 470 Ω resistor in series)

Although software PWM can handle more I/O pins, that does place a fairly high load on the ATmega, and the dimming takes place at a much lower frequency, which can be visible to the naked eye (and quite annoying).

The disadvantage of the Dimmer Plug is that it’s based on a fairly complex chip, the PCA9635. I’ve extended the DimmerPlug class in the Ports library a bit further to make it somewhat easier to use.

There’s also an updated dimmer_demo.pde sketch:

It exercises several of the PCA9635’s features:

all 16 output are set to maximum brightness
the “group blink” mode is enabled, using a specified blink frequency and blink duty cycle
the sketch waits 10 seconds, while blinking
the chip is reset to its default “group dimming” mode
then gradually make all channels dim at the same time
and lastly enter a loop, which illustrates how to do per-channel dimming

The setMulti() call takes a start register number, then a variable of arguments 0..255, and then a “-1” value to mark the end. It is shorthand for calling setReg() with successive register values, but more efficient.

The code in loop() does some tricky bit fiddling. Figuring out what it does is left as exercise for the reader, but you can simply ignore it if you don’t care about such trickery. The main thing to note is that indiviudal LEDs can be controlled by setting their corresponding register: dimmer.PWM0, dimmer.PWM1, …, up to dimmer.PWM15.

As you can see, the PCA9635 can control individual outputs, but also several outputs combined via the “group” modes. There are other options, i.e. only controlling a subset of the outputs in group mode, inverting the output signal, using open-collector mode instead of the default totem-pole configuration, and more. You will need to go through the datasheet (PDF) to take full advantage of all this. All registers in the PCA9635 can bet read and written using the getReg() and setReg() calls, respectively.

But for simple uses, the above should be sufficient!

How the JeeNode evolved

In AVR, Hardware on Jun 8, 2011 at 00:01

Thought it might be interesting to put the six JeeNode versions / designs next to each other. It nicely illustrates my progress in learning PCB design, and making some trade-offs and pinout choices over the past 2.5 years:

JeeNode v1:

Jlpcb 002

JeeNode v2:

Jlpcb 003

JeeNode v3:

Jlpcb 018

JeeNode v4:

Jlpcb 044

JeeNode v5:

Jlpcb 105

JeeNode v6:

Jlpcb 128

We’ve come a long way. And I think it’s now time to call this final v6 design… it!

Hard disk power – Mac OSX

In Hardware on Jun 4, 2011 at 00:01

Ok, quick manual test with Mac OSX gives me this pop-up dialog box when powering off a mounted disk:

Screen Shot 2011 05 30 at 11.19.42

The good news is that I can simply leave this message on the screen, since subsequent power cycling won’t create more dialog boxes. The disk mounts as usual, presumably after a sanity check. I’m using a journalled file system, so these checks should be quick and risk-free.

I can live with that on a “headless” server. Key issue will be to only power off when there really is nothing happening on the disk drive.

Network

Server upgrade

In Hardware on Jun 3, 2011 at 00:01

The JeeLabs server is running out of steam…

No, not CPU load:

Screen Shot 2011 05 30 at 12.41.31

It’s idling at under 10%, and drawing 10..15W, exactly as planned.

It’s running out of RAM, all friggin’ 4 Gbytes of ’em!

There are 4 VM’s running so far, of which Drupal gets 768 Mb, and WordPress / Redmine each get 512 Mb. With Parallels, VM’s take up a bit more memory than the raw amount, I suppose there’s some caching going on.

It’s bordering on the ridiculous. The entire WordPress MySQL database is probably not more than a few dozen Mb by now (which in itself is silly, but that’s another story). Yet it needs more than an order of magnitude more RAM to serve it all up as web pages?

I can’t help but think that a fully RAM-based database (with disk image backup) could dramatically reduce the memory needs. But hey, I’m not in the business of redoing the database world – well, not these days anyway ;)

The shining exception is the nginx reverse proxy I use: it runs in 128 Mb, and would probably run just as fine with 64 Mb. It serves lots of static pages, and handles all the re-routing for the rest of the traffic. Brilliant software.

So I bought a fresh pair of 4 Gb memory sticks off eBay (thx, BWired):

Dsc 2541

With the latest Mac Mini models, memory upgrading is – at last – trivial. You might have seen the backSoon server for a few minutes, which is just a JeeNode USB with EtherCard presenting this (dynamic!) web page:

Screen Shot 2011 05 30 at 18.56.17

So there you go. All the JeeLabs .org and .net sites (and a few more) now run with a bit more breathing space. We’re solidly back in the green again:

Screen Shot 2011 05 30 at 19.01.55

Onwards!

Update – Looks like software always expands to consume all available memory: this time it is Apache, btw. I probably need to tweak it, it just grows and grows and grows! (the Drupal VM is now 1.5 Gb)

Screen Shot 2011 06 03 at 11.15.42

JeeNode, Sensors, Power

Hard disk power – bonus

In Hardware on Jun 2, 2011 at 00:01

Ok, there’s now a design for a high-side power switch which can power disk drives up and down at will.

Wait a minute…

You’re not supposed to power down disk drives just like that! It might be in the middle of a disk write. Even journaled disks are at risk, because journaling usually covers meta data (directories, files sizes, allocation maps, etc) … but not the data itself. So an unfortunate power down could leave the disk in an awful state: sure, the diks will be scanned and fixed on startup, but even then, some of the data blocks might contain inconsistent data. Whoops – bad idea!

One solution would be to add a JeeLink to the computer, and have it send out the power down command only after it finishes flushing and unmounting the disk. It’ll take some scripting, depending on the OS, but it’s all doable. Also, this isn’t really for disks which need to be online most of the time – for that, the normal hard disk spin down and idling modes will be fine.

But I’d like it to be a bit more automatic than that. I don’t want to have to remember to turn off the disks. Nor tie it to a specific time of day, or day-of-the-week. The whole point of these disks, is that I rarely need them. Some disks may stay off for weeks, even months.

Here’s an idea: by adding a current sensor to each disk power supply line, we could monitor disk activity and make sure that power is never shut off while a disk is “doing something”. By adding a bit of extra logic in the sketch, we could implement a timer so that the disk will only be powered down if the disk has been idle for say 15 minutes. Most operating systems have a periodic flush in place, so that changes always get flushed out to disk fairly soon after they have been buffered by the OS. If nothing has happened for a while, then we know there’s no important change pending.

OK, how do you measure the amount of current a circuit draws? Easy: insert a small resistance in series with the load, and measure the voltage drop. For the same reasons as before, we can’t do this “low side”, i.e. in the ground connection. But high-side would be fine:

Screen Shot 2011 05 30 at 02.00.54

With 1A of current, we get (using Ohm’s E=IxR law): E = 1 x 0.1 = 0.1V voltage drop across the resistor. And since the high side of the resistor is tied to “+”, all we need to do is connect the other side to an analog input.

The nice thing about the power control circuit presented yesterday, is that it has a MOSFET between + and the disk drive power pin. And MOSFETs are really very much like a small resistor when turned on. So we can simply use the MOSFET itself as a sense resistor:

Screen Shot 2011 05 30 at 01.54.25

Here are the characteristics of the P-MOSFET I’m going to try this with:

Screen Shot 2011 05 30 at 02.06.51

As you can see, at 3.3V, the MOSFET acts almost exactly like a 0.1Ω resistor: 0.1V drop at 1A – perfect!

There is still one problem though: when the MOSFET is turned off, the voltage on the low side will be at ground level, which is 8.7V below the JeeNode’s “ground”. So we can’t just tie it to an analog input pin, it would fry the ATmega. That’s is why I added a 10 kΩ resistor: it will still be a very “bad” input signal when the MOSFET is off, but the resistor will limit the current to less than 1 mA, and it will flow through the internal ESD protection diode. That amount of current should be harmless.

So now we have a way to sense the current. When the disk draws 1A, the analog input will be at 0.1V below 3.3V, i.e. 3.2V, which can easily be measured. Since the ADC resolution is 3.3 mV, this means that a change in power consumption as small as 33 mA could in principle be detected by this setup. Should be accurate enough to detect a disk spinning up or down and the seek actuator moving.

I’ve ordered a bunch of parts and will report when something useful comes out of these experiments.

Hard disk power #3

In Hardware on Jun 1, 2011 at 00:01

As promised in the previous post, here’s an improved design for controlling hard disk power.

The first conclusion is that we need to switch the positive +12V line, not the ground. Ground is inter-connected between all disks, the server, and this circuit – so we shouldn’t mess with it.

Here’s one way to do a “high-side” switch:

Screen Shot 2011 05 29 at 20.02.56

First problem: we don’t have a voltage higher than 12V available, so the N-MOSFET can’t simply be moved to the upper power line (it needs a few volts above its source to drive it, and when conducting, that source is at 12V). A P-MOSFET solves that, because it needs a few volts below 12V to drive it into conduction.

Second problem: we can’t drive the P-MOSFET high enough (12V) to make it disconnect, when driven from an ATmega output pin (which can’t go higher than 3.3..5V). So we need a resistor to pull the gate up, and a transistor to pull the gate down. And lastly, we need a resistor to limit the current into the transistor.

Quite a few parts, expecially since this circuit needs to be repeated for each hard disk.

For reasons which will become clear tomorrow, I’d like to simplify this circuit a bit further, and get away from handling 12V power levels. This “simplification” needs a bit of explanation, unfortunately:

Screen Shot 2011 05 29 at 21.05.13

To see what’s going on, this trick may help: look at the VOUT pin as being a regulated 8.7V voltage. In other words: the JeeNode “ground” is at +8.7V above ground, in relation to the power supply, hard disks, and server.

This means that the JeeNode is running with a 12 – 8.7 = 3.3V voltage difference between its 3.3V and GND pins, just as it always does. It’s merely floating a bit above ground, but that’s all relative anyway. As far as the JeeNode goes, it’s getting exactly the right power levels.

The result is that the output pins of that JeeNode will be at about 8.7V when “0” and at 12V when “1”. Which is just right to drive the gate of a suitable P-MOSFET (a “1” will turn it off, and a “0” will make it conduct).

So instead of making all the disk ground levels float, this setup places the JeeNode at an unusual 8.7V above ground level, which lets it turn on and off P-MOSFETs by controlling the positive supply line.

Now we need a regulated 8.7V supply. Eh, actually, no… we need a supply which is exactly 3.3V below the +12V line. That way, even if it fluctuates a bit from hard disk load changes, the JeeNode still gets a nice clean 3.3V.

The way to do that is to use a minus 3.3V regulator, such as an LM337. And from the perspective of that regulator, +12V is “ground” and ground is… -12V!

Perfect. You just have to look at voltages upside-down :)

Hard disk power #2

In Hardware on May 31, 2011 at 00:01

Yesterday, I described a design to control the power of hard disks. Now let’s see what happens when two hard disks are hooked up this way:

Screen Shot 2011 05 29 at 19.24.25

I’m including the USB cables to the server now, because that’s what causes a major problem: ground loops!

USB is a 4-wire (+ shield) connection between computer and devices. It is not isolated, i.e. all devices get hooked up galvanically. This in turns means that the ground potential of all inter-connected devices will be the same.

With a disk powered from a 12V power supply, ground is the negative wire. It’s also the ground of the USB connection to the server, so the “–” side of the power supply is connected directly to ground on the USB cable.

When two or more disks are plugged into one computer via USB, all ground pins will be connected together.

So far, no problem. Most devices have their own power supply, and these are all “floating”, i.e. they will adopt any ground voltage potential imposed on them (if any). You can connect any number of power supplies together through their “–” pins, and they’ll happily each feed their own devices and share a common ground.

Yesterday’s design is different – it uses a MOSFET to connect or disconnect the GND level from the disk drive:

Screen Shot 2011 05 29 at 19.36.05

The MOSFETs act as switches, connecting or disconnecting the wires on top to the JeeNode (and power supply) ground. So what one disk sees as “ground” is not the same as what the other sees (unless both are powered up). But… with the USB cables inserted, we’ve in effect created a direct connection between “GND1” and “GND2” through the USB’s common ground wires.

The result will be that no matter which MOSFET turns power on, it will end up powering BOTH disk drives!

And what’s (much) worse: the power supply current for the other drive will go through both USB cables and the server, which isn’t designed to handle the 1..2A peak currents flowing on startup.

Phew! I’m glad I didn’t start building this circuit :)

Tomorrow, I’ll describe a better design.

Hard disk power control

In Hardware on May 30, 2011 at 00:01

There’s a server running 24 hours a day, 7 days a week here at JeeLabs. It has two internal hard drives, one of them used as hourly backup for the system partition on the other disk. It’s running a couple of VM’s with all sorts of services, and it’s been running flawlessly for several months. Draws 10..15W.

Now, I’d like to attach a couple of extra hard disks to this server. A pair of disks for off-site backups (yes, there is a daily cloud backup, but I want a second fall-back system for some files), and a disk with stuff I rarely need, but don’t want to throw away. Disks are cheap – in fact I’ve got enough disks, so disk storage is actually free here. And while I’m at it: maybe add a little NAS for private stuff, since it’s been lying around and collecting dust anyway.

But I don’t want to have everything on-line all the time, for safety reasons and to keep power consumption low.

Why not use a JeeNode to control the power to these devices, which all run off a 12V supply? And why not just use one beefy switching supply, instead of that endless collection of power bricks?

Here’s a first idea:

Screen Shot 2011 05 29 at 18.49.52

Only one of the two channels on the MOSFET Plug is used here. And instead of switching a power LED or LED strip with it, it’s being used to control the power to the external disk drive.

There’s a flaw in this design, though: it’ll only work with ONE hard disk…

Tomorrow I’ll go into this and explain what’s going on, and why it can’t work with multiple disk drives. Hint: this setup only works if the JeeNode is controlled by wireless.

Summary of ISP options

In AVR, Hardware, Software on May 29, 2011 at 00:01

First of all, see this weblog post for an overview of what ISP is, why you’d want to know, and when you need it.

There have been quite a few posts about ISP on this weblog over time – all tagged, so they can be reached via this link: https://jeelabs.org/tag/isp/.

I’ll summarize here, since particularly the different sketches floating around by now might be a bit confusing.

The ZIF socket is a way to connect to chips before they have been soldered into a circuit. There’s one for through-hole DIP chips, and one for 32-TQFP SMD chips:

Once soldered into a circuit, you can use an I(C)SP programmer, which not everyone has. So I created a couple of different options based on a JeeNode (can also be an RBBB or Arduino) to perform the same function.

My first trial was a hack with the isp_flash.pde sketch, which then led to the Flash Board (info). The nice thing about this board is that it has 128 Kbyte of EEPROM on board – enough to hold the complete programming instructions for an ATmega168 or ATmega328.

One way to use the Flash Board is as capturing ISP programmer: you send a sketch to it as if it were an ISP programmer, and then you can disconnect it and use it repeatedly to upload that sketch to other boards via ISP:

I used this to build a 4-fold Multi-ISP programmer to program all those gazillion ATmega’s needed for JeeNodes:

Took a few attempts to get all the bugs worked out, but now it works perfectly.

But there’s a much simpler way to do this, if all you want is to fix a JeeNode, occasionally:

… or use an Arduino:

These two ISP setups use an isp_repair.pde sketch, which has as novelty that it includes the sketch and bootstrap its needs for programming – as data array in flash memory. So all that’s needed is: connect the two boards and power up the master. No need to use the Arduino IDE’s “Burn Bootloader” command or anything.

Then came OptiBoot, which is compatible with the Arduino Uno, and smaller/faster. This is a relatively new boot loader so you might want to update your current JeeNodes – even though an ISP programmer isn’t normally needed for development.

I updated the isp_repair.pde sketch, and then fixed a few remaining problems with it:

And finally, I added a LiPo battery, and 4 config switches, to end up with this tool:

On the software side, the most recent design is called isp_repair2.pde. It supports two different sketches, up to four different bootstrap loaders, and setting the fuses either as 16 MHz crystal or optimized specifically for ceramic resonators.

The include files with the bootstraps included with these sketches are generated from HEX files created by the Arduino IDE. This is done with a small Tcl script called hex2c.tcl, which is located in a slightly older isp_prepare example sketch folder. It’s not needed for normal use, only when one of the boot loaders changes.

Phew. Still there?

In a nutshell: if you need to re-flash your ATmega, pick one of the above options to hook things up, and use the isp_repair2 sketch in the Ports library. By default, it’ll upload a blink demo sketch and the OptiBoot loader.

More bootstraps

In AVR, Hardware, Software on May 28, 2011 at 00:01

Some projects just don’t want to lie down…

The isp_repair example sketch in the Ports library was written for a single purpose: to upgrade a JeeNode to the OptiBoot loader, which leaves more room for sketches and is compatible with the Arduino Uno.

It took two attempts to get it right, but in the end I think it all worked out as intended.

Until featuritis sets in…

First, I added a #define OPTIBOOT in the sketch, to allow re-using that same sketch to revert to the original boot – in case you ever want to go back. So now it’s a setup which can “repair” an ATmega in various ways.

But why stop there?

There are a couple variations for flashing which all make sense in the context of JeeNodes:

load a short Blink sketch, or load the entire standard RF12demo sketch
OptiBoot vs the original Arduino 2009 bootstrap code
faster wakeup after power down, works only with a 16 MHz resonator

The fast wakeup makes it possible to completely power down an ATmega between the reception and transmission of individual bytes via the RF12 driver. It won’t make a huge difference, but it will reduce power consumption just a notch more than staying in idle mode.

So here’s a new setup, and hopefully the last:

Dsc 2536

It includes yesterday’s DIP-switch Plug, which gives me 4 bits of configurability. There’s a new sketch which adds support for these switches and includes all the different pieces if code – it’s called isp_repair2:

Screen Shot 2011 05 26 at 01.34.25

The sketch includes up to four different boot loaders, currently:

Dip Switch Plug

There are two “sketch” code sections, followed by 4 bootstrap code sections:

Screen Shot 2011 05 26 at 03.09.23

With all switches set to “1” (same as not connecting any switches at all, BTW), we get:

Screen Shot 2011 05 26 at 03.06.53

And since (in my case) there’s an on-board LiPo recharger and battery tacked onto the back: this setup is fully self-contained and ready for use at any time.

Hmmm, I wonder what sort of bootstrap loader I could put in that spare slot, one day…

Funky plug

In Hardware on May 27, 2011 at 00:01

What is this thing?

Dsc 2533

Maybe you can guess from the other side?

Dsc 2534

Simple – it’s a funny kind of DIP switch, to manually configure 4 input pins as needed:

Screen Shot 2011 05 25 at 13.17.43

When used with internal pull-ups, this causes each switch to pull an I/O pin down when latched in the top position (as indicated in parentheses).

Works on any pair of ports and in any orientation, of course – but then the pin assignments will be different.

Arduino, ISP

Fixing the isp_repair sketch

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

A few days ago I posted a new sketch to reprogram an ATmega with the OptiBoot loader when you don’t have an ISP programmer. Worked for me, so I thought… kick it into the world!

Whoops…

First of all, there should have been a warning that if it didn’t work, this would leave you with an unusable ATmega. Never occurred to me, since I have an ISP programmer within reach to recover from such mistakes.

Fortunately, someone on the forum reported that the ATmega can be brought back to life with an old version of isp_repair.pde (which can be found here, BTW).

That’s odd… can’t program with the sketch, but can recover with the same sketch and different data bytes?

Time to dig in. First, I wanted to make sure that the timing was slow enough to work in all cases. Time to fire that logic analyzer up again:

Screen Shot 2011 05 25 at 11.33.22

Looks good – since I’m using standard digitalWrite() calls, the pins aren’t toggling very fast at all:

Screen Shot 2011 05 25 at 11.34.29

Then it dawned on me:

The lock bits don’t look right: 0xFF – should have been 0xCF (top 2 bits are always 1, i.e. same as 0x0F).

Maybe everything was working, except the setting of the fuse bits? That would explain everything: a new boot loader gets loaded in the top 512 bytes, overwriting parts of the old boot loader, but the fuse bits perhaps wouldn’t get adjusted to just to the new boot address!

I changed a couple of things:

do the full chip erase before setting the fuse bits
set the lock bits to 0x0F at the end, i.s.o. 0x3F
included both bootstraps in the updated sketch
tri-state the ISP programming pins when done

The erase is needed to recover from a locked fuse state. The programming always took place after the erase, so it went well, but the fuse bits themselves would still be locked while trying to adjust them.

The second step should have been there all along, the way I was doing it the boot section was not protected from overwriting itself. This might explain the occasional report I got of people damaging boot loaders during use.

You can now also adjust the #define OPTIBOOT at the top of the sketch to 0 to revert to the original bootstrap code and fuse settings. So if OptiBoot is not what you want, recompile and restore as needed.

And lastly, the SPI programming pins are now reset to high-impedance after programming, so that the programming connections can be left in place without interfering with the target board.

Here’s the serial output from the updated sketch:

Screen Shot 2011 05 25 at 11.41.31

And here’s why it would sometimes have worked: if your ATmega had the lock bits unset (0x3F i.s.o. 0x0F), then the fuse settings would work as intended even with the chip erase in the wrong order. But with a locked setup, not everything would get set to the proper state.

Which goes to show: bugs can bite at any time!

Update – still some issues to iron out (see forum), but it looks like these are more related to OptiBoot than to this bootstrap replacement sketch.

Update #2 – OptiBoot issue solved.

Avoiding memory use

In Hardware on May 25, 2011 at 00:01

On an ATmega328, memory is a scarce resource, as I’ve mentioned recently. Flash memory is usually OK, I’ve yet to run into the 30..32 Kb limit on code. But the crunch comes in all other types of memory – especially RAM.

This becomes apparent with the Graphics Board, which needs a 1 Kb buffer for its display, and with the EtherCard, which can often not even fit a full 1.5 Kb Ethernet packet in RAM.

The Graphics Board limitation is not too painful, because there’s the “JeePU“, which can off-load the graphics display to another JeeNode via a wireless connection. Something similar could probably be done based on I2C or a serial interface.

But the EtherCard limitation is awkward, because this essentially prevents us from building more meaningful web interfaces, and richer web server functionality, for example.

The irony is that there’s plenty of unused RAM memory, just around the corner in this case: the ENC28J60 Ethernet controller chip has 8 Kb RAM, of which some 3.5 Kb could be used for further Ethernet packet buffers… if only the code were written differently!

In fact, we have to wonder why we need any RAM at all, given that the controller has so much of it.

The problem with the EtherCard library, is that it copies an entire received frame to RAM before use, and that it has to build up an entire frame in RAM to send it out.

I’d like to improve on that, but the question is how.

A first improvement is already in the EtherCard library: using strings in flash memory. There’s also basic string expansion, which you can see in action in this code, taken literally from the etherNode.pde example sketch:

Screen shot 2011 05 24 at 22 57 26

The $D’s get expanded to integer values, supplied as additional arguments to buf.emit_p(). This simplifies generating web pages with values (and strings) inserted, but it doesn’t address the issue that the entire web page is still being constructed in a RAM buffer.

Wouldn’t it be nice if we could do better than that, especially since the packet needs to end up inside the ENC28J60 controller anyway?

Two possibilities: 1) generate directly to the ENC28J60’s RAM, or 2) generate a description of the result, so that the real output data can be produced when needed.

For now, this is all just a mental exercise. It looks like option #1 could be implemented fairly easily. The benefit would be that only the MAC + IP header needs to stay in RAM, and that the payload would go directly into the controller chip. A huge RAM saving!

But that’s only a partial solution. The problem is that it assumes an entire TCP/IP response would fit in RAM. For simple cases, that would indeed be enough – but what if we want to send out a multi-packet file from some other storage, such as an external Memory Plug or an SD card?

The current EtherCard library definitely isn’t up to this task, but I’d like to think that one day it will be.

So option #2 might be a better way: instead of preparing a buffer with the data that needs to be sent, we prepare a set of instructions which describe what is needed to generate the buffer. This way, we could generate a huge “buffer” – larger than available RAM – and then produce individual packets as needed, i.e. as the TCP/IP session advances, packet by packet.

This way, we could have some large “file” in a Memory Plug, and its contents would be copied to the ENC28J60’s RAM on-demand, instead of all in advance.

It seems like a lot of contortions to get something more powerful going for the EtherCard, but this approach is in fact a very common one, called Zero Copy. With “big” computers, the copying is done with DMA and special-purpose hardware, but the principle is the same: don’t copy bytes around more than strictly needed. In our case, that means copying bytes from EEPROM to ENC28J60, without requiring large intermediate buffers.

Hm, maybe it’s time to create a “ZeroCopy” library, sort of a “software based generic DMA” between various types of memory… maybe even to/from external I/O devices such as a serial port or I2C device?

It could perhaps be modeled a bit like Tcl’s “channels” and “fcopy” command. Not sure yet… we’ll see.

Still running on LiPo

In Hardware on May 21, 2011 at 00:01

A while back, a post on this weblog described a simple setup I had running to see how long the radioBlip.pde sketch would keep running on a single LiPo battery.

Here’s the setup again:

That’s a 1300 mAh battery, and the test sketch on it sends out an incrementing counter approximately once a minute (I extended the counter to 4 bytes, instead of the 2 bytes used in the original sketch).

It’s still going strong, i.e. this sketch has been running for 9 months on a single battery charge so far.

The counter is now at about 350,000 and I’ve determined that packets actually go out every 64 seconds, so that puts the counter at about 260 days. There’s a gap there, because the node was once reset some two weeks after being started for the first time.

So with some 275 days of running time, we can deduce that the average power consumption of this node has to be under (1300 * 1000) µAh / (275 * 24) h = 197 µA. This assumes that the battery would be empty, which it isn’t yet – so we know the average current must be lower (a lot lower, probably). Unfortunately, I didn’t include logic to measure and send out the LiPo voltage, which would be a good indicator of how far the LiPo battery actually is. The good news: a check with my multimeter shows the battery to still supply a whopping 3.985 V!

Anyway – I wouldn’t be surprised to get at least 4 times as much runtime, i.e. 3 years, out of this setup (which would translate to 50 µA average current draw).

Sooo… just hang around for another few years, and I’ll let you know!

LiPo bulge

In Hardware on May 19, 2011 at 00:01

Speaking of Lithium Polymer batteries…

Last week, I was working on the (2007-vintage?) MacBook Pro now used by my wife Liesbeth, who uses it every day as desktop machine with an external keyboard and mouse hooked up all the time. Then I noticed that for some reason, the built-in trackpad had stopped working…

Here’s what happened:

Dsc 2524

The battery pack had bulged to almost twice its normal thickness. Here’s a good battery pack for comparison:

Dsc 2523

Sure enough, that bulge pressed up very hard against the mouse pad. I’m surprised it didn’t bend or damage anything else in the laptop! Removing it made the trackpad work again, BTW.

These battery packs are quite large and can store a serious amount of energy:

Dsc 2528

Ok, now since that pack is hosed anyway, I decided to take it apart. Which wasn’t relly hard, considering how much of the innards were already exposed:

Dsc 2525

After prying off the aluminum cover, which was glued on, this came out:

Dsc 2526

You can see the battery protection / charge circuits, and what appear to be three sets of LiPo batteries in a sturdy plastic pouch. And the middle one sure doesn’t look right:

Dsc 2527

I’ve stopped there, afraid to open up the battery and expose the Lithium to air, which as far as I understand could cause it to spontaneously catch fire. Well, that’s what Sodium (Na) does, anyway.

Given that the battery was produced 5 years ago and has given me several years of good service, I don’t really mind. Just need to get rid of this chemical waste in the proper manner.

Or did I narrowly escape a major disaster?

Arduino, JeeLink, JeeNode, ISP

Self-powered Opti-rebooter

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

After yesterday’s post about switching to OptiBoot, I decided to go one step further and go for a self-powered solution, a bit like this unit which has been serving me well for many months now.

So here’s the “Opti-rebooter” with a 400 mAh LiPo backpack:

Dsc 2521

Hookup is trivial, given that the JeeNode USB has an on-board LiPo charger. I picked a battery which matches the width of the board and fits quite well:

Dsc 2522

The two connectiosn of the LiPo battery are wrapped up in heat-shrink tubing to prevent accidental short circuits – the currents involved could easily cause trouble. Note that this is a “raw” LiPo cell, without any protection circuitry. That’s fine in this case, because the on-board circuitry takes care of charging.

To make this complete, the isp_repair.pde was extended to completely power down when done. So there’s no need for an on-off switch, the idle consumption is probably lower than the battery’s own self-discharge rate. And it blinks the on-board led twice: once on power up and once when properly programmed. Very convenient!

The way to use this thing, is: connect to a target JeeNode / JeeLink / Arduino, press the RESET button, wait three seconds, disconnect, done.

I also made changes to the very similar but slightly more elaborate isp_prepare.pde sketch, which was presented in this weblog post.

The updated isp_prepare.pde sketch supports a number of variations. These can be configured by adjusting a few values at the start of the sketch:

Screen Shot 2011 05 16 at 15.00.32

You can choose which type of boot loader to install, which sketch to load initially (just to start off, this can be overwritten later), and there’s a third option to adjust some “fuse bits” in the ATmega to select how fast the ATmega can start up after resuming from a power down.

That third option is particularly useful with battery-powered JeeNodes using the RF12 driver. With USE_FAST_WAKEUP set to 1, the power-up sequence is fast enough for an ATmega to wake up when the first data byte is received. This means you can completely power down the ATmega (while leaving the receiver running), and it’ll still be able to pick up incoming packets and respond to them. There is one gotcha: USE_FAST_WAKEUP can only be set to 1 on units running with a resonator – JeeLinks and Arduino’s running with a crystal must be not use the fast wakeup mechanism, as the clock may not start up properly in this case.

Haven’t tried it though – for now, that LiPo powered unit shown above is really the most convenient way for me to upgrade all the JeeNodes, JeeLinks, and Arduino’s floating around the house at JeeLabs.

JeeLink, JeeNode, ISP

Switching to OptiBoot

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

Now that some of the JeeNode/JeeLink boards from JeeLabs come pre-loaded with the OptiBoot boot loader, it’s time to start thinking about switching everything over. Having to constantly switch the Arduino IDE between “Arduino Uno” (OptiBoot) and “Arduino Duemilanove w/ 328” (original 2009 boot) is quickly going to become very tiresome …

See this weblog post for a quick summary of what all this uploading and boot loader stuff is about, and why you should care. In a nutshell: you need a boot loader on the ATmega to save sketches onto it via FTDI and USB.

There’s a nasty detail, though: to upload sketches you need a boot loader, but how does that boot loader end up on the ATmega in the first place? The good news is that this is usually done in the factory, well, ehm… at JeeLabs, in my case. The good thing is, it’s all taken care of, and the boot loader doesn’t normally get damaged or need to be replaced. It just works.

Except when the boot loader itself needs to be changed, as in the case of OptiBoot. Note that it’s quite worthwhile to switch to OptiBoot: the uploads are twice as fast, and you get 1.5 Kb of extra memory for your own sketches.

So how do you go about updating the boot loader on a JeeNode when you don’t have a special hardware tool called an “ISP Programmer”?

Fortunately, there is a simple trick to do this using a second JeeNode (or Arduino). I’ve written about this in a previous post. There’s an isp_repair.pde sketch in the Ports library which does everything (it emulates an ISP programmer, basically).

I’ve just updated the isp_repair.pde sketch to use OptiBoot.

Here’s the setup to upgrade a target JeeNode to OptiBoot using another JeeNode:

Six wires need to be connected as follows:

And then it’s a matter of attaching the target to the programming JeeNode, and then powering up the whole assembly.

If you happen to have the serial port connected to the programming JeeNode, you’ll see this info:

Screen Shot 2011 05 16 at 17.08.48

I made a permanent setup using a JeeNode USB, because I’ve got a pile of JeeNodes to reprogram here at JeeLabs:

Dsc 2518

The connector was constructed from a 2×4 header, with the pins bent in such a way that the whole thing stays in place when pressed into the 2×4 holes of the SPI/ISP header. And then the whole thing was sealed off with a few pieces of heat-shrink tubing:

Dsc 2519

To program a board (in this case another JeeNode USB), just power it all up and wait 3 seconds:

Dsc 2520

That’s it – you could call this an “opti-rebooter” :)

JeeLink v3 w/ OptiBoot

In AVR, Hardware on May 16, 2011 at 00:01

Small changes. Previous, i.e. v2:

Dsc 2515

And here’s the new JeeLink v3:

Dsc 2516

The changes are mostly cosmetic and include a number of changes to simplify the assembly process. Some minor but oh so important tweaks to more accurately fit it in the case:

Dsc 2517

See those four tiny notches line up? Phew!

Two changes which will be more important for everyone using these:

The JeeLink v3 comes with the OptiBoot loader pre-installed, i.e. you need to select the “Arduino Uno” as board type when uploading sketches to it.
The on-board DataFlash memory has been increased to 16 Mbit. This fast SPI-connected permanent memory makes it possible to use a JeeLink for collecting even more data when the PC is off (but power has to remain, evidently). The RF12demo sketch has a FLASH_MBIT constant defined, it should be set to 16.

You can easily see which JeeLink you have by looking at the gold lettering on the back side.

Apart from that, nothing really changes. All JeeLinks sent out from now on will be this new v3 build.

Onwards!

RFM12B range testing

In Hardware on May 15, 2011 at 00:01

There have been many questions and discussions about the range achievable with the RFM12B wireless modules. Usually, my answers have been: 1) should be about 100m outside, and 2) gets through about two walls inside the house. But the most accurate answer really is a resounding “it depends” …

Because it really does. RF range will depend on a huge number of factors. What works for me may not work for you, and what works today may not work tomorrow.

Triggered by some recent discussions on the forum, and with the help of Steve Evans (@TankSlappa) who wrote a good set of sketches and did some tests, I’ve come up with two sketches and a setup to report reception quality.

This setup requires two RFM12B modules evidently, plus an LCD connected via the LCD Plug. I re-used one of my Mystery Boxes – one of so many projects here at JeeLabs waiting to get finished.

My sending unit is a JeeNode with an AA Power Board on the back. The rfRangeTX.pde transmitter sketch is very simple, and sends out 1-byte packets 10 times per second:

Screen Shot 2011 05 14 at 15.00.18

The receiver is based on a JeeNode USB with LCD and LiPo battery, so both units are portable / self-powered:

Dsc 2513

The code for the rfRangeRX.pde receiver sketch is too long to be shown in its entirety, but here’s an overview:

Screen Shot 2011 05 14 at 15.03.34

The display shows 4 fields:

top left = percentage of packets received in the last 5 seconds
top right = percentage of packets received in the last second
bottom left = sequence number of the last valid incoming packet
bottom right = history of last reception counts (10x 0.5s intervals)

Here, one packet was missed in the last second (98% is 1 out of 50, 90% is 1 out of 10):

Dsc 2509

And here, two packets were missed a few seconds ago:

Dsc 2511

Feel free to take these sketches as starting point for your own tests. You could do all sorts of funky range testing with this, from just seeing how much gets lost in a particular setup, to investigating the effect of different RFM12B baud rates, working in other bands, antenna optimization, identifying in house “cold spots”, and checking the effect of adding an extra pull-up resistor, as recently suggested here and here on the forum.

There are still quirks (i.e. bogus reports every 5s when no packets are coming in, due to byte wraparound).

Both sketches have been added to the RF12 library. There is probably a ton of neat stuff to add – please share your improvements and I’ll try to fold them in so others can use them too. By adding logic for two buttons (or a joystick as on the above RX unit), we could even configure the receiver in the field.

Many thanks to Steve E for coming up with the original idea and getting a first implementation going.

Crunch time

In Hardware on May 14, 2011 at 00:01

Ouch…

The new JeeNode v6 boards have run out. The initial batch has been flying out the door quite a bit faster than I anticipated. And it’s going to take another 10 days until new ones arrive, unfortunately.

My apologies for the delays this will cause.

Displays

Colorful GLCD

In Hardware on May 13, 2011 at 00:01

Whoops! The other day, one of the Graphics Boards here at JeeLabs fell on the floor:

Dsc 2505

Pretty, but not quite what it’s supposed to be :)

Fortunately, I still had a similar black display left over from the initial builds:

Dsc 2507

(ignore the info – node #3 is a radioBlip sketch, even though glcdNode interprets it as a room node)

Sooo… don’t drop the GLCD, it’s brittle! Unless you prefer that first display, of course :)

Assessing the damage

In AVR, Hardware on May 12, 2011 at 00:01

Yesterday’s post was about wearing out the EEPROM memory on an ATmega168. It took over 6.7 million writes to address zero to make it fail. As mentioned, this is a limited test, because reading out the value was done right after writing it. But hey, at least I didn’t have to write 100,000 times to each EEPROM address and wait 20 years @ 85°C to find out whether each byte was still correct…

So we got a failure, now what?

Well, re-running the test caused it to fail after a mere 6,200 write cycles, so that EEPROM definitely isn’t up to spec anymore.

Today, I wanted to see what effect this single massive rewrite of address zero did to the rest of the EEPROM. So I wrote another test which would go through the entire EEPROM and see how well writes + read-backs would work on this same ATmega168 with its massively-abused EEPROM:

Screen Shot 2011 05 11 at 17.23.32

All failures are counted, per EEPROM address. Whenever the maximum number of failures at any single address increases, a map is printed with the counts for each of the 512 bytes. Here’s the startup situation – no errors yet:

Screen Shot 2011 05 11 at 17.23.10

The map counts are encoded as single characters:

 0         =  "."
 1 to 9    =  "1" .. "9"
10 to 35   =  "a" .. "z"
36 to 61   =  "A" .. "Z"
62 and up  =  "?"

Every 100 cycles, the cycle count is printed, just to let me know that the sketch is still running. Unfortunately, re-writing all 512 bytes in EEPROM is way slower than yesterday’s test, over 1 second per cycle. So I also added an LED to toggle on each cycle:

Dsc 2503

Now the waiting begins… it’s going to take hours (maybe even days!) to force the next failure again.

And one thing is clear: it’s not easy to get these chips to fail quickly!

Update – 100,000 cycles later, no new failure yet…

Destruction!

In AVR, Hardware on May 11, 2011 at 00:01

No, not distractions …

Had a ATmega168 chip lying around which isn’t going to be used anymore anyway, so why not do some destructive testing on it, eh?

There have been a couple of such tests floating around on the web, so I thought I’d try to replicate them – to try and find out how many read-write cycles the internal ATmega’s EEPROM can sustain. I started from the info on John Boxall’s weblog, and set up a similar configuration, but based on a JeeNode:

Dsc 2497

Note that this isn’t using the LCD Plug, but has direct connections to 6 digital output pins (I used the same pins as in the original sketch: digital 4..9).

Made a simpler sketch to just toggle bits in the EEPROM and display the counter (the display is fast when there’s no I2C expander chip involved):

Screen Shot 2011 05 10 at 18.46.38

It turns out that flipping all the bits in the EEPROM takes a few seconds, and with an expected lifetime well over 100,000 that test would have lasted several days. So instead, I rigged the test to only flip byte 0 in the EEPROM. Let’s see how much beating that single byte can take!

Several hours later…

Dsc 2499

Over 3,260,000 write cycles and still going.

Note that this is only testing EEPROM address 0x000, and that the check is right after the write, so this is not necessarily a very useful test: bad bytes might hold charge, but not for over 20 years as listed in the specs, and some other address might give an error much sooner.

But still… 32x above spec so far. Not bad!

Update – The ATmega168 finally broke down:

Dsc 2502

Then it failed 6200 cycles after the next power-on.

Home automation, JeeRev

Distractions

In Hardware, Software on May 10, 2011 at 00:01

Sorry, no serious weblog post this time. I’ve been distracted by an iPad which got delivered here today.

Couldn’t resist trying out some stuff…

Portrait

Here’s one in landscape mode:

Landscape

(both screen shots were created via the simulator, but the real thing looks exactly the same)

It’s obviously just a web browser. It’s also totally obvious to me now that touch screens are a natural fit for this sort of stuff. Goodbye double-click, hello swipe and pinch.

Pretty amazing how long we’ve done without ’em!

Another power option

In Hardware on May 9, 2011 at 00:01

Here’s a nice little power supply:

Dsc 2137

It’s one of many LED drivers currently available on the market.

These supplies are designed to provide a fixed current – not voltage. What this means is that if you “overload” them, then they will regulate the voltage down to the point where the current reaches a preset value (700 mA in this case).

In itself, this isn’t really useful for powering anything but power LEDs, but this unit also specifies that as long as the load remains under 650 mA, it will supply a fixed voltage of about 6V. So the other way to interpret these specs, is to see this as a 6V power supply with automatic current limiting to 700 mA.

This means that if we add the optional diode to a JeeNode v5 or v6, then the voltage would be just right to power one or more 5V relays.

The nice thing about these units is that they are fully “potted”, i.e. encased with proper high-voltage isolation.

This might offer a practical way to set up mains-powered JeeNodes, with perhaps a Relay Plug to switch simple AC loads, or a triac for switching / dimming incandescent lights. Another option would be to use a MOSFET to switch 1..3W power LEDs.

PS. Unfortunately, I don’t remember where I got this particular unit (yeah, I know – I feel pretty stupid!)

Inside the USB supply

In Hardware on May 6, 2011 at 00:01

The USB power adapter is a nice little unit pumping out 5V:

Dsc 2461

It’s no doubt intended mostly as charger for USB devices, but with a 1A output current, it can actually power lots of things, including JeeLinks and JeeNodes.

I was curious as to what’s inside this CE-approved device, so I took one apart:

Dsc 2472

A chip, a bridge rectifier, lots of electrolytic capacitors (with limited lifetimes if things get hot), an isolation transformer of some kind, some inductors, and a USB jack:

Dsc 2473

The 400V rating on the 4.7 µF caps sounds a bit far-fetched, though.

The bottom side shows an interesting mix of SMD components and solder joints:

Dsc 2474

I haven’t looked into the circuit itself yet. I can’t help but wonder whether a 50mA supply couldn’t be done with fewer components.

Oh well. This unit works, is certified, comes from an official local wholesale supplier, and nothing I can come up with could be made for less.

Meet the JeeNode SMD

In Hardware on May 4, 2011 at 00:01

After yesterday’s change of name, I’m pleased to announce a brand new member of the ever-expanding JeeNode family, the JeeNode SMD (aka NS1).

It’s a pre-assembled unit with SMD parts, and just some 6-pin headers you have to solder on yourself. Here’s a hand-soldered test unit with the port headers mounted sideways:

Dsc 2493

Here’s that same unit, seen from the bottom:

Dsc 2494

Sideways mounting adds a new option for using plugs, because this unit is flat enough to use upside down:

Dsc 2495

(Note: oops, that BUB needs to be flipped around!)

You don’t have to do it this way, and can of course just choose to mount the headers in the normal vertical orientation.

The main differences with the standard JeeNode Kit are:

on-board activity LED (same as JeeLink and JeeNode USB)
on-board reset button
pads for A6/A7 analog in, and the AREF pin
much flatter, fits in more places than the trough-hole kit
less soldering, just a few headers (so you get to choose their orientation)

Still the same as a JeeNode in most other respects, i.e. same size, same battery options, same FTDI connection to the outside world, and same RFM12B radio.

The Café page is here. Along with a page in the shop.

JeeNode, JeeSMD

What’s in a name

In Hardware on May 3, 2011 at 00:01

The JeeSMD is getting a new name:

Jsx

JeeSMD is OUT, SMD Kit is IN!

Sknew

The new product link is https://jeelabs.org/sk1 (was “js2”). The SKU label and link on the PCB will be updated later, in the next batch of boards.

The new shop link is https://jeelabs.com/products/smd-kit (was “jeesmd”).

All in the name of progress…

Relays at last

In Hardware on May 2, 2011 at 00:01

It has taken months to settle this issue, but I’m happy to report that the supply problems are all over now… the Relay Plug board has been redesigned to accommodate a slightly different model:

Dsc 2488

Still fits, still same size. And still rated 5A @ 250 VAC.

The coil resistance is 125 Ω, which means each of the two relays will draw 40 mA @ 5V when closed. Slightly more than the previous model, but well with the specs of the on-board relay drivers.

The point of it all is that these new relays have a major distinguishing feature: I’ve got them in stock, at last :)

For the record: first an order for the original units was postponed from January to May, then a second order with another supplier was pushed back to June when they told me the stock listed on their website was grabbed by someone else moments before me…

All is well again now. End of story. Well… until the next supply issue pops up, anyway!

Meet the JeeNode v6

In Hardware on May 1, 2011 at 00:01

The JeeNode v5 addeth a diode, and the JeeNode v6 taketh it away again:

Dsc 2490

Here is the new board, which I’ve started including in the latest packages:

Dsc 2492

The differences with v5 are:

The diode jumper is now shorted out by default (cut a trace on bottom side to use a diode).
There is a new ground connection near the antenna connection.
The PD2 (INT0) and PB2 (SS) pins are now connected to pads (same layout as on JS2).
Minor tweaks, such as labeling fixes.

Nothing big or serious, as you can see – I’ll gradually update various bits and pieces on the web to match this revision. For now, please just continue using the links and build instructions of the v5.

(Apologies for the long hiatus, but I needed the break!)

Gas flow measurement artifacts

In Hardware on Mar 14, 2011 at 00:01

The raw gas consumption graph always looks a bit odd:

Screen Shot 2011 03 13 at 12.59.45

Green is gas flow, red is electricity consumption.

This is the same oddity I described two years ago on this weblog. The values are calculated from the last rotation time of the meter, but with gas flow things are a bit different: gas consumption is not continuous but a discrete on/off process, with some “modulation” once on.

So instead of each of those “tapering off” effects, what really happens is that the flow stops completely for a while and then resumes again later on.

This is an example of where the measurements need to be “fixed” (!), by injecting fake data points. It also illustrates how you can’t really know anything about consumption between disk rotation pulses.

The vertical grid lines in the above graph are spaced 500 l/h (resp. 500 W) apart, btw.

New USB-BUB II

In Hardware on Mar 8, 2011 at 00:01

There’s a brand-new “Modern Device” out, the BUB II !

Screen Shot 2011 03 07 at 22.21.15

Lots of options, also on the back (sorry for the color difference: pictures were taken in different contexts):

Dsc 2478

I’ve been waiting for some time for this one, since the old BUBs ran out quite abruptly not so long ago…

The important thing to note is that the BUB II is compatible with JeeNodes out of the box. No jumpers, no settings to tweak, nothing. Just solder in the header and you’re all set.

And of course, most importantly…

Dsc 2477

It’s now the same blue-and-gold as all the other boards at JeeLabs, and it even has exactly the same width as a JeeNode. One more step towards world-21.1mm-wide domination :)

I’ll update the shop shortly, all new BUBs are now sent out as this BUB II.

New USB power option

In Hardware on Mar 2, 2011 at 00:01

Ah, I’ve finally found a nice little CE-certified power supply for USB:

Micro usb

Extremely small (i.e. easy to ship), and very efficient. This thing will provide up to 1000 mA at a stable 5V level. Perfect for JeeLinks, JeeNode USB’s, and Arduino’s – or any other USB devices for that matter:

Dsc 2461

The power consumption when idle is a mere 0.20 watt, i.e. less than 1 mA of mains current. When plugging in a JeeLink, this increases to 0.32 watt, which is pretty phenomenal actually: the difference is 120 mW @ 5V = 24 mA, just about exactly what the JeeLink consumes with an ATmega running full-power and the RFM12B in receive mode.

I’ve added it to the shop and also added it as option to replace the AA board in the JeeNode Experimenter’s Pack in case you’d rather run off mains power.

▶ View 20 Comments

Easy Electrons – Pull Ups and Downs

In Hardware on Feb 13, 2011 at 00:01

Time for another installment of the Easy Electrons series. This one is about the why’s and how’s of pull-up and pull-down resistors.

There are many ways to generate digital output signals. They almost always work with “high” and “low” voltages – for suitable definitions of high and low. As it turns out, there are lots of tricks you can play with this.

The high-end solution is to use a “push-pull” driver with two transistors. Similar to the H-bridge circuit described in an earlier post. By switching either one of the transistors on, you get an output which can carry current in either high or low states (“sourced” to ground, or “drained” from the supply rail, respectively):

Screen Shot 2011 02 12 at 11.32.02

The CTRL A & B pins are set up in such a way that one transistor conducts, and the other blocks. When a PNP/NPN pair is used, tying them both together turns out to work exactly as needed. This is what an Atmega pin does in OUTPUT mode, essentially.

But you don’t really need such a setup in many cases. That upper transistor can also be replaced by a resistor:

Screen Shot 2011 02 12 at 22.40.17

Resistors are cheaper, but more importantly, resistors offer more flexibility. The effect is that when the only remaining lower transistor is conducting, then it draws the signal to ground, and when it is not, then the resistor pulls the now-floating signal to a high level. This works as long as you don’t draw too much current. A common value for such a “pull-up” resistor will be between 1 kΩ and 100 kΩ. In that last case, you can’t put a load of more than a few microamps on the circuit, but again: for signaling purposes that is often just fine.

Why is this useful?

Well, for one, the voltage levels can be different. It’s possible to control a 0..12V digital signal using just one transistor and a pull-up to… 12V. This is also perfect for 3.3V -> 5V conversion, for example, and it even works when the output voltage is lower than the signal input (which goes through a current-limiting resistor anyway).

Another nice property is that you can tie several such outputs together. The output signal will drop to 0 whenever any output is low, and stay at 1 when all the outputs are high. i.e. it acts as an implicit AND-gate. This makes such a circuit suitable for “bussing”, i.e. putting multiple devices on a single signal line. You still need to collaborate between the devices to make sure only one of them talks at any given time, but electrically they can all be tied together with no extra circuitry. An output which is high is in effect not participating in the state of the bus signal.

Third, the single-transistor can still drive larger currents, but only in the “0” state. So you can still use this to turn on a LED (+ resistor), as long as you tie the LED/resistor combo between output pin and the supply voltage, not between output pin and ground.

And fourth, perhaps not as important as the rest: shorting such an output to ground when it only has an active-low transistor cannot harm the circuit (unlike shorting it to the positive supply rail). All that happens is that the pull-up will be supplying a little bit of current as it ends up getting the full supply voltage.

Note that putting a positive voltage on the transistor base willl cause it to conduct, and than tying something between the output pin and the supply voltage will cause it to get power when the transistor is conducting current from the output pin to ground. So loosely speaking, a “high” input voltage leads to an energized output state, even though the effect is to pull the collector low.

A slight variation is to use one transistor and leave the resitor off altogether. This is called an “open-collector” (OC) output, for obvious reasons. Sometimes, that extra resistor is not needed, i.e. when all you care about is energizing a lamp / motor / LED, or not. Sometimes a pull-up is still required, but then a single one will be sufficient, even with multiple OC outputs tied together. This is a way to reduce the total component count a bit further.

The I2C bus is an example which uses the open-collector output plus pull-up resistor approach, to implement a bus with multiple devices, exchanging information between them in any direction.

On an ATmega, you can enable a pull-up resistor on any pin by setting the pin up as an input pin, while writing a “1” as if it were still an output pin. The result will activate a weak pull-up resistor of 20..50 kΩ. One side-effect is that the input pin will read as a clear “1” when nothing else is connected. A pull-up resistor is a bit like slanting the table, i.e. the signal tends to stay in the high state unless a certain amount of current pulls it low.

What about pull-downs?

Technically, all this pull-up trickery can also be done with pull-down resistors and transistors tied between supply and output pin, but it is less comoon to do so. Due to the way transistors work, such a “high-side” switch is easiest to implement with a PNP transistor – and these used to be less common and more expensive. Furthermore, a “high” input signal would now cause no output current to flow. So the sense of operations is inverted. Are these essential reasons to avoid such an approach? No. But the NPN low-side switch approach has become prevalent. It has become second nature to use NPN transistors, and to tie small loads directly between the output pin and the positive supply voltage.

The ATmega has no built-in pull-down mechanism.

JeePlug, Network

OOK fix

In Hardware on Feb 10, 2011 at 00:01

Here’s a great suggestion from Stefan Schulze (“kami” on the forum) for getting that wrong 433 MHz transmitter working with the OOK 433 Plug:

Sideways:

It requires some pin-bending, and you can attach an optional antenna, as he did.

I’m currently discussing option with the supplier to find a more “official” solution, but if you want to use the OOK plug right now, the above is definitely an option.

Thanks, Stefan!

Update – For everyone who received the OOK 433 Plug in its current form: I will send a solution out to everyone once it has been worked out. If you don’t need the TX side immediately, it might be an option to postpone soldering it until that solution is available.

Update #2 – Problem has been resolved, the OOK Plug is now supplied with the correct 3-pin transmitter.

JeePlug, Network

OOK Murphy

In Hardware on Feb 8, 2011 at 00:01

Looks like there is a problem with the OOK 433 Plug…

Here’s the transmitter I started out with:

Dsc 2455 2

Here’s the print layout I designed, based on that:

Screen Shot 2011 02 07 at 20.36.25

Everything worked fine. So I ordered larger quantities, to be ready for production. Here’s what I got in that new batch order:

Dsc 2455 3

Whoops… different unit!

Worse still, the original board had +, Gnd, Data as pins (as seen on the board layout), whereas the new boards have Data, Gnd, +, Antenna. It would be possible to cut the antenna pin off, but that’s not enough since the pinout is in fact reversed!

I’ve contacted the supplier. Let’s see how this goes. For the time being, I’m forced to take the OOK 433 Plug “off the shelf”. Sorry about that – please hang in there, also if you’ve already ordered this plug. Note that this only affects the 433 MHz transmitter – the 433 MHz receiver should work just fine.

Easy Electrons – MOSFETs, part 2

In Hardware on Feb 7, 2011 at 00:01

Yesterday was about MOSFETs and the heat they generate. Pretty impressive, those components which can control a 15A current with just a little bit of voltage.

Unfortunately, it’s not quite as simple as that. We have to check what happens with a lowly 3.3V applied to the gate. This can be found in the IRLZ34N datasheet:

Screen Shot 2011 02 06 at 20.43.00

This is an important graph for MOSFETs. Each line corresponds to a different voltage applied to the gate – this graph is in fact eight graphs in one.

You can see that they really do have some limits at lower voltages. At 3.3V, the IRLZ34N will not go much higher than 7A – quite a bit lower than the 30A maximum specs on the front page of the datasheet. Most MOSFETs are still at the end of their range when driven by a 3.3V microcontroller.

What this graph also shows, is the drain-to-source voltage at different current levels. This makes it very easy to estimate power consumption: at 3V and roughly 5.5A, that voltage will be 1V. In other words: 5.5W – quite manageable if the MOSFET is mounted on a suitable heat sink. But again: quite a bit lower current handling capacity than the 15A from yesterday. Note that we could drive it at a higher voltage by adding an extra stage in front, using either a BJT transistor or a MOSFET to get better current handling capacity.

As you can see, there is a very distinct switch-over point at each gate voltage level, where the MOSFET stops conducting more current. Under the switch-over point MOSFETs act essentially like a pure (low-value) resitor, but above that point they start acting more like a current limiter. This has major implications for power consumption, since the drain-to-source voltage will rise.

With this particular IRLZ34N, driving it at 3.3V, it is best not to push it beyond about 5..6A, and to use a heat sink when power consumption rises above say 1W (i.e. at 62°C/W, that makes the bare MOSFET rise 62° above ambient). Looking at the 3V line in the graph, I’d estimate that this MOSFET would work just fine without heat sink up to at least 2A, perhaps even 3A.

But what if we want to regulate the current? I.e. what if we want to use the MOSFET in an analog manner, and not just as on-off switch?

We could lower the gate voltage somehow, to force the current down. It won’t be a linear relationship, and I’m not even sure a MOSFET will conduct any current at all when the gate voltage is lower than 1 or 2V.

But in general, it’s a bad idea. The reason is (again!) power consumption. Say we use the following circuit:

Screen Shot 2011 02 06 at 22.17.58

(the resistor is a pull-down, explained in a future post)

That’s a 12W incandescent light bulb, powered by 12V, and controlled by a MOSFET, in other words: it draws 1A when full on. Let’s say we want to dim the light by halving the current through it. The lamp acts like a resistor (it just get pushed so hot that it starts glowing, that’s all). So half the current is what you get when you apply half the voltage to it. In this case 6V.

Suppose we figured out exactly what gate voltage to apply to get a drain-to-source voltage over the MOSFET of 6V. That would essentially accomplish our goal: the lamp would be dimmed. Another way to look at this, is that we’re tweaking the gate voltage until the MOSFET acts like a 12 Ω resistor between drain and source. Then the lamp and the MOSFET both get half the voltage.

What about power? Well, the MOSFET will have to have 6V across it, as we just saw. At 0.5A, this means that it will have to burn 6 (V) x 0.5 (A) = 3 Watts of power.

This is totally counter-intuitive: when we switch a lamp full on, the MOSFET will consume less than 0.1 W (as gleaned from the graph), but to dim it, that same MOSFET would need a heat sink!

There is some logic in this, though, if you think about it. The 12V supply voltage is a given. So if we want to apply less voltage to the lamp, we have no other choice but to waste the excess energy. Which is exactly what the MOSFET (or BJT transistor for that matter) will do. So although we’re reducing the total power consumption in this circuit by halving the current, we’re forced to do so by wasting power – as non-visible light, i.e. heat.

Can we do better? Yes, fortunately, we can.

This is where “pulse-width modulation” (PWM) comes in. Instead of eating up the excess power, we can take advantage of the fact that incandescent lights are fairly sluggish in their response. What we do is pulse the power on and of in very rapid succession. So the lamp will constantly heat up and cool down, and the result is that it won’t be burning at full brightness.

Why is PWM so incredibly useful? Several reasons:

we don’t need a way to generate a regulated analog gate voltage, we can simply generate digital on-off pulses with no extra circuitry needed
the MOSFET is again being used as pure on-off switch, and remains maximally efficient – so we probably won’t need a heat sink
power is no longer wasted, it is now effectively throttled instead – in very short and rapid bursts

It turns out that PWM works in a lot more cases than just incandescent light bulbs. DC motors are also sluggish, so controlling their speed with PWM also works extremely well. And better still, even LEDs work well with PWM, even though they respond instantly – because it turns out that our own vision is sluggish too!

See also an earlier post about PWM on this daily weblog.

So there you go. MOSFETs are the workhorses of power control, due to their incredible properties, and PWM is the technique of choice when it comes to throttling power devices (lights, heaters, motors, and more).

Easy Electrons – MOSFETs (and heat)

In Hardware on Feb 6, 2011 at 00:01

To continue this Easy Electrons series, this time I will go a little bit into MOSFETs.

To me, MOSFETs rank high up there, next to operational amplifiers as one of the foundation components in electronic circuits which are extremely useful and practical. The most amazing detail is that MOSFETs only exist since a few decades – newbies when you consider the time scale of most electrical components.

In a way, a MOSFET is like a BJT transistor. Even the symbol for it looks similar (from Wikipedia):

80px Igfet n ch enh Labelled.svg

This “N-channel enhanced MOSFET” type is the most common one, and like the NPN transistor, current flows into the top (D = drain) and comes out the bottom (S = source), all controlled by a third pin (G = gate).

One key difference between a BJT transistor and a MOSFET, is that a BJT is driven by current, whereas a MOSFET is driven by voltage. You feed a (small) current into a transistor to make it conduct, whereas you apply a (small) voltage potential to make a MOSFET conduct. The gate of the MOSFET doesn’t conduct current – it just senses the voltage. Bit like a capacitor.

You could say that a transistor is like a water wheel: you have to keep churning the crank to keep the water flowing through it. Whereas a MOSFET is more like a flexible tube: you pinch (well, “un-pinch”) to control the flow, but that pinch doesn’t consume energy. You could use a small mechanical clamp to maintain the pressure and keep the flow going.

This also explains why a transistor won’t conduct if the base is left unconnected (no current coming in), whereas a MOSFET could be doing anything when its gate is left unconnected, depending on how much charge was left when last connected. Early MOSFETs were in fact incredibly sensitive to static electricity – just touching the gate with a finger would often destroy a MOSFET. Nowadays, they are ESD protected.

MOSFETs are perfect for controlling large currents via a microcontroller. Even the weakest output pins can drive them, as long as the voltage is high enough. In the past, MOSFET’s needed at leat 4.5 to 5V to make them conduct, but nowadays voltages in the 2.5..3V range are sufficient in these so-called “logic-level” MOSFETs.

I’ll take the MOSFET Plug as example. It has two MOSFETs tied directly to two ATmega output pins:

Screen Shot 2011 02 05 at 13.35.58

Let’s look at a manufacturer’s datasheet for that “IRLZ34N” MOSFET, because there’s a lot of useful information in there.

The IRLZ34N datasheet is a great example. Seven pages, full of details, facts, graphs, circuits, pinouts, drawings, etc. It’s worth getting used to reading datasheets. They are loaded with info. To me, datasheets are the user interface of electronics. Give me a part number, and I’ll grab the datasheet to understand what it can do.

Here’s the first part:

Screen Shot 2011 02 05 at 13.42.00

logic level – aha! it can probably work with 3.3V
V_DSS – that must be the max switching voltage, 55V .. plenty!
R_DS(on) – will come to that in a minute
I_D – max current through the drain, a whopping 30 amps
175°C – looks like it can witstand scorching hot temperatures

Ok, there’s your helicopter view of this component. What I’m interested in is: will it be able to switch my <insert-some-high-power-device-here> ?

Well, we’ve seen the max voltage and current specs. But what really matters is power consumption. Because that’s the heat that gets generated, and that’s usually what breaks things.

Power is voltage x current (E x I). The voltage in this case is the voltage across the MOSFET. But we don’t know that – not directly. What we do know is its “RDS(on)” – this is the resistance between drain and source when turned on. Heh, how obvious. And exactly the value we want. It’s a mere 0.035 Ω.

Ohm’s law says V = I x R, so the voltage across the device is the current through it times its resitance.

Combine these two and we get P = E x I = (I x R) x I = I x I x R. Power consumption is proportional to the square of the current. Aha – that explains why large currents can be so destructive!

Let’s try this. Let’s go all out and push 30 amps of current through the MOSFET. Its power consumption will be 30 x 30 x 0.035 = 31.5 Watt. That’s a fair bit of heat (small lightbulb).

But will it work?

To find out, we need to do a thermal calculation. What’s going to happen to those 31.5 Watt of power? Well, they will come out as heat, but how much heat?

Time to look at another bit of info on the datasheet:

Screen Shot 2011 02 05 at 13.57.09

Let’s take the last value first: R(theta)JA, or Junction-to-Ambient thermal resistance = 62°C/W. In other words, each watt of power at the junction (i.e. inside the MOSFET package) will leed to a whopping 62°C temperature rise when the component is suspended in “ambient”, i.e. free, air.

Hmmm: 31.5 x 62 = nearly 2000°C. Yikes, our MOSFET is going to evaporate!

What we need to do is mount this part on a massive heat sink to make sure those temperatures are never reached, by drawing the heat away and keeping the MOSFET (relatively) cool.

Fortunately, there are two other values. The way these work, is that they tell you how much “heat resistance” there is when it flows away from the junction where all the heat is being generated. And it’s really easy to work with:

draw a picture of the MOSFET and how it’s mounted
find out the heat resistance in each step
add them up to get a combined °C/W value
re-calculate 31.5 x <that-value>
make sure it stays under the max temp you want stay under (175°C would be too hot for a plastic case, for example – or even for a printed circuit board)

I’ll use a quick example, just to see how far we can push our MOSFET. Let’s assume the MOSFET is mounted on a (very good) heat sink which has only 5°C/W. Then we add up: 2.2 (junction to case) + 0.5 (case to heat sink) + 5 (heat sink to air) = 8.7°C/w.

With 30A current, we get 30 x 8.7 = 261°C. Whoops, can’t be sustained without damage.

Ok, let’s aim a bit lower: 15 amps. Now the power consumption becomes: 15 x 15 x 0.035 = 7.9 Watt. Without heat sink: 7.9 x 62 = 490°C – still way too hot, but with heat sink we get 7.9 x 8.7 = 69°C.

This value is a relative value. It means 69°C above the ambient temparature. So in a 25°C room, the whole thing would become 94°C. Still very hot, but not a problem for the MOSFET!

In other words: take a MOSFET, mount it on a big heat sink, and you can see how a tiny little microcontroller could control a 15A light or a motor which has a 15A peak current. That’s what makes MOSFETS so magical…

Careful with heat sinks, though. To get it right, you really have to include all the paths to “ambient”. If you mount the heat sink in a big box (which can withstand 94°C), then the temperature inside will rise. And those 69°C we calculated will make the whole setup rise accordingly! – it doesn’t take much to get a “thermal runaway”: core heats up, ambient heats up, core heats up further, etc. Until disaster strikes. Not quite Tchernobyl, but hey… be careful.

Soooo… what started out as a MOSFET introduction, has turned into a power and heat calculation. As you can see, it’s not very complex. It’s not a bad idea to find out up front whether a power circuit will self-destruct or not. Now just add a 2x safety margin, and you should be OK. Or better still: build the circuit, and confirm that the results match these predictions, especially under stress and near design limits.

Ehm… I’ve swept a little detail under the rug:

Screen Shot 2011 02 05 at 14.22.04

These calculations assume that we’re driving the gate to 10V, but we’ll only be applying a feeble 3.3V or so. Whoopsy daisy. Let’s go into that tomorrow.

No time, yet

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

Heh, I bet this isn’t about what you thought the title suggested :)

I’ve been spending a couple of hours today, trying to get a DCF77 time code receiver working on the new ookRelay2.pde sketch. There’s a dcf77demo.pde sketch in the Ports library, which actually does all the hard work of decoding that pulse train.

It’s fairly tricky code, and I tend to throw in lots of tricky hacks (silly me, I know):

Screen Shot 2011 02 04 at 23.31.52

To use this, dcf77poll() has to be called often in loop(), like so:

Screen Shot 2011 02 04 at 23.14.35

(lots of #ifdef’s in there now, to make the sketch more configurable)

The weird thing is that this all worked fine in the previous incarnation of the OOK relay.

This timing code is far less critical than the 433/868 MHz OOK decoding, by the way. Pulses come in once a second, and all it needs to do is disambiguate short and long pulses. Easy stuff for an ATmega.

Except today… well, I don’t know why, but I can’t make any sense out of what’s happening. Been debugging with a few prints to the serial port via LEDs, but no luck. I’ve switched prototype setups, redone it all from scratch, changed DCF77 receivers… nada. Worst of all, there’s no pattern.

It’s probably the wrong moon phase, or somethin’ – I’ll revisit this some other time (soon).

Out of the woods?

In Hardware on Feb 4, 2011 at 00:01

Great, got a new batch of of ATmega328p’s in today:

Dsc 2450

(that’s a mix of ATmega’s and DIP sockets, btw)

With five hundred more in transit this very moment. No more worries!

So that’s a the end of a couple of months of supplier-anxiety :)

Then again, JeeLink and JeeNode USB stocks are low again. I don’t have good estimates on when those will be back in good supply. Am chasing a couple of options right now… for the time being, I can only point to JeeNodes plus assembly service as workaround, I’m afraid.

You can never win 100% at this atoms game, it seems!

Arduino, Network

Meet the RFM12B Board

In Hardware on Feb 2, 2011 at 00:01

With the RFM12B becoming a nice low-cost option for low-volume wireless communication, and the RF12 library proving to be a solid software driver for it, it’s time to generalize a bit further…

Say hello to the new RFM12B Board:

Dsc 2448

This board adds a voltage regulator and 3.3V/5V level conversions, to be able to use the RFM12B on 5V systems such as the various Arduino’s out there, the RBBB, … anything you want, really.

There are 8 pins on this board, of which the 8th is a regulated 3.3V supply which can be used in other parts of the circuit – the voltage regulator will be able to supply at least 100 mA extra on that supply pin.

The other 7 pins are:

+5V
Ground
SPI clock (SCK) – Arduino digital 13
SPI data out (SDO) – Arduino digital 12
SPI data in (SDI) – Arduino digital 11
SPI select (SEL) – Arduino digital 10
IRQ – Arduino digital 2

Just hook each of those up to an Arduino, and you can use the RF12 library as is!

Sample output:

Screen Shot 2011 02 01 at 22.08.14

Look ma, just like a JeeNode or JeeLink!

With an 8-pin stacking header and a bit of bending, cutting, and soldering two wires (I used a jumper wire, cut in half), you can even stick this thing right onto an Arduino:

Dsc 2449

But of course using a normal solderless breadboard and some wire jumpers will work just as well.

Note that this board can also be tied to 3.3V systems – just use the bare PCB (and short out three solder jumpers), which then becomes a breakout board for the RFM12B. No need to mess with the 2.0 mm pin/pad distance on the RFM12B module itself.

Docs can be found in the Café, and the kit/pcb is now available in the shop, as usual.

SMD lab supplies

In Hardware on Feb 1, 2011 at 00:01

With SMD becoming more and more common, I really wanted to get a supply of different resistor values – a bit like this binder with through-hole components:

Dsc 2443

So I decided to get 100 of each of the E12 series, thus named because it has 12 values per order of magnitude – spread out in a logarithmic scale: 10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82.

Here are all the values from 1 Ω to 10 MΩ:

Dsc 2439

Nothing fancy, but pretty low cost. And as a bonus: 0 Ω resistors! Don’t laugh, these can actually be quite handy as bridges over other traces. You could even use a single-sided PCB by adding a couple of these as “wire jumpers”!

Here’s the final result, as stored in the lab. I keep a set of 100 Ω, 1 kΩ, 10 kΩ, and 100 kΩ around for quick-and dirty uses, but this way all the usual values are available when I need ’em:

Dsc 2442

Each drawer has 3 compartments, with two values of the E12 series in each. So that’s two drawers per order-of-magnitude (“decade”), times 7, plus the extra 0 Ω and 10 MΩ. All that’s left, is to add a couple of labels on the drawers to quickly pick the right one.

Ready to do lots more experiments here at JeeLabs! :)

Network

Back-soon server

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

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

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

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

Screen Shot 2011 01 30 at 16.36.21

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

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

Dsc 2434

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

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

Screen Shot 2011 01 30 at 17.24.05

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

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

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

PS. I’ve put the back-soon server on-line as a test, it can be reached at https://jeelabs.org:8080/.

JeeNode, Network

EtherNode on a breadboard

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

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

Dsc 2432

And sure enough, it works as intended:

Screen Shot 2011 01 29 at 21.12.06

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

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

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

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

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

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

JeeNode, JeePlug, Home automation, Network

New OOK and DCF relay

In Hardware on Jan 29, 2011 at 00:01

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

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

Dsc 2429

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

Dsc 2430

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

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

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

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

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

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

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

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

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

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

JeePlug, Home automation, Network

Meet the OOK 433 Plug

In Hardware on Jan 28, 2011 at 00:01

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

Meet the OOK 433 Plug:

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

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

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

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

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

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

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

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

Enjoy!

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

Home automation, Network

OOK reception with RFM12B

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

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

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

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

Screen Shot 2011 01 25 at 14.16.36

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

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

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

Dsc 2427

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

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

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

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

Screen Shot 2011 01 25 at 16.42.14

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

Sample output:

Screen Shot 2011 01 25 at 16.56.39

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

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

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

Thermo Plug fix (v2)

In Hardware on Jan 26, 2011 at 00:01

Another day, another fix.

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

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

Screen Shot 2011 01 25 at 16.54.26

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

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

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

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

Onwards, again!

Carrier Board fix (v2)

In Hardware on Jan 25, 2011 at 00:01

This was looong overdue…

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

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

Dsc 2421

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

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

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

Onwards!

Easy Electrons – Transistor circuits #3

In Hardware on Jan 24, 2011 at 00:01

A third installement about transistors in this Easy Electrons series.

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

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

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

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

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

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

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

And now the other case:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Easy Electrons – Transistor circuits #2

In Hardware on Jan 23, 2011 at 00:01

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

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

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

Note that this is not the way to do it:

Screen Shot 2011 01 22 at 23.13.37

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

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

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

Screen Shot 2011 01 22 at 23.22.24

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

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

150px Darlington Configuration.svg

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

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

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

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

Uln 2803

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

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

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

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

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

Easy Electrons – Transistor circuits

In Hardware on Jan 22, 2011 at 00:01

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

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

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

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

Regulated power supply

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

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

Screen Shot 2011 01 21 at 23.48.09

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

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

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

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

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

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

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

But there is a catch: power consumption – again!

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

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

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

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

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

Easy Electrons – Transistors #2

In Hardware on Jan 20, 2011 at 00:01

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

Let’s look at that NPN transistor symbol again:

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

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

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

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

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

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

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

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

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

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

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

Screen Shot 2011 01 19 at 23.45.31

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

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

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

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

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

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

So what’s the problem? Heat!

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

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

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

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

Tomorrow, some real circuits!

Easy Electrons – Transistors

In Hardware on Jan 19, 2011 at 00:01

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

Transistors. Phew. Biiig topic!

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

Screen Shot 2011 01 18 at 23.32.33

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

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

So what does it do?

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

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

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

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

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

Screen Shot 2011 01 19 at 00.21.58

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

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

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

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

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

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

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

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

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

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

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

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

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

Stay tuned…

Two lousy caps

In Hardware on Jan 18, 2011 at 00:01

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

Dsc 2416

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

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

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

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

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

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

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

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

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

Oh well… one can always dream, right?

Touch screen mount

In Hardware on Jan 17, 2011 at 00:01

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

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

Dsc 2413

But how?

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

Dsc 2414

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

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

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

Kit with SMD parts

In Hardware on Jan 11, 2011 at 00:01

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

Dds 60 (top) 400a

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

Dsc 2394

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

Dsc 2396

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

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

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

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

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

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

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

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

Easy Electrons – Diodes

In Hardware on Jan 9, 2011 at 00:01

It’s time for some Easy Electrons again.

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

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

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

800px Diode 3d and ckt

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

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

Screen Shot 2011 01 08 at 22.40.28

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

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

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

Screen Shot 2011 01 08 at 22.40.40

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

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

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

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

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

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

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

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

Screen Shot 2011 01 08 at 23.03.19

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

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

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

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

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

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

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

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

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

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

LED discharge – measure or simulate

In Hardware on Jan 7, 2011 at 00:01

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

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

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

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

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

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

Whoa – very different outcomes!

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

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

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

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

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

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

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

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

Let’s recaclulate our results with this new insight:

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

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

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

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

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

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

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

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

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

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

Spice led Discharge

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

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

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

LED discharge – more measurements

In Hardware on Jan 6, 2011 at 00:01

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

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

Screen Shot 2011 01 05 at 13.09.50

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

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

Screen Shot 2011 01 05 at 13.10.55

The values are:

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

Here’s a graph of the resulting measurements:

Screen Shot 2011 01 05 at 12.42.29

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

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

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

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

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

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

Screen Shot 2011 01 05 at 12.50.33

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

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

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

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

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

Screen Shot 2011 01 05 at 13.45.46

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

Sample output:

Screen Shot 2011 01 05 at 13.47.05

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

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

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

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

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

Displays, Network

GLCD library

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

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

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

Screen Shot 2011 01 04 at 19.52.45

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

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

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

Screen Shot 2011 01 04 at 19.49.49

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

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

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

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

Screen Shot 2011 01 04 at 20.02.40

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

Screen Shot 2011 01 04 at 20.04.57

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

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

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

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

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

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

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

Update – all the code is now at https://git.jeelabs.org/jcw/glcdlib.

Thermo Murphy

In Hardware on Jan 4, 2011 at 00:01

Mr. Murphy strikes again in the new year…

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

Here’s the board footprint:

Screen Shot 2011 01 03 at 12.08.50

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

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

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

Screen Shot 2011 01 03 at 12.06.16

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

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

Pinouts

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

Screen Shot 2011 01 03 at 12.05.37

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

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

New wire jumpers

In Hardware on Jan 3, 2011 at 00:01

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

Dsc 2407

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

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

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

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

Easy Electrons – Need more power

In Hardware on Jan 2, 2011 at 00:01

Welcome to another installment of the Easy Electrons series.

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

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

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

Source Datasheet

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

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

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

Screen Shot 2010 12 29 at 10.20.57

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

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

200px Transistor 2.svg

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

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

So how do we control an LED strip?

Easy – with a MOSFET, for example:

Screen Shot 2010 12 29 at 10.33.02

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

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

Screen Shot 2010 12 29 at 10.33.14

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

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

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

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

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

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

Screen Shot 2010 12 29 at 10.42.01

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

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

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

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

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

LED discharge – PWM and DAC

In Hardware on Dec 30, 2010 at 00:01

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

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

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

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

Screen Shot 2010 12 29 at 23.28.11

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

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

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

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

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

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

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

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

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

To be continued, probably about a week from now…

LED discharge – it’s analog!

In Hardware on Dec 29, 2010 at 00:01

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

Screen Shot 2010 12 27 at 13.19.46

Here’s what happens:

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

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

Screen Shot 2010 12 27 at 16.25.41

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

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

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

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

Screen Shot 2010 12 27 at 16.31.01

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

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

Screen Shot 2010 12 27 at 16.55.46

Sample output:

Screen Shot 2010 12 27 at 16.53.43

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

Screen Shot 2010 12 27 at 17.03.29

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

Screen Shot 2010 12 27 at 17.05.39

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

Screen Shot 2010 12 27 at 17.11.14

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

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

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

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

LED discharge circuit

In Hardware on Dec 28, 2010 at 00:01

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

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

So let’s do it!

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

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

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

Dsc 2405

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

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

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

Here’s the same circuit, is schematic form:

Screen Shot 2010 12 27 at 12.24.48

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

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

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

Screen Shot 2010 12 27 at 12.37.42

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

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

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

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

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

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

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

Screen Shot 2010 12 27 at 13.19.46

Stay tuned…

Easy Electrons – Electric charge

In Hardware on Dec 27, 2010 at 00:01

Welcome to another installment of the Easy Electrons series.

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

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

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

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

The farad unit is awkward, though.

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

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

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

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

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

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

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

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

Screen Shot 2010 12 12 at 21.17.17

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

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

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

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

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

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

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

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

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

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

Easy Electrons!

Easy Electrons – Capacitance

In Hardware on Dec 26, 2010 at 00:01

This is the third installment of the Easy Electrons series.

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

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

Screen Shot 2010 12 12 at 16.26.53

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

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

Screen Shot 2010 12 12 at 16.26.43

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

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

Ok, so what is a capacitor, eh?

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

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

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

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

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

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

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

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

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

Screen Shot 2010 12 12 at 17.48.52

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

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

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

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

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

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

Screen Shot 2010 12 12 at 17.20.41

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

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

Screen Shot 2010 12 12 at 18.26.30

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

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

JeeNode, Displays

Touch screen

In Hardware on Dec 21, 2010 at 00:01

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

Whatiwrote

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

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

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

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

Connection

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

Tinyconnector

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

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

Calibrate 1

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

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

Easy Electrons – LEDs

In Hardware on Dec 19, 2010 at 00:01

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

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

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

Led Diagram

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

Screen Shot 2010 12 12 at 14.42.29

Here is the way you hook up a single LED:

Screen Shot 2010 12 12 at 14.47.06

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

So what’s that resistor doing in there?

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

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

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

Screen Shot 2010 12 12 at 15.09.35

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

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

Screen Shot 2010 12 12 at 14.47.16

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

So how do we solve this?

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

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

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

Screen Shot 2010 12 12 at 15.09.44

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

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

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

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

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

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

Easy Electrons!

Rethinking the Arduino hardware interface

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

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

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

Jlpcb 105

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

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

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

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

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

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

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

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

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

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

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

JeeNode, Electronics

Voltage: 3.3 vs 5

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

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

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

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

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

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

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

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

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

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

Mixing 3.3V and 5V devices

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

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

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

Screen Shot 2010 12 14 at 23.35.16

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

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

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

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

Screen Shot 2010 12 14 at 23.42.27

Ok, so now we can hook up signals to a JeeNode, even if they swing in the 0..5V range. This works best with “slow” signals, BTW. The extra resistor has a bad effect on rise and fall times of the signal, so don’t expect this to work with signals which are in the 1 MHz range or higher. Then again, it’s unlikely you’ll need to tie such fast signals directly to an ATmega anyway…

How about the other direction?

What if you have a chip running at 5V which needs to receive signals from a chip running at 3.3V, i.e. signals going in the other direction?

Well, it turns out that this may or may not work by simply tying the two lines together. The 3.3V output signal will definitely not damage a chip running at 5V. The worst that can happen, is that the 5V side doesn’t consider the signal valid.

We need to look into logic levels to figure this one out, as specified in the datasheet of the chip. The easy part is logic “0”, i.e. a low level. Most chips consider anything between 0 and 0.8V a logic “low”. There will hardly ever be an issue when tying a 3.3V chip to a 5V chip.

The tricky part is logic “1”, i.e. a signal which is intended to represent a high level. Now it all depends on what the 3.3V chip sends out, and what the 5V chip requires.

Most CMOS chips, including the ATmega, send out nearly the full power line voltage to represent a logic “1” (when the load current is low), so you can expect output signals to be just about 3.3V on a JeeNode.

On the input side, there are two common cases. Some chips consider everything above 1.6V or so to be a logic one. These chips will be perfectly happy with the JeeNode signal.

The only case when things may or may not work reliably, is with chips which specify the minimum logic “1” voltage to be “0.7 x VCC” or something like that. On a 5V chip, that translates to a minimum value of 3.5V …

Note that datasheets usually contain conservative specs, meant to indicate limit values under all temperatures, load conditions, supply voltages, etc.

In practice, I find that even with “0.7 x VCC”, I can usually drive a 5V chip just fine from a JeeNode. The only exception being higher power chips, such as stepper motor drivers and such, which operate mostly at much higher voltage levels anyway. For these, you may have to use special “level translator” chips, or perhaps something like the I2C-based Output Plug, which can be powered with voltages up to 50V or so.

This post only addresses digital I/O signals. With analog I/O, i.e. varying voltage levels, you will need to carefully review what voltage ranges are generated and expected, and perhaps insert either a voltage divider or an op-amp to amplify voltages. That’s a bit more involved.

But all in all, living mostly in a 3.3V world is often more flexible than living mostly in a 5V world, nowadays.

Which is the fourth reason why I decided to run JeeNodes at 3.3V, BTW.

Popping fuses

In Hardware on Dec 13, 2010 at 00:01

The power-line isolation saga continues…

Danger High Voltage alt 1 md

Ok, so the idea of adding an extra RCD device which trips on differences in current turns out to be a mistake. It adds no extra protection when used in the secondary winding of such a setup. I will leave it out.

Next step was to hook up the circuit as described in the above post. Soldered evertyhing in place, used heat-shrink tubing to isolate the loose ends, lots of hot-glue to fix things, and then:

Dsc 2398

POP, said the 5A “slow” fuse – and the next one too!

That’s not just a molten piece of metal, BTW, that’s a vaporized coating on the left. I suspect that the current was substantially over 5 amps. But no ill effect on the rest of the house, no lights dimming, and no other blown fuses (the main ones downstairs are all 16A).

Uh oh, something is wrong. Well, at least I now know the fuse works!

Here’s the plan again:

Ah, wait, not quite! … I have a transformer with dual secondary windings:

Screen Shot 2010 12 12 at 12.36.53

What I did was wire them up in parallel:

Screen Shot 2010 12 12 at 12.37.03

And that’s where I went wrong. Each winding generates an AC voltage. There are two ways to put them in parallel. Connect them right, and you get twice the power – connect them in reverse, and one will generate an AC voltage which is exactly opposite in phase w.r.t. the other winding. The result is not just a short circuit, but two power sources actively counter-acting each other:

Screen Shot 2010 12 12 at 12.42.00

Hence the blown fuses. I did not expect a 300 VA transformer to blow a 5A fuse, which implies its power draw was over 1100 watt – but that’s exactly what happened.

The solution is simple, once you step back and think about it. Instead of connecting the windings in parallel, I need to connect them in series:

Screen Shot 2010 12 12 at 12.37.11

(and the same on the other up-converting transformer too, of course)

Here’s the key: it’s still possible too hook them up the wrong way. But doing so will simply lead to no ouput, i.e. zero volts, instead of the desired double voltage output. But no blown fuse.

Once I made this change (which required a lot of undoing), I found out that the transformer secundaries were indeed wound the other way than their wires had initially led me to believe.

Problem solved!

I now have a working isolation setup which turns a 230.3V input voltage into a 230.9V output voltage under no load. An 80 watt test load worked fine.

P.S. I also gained more respect for AC “power”: such circuit mistakes are a different ball game from fiddling around with an AA Power board and getting all sorts of microcontroller- and sensor hookups messed up!

Easy Electrons – Resistors

In Hardware on Dec 12, 2010 at 00:01

A few days ago, I was completely overwhelmed by the positive response to a couple of posts about electronics principles such as power and circuit diagrams. Since I love to share what I’ve learned (and still learn) about this world full of discoveries, inventions, and creative engineering, I’ve been thinking about how to fold such a topic into this daily weblog.

The result is Easy Electrons – a series which will cover various aspects of electronics from the viewpoint of a technology enthusiast with a non-electronics background.

I’ve got some ideas about the frequency and topics for these posts, but I’m not commiting to a schedule or specific subjects just yet. Let’s see how it goes, and let me know what you think of these posts. Your comments will help guide me.

With that out of the way – let’s have some fun with electronics, eh?

But ya’ can’t run before you walk. This kick-off post has to go into some basic stuff. You may well know all this, but if in doubt, make sure you “get it”. Without these preliminaries, you will not be able to make sense of everything else in the upcoming posts of this series.

Resistance is not futile!

IMO, there is no concept more important in electrical circuits than resistance. One reason is that it’s everywhere, even the thickest copper wire has some resistance, however small. And an insulator, i.e. the stuff that prevents electricity from flowing all over the place, has essentially infinite resistance.

Take a voltage (or, using the water analogy: lift some water up). Once you let it “go”, it’ll want to flow. It does this using the path of least resistance. Thick solid copper pipe: huge current, massive power surge. Very thin wire: tiny current, squeezing its way through and heating up the wire. If the squeeze is strong enough (enough voltage) the wire will heat up to the point where Thomas Alva Edison made an incandescent light!

Voltage wants to flow. And when it does, it creates a current. It flows quickly when the resistance is low, it flows more slowly when the resistance is high, and it fails to flow when the resistance is infinite. That’s also why electricity will always pick a copper wire over plain air.

It’s time to introduce Ohm’s law:

    E = I x R

In words: voltage = current times resistance.

Voltage is described in volts (thanks to Alessandro Volta), current is described in amps (courtesy André-Marie Ampère), and resistance is described in ohm (due to Georg Simon Ohm).

I’ll simplify the world by saying: in simple cicuits with no effects from electric and magnetic fields, Ohm’s law is all you need to know. If you know any two of the quantities, you can calculate the third.

I won’t go into them now, but if you also learn the two Kirchoff’s circuit laws, then you’ll have some incredibly powerful tools to explain what’s going on, even in circuits with dozens of components, connected in all sorts of funky ways.

Physicists and chemists will be used to this, but if you come from the world of software, then note that these laws are really quite amazing: they let you predict what will happen when you hook up a circuit. Laws such as this were not “created” to terrorize kids in school, they are really extremely useful!

Let’s try it:

Screen Shot 2010 12 05 at 15.16.27

What’s the voltage on the right side? (assuming no load current)

I’m going to skip several details, but here’s how I would reason about it:

we want to know the voltage over the lower resistor
we know its resistance, so if we knew how much current is flowing, we could calculate it
the current flows through both resistors
the current IN is the same as the current OUT
so the same current flows through both resistors
we know the voltage over the total
if we knew the total resistance, we could derive the current through both
once we do, we know the current through the lower resistor
and from there, we can calculate the voltage, as requested

Question: what is the resistance of two resistors placed in series, one after the other?

Answer: this is one of those facts you’ll just have to memorize – resistance of R1 and R2 in series = R1 + R2.

so we have 9 volts over 3 kilo-ohm, i.e. 3000 ohm
the current is 9 / 3000 = 0.003 amps, i.e. 3 milliamps
voltage over 1 kΩ is 1000 x 0.003 = 3 volt

So the final answer is 3 volts.

But don’t stop there, please:

What if we use a 3V battery? Answer: (3/3000)*1000 = 1V.
How about a 12V power supply? Answer: (12/3000)*1000 = 4V.
See the pattern?

The two resistors act as a voltage divider. They don’t really “care” about the input voltage, they will simply divide it by 3. Because the ratio of the total to the lower resistance is (2+1)/1 = 3. This is also the reason why I drew that schematic in this particular way: it illustrates the voltage “drop”.

Hold on to that insight. Electric circuits usually have lots of voltage dividers. Whenever I see resistors in series, I try to determine what voltage is placed over them. And sure enough, most of the time, that’s what the resistors are used for. It works for any voltage. It also works for varying voltages: if you have an audio signal in the form a a rapidly varying voltage, then the voltage divider will simply pass the signal through, at a reduced voltage level.

Not every resistor is used as voltage divider. But more often than not, that’s all they do when used in series.

Easy Electrons!

P.S. Would you believe that I found out about this tutorial after writing the above? Heh… synchronicity :)

RCD finally in

In Hardware on Dec 10, 2010 at 00:01

Remember the weblog post about mains voltage and my plan to work on some circuits involving high voltage?

Well, with fear and trepidation I can announce that the missing link has finally arrived:

Dsc 2397

That’s an “Aardlekschakelaar” in Dutch, i.e. a Residual-current device.

People are probably either very thankful or very afraid of this thing, judging by the number of acronyms under which it is known: RCD, RCCD, RCCB, GFCI, GFI, or ALCI – take your pick!

An RCD continuously compares the current in with the current out, and breaks the circuit once the difference exceeds a certain threshold. I decided to get the most sensitive one I could find, which trips at 10 mA. I’m terrified of electric shock – especially the non-lethal kind… (no idea about the other variant, and I intend to keep it that way).

Ok, so it took over a month from ordering the RCD to getting it delivered – from a mail-order company here in the Netherlands, go figure. I’ll build the RCD into my super-duper isolation jig as soon as I find some time. I sure don’t want to fiddle with 230V while distracted or in a hurry.

Speaking of which…

There are a large number of people waiting for orders from the JeeLabs shop right now, for which I offer my sincere apologies. The reason is not really lack of time (well, maybe a little…), but the fact that stocks have run out on several items. I’ve got just about everything that’s missing on order right now, but in some cases my hands are tied because things don’t always arrive as quickly as promised or expected.

I’ve been refraining from sending out partial shipments, because it doesn’t really make much sense most of the time (sending out a JeeNode without the matching JeeLink, for example), and because it adds substantially to my overhead. Which is of course my own concern, but it also raises the chance of mistakes, something which I really want to avoid.

Not everything is in yet, but I hope to have just about all shipments ready by this weekend. Please get in touch if you’d rather have a partial shipment sent out soon, rather than waiting until next week. There will be no extra charges for such split shipments.

Crazy times around here. And the long-overdue server migration isn’t making it any easier!

P.S. Don’t get me wrong. I’m still working on quite a bit of fun stuff on the side, so let me finish this slightly panicky post with a little smiley anyway :)

No more diode!

In Hardware on Dec 6, 2010 at 00:01

The JeeNode v5 introduced a change, which I now regret – due to the amount of confusion it has generated, and the limited utility: an extra protection diode in the PWR line on the FTDI connector (and only there!).

Here’s the PCB layout, as seen in EAGLE:

Screen Shot 2010 12 05 at 17.44.49

The diode is marked “D1”, with a solder bridge on the back side of the board (red lines are on top, blue lines on the bottom, and plated-through holes are in green).

Here’s a close-up:

Dsc 2074

What it does, is block the power when it’s connected the wrong way around. But that only protects the FTDI connector, which is actually quite well protected agains reversal already (if you flip the connector, GND will go to the reset cap, which blocks all DC current anyway).

The drawback of this design is that it lowers the voltage by about 0.7V, so instead of 5V, you get about 4.3V on the remaining PWR pins, such as on all the port headers.

Worse still, is that it causes the JeeNode to stop working from a 3.3V power source, such as the AA Power Board, because it will drop the voltage to about 2.5V – which is too low to run at 16 MHz!

I did design a workaround into the JeeNode v5: there’s a solder jumper on the other side of the board, to bypass that diode. Where “bypass” means: short out the diode, as if it wasn’t part of the circuit in the first place.

The irony is that I’ve been closing this solder jumper on every new JeeNode I’ve built so far.

Add to that the fact that the holes for that diode are almost too small to push the thick diode wires through, and it becomes clear that this new “feature” causes more problems than it solves.

Starting now, once the stock of kits is exhausted, new kits will be shipped WITHOUT the diode!

You will now have to always add a drop of solder to close the jumper on the back:

Screen Shot 2010 12 05 at 18.04.03

If you don’t, there will no power connection from the FTDI header to the JeeNode.

It’s an important change, but it removes the nasty suprise that sometimes things work and sometimes they don’t!

Oh, and if you’re into this tradition – I hope you had a nice Sinterklaas!

Electric circuits

In Hardware on Dec 5, 2010 at 00:01

At the risk of prolonging this “electronics course” and boring everyone after the past two installments about power and switching regulators, here are some thoughts about electronic circuits.

I find the hydraulic analogy very useful, as long as you don’t push it too far. There is a (thick) book called Practical Electronics for Inventors by Paul Scherz (2007) which manages to construct analogies for just about all types of electronic components. It’s a stretch, but it does help understand things.

Here’s an example I found on the web:

Transistor

It’s quite easy to see how a small current can control a larger one. It also falls short, because “current” is really “pressure” in this case. My suggestion would be: do look at those analogies if you want to quickly build a mental model of how a specific component works, but keep the limitations of such analogies in mind.

The neat thing about electricity, is that you can completely understand a circuit by just applying a bit of logic. By which I mean: reason how it probably / sort-of works. And predict some of its behavior. It really pays to invest a bit in understanding electronics circuits.

There is a whole world to discover when you get into this. There are lots of conventions to figure out, but the neat thing is that these conventions are pretty much standardized by now. Electric circuits have been around for a couple of centuries, even if some of the newer components are only decades old.

Here’s part of the Infrared Plug, as a circuit diagram:

Screen Shot 2010 12 04 at 23.47.50

Even without knowing all the conventions, you’re probably able to guess many of the components. Connectors (PORT1, SV1), resistors (R1, R2, R3, R4), capacitors (C1, C2), a transistor (Q1), two LEDs (LED1, LED2), and a box marked “LM555D” which is an integrated circuit for building timers and oscillators.

How it works would be a bit of a long story for this post, but let’s make a guess:

C1 is charged up because it’s connected between + (VCC) and - (GND)
there are two resistors (R1 and R2) which limit the current flowing into it
the charge on C1 is measured through pin 6 of the chip (THR, i.e. threshold)
pin 7 (DIS, i.e. discharge) is actually an output, which can be either open or low

What the LM555D does (consider it magic for now), is watch the voltage level on THR. When it is low, DIS is not connected. The capacitor will charge up, until THR reaches a certain voltage.

At that point, the chip (through magic), decides to pull DIS low, i.e. put it at almost 0 volts, i.e. ground level.

While DIS is low, something completely different happens: with pin 6 being at a fairly high voltage, and DIS low, capacitor C1 will start to discharge, with current flowing into R1 in the opposite direction.

At some point, the THR voltage will be very low again, at which point the chip (magically) decides that it’s time to disconnect DIS. Then the cycle repeats: C1 will start to charge up through R1 and R2, etc… ad infinitum.

These 4 components are the heart of what is called an astable multivibrator.

We haven’t even looked at the rest of the circuit yet. I’ll leave it at that for now, just mentioning that the transistor is there to drive a strong current through the LEDs in a rapid ON/OFF pattern.

The components are dimensioned in such a way that this circuit oscillates at… 38 KHz. Which “happens” to be what most remotes send out as well.

There is a lot more to say about electric circuits, of course. I just wanted to point out that there is a huge amount of information you can glean from such “schematics” of various circuit diagrams.

Since everything made at Jee Labs is open source, you can dive into all of this. Look for the PDF’s linked on the various hardware pages if you’re interested.

It’s fun. It’s enormously informative. And unlike my use of the term “magic” there is really nothing special going on at all. It’s only magic until you dive in. If you have questions about how JeeNode pins are hooked up, for example: check out the manual (PDF). It’s all in there!

Update – for entertaining introductions of the main electrical components, there are a couple of short videos by Collin Cunningham on the Gizmodo website.

Bridge Board – caveats

In Hardware on Dec 2, 2010 at 00:01

There is some complexity lurking in the design of the Bridge Board, which in turn may lead to some head scratching, I’m afraid…

That complexity comes from the fact that not all I/O pins are always available.

Let’s start with an overview of the different pin groups:

Annotated bb

The basic idea is that when you connect all four port headers, then you’ll get access on the breadboard to all the pins marked above in RED. This is the most common usage, and main intended use of the Bridge Board. Note that DIO2, DIO3, AIO2, and AIO3 are available on multiple pins.

So if you follow yesterday’s post, you can use all the pins shown in red as is. The main benefit being that you can easily access the main 8 I/O pins, and that port 2 is in fact replicated in the same layout on the breadboard if you want to hook it up to JeePlugs.

If all you need are the leftmost 16 pins – you can skip the rest of this post.

The remaining pins takes a bit more explanation and preparation, and requires adding some more header on the Bridge Board as well as on the JeeNode! – here’s the summary:

to use the 6 SPI/ISP pins marked in BLUE, add the 2×4 pin header on the right
to use 4 more I/O pins marked in GREEN, add a 8-pin header on the left (the middle 6 are actually enough)
to use FTDI, add the 8-pin header on the left (only JeeNode v4: also the 2×4-pins on the right)

That last option also requires soldering in a 0.1µF capacitor if you want to include the reset-on-open capability for easy uploading. It’s mostly intended for use with a JeeSMD, which does not have an upload capability of its own.

There is a reasoning behind all this madness:

The leftmost 16 pins on the breadboard were the main design goal for this board.
The middle 13 pins (IRQ to B0) match the layout need for the Ether Card.
The rightmost 20 pins are compatible with both Ether Card and Carrier Board.
The Bridge Board is compatible with JeeNode v5 and v4, JeeNode USB, and JeeSMD.

The two LEDs are brought out on separate pins and always available – on the LED1 and LED2 pins, respectively. They are very efficient and require only a few mA to shine brightly. You can hook them up to any I/O pin or other 3.3/5V signal on your breadboard. They make a great debugging tool when the going gets tough.

The push-button at the top of the board is also always available on the BTN pin. It is connected to ground, so pressing the button shorts the BTN pin to ground – you can use the internal ATmega pull-up and some software debouncing to read out this button.

The button can be used as reset button if you have the RST pin, which is right next to it, hooked up to the JeeNode. This requires either the 8-pin PSIX header or the 2×4-pin SPI/ISP header to be hooked up, as described earlier.

Assembling the Bridge Board

In Hardware on Dec 1, 2010 at 00:01

This is going to be one of those long posts again, with lots of pictures…

I’ve switched to a new Bridge Board v2 revision, which differs only in some minor ways from the BB v1, so this also applies to that board. The changes are:

the FTDI connector orientation has changed to match the underlying JeeNode
one extra breadboard pin on the right, to better match the large breadboard
minor tweaks to layout and labeling

Since this is an assembly guide, let’s start with the parts included in the kit:

Dsc 2368

And here’s what we want to end up with – a module which plugs into a breadboard:

Dsc 2381

Ok, let’s get started… there are two current limiting resistors for the on-board LEDs. I prefer to mount them on the bottom of the board, because that leaves the “1” and “2” labels clearly visible on top:

Dsc 2369

Everything else is soldered on the top side of the board. Let’s start with the LEDs. These are polarized, so make sure to insert them properly:

Dsc 2370

The only other component left is the push-button:

Dsc 2371

Congratulations! All that remains is to solder on the various pin headers.

Meet the DC Motor Plug

In Hardware on Nov 30, 2010 at 00:01

Here’s a new I2C plug to drive two small DC motors. The DC Motor Plug has 2 H-bridges on board, which can drive each motor in forward or reverse. An additional 4 I/O pins are available, for limit switches, quadrature encoders, whatever:

Dsc 2310

Here is a test setup with a couple of (different) geared motors, driven from a 4x AA battery pack, plus the usual AA Power Board for the JeeNode itself (these could also have been combined):

Dsc 2309

All I/O is done via I2C, using the MCP23008 expander chip (same as used on the EP, LP, and OP plugs).

Here is a sample sketch called dcmotor_demo.pde which briefly drives each of the motors in both directions:

Screen Shot 2010 11 29 at 13.02.38

One notable detail about this plug is that it uses TC4424 chips which are in fact not DC motor drivers at all but MOSFET drivers… it turns out that these are also well suited for small DC motors, and should be able to handle up to 1.5A @ 4.5..18V.

A small bipolar stepper will probably also work, but I haven’t tried that yet. This board has a jumper to select between I2C addresses 0x26 and 0x27, so two of these can be daisy-chained on a single port.

Speed control should be possible using software PWM, but not at very high rates, since the I2C bus will be the limiting factor.

One use for this in the context of home automation would be to drive small highly-geared 12V motors to adjust the position and raising/lowering blinds.

Action!

Docs added to the café and kit in the shop, as usual.

Techniques, Network

Ethernet web client

In Hardware, Software on Nov 29, 2010 at 00:01

The Ether Card and the associated EtherCard library offer an easy way to connect a JeeNode to a LAN and internet. I consider this option useful enough to even want it within reach on a breadboard, so I designed the Bridge Board to support it as well. Here’s the setup, based on a JeeNode Experimenter’s Pack:

Dsc 2365

This is all it takes for an Ethernet-connected setup, and all JeeNode ports are still freely available for project use.

However, the EtherCard library only includes some examples for the web server approach, such as the EtherNode. What about using this setup to send requests out, and POSTing results to a remote web server?

Well, encouraged by a few great DNS-related patches to the code by Gérard Chevalier, who was also so kind to show me how he does DNS lookups and web requests, I’ve come up with two new example sketches:

The getStaticIP.pde sketch does just a HTTP get to a fixed IP address.
The getViaDNS.pde sketch looks up my server’s IP address by name, via a DNS lookup on startup.

Here is the code of getViaDNS:

Screen Shot 2010 11 27 at 15.38.35

Note that to make any kind of outgoing request outside your LAN, the IP address of the local LAN gateway has to be specified at setup time.

The dependency on the Ports library is due to the use of the MilliTimer class in this code. And because of that, the RF12 library also needs to be mentioned (it won’t increase the code size). Welcome to dependency hell…

Here is some sample output:

Screen Shot 2010 11 27 at 15.29.28

Even though this example is relatively short, I still find it quite awkward. The EtherCard library code really needs a major overhaul – far too much of the underlying mess is still being exposed for no good reason, IMO.

Furthermore, a massive code cleanup will be needed to overcome the current limitations of the EtherCard library: the need for a large RAM buffer, and the limitation that TCP requests and replies may only use a single ethernet frame (approx 1500 bytes).

But getting it working first was more important, and with these new examples you can now see how to implement outgoing TCP/IP requests (not just web/http, btw). Pachube, anyone?

Sensors, Home automation

Meet the new Room Board v2

In Hardware on Nov 28, 2010 at 00:01

For some time now, the Room Board kit has been outfitted with a new PIR sensor:

It’s nicely low-power, but unfortunately it has a pin-out which differs from the ELV model, even with 3 pins!

So I’ve decided to make a new Room Board v2, which drops support for the 8-pin ePir to allow the new PIR sensor to be mounted in two different ways.

Here’s the board, with a solder drop already applied for the SHT11 (much easier to solder it in that way):

Dsc 2345

Things have been moved around a bit, but the basic setup hasn’t changed. The 3 pins in the top left are still for the ELV PIR, and the 1-wire DS18B20 option is still there (with fixed pinout, yeay!).

Here is the board with SHT11 and LDR soldered on:

Dsc 2348

And here are the two ways to attach the new PIR sensor:

Dsc 2350 Dsc 2349

That second setup is the most compact, but also the most inconvenient one if you ever need to make changes or reach the headers. Note that the PIR pins were soldered in as far out as possible, and that the LDR was bent sideways a bit:

Dsc 2354

I would advise to use the first setup where possible.

Having said that, here’s a complete Room Node with the (relatively) “compact” layout:

Dsc 2355

Bit of a hodge-podge, but that’s what you get when everything is kept modular.

GLCD on battery power

In Hardware on Nov 27, 2010 at 00:01

I’m going to switch to a different type of graphic LCD once the next batch of Graphic Boards arrives. Instead of a white-on-black type, the new GLCD will be a blue-on-sort-of-blueish color:

Dsc 2356

The reason for this is that it is still quite readable without the backlight:

Dsc 2358

There is a solder jumper on the Graphics Board, to choose between powering the backlight continuously via PWR, or having it powered under software control, via the not-often-used IRQ pin. This not only lets you turn the backlight on and off, but even dim it under software control, because the IRQ pin supports PWM, i.e. analogWrite().

The above display draws about 280 µA without backlight right now, which means it will keep running for over a month on a single AA cell, using the AA Power Board. There are probably ways to reduce that current consumption further, as I’m not doing anything yet with the ST7565’s standby and other low-power modes.

And although it may not be practical for a permament display, this definitely is useful for something I’d like to have around and use on a regular basis. By sending it stuff to display over wireless, this setup can support what is quickly becoming my favorite mode of operation here at Jee Labs: no wires cluttering my desk!!!

Sensors, Displays

2-channel Logic Analyzer

In AVR, Hardware, Software on Nov 25, 2010 at 00:01

Let’s continue the tiny lab-instrument series ;)

Here’s a logic analyzer which takes 512 samples of 2 bits (DIO2 and AIO2):

Dsc 2318

The “trace” starts when either of the inputs changes. I’ve enabled the internal pull-ups, so in this example you can see that DIO2 has no signal. The AIO2 signal is from a JeeNode running the Arduino IDE’s built-in “ASCIItable” demo, which sends out a bunch of characters at 9600 baud (I took the signal from the USB-BUB connector).

Here is the glcdTracer.pde sketch which implements this:

Screen Shot 2010 11 20 at 17.24.06

Lots of trickery with bits. To keep memory use very low, I’m storing the 512 samples in a 128-byte buffer (512 x 2 bits = 128 x 8 bits). Low values are drawn as a pixel, high values are drawn as a little vertical line.

The code includes a minimal triggering mechanism, i.e. it waits for either of the input signals to change before collecting 512 samples.

Samples are collected at about 10 KHz, but this can easily be changed (up to ≈ 200 KHz with the current code).

Note that it would be possible to double the number of samples to 1024 and display them as 8 groups of 2 signals, but then you’ll have to really squeeze the output to fit it onto the 64×128 pixels on the display.

BTW, there’s some shadowing visible on the display – has to do with how the chip drives the GLCD, no doubt.

Soooo… now we also have a portable Logic Analyzer!

More box options

In Hardware on Nov 24, 2010 at 00:01

Here are a few more options for putting JeeNodes in a box which turn out to work really well:

Dsc 2316

Of course anything larger will fit as well, but I wanted to find out which boxes would be just enough for a JeeNode. As it turns out: several!

These boxes are all available from Conrad, which has an online shop in several European countries. I’m not going to stock them for two reasons: 1) there are just too many choices, and everyone has different needs and preferences, and 2) they won’t fit in an envelope. So to get them, you’ll have to order from Conrad yourself.

The good news is that all these boxes are very inexpensive.

Below is a summary of each one shown above, along with the Conrad order numbers and external dimensions.

#534347 – 85x56x25 mm

The smallest box of ’em all. The JeeNode PCB fits in any of the slots, but you need to make a small notch on the inside of the top cover:

Dsc 2311

#534346 – 85x56x39 mm

A taller version, same color and same perfect fit for a JeeNode (as with the previous box, the FTDI pins need to point up, not out). No need to adjust the cover on this one:

Dsc 2312

#530113 – 88x58x30 mm

This one is slightly larger on the outside, but the sides are slanted and the board only fits by slightly enlarging the plastic notches inside. There’s a small hole in one of the shells:

Dsc 2313

However, there’s also an optional PCB for it with copper islands on one side (#530126). Then the JeeNode can just sit on top as is:

Dsc 2317

#520861 – 90x60x51 mm

On the large side, and fairly high. The JeeNode won’t fit in tightly, so you’ll need to fasten it somehow. This box could almost include a 3x AA battery holder with switch, but to do so you’ll need to remove some plastic inside on all 4 stand-offs:

Dsc 2314

#528373 – 124x72x30 mm

This box is almost identical to the Jee Labs box, but it’s transparent, it has slightly smaller inner dimensions, and there are no slots to slide the Carrier Board into. You can either shorten the pcb a fraction of a millimeter or make some very shallow grooves on the inside of the box to hold the pcb in place:

Dsc 2315

This box also comes in BLUE (#528834), RED (#528347), and GREEN (#528360).

Don’t know about you, but I’m pretty sure I’ll find a good use for each of these little boxes around here…

Sensors, Displays, Oscilloscope

100 KHz DSO

In AVR, Hardware, Software on Nov 23, 2010 at 00:01

You might have been wondering why I created the digital-to-analog converter a few days ago.

Well, because I needed a test signal… to build this thing:

Dsc 2307

You’re looking at a <cough> Digital Storage Scope </cough> with 100 KHz bandwidth :)

First of all: please don’t expect too much. There is no signal conditioning and no triggering whatsoever, and there are no external controls. This is simply a JeeNode plus a Graphics Board. It’s using the built-in ADC, with the conversion clock pushed quite a bit higher than what the Arduino’s analogRead() function will do. This speed comes at the cost of conversion accuracy, which isn’t so important since the Graphics Board display only has 6-bit vertical resolution anyway.

The screenshot shows a 1 KHz sine (from that Bleep! thing, obviously). As you can see, one cycle more-or-less covers the entire x-axis. So that’s about 128 samples per millisecond. This is not the maximum value, the ADC can also work twice as fast – i.e. with a division factor of 4 (ADPS2:0 = 2). This translates to 4 µs per sample.

Using the Nyquist–Shannon sampling theorem again, you can detect a frequency if you sample it at least twice per cycle, so that would have to be a cycle of at least 8 µs, i.e. over 100 KHz. Which is why I decided to call this thing a 100 KHz DSO :)

The code tries to get as many samples as possible into a little 128-byte buffer before doing the rest of the work. The graphics display has a fairly limited response time, so I’m refreshing the display at 5 Hz (it’s still visible up to 50 Hz, but only just…).

I find it pretty amazing what an MPU such as the ATmega can do these days, with just a few lines of C code. Here’s the entire glcdScope.pde sketch:

Screen Shot 2010 11 19 at 02.58.10

The rest of the code is in the same modified ST7565 library as used in the past few days.

There’s lots of room for expansion, this code uses less than 4 Kb.

So there you have it – a very crude, but functional, oscilloscope!

Bleep!

In AVR, Hardware, Software on Nov 21, 2010 at 00:01

Puzzle for you – what is this thing?

Dsc 2301

Maybe the demo sketch helps?

Screen Shot 2010 11 18 at 12.25.23

Answer: it’s an 8-bit digital-to-analog converter, using an R-2R ladder network (with 10 kΩ & 20 kΩ resistors).

The above toneGen.pde sketch generates a sine wave of approx 1 KHz:

Screen Shot 2010 11 18 at 12.25.17

There’s lots of ways to improve on this and turn it into a general-purpose function generator for example.

The interesting part is that all four ports are used for the required 8 I/O pins, and that due to the regularity of the pin assignment, they can all be set at once with very little code. The pin assignments for the DAC are:

bit 0 = AIO1
bit 1 = AIO2
bit 2 = AIO3
bit 3 = AIO4
bit 4 = DIO1
bit 5 = DIO2
bit 6 = DIO3
bit 7 = DIO4

The maximum attainable frequency is about 1.84 Khz with this software approach (1.95 KHz with the sine256 table placed in RAM), but that’s only if you use all 256 steps of the sine wave. The loop itself runs at about 1.84 * 256 = 470 KHz, so based on the Nyquist–Shannon sampling theorem, it should be possible to generate decent signals up to well over 200 KHz. The trick is to increment the “index” variable by larger values:

Screen Shot 2010 11 18 at 12.54.06

Here’s the corresponding output:

Screen Shot 2010 11 18 at 12.55.31

Still a pretty decent sine wave, so 16 resistors are all it takes to cover the entire audible frequency range.

By using fixed-point calculations for “fractional indexing”, you can get even more fine-grained control over the frequency of the generated signal. The following version generates an 8.01 KHz sine wave on my setup (note that “index” is now a 16 bit unsigned integer):

Screen Shot 2010 11 18 at 13.03.55

Update – I’ve changed the main loop to avoid the calling overhead of loop() itself. That increases the maximum attainable frequency by another 50%. Note that interrupts must be disabled to produce a clean tone.

JeeNode, JeePlug, Displays

Indoor temperature, etc.

In Hardware, Software on Nov 20, 2010 at 00:01

Here’s a fun little project…

A Graphics Board with a JeeSMD and two plugs: a Pressure Plug and a partially-populated Room Board.

The result is a geeky little indoor environmental monitoring station:

Dsc 2293

Couple of notes here:

I took the lazy way out and merely display the info as text, graphics would be so much nicer!
Both sensors can read the temperature, but as you can see, they don’t fully agree…
I added the FTDI hookup and used it to power this thing via an AA Power Board.
The AA board does double duty, as a little stand to hold this thing slanted upwards.

Adding FTDI was very useful in this case, since it also makes it possible to re-program the JeeSMD, which has no FTDI connector on board. All it needs is a 0.1 µF cap and the 6-pin header:

Dsc 2298

But there’s more to it than that, alas: to be able to upload to the JeeSMD, you need to hook up all the headers on the JeeSMD, i.e. also the PSI and the SPI/ISP headers. Adding those after the fact is very tricky, since you can’t reach the back of the Graphics Board pcb anymore if you soldered the LCD on permanently – as I did.

I had to solder the female headers slightly higher, to just barely reach the pins from the top with a very fine soldering iron tip (I use 0.4 mm). It worked, but as a result, the JeeSMD sits a bit higher on its pins than usual:

Dsc 2297

Here’s the indoor.pde sketch, also added to the Ports library:

Screen Shot 2010 11 17 at 22.47.37

Onwards!

Thermo Plug mismatch

In Hardware on Nov 18, 2010 at 00:01

The Thermo Plug was recently updated as a kit with a thermocouple for use as Reflow Controller, for example.

It uses screw terminals to connect the K-type thermocouple, because that wire can’t be soldered – I tried, really hard! Besides, you don’t want to add too many weird amalgamated cold metal junctions in this setup, which is all about the tiny voltage potential between different metals.

The whole thermocouple works nicely, but I goofed a bit on the connector: the screw terminal I got for this plug is slightly too big to fit on there in the intended position:

Dsc 2289

Yuck … two solutions:

solder it on anyway, and just ignore that tower-of-pisa effect…
solder it on the other way, and insert the thermocouple wires from the board side

Here’s how that will look:

Dsc 2290

Slightly odd, but it’ll work just fine of course.

Note that the back side of this screw terminal has two holes, but they cannot be used to insert wires, because those will end up too high and wouldn’t be held tight by the screws:

Dsc 2291

I’ll look around for a slimmer form-factor 3.5 mm screw terminal. If I can’t find any, then I’ll plan a board revision – but for now, it’ll have to do.

With a small nod to Mr. Murphy…

Displays, Techniques

Assembling the Graphics Board

In Hardware on Nov 16, 2010 at 00:01

This is going to be a weblog post with lots of pictures…

The Graphics Board is easy to assemble, but there are two things to watch out for:

the polarity markings for two of the electrolytic 1µF caps are reversed
if you solder the display onto the board, then you can’t easily reach the back anymore

The former is a mini goof-up by yours truly, the latter is something to keep in mind when deciding which headers you are going to use (you can side-step the issue by mounting the display using headers, but that will increase the height of the entire stack).

Here goes. As usual, I’m going to proceed from low to high-profile components, because that lets you put the components in, flip the board over, and press on it to get the components soldered closely to the board.

First the 100 Ω backlight series resistor:

Dsc 2251 2

Note that there’s a solder jumper right above it. The default is to connect the middle pad with the leftmost pad marked “P”. This connects the backlight permanently to the PWR line. If you want to control the backlight through the IRQ signal, you can set the solder jumper to the “I” position instead (see the backlight() docs). This can be changed later if you change your mind.

Then 5 yellow decoupling caps. These are not polarized, but make sure you put them into the right holes:

Dsc 2249

Update: The latest kit version ships with ceramic capacitors replacing the electrolytic capacitors. This gives longer life and simplifies the construction detail since these capacitors are not polarised. See the Wiki for more detail

The next step needs some care, because these two electrolytic caps are marked the wrong way on the silkscreen – they should be placed as follows:

Dsc 2251

The proper way to connect these, is to put long lead on the right and on the bottom, respectively. Or, same thing: put the gray stripes of the plastic case insulation on the left and on the top.

Note: the two caps on the left will only just barely fit when a JeeNode v5 is added on later. If you use a JeeNode v4, it is probably better to place them flat on their side pointing left. When in doubt, make sure you check the mechanical layout before soldering these two leftmost caps!

The other two 1 µF caps go as indicated on the board, they will in fact be oriented exactly opposite to the caps right next to them:

Dsc 2252

JeeNode, Displays

Meet the Graphics Board

In Hardware on Nov 15, 2010 at 00:01

Sometimes, 2×16 characters (or perhaps a few more) just don’t cut it, when I’d like to present things graphically, or use larger fonts for some of the info. That’s when a “GLCD” would be handy, one which lets you set individual pixels, that is. I was pointed to a nice low-power 128×64 display recently, and decided to create a pcb for it – so here’s the new Graphics Board:

Dsc 2258

Due to the size of the board, it’s not a plug or an add-on to a JeeNode, but the other way around: you can take a JeeNode, JeeNode USB, or JeeSMD, and push it onto this board to power and drive the display.

Ports 1 and 4 are used for the diplay, but ports 2 and 3 are available, and brought out in such a way that plugs can easily be added on. To make a clock, add an RTC Plug. To add a few touch buttons, add a Proximity Plug. To create a fancy Reflow Controller, add a Thermo Plug. Or just use it as is and add a sketch to display messages received over wireless. Endless possibilities…

Here’s the display in action, it’s pretty bright when driven from 5V:

Dsc 2278

It can display up to 8 lines of 21 characters, but it’s also fully graphical of course. BTW, in real life the display looks much more white-on-black.

I particularly like this setup, using the AA Power Board to make this thing completely self-powered:

Dsc 2245

The backlight resistor is chosen such that on 3.3V, this display draws ≈ 6 mA, and on 5V it draws ≈ 19 mA. It will last a few days with an AA Power Board, but when the 100 Ω resistor is replaced by 270 Ω or even 470 Ω, you can get well over a week of battery life on a single AA (assuming the JN itself is sleeping most of the time) – at the cost of dimming the backlight to a fairly low level.

There is a solder jumper on the board which normally connects the backlight to the PWR line. By connecting it to the IRQ line instead, that pin can turn off the backlight under software control (or dim it, using PWM).

The display is based on the ST7565 chip and can be driven by Limor Fried’s great ST7565 LCD library. Note that this library uses a 1 Kb RAM buffer.

Here’s the glcd_demo.pde sketch which generates the above display:

Screen Shot 2010 11 14 at 17.20.36

I included logic to put the ATmega and radio into power down mode to let me measure the display’s current consumption. While active, they draw another 5..30 mA.

The Graphics Board is now in the café and the shop.

Update – Here is a copy of the ST7565 code I use.

Meet the Infrared Plug

In Hardware, Software on Nov 12, 2010 at 00:01

The new Infrared Plug needed a small adjustment to work, but now it’s working properly. Here’s my hand-soldered prototype:

Dsc 2243

Fits on any of the JeeNode ports, of course. The DIO pin controls the IR output, which is pulsed at 38 KHz (38.28 KHz on my unit, more than close enough). The light is generated with one or two IR LEDs. With one LED, the peak current is ≈ 50 mA (a bit high for the AA Power board) – with two LEDs, the current is ≈ 10 mA. That will no doubt have a lower range, but you could tape one of the LEDs onto a specific appliance, while still letting the other one shine into the room (or a second device).

The input is a 38 KHz detector, with its signal available on the AIO pin.

The “InfraredPlug class” in the Ports library makes it easy to interface to this plug, as described in recent posts.

I’ve also added an “ir_repeater.pde” demo sketch, which repeats any NEC command it receives three times, at 1-second intervals. When I press “Forward” on my Apple Remote, it’ll end up skipping 3 extra songs forward. Can’t quite think of a use for that, but it helped me flesh out the bugs:

Screen Shot 2010 11 11 at 18.16.58

There is a bit of logic in there to convert the incoming slot count to a bit pattern.

Sample output:

Screen Shot 2010 11 11 at 18.16.51

The Infrared Plug is now in the café and the shop.

Parallel port UltiMaker

In Hardware on Nov 11, 2010 at 00:01

I’m currently building the Mantis – a little CNC router designed specifically to help create custom PCB’s. Actually, mine will look more like this.

I’m not convinced yet that this thing will be able to do PCB isolation routing, but I’m willing to give it a try. It’d make it much simpler to do one-off’s, instead of having to live with this:

But I’m not quite willing to dedicate an Arduino Mega and the UltiMaker electronics that is offered as option in the workshop. If you’re interested in 3D printing: the UltiMaker is derived from the RepRap and the MakerBot CupCake, as described here.

So instead of following everyone using the MPU-based approach, I’m going to re-use my parallel-port laptop running the EMC2 software, and let the laptop do all the work, instead of yet another dedicated board. I can always switch to a microcontroller setup later if this machine is practical enough to use it frequently. And if it doesn’t work out, my investment will have been relatively low.

There’s also a second reason for doing it this way: I’d like to build my own electronics for this CNC/3D stuff one day. I think there are better ways to do this sort of thing, more modular, more extensible, and more flexible (why not Ethernet? why not closed-loop servos?). But it wouldn’t be realistic to think I can take on that challenge as well, with everything else also going on at Jee Labs. So for now, the parallel-port shortcut will have to do.

Driving CNC stepper motors from a parallel port is a proven (but by now somewhat outdated) concept. Either way, it all ends up doing the same thing: executing the CNC world’s de-facto standard G-Code scripts.

You still need stepper motors, and stepper motor drivers, since a parallel port can only send out feeble 5V signals.

To save some time, I decided to try something a bit whacky by re-purposing an UltiMaker electronics board to hook up its motor drivers to the parallel port:

Screen Shot 2010 11 10 at 17.49.08

Lots of stuff on there I won’t need: heater control, extruder control, PWM…

Here’s a minimal setup, using just 3 stepper drivers and a little JeePlug board sitting on top of some extra headers on this board:

Dsc 2242

I patched a 5V regulator (plus LED) on there to feed the logic levels of the Pololu stepper drivers, and left everything else off, basically. Only thing left to do is wire up 7 signals + ground between the parallel-port breakout board and the JeePlug.

And then figure out the software side of things…

Almost, but not quite

In Hardware on Nov 9, 2010 at 00:01

There’s a new Infrared Plug in the works – it’s almost ready. The IR transmitter uses the venerable 555 chip:

Screen Shot 2010 11 08 at 20.36.42

I used the formulas from the datasheet to calculate the different resistor and capacitor values to arrive at 38 KHz, which is the most common IR frequency (and which most 36 and 40 KHz systems will pick up as well).

To check things out, I hooked the plug up for constant oscillation (DIO to +3V):

Dsc 2235

Despite using 1% parts for all the timing critical components, the output isn’t quite what it should be:

Screen Shot 2010 11 08 at 20.33.12

That’s 35.5 KHz … i.e. almost 10% off target!

(note that I measured the signal across the transistor – the IR current is actually the opposite, i.e. fast rise time)

I’ll have to tweak one of the resistors empirically (16.0 kΩ i.s.o 17.4 kΩ seems to fix it) and order some new SMD values. And then I need to check that the frequency across multiple plug builds will remain within bounds.

Not quite back to the drawing board (the PCB seems to be ok), but still: back to the soldering iron!

JeeNode Experimenter’s Pack

In AVR, Hardware on Nov 8, 2010 at 00:01

Neat – it looks like JeeNodes are starting to become popular for workshops!

I’m not really surprised: it’s more fun than an Arduino, IMO, because you get to learn the basics of electronics and soldering, and of course every JeeNode comes with wireless connectivity built-in. As I’ve said before, making things happen by wireless is a bit like magic…

FWIW, there are a couple of workshops scheduled for this month (“in-house”, i.e. for a specific audience, and I’m only indirectly involved), all are based on either a JeeNode or an RBBB. Both are well suited for solderless breadboards, which – if you ask me – is one of the greatest inventions ever for tinkering and learning electronics. Sure, soldering works best when the circuit is known and proven, but nothing beats a breadboard, some jumper wires, and a bunch of components and chips to try out things!

This gives me great satisfaction. No, not for the money side of it (it’s all discounted anyway), but because I find nothing more exciting than to see people try out new fun stuff and nurture their tech geek sides :)

Learning is great: if you’re young, it’ll make you wiser – if you’re old, it’ll make you younger … (and it’s fun!)

The big question is always: “what do I need to get started?” – and my answer is usually: “it depends on what kind of adventure you’re after”.

I’ve come up with a new “JeeNode Experimenter’s Pack” to create a baseline for the future. That way, it will be easier for me to set up and document my experiments, knowing that there is a common baseline on which to build. It’s also the logical step after this rubber-band concoction. It consists of the following key components:

Dsc 2221

In prose:

a JeeNode v5 kit (all through-hole components, a proven design by now)
a Bridge Board kit (solder a few components and a few headers)
a USB-BUB (solder one header and one jumper)
an AA Power Board (SMD parts already pre-assembled)
a large solderless breadboard
50 flexible wire jumpers
a USB cable (not shown)

In addition, and only in combination with the rest of the Experimenter’s Pack, I’m throwing in a little 10×17 cm laser-cut wooden base and an LDR to get started with some sensor experiments:

Dsc 2220

The base turns the whole thing into a self-contained “project platform” for all sorts of experimentation. And the AA Power Board will supply 3.3V to make this setup portable and usable anywhere. The rest of the empty space is all yours. That’s where the fun happens :)

The AA Power Board is not just a gimmick, BTW: an AA battery will actually provide more power @ 3.3V than a 9V “block”! As someone pointed out recently, it’s also a great way to drain any half-used AA batteries you might still have lying around (who hasn’t?).

Here’s a recent example of use (which required a bit more power, so I hooked it up to a 12V supply):

Dsc 2215

It’s a little stepper motor tester (using an EasyDriver board). Nothing fancy, but it was a convenient way for me to try something like this out. That project board has now been cleared to make room for new experiments…

That’s the whole point, really – this self-contained setup is intended to provide a quick path for trying out new ideas. USB-connected or battery-powered, serial or wireless, local or remote, whatever.

Once it all works, you could:

take the design and redo it as a more permanently soldered circuit
design a pcb for it (which is what I did for the graphics board)
put it all into a custom enclosure and keep using the setup
stash it all away as is, for some other time
put hot glue on it? (yikes!)

I’ve added this to the shop, as 1- and as 10-pack.

Isolation

In Hardware on Nov 7, 2010 at 00:01

There’s no escape… I have to get into mains voltage stuff and try some things out. All 220 volts of ’em!

I want to experiment with power measurement, power control, dimming, an such – but, ehm… preferably in a way which will let me live to tell the story! (how’s that for dedication to this weblog, eh?)

Now the thing about electricity is that it’s not the voltage that kills you, it’s the current – after all, if this weren’t the case, all the birds on high-voltage wires would be dropping dead out of the sky…

Current means: electricity going from A to B. And the problem with us human beings is that we are conductors – which isn’t too surprising, given that we’re mostly made of water anyway (the rest is hot air, I’m told).

So the first thing to do is to isolate myself from AC mains, by not allowing a ground path to carry any current. This can be accomplished with an “isolation transformer”, i.e. a transformer from 220V to 220V which – like any normal transformer – creates a galvanic isolation barrier:

Screen Shot 2010 11 06 at 20.25.22

Trouble is, these transformers are relatively expensive. One reason for this could be that you want to get a fair amount of power across, so these are hefty units with a lot of copper, iron, etc. in them!

Fortunately, there’s a simpler way to accomplish exactly the same using two back-to-back normal transformers:

Screen Shot 2010 11 06 at 20.26.38

The first one is a normal step-down transformer, producing 10.5V – and then we simply take a second one of the same type, and connect it the “wrong” way around.

There will be losses, so the output voltage won’t be exactly 220V, but I’m fine with that. In fact, it’s a nice test to see what a mains circuit will do with a somewhat lower voltage.

I’m going to use a pair of beefy 300W transformers I have lying around here, which will let me test some control and measurement options up to at least 250 Watts or so. Here are the main ingredients, which I’ll put in a wooden box with slots for natural convection. This dual wine bottle unit looks like a good fit:

Dsc 2212

(I told you they were hefty tranformers – each of them weighs several kilo’s!)

What this gives me, is an isolated source of mains-like AC voltage. It is still just as lethal when touching both power lines. The only safety this adds, is that touching a single high-voltage output wire is now harmless.

The other benefit is that an accidental short will limit the amount of current that can flow through this setup, thus also limiting heat and damage somewhat. But 300W of power is still a huge amount, so I have no illusions that things won’t break. It’s mostly to prevent fires and burnt-out cabling.

Evidently, this thing needs a switch with indicator light, and fuses: a 5 Amp fuse on the input, and a 4 Amp resettable fuse on the output (lowest I could find):

Dsc 2213

Scary stuff. I could set up a pair of much lower-amperage transformers for loads up to 25 Watt or so, but it’d still be potentially lethal, so that would only lead to a false sense of security.

The low-voltage / high-amp intermediate circuit does provide an option to insert a fast-acting fuse. A 100 mA fuse @ 10.5 VAC would translate to 5 mA @ 220 VAC, which is no longer lethal, but I’m not willing to “prove” that! Trouble is that such a setup would blow its fuse with anything over 1 Watt of power, even if only a power-up spike.

Here’s the whole contraption (not wired up yet) – with thanks to Ikea for the “front panel”:

Dsc 2214

I’ll finish this isolation setup for some experiments, but it won’t alleviate much of my fear. Unfortunately, there’s simply no other way to get going…

JeePlug, Reflow

Better panels

In Hardware on Nov 6, 2010 at 00:01

While we’re on the subject of PCB panels…

All new plug panels are now made with a mix of V-scoring and routed slots:

Dsc 2194

The vertical lines are “V-scores” – small sharp cuts on both sides of the boards which makes it easy to break off the board at that point. Adds a few strips of waste, but the result is much cleaner.

The reason for this is that the sides come out better (and much more accurate) when routed, but you don’t want to route all four sides, because then you have to leave little break-off tabs to hold the boards. The problem is that these tend to break off with a very rough edge, requiring extra cutting or sanding to clean up.

Progress!

Smooth sailing

In Hardware on Nov 5, 2010 at 00:01

I’ve just completed three pcb panel reflows, based on my Reflow Timer progress. Here’s a panel of Pressure Plugs:

Dsc 2210

Perfect reflow, on all three panels. There is a small problem with a cold spot in the grill, but that’s a known (and predictable) issue with a specific spot on the panel. Nothing a soldering iron touch-up can’t fix.

Oh, and isn’t blue + gold just gorgeous? – I see that it’s being picked up / imitated by others as well, such as for the “USB BUB” and the “LCD Plug” – well, sort of… ;)

Here’s one of the (unretouched) corresponding reflow graphs:

Screen Shot 2010 11 04 at 18.27.00

A perfect profile on every run, as far as I can tell!

Note that the initial overshoot in the WARMUP phase is not very important. The key is to start off somewhere between 80° and 100°, with a fairly flat curve. How that point is reached turns out to vary a lot – but from then on, all reflow graphs I’ve seen so far look more or less the same. Which is all that matters.

The only improvement remaining, is to find a way to automatically come up with decent P, I, and D factors (I’m currently using 150, 5, and 700, respectively). I’m hoping that a calibration run which applies a step change will be able to solve this. The idea is to start at some temperature (below 40°C), then turn on the heater full blast until it reaches 120°C, then measure the slope at that point as well as the maximum temperature reached after the heater has been turned off. The slope says something about the heater power, the overshoot says something about the amount of “pent-up” heat stored between heater and thermocouple, i.e. the “thermal mass” of the system.

I’m delighted with my new setup, because it no longer needs to be chaperoned – I just turn the Reflow Timer on and walk away to start populating the next board. IOW, this reflow process is now a no-brainer and a time saver!

Onwards! :)

JeeMon, POF, Reflow

Meet the Reflow Timer

In Hardware, Software on Nov 3, 2010 at 00:01

Now we’re cookin’ – here’s the complete reflow configuration I am setting up for use at Jee Labs:

Dsc 2201

Yes, it’s a Project On Foam again!

As before, I’m using a 700 Watt low-end toaster/grill. It can heat about the area of a 10×16 cm pcb and it’s really small and practical for me. I removed the teflon-coated hot plates, and placed a thin aluminum sheet in there, to respond more quickly to heat changes. A small oven or a skillet could probably also be used.

The power is controlled by an FS20 remote switch (available from Conrad or ELV, both in Europe). This is very convenient, since JeeNodes can control this thing through the RFM12B without any further hardware. The big advantage: no need to mess around with 220V AC mains – it’s RF-isolated!

The LCD display makes this thing independent of a PC/Mac. And the battery pack makes it a fully stand-alone solution. The JeeNode (and LCD / radio) will shut off once the temperature drops below 50 °C. This whole setup draws about 30 mA, so with a run time of 10-minutes, four AA batteries will last hundreds of runs, i.e. plenty!

The Thermo Plug and Blink Plug have both been extended in the shop as pre-assembled unit and kit, respectively, including a thermouple which can be used up to 350 °C. I’ve also added a 4-cell battery holder.

Here’s how to operate this thing:

set up everything, place the board inside the grill, and close the lid
press the GREEN button, the green LED goes on
wait for the BEEP, then carefully open the lid
wait until the green LED turns off, i.e. the temperature drops under 150 °C
done!

This is an example of what happens during a run:

Screen Shot 2010 11 02 at 13.10.19

Tomorrow, I’ll comment on this graph and the JeeMon app that produced it.

JeePlug, Techniques, Reflow

Conquering the thermocouple

In Hardware, Software on Nov 1, 2010 at 00:01

(No Halloween stuff on this side of the pond – I’ll defer to Seth Godin for some comments on that…)

A while back, I had to shelve my experiments with the reflow controller, because I couldn’t get a reliable temperature reading from the Thermo Plug when using a thermcouple.

Or rather, sometimes it worked, sometimes it didn’t: the physical computerer’s equivalent of a nightmare!

The thermocouple circuit is very sensitive to ground currents, apparently. The effect was that my setup would work fine on batteries, but jump all over the place when attached to the USB port. Not very convenient for development, obviously.

It still has some unexplained behavior, but I’ve been able to narrow it down, so there are two new pieces of good news: 1) it only works badly while data is being transferred over the USB port, and 2) with some averaging, the readout is actually rock solid, both on batteries and on USB. I still see a difference in readout when data is transferred over USB, but since this is a JeeNode, I can work around that in the final version: go wireless!.

Here’s the readout code which produces good readings – all remaining jitter is now in 1/10’s of degrees Celsius:

Screen Shot 2010 10 31 at 18.48.10

The output is in 1/100’s of °C, because I’m trying to avoid floating point math in this sketch.

And here is the measuring side of my new reflow setup:

Dsc 2200

The thermocouple is taped to the thin aluminium insert in the grill using heat-resistant Kapton tape. When I turn on the heater, I now see a clear rise in temperature within seconds – perfect!

Note that I’m using a 4x AA pack i.s.o. 3x AA, because the AD597 needs at least 2V more on its supply line than the highest output voltage it is going to report. With 4x 1.2V (worst case, i.e. near-empty eneloops), the range will be at least 4.8 – 2 / 0.010 = 280°C, i.e. plenty!

And indeed, I’ve verified that at 250°, it reports valid temperatures on the attached LCD Plug w/ display.

The other plug you see in the lower left is a Blink Plug, with two pushbuttons and two LEDs.

Let’s see if this time around we can get the whole thing going properly!

Meet the new Opto-coupler Plug

In Hardware on Oct 29, 2010 at 00:01

The plug barrage continues…

This time it’s an update of the flawed Opto-coupler Plug, which only worked properly on one channel (unless you patched it up). So here’s the new Opto-coupler Plug v2:

Dsc 2185

Wait! There’s more! It’s actually two plugs in one now:

Dsc 2186

(note: the solder jumpers need to be shorted out to use this as an output board)

Since there was enough room on this board, I decided to make it more versatile: it can now be used as dual Opto-coupled input (as before) or as dual Opto-coupled output plug. In the latter case, the JeeNode drives the IR LEDs and the output is a phototransistor which can be used as low-power (polarized) switch for some external device. The choice is determined by how the IC socket and Opto-coupler are hooked up.

The connectors are the same as before: detachable screw terminals, these are very convenient because you can prepare the wiring elsewhere and then plug / unplug / swap channels as needed.

I have no immediate use for these plugs right now, but of course I had to make sure that everything is working properly, so I hooked both of them up:

Dsc 2190

On the back you can see how things were connected together:

Dsc 2191

Here’s the updated opto_demo.pde test sketch for that – I decided to send the results by wireless for a change:

Screen Shot 2010 10 28 at 18.11.23

Sample output on my central JeeLink:

Opto Output

Yippie – looks like it’s working exactly as intended! Note the inverted signals, BTW.

Docs and shop have been updated for this new plug version. If you have version 1, please let me know and I’ll send out an updated board to you.

Meet the Current Source Plug

In Hardware on Oct 28, 2010 at 00:01

Here’s another new plug, firmly in the realm of home automation: the Current Source Plug drives two independent channels of Power LEDs with either 350 mA or 700 mA current:

Dsc 2183

As you can see, this plug was a very tight fit. These are based on high-efficiency AP8803 switching power supply chips, which also explains the two hefty inductors on the board. The 2 I/O pins are used to control both channels, and can use PWM to dim the LEDs.

The connector on the bottom is for the LED power supply (sorry for the tight fit!), and can be 8..30V. According to the specs, you can have up to 5 power LEDs in series at 30V, so the highest power this plug can theoretically switch is 5x 3W-LEDs @ 700 mA per channel!

There are some thermal limits though, due to the high amount of power involved in this small board. It is best to keep the voltage differential between what the LED needs and the input voltage fairly low. The two 3.7V LEDs I tried worked fine at 6..12V, but the board started heating up quickly with more than 12V (at full power).

Here’s the test setup I used:

Dsc 2182

The big LED is set to 700 mA, the small one to 350 mA – for a total of 1050 mA output. The nice part is the efficiency of this thing: the board draws less than 1050 mA due to the “buck” switching design. I measured roughly 960 mA @ 6V and 490 mA at 12V. At 18V it heated up a lot, I did not dare take it any higher. The main use I see for this board is two channels, each with 1 or 2 power LEDs in series, driven from a 12V supply.

At full power, the board temperature rose about 40°C above ambient after an hour, i.e. roughly 60..70°C. Hot to the touch, but not scorching hot. When dimmed, temperatures immediately went down. Note that the LED lights themselves were hotter than the board. Power LEDs need cooling!

For PWM dimming up to 500 Hz, just use the I/O pins. I haven’t tried it yet, but this could be done with the same rgbRemote.pde sketch as used for the MOSFET plugs.

The documentation and shop have been updated with this new plug.

More goodies coming, stay tuned…

Meet the Bridge Board

In AVR, Hardware on Oct 27, 2010 at 00:01

As mentioned not so long ago on this weblog, I’ve been doodling with some ideas to simplify using a JeeNode alongside a solderless breadboard. So – tada! – here’s the new Bridge Board:

Dsc 2167

As the name says, it acts as a bridge between a JeeNode (also USB or SMD variants) and a breadboard. All the I/O and power pins in one row, labeled for easy reference (including Arduino pin numbers), with two pins sticking into the power rail for ground and +3.3V. The JeeNode goes underneath, component-side up, with the radio on the right-hand side.

Two LEDs and a push button are also brought out, available for general-purpose use.

In the most basic form, the Bridge Board has just 4 6-pin male haders to push into the JeeNode ports, and 29 (+ 2 power-rail) pins to push into a medium or large size breadboard.

The generality of this setup increases if you hook up more headers between the JeeNode and the Bridge Board. With the SPI/ISP connector included, you get the ability to hook it up to an Ether Card, for example:

Dsc 2165

The reason this works, is that the 20 pins on the right are compatible with a Carrier Board – with the “BTN” and “LED2” pins extra. Note that with an Ether Card hooked up, all four ports (i.e. 8 DIO/AIO pins) are still fully available for your own use.

If you connect the 8-pin PSIX header on a JeeNode v5 (or both PSI and SPI/ISP on the other variants), plus a 0.1 µF capacitor, then the FTDI header on the left side can be used. This is paricularly useful for the JeeSMD, which doesn’t have an FTDI connector of its own.

Some I/O signals are brought out on more than 1 pin on the breadboard: DIO2/AIO2 and DIO3/AIO3. This maintains compatibility with the Carrier Board and also means that Port 2 is available on the breadboard in the standard port header layout: PWR, DIO, GND, +3V, AIO, IRQ if you want to insert any of the Jee Plugs.

Another way to combine plugs with the breadboard is to use stacking headers, so that the 4 ports can be re-used on the top of the Bridge Board. See the setup I plugged into the lower left:

Dsc 2166

Evidently, I had to make sure that all the I/O pins work properly, so I pre-loaded the SMDdemo.pde sketch onto a JeeNode and hooked up lots of LEDs:

Dsc 2161

Yeay – it works!

(note how the push-button has been turned into a reset button – this requires either the SPI/ISP or the PSIX headers to be hooked up)

I expect this new setup to be very convenient for all the endless experimentation going on here at Jee Labs. I’ll be updating the documentation site and shop shortly to reflect this addition to the Jee product line-up. I’ll also be adding 6- and 8-pin stacking header 10-packs.

Long live the breadboard!

Meet the Heading Board

In Hardware, Software on Oct 26, 2010 at 00:01

Here’s another plug which didn’t work initially, but as always it was a simple mistake in the software (and a not-so-clear datasheet) which prevented me from using this thing:

Dsc 2157

The Heading Board is based on a somewhat unusual HDPM01 combination sensor by HopeRF, containing a 2-axis compass / magnetometer and a … temperature + pressure sensor. My interest in this thing was the compass, which is relatively low-cost compared to most other options out there.

There’s now a HeadingBoard class in the Ports library to make this thing sing. Note that it’s called a “board” and not a “plug” because it requires two ports and sits as a mini-board on top of a JeeNode (same as the Room Board):

Screen Shot 2010 10 24 at 17.39.20

This board is a somewhat awkward match for the ports concept, because it needs a 32 KHz clock to function. I’ve hooked that up to the IRQ pin, which is reprogrammed by HeadingBoard::begin() to generate that clock using Timer 2, so you may have to jump through some hoops to use this if other ports use the IRQ pin for a different purpose. A more general approach would be to generate the required 32 KHz on-board with an NE555, as is done in an upcoming Infrared Plug – but that requires extra board space (or components on both sides of the pcb).

Here is the “heading_demo.pde” sketch, now added to the Ports library as example:

Screen Shot 2010 10 24 at 17.40.20

Sample output:

Screen Shot 2010 10 24 at 17.17.02

I haven’t figured out the conversion from X-/Y-axis values to compass heading yet. There is some sensitivity to how the board is positioned horizontally – this could be compensated by detecting the angular position using a Gravity Plug. But as you can see, there is a clear variation in readings as I turned the JeeNode + Heading Board around the Z axis.

So if you’re into robots: a Heading Board plus a Gravity Plug is all you need to determine your absolute orientation in all the 3 axes in space, i.e. X, Y, and Z.

Onwards!

PS. Here’s a crazy idea: we could use the Heading Board to create a door-open sensor. Simply attach this thing to a door, and track the Z-axis orientation!

Meet the Proximity Plug

In Hardware, Software on Oct 25, 2010 at 00:01

The Proximity Plug was created a while back, but at the time I couldn’t get the chip to respond properly. Turns out that this was just some silly mistake in the code, so now all is well and ready for use:

This plug uses an MPR084 to support up to 8 capacitive touch sensors. These can be created in any shape you like, using some conductive board, film, or tape. There’s a solder jumper to set one of two I2C addresses, so up to 16 sensors can be hooked up to a single port.

Here’s a little test setup:

Dsc 2154

Capacitive sensing can be fairly tricky to get right – the sensors may respond slightly differently, cross-talk between each sensor, electromagnetic noise pick-up, etc. But this chip does a lot of the work for us.

There are many configurations settings, and I’ve only started to scratch the surface so far. The current setup is configured to only report a single touch at a time, and does auto-calibration on startup. I’m still seeing some cases where things lock up and may have to be reset (in software), so the interface class for this thing is very basic for now – simply giving acces to the individual registers from I2C.

Screen Shot 2010 10 24 at 13.01.33

I’ve added a “proximity_demo.pde” sketch to the Ports library to demonstrate the use of this plug:

Screen Shot 2010 10 24 at 13.10.36

It will print a message whenever a “key-press” is detected. The commented-out code prints out the following ID string extracted from the chip:

    #reescale,PN:MPR084,QUAL:EXTERNAL,VER:1_0_0

Note that the MPR084 chip wants a 100 KHz I2C bus.

One thing I’d like to try with this thing, is to create some input buttons with it using the Carrier Board box. It would be nice if the sensors can be made sensitive enough to reliably work with a bit of copper on the inside of the box, then you wouldn’t even have to drill holes or make any cutouts to be able to control what’s inside. Otherwise, perhaps a slit for adhesive / conductive copper tape, covered up with plastic foil?

More detective work needed…

3D printing again

In Hardware on Oct 23, 2010 at 00:01

Finally found some time to fix the clogged extruder Mk4 I had on the CupCake. A new heater + extrusion head did the trick. Well, almost… watch the leaked blob of ABS on top of the extruder heat barrier:

Dsc 2138

As a result, the first part I printed did not contain enough material, and ended up too fragile for actual use. That’s part of a micro-lathe I’m printing for someone else, btw.

So I disassembled the extruder again, and replaced the PTFE rod with a new black one:

Dsc 2141

Yippie, now it’s working again. I’ve also upgraded to a heated build platform, which works great – no warping and the parts come off real easy, with raft and all:

Dsc 2148

Here’s a component from the Wade extruder which I’ll need for the Mendel:

Dsc 2151

Alas, not all is well yet. This was supposed to be the other half of that gearwheel pair:

Dsc 2150

Hmm, looks more like a cupcake to me…

The other nasty problem is that the main body of the Wade extruder I’m trying to build is too large for the CupCake. I can’t print it! Now I’ll either have to buy a complete extruder for the Mendel or find some other extruder which works with it. So as far as the next-generation “Mendel” is concerned, I still need to assemble the electronics and find some good extruder for it. Drat, it’s always those last 20% that bite…

Wireless mousetrap

In Hardware on Oct 22, 2010 at 00:01

Mathias Johansson recently sent me a description of his project which is just too neat to pass up. So here goes – photos by him and most of the text is also adapted from what he told me in a few emails.

I’ll let Mathias introduce his project:

It is late autumn here in Sweden and the mice starts to search for a winter home. They do normally stay outside modern constructions but I have a croft that is over 100 years old and they tend to like my attic. Mice are pretty cute, and I wish them no harm, but they damage my ceilings! Therefore I have to catch them in traps and transport them deep into the forest and release them near the brink of a stream.

Some properties of each of the three traps built so far:

Does not harm the mouse
Immediately reports which trap is closed on a webpage
Disables itself if the alarm system is turned on for longer periods of absence

Here’s the mousetrap, ready to go:

Mouse Trap

With a guest…

Mouse in Trap

And here the status page indicating which traps have been sprung:

Homepage

The schematic was implemented on what looks like a mini breadboard, here’s the Fritzing version of it:

Musetrap v0 1 bb

The infrared receiver was salvaged from a BoeBot and is used to detect the presence of a guest to spring the trap. Note that by the time it detects something, the tail of the mouse will be mostly inside the trap, so this is a gentle as it gets – well, if you’re a mouse…

Mathias concludes with:

Feel free to publish the pictures (and text) in your “success story” forum or elsewhere on your web-page if you think they are of interest to others or inspire new uses for the JeeNode.

Thanks, Mathias, for sharing your ideas and your delightful rodent-friendly project!

Home automation, Techniques

IR decoding with pin-change interrupts

In AVR, Hardware, Software on Oct 14, 2010 at 00:01

Yesterday’s post described a new “InfraredPlug” class which handles the main task of decoding IR pulse timings. The “irq_recv.pde” example sketch presented there depended on constant polling to keep the process going, i.e. there has to be a line like this in loop():

    ir.poll();

Worse, the accuracy of the whole process depends on calling this really often, i.e. at least every 100 µs or so. This is necessary to be able to time the pulse widths sufficiently accurately.

Can’t we do better?

Sure we can. The trick is to use interrupts instead of polling. Since I was anticipating support for pin-change interrupts, I already designed the class API for it. And because of that, the changes needed to switch to an interrupt-driven sketch are surprisingly small.

I’ve added a new irq_send_irq.pde sketch to the Ports library, which illustrates this.

The differences between using polling mode and pin-change interrupts in the code are as follows. First of all, we need to add an interrupt handler:

Screen Shot 2010 10 13 at 00.26.10

Second, we need to enable those interrupts on AIO2, i.e. analog pin 1:

Screen Shot 2010 10 13 at 00.26.44

And lastly, we can now get rid of that nasty poll() call in the loop:

Screen Shot 2010 10 13 at 00.27.51

That’s all there is to it. Does it still work? Of course:

Screen Shot 2010 10 13 at 00.29.16

Note: I made some small changes in the InfraredPlug implementation to tolerate interrupts and avoid race conditions.

This all seems like an insignificant change, but keep in mind that this completely changes the real-time requirements: instead of having to poll several thousands of times per second to avoid missing pulses or measuring them incorrectly, we can now check for results whenever we feel like it. Waiting too long would still miss data packets of course, but this means our code can now continue to do other lengthy things (or go into a low-power mode). Checking for incoming packets a few times a second is sufficient (IR remotes send out a packet every 100 ms or so while a button is pressed).

So the IR decoder now has the same background behavior as the RF12 driver: you don’t need to poll it in real-time, you just need to check once in a while to see whether a new packet has been received. Best of all, perhaps, is that you can continue to use calls to delay() even though they make the main loop less responsive.

There is another side effect of this change: if your code includes a call to “ir.send()”, then the receiver will see your own transmission, and report it as an incoming packet as well. Which shows that it’s running in the background. This could even be used for collision detection if you want to build a fancy IR wireless network on top of all this.

So there you go: an improved version of the InfraredPlug class, which lets you use either explicit polling or pin-change interrupts. The choice is yours…

JeeNode, Sensors, Home automation

Decoding IR pulses

In Hardware, Software on Oct 13, 2010 at 00:01

After the last few posts, it must come as no surprise that I’ve been working on a new Infrared Plug – so now it’s time to start exploring the software side of things. Note that IR reception doesn’t really need a plug at all, I simply inserted a TSOP32238 IR decoder chip into port 2 while debugging the code:

Dsc 2129

Note: I’ll be using the TSOP34838 for the planned Infrared Plug. It only differs in pinout (!) – and both can be used at 3.3V, which is essential.

In preparation of that new plug (atoms need time!), I’ve added a new “InfraredPlug” class to the Ports library, with the following interface:

Screen Shot 2010 10 12 at 17.30.37

This allows receiving IR codes on the AIO pin of any port, as well as sending out IR bit patterns on the DIO pin.

There’s a new ir_recv.pde sketch to demonstrate reception of arbitrary IR signals:

Screen Shot 2010 10 12 at 17.33.59

Here is some sample output, using two different Apple remotes which send using the NEC protocol, as described on this excellent site by San Bergmans:

Screen Shot 2010 10 12 at 16.49.22

You’re looking at a decoded bit stream – some minor processing will be needed to extract the actual data bits from each packet. This was done to make the decoder as flexible as possible – allowing it to handle all sorts of remotes.

The basic idea is that you set up the InfraredPlug instance with “slot” and “gap” parameters. The slot value (1..255) specifies the granularity of the time slots used by the decoder (in units of 4 µs). The default slot value is 140, this corresponds to time slots which are 560 µs wide. De gap value tells the driver when to consider a data packet as being complete (in units of 256 µs). The default gap value is 80, i.e. treat a series of pulses as one packet once 20 ms have elapsed after the last pulse.

The values can be changed with the “configure()” method. In fact, ir_demo will change the slot value when it receives an integer followed by lowercase “s” on the serial port (not echoed). The default setting on startup is “140s”. For RC5 codes, use “222s”, for RC6 “111s”, and for Nokia remotes “125s”, to name a few.

Each time a packet has been received, ir_demo will send the decoded data to the serial port. The data consists of a series of hex digits, each representing one 4-bit nibble of data, as returned by the InfraredPlug class:

0..9 = 1..10 slots
A = 10 = 11 or 12 slots
B = 11 = 13 or 14 slots
C = 12 = 15 or 16 slots
D = 13 = 17 or 18 slots
E = 14 = 19 or 20 slots
F = 15 = 21 or more slots

The nibbles at even positions correspond to pulse ON widths, the nibbles at odd positions are pulse OFF widths – both as a multiple of the configured slot time, with the above adjustment of longer pulses applied.

The “send()” method uses a different format. You give it a bit pattern and the number of bits to send. Each bit represents an ON or OFF signal value. The duration of each bit is the same slot value as used in the receiver.

That’s it. A simple design which should be able to support lots of different appliances and remotes.

JeeMon, Home automation

IR pulse pickup

In Hardware, Software on Oct 11, 2010 at 00:01

With the sending of IR pulses out of the way, the next step is picking them up. That’s a lot simpler since there are various sensors which do this.

But unfortunately I only have a QSC113 IR photo transistor at hand right now. It doesn’t have any sort of 38 kHz filtering, it just senses IR light. Then again, it still seems to work – I don’t understand why, to be honest:

Dsc 2123

Anyway, this seemed like a good test case to throw at the OOK Scope. The name is a bit confusing actually – it was used to analyze OOK-encoded radio signals a couple of months ago, but it’s really more general than that. What the OOK Scope does, is create a histogram of incoming pulse widths (20 .. 4604 µs with the current code).

As a refresher, here’s some OOK Scope output with a 433 MHz radio attached, after pressing buttons on my KAKU remote control:

Screen Shot 2010 10 10 at 22.06.54

The histogram runs sideways: at the top are the short pulses, at the bottom the long pulses. The longer the bar, the more pulses of that length have been picked up.

Now the fun part is that this same setup can also be used for IR pulses:

Dsc 2122

I simply replaced the OOK radio in port 2 by my IR photo transistor, with the short lead to GND and the long lead to AIO2. Here’s what comes out when using the Apple remote:

Screen Shot 2010 10 10 at 22.47.36

The pulses are a lot sharper, which is not surprising since it’s picking up direct light pulses now, not radiomagnetic waves of a much lower frequency and intensity that has to be detected and converted into an electrical signal by the radio.

Reading these values is a bit more work, because the ookScope.pde does some trickery to increase the range of pulse widths it can report in a single byte:

if (width >= 128) {
    width = (width >> 1) + 64;
    if (width >= 192) {
        width = (width >> 1) + 96;
        if (width >= 224) {
            width = (width >> 1) + 112;
            if (width >= 240) {
                width = (width >> 1) + 120;
                if (width >= 248) {
                    width = (width >> 1) + 124;
                    if (width >= 252) {
                        width = (width >> 1) + 126;
                        if (width > 255)
                            width = 255;
                    }
                }
            }
        }
    }
}

See the OOK Scope post for details on how this works.

Back to the readings. The values reported are two strong bands centered around ≈ 105 and 158, respectively, with another set of pulses at 224. The pulse widths corresponding to these are ≈ 420 µs, 652 µs, and 1536 µs if I got my calculations right. That last one might be the time between retransmissions.

I’ll have to revisit this with a real 38 kHz filtering IR sensor when I get them in – but that sort of looks right to me. Another remote sending out RC5 codes ended up with very similar pulse widths, but with more variation.

Tomorrow, I’ll describe the OOK Scope setup in more detail, since it doesn’t seem to be working for everyone…

Update – I just figured out the pinout of a 5V sensor with IR filtering (TSOP1138) – here’s what comes out:

Screen Shot 2010 10 10 at 23.32.07

Hm, more variation now. Then again, also a lot more sensitive, it seems. And it looks like it should still be possible to discriminate between the two pulse widths at position 135, i.e. around 568 µs.

The pulse trains are now more consistent on the scope:

Dsc 2124

Note that I’m driving the JeeNode I/O pin to nearly 5V, which isn’t really such a good idea…

PS. That’ a DSO Nano scope, in case you’re wondering…

Generating IR pulses

In Hardware on Oct 10, 2010 at 00:01

There are lots of projects and schematics floating around the web for encoding and decoding IR remote-control pulses. Many MPU-based ones use one of the built-in hardware timers for this, which is understandable since you can’t easily bit-bang your way out of a 13.158 µs time between switching flanks.

But I don’t want to be constrained to a specific pin, nor dedicate a hardware timer to this task.

Instead, I’ve been experimenting with the venerable NE555. Its normal operating voltage is 4.5 .. 16V, but there’s a CMOS version which will easily go down to 3.3V, as preferred by JeeNodes.

So here’s the circuit (from the ICM7555 docs by NXP):

Screen Shot 2010 10 09 at 14.06.34

The RESET pin can turn this thing on and off. It’ll also need an extra transistor to drive a bright IR LED.

Had to try it out, of course (the chip I used wants at least 4.5V, hence the USB power):

Dsc 2118

Great. It works, but at 35.1 kHz the frequency is a bit off.

Here’s a Logic Analyzer screen shot (warning: MDI toolbar madness, flash from the past!):

Screen Shot 2010 10 09 at 23.11.14

(FWIW: my USB Scope and Logic Analyzer now both work properly on Mac OS X under Parallels 6 emulation – I no longer need a dedicated Windows setup.)

Let’s do the math for the components used in the above test setup, with RA = 1.2 kΩ, RB = 18 kΩ, C = 1 nF:

Screen Shot 2010 10 09 at 14.05.11

f = 37.09 kHz  
∂ = 51.6 %

Let’s use the 1 nF capacitor, smaller would make the circuit more sensitive to stray capacitance. Then I get:

RA + 2 RB = 36.315 kΩ

I don’t want to raise RA much, because that would change the duty cycle in the wrong direction: more LED-on time (i.e. higher current draw). I also don’t want to lower it much further, because that would draw more current in the discharge phase (pin 7 pulled low).

Using 1% resistors, RA = 1.5 kΩ and RB = 17.4 kΩ will do:

f = 38.02 kHz  
∂ = 52.1 %

The 1 nF capacitor will have to be 1% too, of course.

I think I’ll try this. What remains – as always! – is the software, to send out the proper IR bit patterns and to decode the ones coming in. It’d be nice if that could be done fully interrupt-driven like the RF12 driver, because then the whole real-time aspect of IR communication would be taken out of the loop(), so to speak.

Bridge Board it is

In Hardware on Oct 9, 2010 at 00:01

Yesterday’s post triggered some great comments and email exchanges. I came up with this 29-pin design:

Jlpcb 116

There’s a lot more to say about the board and the choices that ended up being made for this particular setup, but I’ll refrain from doing so until the pcb is ready and comes back for testing.

Let me just point out the two uncommitted LEDs with current-limiting resistors, as well as the sideways push-button at the top – again uncommitted, but it can easily be tied to the RESET pin.

Note again that this board is for male pins pointing down, so this effectively holds a JeeNode, JeeNode USB, or JeeSMD together with a half- or full-sized breadboard.

Attentive readers will have noticed the list of Arduino pin numbers along almost the entire length of the board. No more guessing or doc searching if you live in the Arduino ecosystem most of the time – Uno, Due, whatever. A few signals come out on more than one pin, but there’s a reason for that…

Onwards!

Experimenter’s setup

In Hardware on Oct 8, 2010 at 00:01

I keep looking for ways to make it easier to try out stuff – since that’s what I tend to do a lot, here at Jee Labs.

Here’s a trial with a graphics LCD I was mucking about with recently:

Dsc 2111

I don’t like it. Even if the JeeNode’s pins were facing down into the solderless breadboard, it eats up a lot of real-estate, while only a few pins are actually used. Part of the reason is that the ports have a lot of duplicated power pins (that’s the whole point when you use them independently).

I’d much rather use the JeeNode as follows:

Dsc 2109

Then you develop, upload, and test things while tethered. And when it’s ready to use elsewhere, just replace the BUB with an AA Power Board:

Dsc 2110

Now I’m wondering if it wouldn’t be useful to create a little “breadboard interface panel”, like this:

Screen Shot 2010 10 07 at 14.43.48

It’s a bit like the Breadboard Connector that is included with each Expander Plug, as described in this post.

The panel would re-route all pins to the pins along the top row of the breadboard, as well as hook up to the two power rails along the top.

The top of the panel could have extensive labeling for reference. Even some port headers to hook up plugs, if I can figure out which orientation might work best. No components, it’d just be a little back, eh, I mean, front-plane.

Musings

Over-packaging

In Hardware on Oct 7, 2010 at 00:01

I know I’ve sometimes “under-packaged” things…

But this is sort of the other extreme. A package with 80+ PCB relays from Conrad came in the following box:

Dsc 2009

That’s a 50 x 40 x 30 cm box, i.e. 60 liters of (mostly air).

The payload was this, which is admittedly a bit awkward in size:

Dsc 2010

And this is how I’m storing it at Jee Labs, until the plug PCB’s come in:

Dsc 2011

That’s a 11 x 7 x 5 cm box (they barely fit), or 0.385 liter.

A 155-fold reduction in size. Pfff…

JeeNode, Home automation, LowPower

Room Node battery life

In AVR, Hardware on Oct 6, 2010 at 00:01

The current Room Node sketch only gets 1..2 months of life out of a 3x alkaline AA battery pack. Not enough – by far – for practical use around the house.

The good news is that it’s almost entirely a software issue. There have been JeeNodes running for many months now, some up to 10 months, so there is no hardware limitation to achieve such lifetimes.

In fact, I’d like to push it a bit further and see how long one could run a Room Node off a single rechargable AA battery using the AA Power board. If it’s not that long, I could still opt for the 3x AA pack.

Let’s estimate the idle current draw of a JeeNode first.

The big consumer is the PIR sensor. I recently switched to a new one, because it only needs 3.3V and because of its low current draw. Note that the PIR motion sensor is the only component in the Room Node which should not be disabled during sleep: the whole point is to be able to detect motion at all times, after all. Also, a PIR sensor needs time to stabilize, in the order of a minute, so turning it on briefly is no option.

Here’s the good news:

Dsc 2077

That’s 41 µA idle current.

The JeeNode draws ≈ 3.3 µa, let’s round it up to 4 µA.

The SHT11 draws 2..5 µW, let’s round it up to 2 µA.

So total idle draw is 47 µA.

As it turns out, transmissions consume a neglegible amount of current – if the frequency of transmission is 5 minutes, for example (i.e. 288x per day). The motion detection is different, this needs to go out as soon as there is motion, but this probably won’t happen more than a dozen times a day, on average).

For a transmission, the RFM12B needs to be on for about 2 ms, at which point it draws around 25 mA. With 2 ms once every 300 seconds, that’s a duty cycle of 1:150000, i.e. under 2 µA when averaged out.

So let’s round up and assume that the average current draw of a Room Node is 50 µA @ 3.3V.

A 3x AA battery pack of 2500 mAh would last 50,000 hours, i.e. over 5 years if we ignore the self-discharge rate … assuming that the low-power code is perfect, that is!

Now for the AA Power Board lifetime estimate. At very low current levels, the efficiency of the LTC3525 regulator is 75..80%, according to the datasheet. But first, we need to estimate the current draw. Keep in mind that the power source will be 1.2 .. 1.3V, so we basically need a 3-fold step up. Let’s calculate the input current draw, assuming 1.2V in, 3.3 V out @ 50 µA, and 75% efficiency:

input current = 50 x 3.3 / 1.2 / 0.75 = 183 µA

With an Eneloop battery, I’ll assume it has 1900 mAh capacity, and loses 15% of its charge in two years. Let’s assume that it’ll be used no more than 2 years, and that it lost that 15% charge right at the beginning. Then this is effectively nothing more than a 1600 mAh battery.

Ok, how long can it power a JeeNode plus Room Board?

lifetime = 1600 / 0.183 = 8743 hours = 364 days

So all in all this setup should be able to run just about one year off a single rechargable AA battery. Note that there was some rounding in several places in these calculations, so these estimates are probably a bit conservative.

One year battery life… that’s in fact exactly what I was hoping for!

Now the “only” remaining challenge is to optimize the “rooms.pde” sketch enough to make this happen.

Low-end light box

In Hardware on Oct 5, 2010 at 00:01

Yesterday’s post was about trying to make better pictures for this weblog. The jury is still out on whether the results are dramatically better, but here’s the setup I used – first an add-on for the Nikon D40 built-in flash:

What it does is place a small piece of mirror (extracted from a flatbed scanner) in front of the pop-up flash to reflect all the light up. It’s made of a few little scrap pieces of foam board, glued together to keep the light from directly reaching the object, reflecting the light upwards instead. It’s held in place by friction:

Screen Shot 2010 10 03 at 21.10.03

That solves one half of the problem. The other issue is to get light all around the object to avoid excessively sharp shadows. I made a little “light box” for that, from a little wooden storage box with the interior covered entirely in white foam board:

I can now place the object on the bottom in the back, and sort of peek inside with the camera. The trick is to make sure that the flash sends its light inside the box, bouncing up against the top foam board.

That’s basically it!

The reason I chose this setup, is that I need the height to get the flash inside, and I wanted something that could be easily dismounted and stored away. Like this:

All the foam pieces were cut from five A4-sized panels, because I’ve got lots of ’em lying around. Everything is held together purely by friction, so it’s trivial to assemble and disassemble, but also very easy to replace one of the form boards if it ever got dirty or damaged.

I can also rearrange things, and put the wooden box flat on the table, with the camera looking down into it for shots straight from above.

One detail I’d still like to improve is the amount of diffuse light striking the object at the front. There is currently still a bit of a shadow. One idea is to cover the top with aluminum foil, and perhaps also a surface inside which is slanted forward. Here is a cross section:

Screen Shot 2010 10 03 at 16.27.41

Here is the current setup (no foil yet), with the slanted top panel showing on the left:

Note that foam board is very easy to use for “broken” panels – simply don’t cut them all the way through:

Simple. Now I just need to understand all the adjustments and photo stuff a bit more…

Update – here’s the last trial – different angle, slightly more interesting surfaces, but the FTDI pins are too washed out:

Better pictures?

In Hardware on Oct 4, 2010 at 00:01

Almost all the pictures on this daily weblog are taken with a Nikon D40 + 18..55 mm “kit” lens. I bumped into a fantastic deal two years ago for that setup and have never looked back since then.

Pictures matter on this weblog. In fact I try to get a picture, drawing, or code snapshot image into every single post. It’s simply more fun – to make, to read, and to look back to later.

And until now, almost all pictures were taken in plain daylight (indoor, on a table next to one of the windows). This has been a mixed blessing really – gorgeous light at times, but a widely varying white balance due to the different times of day at which I decide to take some snapshots. And with winter nearing, good daylight conditions are going to get scarce again.

Seeing some of the pictures uploaded to the new “JeeLabs” Flickr group (check it out!), I felt that I really need to beef up the images on future weblog posts a bit. Better close-ups, and more importantly: more consistent lighting conditions and while balance. I’m hoping to do this without killing the low-key basic approach to everything done at Jee Labs.

After some lengthy conversations with Steve Evans and with many thanks for his tips, I’m going to try doing a bit more with flash. At first I wanted to try something with RGB strips, but it simply makes no sense to light up a little scene like a theater (requiring substantial amounts of light!) while the shot only takes a fraction of a second.

There are three problems with using the built-in flash, though:

it causes horrible reflections
it causes horrible shadows
it’s still fairly weak

For decades, I’ve routinely turned off flash for any picture I took. It seemed so ill-suited to capture anything meaningful in a pleasant way, especially with people.

The good news: project / product shots are different…

First of all, everything I shoot for the weblog tends to be fairly small. So a “lightbox” is definitely an option: a micro-studio set up to photograph a very small area with all the lighting in place.

Ok, time for some examples (sorry if it looks a bit like a JeeNode commercial). This is the JeeNode v3, Jul 2009:

Dsc 0424

This is the JeeNode v4, Nov 2009:

Dsc 0767

And here’s the JeeNode v5, Sep 2010:

Dsc 1968

All of them shot out of hand, in daylight, most of them tweaked a bit for exposure, white balance, and shadows, and cropped / rotated for proper framing. No big setups, no comparisons, just some tweaks until it “looks right”, each time.

Here’s a shot of the JeeNode v5, as it came out today, while spending a lot more time on lighting, setup, histograms – but still essentially just some quick ad-hoc tweaking:

Basically, I adjusted the exposure until the background is fully white, and I’ve boosted both color and the sharpness a fair bit (using Nikon’s View NX2 instead of my usual iPhoto).

That last image is definitely closer to the real thing. Much more detail in the shadows and in the highlights. I’m also pretty certain that this new setup can deliver results which are far more repeatable (and at any time of day).

But it is “better”? I’m not convinced. The crystal on the RFM12B is a good example of how you gain detail, but also lose some “vibrance”. Somehow, that JeeNode isn’t jumping off the page anymore … it just sits there.

Oh, here’s another fun shot:

Maybe I’ve simply been staring at too many JeeNodes today. Comments welcome.

Tomorrow, I’ll show the setup I made for this.

Poor Henry

In Hardware on Oct 2, 2010 at 00:01

The new AA Power Board is working very nicely, but it turns out that the ferrite-core inductor is a little fragile.

This is the 10 micro-Henry inductor core, as it should be:

Inductor

… and this is what happened to one of the shipments “all the way” to the UK:

Sje 3911

(photo courtesy Steve Evans – great close-up!)

Whoops, not good!

This happened to two of the five boards shipped as part of a “5-pack”, where I placed all the boards together in a single plastic bag, along with the metal AA clips. The fact that the inductor is placed near the outside edge also probably doesn’t help…

I’ll package the boards differently from now on. But if you got these boards, please check them and let me know if they got damaged (they may still work, depends a bit on the breakage) – I’ll send out replacements for any bad boards out there, of course.

Live and learn!

Relay Plug stocks

In Hardware on Sep 30, 2010 at 00:01

As it turns out, this slim-line relay (Conrad #504286, PCN-105D3MHZ) is not available until April 2011 (gasp!) … no matter where in the world I look:

Dsc 1813 2

Fortunately, there is an equally-slim replacement with the same footprint (thanks, Lennart!):

Dsc 2007

It’s a bit higher, and it handles a bit more current (up to 5A):

Dsc 2008

I’ve ordered a bunch of these, but I also need to get a new batch of PCB’s – didn’t want to order them without a chance of getting suitable relays (Conrad #502047). The new plugs won’t be here before mid-October. And the new relays are a bit pricier, so I’ve had to raise the price of the kit a bit.

Atoms, oh atoms … why can’t you be more like bits? As in: no stocks to worry about?

Opto-coupler doesn’t couple

In Hardware on Sep 27, 2010 at 00:01

It’s that time of year again… a mistake, courtesy Mr. Murphy: the recently-added Opto-Coupler Plug this time.

Triggered by a post on the forum, I created a little test setup. The idea is to feed some outputs in on one end of the plug, and then read them back out. First the outputs, using ports 3 and 4:

Dsc 2000

The plug itself is hooked up to port 1:

Dsc 2001

Here’s the test sketch (see opto_demo.pde):

Screen Shot 2010 09 26 at 15.55.52

What it does is toggle the ouput in all possible combinations, and then report the input signals it’s reading. Here is the correct output:

Screen Shot 2010 09 26 at 15.32.33

I had to create the EAGLE component for the MCT62, since it wasn’t available. Here’s what I made, using some existing part and modifying it:

Screen Shot 2010 09 26 at 16.29.27

Now if it were correct, then the Opto-coupler Plug would be fine. But it’s way off. Here is the datasheet pinout:

Screen Shot 2010 09 26 at 16.30.20

Silly me. The emitter is attached to “+”! – and the cap is also useless… there is no + on the chip, it doesn’t need a power supply.

I don’t know what I was thinking at the time, but it clearly doesn’t make any sense. The test setup I had on the breadboard worked fine, of course. It’s just that I went completely astray on the EAGLE design side of things. And then during the pcb test, I must have made a mistake and only tested one side.

Oh well. Fortunately there is a way to fix these plugs, but it ain’t pretty:

Dsc 2003

One copper trace from pin 8 on the bottom has to be cut, and a short wire has to be connected between pins 8 and 5 to attach the photo-transistor’s emitter to ground.

I’ll be fixing the (luckily small) batch of opto-coupler plug kits currently in stock here. And I’ll get new PCBs made ASAP – but this will take a few weeks, as usual.

Assembling the JeeNode v5

In AVR, Hardware on Sep 26, 2010 at 00:01

New JeeNode means: new build instructions.

Here goes. A long description of how to go from this:

Dsc 1973

… to this:

Dsc 1970

Make sure you’ve got a nice soldering iron (not too hot, not too large) and some solder wick to remove solder in case you need to back up a bit to fix things. The JeeNode printed circuit is very sturdy and can handle a lot of abuse, but some traces are thin, so be careful and don’t apply too much force.

Components are soldered on from lowest to highest profile, because then you can turn over the board and push on it to get each component snugly against the board as you solder it. So let’s start with the resistor:

Dsc 1974 Dsc 1975

Once you’re satisfied with the soldering, turn it over and snip off the leads:

Dsc 1976 Dsc 1977

Meet the JeeNode v5

In AVR, Hardware, News on Sep 25, 2010 at 00:01

I’m very pleased to introduce the – Fresh! – Updated! – New! – JeeNode version 5 board:

Dsc 1929

Hold on. Don’t get too excited. It’s not that big a deal. It’s basically still the same JeeNode v4, with just some incremental changes.

Allow me go through each of the differences in some detail:

on the left, there is now a diode between the FTDI power input and the rest of the PWR lines – so you can power the board from a 4.5..13V battery, etc. and it won’t fry the FTDI board or cable when plugged in
this also means that “PWR” will be about 0.7V lower on the PWR pins in several places across the board, than on the power supplied to the FTDI power pin (i.e. 4.3V when fed from a USB-BUB)
for 100% compatibility with the JeeNode v4 and older, the diode can be disabled (i.e. shorted out) with a solder jumper on the back side
two extra header pins have been added (+3V and RST), on either side of what was the “PWR/SER/I2C” header on the JeeNode v4 – it is now called the “PSIX” header (X = eXtended)
on the right, the RFM12B module was moved a bit to make room for a hole for the antenna wire
not as easy to see, but the board is also fractionally longer, so that the RFM12B no longer sticks out
slight re-arrangement of components (caps and reset pull-up)
most holes are slightly larger, making it easier to unsolder components, if you ever need to
the long sides of the board are now routed i.s.o. V-scored, i.e. much smoother and more precise:

Dsc 1966

That’s more or less it. Oh, and D O T S … four big white dots on each side of the board to be precise, next to the PWR pin of each of the Port 1 .. 4 headers. You’ll be surprised by how convenient that can be when hooking up all sorts of plugs – which have the same dots to mark the proper orientation.

All in all, no big changes. Nothing incompatible with the JeeNode v4, the JeeNode USB, or the JeeNode SMD. This isn’t about planned obsolescence, these are just some tweaks to squeeze the maximum usability out of what is essentially the flagship and workhorse of Jee Labs, if you pardon this odd mix of metaphors.

I did forget to fix two little teeny tiny label name spelling errors which were also on the JeeNode v4 (left as exercise for the diligent reader). Oh well. I hereby claim victory anyway, and now declare this v5 PCB to be TUJ!

… TUJ ?

Yes: TUJ. Shorthand for The Ultimate JeeNode of course! What else?

PS. The JeeNode v5 is shipping now. I don’t play “There’s Something New Coming Soon” games.

Update – I’ve updated the documentation:

JeeNode v5 manual (PDF)
JeeNode v5 pinout (PDF)

It’s all a bit in transition, with the Café moving to Redmine soon – which is where these docs will go, eventually.

JeeNode, JeeSMD

It’s time to Do The Right Thing

In AVR, Hardware on Sep 24, 2010 at 00:01

This is long overdue…

If you have one or more JeeSMD v1 boards, which look tike this:

Dsc 1772 2

… then you are entitled to a free upgrade to the new JeeSMD v2 board, with the fixed VR (and tented vias):

Dsc 1963

Actually, I won’t send you a replacement board for each one you have, but an entire JeeSMD kit.

Likewise, if you ordered one or more Carrier Boards with Boxes, and never got these:

Dsc 1964

… then I owe you that DC Power Jack and matching connector. Ignore the 0.1 µF ceramic capacitor if you already have one – it’s for adding the reset circuitry on the Carrier Board’s FTDI connector.

Email me (please include the order number if possible) and I’ll get it out to you. No questions asked.

Mistakes happen – and I can’t undo the past. But I won’t walk away from my responsibilities either.

AA board testing

In Hardware on Sep 23, 2010 at 00:01

The latest AA Power board is one of those ideas where I can’t help but think… why didn’t I think of it before?

There’s a definite cost trade-off (that LTC3525 is expensive, and it’s only available in SMD so it has to be assembled), but I’m definitely going to switch my room nodes over to it – once that elusive how to enclose it? question gets answered, that is…

Anyway. I’ve been assembling dozens of those boards lately. Hand-soldering them, in fact – because the paste stencils aren’t ready yet. The soldering part is easy, I’ve got that down fairly well nowadays. I like soldering.

The issue is that each board must be tested. Recalls are tedious / inconvenient / annoying for everyone, and not just embarrassing for me, but totally robbing me of my pride in what I do and what I make.

Doh. Welcome to the real world.

Time to use those Pogo test pins. The nice part is that the AA Power board is ridiculously easy to test: apply 1.5V and watch 3.3V come out. Or, more loosely: connect it to an AAA battery, and watch it drive a green LED.

Here’s the AAA battery + green LED + Pogo pins part:

Dsc 1961

Note that there is no circuit on this board – no components, just the missing pieces.

To use it, I simply push the board under test against it, and voilá …

Dsc 1962

If it lights up green (see lower right corner), it works!

Great time saver. Caught about 1 in 10 (mistakes on first test), until every one of the first 50 boards was working.

Onwards!

JeeNode, Home automation, LowPower

Room Node mount?

In Hardware on Sep 21, 2010 at 00:01

I’m still searching for ideas to mount a JeeNode with a Room Board, a.k.a. as a “Room Node”. Now that the AA Power Pack lets me get rid of two of the 3 AA’s, I’m sort of hoping to bump into some new and practical options.

How about this position, against the ceiling?

Dsc 1957

The PIR motion sensor is placed above an empty spot between the JeeNode and the AA Power board. It’ll need to be wired up in that position, of course.

The shapes are still agonizingly unsuited for placement into a corner, but then again… it’s a lot better than with the 3x AA battery pack! Here’s the whole setup again, in close-up:

Dsc 1958

The trick will be to cover it up properly, here’s a first trial using my favorite foam-board as prototyping tool:

Dsc 1960

That’s 6.5 cm wide, btw. Any less, and the battery holder will poke into it and make it wobble.

Does it look good? I don’t know. I think I could live with a slanted 6.5 x 20 cm white strip along the ceiling, with a little PIR peeking out in the middle (and a small hole for the LDR + temperature/humidity sensor).

Next challenge is to come up with a mounting bracket for this darn thing. Perhaps 3D-printed? Two triangles on the end or something? If they slant slightly inwards, they would cast a shadow and not draw much attention…

It all needs to be properly detachable, since this thing runs on battery power. I could stick two little solar panels on the surface to get a warm fuzzy environmental feeling… but I doubt they’ll capture enough energy in that position.

Anyway – I’m happy to have a fresh option to think about. We’ll see…

Lots of AA’s

In Hardware on Sep 20, 2010 at 00:01

C’mon, admit it… you’ve got a pile of discarded AA’s somewhere in your drawers as well:

Dsc 1950

With all the JeeNodes and room nodes I’ve been trying out around here – and the modest results with the rooms.pde sketch w.r.t. battery life so far, I’ve gone through all these much faster than I would have liked to:

Dsc 1949

Went through over 60 here at Jee Labs, in the past year or so. So much for the environment!

Enough is enough. I’m switching to the Apple charger with the Eneloop NiMh’s. And with the new AA Power board, it looks like a single AA cell per node might be enough.

But wait! Are all those AA cells really empty? Time to find out!

Since the AA Power board is so efficient, I though it’d be interesting to see how many of those “dead” AA cells are truly empty. Note that the AA Power board can pull juice out of a battery and generate 3.3V even when it’s supplying less than half its original voltage:

Dsc 1946

So let the battle begin: which cells really can no longer drive a JeeNode as wireless test node?

The result surprised me quite a bit. These 10 were completely dead:

Dsc 1948

But the rest – which is ALL the batteries shown in the first picture – still worked!

This doesn’t mean that any of these batteries will last very long. But still – they drive the JeeNode and its on-board RFM12B transmitter well enough to send out a fresh packet once a second. Which means that even with an output voltage less than 1.1V, they are still able to a briefly deliver a 80 mA peak current once a second (i.e. 3x the current required @ 3.3V) !

Hmm, now what … charge an Eneloop with all that residual energy, perhaps? :)

JeeNode, JeePlug, LowPower

AA power options

In Hardware on Sep 19, 2010 at 00:01

The new AA Power board is a pretty darn flexible little board, if I may say so myself. Its switch regulator draws very little current itself, 7..30 µA depending on the input voltage. The input voltage range is approx 1.0 .. 5.5V, to be able to start up, but it will drain the power source all the way down to 0.4V if it can, pulling every last bit of juice out of regular AA batteries.

But the AA Power board is also capable of providing a pretty decent amount of current when needed. This is essential for the on-board wireless radio of the JeeNode, but it even works with heavier loads than that:

Dsc 1942

That’s an Arduino-compatible JeeNode with an LCD Plug and a 2×16 character LCD with backlight – all running off a single 1.2V AA NiMH battery!

The maximum current depends on the input voltage. It is guaranteed to be at least 60 mA from a 1V supply, going up to 140 mA from a 1.8V supply. Note that the input current can be much more than that – drawing 60 mA at 3.3V means the battery may have to deliver about 200 mA at 1V to make it happen. A clever little power regulator it is – a producer of energy it is not!

There a several ways to connect the AA Power board with a JeeNode:

inline, feeding the PWR pin with 3.3V (this will be dropped some 30..50 mV by the on-board regulator of the JeeNode itself, with no ill effects)
in piggy-back mode, with an AA cell inserted in the battery clips (alkaline or NiMh)
as a shield on top of the JeeNode, again with an AA cell inserted

There’s also a fourth way to use this board: leave off the battery clips, and connect a battery between any PWR and GND pins on the JeeNode itself (or use the battery holes) – this requires a solder jumper on the AA Power board.

The flexibility of the regulator means that you can connect any power source between 1.0 and 5.5V to PWR and GND, just as you would with a stand-alone JeeNode. Whatever it is, the +3V pin will carry the essential 3.3V level.

There is one issue to beware of: when PWR is connected to BAT+ via the solder jumper, then do not hook up a second power source at the same time. The most common case is probably: when a battery is connected to PWR, do not connect an FTDI adapter such as the BUB, because it’ll put 5V on the PWR pin … and the battery (or the BUB!) probably won’t like it.

The PWR pin can in fact be used in four different modes:

normal – it’s higher than 3.3V and the on-board regulator brings it down to 3.3V for the +3V pin – this would be the case with 3 to 8 AA’s, for example (no need for an AA Power board)
boosted – it’s lower than 3.3V and it’s used to feed the AA Power board – in this case the on-board regulator does nothing (and could be omitted)
parallel – the PWR pin is connected directly to the +3V pin – this can be used with the AA Power board to make sure the PWR pin also carries power (always 3.3V), in case some plugs expect a supply voltage on the PWR pin
floating – the PWR carries no power – this is the case when the AA Power board is used without solder jumper (default case)

The important point here is that the PWR pins do not necessarily carry a higher voltage than the +3V pins. It might be more (normal), less (boosted), the same (parallel), or none (floating). Not every JeePlug can be used with each mode of operation, so be careful to check.

Tomorrow, I’m going to fool around with a bunch of batteries :)

JeeNode, JeePlug, LowPower

AA mounting options

In Hardware on Sep 18, 2010 at 00:01

As promised yesterday, here is some more info on how to use the new AA Power board.

You’ve already seen the “inline” mode, using an Alkaline cell this time:

Dsc 1932

The second main mounting option is in piggy-back mode, flipped over and mounted on the back of a JeeNode:

Dsc 1939

This can be done either with regular male header pins (1×6 and 2×4, or 3×4), or with extra long pins which will stick out the front of the JeeNode as normal header pins:

Dsc 1938

Doing so requires some care, because once these two boards are soldered back-to-back, you can’t reach everything anymore. Disassembling such a sandwich later is tricky.

Note that you can stand the whole assembly on empty AA battery clips, but once a battery is inserted, this becomes unstable because the round battery sticks out:

Dsc 1940

With AAA clips and the much thinner (and weaker) AAA battery, it turns out that the whole construction does stand upright, but the size and position of the clips gives it limited stability when adding plugs on top.

There is a third option – use the AA Power board on top of a JeeNode with stacking headers, i.e. like a “shield”:

Dsc 1953

There is not that much room, but the 4 port headers can still be used. Note that the AA Power board needs to be mounted upside down in this case, i.e. with the SMD components and the silk screen facing down towards the JeeNode. Here’s another view of this shield-style option:

Dsc 1951

Coming up… a description of the full range of power connections supported by this little magician.

JeeNode, Home automation, LowPower

Long live the AA battery!

In Hardware on Sep 17, 2010 at 00:01

The AA Power board announced yesterday just arrived:

Dsc 1931

And it looks like it does indeed perform exactly as expected. Here’s the ripple:

Screen Shot 2010 09 16 at 13.41.07

That’s with the 1.6 mA LED load, i.e. a 75 µs cycle / roughly 13 KHz – this was as predicted: at light loads, the recharge frequency can reach down into the audible range. But it’s highly unlikely to be noticable due to the tiny size of the inductor, which after all is not built to act as a loudspeaker :)

Here’s the “AAv1” fully mounted for powering a JeeNode via the FTDI connector:

Dsc 1934

(there’s no charge circuit here, I’m just using an externaly-recharged battery as power source)

And here’s the whole setup in actual use:

Dsc 1935

Works like a charm. Runs just fine with the “rooms” and “radioBlip” sketches, and wireless just works – as before.

Quiescent current draw is about 20 µA when powered this way. That goes down to 10 µA when used with two cells @ 2.4V, and down to an amazing 7 µA when powered from a 3V source (a CR2032 ought to work nicely!). Above 3.3V, the circuit becomes just a tad less efficient when it switches into step-down mode, drawing about 30 µA all the way up to 5.5V.

Great, now we’re starting to get into some serious low-power options.

Tomorrow, I’ll describe other ways to use this new AA Power board…

Meet the AA Power board

In Hardware on Sep 16, 2010 at 00:01

Remember the recent post about running a JeeNode off a single battery?

Dsc 1897

That was 9 days ago, and that LED shown above is still lit. It’s not a huge accomplishment, because the LED draws only about 1.6 mA and is very dimly lit, but still. Over two hundred hours of operation time, and the rechargeable battery I used (this one) is still going. It started off at 1.35V and is now at a decent 1.22V level.

Assuming a 70% efficiency (at such low voltages, it probably won’t be much higher than that), and an average of 1.3V getting boosted to 3.3V, the power consumption over this period is … scribble, scribble … 1.6 * 3.3 / 1.3 / 0.7 * 216 = 1253 mAh, i.e. about two thirds of the total capacity of this one-cell AA battery.

Not too shabby. Even without power-down tricks, just by entering idle mode in all the busy loops, an ATmega328P will draw less than 1.6 mA when running at 16 MHz on 3.3V (which is slightly overclocked, but it works just fine). Idle mode is very nice, because you don’t have to play any serious low-power tricks, you just have to tell the ATmega: I have nothing to do right now, take it easy until the next interrupt occurs.

In other words: using only the simplest of all the low power tricks, a JeeNode can run about two weeks off a single AA battery (less, if you have power-hungry peripheral chips connected, of course).

Try running an Arduino Duemilanove off a 9V battery, or even a 4x AA battery pack. Fine board, but it sure ain’t low power…

Anyway, I’ve decided to design an AA Power board for this little power magician:

Screen Shot 2010 09 15 at 21.20.21

It’s not specific to the JeeNode, but it was of course designed to be a particularly good match for it:

the width of the board is exactly the same as JeeNodes and all the JeePlugs
it can be attached in-line, i.e. like an FTDI board/cable
it can be used in piggy-back mode, i.e. attached to the back of a JeeNode
or use it in shield mode, i.e. on top of a JeeNode with stacking headers
it has mounting holes (since there is plenty of room on this thing)
the board can be fitted with either AA battery clips, or AAA battery clips
or attach external batteries to it: one, two, three (even four, if NiMh) … you decide!

Whatever the power source is, this board will either boost or step-down the voltage as needed. The efficiency will be up to 95%, depending on load and supply voltage. But in any case, it’ll be way more efficient than any linear voltage regulator, including the one on the JeeNode.

One AA is smaller than 3 or 4, obviously, so a JeeNode with this AA Power board will also fit into smaller places.

In case you insist on using 3x or 4x AA’s, then you’lll still benefit from a much higher conversion efficiency, and the ability to run the batteries down until they are completely empty. In other words: they will last longer!

Now it’s just a matter of waiting to find out whether I did all my homework properly, and got the connections, traces, and physical dimensions right.

JeeNode, Home automation

RGB multi-meter?

In Hardware on Sep 12, 2010 at 00:01

How’s that for a weird title, eh? ;)

Just got around to hooking up a test set of 2x 5 meter RGB LED strips to the MOSFET Plugs – using the setup created and described here a few days ago.

These are water-proof strips, with only 30 LEDs/m and a somewhat unfortunate brown strip background color:

Dsc 1925

That’s with all LEDs full on.

Now some more color and power experiments, in the evening – full on:

Dsc 1920

You can see the current reading, the JeeNode setup, and the power supply.

And with 100% / 45% / 15% settings for red, green, and blue, respectively:

Dsc 1923

The color came out much more yellow on this picture than it actually was, btw.

Some power measurements on the 12V line:

full on: 2.4 amps @ 12 V = 28.8 watt
color-adjusted: 1.9 amps @ 12V = 22.8 watt

The power supply is a beefy 12A @ 12V cage which draws 4.4 watt even without anything connected. That’s very unfortunate, because I’d like to turn the LEDs off on the 12V side and leave the power supply on at all times. Will need to find a better supply – 4A would be plenty.

These results are slightly disappointing. First of all, 60 LEDs per meter will be a minimum to provide a decent level of (indirect) house lighting at full power. But also, it’s frustrating to see how the power gets eaten up in the supply and by the resistors (especially with red LEDs dimmed less than the others).

No doubt this is way better than incandescent lighting, but still…

Another surprising outcome, is that the RGB settings for this strip are completely different from the 5050 RGB test setup I used a few days ago. It looks like I’m going to have to adjust each strip individually to get a nice consistent white balance.

And then there’s the issue of fringing. Looking directly at these LED strips clearly shows the distinct RGB components, with the color balance very much dependent on the viewing angle. I sure hope that the 60 LED/m strip with white background and used as indirect lighting will even this out.

On the plus side, the ≈ 300 Hz PWM of the new rgbAdjust.pde sketch I’m using on the JeeNode seems to make these LED strips completely flicker-free.

Onwards!

JeeLink DataFlash logging

In Hardware, Software on Sep 11, 2010 at 00:01

Since July, the JeeLink has undergone a slight hardware change. It used to include an 8 Mbit AT26DF081A DataFlash chip, but unfortunately this chip is no longer being produced:

Jl Dataflash

As it turns out, only very few chips are physically and electrically compatible with the AT26DF081A. The only one I could find is the AT25DF041A, which has half the memory, i.e. 4 Mbit.

So that’s what’s being included on the current batch of JeeLinks. I’ll review the alternatives when it is up for a revision, but for now I’ve just opted for this change – especially since the use of the on-board DataFlash memory chip on the JeeLink is probably still very limited.

Having said that, the “RF12demo.pde” sketch does include support for the flash memory, in the form of a continuous data-logging capability. This is the main topic of this post, actually.

All packets received by the JeeLink are saved up and stored in flash memory whenever 256 bytes of data have been accumulated – along with a sequence number and the current value of the millisecond counter.

This process takes place continuously, wrapping around when all available flash memory has been filled. There are some tricky details involved, since DataFlash needs to be erased before re-use. The way RF12demo does this is that it always erases one extra 4 Kb block of memory, just ahead of the current write buffer pointer.

The “sequence number” is a 16-bit counter which gets incremented on each power-up and whenever the buffer writing wraps around. In practice, it’ll never overflow, but there is a “w” (wipe) command to fully erase the entire flash memory and start over if that is ever needed. It only works when executed as “12,34w” to prevent an accidentally typed “w” from wiping the flash.

The data-logging mechanism in RF12demo can be used to catch up on received messages when the attached computer has been asleep for a while. There is a “d” command which dumps info about each 256-byte page in the DataFlash – for example:

    > 0d
     df# 34 : 2 698 28309
     df# 35 : 2 955 3849
     df# 36 : 2 1213 38883
     df# 37 : 2 1471 51360
     df# 38 : 2 1728 55763
     df# 39 : 2 1986 26600
     df# 40 : 2 2244 10261
     df# 41 : 2 2501 57698
     df# 42 : 2 2757 1373
     df# 43 : 2 3016 25513
     df# 44 : 2 3273 41145
     df# 45 : 2 3532 39344
     df# 46 : 2 3789 63313
     df# 47 : 2 4047 57266
     df# 48 : 2 4304 13464

Pages 34 through 48 contain data, all from the same power-up cycle (seqnum = 2), and spanning time 0.698 through 4.304 (seconds). The last values are 16-bit checksums, and less useful here.

What you can do with this data is play it back with the “r” (replay) command:

    > 0r
    r: page 33 48
    R 2 698 3 129 44 0 0
    R 2 704 61 4 17 6 34 116
    R 2 708 56 199 0 215 0
    [...]
    R 2 944 56 147 0 215 0
    DF R 34 2 698
    R 2 955 3 133 44 0 0
    [...]
    R 2 4298 61 52 232 0 135 39
    DF R 47 2 4047
    R 2 4304 3 185 44 0 0
    [...]
    R 2 4525 56 198 0 215 0
    R 2 4538 61 52 233 0 134 39
    R 2 4541 61 4 1 135 49 145
    DF R 48 2 4304
    DF E 48 4 17476

If you replace the “R” and the next two numbers with “OK”, then you’ll see that a long stream of received packets is being reported. The data is internally stored as variable-length binary data, i.e. in a very compact format, but replay converts it back to the same bytes-as-small-integers format as the original “OK” packets.

The replay command also takes arguments to play back from a certain point. The way this works is that the output includes “DF R …” replay markers, which indicate which page has just been replayed. Furthermore, special “DF S …” store markers are also occasionally inserted in the output during normal reporting:

    DF S 49 4 28

With these two bits of information, it is possible to track the point in the logging process so far: whenever a “DF S” or “DF R” arrives, it marks which particular page has just been completed. By storing this on the receiving computer, we can remember how far we got when shut down (even accidentally).

To recover data when started up again, the replay command can be given 6 arguments: “S,S,T,T,T,T r” which tell the JeeLink to start replaying after sequence number SS and time TTTT.

This replay recovery hasn’t been added to JeeMon yet. Once implemented, JeeMon will be able to collect data from remote nodes even if the computer is off once in a while (at night, for example). All we have to do is keep the JeeLink powered, so that it will log all incoming data it its DataFlash.

Back to the hardware change in the JeeLink…

As mentioned on the discussion forum, the new DataFlash chips broke the RF12demo code, which looks for a specific hardware signature to detect the chips. I’ve added some conditional definitions to RF12demo, so that it can now be built for either the 4 Mbit or the 8 Mbit version:

Screen Shot 2010 09 10 at 21.27.24

The RF12demo.pde sketch in the RF12 library has been updated. This new version announces itself on the serial USB port as “[RF12demo.5]”. Note that the current batch of JeeLinks still has the older sketch, so you’ll need to recompile and upload the latest one if you want to use the datalogger functionality.

PC Bees

In Hardware on Sep 10, 2010 at 00:01

New batch of JeeSMD‘s and Carrier Boards just came in:

Dsc 1918

At last! – this batch took a lot longer than anticipated…

The JeeSMD fixes a nasty error reported in the Talk forums, which had two pins exchanged on the 3.3V voltage regulator.

The reason I missed this, is that I used the JeeSMD on a LiPo battery pack, which runs at around 3.7V – and as it so happens, an MCP1703 will generate a voltage drop of roughly 0.4V when connected the wrong way around. So it all basically worked exactly as expected in my setup.

I bet Mr. Murphy had a major role in this “accidental” design detail…

The Carrier Boards haven’t changed. I simply ran out of the first 100 way faster than I had expected. The good news with the Carrier Board + Box kits, is that I’ve now also got a decent stock of DC jacks, so these will be included with all orders. In fact, I’m also throwing in a DC plug, so you can make your own power cables, or adapt some 5..12V DC power supply to fit these standard 2.1/5.5 mm jacks:

Dsc 1919

There are several dozen packages waiting for this back-ordered stuff. I’ll get them out in the coming days!

JeeNode, JeePlug, Home automation

RGB strips, revisited

In Hardware on Sep 8, 2010 at 00:01

A while back, I reported about hooking up an RGB strip. That was then.

Now there is the MOSFET Plug to make such hookups a lot simpler. So it’s time to revisit that experiment, because I want to find out how well RGB strips would work for < w a r m > white lighting in the house. Theoretically, RGB can generate any color, so that would include any “temperature” of white, right? Trouble is, I’m not convinced that LED strips are color matched well enough across their entire length to accomplish such lighting conditions over a few meters. The other concern is that RGB LEDs have the Red, Green, and Blue LEDs sitting next to each other, so there may be some fringe colorization – maybe diffusers will be needed.

Then again, I do have one LED lamp of 1 meter long which generates an abolutely great tint of white (“white tint” – interesting concept, eh?).

Time to find out:

Dsc 1912

I obtained some samples of “5050” RGB self-adhesive LED strip, one with 30 LEDs per meter, the other with 60 LEDs. They are mounted on nice white flexible strips, and the whole thing was tacked onto my all-time favorite material: foam board!

Since 2 x 3 is 3 x 2, I used 3 MOSFET plugs to connect this together, these are in turn plugged into a Carrier Board with a JeeNode on its back, and the whole kaboodle is placed in half a box. Since the plan is to later attach this unit to much longer LED strips, I don’t really want to close that box – the MOSFETs will no doubt generate too much heat once they drive several amps each.

Here is how everything is wired together:

Screen Shot 2010 09 07 at 22.31.09

Oh, there’s one more wire: on the photo you can see a red jumper wire running from +12V to a PWR pin on the Carrier Board (I used the FTDI connector) – so the same 12V supply is used to power the JeeNode itself.

That’s it. Six output lines to control the on-off state of two independent strips of RGB LEDs.

Tomorrow – the software…

Pogo pogo

In Hardware on Sep 7, 2010 at 00:01

Until now, I’ve always been testing plugs with an Extension Cable:

Dsc 1903

Works ok, but with two hands, it’s a bit limiting for more complex cases, such as this Input Plug test rig.

Looks like people seem to be using spring-loaded “pogo” test pins more and more. Here’s one, which comes as a small 6-pin wide SMD “header”:

Dsc 1902

I mounted it on an obsolete I2C plug, simply to have a better grip on it. Not a big step up from the Extension Cables, but it’s slightly better because of the spring-loaded pins. No need to press as hard.

But to really make it simpler, you need to place the pins in all the places you want to test at once. Here’s one adapter which works for several plugs:

Dsc 1900

Once soldered on both sides, it’s actually quite sturdy.

Now, all you need to do is place the board under test on top, and press down slightly:

Dsc 1901

This was the trivial part. It’ll be a bit more work to create custom pin arrangements for the different plugs with I/O headers on the side. But it’s a great step forwards, and will let me do a better job of testing the more elaborate plugs as well.

Right now, all I2C-type plugs are verified to work from the bus side, but connections to other headers are a matter of visual inspection still. There’s “room for improvement” as they say…

Running off a single AA battery

In Hardware on Sep 6, 2010 at 00:01

The other day, I found the LTC3525 – an interesting little (yes, tiny!) boost regulator chip, which might be a pretty good power source for low-power JeeNodes.

Couldn’t resist – had to try it…

Here’s a test setup using my favorite foam-board as base, with one AA battery driving a test LED:

Dsc 1897

(hard to see, but that LED is indeed on)

Did I mention that the whole thing uses tiny parts? It did take some patience…

Dsc 1898

Tests show that it will regulate any input voltage from 0.8V .. 5.5V to 3.3V @ 60..200 mA depending on the input voltage. And with 70..90% efficiency, even in the 10’s of µA current consumption range. I’ve verified that it will indeed down-regulate when fed > 3.3V, which makes it very flexible.

The quiescent current draw of this circuit appears to be around 20 µA on a 1.3V input.

So it looks like this could work out nicely:

Dsc 1899

My hunch is that this thing could last 6 months for a room node. Maybe more, but with a 6-pack of AA batteries plus charger, who cares?

Hmm, might be worth designing a little board for…

Utility Plug pack

In Hardware on Sep 5, 2010 at 00:01

The recently announced Utility Plugs have room on board to add some resistors, diodes, transistors, LEDs, etc. but that’s not always needed. Sometimes, you just want a way to bring a cable out with a decent connector.

The way to do that is to solder these 4 jumpers to connect everything straight through:

Dsc 1907

Now, all you need is a cable. But beware – this one isn’t what it seems:

Dsc 1906

It only has the middle two wires connected:

Dsc 1911

Not much we can do with those: they are +3V and GND on the Utility Plug!

The way to spot them before cutting the wire, is to look carefully at the connector:

Dsc 1908

As you can see: 4 gold-plated pins on the outside (i.e. RJ-11), but only 2 wires have acually been pushed into the connector. Here’s one I made myself, using modular plugs and flat telephone cable from a local DIY shop:

Dsc 1909

Now I get DIO and AIO as well (possibly altered by the circuits added to the Utility Plug):

Dsc 1910

To better support wired-through scenarios, I’ve added a “Pack of 4” variant of the Utility Plug to the shop:

Dsc 1904

It omits the extra components, so you just need to close those 4 solder jumpers. Note that there was no room on these boards for mounting holes – best way is probably to hot-glue them to a stable base plate of some kind.

JeeNode goes solar

In Hardware on Sep 3, 2010 at 00:01

Now that ultra low-power options are coming into reach for JeeNodes, lots of new scenarios can be explored.

The most obvious one is probably a solar-powered JeeNode … so meet the latest new node #5 at Jee Labs:

Dsc 1875

It also uses a 0.47 F supercap, same as yesterday, but now hooked up to a small 4.5 V solar cell (which can only deliver a few mA in bright sunlight), and a Schottky diode between the solar cell and the capacitor.

Here’s the “power supply” in more detail:

Dsc 1876

As you can see, the solar cell is tiny. A few square cm’s only. In fact, it takes quite some time for it to charge the supercap to acceptable levels. I had to place the cell in moderately bright sunlight for about half an hour to get to a 4 Volt charge. It was inching along, taking several seconds per 0.01 V increase.

To avoid losing all that charge right away in the power-up cycle, I modified the ATmega’s fuses to start in 258 clock cycles after power down, and to start up within 4.1 msec after reset. That way it will start up as quickly as possible at all times. The 258 CK setting is particularly nice, because it means the ATmega can get out of total power down within about 16 µs, fast enough to respond to a byte RX/TX interrupt from the RFM12B!

Does it work? Check it out: after connecting the JeeNode with the “radioBlip.pde” sketch pre-loaded… away it went – sending one packet every 60 seconds as node 5:

While exposed to the current partly-sunny / partly-cloudy light levels, the voltage on the supercap is still increasing. This is good – it means there’s a surplus of solar energy, even with these transmissions going on. That extra energy will be crucial if this thing is to last through the night…

If everything works out, this little Arduino-compatible bugger could well be the first JeeNode to become completely autonomous and transmit wirelessly… forever!

Time will tell :)

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.

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).

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!

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!

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 Wiki, 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.

Techniques, JeeSMD, ISP

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!

Techniques, JeeSMD

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.

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.

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!

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.

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…

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 !

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.

JeeNode, JeePlug, Home automation

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…

JeeNode, Home automation

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.

JeeNode, Home automation

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.

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.

JeeNode, Techniques, ISP

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!

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!

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

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.

Sensors, Reflow

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.

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 on this page 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’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 :)

JeeNode, JeePlug, ISP

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!

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.

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!

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 0x29, 0x39, or 0x49)

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!

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 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.

JeeNode, Home automation, 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!

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 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? 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.

JeeNode, CNC

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…

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.

Update – for the Room Board v2, see this weblog post.

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.

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!

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 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 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.

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.

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.

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…)

JeeNode, Sensors, POF

Wireless Light Sensor – POF 71

In AVR, Hardware, Software on Dec 8, 2009 at 00:01

After last week’s Hello World POF to get started, here is a new Project On Foam:

A battery-powered wireless light sensor node. This is POF 71, and it’s fully documented on the wiki.

This project goes through setting up the Ports and RF12 libraries, setting up a central JeeNode or JeeLink, and constructing the light sensor node.

It also describes how to keep the node configuration in EEPROM, how to make a sensor node more responsive, and how to get power consumption down for battery use.

The POF includes code examples and uses the easy transmission mechanism, with the final responsive / low-power sketch requiring just a few dozen lines of code, including comments. The sketch compiles to under 5 Kbyte, leaving lots and lots of room to extend it for your own use.

All suggestions welcome. Anyone who wants to participate in these POFs, or in the wiki in general, just send me an email with the user name you’d like to use. I’m only restricting edit access to the wiki to prevent spamming.

JeeNode power pins

In Hardware on Dec 7, 2009 at 00:01

The JeeNode has a number of connections for external power. This is the place before the 3.3V LDO regulator. Keep in mind that all these pins are tied together, electrically:

JeeNode power pins.png

This has two important consequences:

You can power a JeeNode through any of these pins. It does not matter how you connect power to a JeeNode, all of them will have the same effect. You don’t have to connect a battery to the battery connector or the FTDI connector, you can also tie it to a PWR pin on any of the port headers (as I tend to do with Projects On Foam).

You should avoid connecting multiple power sources. If you connect a 9V battery, for example, the JN will work fine. But if you leave it connected when plugging in an FTDI interface such as a USB-BUB, then the 9V will find its way to the FTDI chip, and through the internal ESR diodes probably also to some I/O pins. Chances are high that you’ll damage at least the FTDI and the ATmega chips at this point (thanks to Paul Badger for pointing this out). A 3- or 4-cell Alkaline / NiMh battery pack can probably take some abuse without damaging anything.

There are no diodes in these various connections because the JeeNode is designed to be usable under very low power conditions. Throwing away 0.6V (or even just half that with a Schottky diode) is not always an option. The MCP1702 voltage regulator on the JeeNode was specifically selected to have an extremely low drop-out voltage (under 0.1V at low power levels) and a minute quiescent current draw (under 2 µA). This means that you could power a JeeNode from just 3.4V, perfect for 1 LiPo or 3 NiMh batteries, for example. The price is reduced protection against incorrect use.

The JeeNode USB is slightly different. It is intended to always be powered from USB, i.e. with PWR fixed at 5V. There are no FTDI and battery connectors, and all the other pins are connected to the 5V line via a 350 mA polyfuse (PTC) as protection against over-current on the USB power line. You can probably power a JeeNode USB through any of the port or PSI connectors, as long as the voltage is around 5V. The current draw will be several mA higher than with a plain JeeNode due to the on-board FTDI chip.

(continued…) Read the rest of this entry »

Building the JeeNode v4

In Hardware on Dec 6, 2009 at 00:01

Here are the updated build instructions, using the latest v4 board.

This is the contents of the kit:

You’ll need some basic skill at soldering but don’t worry, as there are only a few parts to solder on. The best way is to start with the lowest-profile part, that way you can place things flat on the table and press down to keep the parts in place. So let’s start with the 10 KΩ resistor:

Turn the board around and solder the leads:

FTDI Reset Supressor

In AVR, Hardware on Dec 5, 2009 at 00:01

Sometimes the simplest things are so obvious that it’s easy to miss them…

I occasionally do not want to reset a JeeNode when accessing it via USB. The reset is great for uploading, because the ATmega’s bootloader runs right after reset and intercepts such upload requests in a very convenient way. But sometimes, you just want to leave the ATmega running when re-connecting to it.

Meet the “FTDI Reset Suppressor”:

All it does is break the reset connection between an FTDI interface such as the USB-BUB and the JeeNode.

Just to make this post a little longer, here are the steps to make one:

And here is an action shot:

Tada! And it’s totally voltage, baud-rate, and platform independent… :)

Update – it just occurred to me that this already exists, it’s a 5-pin stacking header! Or a 6-pin one, as follows:

JeeNode clock

In Hardware, Software on Dec 4, 2009 at 00:01

To follow up on a recent post, here is the same real time clock demo using a JeeNode + USB BUB instead of an Arduino + Plug Shield:

(instead of JeeNode + USB BUB, the new JeeNode NoRF or a JeeNode USB could also have been used)

I chose to use two different ports for RTC and LCD, but these could just as easily have been daisy-chained on a single port.

The changes to the code are minimal, here is the complete sketch:

Screen shot 2009-11-29 at 15.44.07.png

The changes affect a few declarations at the top, and the fact that the use of the Wire library was hard-wired into the getDate() function.

Updated Thermo Plug

In Hardware on Dec 3, 2009 at 00:01

The Thermo Plug prototype has been updated to the final version:

This plug supports either a thermocouple, an NTC, or a 1-wire temp sensor on the AIO line, and either a buzzer or a relay on the DIO line. It does not use I2C.

The connections of the AD597 thermocouple readout chip are now correct, and there’s a new 4.7 kΩ pull-up resistor option when using the 1-wire interface.

I’m still looking for a good way to attach the K-type thermocouple (soldering is not a good option with those metals), and am considering adding this plug as kit with AD597, thermocouple, buzzer, and the rest of the components to the shop. This is the combination I’m using in my reflow oven / grill controller. The bare pcb is already available.

POF

Hello World – POF 52

In AVR, Hardware, Software on Dec 1, 2009 at 00:01

The first Project On Foam is inevitably a blinking LED:

Not very exciting, but it’ll allow me to go through the steps needed to set up the development environment, the first-time USB hookup, and getting a first sign of life out of a JeeNode in Physical Computer terms…

There is a new section on the Jee Labs wiki which I’m going to use for POFs. For rather obscure reasons, this POF is #52 (new POF numbers always increase).

Note that as Project On Foam, this Hello World example is rather silly – because it doesn’t really need a foam base at all. But bear with me – this step is intended to help people through the first (and sometimes daunting) steps of getting started.

The challenge for me right now is to provide the proper information as concisely as possible. These POFs are being placed on the wiki so they can be updated and improved. There will be a few more people involved in this, which again makes the wiki much more suitable to collect and maintain all the POFs than say this weblog. New POFs will be announced on this weblog, but updates are an ongoing process on the wiki pages themselves.

There have been a lot of experiments and projects at Jee Labs over the past year, in various stages of completion. From hooking up all sorts of sensors to the house-monitoring network currently running here at Jee Labs. It is my intention to redo a number of these as POF, in more detail and with more background information. Other POFs will be completely new, though – the list of fun stuff one can do with Physical Computing is endless!

Other news: since assembly and reflow soldering of the JeeLink and the JeeNode USB has been going a lot better lately, their price has been reduced to €29.50 (incl. VAT and shipping) – see the shop for details.

Plug Shield clock

In Hardware, Software on Nov 30, 2009 at 00:01

As a reminder that not everything here at Jee Labs is about JeeNodes, here’s a clock for the Arduino (which keeps track of time, even when not plugged in):

This was built with an Arduino Duemilanove, a Plug Shield, an RTC Plug, and an LCD Plug piggy-backed onto a 2×16 character display.

Here’s the sketch:

Screen shot 2009-11-29 at 13.12.46.png

And here are links to the PortsLCD.h and PortsLCD.cpp source files.

But there could be some serious trouble ahead…

This code depends on an extended version of the LiquidCrystal library that comes with the Arduino IDE version 0017. Since I don’t want to modify that code, I had to use different names, so the PortsLCD.h/.cpp files use the following class names:

LiquidCrystalBase – an abstract class containing all the generic LCD code from the original class
LiquidCrystalPins – this is for use with plain pin connections, as before
LiquidCrystalPort – this uses bit-banged I2C with one of 4 JeeNode ports
LiquidCrystalI2C – this is for use with hardware I2C, using the Wire library

These names are slightly different from the previous ports-only version, btw.

So PortsLCD is a library which does everything the original did, and more. The flexibility is that you can write your sketches with this and then use any type of LCD you like with it, by just changing a single line of code. And if you’ve got a different hardware hookup, a new class can be added for it based on this same code, so that again your sketch only needs to change a single line of code to use it.

So far, so good. This is the benefit of object-oriented code and polymorphism.

But there is a price, due to the way the Arduino IDE does things: even if you don’t use the Wire library, you’ll need to include it in your sketch! For similar reasons, I’ve been forced to include the RF12 driver in all my demo sketches, even those that don’t use it. Leaving it out leads to build errors and prevents uploading.

This is not a C/C++ issue, the gcc compiler is actually quite smart about leaving out things which are never used. No – this complication is caused by the way in which the Arduino IDE tries to do some clever things to simplify naive use of libraries. I’ll go into this in another post – it is not a show stopper yet, but it may become one as I start combining more features and code, since memory on an ATmega is quite limited.

To put it bluntly: the way the Arduino IDE currently deals with libraries is a ticking time bomb…

JeeLink flash memory

In Hardware, Software on Nov 29, 2009 at 00:01

The recently updated version of RF12demo automatically logs all incoming data to the 1 Mbyte flash memory in a JeeLink. It looks like this is starting to work fairly well – I’ve been leaving a JeeLink on for over a week now, picking up packets from a number of different sources around here. It’s still only 80% full:

So the JeeLink is now at page 3102 of 3840. Here are the first and last lines from the dump command:

Screen shot 2009-11-28 at 12.36.37.png

…

Screen shot 2009-11-28 at 12.38.30.png

The first two numbers after the colon are the reboot count and the time in seconds since reboot. There have been a bunch of reboots (most of them caused by me connecting to the JeeLink via a terminal program to see how it’s doing). The last run has been going for almost 24 hours.

Here are the first and last lines of the actual stored data replay:

Screen shot 2009-11-28 at 12.42.30.png

…

Screen shot 2009-11-28 at 12.45.23.png

Again, the first two numbers on each replayed packet are reset count and seconds since reboot. The rest is the packet data itself.

That’s quite a bit of stored data – almost 84,000 lines of text. It took over 7 minutes to get it all across USB at 57600 baud. Each received packet of data uses about 10 bytes of flash memory on average, in this example.

These results are better than I expected. Even with much more data coming in, it should be possible to leave the PC turned off over say the weekend, with the JeeLink collecting all incoming data and then replaying it when the PC comes back on. The only requirement is a powered USB socket.

Good. My home monitoring network won’t need a PC or server to be constantly on, since I don’t intend to set up around-the-clock internet access to this info – unless perhaps while away from home.

Updated Plug Shield

In Hardware on Nov 28, 2009 at 00:01

The updated Plug Shield has come in, here pre-assembled and with all the headers soldered on:

This fixes the problem with D9, and adds one extra feature: there is now a pull-up for the IRQ line, with a solder jumper to connect it to D3. See the label “JD3” at the middle right in the above picture. This makes the IRQ pin on the port headers compatible with the JeeNodes when an IRQ pin is needed.

This shield is still called “v1” due to an oversight, but that should not be too much of a problem because only 3 prototypes have been sent out. If you got such an “old” prototype shield and want the final one, get in touch and I’ll send it (pcb-only).

On a related note, the Memory Plug has also been updated (to “v2”, correctly this time). This fixes an addressing limitation with 128 Kbyte EEPROMs.

Onwards!

POF

Introducing Projects On Foam

In Hardware on Nov 27, 2009 at 00:01

After exploring a number of options, I’m settling on foam board as the basis for my future Jee Labs demo projects. So here come the Projects On Foam – POF‘s!

What’s a POF? Well… I start with two JeePlugs and solder some headers onto them, as follows:

Then I take an A5-sized (148×210 mm) piece of 5 mm foam board / foam core:

… and glue those two plugs onto it using sticky tape or hot glue, pins up:

Last step is an optional battery holder and some rubber feet on the back side:

And there you go, the basis for an endless variety of Projects On Foam:

Just by sticking stuff together. Here’s an example:

I’ll probably fix one or two mini-breadboards onto the board as well.

The end result is modular, reusable, light, cheap, and sturdy enough to pick up and move around. It’s not meant for permanent setups, the whole idea is really to “doodle” with nodes and plugs in this way until everything works, and then to take it all apart and either rebuild the whole circuit from scratch with all the individual components, or to place these boards and plugs inside a more permanent enclosure.

Here’s another trial, with a cutout for the LCD to make it stick in place a bit better:

(apologies for the flash lighting)

As you can see, by adding a sheet of paper between the board and the different components, everything can be labeled and annotated.

I still need to fool around with this approach a bit more, but so far so good – it would be easy to make templates as PDF’s so others can replicate these Jee Labs projects more easily.

If there is any interest in this, I can make foam boards and other doodahs available via the shop. There’s really nothing to it.

Update – POFs now have their own section in the wiki.

JeeNode comparison matrix

In AVR, Hardware on Nov 26, 2009 at 00:01

All the final boards are in now. It’s time to step back a bit. Let’s start with a picture:

From left to right: JeeLink (v2), JeeNode USB (v2), and JeeNode (v4).

Here is a summary of the similarities and differences between these units:

(this comparison matrix is also available as PDF)

So there you have it – one happy JeeFamily :)

Update – Nov 30: lower prices for the JeeNode USB and the JeeLink!

Update – Dec 1: added the new low-cost “JeeNode NoRF” kit.

Meet the new Analog Plug

In Hardware on Nov 25, 2009 at 00:01

Here’s the revised Analog Plug (AP2):

Still the MCP3424, i.e. from 12- to 18-bit (!) resolution, depending on configuration, supporting 4 differential inputs with an input range of -2.048V to +2.048V. The plug is I2C based and can be daisy-chained with other I2C plugs on the same port.

Here’s a hookup to measure the voltage of a NiCd battery:

Note: I did not forget the solder jumpers. With this chip, floating inputs are ok. The I2C address is 0x68 (which is actually not such a good choice because it conflicts with the RTC plug).

The following code turns the JeeNode into a 4.5’ish-digit voltmeter:

Screen shot 2009-11-23 at 18.21.27.png

And here is the sample output:

Screen shot 2009-11-23 at 18.05.39.png

Is it precise? You bet.

Is it accurate? Well, my multimeter says 1.265…

Node, node, node

In AVR, Hardware on Nov 24, 2009 at 00:01

Ok, finally got around to building a bunch of JeeNodes for all those room boards I had waiting:

Just for the heck of it, I decided to leave the boards joined together, as they come from the pcb manufacturer. This picture was taken just before separating these final units.

Small detail: on the left the original 10 µF capacitors, lying down, and on the right the new ones I will be using from now on, which are much smaller and leave the battery connection pads exposed.

The good news is that these units all worked out of the box. Great, eight of ’em will go straight to their room :)

I’m not having quite as much luck so far with the assembly of JeeLink and JeeNode USB boards, both using SMT parts. There, I often have to debug 2 or 3 out of 10 boards before they work. Occasionally, even that doesn’t solve it so once in while a board gets set aside, awaiting further debugging some other time.

It’s called “production yield”, I think, and I’m not quite there yet… oh, well.

Arduino?

In AVR, Hardware, Software on Nov 23, 2009 at 00:01

What is it? Hype? Hobby? Hacker stuff? Here is the best overall introduction I’ve seen so far – by Dave Jones. It’s 19 minutes – plenty of time to get used to his accent :)

(view directly on YouTube)

I think he really touches on all the important aspects and inevitable trade-offs.

Me, I use the Arduino bootloader for JeeNodes and JeeLinks all the time, and the Arduino IDE to compile and upload stuff to them, as well as the serial console in many cases. I do use my own editor environment – which is easy to do once you disable Arduino’s built-in one (this is not well documented, Google for “Arduino external editor”). So for me the Arduino is really the bootloader, plus the IDE just as compile/upload system.

As Dave points out, the Arduino is a wrapper around the avr-gcc compiler + avrdude in combination with a convenient USB-based upload/console/power hookup. The rest is libraries, conventions, a Java based IDE (based on Wiring), and optionally a Java-based PC-side front end called Processing.

On the embedded software side, it’s really standard full-scale C and C++.

Which is great, IMO. I can keep going with the Arduino-compatible JeeNodes and JeeLinks, and their built-in wireless, port conventions, 3.3V operation, and all the add-on plugs – knowing that much of this will work fine with as well as without all the stuff going on in the Arduino ecosystem right now.

Yeay, it’s drawing!

In Hardware on Nov 22, 2009 at 00:01

Baby steps in CNC land, but still a milestone for me:

With a pencil, the worst that can happen is a broken tip. I’m not quite ready to put a Dremel on there, turning at 10’s of thousands of RPM, and chewing its way through anything that happens to be near it. Need to get the limit switches and the relay board going first, so it can be turned off under computer control. Besides, it’ll be noisy and get very dusty.

The red-black wire hanging down the “gantry” (yeah, new words every day) is for the limit switches, which have been glued in place but not yet hooked up. The switches have been connected in series, two per axis and using the Normally Closed pins so that the circuit gets broken when a limit switch trips. That way it will also act as stop signal when a wire gets pulled loose.

I’m still exploring, but I think I’ll call the longest axis (towards the camera) the X axis, and the sideways one the Y axis. Let’s just stick with Z for up and down ;)

The drawing is the standard demo built into EMC v2, and I had to move the paper during while drawing because it would have run off the edge otherwise:

Some oddities in there because the pencil is not rigidly attached to the tool holder, but basically it’s doing all the right things. And making funny sounds as the steppers go through curves such as for the “C” and the “S”. Can it draw an accurate rectangle? I hope to find out soon.

So now zee Jee Machine is writing on paper! Onwards!

OOK unit

In AVR, Hardware, Software on Nov 21, 2009 at 00:01

Here’s an ELV 868 MHz OOK receiver, connected to the new JeeNode USB:

Note that this plug can be used for any of the four ports, simply by plugging this thing in one of the four possible orientations. In this case, it’s hooked up to port 1.

The receiver is mounted on a JeePlug for stability:

There really are only three wires: GND, +3V, and the received bit stream, which is tied to the AIO pin:

You can clearly see the built-in pcb antenna on these last two pictures.

The code for this is similar to the one used in an earlier post and basically runs a couple of bit decoders in parallel to recognize FS20, (K)S300, and EM10 commands. It’s available here. Sample output:

Screen shot 2009-11-19 at 15.02.31.png

Or have a look at the OOK relay, with which this plug will also work.

I really need to clean up and merge the different OOK decoding sketches – they all have slightly different capabilities…

One thing which would be very nice to do with this unit, is a general sketch which reports incoming OOK packets but which also uses the OOK sending capabilities of the RF12 driver to send out such packets, to control FS20 devices for example. That mould make this a general-purpose bi-directional 868 MHz OOK unit, connected via USB and controllable via simple serial-port commands.

I’ll punt for now. Don’ have time to go into this. Or perhaps I should say… exercise left for the reader :)

And maybe one day we’ll get OOK input going without extra hardware ?

PS. Good news: everything is now in for the JeeNode USB, so I’ve started shipping them.

CNC progress

In Hardware on Nov 20, 2009 at 00:01

The CNC router is coming together nicely. The controller board works so far, and so does the EMC software running on a Dell laptop:

Here’s the complete setup, next to the V90 (the electronics will go inside once finished):

And here’s the EMC 2.3.4 software, running under Linux (Ubuntu 8.04):

Screen shot 2009-11-15 at 16.10.16.png

It just finished “doing” the demo, i.e. making the motors turn in lots of mysterious ways.

Some tech specs: the laptop has a worst-case real-time jitter of around 17600 nSec, which means the computer can send out up to 30,000 steps per second. I’m using quarter stepping, so that translates to 800 steps per rev, 4000 steps per inch, i.e. max about 7.5″ per second on the X and Y axes (which the motors can’t handle anyway – I may switch to 1/8th micro-stepping later). The system uses imperial units for the screws, so that’s what I’m sticking with, but I’ll probably do most designing in metric units. Resolution of the machine is about 0.006 mm for X & Y, and even higher for the Z axis. Don’t know about accuracy, repeatablity, and backlash yet – that’s where lots of tweaking will probably be required.

Next step is to mount the motors on the V90, and then go through all sorts of adjustments to make this thing move properly in all three axes. Oh, and hooking up the emergency button and the six limit switches.

And that’s just the CAM side of it all… CAD will be a completely different story!

CNC electronics

In Hardware on Nov 18, 2009 at 00:01

First step to CNC was the mechanical assembly of the V90. Little to report here – it took an hour or two. Adjustment and tweaking will probably take a bit longer, once things start to move.

The next step was a bit more work – here’s the power supply + electronics stuff, mounted on some scrap wood. It was made flat enough to mount inside the V90, underneath the work area and X-axis (Y-axis?) slide:

At the top what this is all about: connections for three stepper motors and a strip to hook up limit switches and the emergency stop button.

The power brick in the bottom right supplies 5V to the parallel-port side of the RF-isolated breakout board and the opto-isolated relay board. That means the 24V @ 6.5A supply can’t ever reach the computer. It also avoids 1A current through the linear voltage regulator to supply the relays (i.e. 20W of heat, just to go from 24V to 5V).

End stop switches, heat sink, and relay board have not yet been added / connected. Plus some power cable fasteners at the bottom, so they can’t be yanked loose.

All the high voltage is in one area at the bottom, to be covered by a shield. But even without the shield: all the exposed metal is recessed so it can’t be touched without sticking some sharp object in there – 220V scares me!

Meet the Output Plug

In Hardware on Nov 17, 2009 at 00:01

Here is another I2C I/O plug:

It combines the MCP23008 8-bit port expander with a ULN2803 darlington array which can drive up to 500 mA @ 50V. The ULN2803 includes clamping diodes, so that relays and other small inductive loads may be tied directly to this plug.

Here is an example with a little unipolar stepper motor:

The red-black wire is from a 12V lab supply.

This demo sketch pulses the lower 4 bits of the output plug to rotate this motor back and forth by 200 steps:

Screen shot 2009-11-12 at 15.46.22.png

The above was inspired by some sample code by Chad Phillips. It has been added the the Ports library as “output_stepper” example sketch.

JeeFab?

In Hardware on Nov 16, 2009 at 00:01

Heh, heh. Some crazy stuff is about to happen in the Jee Labs…

I’ve received a CNC router kit, i.e. the subtractive way to create 2D and 3D shapes. This one:

Picture 2.png

It’s one of the simplest CNC units available, from what I can tell. The work area is about 30 x 45 cm (A3).

Got various ideas to try out – from one-off pcb’s to front-panels. And more.

CNC routers can be very noisy and dusty, so this thing will be placed in a corner of the garage. A trusty ol’ Dell Inspiron 5000 laptop will sit next to it, running EMC and driving it all via the parallel port.

I’ve also ordered an extruder-type machine, i.e. the additive way to create 3D shapes. This one:

cupcake

I don’t expect any of this to be a time saver – on the contrary, getting all the details right for CNC is going to take a huge amount of time and effort. But if it helps me try out ideas and explore new avenues, then so be it.

Yeah. Totally. Crazy. I know…

Memory Plug redux

In Hardware on Nov 15, 2009 at 00:01

Another case of me mixing up specs. Here’s the original prototype:

And here’s the latest one:

Guess what… the original prototype is ok. The “latest” one is bad :(

While testing the original plug, I noticed that multiple chips showed up at I2C addresses 0x50, 0x52, etc – i.e. with a gap in the addressing.

I thought this was a mistake in connecting the E1 and E2 address lines, but it turns out that the lower address bit is needed for 128 Kb addressing (while testing, I used some spare 64 Kbyte units). So without thinking, I changed the lines and had “final” versions made.

But it was no mistake… an M24M01 needs 2 I2C addresses to access both 64 Kbyte banks of its memory:

Screen shot 2009-11-08 at 19.27.04.png

So, in other words the latest plugs can’t hold 4 chips of type M24M01 – only two, in positions 0 and 2.

The original plug works as intended, with each 128 Kbyte chip responding to two I2C addresses. So a fully populated plug looks as eight different I2C memory chips, each capable of storing 64 Kbyte.

Doh. I’ll need to re-order. Until then – the remaining old / green plugs will be shipped.

Note: if you ordered memory plugs and received blue ones, and if you want to be able to use them with more than two 128 Kbyte memory chips, let me know and I’ll send you the boards which properly support all 4 chips.

Energy tracking with Cost Control

In Hardware on Nov 14, 2009 at 00:01

The ELV Cost Control is a set with two power measurement units and a display:

Every 5 seconds the base units transmit their readings over 868 MHz, each with a unique 4-digit ID. The display shows actual and aggregated results for up to 5 units. You have to press a button to get an update, i.e. the receiver is only activated on request – for about 6 seconds.

Setup is trivial. Tracking current power consumption, peak power consumption, projected monthly & yearly cost, and hours on vs. total is extremely straightforward.

This is a very convenient setup because you can put the sensor in the outlet, way down deep behind everything if needed, and then take individual appliances out to see what effect each one has on the total consumption.

I found out that my 5-port Ethernet hub draws 3W (of which 2W in the adapter), and an old monitor I’m only using occasionally uses 4W (both asleep and “off”).

Our TV + amplifier + speakers + satellite receiver is drawing 6W when idle. Most of this is the Mac Mini (used as TV), due to an energy saver which cuts power to all other appliances when the Mac sleeps.

At €12.95 per outlet, this is the cheapest good-working solution I’ve found so far for tracking power use at individual outlets. I’m thinking of getting several more of these for the refrigerator, washing machine, and other intermittent power consumers.

Does anyone know whether the Cost Control wireless protocol has been documented?

Arduino plug stack

In AVR, Hardware on Nov 13, 2009 at 00:01

You could combine all these …

… and create an Arduino sandwich like this – with full access to all the Arduino pins:

That’s a Plug Shield with, from left to right / top to bottom:

UART Plug – with a hardware serial port
RTC Plug – with a battery-backed real time clock
Expander Plug – with 8 extra general I/O lines
Memory Plug – with extra EEPROM memory
Pressure Plug – with pressure + temp sensor
LCD Plug – with a 2×16 char LCD display on top

Each of the plugs can be accessed via I2C, i.e. using the Arduino’s “Wire” library.

Would all this work? Yes, I’m pretty certain it would.

Would it be useful? Probably not in this combination…

I just wanted to show off the I2C plugs and shield ;)

Meet the Pressure Plug

In Hardware on Nov 12, 2009 at 00:01

Here is a little interface board for the BMP085 atmospheric pressure sensor – I2C based and daisy-chainable as usual:

This sensor is a bit tricky to solder by hand, as you can see in an older post.

The sensor is extremely sensitive and measures both pressure and temperature. The “bmp085demo” sketch in the Ports library hasn’t changed:

Screen shot 2009-11-05 at 15.16.54.png

Here’s some sample output:

Screen shot 2009-11-05 at 15.16.32.png

The temperature is not 27°C around here ;) – this board is simply still cooling down from the reflow!

This new Pressure Plug will replace the hand-soldered one in my OOK relay, of course.

Analog, but not quite

In Hardware on Nov 11, 2009 at 00:01

The original Analog Plug is a bit overkill and a bit expensive for 8 simple 12-bit channels. I’m going to switch to an MCP3424, which has “only” 4 channels. The interesting bit is that they go all the way up to 18-bit resolution – if you need only about 4 samples per second (think thermostats, voltmeters, etc).

Here’s the board I had made:

And here’s the patch I had to apply (VSS and VDD mixed up, doh!):

This sketch puts the chip in continuous 18-bit mode and reports the readings:

Screen shot 2009-11-05 at 17.54.24.png

Sample output:

Screen shot 2009-11-05 at 17.54.05.png

I tied channel 1 “-” to ground and connected a small trimpot to “+” – note that the input range is bipolar and should be within -2.5 .. +2.5 V (or less, since input gain is adjustable from 1x to 8x). The sample output shows readings while turning the trimpot a bit, with 18-bits these readings lie between -131,071 and +131,071.

Luckily only a few of these plugs have been made so far (as part of a larger panel with other stuff on it), so there’s no harm done. To redo them properly will just take a few more weeks, as usual…

Extension cables

In Hardware on Nov 10, 2009 at 00:01

As an experiment, I had these 150 mm long custom cables made:

They can be used for anything of course, including FTDI. But their main purpose, and the reason the wires are colored the way they are, is for use with ports and plugs:

PWR = Red
DIO = Yellow
GND = Black
+3V = Green
AIO = White
IRQ = Blue

Looks like these will be quite convenient, also for mounting stuff inside an enclosure.

Got a bit more than I will need here at Jee Labs, so they are now also in the shop ;)

JeeLink flash works

In Hardware, Software on Nov 9, 2009 at 00:01

Ok, the last hurdle has been passed. The new 1 Mbyte flash memory on the new JeeLink v2 works – I’ve been able to erase the chip, write data to it, and read it back.

Here is the main test code I used:

Screen shot 2009-11-05 at 00.26.33.png

And here’s the output:

Screen shot 2009-11-05 at 00.26.00.png

Some timing results can be gleaned from that output:

Erasing the entire chip takes 5.7 seconds (!)
Reading takes about 1.1 mSec per 256-byte page
Writing takes about 1.4 mSec per 256-byte page
Reading 8 bytes takes about 90 µSec

Good enough, but definitely not instant in the ATmega’s time scale.

This code needs to block-out interrupts while accessing flash memory because the radio can generate lots of interrupts which need to be serviced quickly over that same SPI bus. Some care is needed to give enough attention to the radio during long memory transfers – it looks doable.

Anyway, I’ve started assembling a bunch of these JLv2’s. Here’s the very first hand-soldered batch:

At last!

Meet the JeeNode USB

In Hardware on Nov 7, 2009 at 00:01

Here is a brand new JeeNode USB v2, this is the successor of the JeeLink v1:

This is the first (hand-soldered) unit, I had to stack a resonator on its side to fit it in – properly-sized resonators should be coming in soon. The final version will have the usual bright yellow antenna wire – I merely used black to remind me that this is a prototype. You don’t want to know how many different versions of various units are scattered all over the Jee Labs…

The JeeNode USB is a JeeNode with built-in FTDI interface and mini-USB jack. It uses surface mounted parts and has exactly the same size as the basic JeeNode. All the headers and connectors are in the same place, so this thing is plug-compatible – apart from the 6-pin FTDI connector vs. the mini-USB jack, of course.

The JeeNode vs. JeeLink naming confusion is a bit unfortunate, but I’m hoping to resolve it now – before the confusion gets even worse. There is no “v1” of the JeeNode USB, btw.

The JeeNode is the unit with ports and headers. There is the basic JeeNode v4 with through-hole parts, and now there is also a JeeNode USB v2, with SMT parts.

The JeeLink v2 is the unit in the shape of a USB stick, using SMT parts. It has no headers, but it has extra flash memory on board. And it comes in a Cool Clear Case.

Both JeeNodes as well as the JeeLink have an RFM12B wireless radio module.

Ok, everything is starting to come together now.

Activity LED

In Hardware on Nov 6, 2009 at 00:01

The new JeeLink v2 has an “activity LED” added, which is not present on the JeeNode.

This is simply a LED from PB1 (Arduino pin 9) to “+” via a current limiting resistor. It’s very easy to add the same activity light to the JeeNode, using a 4-pin connector:

Now place this contraption on the SPI/ISP connector as follows:

Voilà – it even has PWM!

The latest RF12demo code now has a “l” command to test the led – “1l” turns it on, “0l” turns it off again.

Woohoo – this is post #300 !

Meet the Plug Shield

In Hardware on Nov 5, 2009 at 00:01

There are a couple of Arduino’s lying around idly here at the Jee Labs, so I thought it’d be nice to be able to attach some JeePlugs to them. Not all interface tasks require a wireless JeeNode, after all…

The main issue is how to deal with different voltage levels, i.e. 5V logic levels on the Arduino vs 3.3V on all the Jee stuff. Luckily, this is not a problem for an I2C bus, since there are chips which automatically convert between two different I2C bus levels.

So here’s the Plug Shield, carrying an RTC plug:

Check out the gold lettering!

There is room for up to 5 port connectors, all connected in parallel, with right-angle 6-pin female headers (I take straight headers and just bend their pins). This supports two plugs lying flat on the board and three pointing outwards, although many more can be attached through daisy-chaining.

The PWR pin is connected to 5V. The IRQ signal is currently not connected to any pin but could be tied to PD3 to be compatible with JeeNodes.

Note that the Plug Shield will only work with I2C-type JeePlugs – things like the Room Board and the Thermo Plug cannot be used.

There is a regulator to supply 3.3V to the port connectors on-board, as well as an I2C bus level converter. To maximize the space available to plugs, these are all SMD’s. The reset button and ISP header have been brought out as well, since the original ones on the underlying Arduino board cannot be reached.

This shield allows stacking and can be sandwiched between an Arduino and any other shields. The only requirement is that analog pins 4 + 5 must be used for hardware I2C – these are not available as I/O pins.

Here’s a demo, reading out the RTC:

Screen shot 2009-11-03 at 00.32.07.png

Uses the standard “Wire” library that’s included with the Arduino IDE.

There is a wiring mistake in the shield, causing PB1 to be shorted to ground, so as a result digital pin 9 can’t be used with this shield. I placed one of the headers the wrong way around. Doh!

I’ve added this shield in the shop anyway. Got only a handful of ’em for those who don’t care too much about that PB1/D9 issue. New shields will be made soon.

Apart from that, it’s working great. All I2C-based JeePlugs can now be used with standard Arduinos, without plug-stacking conflicts or voltage translation hassles. Want an RTC? LCD? UARTs? More I/O lines? You got it.

Update – The pcb was updated soon after this post, the above mistake only applies to the first few shields.

More efficient computing

In Hardware on Nov 4, 2009 at 00:01

A few days ago, I replaced my (3y old) MacBook Pro + (8y old) Cinema Display with a brand new 27″ iMac. Here’s the result:

Screen shot 2009-10-31 at 17.59.38.png

That’s the total energy consumption of my work desk – i.e. computer, lights, and a some USB-powered stuff. The scale is in Watt-per-5-minutes, so if you multiply all figures by 12 you’ll get the normal Watt ratings.

There are many different operating modes here – night-time near off, full sleep, display sleep, display on, a few computing peaks, and in the evening also the lights on.

On Oct 30 both machines were active, while all the data from the old setup was being migrated to the new one.

The interesting parts are the low periods at night which more or less dropped to zero, even though the iMac is simply sleeping (with BlueTooth and USB still on), not turned off.

It’s also nice to see that even with this new dual-core 3.3 GHz monster, energy consumption is noticeably lower most of the time – not just in idle mode!

These readings were obtained with the ES-1 sensor described a while back + a central JeeNode + JeeMon.

Meet the new JeeLink v2

In Hardware, News on Nov 3, 2009 at 00:01

Just in!

Look at that fancy gold lettering – neat, huh?

And the first hand-soldered unit is working perfectly:

Here’s the new software-controlled LED:

This is in addition to the red TX and green RX LEDs, indicating USB activity.

Only thing not tested yet is the new on-board 1 Mbyte flash memory. Once that’s done, I’ll start assembling a couple of these. Will be a lot easier once the solder paste stencils come in.

JeeNode v4 on a breadboard

In Hardware on Nov 2, 2009 at 00:01

Now that the JeeNode has labels on the back, there’s a convenient way to use it with mini-breadboards:

This uses male-male headers with extra-long pins, so that the JeeNode can still use female headers:

To get more space to work with, use two mini-breadboards:

Plenty of room for lots of experiments, even for a few plugs.

LCD Plug

In AVR, Hardware, Software on Nov 1, 2009 at 00:01

Here’s the new LCD Plug:

It’s a little piggy-back board for standard LCD modules with 16-pin connectors. The middle 4 pins are not connected, so that two 6-pin male headers are in fact enough to hook this board up to the LCD.

Here is a setup using a 2×16 character display:

The interface uses I2C, so this “plug” can be daisy-chained like all the others. The plug uses an I2C expander chip with a fixed I2C address of 0x24. There are two jumpers to select the voltage level for driving the logic supply and the backlight, respectively. The backlight can be turned on and off under software control.

A generalized version of the LiquidCrystal library included with the Ardiuno IDE 0017 is used to redirect the actual interface through a bit-banged I2C bus, using the Ports library. This was described in an earlier post. Details about how this code works are also available, see this post.

The latest Ports library now includes the new code, including the “lcd_demo” example as shown above:

Screen shot 2009-10-31 at 16.06.14.png

The only difference with the LiquidCrystal example is the definition of port 1 as I2C bus, and defining the “lcd” object to connect to the display via this I2C bus.

Room Board update

In Hardware on Oct 31, 2009 at 00:01

Here is the latest version of the Room Board, just in:

It works for all combinations of SHT11/DS18B20, PIR/EPIR, and LDR. Here’s SHT11 + PIR + LDR:

And here’s a setup with DS18B20 + EPIR + LDR:

Both can be used with the latest version of the rooms sketch.

But… if look closely at that second board, you’ll see that I still got it wrong!

The DS18B20 temperature sensor is labeled the wrong way around, and must be mounted as follows:

Drat – same mistake as last time!

And now I’ve also figured out how this happened. Here is the pinout shown on the Dallas Semiconductor / Maxim data sheet:

Screen shot 2009-10-30 at 14.43.29.png

B o t t o m view. Doh!

I’m going to declare victory anyway, and call these boards final. Even though this issue will have to be documented and spelled out everywhere to prevent people from falling into this trap. I have 100 room boards, and I simply don’t want to trash them and wait another 3 weeks. Most people will probably use the SHT11 sensor anyway, where this issue is irrelevant.

Available in the shop now. Foul-ups happen, so be it. End of story.

More room sensors

In Hardware on Oct 30, 2009 at 00:01

I’m getting ready to install a new round of room sensors around the house. Am using the remaining prototype boards, now that the final version is ready:

Some rooms here don’t really need relatively expensive SHT11 sensors and some places don’t need a motion sensor, hence the variation across these 6 new units.

These boards require some patches, as described earlier, for use with the EPIR sensor, i.e. the three leftmost boards shown above.

The patches are easy to apply on the back of these little boards:

That’s a 4.7 kΩ pull-up for the DS18B20 1-wire sensor, and a 100 kΩ pull-up for the EPIR.

Installing these will bring the total to 10 active nodes, but that’s still not the end of the story. Once everything is done, I’ll have 16 JeeNodes with room boards and sensors watching over this house. It’ll be interesting to see how the temperature changes across the different rooms, and what humidity levels are reached in the basement and beneath the house once winter sets in…

New UART plug

In Hardware on Oct 28, 2009 at 00:01

The revised UART plug now works as expected:

This board has been reworked to use a 3.68 MHz resonator. Two solder jumpers allow using several UARTs on a single I2C bus.

Since the UART chips include 2x 64 bytes of buffering for transmit and receive data, and since they can be set to do hardware and software flow-control, this is quite an effective way to offload work from an ATmega328, once you need more than its single on-chip serial port.

See a previous post for sample code.

Documentation can be found at https://jeelabs.org/up1 – the plug code (“up1” – has to be lowercase) at the end of this URL will redirect to the corresponding page in the documentation tree.

The BC1, BP1, EP1, MP1, PB1, and RP1 plugs are now also available. Nothing really exciting to report about them, I’m still waiting for a couple of more interesting ones such as the LCD Plug and the updated Room Board and Thermo Plug.

Four generations

In AVR, Hardware on Oct 26, 2009 at 00:01

After one year, I thought it’d be nice to compare all the JeeNode versions which have come out – up to and including the latest v4:

Here is the back side of each of them:

The back side in particular illustrates the evolution which has taken place this year.

In version 1, there were no labels – mainly because I hadn’t figured out how to do those and I was eager to just see the darn thing work…

Version 2 added some minimal labeling (in copper, to save on production charges!) and a ground plane. Port pairs 1+4 and 2+3 were moved 0.1″ further apart. The mounting holes were dropped.

Version 3 was really the first production-ready one. It added lots of text on the component side, plus a bit of eye candy by going for blue solder masks. I switched to yellow wire for the antenna, to help remind me that this is the version with the final port and pin layout – the one which matches all the new JeePlugs. Version 3 did get the silkscreen for the regulator wrong, but it also made it to the Make Magazine weblog – cool! :)

Version 4 now takes this evolution to its logical conclusion: a clear visual “identity” in the form of blue-and-gold color choices and lots of labels on both sides of the board. No more guessing! The PWR/I2C connector moves a bit and is augmented with two more pins. This JeeNode is the narrowest of all, it now has precisely the same width as all the plugs (21.1mm / 0.83″). This is the grown-up version at last, focusing on actual usage convenience along with a proud & pleasing appearance.

It’s time to move on. The JeeNode is done.

Assembly service

In AVR, Hardware on Oct 24, 2009 at 00:01

It’s time to try something new!

Sometimes, this DIY electronics stuff can be a bit daunting. Maybe you’ve never soldered microprocessor circuits before. Or maybe you’re worried about that RFM12B “SMD” module on the JeeNode. Or maybe you just want to get going fast, and not spend your time on the hardware side of things.

Meet the new Assembly service option:

For a small fee, I’m going to offer to assemble JeeNode kits for you, as well as soldering headers onto any of the plugs available from the shop.

This can help more people get started on this wireless and sensor hookup stuff. And it lowers your risk – you could get two kits, have one of them assembled, and build the other one yourself. Or if you don’t care about soldering at all, just get all the pieces you want to hook up in assembled form.

In fact, I’m going to extend this new service even further: if you get a kit to build yourself and it turns out that you can’t get it to work, then you can send it back and I’ll assemble / finish it for you. I can only do this if all the components are still undamaged, otherwise you’ll need to get a replacement kit. Since I don’t know whether this will work out, nor whether I can handle such a “return/repair” flow of items, I will only commit to do this until the end of November. If it works well enough, I’ll prolong this service.

The reason for doing this is not to add a massive amount of assembly to my workload, but to help people take the plunge with less risk. Especially if you’re new to all this physical computing stuff and electronics, I think you’ll find out that assembling kits can be a lot of fun and very rewarding. But hey, if you’re in doubt, just get a kit and some assembled parts so you don’t have to worry about everything at the same time.

Monitoring failure?

In Hardware, Software on Oct 23, 2009 at 00:01

Yesterday, the Jee Labs energy monitoring system stopped working:

Picture 2.png

A few hours went by before I found out, because I’m not constantly checking these graphs nowadays.

Couldn’t figure out why, so I reset the sending node next to the electricty/gas meters, and shrugged it off as a fluke because it all started working again.

A few hours later, after dinner, we find out that there’s water dripping down right next to that JeeNode, but more importantly the whole meter closet is soaking wet in some places. Whoops… not good!

Turns out that there was a leak in the kitchen drain right above that meter closet. Fortunately, the problem was easy to identify. And didn’t lead to fireworks.

That was around 8 PM. Only this time the JeeNode is also soaking wet – free-hanging constructions are not such a good idea after all, I guess. Unplug. Wipe off the water. Let it dry for a few hours. Plug it back in.

OK, the energy monitoring setup is working again. Tomorrow, I’ll fix the drain pipe – properly.

The drawback of tinkering is that you always blame your own stuff when there is a failure. But in this case, it was trying to tell me about a problem coming from elsewhere…

Solar power

In Hardware on Oct 20, 2009 at 00:01

The Lighty project described earlier on this weblog was an attempt to create a node for outdoor use, which periodically reports some light measurement details and powers itself indefinitely via solar energy.

At the time, I couldn’t figure out how to get the power consumption down far enough, nor how to prevent the LiPo battery from overcharging.

I think I found a solution for both, triggered by a recent article in Elektor:

Picture 2.png

The main idea here, is to simply short out the solar panel when the LiPo voltage reaches 4.15 V, using a MOSFET. The battery voltage has to be measured using a voltage-divider which doesn’t constantly drain the battery – this can be solved with a low-power op-amp in voltage follower mode, using a 2:1 voltage divider. The LT1494 op-amp will work with varying supply voltages and consumes only about 1 µA.

I think I’ve got the resistors attached wrong though – need to brush up on my op-amp knowledge…

When using the ATMega’s A4 (PC4) and A5 (PC5) pins, everything can be hooked up using just the PWR/I2C connector. If this works as intended, it’ll make a nice and simple solar power setup for any JeeNode.

Anyway, I’ve ordered a MOSFET and an op-amp to see whether this idea can be made to work.

Update – looks like the op-amp can be avoided, the ATmega328p datasheet says the ADC input impedance is 100 MΩ, so two 1 MΩ resistors should work fine as voltage divider, with less than 2 µA power consumption.

JeeLink, JeeNode, JeePlug

Documentation conventions

In Hardware on Oct 19, 2009 at 00:01

With so many plugs and boards (f)lying around here these days, I’m trying to stick to a couple of tagging and documentation conventions.

First and most important one, is that each package has a unique ID which refers to a web page:

Even each board has such an ID:

(this plug is now called an “RTC Plug”, btw)

When you type in the URL, you’ll be redirected to its main documentation page – for example:

Picture 3.png

Did I mention that everything on this site is open source, software and hardware? Well, as you can see above, all the design files are freely available. Enjoy… just don’t do anything with ’em your mother wouldn’t approve of.

The other way to get to these documentation pages is via the “DOCS” link at the top of all the weblog pages. It points to an index of all available documentation pages.

As you can see, all product IDs are two letters plus a version number from 1 to 9. URLs of the form http://JeeLabs.org/ + lowercase-letter + lowercase-letter + digit always redirect to the latest documentation page, regardless of the structure of this site.

I’ll let you know when I run out of all the 6084 codes :)

Of JeeNodes and JeeLinks

In Hardware on Oct 18, 2009 at 00:01

There’s a new JeeLink coming…

No external connections, just a little antenna wire sticking out. Uses a 10 ppm crystal to accurately keep track of time and has 1 Mbyte of flash memory on-board so it can collect data in unattended mode. This new JeeLink’s only purpose is to attach to a computer for communicating with JeeNodes and several commercially available RF controlled devices (KAKU, FS20, etc). It has three LEDs: RX, TX, and ACTIVITY.

The above will be called the JeeLink (v2) – I’ve just sent off my second prototype to the pcb shop. Quite a few tweaks and tricks were needed to fit everything into such a tight enclosure:

Picture 1.png

The current JeeLink (v1) is also going to change. First of all, it’s going to be called the JeeNode USB (v2) in the next revision since it really is a JeeNode, but with the FTDI-USB adapter added-on. Other changes will be mostly to make the standard JeeNode and this new JeeNode USB even more compatible with each other.

JeePlug, Sensors, Reflow

Thermo Plug update

In Hardware on Oct 17, 2009 at 00:01

The Thermo Plug works, basically. Here’s the configuration with an NTC sensor and a buzzer:

Sample output, reading out the ADC periodically:

Picture 8.png

As the temperature goes up, the resistance and the ADC readings both go down. The actual conversion to the corresponding temperature will require a calibration and either a lookup table or a polynomial fit, as described in a previous post.

Here is the board layout:

Picture 8.png

The buzzer can be replaced by a relay plus clamping diode. Since it’s driven via an NPN transistor, there will be enough current to drive several types of relays. The buzzer / relay are hooked up to PWR, not +3V.

Another configuration for this board is with the AD597 thermocouple sensor chip. Unfortunately, I forgot to add a wire between pins 1 and 3, so it has to be added by hand – as you can see here:

Another view, with the attached K-type thermocouple:

The thermocouple responds to temperature change much faster than an NTC – and it’s already calibrated (second number is °C):

Picture 9.png

When I touched the sensor with my hands, it took less than half a second to detect a 5° increase!

Here is the sketch I used for the above demo:

Picture 10.png

Ok, time to tweak the Thermo Plug and fix that missing wire in the next pcb run.

JeePlug, Displays

New LCD Plug

In Hardware on Oct 16, 2009 at 00:01

There’s a new LCD Plug on its way – hopefully this one has the correct pinout.

Here’s the schematic:

Picture 7.png

This board is based on the same MCP23008 chip as the Expander Plug. Six outputs are used to drive the LCD panel (in 4-bit mode), one output controls power to the backlight, and one spare I/O line is available for a button or a LED – this is brought out to a 2-pin connector.

A breadboard version of a similar setup was described in an earlier post. The software to drive this plug has also been presented before.

The layout of the LCD Plug is as follows:

Picture 3.png

It departs slightly from the normal plug layout, because this board is intended to mount on the back of the LCD panel. There are two solder jumpers to select between PWR and +3V for both logic and backlight. R3 is a current limiting resistor for the backlight, it can be bypassed with a third solder jumper if not needed.

Now I get to play the waiting game again, to see if it comes out ok…

A JeeSupply?

In Hardware on Oct 15, 2009 at 00:01

For some time now, I’ve been thinking about creating better tools for my own use here at Jee Labs. One of them would be a simple power supply with adjustable voltage and current limits. Nothing fancy, even 1 Amp is really overkill. But with a finely adjustable current limit and a continuous readout of the actual voltage and the current draw would be really nice.

Yes, there are lots of laboratory supplies. Cheap ones even, with such capabilities. I’ve got one. But they don’t measure or limit well in the milliamps range I’m interested in. And they are all so… b u l k y !

So the idea of a “JeeSupply” was born: a little unit which runs off any simple power brick, and which uses a JeeNode to perform all the control tasks. Why a JeeNode? Well, because then I could display the readout on the PC/Mac screen, and do it wirelessly without cluttering up my desk. And set it wirelessly as well, of course. It wouldn’t take much to turn it into a stress testing rig, gradually raising the voltage and plotting the current draw over time, or lowering to see when the circuit fails. Auto power-off. Watt-metering. Motor/servo test rig. Lots of extensions come to mind once it’s under computer control.

As I said, I don’t really need much power. Even just going up to 12 V @ 500 mA would be quite useful. Especially if the whole unit is so small that you can place it on the table next to the circuit it’s feeding.

Here’s a first design for it:

Picture 1.png

Click here for a larger PDF.

It has two switching power supplies. One produces 5V and powers the JeeNode and some of the other chips, the other is based on a L6902D and generates the requested voltage. This particular switching regulator has built-in current limiting. Normally, this would be done via a fixed current sense resistor, but in this case there’s a “high-side current sensor” chip involved which converts the current to a 0-based voltage level – this level is read out by the JeeNode, and also attenuated by a digital potentiometer to adjust the actual current limit. A second digital potentiometer is used to adjust the output voltage. This is all done via an I2C bus.

The digital pots have 257 steps, which is a bit limited at the end of the V and I ranges. For this reason, I added a second pair of pots in parallel to be able to tweak the values a bit more. My hunch is that the non-linearity of this setup may work out nicely, but I haven’t thought it through yet – these extra digital pots are entirely optional anyway.

The JP1 .. JP4 connectors on the left are connected to the port headers on a JeeNode. All pins have been assigned to some function, just to see how far one could take this.

There are two more connectors: one brings out the I2C bus to drive an LCD display, the other allows connecting some LEDs, buttons, and a rotary encoder to adjust settings directly. Both are optional – with remote control, this JeeSupply would need no other connections than a power jack and the two output power lines. It could all be built very compactly – not much larger than the JeeNode itself:

Picture 5.png

The above circuit can deliver up to 25 V or so, and can probably handle 1 amp. But I really don’t care – any 8 .. 30 V power brick will drive it. I just want it to work well in the 2 .. 5 V range with a few hundred milliamps of current at most. And because both supplies are efficient switching types, there will be little heat involved.

I haven’t built this circuit, I haven’t even tried it on a breadboard. But I sure could use a pair of these in my daily lab work. Something like this would definitely help detect and debug short circuits and other common electrical wiring mistakes in all those little projects sprawling around here. It might even save a chip from frying, occasionally.

What do you think?

Room Board update

In Hardware on Oct 14, 2009 at 00:01

I finally figured out what was going on with the new Room Board.

The bad news: there are three errors on the board when using it with a 1-wire temp sensor and the EPIR motion detector board.

The good news: each problem is easy to work around.

Problem #1: the 1-wire DS18B20 outline is reversed:

So much for taking an EAGLE library component from the web and not checking it…

Problem #2: the 1-wire sensor really needs a 4.7 kΩ resistor pull-up:

The solution for both problems is to solder the sensor on the other way, and to add a resistor between two of the pins, as shown above.

Problem #3: a pull-up resistor is missing (again!) – it turns out to be essential to get the EPIR in the proper serial mode on power-up:

This can’t be done by enabling a pull-up in the ATmega as I originally thought, because that’s too late. The EPIR really checks for this on power-up. The solution is (again!) to manually add a 100 kΩ resistor between pins 2 and 4 of the EPIR connector.

Phew. So now all configurations work. Sort of… :)

I’ve added the Room Board to the shop, but as PCB only because there are several configurations possible and because some of these sensors and boards are relatively expensive (also for me to keep in stock).

With the caveat that I only have a handful available right now, and that these are “imperfect” prototype boards. With SHT11/SHT15 sensors and simple 3-pin PIRs, these prototypes will work fine. But for 1-wire and/or EPIR use, you’ll need to patch things as described above.

I’m going to create a new revision with all these issues fixed, of course. But it will take a few weeks to have new boards made.

The “Rooms” sketch for these boards has been updated to work with all configurations. It needs the NewSoftSerial library if the EPIR is used, and the OneWire library if the DS18B20 is used.

JeeLink v1 bug!

In Hardware on Oct 13, 2009 at 00:01

The JeeLink v1 board had two problems I knew about and which I’ve been able to work around. A few days ago a third more serious problem was brought to my attention – the C4 10 µF capacitor which was supposed to filter out ripple for the on-board MCP1703 regulator turns out not to be connected to ground. Whoops!

The GND pin on the PWR/I2C connector is also not properly connected due to this same problem, but this is probably of slightly less importance.

Here are the two affected connections on the JeeLink v1:

jl1 build.FlySketchExport.png

The solution is to connect either of these to another ground pin on the board. But since this problem was only just found, all JeeLinks sent out before October 9th will have this problem still in them.

I’ve documented all known problems on the JL1 Build page, along with suggestions on how to fix them – so if you have a JeeLink and it’s not working as expected, please check out that page.

After this bad news, and at the risk of having everybody who planned to get a JeeLink hold off and wait – there is also some good news to report: a successor for the current JeeLink v1 is currently “in the works”. So all the teething troubles of the JeeLink v1 will one day be over – unless I mess up again, of course :)

An OOK relay

In AVR, Hardware on Oct 12, 2009 at 00:01

After having hooked up OOK radios in a few ways, I’ve decided to create an “OOK relay” – a little unit which listens for OOK-encoded data on the 433 and 868 MHz bands, and then re-transmits the decoded data as “normal” packets via the RF12 driver. OOK stands for “On-Off Keying” as opposed to the more advanced FSK – “Frequency Shift Keying” used by the RFM12B’s – i.e. AM vs. FM.

The benefit of an OOK relay is that OOK reception then automatically gets integrated into all the data collection from other JeeNodes that’s already going on anyway. Since an RFM12B can send both 433 and 868 MHz OOK signals, the end result is a pretty complete solution for all sorts of things going on over the air.

Here’s the hardware test setup:

The 433 MHz receiver is seen from the side, standing almost straight up with the white antenna wire. It’s connected to DIO of port 1. The 868 MHz receiver is lying flat, with the red antenna wire, and is connected to AIO of port 1. Both receivers are powered from the 3.3V supply.

The reason for this particular setup is that I can use two different pin change interrupts for both: PCINT1_vec for 868 MHz and PCINT2_vec for 433 MHz. No need to decide inside the interrupt routine which is which – this saves some interrupt routine overhead.

The code was created from the two existing decoders for these receivers, and will be made available once everything is finished. Right now, the decoders work happily alongside each other:

Picture 3.png

Sample output:

Picture 2.png

I cheated a bit though by selectively powering the receivers, because there is a hardware problem… it looks like these receivers are interfering with each other. They only work when the other one is off. It’s not that surprising, given that one frequency is almost an exact harmonic of the other. Maybe placing the two receivers physically further apart, or adding better RF power supply decoupling will fix it. They should be able to work together, even receive signals on the two frequency bands at the same time.

More work left to do…

Experimentation setup

In AVR, Hardware on Oct 11, 2009 at 00:01

After coming up with the JeeBoard, which needs a PCB with at least an I/O expander and two LEDs/switches, I decided to go one step simpler and just wire up a version with no active components at all:

It connects the same 3.6 .. 4.5 V battery pack through a slide switch, and ties a breadboard to the AIO + DIO pins of ports 1 .. 3, along with +3V and GND. With a few headers placed flat on the board for various plugs.

Wiring this up is simple – note the added rubber feet:

Now it’s ready to go, with 3 rechargable NiMH’s:

And here’s the final setup:

Just to show how you can go nuts with plugs:

The battery pack connection is removable to give me a nice spot to insert a current-measuring multimeter.

First demo of this board coming up tomorrow…

Room sensor board

In Hardware on Oct 10, 2009 at 00:01

At last, the latest Room Board design is starting to work:

I’m no longer calling this a plug – that’s now reserved for things which you stick into a single port. One of my “tics” is that I like to play games with abbreviations – in this case: trying to abbreviate all product names to two unique letters plus a version number. By not calling everything a plug, I get more letter combinations to play with – so this thing is the “RB1” :)

The version you see above is my preferred configuration, but it requires sensors which are a bit expensive (SHT11) and Europe-based (ELV’s PIR kit). So there is room on the board for some alternatives: the SHT11 can be replaced by a DS18B20 1-wire temperature sensor if you don’t need humidity measurements. And the ELV PIR kit can be replaced by any other PIR sensor which runs off whatever voltage you’re feeding to the PWR pins – many PIR sensors can run with 5V and have an open-collector output, though their three pins may be oriented differently. Parallax and Futurlec come to mind.

The PIR can also be replaced by an EPIR (DigiKey part# 269-4710-ND, non-RoHS). It’s low cost but it draws about 5 mA due to its on-board (“sub-embedded”?) microcontroller. The Room Board will work with the EPIR plugged into the 8-pin “PIR2” connector on the other side of the board, but you have to also move the LDR to the pins marked LDR2. The reason for this is that that the EPIR uses a bi-directional serial connection and therefore needs two signal pins. Luckily, it has the smarts to also handle an attached LDR – so the result is the same.

Here’s the Room Board with an EPIR and a DS18B20 1-wire temperature sensor:

Haven’t tested this configuration yet, but every combination of PIR-or-EPIR plus SHT11-or-DS18B20 will be supported. Once the Room Board has been fully tested, it will be listed in the shop.

The Room Board can be plugged into any two opposite ports, but the software expects one of two specific board orientations on port 1 and 4: the PIR and EPIR must be located in the middle, i.e. roughly in between all port headers. It’s easy to change the code if you need other configurations.

Speaking of code, the source code for this setup is available here, as the “Rooms” sketch. It reads out the sensors and periodically sends out the readings over wireless.

Latest news: all the plugs and boards described yesterday have now been added to the shop, as either pre-assembled or pcb-only units.There are only half a dozen boards right now, so please be patient until new ones come in. Please get in touch if you have questions or run into anything unexpected with these plugs. I’m gradually filling in all the associated documentation pages, but some of them are bound to remain skimpy for a while.

Tiny as these plugs are, they sure keep me busy!

Expander Plug, revisited

In AVR, Hardware on Oct 9, 2009 at 00:01

Got some revised plugs. The Expander Plug now works:

Here’s a sketch which blinks all pins on the expander:

Picture 3.png

I forgot to check the A0 solder jumper orientation, so I accidentally wired my first plug up for address 0x21 instead of 0x20. Each Expander Plug can be configured for I2C addresses 0x20..0x23, i.e. up to 4 expander plugs can be daisy-chained on each port.

Expander plugs work nicely with the Breadboard Connector, to hook up a mini-breadboard like this:

The width of a mini-breadboard is slightly less than an Expander Plug + sideways headers, so daisy-chained plugs can each have their own breadboard.

In summary: the Blink, Expander, Memory, RTC, and UART Plugs all work. So do the unpopulated Proto Board and Breadboard Connector, of course.

More news about prices and availability in the shop tomorrow… once I finish my homework and figure out a few remaining pesky little details and logistics issues.

Light to RF converter

In Hardware on Oct 8, 2009 at 00:01

While testing out some new code to handle extended FS20 packets in the forum, I remembered that I had an FS20 LS sensor still lying around:

Puzzled? Maybe the back will show a bit better what this thing is about:

Still puzzled? Me too – until I assembled the kit and tried it out. There is a light sensor on the back with a bit of sticky tape, which you’re supposed to place over a LED or some other light signal.

What it does is whenever light on or off is detected, it sends out an RF signal at 868 MHz using the FS20 protocol. So any FS20 receiver can pick it up:

The four buttons are a way to adjust all sorts of settings. I haven’t tried those, the factory defaults seem to work just fine for me. As it is this is a nice install-and-forget unit. Hopefully the battery will last a year or more.

Could this report the fridge light? Hmm, not sure – not all packets are coming out. Maybe it’ll be ok if the receiver is close enough.

Cool – another wireless gadget to help automate stuff around the house!

Prototyping board

In Hardware on Oct 7, 2009 at 00:01

Plugs are not required to hook up to a JeeNode, of course. They just act as pre-wired components which can be combined and re-used at will.

Here’s a more Ardino’ish shield-like approach, the Proto Board:

It doesn’t have any wiring, just plated-through holes to allow components and connectors to be soldered to either side. The rectangle on the left matches the SPI/ISP header below, while the rectangle on the right matches… an upcoming modification of the PWR/I2C connector.

The board is slightly asymmetric, i.e. larger by 0.1″ on one side than the other. Note that due to the way port headers are aligned, plugging this board the wrong way around has no effect other than re-arranging port numbers. No risk of shorts or wrong voltages on any of the pins.

Here’s another way to plug two of these boards in, if the port numbers printed on the board are ignored:

That’s about as much real-estate we can get from generic plugs. For larger projects I use standard perf board with copper islands and push the JeeNode upside down onto it i.s.o. the other way around.

Optimizing SMD

In Hardware on Oct 6, 2009 at 00:01

I’m trying to simplify some plugs a bit. The UART plug has a 3.6864 MHz crystal and two 18 pF caps:

(yeah, it’s an awkward fit)

Turns out that it works just as well with the 16 MHz + 10 pF combo I’m using in another project – using adjusted baudrate dividers, of course:

(somewhat better fit)

But hey, why stop there. A resonator with built-in caps would get rid of two more components – and it’s more than precise enough to generate accurate baudrates:

(awkward fit again, but who cares since it’s a test)

Cool: the 3.68 MHz resonator works – a 40% reduction in component count! Now I can make a new “release”.

I’m still readjusting my neurons to this hardware world. It sure is different from software – even though bits & bytes could be considered to be infinitely small, this hardware stuff somehow feels tangibly smaller…

Clock fixed

In Hardware on Oct 5, 2009 at 00:01

Ok, after switching to a DS1340Z chip, the RTC Clock Plug now works:

Sample output:

Picture 2.png

I first ran a sketch to set the time, then commented out the setting part and uploaded it again. As you can see, the time kept ticking – just as in real life…

And it keeps going on its internal battery while power is disconnected:

Picture 3.png

That’s the whole point of this plug!

The battery holder is not perfect. The type I got is for surface mounting, but the board is for a narrower through-hole type. Had to snip the sides of this one off a bit, and it didn’t solder on quite as intended:

But it works. The spring action is very strong and pushes the battery to the board anyway.

The code for this RTC Plug has been added to the Ports library as “rtc_demo” example, and is available here.

More serial ports

In AVR, Hardware on Oct 4, 2009 at 00:01

Here’s an easy way to add more serial ports via I2C:

I got the wrong crystal size, so it’s mounted a bit awkwardly:

There are two jumpers, allowing up to 4 serial ports to be added to each I2C bus – i.e. up to 16 on the bit-banged I2C buses, and 4 more on the hardware I2C line. Since the A0/A1 jumpers actually support up to 16 addresses with a bit of extra wiring, you could theoretically connect up to 80 serial ports to a single JeeNode!

Here’s some sample code:

Picture 5.png

It sets the serial port to 57600, 8 bits, no parity and then sends whatever comes in to the “normal” serial port. The default fast I2C bus rate of over 1 Mhz appears to work just fine.

The header of the UART plug is compatible with FTDI, so you can hook up another JeeNode to it:

In this case, I used a JeeNode with a room plug prototype. Sample output:

Picture 3.png

This demo code has been added as “uart_demo” example in the Ports library and is also available here.

JeeLink assembly line

In Hardware on Oct 3, 2009 at 00:01

Here’s a peek into the Jee Labs kitchen:

This is my – tada! – JeeLink assembly line. A factory in-a-box, so to speak.

I keep this box stored away for when I need to make a new batch of JeeLink v1’s. Usually I assemble 1, 2, or 3 panels at a time – depending on how many parts I have available at that moment. Each panel has 4 JeeLinks.

From top left to bottom right, sort of:

Small containers with the parts required for the board. Many of the parts are so tiny that you could actually put thousands of them in these little boxes. Some parts, such as the USB plug and the ATmega chips are a bit larger.
The syringe with lead-free solder paste, as well as a few plastic syringe tips. Got this from Farnell – nowadays I use the stencil so these are no longer used really. The solder paste is in a jar, stored in our fridge in the garage.
Cotton dabs – used with a bit of alcohol to clean off the boards after use. Not needed for the solder paste, but if I have to wick off some excess solder, the wick leaves a very ugly residue. Alcohol stored elsewhere, I don’t want the bottle to leak in here!
The stencil and the little adapter I made to hold a panel of 4 JeeLinks.
Toothbrush, goes along with the cotton dabs to clean up.
On the right is the – ahem – “squeegee” I use to apply solder paste. At first I thought it’d be completely unsuited for this task, but it actually works surprisingly well.

The most important items are actually not in this box, because I use them for everything on a daily basis – an illuminated magnifying glass, very thin tweezers, a “third hand”, and a 15W (yes, 15!) soldering iron:

Take away any of these and there would be no Jee Labs.

So if you ever get pre-assembled units from the shop with smd parts soldered onto them, you can now picture yours truly with something like this sitting next to me…

Voltage Plug

In AVR, Hardware on Oct 2, 2009 at 00:01

The Voltage Plug generates up to four 0 .. 3.3V levels using MCP4725 12-bit DAC’s controlled from I2C:

This sketch switches between 0 and 4095, displaying as 1.2 mV and 3.295 V on my multimeter, respectively:

Picture 1.png

The cycle time was set to 5 seconds to give my auto-ranging multimeter time to adjust itself.

There is room for 4 DAC chips, which seems like a bit of overkill, but I couldn’t think of anything else to put there and the board looked so empty :) – perhaps some sort of voltage-follower op-amp or amplifier stage would make more sense? Anyway, I’ll probably remove two of those chips from the plug again.

The MCP4725 only has one pin to specify the lower address bit. There are in fact 4 different chips available from the manufacturer, to support up to 8 DAC’s on a single I2C bus. Since I got the “A3” version – and since I mixed up high and low again – this particular test uses address 0x67. For the final version I’ll fix the low-address bit and use “A0” versions, i.e. 0x60 and 0x61.

JeePlug, Displays

No LCD Plug yet

In Hardware on Oct 1, 2009 at 00:01

As mentioned before, the LCD Plug will need to be redone. The MCP23008 chip pinout was completely wrong…

But hey, it does look nice, doesn’t it?

Here’s how it’s supposed to go on the back of any LCD with a standard 16-pin header:

The board can be mounted very close to the LCD because it uses SMD parts:

Alternately, it could be flipped over and mounted alongside the LCD.

Note how the solder pad configuration is on the other side, so it can be adjusted once mounted. Not included in this first prototype is a small trim pot to adjust the contrast level.

So the real LCD Plug will take a bit longer – hopefully the next board will be without these crazy mistakes…

Analog Plug

In AVR, Hardware, Software on Sep 30, 2009 at 00:01

The second plug panel has arrived. I’ll document my test results in the coming days.

First, the Analog Plug – an 8-channel 12-bit ADC connected via I2C:

It’s based on the ADS7828 chip. Here’s a demo sketch to read it out:

Picture 3.png

I hooked it up using various gimmicks lying around here – this ties a trim pot to channel 4, with range 0 .. 3.3V on the wiper:

As you can see, the Breadboard Connector can be used to hook up to 8 of the 12 pins of this plug.

Here’s some sample output:

Picture 1.png

I slowly turned the wiper as you can see. It stops at 4095 counts, which represents the 2.5V of its internal reference. Appears to work fine in this test setup at the maximum I2C rate, somewhere over 1 MHz. The readings didn’t change by more than one count when touching various parts of the circuit, so as first impression it looks like it’s pretty stable.

This plug has two solder jumpers, to configure its I2C address to 0x48 .. 0x4B, which in hindsight is a bit overkill. Only minor nit is that I mis-labeled the A0 jumper – as shown in the picture, the address ends up being 0x49 i.s.o. 0x48. Oh well, a small silkscreen fix will resolve that later.

So there you have it – eight 3.5 digit voltmeters on one tiny blue-and-gold plug :)

Displays

Another display option

In Hardware on Sep 29, 2009 at 00:01

Here’s another display option, using a 16×32 LED panel by Futurlec:

The pattern was hand-coded, to help me figure out which pin is which. The board has 3 16-bit shift registers and corresponding LED drivers. This display can be much brighter than in this picture, I’m using PWM to dim it way down and reduce average current consumption (I think it was 40 mA i.s.o. over 250 mA).

The board is powered from 5V and requires 6 output pins – I’m just using the DIO + AIO pins from three different ports for this test.

Note the 470 µF cap hooked up to the power lines of port 4 to help avoid glitches – switching 32 LEDs on and off at 1 KHz can generate a lot of noise!

Sample code for this display can be found here.

It’d be fun to have this display in a nice enclosure and drive it from packets received over wireless from another JeeNode!

JeeNode, JeePlug, Displays

Mounting options

In Hardware on Sep 27, 2009 at 00:01

I’ve been getting some questions about mounting options for the JeeNode lately. And once some plugs are out, that same issue is going to come up for these too, no doubt.

There are no mounting holes in the JeeNode. The reason for this is that it would increase the size by quite a bit (one hole isn’t enough, even two is debatable), which in turn could actually reduce the options for using a JeeNode since it would be larger than the current design.

The basic solution for this for me, is to treat the JeeNode as a module that plugs onto something else – be it a generic board such as the Jeeboard idea I described a while back, or a custom board created for a specific application.

Here is an example of a JeeNode with an LCD display:

Picture 2.png

Note that the JeeNode is mounted upside down, with the components facing downwards.

But where do you go from there? One approach would be to place a transparent acrylic plastic panel over this entire thing, with some stand-off’s to create a sandwich consisting of base panel, JeeNode and other components, and the acrylic panel on top. That’s the geeky way to do it: make the electronics visible!

I’m not sure I’d always want that. I also like things which are “closed”, with only control/display functions visible, and the whole thing having a nice and calm front plate.

This would be an intermediate solution – a clean front panel hiding all the techy stuff underneath it:

Picture 3.png

Still open on the side, where the connectors, power jacks, and even simple controls switches could be located.

The reason why all this awkward compromising is needed of course, is that with only single units (or say a few dozen kits), there is simply no way to get custom enclosures made that are affordable and also really look sweet – a JeeNode is not an iPhone!

Here are a few other options I’ve been pondering about:

Cardboard – design a fold-up box and print it out as template for a DIY cardboard enclosure. Would be very low-cost, but not very sturdy. And it looks a bit cheap…
Wood – this is the classical enclosure: a lot of work, but you can make it look any way you like, if you’re willing to go through all that. Takes a lot of craftsmanship.
Sandwiched foam – of the kind used as poster board for photographs. Again, a DIY design which you’d have to cut out and assemble yourself. Probably not easy to get real clean edges, cutouts, and holes. Not truly sturdy.
Acrylic front – as described above: a base pcb with everything mounted on it and the acrylic as cover on top. The you-can-see-what’s-inside option. Not easy to do yourself without a laser cutter or CNC router.
Aluminum front – this is a variation of the acrylic front. End result is no longer transparent, but creating a clean panel with labels is not trivial.
Prefab box – this is what many hobbyists do: get a plastic box, and drill holes and cut-outs in it, possibly also with an aluminum faceplate. Again, hard to get a nice clean result without a CNC router. But to be honest, I don’t think these (mostly black) boxes look that spiffy…

I really would love to find a nice generic solution for this. Right now, since pcbs are already being made completely to specification, and because they end up looking quite nice, I’m inclined to look for solutions with either the front, the back, or perhaps even both made of pcb material. With SMT components, most if not all through-holes can be avoided, leaving the back side available for all sorts of visible cutouts and labeling.

So what’s the solution? Just let everyone figure this out for themselves? Start saving for a laser cutter or a CNC router to be able to provide simple but accurately machined parts? To be honest, I wouldn’t mind doing the CNC thing – but until it becomes clear what a desirable result should look like, there’s little point picking any tool!

And then there’s plugs and daisy-chained plugs…

If you’ve got further suggestions or ideas on how to come up with kits that not only work well but also make the end result look really nice, please let me know!

Parts!

In Hardware on Sep 25, 2009 at 00:01

The flip side of experimenting with electronic stuff, is that you end up with a lot of little things!

To avoid losing my sanity, I’m now trying to get organized. The above has about 50 bags with one or a few tiny parts in them, mostly stuff from DigiKey and Farnell. SMD, through-hole parts, sensors, little batteries, buzzers, you name it…

And that’s just a fraction of the mess I’m creating around here :)

Anyway, I’ve been spending my time to try and get to grips with this. Bags of similar sizes in one box. A sheet printed out with unique label numbers, and then the work starts: put label on bag, place in box, and add a line to a little database with Location, Label, Description, and Notes. Then it won’t matter where the stuff is, since it’ll be tagged with a note in the database. I use DEVONthink for this, its storage and search capabilities are just right for me.

The trick of course, is to use tags. I’m going to start using the different vendor options to add my own tags during the on-line ordering process. Doesn’t matter one bit what the tag is, as long as it’s unique. I’m using tags like F0001/F0002/… for Farnell items, D0001/D0002/… for DigiKey, etc. By printing a batch of them on a sheet, it’s trivial to keep all tags unique. I don’t have small labels, so I print on larger ones and then slice up the sheet to create lil’ ones:

The texts are created in Tcl/Tk by placing a bunch of them on a canvas the size of an A4 sheet along with thin cutting lines, and then saving the result as postscript. So now I can run “numprint X2500” to get a printable sheet of labels X2500 .. X2639 in exactly the right spot. Very configurable, very automated.

So trivial. So overdue…

JeePlug, Displays

LCD Plug prototype

In Hardware on Sep 24, 2009 at 00:01

For one of the numerous projects here at Jee Labs, I’m going to need a little 2×16 LCD panel hooked up to a JeeNode. Time to get the breadboards and jumpers out:

On the left is a breadboard-friendly 5V power supply.

The chip is an MCP23017, which is a 16-bit GPIO expander for the I2C bus. For the LCD, I only need 8 pins but this particular project needs a few more, hence the MCP23017 i.s.o. of the MCP23008. What’s the project? Well, for now let me just say that it’s about Volts and Amps (no, not because it’s an electrical circuit).

Here’s the MCP23008, as originally planned for use with LCD panels:

Picture 2.png

The chip is running at 3.3V, matching the I2C bus, but the LCD is powered at 5V. This should not be a problem since all connections on the LCD are inputs, and a 3.3V “high” level ought to be sufficient as 5V “high” level as well. The PNP transistor for backlight control will need a second resistor between B and E, though.

Next step is to come up with code for this I2C setup!

JeeNode, Displays

Bi-color LED

In Hardware on Sep 23, 2009 at 00:01

In trying to save precious I/O lines, I wanted to use one line for three states:

Picture 2.png

Red (logic 1), green (logic 0), and off (tri-state).

The way this SMD bi-color LED is connected is:

Picture 3.png

The idea being that together, the forward voltages of these LEDs is more than 3.3V, so they can’t both light up. Both are rated at 2.0 V typical (2.4 V max) forward voltage.

And in fact it almost works as expected. The only problem is that when the I/O pin is left floating, the red LED still lights up dimly – it’s hard to see in the photo, but it really does.

These LEDs are rated at 80 mA peak and 30 mA continuous, btw – so I figured I wouldn’t need a resistor, at least for the test. For a more permanent setup, a 100 Ω resistor between this circuit and the I/O pin would probably be better.

I wonder if there is a simple way to turn the red LED completely off – a 1N4148 diode between 3.3V and the red LED perhaps? That might also dim it a bit, since it’s brighter than the green one.

Geek news: this is post # 2^8 :)

Update – the extra diode helps. Here’s a better test, showing red, orange, green and off:

Picture 2.png

The “orange” isn’t truly convincing with the clear LED I’m using, but its reflection on a piece of white paper looks ok.

Four states on a single I/O pin!

Solder paste on gold-plated boards

In Hardware on Sep 22, 2009 at 00:01

Did I mention that blue + gold is the new chique around here?

All JeeLabs boards will use a blue solder mask and gold plating from now on, which is very nice for soldering. And because I think it looks nice :)

You may have seen this already, because all recent JeePlug proto boards use that design.

To make sure that solder paste would work properly, I did a little reflow test. First a hefty dab of solder paste of varying thickness, and three 0603 resistors:

Can you spot that third resistor? Hint: it’s parallel to the lettering.

Then into the reflow grill, taken up to 250°C as required for lead-free solder:

Notice how each of the resistors aligned itself nicely, due to the capillary pull of liquid solder. And how all the solder paste ended up on the gold contacts – that’s what solder masks do: repel solder!

Here’s the other side after reflow:

Not that this matters much, since solder paste is normally only applied to pads on the top side…

More re-design needed

In Hardware on Sep 21, 2009 at 00:01

This is embarrassing…

It looks like some trivial plugs in Plug Panel 1 do work, but everything of even the slightest complexity (and usefulness) is faulty :(

The Expander Plug has a completely incorrect pin allocation for the MCP23008 18-SOIC chip. Which I had to create from scratch in EAGLE, and obviously I’m still learning just how to do that. Lesson one: don’t move pins in a package around without checking their pin numbers afterwards!

Unfortunately, that means the LCD Plug I sent off a few days ago will also come back useless :(

The Thermo Plug can’t turn off its buzzer because a trace is shorted out to a pad (I guess I didn’t do a DRC), and the thermocouple interface isn’t working because the AD597 chip needs at least 5V as power supply. So much for sensing or controlling anything. Oh well, I suppose the NTC and 1-wire inputs work.

The Room Plug didn’t work with a 1-wire DS18B20 sensor, in fact it looks as if the 1-wire sensor is hooked up the wrong way around since it’s shorting out the 3.3V supply. And the EPIR sensor isn’t responding either. I haven’t tried other configurations yet.

The Clock Plug mistake was described yesterday. It’ll probably work with a DS1340 chip i.s.o. a DS1307.

The I2C Connector … well, ehm, I mixed up the AIO and DIO pins. Incredible stupidity.

Oh, yes, there is some good news – the Breadboard Connector “works”:

But then again, it’s a bit hard to mess up a tiny pcb with no electrical components on it :)

Drat. Back to the drawing board. I may need several iterations to get my act together. This will add weeks to the process. Of course it’s a learning experience, such as: lesson 2 – check and double-check, and lesson 3 – check everything again. E v e r y t h i n g !

Man, do I feel JeeSilly right now…

Clock Plug v1

In AVR, Hardware on Sep 20, 2009 at 00:01

The Clock Plug adds a real-time clock to a JeeNode:

A demo for setting it and reading it out follows:

Picture 2.png

Unfortunately, there seems to be a problem with it – it does not start up reliably, and connecting the backup battery makes it stop?

Oh, wait – the DS1307 is specified for a 4.5 .. 5.5V power supply, and I’m driving it from the 3.3V line! And yes, sure enough, it works fine when powered from 5V.

Whoops!

Time to look for another chip. Ah, looks like there is a pin-compatible one which does work at 3.3V – here’s a post from someone who fell into the same trap.

Update – the DS1340Z works fine, see this followup post.

Memory Plug v1

In AVR, Hardware on Sep 19, 2009 at 00:01

The Memory Plug adds flash memory to a JeeNode:

This particular one has 2 different brands of 512 Kbit chips on it: a AT24C512B by Atmel and a M24512 by STMicroelectronics, for a total of 128 Kbyte. By fully populating it with 1 Mbit chips, this plug can contain a whopping half megabyte of memory :)

Here’s small sketch to test reading and writing to it:

Picture 1.png

A value will be incremented each second. When restarted, the value will continue to increase since the last setting, demonstrating the non-volatile memory. The demo uses I2C address 0x50 to address chip #0 – chip 1 #is at 0x52, chip #2 at 0x54, and chip #3 at 0x56.

This demo is available as the eemem example in the Ports library.

Here’s the plug hooked up to a JeeNode:

This plug supports daisy-chaining of more I2C-type plugs.

So there you have it – a Solid State Disk!

Plug Panel 1 is in!

In Hardware on Sep 18, 2009 at 00:01

Woohoo, got my 10 prototype boards with 6 plugs and 2 connector boards in:

Already, several major and minor issues have appeared. I’ll report here as I investigate exactly how good or bad all these tiny boards have come out.

Here’s a first one, the Blink Plug:

The header has been soldered flat and on the bottom side, so that through-hole pins are raised slightly above the base level. This is a convention I intend to use for all plugs: male, flat, bottom-side, left. And with I2C daisy-chainable plugs: an optional female header on the right.

Here’s a silly way to use the plug… on an Arduino!

(apologies for the ugly flash picture)

The “port” header is pushed into Arduino pins 8 through 13. A trick is used to supply power via the I/O lines:

Picture 4.png

This demo sketch is available here as “arblink.pde”.

Note that with this very simple Blink Plug, pressing a button always turns its LED on. The proper LED state is restored once the button is released.

Connecting a battery

In Hardware on Sep 17, 2009 at 00:01

There are a number of ways to run a JeeNode off batteries. The lower bound is around 3.5 .. 3.6 V, depending on current draw. With 3.5V, the voltage regulator only has about 0.2V to work with, which is probably ok as long as the total current consumption stays under 50 mA or so. The maximum allowed voltage is around 13V, but drawing too much current at that level will lead to excessive heating and cause the voltage regulator to shut down.

So with alkaline and NiMH, you need only 3 cells.

For temporary connections, use the FTDI connector:

For more permanent connections to the JeeNode v3, you can hook up a 3-or-more-cell battery pack as follows:

The 10 µF capacitor next to the battery connectors can then be folded flat over these wires again, if needed.

Another option would be a 9V battery:

Keep in mind that 60% of those 9V will be turned into useless heat in the voltage regulator…

And then, there is the option of using a rechargeable Lithium cell (LiPo). They supply 3.7 .. 4.1 V – a perfect match, if you take the proper safety precautions with charging them.

Update – note that the FTDI connector and battery connectors are both attached to the same “PWR” line, so please remove the battery (or add a disconnect switch) when connecting the unit to FTDI.

JeeNode pinout

In Hardware on Sep 16, 2009 at 00:01

I don’t think I published this pinout overview before:

jeenode pinout.png

Also available as PDF – use your printer’s print-4–pages-per-sheet setting to print a smaller version as reference.

JeeLink, JeeNode, JeePlug

Port extension

In Hardware on Sep 15, 2009 at 00:01

Found these 6-pin female-to-female cables at Seeed Studio:

Available in 100, 200, and 300 mm lengths.

By adding an extended-length 6-pin male header as shown on the right, this can be turned into a convenient extension cable for ports and plugs.

The color coding helps create a convention for ports, since their connectors are not polarized, but be careful – it looks like my batch used a different set of colors than what is currently showing on their website. And the colors also differ from an FTDI cable, alas.

Ah, conventions… so many to choose from! ;)

Second plug panel

In Hardware on Sep 14, 2009 at 00:01

Here’s the second panel of plugs I’m about to send off:

Picture 1.png

Some pretty odd stuff on there. Top left is a breakout board I’m making for a 30-pin FPC connector. Just because it was easy to add, not likely to be of use to anyone else.

The Voltage Plug has up to four 12-bit DAC’s connected via I2C. Yes, I do have something in mind for them…

The LCD Plug now comes with a tiny “end plug” attached which can be separated from it if needed. It’s a 3.3V to 5V boost regulator. This makes sense for an LCD backlight, but I need to work out usage scenarios, otherwise this will cause major trouble – with 5V regulating down to 3.3V while at the same time boosting it back up…

JeeLink, JeeNode, JeePlug

Daughterboard

In Hardware on Sep 13, 2009 at 00:01

Here’s a simple design for a little “Proto Board” which covers all the port headers and the ISP/SPI connector:

Picture 1.png

The PWR/I2C header on the JeeNode is not covered by this board. I’m still exploring some options, hence the unmarked rectangle at the right end. The board is deliberately slightly asymmetric, to make it easier to remember which way it goes on.

Holes will be plated through as always, with text labels on the other side as well.

I’m considering not adding any connections to allow all solder pads to be used in various ways. This does mean wires need to be attached directly to the header pins to use them.

Just exploring for now – I’ll probably add this to the next panel prototype run, just to see how it works out.

Even more plugs

In Hardware on Sep 12, 2009 at 00:01

This plug thing is starting to become addictive…

I’ve been working on another set of plugs, to extend the interfaces further. Here’s a preview of a few new ones, all using I2C and daisy-chainable:

Picture 1.png

From left to right:

UART Plug – a serial port with 64-byte RX/TX buffers and RTS/CTS lines
Analog Plug – 8 analog inputs with 12 bit resolution
LCD Plug – a piggyback board for LCD displays with a standard 16-pin header

Most of these plugs will have jumpers to allow connecting more than one of them to the same port (as I2C bus). So within the limits of power consumption, I2C bus lengths / loading, and processing bandwidth, this should allow for quite a bit of extensibility.

Build progress

In Hardware on Sep 10, 2009 at 00:01

Aha, now we’re getting somewhere:

Almost perfect reflow this time – only had to fix 2 solder bridges on the rightmost FTDI chip, then add the USB connector and wire antenna. All four worked right away!

The trick is to press harder on the stencil at the end, so that a truly thin layer of paste remains when lifting it off. It was a bit too thin in some places in fact, so I had to dab a bit of extra paste on a few pads.

This stencil thing is indeed a huge time-saver over applying paste with a syringe to each individual dot. It’s not just the amount of work, it’s also the type of work: keeping a steady hand while doing all those 100’ish dots per board was extremely tedious.

The total time spent on assembling these four boards was 1:30 hours – not stellar, but ok.

Four more boards done!

Smaller still?

In AVR, Hardware on Sep 9, 2009 at 00:01

Now that the JeeLink is a reality, and SMD has become an option, I’m already wondering how far to take this…

Because, well, there’s this neat USB stick case available:

I suspect that the same FTDI + ATmega + RFM12B as on the JeeLink can be fitted in there, but at the cost of omitting all expansion. No ports, no headers, no reset, nothing – but nevertheless an Arduino / JeeNode / JeeLink compatible unit.

There may even be room for a few Mb of flash memory. So this could be used as central interface to a PC/Mac, and it could collect data while the computer is off – as long as the USB port is on (a powered hub perhaps).

Would it make sense to create a separate unit for this? Just for the wow factor? Let me know, please…

Final JeeLinks

In AVR, Hardware on Sep 8, 2009 at 00:01

After the goof-up of not heating the boards up enough for lead-free solder, I simply re-did the reflow with a 250°C temperature profile. This appears to be near the limit of what my reflow grill can do, btw.

Here’s a fully assembled JeeLink:

Note that I soldered all headers in, including two which aren’t supplied standard with the JeeLink:

As shipped, the JeeLink comes with the 4 port headers, not yet soldered in.

While it still takes me quite a bit of time to assemble these JeeLinks, all four of the ones I did are now working (ahem, that’s a lie: I shipped two JL’s without proper testing… impatient as I was!).

So this story has a happy ending – the JeeLinks are ok now, it’s time to move on …

JeeLink, Reflow

SMD pick and place

In Hardware on Sep 7, 2009 at 00:01

Now that the solder stencil is ready for use, I went ahead and tried it – using solder paste and a (not-so-wide) squeegee type tool. Here’s the result:

If you look closely, you can see how nicely the paste ends up on the pads:

The stencil needs to be cleaned for future re-use, though:

(sorry for the incandescent light reflection)

Ok, now the tricky part – the “pick and place machine” (me). The result:

That’s the illuminated magnifying glass I’m using, by the way.

Looks perfect to me:

Baking now, in my JeeNode-based reflow controller:

Hm, this stuff is considerably smellier than before. Here’s the result…

Wait a minute – if you look closely you can see that a lot of the pads show up as a gray surface, not the shiny metal I was expecting!

WHOOPS – I used a temperature profile for leaded solder, but this is lead-free solder – silly me!

Stay tuned for the rest of this story… tomorrow.

Solder paste

In Hardware on Sep 6, 2009 at 00:01

As I mentioned before, the main problem I have with SMD’s on JeeLinks is applying too much solder paste.

Well, I just got a few test stencils in the mail from Paul Badger of Modern Device, who is experimenting with a laser cutter and a variety of plastic sheets.

So here’s my first DIY solder paste stencil jig for JeeLinks:

In good DIY fashion, it’s made of things I “happened” to have lying around, such as a piece of “foam” used by photographers, i.e. a few millimeters of foam (PU?) sandwiched between two thin plastic sheets. It’s easy to cut so size, and a bit of a cushion might actually help level out the pressure when applying paste. I used hot glue to fix a couple of pcb scraps to the board, and a single line of adhesive tape to fix the stencil.

This jig opens up to take a panel with 4 JeeLink boards, like this:

It’s all about getting the alignment right, of course:

Will it work? I’ll report in the next few days…

Boards done

In Hardware on Sep 4, 2009 at 00:01

Ok, the 8 little board designs are done and have been sent to manufacturing (doesn’t that sound impressive?). Here’s the final layout check:

(This is a screenshot from ViewMate, with all the Gerber files generated by Eagle loaded in.)

Here is a summary of what each board does, from left to right, top row:

The Blink Plug is as simple as it gets: two LEDs and two push-buttons.
The Expander Plug has 8 general-purpose digital I/O lines – based on the MCP23008 chip, it uses an I2C bus and allows daisy-chaining. Two jumper pads allow up to 4 of these plugs on the same bus.
The Thermo Plug ties the AIO pin to either an NTC (thermistor), or a K-type thermocouple (via an expensive AD597 chip), or a DS18B20 1-wire sensor. The DIO signal drives either an on-board buzzer or an external relay / light / DC motor via a transistor.
The I2C Connector is not a plug but hooks up to the 4-pin PWR/I2C header on the JeeNode and provides a “port-like” 6-pin bus for I2C-based plugs.

In the bottom row:

The Room Plug is a shield-like daughterboard which plugs into ports 1+4 or 2+3. It supports an SHT1x temperature/humidity sensor or a DS18B20 1-wire sensor, a PIR or ePIR module, and an LDR.
The Memory Plug is an I2C-type daisy-chainable plug with 1 .. 4 EEPROM chips (up to 512 Kb).
The Clock Plug is an I2C-type daisy-chainable plug with a DS1307 real-time clock and battery backup.
The Breadboard Connector is the thing marked “plug” in this previous post. It’s not a plug, just a bit of wiring between a bunch of pin headers. It also works on the rightmost pins of the Expander Plug.

I2C plugs are at least 0.1″ wider than daughterboards, so that they can’t accidentally be plugged into two ports at once (which would short-circuit just about everything!).

I haven’t tried all of this yet, the I2C stuff in particular is untested. I have no idea how many of these plugs could be daisy chained reliably, or what the limits are in terms of power drain. But with the I2C Connector, things should be fairly robust since it has pull-up resistors to bring the I2C bus in spec, as well as a 3.3V regulator.

Note also that all these I2C buses (up to 4 bit-banged ones and 1 with MPU hardware support) use 3.3V logic levels. Just like the rest of the JeeNode, I’ve decided to use 3.3V as standard voltage for everything. The “PWR” pin carries whatever voltage is fed into the system, though it will most likely be about 5V in many cases. More and more sensors and memories come in 3.3V versions, these days.

It’s far too early to say how far this can be taken. Can we connect up to 160 individual I/O pins on a JeeNode? (5 buses x 4 expander plugs), or 2.5 Mbyte of EEPROM memory? (5 buses x 1 memory plug) – I doubt it. Besides, if connecting the maximum number of I/O lines were a goal, I’d probably combine several 16-line expander chips on a special-purpose plug instead, or even use 40-line expanders.

Done! The next challenge is to maintain all this flexibility in the software.

Update – I’ve added some docs, very preliminary for now, i.e. until the boards get a proper workout.

Lots of plugs

In Hardware on Sep 3, 2009 at 00:01

After a lot of head scratching, I’m getting ready to have some prototype boards made. Here’s a recent version of the Gerber files:

And here’s a 3D rendering of the same which was astonishingly easy to do (I’m not going to finish it or fix the quirks – this was just to try out Eagle 3D):

You’re looking at eight tiny boards, most of which have already been presented in recent posts. It’s also eight ways to mess up in some more or less silly way, but hey that’s all part of the game.

Unlike the software design-code-test-rinse-and-repeat cycle, which can be done many many times per hour, the cycle time for hardware project runs like these is measured in weeks. W e e k s !

Since I don’t expect these boards to be right on the first iteration, this means that at least some of them will be more than a month off before I can declare victory and start using this stuff all over the place. But then again, each of the boards is in itself fairly simple, who knows…

Ok, I’ll do one last round of checking, tweaking, and re-generating the final Gerber files, and then the waiting starts…

Patience. Drat.

JeeLink, JeeNode, JeePlug, Sensors

Meet the JeeBoard

In AVR, Hardware on Sep 2, 2009 at 00:01

I hate wires. Wires to power up stuff. Wires to transfer data. What a mess.

I just want to try out physical computing ideas on my desk, next to my (wireless) keyboard and my (wireless) mouse – while exploring the possibilities of hardware + firmware + software running on my “big” computer.

So here’s to scratching my own itch: meet the JeeBoard – a little 8×10 cm unit with no strings attached – heh ;)

A first mock-up with real parts, here still using a green JeeNode v2:

On the left, a couple of demo plugs have been inserted. Those that use I2C can be daisy-chained.

One port is permanently hooked up to an I/O expander chip with 6 digital I/O lines for the mini-breadboard, 2 LEDs, and 2 pushbuttons. The on-board battery pack provides 3.6V with NiMH or 4.5V with alkaline cells.

The little overhanging board on top of the mini-breadboard “feeds” 8 wires into the center of the breadboard: +3.3V, ground, and the 6 general-purpose I/O lines.

I’m going to mess around with the layout a bit and explore some actual hookups before designing a real PCB for this. But even just looking at the mockup makes me want to start trying out stuff with it. Wireless, of course!

JeeNodes now with 328

In AVR, Hardware on Aug 31, 2009 at 00:01

Starting now, I will be replacing the ATmega168 by the ATmega328p in all future JeeNode kits:

Twice the memory: 32 Kb flash, 1 Kb EEPROM, and 2 Kb RAM – and twice the creative fun!

Memory Plug design

In Hardware on Aug 30, 2009 at 00:01

Got some ideas about storing a bit more data than the JeeNode can handle by itself, so here’s a little plug for EEPROM memory chips:

Picture 4.png

There’s room for up to four chips, i.e. 64 .. 512 Kbyte total. Plenty for a bit of data-logging and for storing compiled sketches / code for remote nodes. Or you could push for new limits with a flash-based O/S :)

This uses an I2C bus: the 6-pin male header on the right plugs into a port and is wired-through to the 6-pin female header on the left, just as with the Expander Plug described a few days ago. The width of this board has been increased so that it can’t be mistaken for a dual-port daughterboard.

Ok, so much for plugs… I need to re-check and finish each one and get a few prototype boards made!

Clock Plug design

In Hardware on Aug 29, 2009 at 00:01

The obvious plug, given that I2C is so easy to do now, is a real time clock based on the DS1307:

Picture 2.png

I’m using a small battery since a CR2032 coin cell is so… large. This board has a 12mm holder – with a 48 mAH BR1225 battery the RTC will run for some 10 years according to Maxim.

As with several of these plugs, boards like the above come a dime a dozen. It isn’t very hard to do – but once you’ve got a convention for pinouts and a physical layout that works, having such boards becomes a great time-saver. Particularly when daisy-chaining I2C plugs.

Thermo Plug design

In Hardware on Aug 28, 2009 at 00:01

The plug rage continues … this is a plug to measure temperature with either a thermocouple or an NTC resistor:

Picture 1.png

The chip is one of the AD594 .. AD597 series for use with J / K type thermocouples. With an NTC, the chip and 2 caps should be omitted, with a pull-up resistor added instead.

The other I/O pin is used for a piezo buzzer. It is driven via an NPN transistor with the positive lead connected to PWR to increase the volume. An alternate use for this pin + transistor is to control a relay or an opto-isolated triac.

Depending on the parts used, this might make a nice plug for a JeeNode-powered reflow controller. Or a temperature-controlled aquarium / soldering iron / 3D extruder / whatever. Or up to four overheating sensors, when used with multiple ports.

Expander Plug design

In Hardware on Aug 27, 2009 at 00:01

Here’s a design for a little 8-bit “Expander Plug”, based on I2C:

Picture 1.png

This uses the PCA9674 expander chip (PCA8574 would also work).

The connector on the left plugs into a port. The one on the right is wired-through to allow daisy-chaining a few of these plugs (or other I2C plugs). There are solder pads to assign one of four I2C address ranges to each plug.

The I/O lines are brought out on a 2×5-pin male header, including ground and optional PWR. This can be used with a standard 10-wire ribbon cable connector, though I’d place the plug near where it is needed and use a 6-wire connector between the JeeNode port and this plug in most cases.

This plug can also be used to attach a standard LCD module. There’s even a spare pin which could be used to drive the backlight on and off through a transistor. This plug will require a small change to the Arduino’s LiquidCrystal library to re-route the I/O through I2C.

It’s a tight fit, I’ll probably make the plug slightly wider. The added benefit is that it can then no longer be plugged into two ports by accident. I’m still undecided on the 2×5 header, but haven’t been able to come up with a more convenient choice. Suggestions?

As bonus, here’s a trivial plug with two LEDs and two push buttons:

Picture 3.png

By switching I/O pin directions briefly we can read out both button states, so this trick allows using a single port as 2 inputs plus 2 outputs.

Room Plug design

In Hardware on Aug 26, 2009 at 00:01

I’ve started work on a plug for the room sensor nodes, since it’s too tedious to wire up lots of them by hand.

Meet the 20x21mm “Room Plug”:

Picture 1.png

It has room for an SHT11/SHT15 type temperature / humidity sensor, an LDR as light sensor, and one of two types of PIR motion sensor. There are two positions for the LDR, depending on which type of motion sensor is being used.

In normal use the plug will be fully populated and placed as a bridge over ports 1 + 4 (or 2 + 3) of a JeeNode or JeeLink, but it’s also possible to only mount one or two sensors and – depending on which sensors – to plug the board into a single port, pointing upwards. Or even to use it as breakout board for a standard Arduino, or any other setup you like for that matter.

I’m going to look into a few more plug ideas before having prototypes made, to reduce cost a bit since these plugs are so tiny. Many sensors are not really worth a custom-made board, since the generic JeePlug will let you hook up most of them yourself. But having said that… if you’ve got suggestions for a hookup which would be really cool to have as ready-made plugs, let me know!

RJ11 daughterboard

In Hardware on Aug 24, 2009 at 00:01

For connecting the JeeNode to a bunch of opto-sensors to track energy, gas, and water consumption, I’m thinking of using RJ11 telephone cables. Not only is the 4-wire version of these cables easy to get and cheap, you can in fact get two cables by cutting them in half and connecting the loose wires to whatever you like.

Here’s a daughterboard idea which would make it very easy to use JeeNodes for such a setup:

This is a mockup – the pin distances do not fit the 0.1″ proto-board grid, but you get the idea. Should probably add a power-on LED as well.

The power jack makes it easy to attach any standard 4..12 V power adapter. The 6-pin FTDI connector on the side is only for re-programming the unit – it can be omitted if you flash the ATmega with the proper code before inserting it into its socket.

I’m not sure what to do about mounting such a unit, though…

Update – The term “RJ11” is not quite accurate. It’s a 6-pin socket (RJ12), which could be used either with 2 (RJ11), 4 (RJ14), or 6 (RJ25) wires connected, as described on this page, for example. So it’s more like an RJ12 daughterboard, for use with RJ14 or RG25 cables.

JeeLink issues solved

In AVR, Hardware on Aug 23, 2009 at 00:01

It turns out that there were two problems with the new JeeLink boards, one major and one minor.

The reason why my assembled JeeLinks wouldn’t show up as USB devices is that the FTDI chip’s TEST pin was left floating instead of being tied to ground. It’s trivial to fix: a small dab of solder between pins 25 and 26 of the FTDI chip does the trick. Now all but one of my 6 JeeLinks show up as USB devices – yeay!

The second problem is not as critical: the +3.3V pin of all ports isn’t actually connected to anything… whoops. But this too is relatively easy to fix – a small wire from the VR output to the +3V pin on port 2 will fix it.

Thanks to Paul Badger of Modern Device and Marius Kintel for helping out and coming up with suggestions. I’m regaining my sanity now…

In the coming week, I’ll send out new JeeLinks to everyone who pre-ordered these units. I’ve run out of SMD LEDs, so I have to replenish my (limited) supplies before assembling and testing more boards.

But rest assured, they work and pass all tests. There are several JeeLinks on my desk right now, each of them running as intended.

To celebrate this milestone, all JeeLinks will be shipped with ATmega328’s instead of 168’s – including all the pre-ordered units.

Update – the above two issues and their fixes have been documented here.

Lots of nodes

In AVR, Hardware on Aug 22, 2009 at 00:01

I’m gearing up to install over half a dozen nodes around the house to monitor temperature, humidity, light levels, and to detect motion:

The plug at the bottom is a one-off to check out the connections for the EPIR version.

These are my last JeeNode v2 boards, salvaged from various experiments, with all their port headers replaced by the new 6-pin-female-up standard.

Given that these are v2 boards, I’m hand assembling the plugs to match the “old” port pinout. Beyond these, I’ll use the new v3 boards with a little pcb “room plug” to be created later.

Back to soldering a few more of these little sensor critters!

JeeLink status

In AVR, Hardware on Aug 21, 2009 at 00:01

The plot thickens… and I’m pulling my hairs out along the way.

The good news is that I have assembled 6 boards now, and they all behave in (nearly) the same way. The on-board ATmega is working and correctly running the blink test sketch installed when setting up the boot loader via ISP.

So the basics work. The voltage regulator is probably also ok.

The bad news is that none of these 6 boards is showing up as USB device. Whoops.

I’ve gone through a couple of build techniques, from reflow to hand-soldering, as well as various combinations. But after some obvious solder bridge removals and a few loose connections after hand-soldering, at least 5 of these boards exhibit identical behavior. I’m either getting it right or consistently doing something wrong.

Also found a problem in the PCB traces, i.e. a trace between 3.3V power and the 3.3V pins on all 4 ports is missing. But this is relatively minor – a tiny extra wire should fix that.

I’m at the point where I really need to step back to re-think what else could possibly be wrong. It must be some silly / stupid oversight… I’m still hopeful that the aha-slap-on-the-head-erlebnis will come soon.

Meanwhile, I’m also exploring some alternatives. Today, I visited a nearby “Fab Lab”, which has laser cutters, CNC routers, 3D-printers, and more such mind-blowing geek stuff. Absolutely fascinating – I’ll never look at an object in the same way again. Any object.

One of the things I wanted to try out is to create SMD stencils like the big boys do. A first trial on cardboard, paper, and 0.5mm polystrol came out as follows:

The layer on top was my first attempt, using thin cardboard. As you can see, it’s not quite perfect since the holes are too large – there is no vector adjustment for the 0.1mm laser beam overhead. Then again, the plain paper example in the middle shows decent separation, and having paste overlap is not necessarily a problem.

I’ll try some more adjustments next time and will get a bottle of paste with squeegee to play around with this stuff. Who knows, maybe even a 1-time use plain paper sheet can work?

CD drive as X/Y table?

In Hardware on Aug 20, 2009 at 00:01

(Warning: this post is a digression into robotic tools…)

I’m still struggling with the assembly of JeeLinks: after 4 attempts, none of my boards work and each with different results – not good :(

The answer is probably to have SMD stencils made to apply the solder paste evenly and in precisely the right spot. Manual parts placement with a tweezer is tricky but it seems to work ok for me.

But I’m hesitant. Stencils add a considerable cost overhead to each pcb run, and I’d like to be able to do lots of prototype runs in the future.

The other way to do this is to automate. Unfortunately, SMD machines are expensive – even the manual-assist or “semi-automated” ones are in the multi-$1000 range. And I don’t really need a CNC router with extreme precision or a 50x50cm work area plus a full 3D Z-axis. I just need to deal with printed circuit boards of say 3x12cm and position them within 0.2mm or so. Plus a reasonably accurate automated solder paste dispenser.

Hm. Wait a minute. That’s essentially the range of a CD/DVD drive: the tray comes out about 12 cm, and the laser inside moves about 3 cm. Why not take apart an old CD drive and mount the laser motion system on top of the tray and perpendicular to it?

Here is an old Philips drive I still had, disassembled:

Here is the drive, “reorganized” to perform X/Y positioning, with both actuators at the opposite ends of their respective travel:

Here’s another one from AOpen:

A close-up with the laser platform turned and on top of the tray:

The motors in both drives create a smooth and not overly fast motion when driven by 1.5 .. 3V, but the tray motor from AOpen draws much more power (about 250 mA).

The main idea is that such a setup can move the laser platform over an area of 3x12cm. But instead of turning on the laser, some sort of pcb holder could be attached to it so that the board is positioned. Then, all I need is a syringe mounted in a fixed spot over this X/Y table and some move-down-and-dispense mechanism.

Voilá – a dirt cheap automated solder paste applicator for small PCBs!

Given that there is no sideways strain, I hope that the tray/X-axis positioner (which has some slack) can be made accurate enough for solder paste by spring-loading it. The laser/Y-axis accuracy should be ample without much effort.

One problem with both drives is that they use linear motors instead of stepping motors, so there is no easy way of figuring out the current X/Y position.

Hm again. Could we somehow accurately measure the position of the X/Y table? Adding quadrature encoders to both rotating shafts would solve it, but that means hacking the mechanism – which I’d rather not alter. Not to mention getting suitably small encoders.

So here’s a second idea: the X/Y table positions the pcb, but perhaps it could also move around a bit of graph paper, attached alongside the board. And then… maybe an optical mouse could be hacked to detect the changes? Though I don’t know how hackable optical mice are. Another option might be to use IR proximity sensors, but that’s pushing it and would require precise calibration.

The third issue is the solder paste dispenser. Some sort of syringe, with the plunger tied to a servo, perhaps?

There’s a second, simpler, use for such a system: a PCB inspection system. Just place a loupe or microscope on top and meander the board underneath it.

I’ve even got an old Ikea drawer to fit the entire thing into:

I know, I know, it’s crazy. But still… ideas are cheap, and so far my materials cost is zero!

New home sensor setup

In Hardware on Aug 19, 2009 at 00:01

Here’s my new prototype for sensor nodes in the house:

It has an SHT11 temperature/hunidity sensor, an LDR, and a PIR motion sensor. Prototyped using a JeePlug, of course. Ports 2 and 3 are still unused. Note that this little board can also be plugged into ports 2/3 or even turned around – all configurations will work (by adjusting the port numbers accordingly).

Here’s a silly mounting option, which will have to do for now:

This setup is attached inside a bookshelf under the top panel, roughly pointed so the motion sensor covers the room. Not shown is the power connection from a 5..12V wall-wart (I’ll look into battery mode at a later date).

Totally crude, but it works and lets me easily detach the unit between tests.

Here’s another prototype based on old “plugs” I had lying around and a JeeNode v2:

The source code for this is called “rooms” and replaces the older “pulse” sketch. It’s available here. It handles both configurations, i.e. the ELV PIR and the ZDOT SBC.

This setup will be used instead of the earlier “pulse” design described in these posts. If there is interest, I can design a little board for it handling either PIR module.

FS20 developments

In Hardware on Aug 18, 2009 at 00:01

Looks like the FS20 remote-controlled system from Conrad and ELV has gained a few new units. Here’s a 60-euro 2-channel power-strip, controlled from 868 MHz, hence also from a JeeNode:

Also a 42-euro repeater to get through multiple layers of reinforced concrete.

Great options to avoid having to deal with line voltages. Not ultra-cheap, but still.

The one drawback worth noting with FS20 is that’s it’s not replay-safe. If someone picks up these signals, they can re-send them at a later time, even from outside the house. This means there is essentially no security at all with this approach. But for things like lighting and office equipment, that’s probably not an issue.

LED polarity

In AVR, Hardware on Aug 17, 2009 at 00:01

Ok, first puzzle solved. I had the two 0603 LEDs reversed.

The silly part is that I had actually built a test rig to make sure this wouldn’t happen:

As trivial as it gets: a battery with a series resistor. By holding the SMD LED against two copper contacts it’s easy to check which side is which. Here’s a green LED lighting up:

Then I got confused and placed all the LEDs exactly the wrong way around – doh!

There are three copper pads. The middle one is PLUS, the other two are GROUND.

Ok, now the RX+TX LEDs blink a few times when plugged in. Onwards!

JeeLink build woes

In AVR, Hardware on Aug 16, 2009 at 00:01

Ok, I’m back. The Jee Labs blog resumes…

This first post is a progress report on the JeeLinks. Here are three partial builds (the bottom one has some hand-soldered parts, the rest use reflow soldering):

I had to remove some solder bridges from the FTDI chips, but apart from that everything looks pretty tidy now. The JeeNode-based reflow controller is working very nicely.

Here are a couple of extreme close-ups:

Unfortunately, I’ve not been able to get any of these boards working so far. The FTDI chip ought to be visible as a serial USB port, even if the MPU isn’t working properly, but it isn’t showing up.

I’m probably missing something but for now it’s bad news. I’ll continue debugging this, of course…

Building the JeeNode v3

In AVR, Hardware on Jul 15, 2009 at 00:01

The v3 boards are finally ready! Here’s a step by step overview on how to assemble a JeeNode v3 kit:

Turn the board around and solder the leads:

Then carefully cut them off:

Continue in a similar vein with the four 0.1µF ceramic capacitors:

Next the IC socket, which is a bit more work. The best thing is to solder two diagonally opposite pins, then check that the socket is pushed in all the way:

If not, reheat and fix it. Then solder the remaining 26 pins:

The 10 µF electrolytic capacitor is polarized – there is a “+” marking to indicate which way it should be soldered in. I normally bend the leads first and then make it lie flat on the board:

Next the voltage regulator IC. This one needs special attention because it has to be mounted differently from what the marking on the board says. The reason is that the board was designed for an LP2950, but the kit includes an MCP1702 which has a different pinout. Here is how it should be mounted:

The 16 MHz resonator is next, it’s the tallest part on the board:

You’re almost there now. The radio module is a surface mounted module, which needs a slightly different approach. Put a bit of solder on one pad, then place the module over it and reheat to stick it in place:

Once correctly positioned, add solder to each of the remaining pads to make shiny round joints:

The 6-pin male FTDI connector can now be soldered on, I usually mount it sideways, but the choice is yours:

A simple wire acts as antenna for the radio – attach it to pin 1 of the radio module. You can bend it as needed afterwards. I used a red wire, even though the kit probably has a yellow one.

One more step and you’re done: add the four 6-pin port headers.

Good, the soldering is over. Now bend the pins of the ATmega microcontroller slightly inwards so it fits into the socket. Make sure you only press it firmly down after all the pins are in the proper position.

Voilá! Your finished JeeNode:

If you have a USB-BUB adapter, you can now plug it in and try out the board (note the 3.3V jumper – the JeeNode uses 3.3V logic signals). The ATmega that comes with the kit is pre-loaded with the RFM12demo sketch to get you up and running in no time:

That’s it. Congratulations with your new JeeNode v3!

My first reflow

In Hardware on Jul 13, 2009 at 00:01

Here’s my new super duper reflow setup:

I decided to use a JeeNode as reflow controller. This is all about hammers, nails, and dog food, after all :)

The grill is turned on and off via an FS20 remote power switch, which is controlled by the on-board RFM12B. No need to get into relays and high-voltage stuff. Total cost including grill, LCD, and remote switch is under € 100.

The whole setup can be battery powered. I used the new plug breadboarding approach for prototyping it all:

The “P” at the lower left indicates it’s currently in the pre-heat phase, now at 110° with a target of 140°.

The port assignments on the JeeNode are:

Port 1: serial 4×20 LCD display, based on the Modern Device LCD117
Port 2: NTC on AIO with 1 KΩ pull-up to 3.3V, piezo buzzer on DIO
Port 3: two leds: green is running, red is grill power on
Port 4: two switches: white is run/stop, black is select profile 0..9

I’m not using PID control. Merely did a manual test to determine the overshoot, and am compensating for that by turning off a bit earlier. It turns out that this grill has a huge overshoot: some 65°C ! … so I removed both Teflon-covered metal plates and am now using a 0.5 mm aluminium panel instead. Overshoot is now around 30°.

The system can be configured through FTDI / USB. Once set up, it can be operated without computer. The LCD display is optional but a great convenience.

Here’s the first test board (using some scrap boards from SparkFun):

This is the cool-down phase, i.e. with the grill open. The temperature sensor is taped to a separate board to track things under similar conditions. The tape needs to be heat resistant, of course… I got it from DealExtreme:

And here’s the final result:

Only used a few resistors for this trial, and spread some paste on the TQFP pads to see how that comes out.

If you look closely, you’ll see that the leftmost resistor under header pin 13 is “tomb-stoned” – it’s standing straight up as the capillary pull of one pad took over. I probably put too much paste on one pad and not enough on the other.

But the rest looks good… f a s c i n a t i n g !

I seem to be getting a decent temperature profile. Things heat up nicely, stay in soaking ramp-up mode for a while, and then go up to a few degrees over 220°C. When the grill has to be opened up for cooling down after reflow, the system beeps to draw my attention.

FWIW, the source code for this setup is available here.

There’s still an intermittent problem with the NTC hookup – I’m getting occasional flakey connections on the enamel wires, which are simply wound tightly around each end of the NTC. Can’t use solder there, and I haven’t found another solution for that. For now, the controller just powers off when the NTC reading is bad, but that’s a pretty horrible approach.

Conclusion so far: reflow is absolutely doable for hobbyists (my second try went perfectly!), with the paste being the most tricky bit. Stencils are probably very useful to apply paste quickly and evenly.

See also Stephen Eaton’s recent post, where he describes his latest results with SMD reflow.

Sensors, Reflow

Reflow temperature

In Hardware, Software on Jul 12, 2009 at 00:01

For my upcoming reflow experiments, I’d like to use a JeeNode to track the temperature and perhaps also control the grill. As the saying goes… when you have a hammer JeeNode, everything looks like a nail sketch.

So I hooked up a 10 KΩ NTC resistor rated up to 300°C as voltage divider with a 1 KΩ resistor pull-up. Bought a cheap and probably not-so-accurate multi-meter with thermocouple-based temperature readout. And then the fun starts – turned my grill on and watched it heat up and then cool down, while jotting down the “readings” from this “experiment”. I felt like a high-school kid in physics class again :)

The results:

Picture 1.png

Not bad. The readout is a bit coarse at the higher end, but I think it’s accurate enough for reflow soldering in the 170° .. 240° range. The grill goes up to 260°C from what I can tell.

But I didn’t want a lookup table, so I went looking for a polynomial least-squares regression fitter on the web and found this one. Great: copy and paste the 18 heat-up readings, then try out a few polynomes – turns out that a 7th degree polynome fits well, matching the measured data within a few tenths of a degree.

And then I found an even better site called ZunZun – it lets you fit polynomes and graph the results and generate the C++ code. No need to copy lots of coefficients!

Here’s what I ended up with, using a “Lowest sum of orthogonal distance (ODR)” fit:

Picture 1.png

Corresponding C++ code:

Picture 4.png

To be able to configure this thing, it would be nice to be able to enter degrees. That’s easy to do by also fitting the inverse function:

Picture 7.png

Corresponding C++ code for the inverse:

Picture 6.png

Great. Onwards!

JeeLink, ISP

Programming a 32-TQFP chip

In AVR, Hardware on Jul 11, 2009 at 00:01

With SMT parts, all sorts of things change. For the JeeLink, I’d like to set the fuses and flash the bootstrap code to the ATmega chip before soldering it to the board. Here’s how:

This is a zero-insertion-force socket for 32-TQFP chips. You put the chip on, press down, and the whole thing presses these 32 gold-plated contact fingers onto the chip. There are several alignment edges in there making it relatively easy and quick. It’s no doubt made for machine operation but it works nicely by hand as well.

And here’s the result – an ISP programmer which works with the Arduino IDE:

I’ll start flashing a couple of ATmega168 chips, in eager anticipation of the JeeLink boards…

Mounting a JeeNode with plugs

In Hardware on Jul 9, 2009 at 00:01

As promised: here’s an idea how to combine things. First let me show that plug pinout again – because I can…

Picture 3.png

An idea I’d like to present is to mount the JeeNode facing down. The board would look something like this:

Each of the four port groups has the corresponding pins tied together. With a JeeNode plugged in you get this:

And with some example plugs added:

Note how plugs mount the proper way up, i.e. lying flat on the perf-board, because the upside-down mounting of the JeeNode takes care of mirroring the connector. The only thing to keep in mind is that port numbering now runs clockwise, with port 1 in the top right.

The extra female headers can be used for testing, or as simple breadboard pins for hooking up some LEDs. Some space could be saved by leaving them out, though.

I think there could be several advantages to this setup:

plugging stuff in the “right” way becomes quite obvious
if you wire up plugs appropriately, you can chain them sideways (i.e. for I2C use)
mix and match: put some components directly on the board if you prefer
it’s all easily constructed with off-the-shelf “perf board” (with or without copper)
it could even be made from a piece of cardboard with a few holes in it
my favorite fastening system works: a couple of zip-locks to tie things down
for better protection, simply add a cover and leave cables coming out the side
the whole sandwich can be solidified with spacers and remains low-profile
it’s all laid out in the plane – place a paper design on the board to guide you
it’s easily documented: just take a picture of it…

But perhaps best of all, you can still create a completely different setup for permanent use. Just unplug everything and re-assemble it in some other orientation. So while this approach takes up relatively much space for the connectors, it does give you total flexibility to re-arrange things any time later.

I’ll try this out in a couple of projects. But even just with this mockup I noticed that having the plugs flat on a supporting surface makes it all surprisingly stable, and easy to carry around.

Plug pinout

In Hardware on Jul 8, 2009 at 00:01

Here is the standard pinout I will be using for all my JeePlugs and port connections from now on:

Picture 3.png

Do not ask how many different variations and scenarios I’ve been through. You don’t want to know. I’ve got the scars and JeeNode debris lying around here to prove it. I agonize over these choices so you won’t have to …

There are difficult trade-offs whichever way you go, but this is it. The best choice, period.

From that, several consequences follow. The most important two being that the JeeNode v3 and the JeeLink will be supplied with female headers for the ports, and that these headers should be soldered on pointing up.

If you have the v2 JeeNode, then my advice is to make a couple of conversion cables or plugs, so that you can set up all future connections using new standard. That’s what I did anyway – I don’t even have a v3 JeeNode here yet, and I’m already wiring up new plugs using the above convention. The pain of converting now is nothing compared to having a confusing mix of boards and plugs and cables later.

Depending on the power source you use, plugging in things the wrong way can definitely damage circuits. I suspect that a 5V power source such as the fused one from USB on the JeeLink is relatively safe, but a 12V PWR line hooked up the wrong way is likely to damage the ATmega. So will shorting pins 1 and 2, i.e. PWR and DIO.

If you need to work with such “high” voltages, I would suggest using 4-pin plugs where possible. In other words, don’t even bring that PWR line out to the peripherals / plugs unless needed.

Back to the pinout and orientation of plugs. With female headers on the JeeNode / JeeLink, you can see that plugs will be oriented with the components sticking out.

For plugs requiring two ports, you can mount the male headers pointing down on the JeePlugs and use them as tiny shields. Plugging such a shield in the wrong way, i.e . turned 180°, has no serious consequences. The ports 1 & 4 or 2 & 3 will simply be exchanged. Your sketch won’t work, but at least it won’t cause any electrical shorts or power-line mixups. Plugs used as tiny shields are quite robust in that sense.

That’s it for using plugs (or your own perf-board) and hooking up stuff to each port. By sticking to these conventions, it will be easy to re-use components in different configurations later.

The choice for non-polarized pin headers was a very deliberate one. They are very low cost, small, and widely available. This matters to me because I intend to hook up tons of different things over time. It just means we have to carefully pick some conventions and stick to them. Done.

Tomorrow I’ll describe another variant compatible with this which helps avoid inadvertent reversed connections and which supports chaining with a port as I2C bus. It will also make it easy to construct a more permanent mechanical “fixture” when hooking up multiple sensors, indicators, actuators, etc.

IO Expander

In AVR, Hardware, Software on Jul 7, 2009 at 00:01

Here’s a way to expand the number of digital I/O lines on a port:

3686066291_f856efcb63_o This is a JeePlug filled to the rim with tiny components and connectors. It’s based on a PCA8574A I2C 8-bit I/O expander. Each of 8 pins can be used either as inputs or as “mostly” open collector outputs. See the datasheet for details.

Here’s the bottom side of the plug:

3686871488_b2366a7459_o

Crowded indeed!

And here’s a demo sketch called “expander” which blinks the eight LEDs connected between PWR and the respective I/O pins:

Picture 3.png

As with yesterday’s example, this is running the I2C at maximum bit-banging speed, and seems to work fine. It’s used to make 8 leds blink:

3686871410_0e325c3a2b_o

The connector block on this plug has 8 sets of three connections: GND, PWR, I/O. Note that PWR is connected, not +3.3V. The reason for this is that I’d like to try driving a bunch of servos from this plug one day – it’ll load the JeeNode down a bit but it should be feasible.

The “expander” sketch has been added to the Ports library and is available as ZIP file and in subversion.

External memory

In AVR, Hardware, Software on Jul 6, 2009 at 00:01

For one of the projects in the Jee Labs, I needed a bit more “permanent” memory than the ATmega’s EEPROM or even flash could provide. Here’s what I came up with:

3683813851_d524fedae2_o

That’s a 64 Kbyte AT24C512B serial EEPROM memory which talks via I2C.

It takes only 4 wires to hook this thing up:

3684626986_c2c8f1119c_o

And this is the mess you get in when you don’t have the right connectors and need to deal with older boards:

3683813971_e00e924cb0_o

That’s the “regret plug” mentioned a few days back, to turn the downward pointing male header into an upward pointing female header, plus a “cross-over plug” to let me wire this thing up for the new JeeNode v3 pinout, yet use it on a (minimally populated) v2 board. Yuck!

Lesson: think about headers before deciding how to solder them on …

All future JeeNodes will be supplied with 6-pin female headers for the ports. Soldering them on pointing up is probably most convenient: it lets you stick little LEDs and wires in there, and JeePlugs can be placed pointing upright – such as this memory.

Back to the memory expansion. Here’s a test sketch:

Picture 5.png

Sample output:

Picture 4.png

As you can see, the count did not start with 255, as it would have if the EEPROM had still been empty. The JeeNode was powered off in between to demonstrate data retention.

This example code runs at full bit-banging speed – seems to work just fine.

The “eemem” demo sketch has been added to the Ports library and is available in this ZIP file as well as here.

There you go … a whopping half million extra bits of permanent storage :)

Mystery JeeNode

In AVR, Hardware on Jul 3, 2009 at 00:01

Some more pictures from yesterday’s puzzle…

3681641100_900fdf0f6e_o

Added a second LDR on the left and a DS18B20 1-wire temp sensor. A 4.5V @ 35mA solar cell has also been soldered in.

The sensor is a TSL230R light sensor, as Milarepa correctly commented:

3679117790_f89f0caa7d_o

It has one frequency pulse output, with two other port pins used to control sensitivity (1x/100x) and frequency divider (2x/50x). The fourth I/O pin is used as power supply for the chip, so that it can be turned off completely in sleep mode.

Here’s the whole assembly from the side:

3681641152_3a6d49194e_o

And here the complete JeeNode (using a different solar panel which turned out to be too weak):

3679151344_f871517b7c_o

So what does it do? And what is it for?

Well, two things really – but I’ll be the first to admit that this isn’t truly general purpose and unlikely to be very meaningful for anyone else.

The first use is to help me take better pictures. The photos on this weblog are all taken using nothing but a white sheet of paper and plain old-fashioned daylight. Benefits are that it’s free and abundant, it needs no space for a light-box setup, and it tends to produce beautiful images.

The problem which you may have seen on this weblog, is that daylight ≠ daylight. Sometimes it’s too dark outside, and sometimes the light is too harsh. Worse still, many of the photos end up with a blueish tint. I’m having a hard time predicting this, so it seemed like a nice idea to just throw a bunch of light sensors together and try to correlate this to picture quality over a few weeks time.

The other purpose of this unit is to act as test-bed for long-term solar-powered use. That means getting the power drain down to very low levels of course. But I also added the ability to read out the voltage of the solar cell and of the battery, as well as temperature (solar cells are sensitive to that). And LDRs facing opposite directions, to try and detect sun vs. cloud cover weather info.

This seemed like an excellent project for JeeNodes and JeePlugs. Once it’s working well enough – auto-ranging the light sensitivity and such – I intend to put this up on the roof and just let it send out packets every 5 minutes or so, day and night. This will make an excellent yet non-critical test setup as well as allow me to track solar intensity over the entire year. Think solar panels…

Tomorrow I’ll post several sketches: one showing how to read out everything and report it over the serial FTDI connection, then two more to show how to turn this into a send/receive solution with two JeeNodes, and the last one showing how to get power consumption down.

Stay tuned!

Simple plugs

In Hardware on Jul 1, 2009 at 00:01

Here are some basic uses for JeePlugs…

First the v2-to-v3 pinout converter:

3672042410_7d5b23f1b8_o

It flips the +3V and AIO pins. Here’s the bottom view:

3671235369_b5d1054071_o

Not pretty, but robust, and it works. Here’s a v2 JeeNode which will allow me to use plugs designed for the new v3 pinout:

3672042554_6468878165_o

The shrink-tube yellow bands are a reminder that these are “crossover” plugs. Better avoid major confusion later, once there are more plugs all over the place…

Here’s a weird one, I’ll call it the “regret plug” because it lets me use JeeNodes with a header orientation I’m now regretting:

3672042632_8a891a56a4_o

It lets you turn a JeeNode with downward facing male pin headers into onto one which has female headers pointing up, or male headers pointing sideways. Like so:

3671235565_ac050f2bd5_o

This is an odd contraption, but I’m sure it will come in handy one of these days. Note that there are no wires across the plug. Each side is independent and simply has 3 headers with all the corresponding pins soldered together.

The outer female headers have been soldered on at an angle to allow attaching to it – otherwise the JeeNode board edges would obscure the connector.

Note – Apologies for the confusing posting/re-posting today. I knew I had a post ready, but it got back-dated to June 1st, instead of July. Should all be fixed now, but some RSS readers might cache the previous post.

JeePlugs have arrived

In Hardware on Jun 30, 2009 at 00:01

Got some JeePlugs in today – yippie!

Here’s how I’ll probably use them most often – with one or two sideways headers:

JeePlugs

(These boards were sent off before the big URL rename – such is life…)

Note that both ends and the middle rows are connected in a pairwise fashion. The middle row traces are thin and can easily be cut if necessary.

I used flat headers, soldered in the underside of the plug. That way you can chain them and they’ll hold the plug slightly above the plane for pins sticking out, etc.

Here’s one way to use them on a JeeNode:

JeePlugs

The blue is the new green – all boards from JeeLabs will be blue with white markings.

Note the orientation here: in this setup, components are mounted on the outside.

And here’s another way to use the plugs, as mini shields:

JeePlugs

The headers are soldered onto the inner rows, leaving the connections to each header pin available from both sides on the outer rows.

There’s nothing JeeNode-specific about these boards, by the way. They have plated through holes, which makes them more convenient for soldering components and wires on either side. And the pairwise pad connections can save a bit on wires.

Breadboard limits

In AVR, Hardware on Jun 29, 2009 at 00:01

Here’s something which isn’t a good idea with breadboards:

Breadboard limits

I used a socket with wire-wrap pins to be able to connect a few wires yet still be able to use the whole thing in a breadboard. If you look closely, you can see that the 5-pin metallic connectors inside the breadboard are pushed out – making the adhesive separate from the rest. Whoops.

Wire-wrap pins are clearly too thick to be pushing into breadboards…

Arduino Mega + shield

In AVR, Hardware on Jun 28, 2009 at 00:01

Got myself an Arduino Mega – an Arduino on steroids:

Arduino Mega + shield

Compatible with current Arduino shields, but extended to support a lot more pins.

Ordered it from NKCelectronics, along with their new extended shield for it:

Arduino Mega + shield

There’s a lot of them pins on there…

I decided to attach a solder-less breadboard to it, to be able to experiment with projects which need more I/O lines or comms than a standard Arduino:

Arduino Mega + shield

It fits, but just barely. Had to cut off the little hooks on the plastic. Using a breadboard in this way covers up all the identifying pin texts on the silkscreen, alas.

Actually, it doesn’t quite fit – couldn’t get all headers on:

Arduino Mega + shield

I’m using a mix of 4- and 6-pin headers, since I had them lying around. As you can see, the last 4-pin header makes it impossible to fit that other header in, so I left off pins 22 and 24. It might have worked with an 8-pin header i.s.o. 2x 4-pin.

And here’s the final “stack”:

Arduino Mega + shield

Conclusion so far? I’m not sure this is the way to go. I think it’s an abomination, to be honest. There are so many pins to connect that the two boards are very hard to separate once stacked up. You don’t want to pull too hard on one side and end up with bent pins when the thing finally comes apart.

And how often do you need that many I/O pins one one fixed board setup? Sure, the ATmega1280 has 128 Kb of flash memory, which is plenty to get fairly complex sketches going. But it also builds on that trend of using stacked shields – and let’s face it: a single shield is often great, but with 2 or 3 you end up with pin allocation nightmares (for designers) or conflicts (for users). Multi-stacking is tricky, requiring special stacking headers.

Nah, I’d much rather go with ports, and extensions for that, and connecting two or three independent units over a bus if need be. But then of course I would, that’s why I went for such an approach with JeeNodes after all.

JeePlugs are on their way

In Hardware on Jun 25, 2009 at 00:01

Ok, I’ve decided to get a bunch of JeePlugs made.

A JeePlug is a little prototype board designed to fit exactly on one or two port headers of a JeeNode (or JeeLink). Here’s the layout:

Picture 6.png

See an earlier post for a description of how these plugs can be fitted to the JeeNode / JeeLink.

Some of the holes are connected in a pairwise fashion. With traces which can be cut when such a connection is not desired. The outermost two rows are for header pins and wires to connect to each pin, respectively.

The main intended use for these plugs is as a mini-breadboard hanging off the side of the JeeNode, so that up to four of these can be attached at the same time. But sometimes a single AIO + DIO pin just isn’t enough, in which case these plugs can be used as mini-shields bridging across two opposite ports.

It’s pretty low-tech obviously, but I expect these plugs to be a huge time-saver. Not just because they make it easy to hook up all sorts of sensors, indicators, and actuators, but because the result really is a plug. They can be mixed and matched at will, since all ports are equivalent. All that’s needed is to adjust the port number in the sketch / code to match the chosen header, a trivial 1-line change.

And because ports are so versatile, each plug can be an analog + digital I/O line, or an I2C bus, or a serial line. There are definitely limits to this approach, given that a JeeNode is after all based on a micro-controller, not a full-blown PC – but still.

Being flexible, modular, and inexpensive – that’s what JeeNode ports are really about. Oh yes… and wireless :)

I hope to get various plug examples going in the Jee Labs in the months ahead.

Meet the JeeLink

In AVR, Hardware on Jun 24, 2009 at 00:01

I’m proud to announce a new board next to the JeeNode, called the JeeLink. Yes, there’s a pattern in the naming choices made for products on this site.

The JeeLink is very much like a JeeNode, but in the format of a USB stick and with a few small differences listed below. Here’s the layout:

Picture 2.png

As you can see, the JeeLink has basically the same headers as the JeeNode, but with a USB plug in the place of the JeeNode’s FTDI connector.

The JeeLink is useful in two different ways, I think: first of all, if you have a couple of remote JeeNodes, you’ll probably need a central node as well to tie the whole network to a personal computer. The second use case is that it can be used as a JeeNode with built-in FTDI-to-USB conversion – which is exactly what it is, technically speaking.

A major difference with the JeeNode also, is that the JeeLink is built with SMD parts. The intention is to make it available in pre-assembled form and as bare board. No kits with parts – that’s reserved for the JeeNode since I don’t want to stretch myself too thin.

There will be a more detailed description of the JeeLink once it is ready and working, but here’s a first overview:

the dimensions of a JeeLink are slightly different, obviously
the I2C and SPI/ISP headers are not in exactly the same position as on the JeeNode
there’s no battery connector (who needs one with USB?)
the FTDI-type USB connection includes two on-board activity leds

So there you have it – a new descendant in the Jee family. With on-board RFM12B wireless radio of course, and 4 ports to connect absolutely anything you like to. Just like the JeeNode.

The JeeLink is the initiative of – and was designed in collaboration with – Paul Badger of Modern Device. We’ve been having a heck of a time together, hammering out all the details and making sure the result will be as good as we can possible make such a new concept. I’m proud of the result, and hope you’ll like it as well. Should have properly working JeeLinks in my hands in July, assuming Mr. Murphy doesn’t barge in to spoil the party.

More JeeNode v3 changes

In Hardware, News on Jun 22, 2009 at 00:01

Here are a few more details about the upcoming JeeNode v3 board.

First off, I said no more changes w.r.t. the pinout. Not true – the I2C/PWR pinout has also changed:

For a couple of reasons which I don’t want to go into just yet. The GND pin is now on the outside, just as on the FTDI header. Note that PWR is the incoming voltage, not the regulated 3.3V at which the ATmega operates (including those SDA / SCL pins).

The other change worth mentioning here, is that components have been rearranged slightly to make room for 2 pads to connect a battery or battery pack – along with holes for strain relief. Both leads are clearly marked “+” and “-” to avoid polarity mistakes.

The JeeNode is well suited for battery use due to it’s 3.3V design and because it has no on-board LEDs. The regulator lets you choose from a huge range of battery options (hence the soldering pads i.s.o. a fixed battery choice): 3x or 4x AAA or AA, NiMH or Alkaline, or one of the increasingly popular 3.6 .. 4.1 V Lithium batteries, which are great as long as you take care not to short-circuit them and not to discharge them beyond their advised limits.

So there you have it. The new JeeNode v3 board is just about ready to send off to manufacturing. I hope to get my hands on them early July.

More SMD stuff

In AVR, Hardware on Jun 21, 2009 at 00:01

My adventures in SMD miniaturization-land continue:

SOIC chips

Those are two Atmel chips – an ATtiny85 (SOIC-8) and an ATtiny84 (SOIC-14).

Compared to 0603 parts, these are actually quite large. The distance between the pins is 1.27mm (0.05″), half of regular through-hole parts.

But you do need fine tweezers, and a ZIF socket to flash them or try them out without soldering is also nice:

SOIC chips

The lid snaps down, making a firm connection with each of the 14 pins.

Hm, I see now that the SOIC-8 dimensions are a bit wider than the SOIC-14 package. So the smaller package doesn’t fit in this (pricey) ZIF socket.

So not only is this stuff small – it’s also easy to overlook such differences!

Fortunately there are datasheets.

JeeNode v3 pinout

In Hardware, News on Jun 20, 2009 at 00:01

There are two important pinout changes in the upcoming JeeNode v3:

On all four ports, pins 4 and 5 will be swapped (AIO and +3V)
Pins 1 and 2 of the SPI/ISP header will become pins 7 and 8

So the final pinout for ports is:

Preview of “jeenode-v3.graffle”.png

The change isn’t being made on a whim – I’ve got several things plugging into ports here which will need to be changed to work with the new pinout. And it will affect everything plugged in for years to come. One of the reasons for the change is that it lets you plug in a 3-wire servo (pins 3..5). Another reason is that it is compatible with the BBB board already out there (also pins 3..5).

As before, a 4-pin connector on pins 2..5 is often all you need. The outer two pins are for more advanced uses.

As before also, pin 1 carries the input voltage to power the board, and can be anything from 3.5V to 13V. With an FTDI connector it will usually +5V. Batteries work great, anything from a 9V block, or 3x AAA/AA (both NiMH and alkaline), or even a LiPo battery.

Note also a small change in pin names: the 3.3V regulated power supply is now called “+3V” instead of the somewhat ambiguous “VCC”, and the interrupt line is called “IRQ” instead (was INT).

Every future JeeNode design will use this pinout on every port.

The new SPI/ISP header is (pin 1 at top left):

This is an “extended” ISP header. The main reason for this change is that pins 1..6 are now compatible with a standard 6-pin in-system programming connector, through which the ATmega’s fuses, flash, and EEPROM can be programmed. Note that the JeeNode is a 3.3V device, it should not be driven by an ISP programmer set to 5V voltage level.

The two extra pins are tied to digital I/O lines B0 and B1, and allow connecting more SPI devices to the JeeNode. Note that SPI is used internally by the RFM12B radio module, so these pins should not be re-configured for other purposes, although you could use SEL0 and SEL1 as general-purpose I/O lines if you want – a LED and a push-button switch perhaps.

I’ve made a few experimental add-ons using the SPI/ISP connector, such as this one. They will need to be adjusted for v3, but as with ports the same new pinout will be used for all future JeeNodes and derivatives from now on. Although some of them might not have such a connector at all.

That’s it – no more changes. Now I can “standardize” everything I want to connect to the JeeNode ports!

Don't sneeze

In Hardware on Jun 18, 2009 at 00:01

Ok, so this is what 0603 SMT parts look like:

Don't sneeze

That’s a 0.1 µF capacitor and a 10 kΩ resistor.

Trouble is, they are small …

Don't sneeze

The “0603” part designation for SMD’s stands for 0.06″ x 0.03″ (roughly), which is 1.6 x 0.8 mm. Here’s a good overview, from that same SMT page on Wikipedia:

Well, it sure is something new for me to try out such miniature components!

Fortunately, that’s as small as it gets (I’ll leave 0402 components to the industrial parts-placement machines). Other capacitors (3216), voltage regulators (SOT23), and microcontrollers (SOIC) are all a bit larger.

Prototyping with JeeNodes

In AVR, Hardware on Jun 16, 2009 at 00:01

Here’s a little board I used for a while with a JeeNode:

Pulse prototype

It has 6 female header underneath, which get plugged into a JeeNode with its header pins sticking upwards. It has an LDR, a diode I tried to use as voltage reference, a plugged-in SHT11 temperature / humidity sensor, a 3-pin connector to plug in a Parallax PIR sensor, and a 2-pin header (top right, behind the SHT11) which was used to connect a couple of 1-wire temperature sensors).

There are a couple of issues with this, though some are probably unavoidable for such one-off / ad-hoc solutions. For one: it’s a bit of a mess. One reason is that with this setup the 1-sided perf-board I used has to be mounted upside down to allow soldering in the female headers. That’s awkward, because it means you have to “surface mount” most components.

One option is to use perf-boards with plated-through holes. These are several times more expensive than single-sided boards, though. But more importantly, cheap one-sided boards are often based on “Pertinax” (SRBP) which is a lot easier to handle than FR-4 epoxy: you can simply break them on a sharp edge, with the row of holes acting as perforation.

The other problem with putting everything on a single board is reduced flexibility. In this case I had to add a second 4-pin female header on top to accommodate the SHT11 plug I had already made – which would have fitted just as well directly on the JeeNode.

One nice benefit of per-port prototyping is that it is easy to re-use this stuff in different configurations. In fact, as with the SHT11 plug showing in the picture, that’s precisely what happened.

So I’ve been thinking a bit about ways to use JeeNodes for experimentation. Which happens a lot around here. One simplifying convention is to always use male headers on the JeeNode. That leaves essentially two choices (ignoring sideways mounting for now):

Picture 1.png

I’m thinking of having a bunch of, ehm, “JeePlugs” made: tiny boards with a 6×8 “prototype” area containing plated-through holes, plus a 6-pin female header and connecting pads. Three ways to use these:

Picture 2.png

You’ll need male headers for use with a breadboard, but I’m assuming you’ve used the breadboard to figure out the connections with the bare parts, so this post focuses on using female headers for the JeePlugs.

In all cases, the orientation of the pins is the same, so once you have a plug set up with stuff on it, you could still use it in multiple ways. And plug them onto any of the 4 ports at will, of course.

One last refinement is to make these plugs around 20 x 25 mm – i.e. long enough to optionally plug onto two ports in that inverted 3rd example shown above. Here’s a first design:

Picture 3.png

It’s really not much more than a tiny perf-board of the proper size for JeeNodes with a couple of doubled-up connections. Using plated-through holes so components and wires can easily be soldered from either side.

The plugs are not labeled with pin numbers or signal names, because those depend on the orientation in which you use them. For that, use the markings on the JeeNode itself (starting with v3, that is).

These JeePlugs only makes sense in larger quantities, so I haven’t yet decided whether I really want to order them. I sure could use some, but it wouldn’t be practical to have less than a hundred or so of them produced.

Sensors, Reflow

Reflow experimentation

In Hardware on Jun 15, 2009 at 00:01

Got this little skillet/grill thing recently:

Heating plate

Quite a convenient size (and it can be stored upright) – the usable area is around 25 cm diagonal. It’s also relatively weak at 700 Watt, but since it’s so small it still easily reaches the solder melting point within a few minutes (with the lid closed).

I’ll be experimenting with this thing for SMD reflow soldering. Will need to measure and control the temperature (an NTC resistor rated for 300° no doubt, but I don’t know which type yet).

If the heat collection in these plates makes the thing too slow to control properly, I could take the plates out and use some sort of grid instead:

Heating plate

Note the heat sensor in the middle, triggering a thermostatic switch.

Ideally – of course – I’d want to control this thing with a JeeNode, but I’m not willing to spend very much time on that right now. We’ll see. First thing will be to measure the temperature ramp-up/-down behavior of this thing, with the lid open and closed.

If this works, it’s a pretty good deal for €19.95 !

New JeeNode v3 design

In AVR, Hardware on Jun 14, 2009 at 00:01

Here’s an – improved! – board design for the JeeNode:

Picture 1.png

The main two changes are: labeling of all the components and pins, and a change in the ISP/SPI pin header (pin 1 is now also pin 1 for ISP). All connectors are in exactly the same place, but the board is a tiny fraction wider.

For details, see the EAGLE files (jee-pcb-011.sch and jee-pcb-011.brd). The PDF of the schematic shows that the functionality is unchanged – other than the ISP/SPI header pinout change, this board should be 100% compatible with the JeeNode v2.

The v3 board was designed in collaboration with Paul Badger of Modern Device, to whom I’m most grateful.

I’ve just ordered a batch of these boards. Should be able to report here in ten days or so as to whether they are working properly. Let’s hope so!

JeeBot, Sensors

Bad things happen

In Hardware on Jun 13, 2009 at 00:01

Looks like one of the sensors broke:

Broken sensor

That’s an IMU (Inertial Measurement Unit) with a dual accelerometer and a gyroscope. The gyro is the “big” one on the right. It senses rotation around the Z axis perpendicular to the board. The accelerometers are working fine, but the gyro appears to be toast. No matter what I try, it produces a noisy but fixed analog voltage. Connecting either of the self-test pins doesn’t doing anything.

Ouch, the gyro is also the most expensive part (in the €25..50 range). And this was a rather nice and sensitive one. Oh, well…

(that’s an Arduino with a battery pack by LiquidWare underneath, btw – so I can move this thing around and hook up the scope without having to attach power)

Ancient technology

In Hardware on Jun 12, 2009 at 00:01

This is fun. For one of my numerous projects, I wanted to resurrect a 15 year old LaserPrinter which has been gathering dust for a while:

Ancient technology

A “state of the art” 600 DPI PostScript laser printer for the Mac. With a whopping 6 MB RAM and LocalTalk / RS-232 / Parallel interfaces. Those were the days.

Plugging it in and running a self-test from the menu was all it took:

Ancient technology

As you can perhaps guess from the Dutch report in the bottom left, it has printed a mere 8050 pages in its lifetime so far.

Yeah. Back then, they knew how to make things. You just turn it on and it works. That toner cartridge must be at least 10-years old, btw!

Got some ideas about hooking up a JeeNode to this thing, probably via the serial port. The printer draws a lot of power and does not really have a standby mode, so the RFM12B could be used to control a remote KAKU power switch, for example. We’ll see…

JeeNode v2 kit notes

In AVR, Hardware on Jun 11, 2009 at 00:01

Just to make sure I didn’t forget anything – here’s the contents of a JeeNode v2 kit with parts:

JeeNode kit contents

For those of you who are about to receive the kits: they should match what’s shown above. If I forgot anything please let me know and I’ll take care of it right away.

The ATmega168 is pre-flashed with the standard Arduino boot loader and the RF12demo sketch.

As for assembling these kits, the main thing to keep in mind is the orientation of a few components and the ways things should be hooked up – see the recent post and the reference doc and close-ups on this site such as this one:

JeeNode v2

These are first-generation boards without silkscreen (I’m still learning about all this PCB design stuff!), although there are tiny markings on the top copper layer if you look really closely.

One important detail I forgot about is the antenna: for these 868 MHz units, I use a piece of 85 mm insulated wire. It needs to be connected to the ANT pin, which is the one in the corner as you can see in the above picture. You need an antenna, I’ve not been able to bridge even the shortest distance without one.

Building the JeeNode

In AVR, Hardware on Jun 9, 2009 at 00:01

Now that a few people have started building JeeNodes for themselves, here’s a close-up:

MCP1702 detail

Make sure you put that MCP1702 voltage regulator in exactly as shown. That’s the TO-92 package in the middle.

The board was intially designed for an LP2950, which has a different pinout. The MCP1702 does not have ground in the middle, hence the twisted positioning.

Note also how I use flat 6-pin headers, even for the FTDI connector. All the header pads are large enough to solder them on in any orientation you like.

FWIW, I’ve still got 9 JeeNode boards left (and probably all the parts needed as well). So if you want ’em let me know. I can send bare PCBs for €5 each. Or the PCB with all parts including 868 MHz radio and pre-flashed ATmega168 for €17.50. Shipping included if you order more than one.

JeeBot Duo schematic

In AVR, Hardware on Jun 8, 2009 at 00:01

Heh – my most “sophisticated” robot so far. Here’s the plan for the electrical hookup of the JeeBot Duo:

Picture 1.png

There’s quite a bit of functionality in there, all the way to an on-board LiPo battery charger. Other things to note: the Baby Orangutan controller (BOC) can shutdown all power (to avoid running down the battery too far) and the JeeNode can reset the BOC if need be.

The two processors communicate with each other via an I2C bus. The on-board FTDI header connects to the BOC serial port and supplies power to the LiPo charger. The FTDI header on the JeeNode can be used for monitoring, control, and uploading, as usual.

JeeBot Duo – in progress

In AVR, Hardware on Jun 7, 2009 at 00:01

To continue this bot-craze, here’s another design, the JeeBot Duo …

More JeeBots in progress

This design is considerably more advanced. From left to right:

two 50:1 micro motors with wheels and encoders (Pololu)
a 6-pin FTDI header
the Baby Orangutan 328 motor controller (Pololu)
underneath: a low-voltage boost regulator (Pololu)
at a 45° angle: IMU board with 2-axis accelerometer and gyro (SparkFun)
a JeeNode v2 with on-board RFM12B 868 MHz radio module
underneath: a 860 mAh LiPo battery

It’s called a JeeBot Duo because there are two processors on board. The plan is to put the self-balancing smarts in the Baby Orangutan – which has all the hardware needed to connect to all sensors and motors. The JeeNode is available for telemetry, remote control, and perhaps to connect to further gimmicks later on.

Initial tests show that the motors have plenty of speed and torque, and draw 40 .. 300 mA each, depending on load. The boost regulator can produce a constant 5.4 V for the motors, while the battery level gradually decreases. There’s a tiny bit of slack in the gears, which translates to about 1 mm of slack/travel on the wheels.

The remaining space is for a compass module and an on-off switch. That makes this a relatively complete autonomous unit, able to sense its vertical position and change, as well as the distance traveled and the compass heading. With the proper software, it should one day be able to respond to commands such as “go 2 meter north”, or “drive around in a 1-meter circle”.

But that’s a long way off. Lots of tuning and software development will be needed to get there…

JeeBot Mini – in progress

In AVR, Hardware on Jun 6, 2009 at 00:01

Here’s a second design, called the JeeBot Mini – no less:

More JeeBots in progress

The first JeeBot used servo’s but that’s not really such a great fit for self-balancing. This one uses miniature (and pretty weak) motors, directly driven by the ATmega’s I/O pins. The small socket is for the same Memsic 2125 accelerometer as on the original JeeBot, but placed at a 45° angle to use both X and Y axis together.

On the right is a tiny 100 mAh LiPo battery – plenty for simple trials. No gyro, no regulator, and no resonator (so far). No JeeNode either – just a serial FTDI interface and a bare ATmega168 chip running the LilyPad bootstrap @ 8 Mhz, straight off 3.7 V from the battery.

I’m waiting for some wheels for this thing. Am not sure the wheels will turn fast enough to regain balance once detected. If not, maybe raising the center of gravity by extending the “chassis” upwards will help. Or bigger wheels. Or both. Or maybe the design choices are hopelessly wrong already… we’ll see.

Minimal motion

In AVR, Hardware on Jun 3, 2009 at 00:01

Now that I’ve been bitten by the robot bug, it’s hard to stop. Wanted to experiment with a minimal setup for self-balancing:

Minimal motion

These are 1.5 .. 3V motors with 1:96 gears from Conrad. What’s special about these is that they only need some 20..30 mA current, which is sort of within the direct-drive capability of an ATmega168. That means 2 I/O pins per motor can be used to create an H-bridge without any further electronics.

Here’s a small sketch to drive these from a JeeNode:

Picture 1.png

A couple of details show that this really is pushing the limit: without the capacitors, timing becomes erratic. Also, the delays between reversals seems to be needed to bring the motors to a stop. I suspect that there’s still some very bad stuff happening due to inductive kickback, so diodes to ground and VCC are probably required to avoid damaging the MPU chip.

But it does run. It’s all driven off a tiny 100 mAh LiPo battery in that picture above, and it kept going longer on a charge than I was willing to wait for. Probably over an hour – total power draw is in the 50 .. 60 mA range.

Anyway, this is even more spielerei than the JeeBot. Just wanted to find out whether these components might be used for a little baby balancer one day. This would also require wheels and at least an accelerometer.

Vertical JeeBot

In AVR, Hardware on Jun 2, 2009 at 00:01

Here’s a first example of the JeeBot standing upright:

Vertical JeeBot

When held upright on startup, it actually stands on it’s own two wheels very calmly, compensating immediately for slight imbalances for a couple of seconds. But beyond a minor error, it fails to regain its balance – so my hands are right outside the picture, ready to catch it :)

Have added a Memsic 2125 accelerometer to provide a sense of what’s up. It’s connected to port 1, with the X and Y axes each producing pulses at around 100 Hz. The gyro kicks in when it’s falling either way. Having both near the center of gravity helps, as the counter force of the servo won’t disturb the accelerometer as much.

Here’s the main code. It has a crude low-pass filter and PID control loop:

Picture 1.png

The parameters were set using (much) trial and (much) error. I’ll clearly need to learn more about PID control to make this thing properly self-balancing. The loop runs 49 times per second on average, which also happens to be the servo pulse rate – maybe there’s some accidental interaction with the SoftwareServo library.

But still, a lot better than I had expected after one day!

Horizontal JeeBot

In AVR, Hardware on Jun 1, 2009 at 00:01

The JeeBot has made its first explorations, using a Nunchuk controller:

JeeBot baby steps

It drives on two wheels plus a coaster ball to support the batteries – although not very fast and veering slightly to the right. It will also turn, by rotating the servos in opposite directions. The batteries push down hard on the coaster ball, making the wheels slip when turning if the surface is not hard enough. The control mechanism is somewhat proportional, although it seems to work best by just pushing the joystick to its limits.

Here’s the current primitive control loop:

Picture 1.png

Some more close-ups:

JeeBot baby steps

From left to right: the Wii adapter, batteries with coaster ball underneath, on-off switch, JeeNode, and the edge of the servos.

Not much wiring needed to get it going:

JeeBot baby steps

The two resistors divide the battery voltage in half, so it can be measured by an ADC pin. Note the use of wire to “bundle up” the Nunchuk I2C “bus”.

Port layout so far: 1 = unused, 2 = left servo + battery level, 3 = right servo, 4 = Nunchuk via I2C.

I’ve also mounted the gyroscope (not connected yet) in the proper orientation to sense rotations around the wheel axis:

JeeBot baby steps

Will need to add an accelerometer as well, no doubt.

The center of gravity is just about on the power-switch, between the battery pack and the JeeNode. Which is quite low when this thing is placed upright, not sure the servos + control loop will respond fast / accurately enough for balancing.

Current consumption is around 30 mA when idle, 160 mA with wheels turning freely, and up to some 300 mA under load – these 4 NiMH batteries give about 5.2V under no load when full, but I’ve seen it drop to 3.7 V under load after a bit of use – not so good…

Seeing sharp

In Hardware on May 31, 2009 at 00:01

Here’s a fun gimmick from DealExtreme:

Seeing sharp

It won’t make you look sharp, but these glasses are pretty effective. There’s a built-in white LED with battery (that’s the big black case) which isn’t that great, but it comes with three plastic lenses of varying strength.

Really works well, even if not quite for a neurosurgeon ;)

This’ll be great for some SMD stuff I’d like to explore.

Yet more AVR size comparisons

In AVR, Hardware on May 30, 2009 at 00:01

Ok, let’s finish off what I started yesterday – here are yet more tiny AVR boards:

Another AVR board line-up

From left to right:

JeeNode v2 – ATmega168/328, FTDI, wireless
Strobit – ATmega168V, FTDI, wireless
RBBB – ATmega168/328, FTDI, 5V power
iDuino – ATmega168/328, USB
Dorkboard – ATmega168/328, 5-pin FTDI’ish
Arduino Nano – ATmega168 , USB
Arduino Pro Mini – AtMega168, FTDI
Arduino Mini – Atmega168, 5-pin FTDI’ish

Here is the previous line-up again for comparison:

More AVR size comparisons

See yesterday’s page for a description of what is what.

If you look closely, you’ll see that yesterday I used a JeeNode v1 board.

Update – same photos, higher resolution: first, second.

More AVR size comparisons

In AVR, Hardware on May 29, 2009 at 00:01

Here’s another comparison of little AVR-based boards:

More AVR size comparisons

From left to right:

JeeNode – ATmega168/328, FTDI, wireless
Boarduino – ATmega168/328, USB
Stickduino – ATmega168, USB stick
Teensy++ – AT90USB646, on-chip USB
Teensy – AT90USB162, on-chip USB
Baby Orangutan – ATmega328, motor drivers

Unfortunately, I forgot to show the RBBB (Real Bare Bones Board), and the new Strobit unit (also shown here) – they both deserve a place in this line-up.

These little boards are not entirely equivalent, but all of them are great for AVR-based fun DIY projects.

Measuring the AC line frequency

In AVR, Hardware on May 28, 2009 at 00:01

There is an interesting site in the UK called Dynamic Demand. The idea is to let the 50 Hz power-line frequency vary slightly to indicate the current load of the entire grid. Simple line-monitors can then track this locally and respond by voluntarily shutting down some power consumers (i.e. turning off freezers, A/C units, or electric heaters for a little while). With a bit of collaboration, the grid would then presumably recover as the load eases off – and overcome these demand peaks. I love the idea, it’s so beautifully simple.

The Dynamic Demand site also has a page showing the current frequency online, here’s a snapshot:

Picture 2.png

I don’t think this mechanism is being used – or even considered? – in the Netherlands but I couldn’t resist setting up a JeeNode to monitor the frequency myself. The sketch:

Picture 3.png

What it does is measure elapsed microseconds between 100 transitions of its input signal against the 1.1V bandgap reference voltage. That’s 50 ups and 50 downs, which should take 1 second.

The AIO pin of port 1 is connected to a rectified but unregulated AC voltage, coming from a 17 VAC power brick through a diode plus 1:10 voltage divider. The signal looks as follows:

And here’s some sample output:

Picture 1.png

Note that for stable and repeatable results, the JeeNode will need to be fitted with a crystal as clock.

The accumulation over 100 transitions is a simple way to average all the pulse durations. Most of the code then tries to present a nice result, with sufficient accuracy to display minor variations.

Nice and tidy.

Meet the JeeBot

In AVR, Hardware on May 27, 2009 at 00:01

Here’s a fun new project, the JeeBot:

Meet the JeeBot

A little platform with two continuous-rotation servos, a JeeNode, and a (4x AA) battery pack. It’s all mounted and fixed together with what I had lying around: strong epoxy-based perf-board and lots of fasteners.

The electronics isn’t “quite finished” as you can see:

Meet the JeeBot

The JeeNode can be removed. There’s a small slide switch on the side to turn on power.

First task would be to get this thing rolling and steering – adding a small coaster of some sort on the right side under the batteries, to keep this thing off the floor.

The more ambitious plan is to make this thing stand upright and self-balance… who knows, one day, maybe it’ll be able to walk roll on two feet wheels?

RF size comparison

In AVR, Hardware on May 26, 2009 at 00:01

Here are four very similar wireless AVR-powered solutions side-by-side:

RF size comparison

From left to right:

Arduino Duemilanove with XBee shield (ATmega168/328) – 2.4GHz
JeeNode with RFM12B (ATmega168/328) – 433/868/915 MHz
Strobit board with RFM12B (ATmega168V) – 433/868/915 MHz
Busware CPM with CC1101 (ATtiny84) – 868 MHz

The XBee has more software on board, giving it more functionality. The CPM module, which is only marginally bigger than a DIL-14 chip – including antenna! – does not come with software loaded AFAIK, but there is open source software available for it. The middle two boards are compatible with Arduino IDE “sketches” and support the RF12 driver library by yours truly.

JeeBot, Sensors

Gyro sensor

In AVR, Hardware, Software on May 25, 2009 at 00:01

Here’s the LISY300AL gyro sensor, mounted on a Sparkfun breakout board:

Gyro sensor

The sensor is not extremely sensitive, but works at 3.3 V. It has a single analog output, so readout is trivial:

Picture 1.png

Sample output:

Picture 2.png

The readout changes as this setup is rotated around the horizontal plane. Looks like the self-test (pin 5) to ground can be omitted, btw.

One (tiny!) step closer to a self-balancing bot…

Update – the Segwii website is a fantastic resource on how to accomplish self-balancing in a fairly similar setup.

JeeBot, JeeNode, Sensors

Servo fun

In AVR, Hardware on May 24, 2009 at 00:01

Here’s some fun with a servo:

Servo fun

A slider drives the two servos in opposite directions, so you can make this thing turn on the spot.

Here’s the sketch:

Picture 1.png

Had to use SoftwareServo instead of the Servo library which comes with Arduino IDE 0015 – which didn’t work for me.

Turns out that only pulses from 1.4 to 1.6 msec actually have any effect on the speed of the servos, the rest of the 1.0 .. 2.0 msec range just makes them run at full speed. These ara Parallax (Futaba) Continuous Rotation Servos.

Note that the servos are driven from the PWR line, i.e. the full 5V – but the servo pulses are 3.3V, like the rest of the JeeNode.

It’d be nice to use a Wii Nunchuk controller as input. Even more fun would be an accelerometer / gyro combo to turn this thing into a self-balancing bot …

Strobit boards

In AVR, Hardware on May 22, 2009 at 00:01

Stephen Eaton, the guy behind Strobit, very generously sent me two of his boards and prototype boards:

Strobit boards

These units run at 3.3V by powering them off a corresponding USB interface, such as the boards from Modern Device and SparkFun. And it’s fully compatible with the RF12 driver and the RF12demo sketch – I’ve run a successful test with it. This particular unit has no crystal, so it’s running off its internal 8 MHz RC clock. Works fine, just treat it as an Arduino LilyPad in the IDE.

As you can probably see these well-designed boards are slightly shorter and wider than a JeeNode. Very neat to see the SMD stuff on there – clearly lots of room left. Note that the board doesn’t have a voltage regulator – it’s intended to run straight off a CR123 battery, for which connections exist on the back.

A really neat trick is that the holes for the header pins are slightly staggered. This means that when you push in a header, it fits snugly even before soldering – a huge convenience, considering how soldering those headers is always a bit tricky on the JeeNode, especially with 4-pin headers.

Lots of attention to detail, such as the silkscreen text where you can mark which frequency band module has been used. And two (pretty bright) red leds.

Another neat feature is the prototype board (“shield” in DuinoSpeak):

Strobit boards

Lots of room for some custom stuff. Room for 4 through-hole LEDs + resistors, a reset button, and an ISP connector. This could also be used to mount a LDO voltage regulator. Given that the Strobit board itself is so flat, I’m inclined to place this shield underneath to keep total height to a minimum – but that’s just me, and would not be optimal while trying out stuff.

Anyway: congratulations, Stephen – I’ll report further when I get to do more with these units.

JeeNode Pulse revisited

In AVR, Hardware on May 21, 2009 at 00:01

The JeeNode Pulse hasn’t fully materialized yet – it’s the configuration I’d like to use around the house. Here’s a new configuration:

Pulse revisited

PIR and LDR on port 1, BMP085 on port 2, and SHT11 on port 3. There’s obviously no point in having a BMP085 sensor in more than one node, but for now it’s easy to leave it in for testing.

Different PIR sensor (from ELV). That sensor draws 30..40 µA – this matters for battery-operated use because it’ll be permanently on.

Here’s the main part of a first sketch, using the new power-down logic:

Picture 3.png

The code compiles to around 9 Kb. This includes floating point calculations in the SHT11 driver and the serial port reporting, both of which could be jettisoned later.

Sample output:

Picture 4.png

The values are:

temperature x10, from BMP085
barometric pressure x100, from BMP085
relative humidity, from SHT11
temperature, from SHT11
motion detect, from PIR (1 = no motion)
light level, from LDR (high means dark)
the number of milliseconds spent measuring

That last value is way too high for battery use – this code is spending 0.316 seconds collecting sensor data… in high power mode!

Breaking down the time spent, it looks like the BMP085 takes 2x 7 ms, and the SHT11 takes 2x 70 ms. The odd thing is that the SHT11 seems to take 300 ms when taking both temperature and humidity readings.

The good news is that the power-down current consumption of this setup is around 40 µA.

What needs to be done, is to spend the waiting time in these sensor read-out periods in power-down mode as well. The BMP085 driver already supports low-power readout by splitting the start and end parts of the driver, so that the waiting time can be handled in the calling loop. The SHT11 driver will needs to be adjusted to allow a similar approach.

With a bit of luck, only a millisecond or two will have to be spent in high-power (10 mA, haha!) mode. Then perhaps 2..3 milliseconds with the RFM12B radio active, and that should be it.

With a 15..60 second reporting period, the node would stay almost entirely in power-down mode. An average power consumption of under 100 µA total should be feasible – giving well over a year of service on 3 standard AAA batteries.

But that’s not all. To effectively use the PIR module, the code must be set up to handle motion-detect triggers at any time, also in power down mode. One approach would be to wake up (i.e. use a pin change interrupt), note the change and power back down. A refinement would be to “preempt” and start transmitting right away when motion is first detected – and then re-schedule future transmissions so the average reporting period remains the same. This makes the central JeeHub aware instantly of motion detected by the various nodes.

JeeHub, JeeMon, JeeNode

Parallel WSN choices

In Hardware on May 20, 2009 at 00:01

Just came across the eKo range of commercial products by Crossbow. Interesting how the eKo and Jee-Node/-Hub/-Mon designs almost exactly overlap – well, seen from a large distance anyway.

Their “JeeNode”:

Picture 2.png

Their “JeeHub”:

Picture 3.png

Their Linux server hardware and software:

Picture 4.png

Of course the eKo products are a million times more mature and advanced than the Jee-stuff which isn’t even a product, but still…

Future JeeNodes – thoughts

In AVR, Hardware on May 19, 2009 at 00:01

After several months tinkering with the JeeNode v2 boards, I’m starting to make a list of things I’d like to change for a future design.

What I’d like to keep:

having 4 identical “ports”, both physical and in software
running at 3.3 V, with on-board regulator
the wireless radio module :)

What I’d like to change:

switch to SMD to create a smaller unit
add a PCB antenna, even though it’s frequency band specific
add mounting holes

This could perhaps become the layout:

Picture 1.png

Not 100% sure about the SPI/ISP and I2C/PWR pin headers – though I’m inclined to keep them, somehow.

No idea when or even whether this ever materializes, just some thoughts.

Better PCB auto-routing

In Hardware on May 17, 2009 at 00:01

While surfing around on the web, I came across the FreeRouting website. It lets you grab a Java app which does auto-routing. It takes time, but it is quite advanced.

One feature really caught my attention: the ability to take an EAGLE .brd file, auto-route (or just optimize) it, and then bring the results back into EAGLE. It’s all documented here.

Here’s what it did to the JeeNode v2 design (jee-pcb-003.brd), which was routed 100% by EAGLE (after quite a bit of tweaking to make it succeed).

Before:

Picture 1.png

After:

Picture 2.png

(there are some discrepancies between the two, due to some hidden ground planes)

I haven’t checked it much, nor applied any DRC’s, but if it’s all correct then that’s 9 via’s instead of 26 – not to mention the considerably simpler traces. Impressive!

Power consumption – more savings

In AVR, Hardware, Software on May 16, 2009 at 00:01

Let’s get that JeeNode power consumption down …

The no-savings baseline from two days back was 10 mA, with a few simple measures getting it down to 1.31 mA, i.e. waiting in idle mode with the pre-scaler set to 64 and turning the RFM12B clock off.

It turns out that the ATmega328 is quite a bit more power efficient in that mode, the same sketch consumes 0.67 mA, i.e. half that of an ATmega168. Great – that’s an easy gain. Unfortunately it doesn’t carry over as much to power down mode: 125 µA versus 137 µA. There is still some unexplained power use there – maybe some of the circuits need to be turned off explicitly, or some more output pins floated.

Anyway, the next idea to go beyond 1.31 mA is to use the watchdog timer for idling away in power down mode. The basic code structure will be as follows:

Picture 1.png

Ooh, wait – turns out that there is a simpler way, which doesn’t require changing the main application logic after all. We can let the watchdog generate an interrupt without resetting the system. Here’s the code I ended up with after some experimentation:

Picture 2.png

Note the added dummy watchdog interrupt routine. Without it, the code apparently enters a nasty infinite loop when the watchdog fires, which is hard to get out of – even after a hardware reset.

Usage: 139 µA while waiting – 99% of the time. Great.

The code can actually be streamlined a bit – simply leave the watchdog running to pull the processor out of power down mode once a second:

Picture 4.png

But there’s more. The ADC can be disabled to reduce the power drain even further:

Picture 5.png

Now usage drops to 24 µA while waiting. Cool.

One last change is to disable the brown-out detection, which in turn disables the internal voltage reference. Changing the high fuse from 0xDD to 0xDF drops total power usage to a diminutive 6.8 µA. Perfect.

So there you have it – 1500 times less power usage!

Update – see the discussion in this post for a change which gets this down to 3.7 µA …

Update 2 – changed the low fuse from 0xFF to 0xEE, i.e. 64 µs start-up i.s.o. 1+64 ms (ok for resonator, not ok for a crystal). This will help get the power up duration down once I start looking into it.

Power consumption

In AVR, Hardware on May 13, 2009 at 00:01

This contraption:

Measuring power draw

… when connected as follows:

Measuring power draw

… makes it easy to measure the supply current, with a BMP085 pressure sensor hooked up in this case:

Measuring power draw

Just under 10 milliamps, as you can see. That’s just the JeeNode running the BMP085 demo at 16 MHz, sending a new reading over the serial port every second. The RF12 module has not been turned on.

If the JeeNode is to be used for a WSN, then it will have to get its power consumption down. Way down, in fact…

Bubba JeeMon back up

In Hardware, Software on May 12, 2009 at 00:01

The title of this post can be interpreted in two ways, both accurate: 1) the Bubba Two NAS from Excito was my back-up server for the MMnet1001 module, and 2) that Bubba box is now my main JeeMon server and back in the air with all the electricity / gas / weather monitoring working again, as well as the Pachube and Bwired feeds.

I will probably stick to the Bubba from now on. It’s running Debian Etch Linux, and there’s a JeeMon runtime for it so the switch-over was trivial.

bubba-two.jpg.jpeg

This NAS box consumes about 4 watt, which is less than the specs because it has been modded to use a 2.5″ SATA disk instead of the standard 3.5″ ones they normally ship. It’s also a 300+ Gb file server which has been running various periodic tasks for almost a year now. There’s in fact much more disk storage in the form of 3 additional USB disks, but these are normally powered down (via a KAKU switch).

Something happened …

In AVR, Hardware on May 11, 2009 at 00:01

The electricity / gas metering monitor – which has been running for months – stopped working:

Picture 1.png

It just flat-lined, dead, nada. Power cycling everything and re-flashing the meter node did not fix it. I don’t see any packets from the meter node on the air when listening via an independent JeeNode.

The only packets right now are from a JeeNode pulse upstairs, which keeps resending – indicating that the central JeeHub isn’t replying with an ack. Weird.

I’ve adjusted all nodes to explicitly use netgroup 0x50, since there have been changes to the RF12 default netgroup and CRC calculation. Just to rule out a potential issue.

Still no go. I’m flabbergasted.

Update – uh, oh… the JeeHub 3.3V regulator is way too hot. It’s shutting down from time to time. Not good!

Time to switch to plan B – a JeeNode used as packet receiver connected to my “Bubba II” NAS. It’s been running all the time to collect weather data from the KS300 anyway. Still no electricity / gas metering data coming in, but at least all the remaining JeeNode and KS300/FS20 data gets logged again.

Update 2 – first there was one problem (JeeHub failing), then I created another one by re-flashing the metering JeeNode with the wrong node ID – doh! Anyway, metering data is coming in again now. Still don’t know why / how the JeeHub broke, but it was up for a hardware revision anyway…

Teensies

In AVR, Hardware on May 8, 2009 at 00:01

The “Teensy” by PJRC is a tiny AVR processor with embedded USB device port:

Teensy

It’s similar but not quite identical to an ATmega168 Arduino (no analog inputs, no I2C, and some other diffs). But the basics are the same, and you can even adapt the Arduino IDE to feed it sketches.

Now there’s a “Teensy++” with 64 Kb flash, 4 Kb RAM / EEPROM, and analog inputs and I2C:

Teensy++

Plenty of oomph for much larger applications!

It’s still not quite what I’m after though, since these operate at 5V (although the Teensy++ can be made to run at 3.3V that only works when not tied to a USB port). I’ve all but abandoned 5V logic, because the RFM12B wireless modules require < 3.8V to operate and because battery power is simpler when in the 3 .. 4.5 V range.

Still, these look like nice little boards, and at a good price.

RFM12 vs RFM12B – revisited

In AVR, Hardware on May 6, 2009 at 00:01

Now that the RFM12 is working, here’s the list of differences between RFM12 and RFM12B I’ve come across:

The RFM12 works up to 5V, the RFM12B only up to 3.8V (but it won’t be damaged by 5V).
The RFM12 needs a pull-up resistor of 10..100 KΩ on the FSK/DATA/nFFS pin, the RFM12B doesn’t.
The RFM12 can only sync on the hex “2DD4” 2-byte pattern, the RFM12B can sync on any value for the second byte, not just D4.

More differences, found by Reinhard Max:

The B version can be set to a single sync byte.
The “PLL setting command” (CCxx), which only exists on the RFM12B.
Different values for RX sensitivity and TX output power.
A slightly different formula to calculate the time of the Wake-Up Timer.

Here is the back of the module, RFM12 on the left, RFM12B on the right:

RFM12 vs RFM12B

(these also happen to be for different frequency bands, as you can see)

And here is the front view, with RFM12 on the right and RFM12B on the left this time:

RFM12 vs RFM12B

The RFM12 unit on the right has a pull-up resistor added on top – note also the exposed pads at the top.

Note how the alignment of the solder pads on the JeeNode PCB is a bit off – these are v1 PCB’s, the v2 PCB’s have better alignment.

JeeHub Lite

In AVR, Hardware on May 4, 2009 at 00:01

The current JeeHub includes a MMnet1001 Linux module, which is great for running JeeMon. But for an even more basic always-on system, it’s possible to forego the Linux part – here’s the idea:

The whole thing is powered from USB, which must remain on permanently. There is no need for the attached computer to be on all the time, because incoming data can be saved into the on-board DataFlash memory. Depending on data volume and memory size, it ought to be possible to have a few days of autonomy.

The 433 and 868 MHz OOK receivers make this thing suitable for receiving weather data from off-the-shelf components, as well as responding to KAKU and FS20 remotes (and others like them). And since the RFM12B is so versatile, it can also send out 433 and 868 MHz OOK commands to those systems.

One thing I forgot to add in the above diagram, is a DCF77 receiver – or perhaps using a crystal or RTC. As has been mentioned a few times, the JeeHub needs to have a fairly accurate sense of time to do its main job of collecting real-time readings.

Only a minimal number of signals/ports are needed for the main tasks, there are several pins left to connect a few extra sensors.

The main bottleneck will probably be the amount of code needed to make such a JeeHub Lite perform basic home automation tasks. An Atmega328 might help a bit.

The normal monitoring and reporting work is still done with JeeMon, but now running on the attached PC (which can be Windows, Mac OS X, Linux, whatever). In such a configuration JeeMon must catch-up and extract saved data from the DataFlash in the JeeNode whenever it is launched.

JeeNode in a bottle

In AVR, Hardware on May 3, 2009 at 00:01

When you have a hammer, everything looks like a nail. Or in my case, a potential enclosure for JeeNodes:

JeeNode in a bottle

This adjustable enclosure came with some small relays shipped to me a while back.

Now if only I could figure out a way to make JeeNodes run a while on these batteries:

3.7 V @ 100 mAh Lithium

That’s a 3.7 V @ 100 mAh Lithium cell. Three months endurance would be the minimum needed to make this practical, that’s about 40 µA average power draw (the RFM12B draws 30 µA in sleep mode, though that could be lowered tenfold by connecting it to a switchable regulator such as the LP3985). Hm, might actually be feasible.

Soldering station? Nyet!

In Hardware on May 2, 2009 at 00:01

Got myself a new soldering station a few weeks ago:

soldering station

The intention was to replace my old (but analog temperature-controlled) 15W weller, which is a bit weak. This unit is 45W and shows when the iron is ready.

Unfortunately, it broke down after a just a few times… I suspect that the heating coil is blown: the temperature stays at 25°C no matter what. Bummer.

Oh well, that should teach me to know buy dirt cheap bargains – this thing was just €29 – and now I’m stuck with a heavy piece junk plastic. I’m not tempted to replace the iron, it’d probably break again quickly. Maybe I can at least salvage the 24V @ 2A transformer in there. Two of those would make a nice isolation transformer, nice to have for experimenting with 220V AC power control and sensing.

Receiving and decoding FS20

In Hardware on Apr 30, 2009 at 00:01

Here is a little kit by ELV which can receive FS20 signals and switch 4 independent open-collector outputs:

4-channel FS20 decoder

This board has an on-board regulator and requires 5..24V DC. Most of the components are SMD’s on the other side, the wire bridges show that this is a single-sided pcb.

Pretty obvious stuff… my reason to buy this was simply to get another 868 MHz receiver module!

RFM12 vs RFM12B

In AVR, Hardware on Apr 29, 2009 at 00:01

Here’s an RFM12 433 MHz module from Pollin, hooked up to an Arduino Duemilanove:

RFM12 (not RFM12B) @ 5V

One major difference between the RFM12 and the RFM12B is that the RFM12 can run at 5V, whereas the maximum operating voltage for the RFM12B is 3.8V (it can withstand up to 6V, which is good to know).

Alas, there seems to be some other difference which eludes me, because the RFM12 hooked up in the above picture only seems to be able to send. The RF12 demo code, which works fine for send and receive on RFM12B’s seems to do something wrong. Same behavior with another RFM12 module – so it looks like this is not due to a broken module. Send works, but nothing is coming in other than occasional garbage data.

The transmit part works fine when sending to an RFM12B, also in OOK mode: the RFM12 successfully controls both 433 and 868 MHz units (KAKU and FS20, respectively). But as packet receiver for other RFM12 or RFM12B modules … no joy so far.

Weird. Tips, anyone? Please let me know.

Update – Thanks to R. Max’s comment below, the problem has been solved: the RFM12 does not support arbitrary 2-byte sync patterns, it has to be 0x2D + 0xD4 – then it works fine!

Update 2 – See also the RFM12 vs RFM12B revisited page for a list of differences.

JeeHub, JeeNode

RF woes

In Hardware on Apr 22, 2009 at 00:01

I’ve been trying to set up a JeeNode as forwarding gateway from the various 868 MHz OOK signals into the RFM12B packet format. The lower left block in the following diagram, that is:

RF woes.png

But I can’t seem to get it to work…

The 868 MHz OOk receiver and the RFM12B transceiver both work fine. In isolation. But when I run code which enables both receivers, the OOK module stops receiving proper data.

There was a mention somewhere about having to provide a really clean power level to the OOK radio, so I’ll probably try again with a separate regulator for it. Or maybe move the two radio modules further apart, since they are both to the same 868 MHz frequency band.

Can’t think of much else. Hm, again.

Home control with FS20

In Hardware on Apr 20, 2009 at 00:01

There are many different types of FS20 units (by Conrad / ELV). Two new types of units came in recently. Here’s a power monitor which transmits power consumption via 868 MHz OOK in 5-minute intervals:

FS20 home control

It’s recognized by the CUL receiver, showing readings such as these:

E0205010000000000001B
E0205020000000000001A
E0205030000000000001A
E0205040100010001001A

Hmm, looks like a cumulative power consumption counter… I plugged in a lamp before that last reading. Maybe there’s both cumulative and real-time power use in there. I’m sure the protocol has been analyzed… and indeed, here it is.

One drawback is that the addressing scheme is limited to at most four ES-1 sensors.

And here’s a little touch-sensitive control panel which can send up to 6 different commands and is made for mounting into the wall:

FS20 home control

The panel can differentiate between short (on/off) taps and long (dimmer) taps, so one panel can actually emit up to 12 different signals. Again, this shows up in CUL:

F1000001204
F1000011217
F10000212F9
F1000031203

At € 36 and € 28, respectively, these units are not really affordable enough to sprinkle lots of them all over the house. Then again, maybe a few strategically placed power meters plus the total electricity meter pulses would be enough to figure out most power consumption patterns in the house…

The advantage of these of course is that they are plug-and-play. It ought to be easy to extend the current FS20 receiver code for the RFM12B so they recognize these extra bit patterns.

Production

In AVR, Hardware on Apr 19, 2009 at 00:01

It’s starting to look like a little assembly line over here…

Assembly line...

That’s five fresh JeeNodes … and they all worked right away, yippie!

Mounting the JeeNode Pulse

In AVR, Hardware on Apr 18, 2009 at 00:01

Here’s another experiment in creating a practical Pulse setup, using a fully populated JeeNode:

JeeNode Pulse mounting

The PWR/I2C and ISP/SPI connectors use wire-wrap pins mounted the other way:

JeeNode Pulse mounting

Here are four “peripheral boards”, ready to add all sorts of sensors:

JeeNode Pulse mounting

They look a bit like feet, ha ha:

JeeNode Pulse mounting

The nice bit is that since each of the boards uses one port and all ports are identical, it is very easy to use various sensor configurations.

Here’s the “carrier board”, mounted on part of the enclosure:

JeeNode Pulse mounting

All the pieces fit together nicely, of course:

JeeNode Pulse mounting

And lastly, the protective shell:

JeeNode Pulse mounting

Case closed… heh :)

Switching AC

In Hardware on Apr 16, 2009 at 00:01

Got myself a couple of these relays from Pollin, for less than the coin next to it:

Bi-stable relay

They can switch 220V @ 16A, and work at 3V. The specialty is that this relay is bi-stable, IOW there are two 15 Ω coils and you send a short pulse through either of them to switch to the corresponding position. So it takes some power to switch, but after that the relay keeps its last position without power. Like a mechanical switch.

It does take some 200 mA – briefly – to switch, so the power supply has to be up to that.

My plan is to connect this to a JeeNode as follows:

Picture 3.png

Probably using a pair of BC547 transistors and 1N4148 diodes (or maybe a ULN2803, to control up to 4 relays). That way, each port would be able to drive one relay. A pretty cheap solution to control any 220 V appliance.

Haven’t decided yet how far to go into actual AC control, since the other option is to use off-the-shelf RF-controlled switches, such as the Conrad/ELV FS20 868 MHz series or the cheap KAKU 433 MHz switches. But relays can be more secure, if some encryption is added to the RF12 driver.

Fun note: I spent a lot of time as a teenager thinking about building a (feeble) computer with relays. After all, this is essentially a 1-bit memory. I’ve moved on since then … slightly :)

JeeHub, JeeNode

JeeHub modularity

In Hardware on Apr 13, 2009 at 00:01

The current JeeHub setup is a bit of a mish-mash:

Picture 1.png

It includes the RFM12B radio of course, to receive data from all JeeNodes. But it also includes a 433 MHz OOK receiver, a BMP085 pressure / temperature sensor, and a DCF77 clock signal receiver.

Trouble is, these things interfere with each other …

The 433 MHz OOK receiver seems to severely degrade RFM12B reception – so I yanked it out. Didn’t have an immediate need to decode KAKU signals anyway.

But worse, the DCF77 receiver also fails to work inside the current JeeHub enclosure. I suspect that either radiated RF power or some messy interference on the power supply levels is preventing it from detecting the 77 kHz signal. I really want DCF77 as reference clock, but I haven’t been able to make any use of it so far.

It looks like there’s too much going on in the current JeeHub prototype, electrically or electro-magnetically.

This is silly – and there’s a very simple way out: move some data sources / sensors to a separate JeeNode. After all, the JeeHub has been doing one thing really well for some time now, i.e. collecting data from remote JeeNodes via the RFM12B:

Picture 2.png

All I need to do is add support for OOK receivers plus BMP085 to the pulse software, and then attach them to one of the remote JeeNodes. Would also make it possible to connect both 433 and 868 MHz OOK receivers.

Haven’t made up my mind about the DCF77 receiver though. Having it tightly integrated with the JeeHub still makes sense – it’s where all the data comes through and gets time-stamped. Maybe the DCF radio will start to work once I disconnect all the other cruft. If not, I’ll either move it physically away from the rest of the JeeHub or reassign it to a remote JeeNode as well.

Surprising, how physical / electrical aspects are starting to impose themselves…

JeeNode Pulse deployment

In Hardware on Apr 11, 2009 at 00:01

This is my plan for sensors in each room in the house:

This setup uses a power supply, which is a bit inconvenient. But the ePIR motion sensor draws too much power to run long enough off a battery. And I haven’t yet figured out low-power use of the RFM12B anyway. With everything permanently on, total power consumption should be under 40 mA.

Am still looking for a nice power supply to use, Pollin has several, some as cheap as € 2. Given that the JeeNode has an on-board regulator, any 4..8 V DC supply will do.

The sensors listed above require 2 ports, so there is room for expansion – depending on room requirements:

more temp sensors, strung together via 1-wire
door and window contact sensors, water level, etc

The JeeNode is placed up against the ceiling to give the motion sensor an optimal view of the room. For really accurate temperature and humidity measurements, it might be preferable to move the SHT11 sensor down a bit – or alternately, to put the JeeNode near the power supply and run a 4-wire cable to the ePIR + light sensors.

Decisions, decisions …

Bye bye readout

In Hardware on Apr 2, 2009 at 00:01

This is what remains when I took the ELV WS300 PC unit apart – the enclosure:

ELV WS300 PC

The electronics, with an ATmega168, a temp/humidity sensor (SHT10?), a barometric pressure sensor, a combined USB interface / battery holder, and a pretty nice custom LCD:

ELV WS300 PC

Oh, and an 868 MHz OOK receiver module:

ELV WS300 PC

This unit includes some dataflash memory to store all received measurements and can be connected to a PC for reading everything out. I took it apart because the Windows-only software really isn’t my cup of tea (a not-so-exciting front end with Postgresql as database backend) and because the 3 AA batteries where running out a bit too quickly (why doesn’t it use USB power when available?). Besides, I really wanted to get a better 868 MHz radio. The module in here seems just right: it can receive all the KS300 and S300 data and it runs at 3V.

Maybe I’ll try my hand at de-soldering one day – the sensors might be worth salvaging as well.

Meet the JeeNode "Pulse"

In AVR, Hardware on Mar 30, 2009 at 00:01

Here’s the first prototype of what I plan to install in several places around the house:

Pulse prototype

It looks a lot like the last post because it’s the same setup, with an SHT11 temperature/humidity sensor added on port 2. The current plan is to support the following hookups:

Either an ePIR via software serial or a PIR on DIO plus an LDR on AIO.
The SHT11 sensor, which requires a dedicated port.
Two pins for either 2 contact sensors or more I/O via I2C I/O expanders.
Up to ten DS18B20’s via a 1-wire interface.
This leaves one spare pin – for a status LED or to monitor the voltage.

Am still looking for alternatives for the SHT11 sensor – it’s more expensive than the rest of the components combined! Maybe I’ll fall back to a 1-wire DS18B20 sensor for just temperature and skip the humidity measurements in some rooms.

The software for the Pulse is mostly a matter of cobbling together existing bits and pieces. But first, the hub needs to be extended to better deal with packets coming from different nodes. Right now, I’m not logging the name and type of the originating node – whoops!

As for constructing actual nodes, I’m exploring some ideas for a daughterboard PCB that snaps onto a JeeNode. It should accommodate a few types of sensors, any of which can be omitted. But the tricky part is not the electrical aspect but the physical one: how is the end result mounted? what type of enclosure should I aim for? what sort of power brick / hookup to use? Lots of loose ends…

Reading out an ePIR motion sensor

In AVR, Hardware on Mar 29, 2009 at 00:01

Here is an “ePIR” sensor (google it), connected to port 1 of a JeeNode (along with an LDR light sensor):

ePIR with LDR

A simple Arduino sketch to read it once per second:

Picture 1.png

Sample output:

Picture 2.png

Where “Y” means motion detected and the number after it is the current light level. As you can see, I first shielded the light from the LDR and then waved in front of the passive-infrared sensor. Note that the LDR is connected to the ePIR, not the JeeNode.

The ePIR has a 9600 baud serial interface, connected via Mikal Hart’s excellent NewSoftSerial library.

MuxShield

Introducing the MuxShield

In AVR, Hardware on Mar 24, 2009 at 00:01

One of these days, I’d like to push the RFM12B radios a bit further, to see how they behave in high-traffic and high-noise situations. What I need really, is a convenient way to re-flash and monitor multiple JeeNodes. Here’s what I’ve come up with:

Test rig concept

It’s an Arduino Duemilanove with a proto shield, containing 5 FTDI sockets for connecting slave boards. I’d like this new “MuxShield” to perform two tasks:

A serial line multiplexer which can send out commands to any connected board, as well as receive and report incoming data from all connected boards, at the same time.
A boot flash repeater which can reprogram the flash memory of each board, using the standard FTDI serial protocol.

The multiplexer makes it possible to collect data while running a multi-board send-receive test, while the repeater simplifies the development cycle when frequently altering the software. With the combination of both, I won’t need to constantly unplug boards or adjust IDE settings.

The idea for the repeater is to use a larger ATmega328 on the Duemilanove, and to reserve half its flash memory for the data which needs to be programmed into the slave boards (which for now will remain ATmega168’s).

A few more hardware details: 4 of the 5 FTDI connectors are jumpered to supply either +5V or +3.3V from an on-board regulator. And there’s a small slide switch (visible in the picture above) which determines whether the incoming flash program is intended for the Arduino or for the slave boards. I’ll add two status LEDs later, to make it easier to see what’s going on.

This setup is not limited to JeeNodes or to testing wireless radios, it works with other FTDI-based Arduino’ish systems such as the RBBB by Modern Devices or the DC Boarduino by Adafruit – there are no doubt several more.

Anyway, on the software side it’s going to be a challenge to make all of this work. And I’ll need to customize the Arduino bootstrap code.

The JeeNode v2 works

In AVR, Hardware on Mar 23, 2009 at 00:01

The PCB’s arrived and again it looks like everything is working as intended. Here is the bare board:

JeeNode v2

Changes are really minor. But at least now this thing has a name on it, and all connectors have (tiny) texts next to them so it’s easier to remember what goes where and in which orientation.

Even with just two versions in existence so far, I’m already starting to get confused about pinouts, header orientation, etc. so I’ve started documenting this latest JeeNode board here (PDF).

The next steps will be to decide on a useful sensor setup, to decide on how to best power these units, and to distribute lots of them all over the house as part of my own DIY “Home WSN“. This is going to be fun!

(I’ve got a few extra boards and parts this time – let me know if you’re interested in tinkering with this stuff)

JeeHub, JeeMon, JeeNode

Let's pick a few more names

In Hardware, Software on Mar 20, 2009 at 00:01

Not to worry: I’m not going to go crazy on the Jee<blah> naming used so far…

But I do need to give the different pieces some name. To be able to refer to them in these posts, but more importantly as names for the software for all this. I also need to introduce a basic structure (and some limits).

Picture 1.png

Here goes:

A JeeNode is this ATmega-with-4-ports-and-RFM12B thing. There may be lots of JeeNodes for various purposes. They can communicate with each other via wireless.
I use the Ports and RF12 libraries with JeeNodes, although this is not a hard requirement – both the JeeNodes and the libraries can be used in numerous other ways.
Each JeeNode has a letter ‘A’ to ‘Z’ assigned to it as node ID. Nodes are usually given a unique ID to avoid mixups, but this is not strictly required.
There can be up to 250 separate groups of JeeNodes. Nodes can only communicate with other nodes in the same group. Gateways between groups could be implemented later, if needed.
Most nodes will be pulse JeeNodes, i.e. running a specific piece of software called – you guessed it – “pulse”, which continuously monitors some attached sensors and reports the readings via wireless.
The JeeHub is either a JeeNode by itself connected to a Mac, Windows, or Linux PC via USB, or a JeeNode connected to Ethernet via a small dedicated Linux module.
This JeeNode-as-part-of-a-JeeHub is called the central node from now on. It runs a specific software configuration, also called “central”. There should always be exactly one central node.
The software running on the Mac, Windows, or Linux machine(s) is called the server from now on (how original, eh?). It consists of a system-dependent executable runtime called JeeMon plus the code and data for the application itself.

It probably doesn’t hurt to reiterate that “JeeNode” and “JeeHub” are hardware, whereas “JeeMon” and the Ports / RF12 libraries are software.

The above names are also used in the source tree repository now.

There are no doubt still infinitely many ways to lead you astray, but I hope that these definitions will help me place everything into an increasingly coherent context.

Energy monitoring

In Hardware, Software on Mar 19, 2009 at 00:01

This setup has been running here for a few months:

Picture 1.png

A light reflectance sensor detects the revolutions of the electricity meter. It is hooked up to a JeeNode, which counts the revolutions and sends its counter value to the central JeeHub node every 10 seconds.

For basic tracking of total electricity consumption, that’s all you need. Occasional packet loss has no influence on aggregated results since the counts are tracked near the sensor. The same works for gas and water consumption.

However, I also want to get a good estimate of the consumption rates in real time. This can be done by timing the rotation period, at millisecond resolution preferably. So the first improvement a while back was to let the sensor JeeNode send packets the moment a revolution is detected, and not just every 10 seconds. That way the central node can do millisecond-resolution timing, which is easy with a stable clock and Linux.

This works reasonably well, but only if reception is nearly perfect. Any lost packet messes up the preceding and the following timing estimate. Only with two packets sent right after a counter change can the period be measured. I kept the periodic 10-second sends enabled as fail-safe, but these late packets are useless for real-time rate calculations.

The next improvement was to let the sensor node do the millisecond timing. It wasn’t obvious how, though, as sensor nodes do not have a very accurate clock: a ceramic resonator has around 0.5% accuracy and probably also some temperature sensitivity. Turns out that it doesn’t really matter: as long as these real-time estimates are not summed together, errors won’t propagate any further.

So now the sensor node sends both the counter value and the last rotation period in milliseconds. The counter value is perfect for long term energy consumption monitoring – after all, it’s exactly the same as what the power company will use to charge me later. The millisecond period is a good estimate of current electricity use, and probably fairly stable from one measurement to the next. Absolute accuracy and drift are not so important here, because the main use of the real-time estimate is to see small changes as they occur.

Here’s an example of the entries logged on the JeeHub:

Picture 2.png

All log entries have the format “T [time] [millis] [type] …”. Where “time” is the time on the Linux module of the JeeHub in YYYYMMDD.HHMMSS format and “millis” is the current millisecond counter on the JeeNode inside the JeeHub. This might seem redundant, but keep in mind that the Linux module is not always on – it can pull data off the JeeNode when started up again. Additional timing data will come from the on-board DCF77 receiver once that is fully operational. So there are three sources of timing information inside the JeeHub: Linux, JeeNode, and the DCF77 atomic-clock reception. Each have different levels of accuracy and drift, but because all of them are logged, this can be fully determined later.

The raw text log files grow by around 0.5 Mbyte/day right now. Gzip compresses them to roughly 20% of that, so they can easily be kept around: the MMnet1001’s flash memory will hold several years of these full-detail logs.

Back to the actual log entries now.

The “HM2” packets are from the electricity & gas metering node. Packets 56, 57, 58, 60, 61, 62, 63, 0, and 1 were lost (more on that later). The electricity revolutions went from 132 to 136 in this time frame, and the gas counter stayed at 139. The rotation time for the electricity meter in packet 54 was 74*256+209 = 19,153 ms. There is a third slot of four 0’s in each packet for measuring water consumption, currently waiting for a new sensor-enabled flow meter to be installed.

Looking at some calculated results, I think this setup will be able to track real-time power consumption with a resolution of under 1 Watt. The resolution actually improves with lower energy consumption rates – precisely what you’d want.

The VOLT and BARO entries are from sensors within the JeeHub. The ALT entry is weather data from a remote sensor and comes from another system for now.

A further improvement with the energy data was to switch to the latest RF12 library code and to use acknowledgements. Every time a packet has been properly acknowledged, the sensor node stops sending data until one of the counters changes. When no ack is received, data is resent every 3 seconds. With good reception most of the time, the number of packets sent (and logged) willl be quite small. And with packet loss, the data will usually arrive 3 or 6 seconds later anyway. Note how in the above log file excerpt each counter value from 132 through 136 was recorded, but retransmits were needed to get counts 134 and 135 to the JeeHub.

Final point: the wireless communication speed was raised from 38400 to 57600 baud – and reception appears to be at least as good as before.

Packet loss – I’ve been seeing long stretches of fairly bad reception at times. Until I realized that these coincided with our wireless headphone set being turned on. I don’t know what that thing is sending out into the ether, but it’s clearly interfering with the 868 MHz communication between JeeNodes. Oh well – it’s a good test for dealing with missed packets…

JeeHub enclosure

In Hardware on Mar 18, 2009 at 00:01

Ok, so I wanted to wrap the JeeHub prototype into some sort of enclosure…

JeeHub enclosure

Yeah, why not, a cardboard box.

Got a couple of these from SparkFun, from whom I’ve ordered a few times. The fit is very tight:

JeeHub enclosure

And all connectors come out on one side:

JeeHub enclosure

From left to right:

Access to the FTDI connector of the JeeNode
The ethernet port of the MMnet1001 Linux module
A mini USB plug, only used to supply power
DC power, has to be between 5 and 6 volt

In normal use, only the Ethernet and USB ports are hooked up. But even without anything connected, the JeeNode will continue to receive and log data packets (once I finish the dataflash code, that is).

Minimal JeeNode

In AVR, Hardware on Mar 16, 2009 at 00:01

Here’s a functioning ATmega168 on a JeeNode v1 PCB:

Minimal JeeNode

It needs just a 10 KΩ resistor, a 100 nF capacitor, and a wire jumper. The IC socket is optional :)

The jumper replaces the voltage regulator. If you later add the RFM12B module, use an FTDI interface which supplies 3.3V to this configuration, not 5V.

To make this work from the Arduino IDE, choose “Lilypad Arduino” as board – it’s set up to run off the internal 8 MHz RC clock. Then burn the corresponding bootloader to the chip (I use a USBtinyISP). Once that is done, you can upload and try out sketches.

This setup requires the modified “avrdude” software which is part of the Arduino-0013 IDE (version “5.4-arduino”). See this comment for why and how it confused me.

Update – All gcc/avrdude issues have been resolved in the Arduino-0014 IDE.

Package from China

In Hardware on Mar 15, 2009 at 00:01

The other day (three weeks ago, actually) I ordered a wide range of connectors in 10x sample quantities from 4Uconnector. Then this came in:

Package from China

A little envelope full of low-cost goodies, such as this 4-way RJ11 jack:

Sample RJ11 connectors

Look how neatly it’s packaged. All the other parts were placed in little zip-lock bags and accurately labeled. How convenient, 100% ready to use and store.

The RJ11 jacks are an idea I’d like to try out to easily hook up sensors and other peripherals. Simply cut a standard 2-/4-/6-wire telephone cable in half and you’re all set to hook up two devices!

The only snag here is that the minimum order quantity is often 100’s or even 1000 units. So it’ll be crucial to choose wisely and stick with it…

Using a crystal

In AVR, Hardware on Mar 14, 2009 at 00:01

For the JeeHub, I wanted better clock stability than the 0.5% provided by a ceramic resonator, so I mounted a crystal instead:

Crystal mounting

This needs 2 extra 20 pF capacitors to ground, which I mounted on the other side as SMDs:

SMD 20 pF capacitors

A bit of solder and a short wire to the ground pin did the trick. Wow, even those 1206 components are tiny…

JeeHub physical layout

In Hardware on Mar 11, 2009 at 00:01

I’m going to try and fit all the components of the prototype JeeHub onto an 8.5 x 11.5 cm board to match a little enclosure that’s been lying around here:

Picture 1.png

It looks like everything fits – though it’s a bit tight:

JeeHub proto

There are two subsystems: the MMnet1001 Linux module and the rest, based on a JeeNode. The “rest” is actually the core of the system since it will run day-in day-out, whereas Linux could be shut down when no ethernet access or fancy reporting is needed.

The remaining components on this set-up are:

a DCF77 receiver for accurate time tracking
a BMP085 barometric pressure sensor
a 433 MHz OOK receiver to pick up remote control commands
a 8 Mbit dataflash memory as piggy-back on the JeeNode
a status LED

Furthermore, the RFM12B wireless on the JeeNode can control standard 433 & 868 MHz radio-frequency units such as power switches.

Everything can be powered from a USB port or a 5..6V DC wall plug. The automatic battery back-up allows running the JeeNode core off-the-grid. It’s not a priority but I want to see to what extent a JeeHub can function on its own power. The Linux module will be powered by a 5 -> 3.3V regulator, with a shutdown-pin controlled from the JeeNode.

Much of the basic software for the JeeNode core has already been written. But that’s of course just the tip of this “home-monitoring and -control” iceberg…

Tiny embedded Linux

In Hardware on Mar 8, 2009 at 00:01

The MMnet1001 is an interesting little setup, based on the AT91 ARM chip. Here’s a close-up image, as provided by Propox:

The ethernet connector is about the only hint you get on how small this thing actually is. It’s shorter than a JeeNode (and it has a lot more hardware!).

I did not order the development board with this, given that I only need minimal hardware interfacing. So my first try was to simply hook up 3.3V power to J2-1 and J2-2 and plug in an Ethernet cable.

Hmm, nothing happens. No new device shows up on the LAN. It turns out that the bootstrap uses a debug serial line, and unfortunately in this revision the internal pull-up on the RX pin is not enabled. So the bootstrap picks up something on the line, and then waits for a complete command.

A 10 KΩ pull-up resistor on J1-13 fixes it. The user LED is flashing!

Now I can see a network device, but it won’t let me in via SSH and I don’t see an HTTPD server on port 80 either.

Ok, time to hook up the serial port @ 115200 baud via an FTDI cable. Aha!

Picture 3.png

(actually, this is the text I get after editing out some cruft from “/etc/issue”, not a first-time hookup)

Great. I’m in. And there’s a “dropbear” SSH. Ok, turns out the root password hasn’t been set – that’s easy to fix.

Yes! Now I can connect over ethernet at last:

Picture 5.png

Perfect. The serial line is no longer needed. This thing now boots up and lets me in via SSH without further tweaking.

Power consumption @ 3.3V is about 250 mA idle and 350 mA when running the CPU at full load. Here are some more system specs:

Picture 6.png

All is well. Onwards!

JeeHub, JeeNode

JeeHub mock-up

In Hardware on Mar 7, 2009 at 00:01

Meet the JeeHub, a self-contained server and gateway between networked JeeNodes and an Ethernet network:

JeeHub prototype

On the right is a Propox MMnet1001 module with an AT91 ARM processor, 64 Mb RAM, and 1 Gb flash, running Linux. On the left is a JeeNode, to be used as receiver and central node in the 868 MHz wireless connection with all other JeeNodes. It hasn’t been hooked up yet – this was just a mock-up to make a pretty picture.

The software on the JeeHub is portable, the same code also runs on Windows, Mac OS X, and Linux x86. The benefit of a JeeHub is that you don’t have to leave a PC on to collect / process / present all measurement data, or to control devices around the house. The JeeHub draws less than 1 watt of power and can be left on to provide all these functions around the clock. It has a built-in web server and database, and can connect to other systems on the local network as well as the internet to perform both interactive and unattended tasks.

The basic JeeHub hardware and software is working here now, with automatic self-updates for completely maintenance-free use, but things are still changing far too quickly to document them and turn this loose.

So yeah, this post is a bit of a teaser for now…

JeeNode v2 PCB

In AVR, Hardware on Mar 5, 2009 at 00:01

Ok, here’s a new design for the JeeNode board:

JeeNode v2 PCB

Major changes were the swapping of pins 1 + 6 on each port and flipping around the FTDI connector so plugin adapters no longer end up being upside-down (doh!).

Plus lots of relatively minor changes, such as tiny connector pin markings in the top copper layer, moving ports 1 + 4 an extra 0.1″ towards the radio, making all power traces thicker, and making the board slightly narrower. I didn’t want to dive into silkscreens yet, though in hindsight even the default one would have been workable.

Some cosmetic changes too: added a descriptive “JeeNode v2” text on the bottom layer and a ground plane fill.

Anyway, I recently ordered a couple of these new ones… we’ll see!

EAGLE schematic (PDF) & board files (jee-pcb-003).

Update – the new PCBs are in, I’ve added some preliminary documentation here (PDF).

Dataflash via SPI

In AVR, Hardware on Mar 4, 2009 at 00:01

The AT45DB081D dataflash memory holds over 8 Mbit, organized as 4096 pages of 256 (or 264) bytes. It’s easy to connect to a JeeNode:

Dataflash via SPI

Looks a bit messy at close-up but it’s actually quite sturdy with 6 wire-wrap wires.

It’s quite easy to talk to this device. Here’s the sample output of reading and writing 100 blocks:

Dataflash via SPI

It looks like reading takes about 1.1 msec per block and writing 8.6 msec. A scan over all 4096 blocks while reading only 8 bytes from each takes less than half a second, so it’s definitely feasible to scan the full memory when starting up.

Out of spec

In AVR, Hardware on Feb 27, 2009 at 00:01

Running an Atmega168 at 16 MHz on 3.3V power is beyond its specs:

Out of spec

Officially, you’re only allowed to run it at up 13.333 Mhz with 3.3V. Easy math: it’s 10 Mhz change over a range of 1.8V, and 3.3V is one third of the way up from 2.7V.

Yet I’ve been running this chip with a 16 Mhz resonator on at least a dozen JeeNodes now. I don’t know whether that means all is well because the limits are conservative ones, or whether they might fail outdoors in an extended temperature range, or whether a few units will not work.

Memsic 2-axis accelerometer

In AVR, Hardware on Feb 26, 2009 at 00:01

Yet another sensor mounted on a breakout board by Parallax, is the Memsic 2125 accelerometer:

Memsic 2125 2-axis accelerometer

Demo sketch, called “accel2125_demo” in the Ports library:

Memsic 2125 2-axis accelerometer

Sample output:

Memsic 2125 2-axis accelerometer

The pulses are 5 msec at rest, and changed slightly when I moved this thing (rather gently).

Might work nicely for a self-balancing robot…

QTI measures reflection

In AVR, Hardware on Feb 25, 2009 at 00:01

Parallax offers a QTI sensor, which is a led + photo transistor on a breakout board. It’s easy to hook up to a JeeNode because the pin-out matches port pins 3..5:

A QTI sensor measures reflection

Demo sketch, added as example to the Ports library:

A QTI sensor measures reflection

Sample output:

A QTI sensor measures reflection

Could be used to count power / gas meter revolutions.

So what's with pins 1 and 6?

In AVR, Hardware on Feb 24, 2009 at 00:01

So far, I’ve only been using pins 2..5 on all ports:

So what’s with port pins 1 and 6, eh?

The main reason being that they offer most of what I need anyway: 2 I/O lines and power. The main idea of ports is that they include power alongside the I/O lines, which makes experimentation much simpler while also allowing me to reconnect stuff to different ports at will. It’s fascinating how much one can do with just the AIO + DIO signals.

Two more pins were added relatively late in the design process: the raw pre-regulator power line (PWR) and an open-collector interrupt line shared by all ports (IRQ). Some chips such as I2C port expanders have the ability to drive higher voltages and an option to generate interrupts. So one practical scenario is with +5V as PWR to support 5V sensors and other chips. Level conversion may still be needed for the DIO + AIO pins, but at least there is +5V to properly drive everything. An obvious source of 5V power is a USB port, so with the proper FTDI cable or breakout board PWR becomes a convenient +5V line.

As for IRQ: I’m a big fan of interrupts. They make it possible to handle tasks in the background, such as keeping a wireless connection going. Or responding to events without having to wait for them in busy loops.

But there’s a potential problem: external power is on pin 6, right next to +3.3V. If pins 5 and 6 ever get shorted out with +6V or more on pin 6, then this could fry the entire system: MPU, sensors, everything. It’s the same as shorting the input and output pins of the voltage regulator!

I’m considering switching pin assignments 1 and 6 for a re-designed JeeNode, i.e. PWR on 1 and IRQ on 6. At least that way everything but the MPU might survive such an accident. With expensive sensors, this matters.

For now, it’s best to use just pins 2..5 where possible.

Breadboard options

In AVR, Hardware on Feb 23, 2009 at 00:01

The JeeNode can be used with breadboards in different ways. The smallest configuration is a mini-breadboard, allowing one wire per pin (or 2, just…):

Breadboard options

To get more connections on each pin, use this:

Breadboard options

Or a bigger breadboard:

Breadboard options

Or use one breadboard per port:

Breadboard options

You could also set things up vertically:

Breadboard options

The rotated layout lets you switch between diagonally opposite ports, here are ports 1 and 4:

Breadboard options

The black and white boards can be swapped without having to redo any wiring:

Breadboard options

You can also flip entire sides:

Breadboard options

And finally there’s the option of using wire-wrap pins as IC socket to get access to all of the ATmega’s pins:

Breadboard options

Although that hardly qualifies as a JeeNode anymore…

The same 10 µF

In Hardware on Feb 11, 2009 at 00:04

Three capacitors, all 10 µF / 16V:

That left one looks big. But it isn’t really:

It’s unfortunate that they all have different pin spacings (2.5, 1.5, and 1.0 mm, respectively). That means I can’t design for all of them. The large one is not a good option because it sticks out too much when placed upright, so I guess I’ll design for the middle one and hope the tiny one still fits in reasonably well.

(Side note: I really need to get my photo lighting setup sorted out…)

Logic Analyzer: fantastic!

In Hardware on Jan 27, 2009 at 20:39

Today, I received my new USB-connected/-powered 16-line 100 MHz logic analyzer:

It captures signals in time and displays / analyzes patters in them. Here’s a setup which decodes 2 signals of an I²C bus:

The instrument shown here is a ZeroPlus LAP-16032U (old version: 32 Kb memory w/ compression), now superseded by this one. For € 120 this includes several protocol analyzers, including I²C, SPI, and async serial (RS232). And the built-in hardware compression means it can capture very long pulse sequences.

This is a phenomenal debugging tool and time-saver. Well… for people who deal with logic signals and need to analyze them, that is!

Wireless power monitoring

In Hardware on Jan 25, 2009 at 16:47

Looks like lots of hobbyists are starting to explore the world of tracking energy usage in the home in real time.

Here’s a recent weblog entry by LadyAda, called Wattcher. It uses off-the shelf components and modifies them (could that be called a hardware mash-up?).

Great, very similar to what I’m after – but I hope to get there at a lower cost…

RFM12B up close

In Hardware on Jan 24, 2009 at 16:28

Here are some pictures of the RFM12B radio module (there are versions for 433, 868, and 915 MHz).

With wires to adjust between the module’s 2 mm spacing and the breadboard’s 2.54 mm (0.1″) spacing:

This is how I’ve been mounting a couple of these modules lately, the white wire is an 85 mm wire antenna which appears to work well:

And this shows how I’d like to mount these modules onto a PCB – with proper 2 mm spacing of course, this was just soldered on to give you an idea:

IOW, in this last case the radio module would be flat on top of another board, with just the solder masks as isolation between them.

Shield progress

In AVR, Hardware on Jan 14, 2009 at 15:57

The Arduino shield stack is shaping up. Here’s the peripheral shield, with all modules installed:

This now contains the following peripherals:

a µSD card reader with 2 Gb card (top right)
an RFM12B 868 MHz transceiver (bottom right)
an 433 MHz AM receiver (top left, hidden)
an 868 MHz AM transmitter (bottom left)
a DCF77 time code receiver (middle, with ferrite antenna)

The header pins support a status shield on top with a small 3×12 LCD display (connected via I²C) and some leds & buttons:

The whole setup, when stacked on an Arduino Duemilanove, now becomes this:

What it does will depend on the software written for it, obviously.

Arduino + RFM12B + µSD

In Hardware on Jan 13, 2009 at 00:59

This is the first working version of the new shield mentioned yesterday:

Peripheral shield

It connects a RFM12B radio and a micro SD card to the SPI bus. They both work, i.e. the radio can send & receive packets and the 2Gb Kingston µSD card can successfully enter SPI mode. These two peripherals alone would be enough to set up a self-contained data logger, but this is just the start – less than half of the shield area has been used so far.

Shield stack

In AVR, Hardware on Jan 12, 2009 at 16:11

Here is the start of a new set of shields for the Arduino, based on Adafruit’s Proto Shield:

This little thing might one day become my “home monitoring & control server”, but that’s still a long way off. You can see a µSD card slot with 2 Gb of flash memory on the middle board, which will become the main peripheral shield. The top shield is for basic access and status info, and is optional. Additional shields could be inserted into this stack later.

This is not a mouse

In AVR, Hardware on Dec 17, 2008 at 15:53

The CUL is a small gadget which combines a CC1101 RF module with a USB-enabled ATmega processor in a very small unit:

So, yes, it has a tail and it plugs into a USB port, but it’s not a mouse. This thing can receive and decode messages from 868 MHz devices such as the FS20 home control unit, the KS300 weather sensor, and more. Technically, it could also send out such messages since the CC1101 is a transceiver, but apparently the 1.07 firmware isn’t quite there yet.

Switching stuff

In Hardware on Dec 16, 2008 at 15:51

Today, some simple “KAKU” remote switches came in. These are both by KlikOn-KlikOff – the first one is an older setup I was already using, with up to 12 different codes:

The second is a newer model with up to 256 different codes – it’s heavily discounted (€14 for 2 units plus transmitter), probably because this type is being replaced by a newer model which uses unique unit codes:

The drawback with both of these, as compared to the FS20 models by Conrad, is that you can’t control them at the plug – you have to locate the remote and press buttons on it. But then again, at these low prices per unit … you get what you pay for.

These units use 433 MHz signalling, there’s code for Arduinos which understands the KAKU protocol.

Wireless RFM12B Module

In Hardware on Dec 10, 2008 at 15:36

A new 868 MHz module came in today, which uses FSK as modulation method:

This is a tiny 16×16 mm RFM12B module. It contains a transceiver and can be connected with a 4-pin SPI bus plus an IRQ pin to send/receive bytes using interrupts. Documentation is a bit sketchy, but there are a few different code samples on the net.

This version is for SMD mounting (with 2mm pins, again). But it’s easy to add a few wires and use this in a 0.1” grid breadboard. The antenna used here is an 82 mm straight wire.

Home Control

In Hardware on Dec 7, 2008 at 15:34

The FS20 system by Conrad is a simple RF-based set of modules to turn various appliances on and off. The transmitter looks like this:

The most basic on/off remote control switches are as follows, shown with central European power plugs:

They have an on/off toggle on the unit, which is a big plus over simpler units. The other useful aspect of these units is that they operate over the 868 MHz band, and that the details of the FS20 protocol are available. Several projects exist which can receive and/or transmit the corresponding signals.

Definitely not the most beautiful design, but hey, they get the job done…

Bad Reception

In AVR, Hardware on Dec 5, 2008 at 15:32

This is a USB Boarduino with an 868 MHz receiver connected to it:

The antenna is a short 82 mm wire. Just like the one used in this setup. Given the same software, it receives the same signals.

But somehow, it’s considerably less sensitive – so far this unit won’t pick up the (faint) transmissions from the energy monitor nearly as reliably as the first setup. It’s not a matter of noise signals, antenna placement, or any hardware differences (all physical variations give the same result). Must be moon phases, or something. I’m going to let it rest and focus on other RF options instead.

The original polling setup has been working fine for several days now, btw.

CC2500

In Hardware on Dec 2, 2008 at 15:27

The nice part of this transceiver by Ideetron is that it’s cheaper yet more advanced than the 433 & 868 MHz radio modules by Conrad:

I does have that awkward 2mm pin header, but Ideetron most generously threw in a few female headers for free.

This modules uses a CC2500 chip operating at 2.4 GHz. The interface is via SPI commands, which provides various registers to exchange data both ways. All the bit manipulation and byte synchronization is handled, and the communication is bi-directional, allowing for a packet-oriented design with positive acknowledgement.

Unlike the iDwarf kit there is relatively little sample software to get started with this module, so it will take more work to get this going. Having an on-board antenna just like the iDwarf and XBee and using the same 2.4 GHz frequency band, the range might again be insufficient to pass through a few stone walls, but that’s just guessing for now.

From 433 to 868

In AVR, Hardware on Dec 1, 2008 at 15:26

These are the 868 MHz modules from Conrad – receiver on the left, transmitter on the right:

Worked as straight replacements in the 433 MHz setup, but there seems to be some problem with noise. It got a bit better when the receiver was tied to an 82 mm wire as antenna (as shown), i.e. exactly 1/4 wavelength. And that funny transmit antenna wire/coil probably isn’t optimal either…

Still, a bit noisy, lots of spurious pulses, and only occasional CRC-valid reception. It looks like much of the problem is caused by the crude bit-start synchronization software. Needs more work, clearly.

iDwarf

In AVR, Hardware on Nov 30, 2008 at 01:06

The iDwarf system is a wireless 2.4 GHz radio module with an ATmega168 inside. The starter kit comes with two sensor nodes with built-in battery holder and one “hub” which interfaces to (and runs off) USB:

The daughterboards showing on top are the actual modules, the rest is part of the starter kit, i.e. sensor node and hub interface boards.

Several software examples were included, with hex files ready to try. It took me a while to figure out that I had to also set up the fuse bits – as delivered, the 168 is completely empty:

And just changing some ’s to /‘s in the source was all it took to re-compile these examples from source on MacOSX (the actual radio driver code is linked in from a library, no source, though).

Having a fully programmable chip to customize, with over half of its memory free makes this a more flexible option than XBee’s, at about the same price.

First trials indicate that the range of these little modules is a bit limited. They didn’t maintain a connection across three layers of stone & concrete (floors / walls) – a hefty requirement, but all within a single home. Still, it’s impressive what a pair of tiny on-board antennas can accomplish.

Wireless at 433 MHz

In AVR, Hardware on Nov 29, 2008 at 01:03

This was an experiment to learn about low-power / low-range wireless communication using a 433 Mhz transmitter / receiver set from Conrad. The transmitter was tied to an RBBB board and accessed via an FTDI-USB cable:

The receiver was mounted on a proto shield with breadboard, on top of a standard Arduino:

The software for this requires some attention due to the crude communication system.

Basically, the transmitter is turned on and off by a serial bit stream, i.e. this is not FM or even AM, just the presence and absence of a signal. To make this work properly and get say 20 bytes of data across, you have to go through the following sequence:

turn on the signal for a few milliseconds so the receiver adjust its AFC (assuming it has one)
send a unique bit pattern so the receiver can synchronize to receive data as individual bytes
send the data bytes, i.e. the “payload”
send a 2-byte CRC so the receiver can verify proper reception
turn off the signal for at least a few dozen milliseconds to avoid hogging the radio channel
re-send the whole packet one or more times to deal with interference and collisions

Even then, correct reception is not guaranteed – that would require a transceiver setup with two-way acknowledgement.

Data is sent using Manchester code, a phase change trick which keeps the on and off times equal, on average. The signalling rate is only 1000 baud (i.e. 1 millisecond per bit) and even then the error rate is quite substantial.

The CRC is calculated via standard code from the avr-libc library. A little trick is used to simplify the code: when the two CRC bytes are appended in little-endian format, the receiver can calculate its CRC including these bytes and verify that the result is zero.

The C test code is in the download area – for both the transmission and the reception version. It uses busy loops for (rough) timing. An interrupt-driven version using one of the 168’s hardware counters would have been preferable, to generate a jitter-free signal and to be able to handle other tasks during reception.

The results indicate that the transmitter really needs an external antenna wire to cross more than a meter (!) or so of air. With antenna, the signal barely makes it through one (reinforced) concrete wall in the house, which is insufficient for my purposes, but an 868 MHz version will probably overcome this limitation.

XBee Adapters

In Hardware on Nov 21, 2008 at 00:55

Apart from the XBee shield, there are several other options to hook into that module with its non-standard 2-mm connector.

The simplest is a little breakout board which brings things back to “normal” 2.54 mm PCB units:

Next up is AdaFruit’s adapter which connects to an FTDI cable or plugs into a breadboard:

Finally, there is the Xbee Explorer USB which ties it directly to a slave USB port:

The adapter is probably the most convenient to embed and to use stand-alone, since it does all the voltage regulation and conversion in a simple package.

XBee shield

In AVR, Hardware on Nov 11, 2008 at 00:46

Here’s an Arduino shield for the XBee wireless 2.4 GHz module (v2, as kit from NKC Electronics):

I haven’t been able to find the hardware schematics or board layout, looks like it’s proprietary…

If you look closely, you’ll see that the board underneath it is a new Arduino Duemilanove, which auto-senses power between the plug and the USB port.