Computing stuff tied to the physical world

Archive for March 2012

Pressure cooker

In Musings on Mar 31, 2012 at 00:01

These past 36 hours have been absolutely fabulous, and exhausting…

First there was the 7th HackersNL meeting in Utrecht. The name of the event is unfortunate, IMO (this whole “hacker” monicker doesn’t sit well with normal people, i.e. 99.9% of humanity), but the presentations were both absolutely fantastic. A wide scale of design topics by David Menting, including his “linear clock” for which he designed custom hardware based on a standard tiny Linux + WiFi board, and then a talk about turning a cheap laser cutter into a pretty amazing unit by ripping out the driver board and software, and replacing it with their own custom hardware with an MBED module plus software (wiki) – by Jaap Vermaas and Peter Brier. Both cutting edge, if you pardon the pun, and above all a pressure cooker where two dozen people get to talk about “stuff”, mostly related to Physical Computing really. Everything is open source.

If you live in the neighborhood of Utrecht, I can highly recommend this recurring meeting, scheduled for the last Thursday of each month – so take note, hope to see you there, one day!

The other event was the Air Quality Egg Workshop, by Joe Saavedra. Basic idea: a sensor unit, to measure air quality in some way, plus an “egg” base station which can tie into Pachube (both ways), relays the sensor data, and includes an RGB color light plus push-button.

Except that it doesn’t exist yet. We built a wired prototype based on a Nanode with SparkFun protoshield, a CO sensor, an NO2 sensor, and a DHT22 temperature/humidity sensor.

Here’s my concoction (three of the sensors were mounted away from the heat generated by the Nanode):

DSC 3002

It’s now sitting next to the JeeLabs server, feeding Pachube periodically. We’ll see how it goes, since apparently these sensors need 24..48 hours to stabilize. Here are some of the readings so far:

AirQuality

CO

NO2

Temperature

Humidity

What I took away from this, is:

  1. Whee, there sure is a lot more fun stuff waiting to be explored!
  2. When you put a fantastic bunch of creative people together, you get magic!
  3. Not enough time! Would it help to keep flying westwards to cram more hours into a day?

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.

PortI2C – C++ classes

In Software on Mar 28, 2012 at 00:01

Last week, I described how the PortI2C + DeviceI2C definitions in JeeLib work together to support daisy-chaining multiple “JeePlugs” on a “JeePort”. To describe how, I need to go into some C++ concepts.

PortI2C and DeviceI2C (and MemoryPlug) are each defined as a C++ class – think of this as a little “software module” if you like. But a class by itself doesn’t do much – just like the C type “int” doesn’t do much – until you create a variable of that type. JeeLib is full of classes, but to make any one of them come alive you have to create an instance – which is what the following line does:

    PortI2C myPort (3);

This could also have been written as follows, but for classes the parentheses are preferable:

    PortI2C myPort = 3;

The class is “PortI2C”, the new variable is “myPort”, and its initial value is based on the integer 3.

In C++, instances are “constructed”. If a class defines a constructor function, then that code will be run while the instance is being set up. In this case, the PortI2C constructor defined inside JeeLib takes the port number and remembers it inside the new instance for later use. It also sets up the I/O pins to properly initialize the I2C bus signals. You can find the code here, if you’re curious.

So now we have a “myPort” instance. We could use it to send and receive data on the I2C bus it just created, but keeping track of all the plugs (i.e. devices) on the bus would be a bit tedious.

The next convenience JeeLib provides, is support per plug. This is what the DeviceI2C class does: you tell it what port to use, and the address of the plug:

    DeviceI2C plugOne (myPort, 0x20);

Same structure: the class is “DeviceI2C”, the new variable is “plugOne”, and the initial value depends on two things: a port instance and the integer 0×20. The port instance is that I2C port we set up before.

The separation between PortI2C and DeviceI2C is what lets us model the real world: each port can act as one I2C bus, and each bus can handle multiple plugs, i.e. I2C devices. We simply create multiple instances of DeviceI2C, giving each of them a different variable name and a unique bus address.

The Memory Plug example last week takes this all even further. There’s a “MemoryPlug” class, i.e. essentially a specialized DeviceI2C which knows a little more about the EEPROM chips on the Memory Plug.

In C++, this sort of specialization is based on a concept called subclassing: we can define a new class in terms of an existing one, and extend it to behave in slightly different ways (lots of flexibility here).

In the code, you can see this in the first line of the class definition:

    class MemoryPlug : public DeviceI2C {
      ...
    };

IOW, a MemoryPlug is a specialized DeviceI2C. Simply remember: English “is a” <=> C++ “subclass”.

Next week, I’ll elaborate on the funky C++ notation for constructors and subclasses – stay tuned!

Tracking time via the watchdog

In AVR, Software on Mar 27, 2012 at 00:01

The JeeLib library has a convenient loseSomeTime() function which puts the ATmega in low power mode for 16 to 60,000 ms of time. This is only 10% accurate, because it uses the hardware watchdog which is based on an internally RC-generated 128 KHz frequency.

But the worst bit is that when you use this in combination with interrupts to wake up the ATmega, then you can’t tell how much time has elapsed, because the clock is not running. All you know when waking up, is that no more than the watchdog timeout has passed. The best you can assume is that half of it has passed – but with loseSomeTime() accepting values up to 1 minute that’s horribly imprecise.

Can we do better? Yes we can…

Internally, loseSomeTime() works by cutting up the request time into smaller slices which the watchdog can handle. So for a 10000 ms request, for example, loseSomeTime() would wait 8192 + 1024 + 512 + 256 + 16 ms to reach the requested delay, approximately. Convenient, except for those long waits.

Here’s a test sketch which simply keeps waiting 8192 ms at a time:

Screen Shot 2012 03 21 at 13 14 16

The corresponding current consumption, measured via oscilloscope, shows this:

SCR58

First of all, note how 8192 ms ends up being 8255 ms, due to the watchdog timer inaccuracy.

But the main result is that to perform this sketch, the ATmega will draw 5 mA during about 50 µs. The rest of the time it’ll be a few µA, i.e. powered down. These wake-ups draw virtually no current, when averaged.

The downside is that under these conditions, interrupts can cause us to lose track of time, up to 8192 ms.

So let’s try something else. Let’s instead run the watchdog as briefly as possible:

Screen Shot 2012 03 21 at 13 04 43

Current consumption now changes to this:

SCR57

I don’t really understand why Because of a loop in the loseSomeTime() code which runs faster, the running time drops by half in this case (and hence total nanocoulomb charge halves too). But note that we’re now waking up about 60 times per second.

This means that interrupts can now only mess with our sense of time by at most 16 ms. Without interruptions (i.e. most of the time), the watchdog just completes and loseSomeTime() adds 16 ms to the millis() clock.

Let’s try and estimate the power consumption added by these very frequent wake-ups:

  • each wake-up pulse draw 5.5 mA for about 25 µs
  • the charge consumed by each pulse is 122 nC
  • there are (roughly) 60 wake-up pulses per second
  • so per second, these pulses consume 60 x 122 nC ≈ 7.3 µC in total
  • that comes down to an average current consumption of 7.3 µA

That’s not bad at all! By waking up 60 times per second (and going back to sleep as quickly as possible), we add only 7.3 µA current consumption to the total. The reason this works, is that wake-ups only take 25 µs, which – even at 60 times per second – hardly adds up to anything.

So this technique might be a very nice way to keep approximate track of time while mostly in sleep mode, with the ability to wake up whenever some significant event (i.e. interrupt) happens!

PS. In case you’re wondering about the shape of these signals, keep in mind that I’m measuring current draw before the regulator and 10 µF capacitor on the JeeNode.

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!

PortI2C – The Big Picture

In Software on Mar 21, 2012 at 00:01

The JeeLib library includes two C++ classes called “PortI2C” and “DeviceI2C”, on which a lot of other code in JeeLib is based – derived classes for various plugs as well as several examples.

This stuff is well inside C++ territory, so if you’re not familiar with “OO design” it’s easy to get lost…

Let’s first look at what we’re trying to model:

Screen Shot 2012 03 17 at 12 13 55

In short: one port (any of the 4 on a JeeNode) is driven as an I2C bus using software bit-banging, and one or more I2C-type JeePlugs are attached to it. Each plug may or may not be of the same type.

What we want is a set of software modules which we can use in our sketch. Say we have three plugs, responding to I2C addresses 0×20, 0×21, and 0×22. Then the code might be something like:

    const byte portNumber = 3;
    PortI2C myPort (portNumber);
    DeviceI2C plugOne (myPort, 0x20);
    DeviceI2C plugTwo (myPort, 0x21);
    DeviceI2C plugThree (myPort, 0x22);

This would set up three C++ objects, where each knows how to reach and control its own plug.

But that’s not all. Suppose plug #3 is a Memory Plug, i.e. an EEPROM memory of 128..512 kB. JeeLib contains extra support code to easily read and write data to such a plug, in the form of a C++ class called “MemoryPlug”. It’s an I2C device, but it always has a fixed bus address of 0×50, which for convenience is already built into the JeeLib code. To use this, all we have to do is replace that last plugThree definition above by this line:

    MemoryPlug plugMem (myPort);

Once this works, we get a lot of functionality for free. Here’s how to send an I2C packet to plug #1:

    plugOne.send();
    plugOne.write(0x01);
    plugOne.write(0x02);
    plugOne.write(0x03);
    plugOne.stop();

Or you can save a 3-byte string to the Memory Plug, on page 12, at offset 21:

    plugMem.save(12, "abc", 21, 3);

There’s a lot going on behind the scenes, but the result leads to a fairly clean coding style with all the details nicely tucked away. The question remains how this “tucking away” with C++ classes and objects is done.

Stay tuned, this will be described next week…

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.

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:

Screen Shot 2012 03 11 at 16 38 26

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?

MilliTimer example

In Software on Mar 16, 2012 at 00:01

The MilliTimer class in JeeLib is a convenient way to perform time-related activities while doing other things at the same time. See also these weblog posts about wasting time and other ways of scheduling multiple tasks. And if you’re willing to learn a new programming language: check out this post.

With just the basic Arduino library support, i.e. if you have to do everything with delay() calls, it’s a lot harder to do things like making two LEDs blink at an independent rate – as in this blink_timers example:

Screen Shot 2012 03 09 at 11 59 12

This illustrates a simple way of using the millisecond timers: calling one with “poll(ms)” will return true once every “ms” milliseconds. The key advantage is that you can do other things in between these calls. As in the above example, where I used two independent timers to track the blinking rate of two LEDs.

This example uses the millitimers in automatic “retrigger” mode, i.e. poll() will return true every once in a while, because whenever poll() returns true, it also re-arms the timer to start over again.

There may be cases where you need a one-shot type of trigger. This can also be handled by millitimers:

    MilliTimer t;
    t.set(123);
    while (...) {
      ...
      if (t.poll())
        Serial.println("boom!");
      ...
    }

When used in this way, the timer will go off only once, 123 milliseconds after having been set.

There are a few other things you can do with millitimers, like finding out whether a particular timer is running, or how many milliseconds remain before it will go off.

These timers only support timeouts in the range of 1..60,000 milliseconds. For longer timeouts, you’ll have to do a bit more work yourself, i.e. to wait one hour you could do:

    MilliTimer timer;
    int seconds = 3600;
    while (...) {
      ...
      if (timer.poll(1000) && --seconds <= 0)
        Serial.println("ding dong");
      ...
    }

Note that the MilliTimer class implements software timers, and that you can have as many as you like. No relationship to the hardware timers in the ATmega, other than that this is based on the Arduino runtime’s “millis()” function, which normally uses hardware TIMER0 internally.

For a more advanced mechanism, see the Scheduler.

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…

Serial Port on JeeNode Micro

In AVR, Software on Mar 9, 2012 at 00:01

The JeeNode Micro is based on an ATtiny84, which has quite a bit less hardware functionality built-in than an ATmega. There is some rudimentary byte-shifting hardware for sending or receiving a serial bit stream, but that’s already assigned to the SPI-style RFM12B interface.

So how about a serial port, for debugging? Even just serial out would be a big help, after all.

Luckily, the developers of the Arduino-Tiny library have thought of this, and have implemented a software solution. Better still, it’s done in an almost completely compatible way.

Here’s an example test sketch:

Screen Shot 2012 03 08 at 07 52 04

Look familiar? Of course it does: it’s exactly the same code as for a standard ATmega sketch!

The one thing you have to keep in mind, is that only a few baud rates are supported:

  • 9600, 38400, and 115200 baud

The latter is unlikely to work when running on the internal 8 MHz clock, though. It’s all done in software. For an ATtiny84 running at 8 MHz, the serial output appears on PB0. This is pin 2 on the chip and pin 10 on the 10-pin header of the JNµ, marked “IOX”.

The code for this software-based serial port is fairly tricky, using embedded assembly code and C++ templates to create just the right timing loops and toggle just the right pin.

Note also that since this is all done in software, interrupts cannot occur while sending out each byte, and sending eats up all the time – the code will resume after the print() and println() calls after all data has been sent.

But apart from these details, you get an excellent debugging facility – even on an ATtiny!

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.

Which boot loader do I have?

In AVR, Software on Mar 7, 2012 at 00:01

Denisj asked on the forum recently whether it’s easy to find out which boot loader is stored in the ATmega. That would indeed be very useful, now that we have a few different versions floating around.

Here’s a new “bootCheck.ino” sketch which tries to identify the boot loader and reports it on the serial port:

Screen Shot 2012 03 06 at 12 23 06

Here’s some sample output when uploaded to the current JeeNodes and RBBBs:

    [bootCheck.2]
      CRC 2048b @ 0x7800 = CD70
      CRC 512b @ 0x7E00 = FD70
    Boot loader: OptiBoot 4.4

The current version only knows about a few boot loaders so far, but it’s table-driven and can quickly be extended.

So now that it exists, let’s use the power of crowdsourcing and make it really useful, eh?

If you’ve got an ATmega328-based board with a bootloader on it, upload this sketch to find out what it reports. If it says “UNKNOWN” and you happen to know exactly what boot loader is present, please let me know what output you get (i.e. the two CRC values) and the name/type of the boot loader, and I’ll add it to the table.

I’ll update the code for each new boot loader. The sketch is maintained as gist on GitHub, so please be sure to get the latest version before you try this. Your boot loader might already be in there!

Note that this is not limited to JeeNodes or RBBBs. Anything with an ATmega328 that will run this Arduino sketch can be included.

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.

Power-up

In Musings on Mar 3, 2012 at 00:01

My PC has been updated. I left it unattended for a month, and now I’m powering it up again. It’s got a new motherboard, a new display, and a new OS revision. It’s quiet, because it’s all-SSD now, and it’s actually a bit slower than the previous one.

The above paragraph is a mix of reality and fiction, BTW. Because I’m talking about two things at once – the Mac I work on, and… my brain. Both have changed :)

The past month has been extremely chaotic for me. I’ve been trying to figure out what I really want to do, and how to make it happen. The outcome surprised me: I absolutely want to keep doing what I’ve been doing these past few years, with JeeLabs. So the good news, if you been following along, is that I will. But there will be changes, because the intensity of it all is not sustainable for me, not at the previous energy level anyway. I will spread out stories over more weblog posts – thus also making it easier for you to keep up and follow along.

In this day and age of instant gratification, mass consumption, and immediate mail-order fulfillment, I’m going to go against the grain and buck the trend – by reducing short term the frequency of JeeLabs shop fulfillments, dealing with shop-related tasks less often. The shop will become even more of a secondary activity here, but fulfillment improvements are in the pipeline. The product range will grow further, but the pace and scale of commerce most likely not. It gives me pleasure to send out packages and to stay in contact with the people who are going to use these products. The shop isn’t about volume and turnover, but about allowing others to reproduce and extend some projects I’m coming up with and working on. Because making stuff is fun.

Board part

My passion, my energy, and my time will remain focused on the weblog, or rather on the projects that drive it all. Whether the frequency can stay as is, time will tell. I hope it can – with occasional breaks in the year – because the daily cycle is great fun, keeps me focused, and is clearly being appreciated.

As Seth Godin describes in his manifesto, the schooling system has taken our dreams away. I’ve been lucky to keep (or rather, rediscover) mine, and want to help as much as I can to make sure others will be able to latch onto their dreams as well, with curiosity and creativity as the driving forces – in the context of Physical Computing, that is.

The internet, at least the part I care about, is evolving into an extra-ordinary global learning powerhouse. It started with Wikipedia and led to the inspiring TED presentations, MIT’s Open Courseware, and the Khan Academy (an absolutely astounding initiative which is turning the way education works on its head). There is no excuse anymore for not knowing what you’d like to know, it’s all there.

And as I’m finding out, there is no excuse anymore for not sharing what you know, either.

Onwards!