Computing stuff tied to the physical world

Posts Tagged ‘Flashback’


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:

dsc_2597

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:

Screen-shot-2009-12-19-at-16.27.09

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:

detail_power_use1

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:

annotated-room-packet1

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:

dijn01-essence.png   dijn01-diagram

.. to here:

Screen-Shot-2013-02-09-at-12.22.13

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:

screen_shot_2010_12_29_at_103314

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 – Ports and I2C in JeeLib

In AVR, Software on Oct 2, 2013 at 00:01

One of the small innovations in the JeeNode is the use of “Ports”:

ports

Most µC boards, including the Arduino, brought out all the I/O pins on one or more large headers, meaning that you had to pick and route individual pins for each case where some component or sensor was being connected. While flexible, it prevented adding stuff in a plug-an-play manner: hook up some sensors, use matching bits of C/C++ code, and done.

I also always kept running out of VCC and GND connection pins while experimenting. So instead of bundling all I/O pins, a decision was made in 2009 to bring out a couple of (nearly) identical “ports”, to any of which the same sensor could be attached. That meant you could connect up to at least four sensors independent of each other.

As it turns out, there are enough spare I/O pins on an ATmega to provide one digital and one analog pin to each port. Add GND, VCC (+3.3V) and PWR (the input voltage, could be up to about 13V), and you end up with a fairly general-purpose setup. One extra spare pin was provided as “IRQ” to allow connected sensors to draw attention to themselves via an interrupt, although this feature has admittedly so far not been used much on JeeNodes.

But the real improvement is the fact that the two I/O pins can be used as I2C bus. All of a sudden, each port is no longer limited to a single sensor. The I2C bus is so useful because many types of low-cost chips include an I2C interface in hardware, and it lets multiple chips operate on a single bus.

One of the first extensions added was the Expander Plug, an 8-bit general-purpose digital I/O interface. So now, with just two pins consumed on the ATmega, you could have up to 32 input/output pins (by daisy chaining 4 of these plugs and setting them each to a different I2C address). The Dimmer Plug takes this even further: up to 8 of them on one bus, each driving up to 16 LED’s – for a total of 128 dimmable LEDs on 2 I/O pins!

Officially, the I2C bus requires dedicated hardware with “slew control” to increase the accuracy of signals on the bus. And while the ATmega has such an interface, there is just one per ATmega. Fortunately, you can also “bit-bang” I2C in plain software, i.e. simulate the relatively slow pin changes with nothing but software on any 2 I/O pins. The speed is not quite as high, and the supported bus length is also limited to a few dozen centimeters, but for direct connection of a few plugs that still works out quite well.

And so the JeeNode has ended up having 4 “ports”, each of them individually capable of supporting either I2C, or one analog (AIO) and one digital (DIO) pin – or alternately 2 digital I/O’s, since each analog pin on the ATmega can also be used in digital mode.

Since then, lots of different types of “JeePlugs” have been created, some I2C, some not. Most of the plugs have a corresponding class and a demo sketch in the JeeLib library, making it very easy to hook them up and interface to them in software. With most plugs, you just have to define which port they are connected to – and in the case of I2C plugs, which bus address they have been set to.

The placement of these ports and the choice of very low-cost standard 6-pin headers took some experimentation, but I think it all turned out ok. Lots of expandability and flexibility.


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:

pd-d1

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:

DSC_4499

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:

DSC_0496

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:

wireless-modules

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:

mousetrap

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):

atmega328p

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.