# Computing stuff tied to the physical world

## Component Tester

In Hardware on Jan 31, 2012 at 00:01

Hameg scopes have often included a “Component Tester” (CT) and mine’s no exception. It’s a really nifty way to identify a component and understand its basic characteristics. It requires a sine wave signal and an oscilloscope:

Don’t fret too long about the above circuit (copied from this PDF, which I found via Google). It’s just to show that setting up something like this is very easy – but you do need an oscilloscope with X-Y capability.

The basic idea is to apply a sine wave of say 10 VAC @ 50 Hz to the part you want to identify, and to then display voltage over versus current through that component.

My scope has the equivalent of the above simple CT circuit built in:

Two pins, on which a 50 Hz voltage is applied which varies between +10V and -10V in the form of a pure sine wave. For some reason, the scope won’t let me take screen dumps to USB in this mode, so I’ll use camera shots.

Here’s what you see with nothing connected (note the full scale: ±10 V on X and ±10 mA on Y):

The horizontal axis shows the applied voltage, and as you can see, no current is flowing. Because air insulates!

Let’s short the two pins with a copper wire (I’ve reduced the image scale to reduce this weblog post’s length):

Of course: no matter what voltage we try to put between the pins, the wire will force it to 0V, and will simply pass -10 .. +10 mA of current. As you can see in the schematic, there’s a 1 kΩ resistor in series to limit the current.

These two images of open vs shorted set the stage. Now let me insert a couple of different components, so you can see how they behave when subjected to this 10 Vpp sine wave. First, let’s insert a 1 kΩ resistor:

Make sense? Now have a look at a 10 kΩ resistor:

So what we have so far, is resistance varying from zero ohm (shorted) to infinite ohm (open), with two values in between. It all ends up as a straight line, with the slope varying from horizontal to vertical. That’s it: resistance!

If you want an explanation: this is Ohm’s law, visualized. Voltage and current are proportional, i.e. V = I x R.

So much for the basic stuff. Tomorrow, I’ll show you a couple of considerably more interesting components.

## Capacitive power supply – part 2

In Hardware on Jan 30, 2012 at 00:01

Yesterday, I tried to get to grips with how a capacitive power supply works. Real samples are a bit messy, though.

So let me try something else this time, and simplify a bit:

The setup is very similar, but I’m leaving out the zener diode and the rest, and more importantly, I’m going to feed a real 50 Hz sine wave signal into this circuit, using my little sine wave generator.

Here again, because scopes need to measure with a common ground, I’m placing that common ground in between the resistor and the cap, and I’m using the scope’s internal “invert” feature to treat this as if the channel 1 probe were connected the other way around. Here’s what we get with this new setup:

The vertical scale of the resistor was adjusted to display the same amplitude for the resistor as for the capacitor.

• the yellow line is the voltage over the capacitor
• the blue line is the voltage over the resistor
• the red line is the sum of the yellow and blue lines

The scale of the red line is not quite accurate, but its shape is. So the red line is in essence the input signal.

So what’s going on here?

As you can see, all these signals are 50 Hz sine waves. That’s quite remarkable already. Obviously the red line is a 50 Hz sine wave, since that’s what we’ve been feeding in. But so is the voltage over the capacitor, the voltage over the resistor, and hence also the current through this circuit!

What you see, is a set of sine waves which differ only in phase and in amplitude:

• the voltage over the capacitor (yellow) lags the input signal (red): it’s forever trying to catch up
• the current through the capacitor, i.e. the voltage over the resistor (blue), is leading in phase

And something else, as we saw yesterday: the current through the capacitor is related directly to the slope of the capacitor’s voltage change (i.e. its derivative). When the yellow line is steepest, the blue line is at its highest.

Let’s throw one more calculation into the mix: power. Power is input voltage (red) times input current (blue):

Looks very sine wave’ish again! There is some amplitude variation, which can probably be attributed to signal asymmetry or amplitude differences between the different sine waves. The phase of this wave is different from the ones already shown, but note that it’s also twice the frequency, i.e. 100 Hz.

Let’s step back for a moment. With a purely resistive circuit (as used in a resistive transformer-less supply), the current and voltage would be in lock step, i.e. sine waves with exactly the same phase, and the power consumption would be maximal (high current at times of high voltage).

With this capacitive setup, currents get “moved around”. That means power consumption will be less than when voltage and current match up (since this gives the largest possible results).

I’ll include one more screenshot, this time using the same vertical scale for all signals (except power):

This puts things more in perspective: the voltage over the capacitor (yellow) is slightly lagging the input signal (red) now. And the input current (blue) is out of phase w.r.t. the input signal (red). So the power consumption (red x blue) is substantially lower than with a resistive circuit: when the current is maximal, the input voltage is only a fraction of its maximum range. IOW, we’re drawing current when it “costs” little.

This is why a capacitively coupled supply is cheaper: the electricity company charges us for real power (i.e. V x I). We’re being charged for what happens inside a pure resistor.

But we’re doing a lot more: we’re taking charge out of the AC mains line on one half of the cycle and pushing it back on the other half. It might seem as if that doesn’t use up energy, but it does: current through a wire causes resistive losses (in the form of heat), and “returning” that energy one half cycle later causes those losses again! So the electricity company sees its electricity turn into waste heat, and they can’t charge us for it.

Here’s a thought experiment: suppose you had a huge capacitor, and hooked it up directly to AC mains, next to the electricity meter. According to what we’ve seen, it’ll track the 230V cycles, with current exactly 90% out of phase with AC mains voltage. Huge currents would flow at the time of zero volts. You’d be charged relatively little for the large out of phase current that flows (not quite zero because a practical capacitor has some internal losses that look like a resistive component from the outside). But your garden would be nicely heated by that current in the resistance of wires between the electricity company and your meter…

You can read more about “real”, “reactive”, and “apparent” power on Wikipedia.

(with a tip of the hat to Martyn for helping me understand this stuff a little better)

## Capacitive power supply

In Hardware on Jan 29, 2012 at 00:01

(Thanks for your overwhelming understanding w.r.t. not making the Low-power supply available as kit!)

The concept of the transformer-less capacitive power supply still puzzles me – intuitively I still don’t get it:

(the above image was copied from this excellent site with a web-calculcator for it all)

So what exactly is going on here? Tomorrow, I’ll simplify that circuit in an attempt to really get it, but for now let me show you what I see on the oscilloscope. What I did was feed a ≈ 100 Vpp signal into the above circuit, which is essentially the same as in the Low-power Supply.

To interpret the graph, you need some info:

• the scope ground was connected between the capacitor and the resistor
• the yellow trace is the voltage over the resistor
• the blue trace is the voltage over the capacitor
• the yellow trace is inverted, i.e. negative voltages at the top, positive at the bottom
• zero is the middle of the screen for both signals

Here’s the scope capture:

Ignore the fact that these waves are hideously complex, ignore the red lines for now, and also note that watching voltage over a resistor is the same as watching current through that resistor. Voltage and current are always proportional in a resistor, that’s what defines a resistor (Ohm’s law: voltage = current x resistance).

So what are we seeing here?

Well… when the yellow line is high, the blue line rises sharply. When the yellow line is zero, the blue line is flat.

That makes a lot of sense: the resistor is charging the capacitor. And similarly for negative values, it’s discharging the cap (and then charging it negatively).

So ignoring the zener and the rest of the righthand side of the circuit, this is really all that’s going on: when the input voltage is highly positive, current flows in one direction, charging the cap and dropping to zero, and when the input voltage is highly negative, the whole process unfolds in the opposite direction.

One more piece of the puzzle: current is “charge per time unit” (in units: Amperes is Coulombs per second).

In other words, the capacitor accumulates the charge pushed into it, in either polarity. And while it does so, the resistor “takes the heat”, so to speak: it limits the current by creating a voltage drop over itself.

Please let this sink in, dear reader. It’s essential to get a solid intuitive grasp on what’s going on.

Note also that it really makes no difference at all how complex the input signal is. The resistor and capacitor work in tandem, sharing the task of dealing with that signal. In other words: the capacitor is always trying to catch up!

This is where it gets interesting.

You may or may not have given up in high school when it came to advanced maths / calculus – derivatives and integrals, in particular. If so, then get ready to finally get to grips with these incredible concepts.

Let me explain the red lines in the above image – they are generated by the built-in math functions of this scope. One red line is the integral of the value measured across the resistor, and the other red line is the derivative of the voltage across the capacitor. But here’s the big surprise:

• the integral of the voltage over the resistor is the same as the voltage over the capacitor!
• the derivative of the voltage over the capacitor is the same as the voltage over the resistor!

What’s the point? Well, this means that I didn’t have to measure both signals to see what’s going on. I could have omitted the blue trace, because it can be calculated from the yellow trace (and vice versa). Even though these traces have completely different shapes, they are in fact totally inter-locked and inter-related.

As I said before, the voltage over a resistor is proportional to the current through it. So the derivative of the voltage over the cap is the same as the current through it (the current flowing through the resistor and the capacitor is always the same, since they are connected in series).

The derivative is the rate of change, i.e. the slope of the graph. Integrating the current (i.e. the derivative) is like adding “all the little currents together over time. A capacitor is no more and no less than a “current integrator”.

And that’s exactly the same as saying that a capacitor accumulates charge. It’s like a tiny rechargeable battery, it takes the current pushed through it and it stores that current (as charge). As the charge accumulates, the voltage rises. Loosely speaking, this is the same as saying that it pushes back harder and harder against the incoming current. At some point it pushes back so hard, that no more current comes in. At that same point, there will be zero volts over the resistor, and the voltage over the cap stays constant. Check the graph to see where that happens.

One last observation is that the blue line is a lot smoother than the yellow line. That’s not surprising: when you integrate (accumulate) a jittery signal, things tend to smooth out. That’s why capacitors are also a fundamental component in filters, i.e. circuits which let some frequencies through more and others less. That schematic we’ve been looking at here is also known as an RC circuit – if you ignore the zener and the rest. One way to look at an RC filter is to see the capacitor as the sluggish part, and the resistor as taking up the slack. So with any input signal, the voltage over the cap is related to the low frequencies, while the resistor follows more the high frequencies.

Did this explain how a capacitive power supply works? Probably not. But first we need to get to grips with what a capacitor does, and hopefully this little experiment helped you get some intuition for what’s going on.

I’ll try to take this further tomorrow, by simplifying things a bit. Stay tuned!

## DIY versus outsourcing

In Musings on Jan 28, 2012 at 00:01

Currently on the front page of the JeeLabs shop:

The benefit of doing everything yourself, is that you can make things work exactly as you want them.

The drawback of doing everything yourself, is that you have to do everything yourself…

Having become pretty independent in my work areas, my hobbies, and my income streams over the years, I know all about those trade-offs. Or at least I think I know about most aspects of this DIY-vs-outsourcing range.

It’s a bit like trying to stay on your feet with a floor covered with marbles…

Example: I used to rent a web server (a real physical one, with full root access and Linux on it). No worries about hardware outages or connectivity details. Being housed at an ISP with thousands of servers, means they’ll have round-the-clock watchdogs and support staff, and will jump into action the minute something is seriously wrong.

At the same time, I had total control over the web server software and operating system configuration. With a Linux distribution such as Debian, maintenance was delightfully simple (“apt-get update && apt-get upgrade”).

The flip side is that I had to choose and configure a web server (“lighty” / lighttpd at the time), and technologies to create dynamic database-driven websites (I built my own back then, based on Metakit – my own database).

Did it work? Sure. Did it evolve? Nope. Too busy. Didn’t want to risk breaking anything.

Only thing that setup did was track security updates (automatically). I had two break-ins over the 10 years that this went on. Learned more about rootkits than I care about (they’re evolving to amazingly sophisticated levels).

Did I learn a lot? You bet. And some of that knowledge is priceless and timeless. Big, big benefit.

But I also had to learn lots of stuff I really care very little about. For me, network routing, package installation dependencies, mail server configuration, and lighttpd configuration were a waste of time. The latter because lighttpd wasn’t really kept up to date very actively by its developer(s). Other options became more practical, meaning that all that lighttpd-specific knowledge is now useless to me.

The story is repeating itself right now. Redmine, which I use on http://jeelabs.net/ is not up to date, because I haven’t found a simple upgrade path. The difference is that it’s not just me not updating my stuff, I now have the same stagnant state with stuff from others. So what’s the point of Redmine? As far as I’m concerned, it’s a dead end (luckily, everything in there is stored in Markdown format – a solid long-term standard which I also use for the forum and the weblog).

With the forum, running on Drupal, it’s different again. Module updates are automated more or less, so I tend to track them from time to time. But Drupal itself is a little harder to update. And sure enough, it’s falling behind… With Drupal, I’m also running into not being knowledgeable enough to put it to really good use.

But the reason for writing this post is a different one – see the message at the top.

For the web shop, I use the Shopify web store service. They have the servers (at Rackspace – very good ops, I’ve used them for a couple of years). And Shopify develop and run the web store software (using Ruby on Rails).

They take care of dealing with nasty things such as possible DoS attacks, heavy data security, financial gateway interfaces – lots of important issues I no longer need to worry about. So far so good.

But they have their own agenda:

• some things don’t change, and that’s good: it works, the shop is operational
• some things don’t change, but that’s bad: years have gone by, and they still haven’t got a clue about VAT
• some things change, and that’s good: improvements to the service, new features for customers
• some things change, but that’s bad: they change their API and their XML data structures

That last one is what bites me now. I created a little scripted setup whereby I always pull information about orders from their shop database, to fill my database here with all the details, so I can generate paper invoices, and do the fulfillment of orders here. Doing this here was necessary to be able to do the Value Added Tax thing properly, as required by law and as my accountant wants it, of course.

So to summarize, the choices are:

1. do everything yourself (and pay in time)
2. outsource everything (and pay in money)
3. choose a mix (and deal with the interface changes)

Everything is a trade-off, of course. In my case, I’m moving more and more to #1 as far as operational choices are concerned (own server, own fiber connection), and #2 as far as day-to-day software use is concerned (solid, but actively developed open source software, and Apple hardware + Mac OSX for my main workplaces). These choices are optimal for me, in terms of cost and stability.

The choice to host my own servers was made a lot simpler because I’m running VM’s for the different sites, built from ready-to-run images from TurnKey Linux. What makes them (and others, like Bitnami) different, is that all VMs are automatically backed up to the cloud (Amazon S3 in my case). The way TKL does this is really clever, reducing the amount of data in incremental backups, even for all the records stored in MySQL. So not only are my VM’s pre-configured and run out of the box, they automatically self-update and they automatically self-backup – if anything goes completely wrong, I can switch to cloud-based instances and be up and running again in no time.

TurnKey Linux is an example of using third-party stuff to side-step (and in fact avoid) a massive amount of effort, while retaining maximum operational flexibiity. My Amazon S3 bill is a whopping \$1.01 per month…

But the web shop setup at Shopify is far from optimal. It was supposed to be choice #2, but ended up being #3 due to the mismatch between what I need (a European shop with correct VAT handling) and what they offer (flashy stuff, aimed at the masses). In hindsight, it was a bad choice, but I really don’t want to do this myself.

Oh well, I’ll suffer the consequences – will fix my scripts and get everything going again by next Monday!

PS. My little presentation yesterday at HackersNL #5 can be found here (PDF) – for those who read Dutch.

## Can’t be done

In Hardware on Jan 27, 2012 at 00:01

As you may know from posts a short while ago, I’ve been working on creating an ultra-low power supply, providing just enough energy to a JeeNode or JeeNode Micro to let it do a little work, report some data over wireless, and then go to sleep most of the time.

I even designed a PCB for this thing and had a bunch of them produced:

The good news is that it works as intended and that I’ll be using this circuit for some projects.

The bad news is that they won’t be available as kits in the shop. Ironically, this was the first time where I actually had a batch of kits all wrapped up and ready to go, ahead of time.

But the reality is that I can’t pull it off. For two different reasons:

• The circuit is connected to live AC mains @ 230 VAC and that means there is a serious risk if you build this stuff, try it out, and then hurt yourself because of some mistake. And even after that, there is the risk that the whole circuit is not properly protected, exposing these voltages (even just humidity and condensation).

• The other risk is that once everything works, it gets built-in for permanent use and becomes part of your house. What if it gets wet or malfunctions for some other reason, and your house burns down?

As supplier, I’d be liable (rightly so, BTW – there is no excuse for selling stuff which might be dangerous).

The hardest part of all is that even if an accident has nothing to do with this Low-power Supply, I still have to prove that this stuff is safe under any circumstance and that it complies with all regulations!

I’m not willing to go there. Life’s too short and I don’t have the pushing power to go through it all.

Having said this, I do intend to use this supply myself and create all sorts of nodes for use here at JeeLabs. Because I know the risks, I know which failsafe features have been built into the supply, and I’m ok with it:

The design is available in the Café, to document what I’ve done and for others to do whatever they like with it.

I’m not happy about this decision, in fact I hate it. I’m really proud of finding out that it is possible to create sensor nodes which run off just 12 mW of AC mains power. But the right thing to do is to stop here.

## Tektronix 475

In Hardware on Jan 26, 2012 at 00:01

Oh boy, I’ve been bitten by the collector’s bug…

Couldn’t resist an excellent offer on Marktplaats (the Dutch equivalent of eBay) for a fully operational analog scope built in the late 70’s. The Tektronix 475 is, ehm… slightly larger than the Hameg HMO2024:

Then again, they are quite comparable – both are specified as 200 MHz bandwidth. Check ’em out:

The Tek will need to be re-calibrated, but as far as I can tell all the functions work and all the switches, knobs, and indicators are in good order. The previous owner said he had used it for a long time, but not intensively.

First thing I had to try was the analog clock, of course:

Apart from that? Oh, I don’t know. I’ll refurbish and re-calibrate it one day, there’s lots of info about this classic workhorse out on the web, and I really would like to learn how to diagnose and repair stuff. Even old stuff.

This is a single-beam unit, meaning it can’t show two signals at the same time. Newer and more advanced models are dual-beam, but this one has to either “alternate” between the two beam displays, or “chop” them up and draw bits of one and the other in an interleaved fashion. It’s also not a storage scope, so you’ve got to look very carefully if you want to see one-shot events – the display on the screen shows only as long as the phosphor glow lasts!

Fantastic engineering. Electronics, mechanical, operation, documentation, service – everything!

Would I have bought the Hameg if I’d had this one at the time? You bet – the “S” in DSO is a game changer, especially with microcontrollers and physical computing. But that huge Tek brick is more endearing :)

Heh, I’ve never before collected anything in my life – this is fun!

## The PWR vs the +3V pin

In AVR, Hardware on Jan 25, 2012 at 00:01

JeeNodes and plugs use 6-pin headers with the following pin assignment:

(there’s usually a big printed dot near the PWR pin for orientation)

There has been some confusion about what PWR is w.r.t. +3V and how to use it, so let me elaborate a bit.

First: “+3V” is the main regulated power reference for most chips and circuits. And to make it more complicated: it’s actually 3.3V, not 3.0V. The “+3V” label merely identifies the pin (VCC would be too confusing).

The ATmega on the JeeNode, as well as most (but not all) chips on attached plugs run on this 3.3V voltage level. It is also the reference level for all digital I/O (0 = 0V, 1 = 3.3V), as well as for the ADC when used for analog inputs (1023 steps of 3.22580645161 millivolt each).

As for the other supply pin: “PWR” is usually a higher voltage from which +3V is derived.

There’s a voltage regulator on the JeeNode which can take any input voltage on “PWR” up to about 13V as input and which produces the 3.3V regulated voltage on the “+3V” pin.

The JeeNode regulator has some limits: it’s can’t supply more than 250 mA and it can’t dissipate more than about 600 mW. It’ll shutdown if either of these are exceeded (and it’ll get damaged if you feed it more than 13V). These figures are fairly limiting: if you run a JeeNode off 12V on the PWR pin, then it actually won’t be able to supply more than 70 mA. With 5V on the PWR pin, the limit will be current, not power dissipation, i.e. 250 mA max.

That’s for a JeeNode with through-hole components, i.e. an MCP1702 regulator in a TO-92 package. With the JeeNode SMD and JeeNode USB, you get even less power from the regulator: at most about 250 mW of heat dissipation. That’s 150 mA @ 5V, and only 28 mA @ 12V. In short: the JN SMD and JN USB are not really meant to be powered from more than 5V – or at least not without an extra external regulator (on the plus side: the MCP1703 supports up to 16V on the PWR pin). Note also that the JeeNode USB doesn’t support more than 7V on the PWR pin, due to limitations of the on-board LiPo charger – but that should not be an issue since it’s really only meant to be powered from 5V via USB.

As you can see, there are several limiting factors as to what voltage is supported on the PWR pin. Keep in mind that JeeNodes were designed for ultra-low power consumption, and the regulator was selected for its extremely low idle current draw, not its “high-end” characteristics.

But that’s not all…

One trap for the unwary is with the JeeNode USB: it doesn’t actually feed 5V to the PWR pin when connected to USB but only 4.2V. This is due to the LiPo charger circuit, which allows a LiPo battery to be connected between PWR and GND. With a LiPo battery, the JeeNode USB becomes a very convenient stand-alone unit: low-power untethered operation while not connected to USB, and automatic LiPo charging while connected to USB. It even has a voltage divider on board to monitor the LiPo battery voltage (tied to PC6, i.e. analog 6 in Arduino-speak).

The trouble here is that when you connect plugs to the JeeNode USB, you won’t get the full 5V you might expect. This affects all those plugs which don’t run entirely off +3V but expect some higher voltage on PWR.

And here’s another tricky situation…

With the AA Power Board, you can run JeeNodes off a single AA cell. In this case, there isn’t a voltage higher than 3.3V anywhere in the circuit – so what to do with the PWR line? Well, there’s a solder jumper on the AA board to let you decide: it’s normally open, but you can connect it to either +3V or to the battery “+” (i.e. 1.2..1.5V). Obviously, this setup will be even less suited for plugs which expect a higher voltage than 3.3V to operate.

As you see, the +3V pin is solidly specified as always being 3.3V, but the PWR pin level can be all over the map.

The following plugs are especially affected:

• the LCD Plug will work, when used with a 3.3V display (as shipped by JeeLabs), but will only be suitable with 5V displays if PWR carries 5V

• the Graphics Board assumes that PWR is 5V, because the display needs it (it’ll probably still work with 4.2V, but PWR should not be above 5V)

Most plugs will be fine, though, since they only use the +3V supply. The only issue here is to make sure that the total current consumption off +3V is not too high.

Using a JeeNode with an unregulated power supply

The maximum allowed voltage on the PWR pin is about 13V. Unfortunately, many 12V power bricks are fairly badly calibrated, and often deliver substantially more than 12V under no-load conditions. You could easily damage the JeeNode’s on-board regulator with a cheap 12V power brick – better use a 5V or 9V brick.

If you do want to power a JeeNode off 12V (perhaps you need 12V on the rest of the circuit for LEDs, relays, or motor power), then the best approach is to insert a 5V regulator and feed that 5V level to PWR. This can easily be done with a “7805” regulator chip, which is available from many electronics parts sources.

## Too much heat

In Hardware on Jan 24, 2012 at 00:01

To avoid switching noise near the work bench, I wanted to drive my LED strips from a plain ol’ transformer -> bridge -> capacitor supply. It would have to supply about 2A @ 12V for my LEDs. Here’s the setup:

Ignore the diodes at the top, these were 1N4004 diodes which weren’t quite up to the task. The ones at the bottom right are Schottky diodes for a lower voltage drop, rated at 5A. The capacitor is 2200 µF, but ripple isn’t an issue.

Alas, the heat from this thing is excessive. I even went for an artsy swiss-cheese design:

Trouble is the transformer (and surprisingly not the diodes!) – I measured them both, with everything closed:

Diodes heated up to 75°C – but the transformer went all the way up to well over 90°C within the hour! AC mains consumption is 50W, so this silly thing is eating up half the power while trying to behave like a stove…

The transformer is a cheap 2x6V @ 2.5A unit I had lying around (draws 3.7W, even without any load). I’ll keep this as a high-ripple 12..20 VDC power brick for testing – but it definitely can’t be used continuously @ 2 Amps!

PS. If you’d like to meet up – I’ll be presenting JeeStuff at HackersNL coming Thursday evening in Utrecht.

## Flash from the past

In Hardware on Jan 23, 2012 at 00:01

A while back, Jeroen mentioned on the forum that he had an ancient GM5655 Philips oscilloscope, and since he lives in Houten we thought it’d be fun to put it side-by-side with my new Hameg scope I keep generating screen shots with in this weblog (ad nauseam for some, I suspect…). Here’s his vintage 1955 hardware (from a web image) – just imagine how attractive that must have looked to geeks back then:

It’s single-channel unit, with a sweep generator which can go “all the way” up to 30,000 Hz. The horizontal deflection can also be driven externally, making this scope X-Y capable. Vertical sensitivity is up to 60 mV/cm, horizontal up to 100 mV/cm. No positioning, no magnification, nothing. This is as basic as a scope can be.

Jeroen dropped by a few days ago and we had a go at it. Unfortunately, we couldn’t get it to work. The horizontal deflection appears to be broken (not just the sweep generator, since it also didn’t respond to external signals). Most probably one or more of the “tar capacitors” has failed. It’s always them capacitors with old equipment…

Neither of us felt confident enough to go about messing with this thing while powered on (vacuum tubes, and especially the CRT, run on high voltage). But the least we could do is open it up and marvel at how things were constructed back then. No semiconductors and no printed circuit boards – pretty amazing, if you think about it.

It’s a pretty scruffy unit, once you open it up!

Note the big tar caps and the “flying” construction, especially around the rotary switches:

Here’s the other side, with what looks like just the vertical input circuit:

Here’s the top view, with 6 vacuum tubes in total:

The bottom view, with one more tube and what looks like a bunch of electrolytic power supply caps to me:

All this was manually assembled, so each unit had to be tested and debugged, since it wouldn’t take much to hook up things incorrectly. The invention of the printed circuit board not only creates a mechanical platform to hold everything in place (especially for low-voltage semiconductors), it also acts as a self-documenting area during assembly, since all the spots are already marked with what goes where.

Amazing stuff – I’m tempted to get a (somewhat more modern) analog scope off eBay, just for the fun of it :)

## More accurate 10 MHz

In Hardware on Jan 22, 2012 at 00:01

To follow up on yesterday’s post, here’s a similar TCXO oscillator which is considerably more accurate:

It’s a 10.000 MHz unit which has been calibrated and claims a 0.1 ppm accuracy. That’s 10 MHz ± 1 Hz, i.e. 7 digits. Here’s the output signal, which appears to be AC coupled:

Not bad for a low-cost unit. I got it from the RFcandy shop. Current consumption is 0.94 mA @ 5V.

Once you start looking into this stuff, all sorts of things pop up on the web. There’s a group of amateurs who call themselves Time-Nuts (terrific name!) and who aim to keep track of time as accurately as they can – with pretty amazing results. In a comment yesterday, John Beale pointed me to a web page with info about the Rubidium clocks now available cheaply on eBay.

I found this page most entertaining, summarizing the history of accurate time-keeping in a few slides.

## Precision time, anyone?

In Hardware on Jan 21, 2012 at 00:01

The RTC Plug uses a DS1340 chip to keep track of time. It has its own on-board coin cell and 32 KHz crystal, so that it can keep running when power to the JeeNode is switched off.

The 32,768 Hz crystal is rated at 20 ppm, with 3 ppm aging in the first year. A year has about 3600 * 24 * 365.25 = 31557600 seconds. With 20 ppm, the RTC Plug can be some 630 seconds off at the end of the year, i.e. close to one minute per month – worst case, that is. It’s fine for lots of uses, but evidently not all…

Here’s a new plug prototype, designed by Lennart Herlaar:

It’s based on the DS3231 chip, which includes a “TXCO”, i.e. a Temperature Compensated Xtal Oscillator. There are many ways to improve the stability of a crystal oscillator, but this one is pretty nifty because it’s low-power (unlike an oven-based technique, which puts the crystal in an controlled temperature environment). The idea is that the chip periodically measures the ambient temperature, and then adjusts the capacitive loading of the crystal according to a calibrated function of temperature. IOW, it knows how to compensate its on-board crystal.

The DS3231 is specified at 2 ppm for temperatures 0 .. 40°C, i.e. ten times more accurate than the above crystal. So this clock will stay on time with an error of at most one minute per year, i.e. about a second per week.

For something, eh… slightly better – you could consider a Rubidium Frequency Standard with 50 ppt accuracy, i.e. well under a millisecond per year error. But don’t expect to run it off a coin cell – it draws about 11 Watt :)

If there’s enough interest, this plug could be added to the shop…

## Seeing glitches

In Hardware on Jan 20, 2012 at 00:01

There’s one dirty little secret about most digital storage oscilloscopes (DSOs) which puts them way behind the capabilities of their analog brethren: screen update rate.

For a scope to present a trace on screen, it has to do a lot of signal processing. After all, 1 GSa/s means its acquiring 1 billion data values per second. And although we’re not able to really see that with our eyes, we do see things that stay on the screen for a few milliseconds.

One trick is to turn on persistence. On analog scopes, that’s a pretty nifty feature whereby the image generated from the beam hitting the screen is made to stay visible for a while. Either via a phosphor coating which keeps on glowing for a while, or by constantly re-sending the same beam pattern to keep the visual display going.

Digital scopes can simulate this. All they need to do is leave the pixels on their LCD display as is, right?

Unfortunately, it’s a lot more complicated than that. If you just refresh the screen a few times a second, then you’re still going to miss a huge amount of detail. Let’s take a periodic 1 MHz signal: to display everything measured, the display needs to be updated 1,000,000 times per second, which means each “sweep” would only remain visible for 1 µs. That won’t do – our slow eyes wouldn’t see a darn thing, especially glitches which occur very infrequently. So what a DSO does, is simulate persistence by merging new sweeps into what’s being shown, and then take old sweeps out of the picture a bit later (try implementing that – efficiently – !).

To test this stuff, I used the following sketch (which is based on this pin flipping trick):

It generates pulses at ≈ 1 MHz, but every once in 10,000 pulses, it messes up the timing. Note that interrupts are turned off, so this thing is as stable as the clock it’s running on (a JeeNode with a 16 MHz resonator in this case).

One glitch every 10,000 pulses at ≈ 1 MHz means there are 100 glitches per second. That should be constantly visible on the screen, right? Well… not so on my scope. I enabled 10s persistence, i.e. sweeps will fade after 10s:

That’s two glitches (the actual display is a bit erratic, but the position of the glitch pulses is absolutely repeatable).

IOW, this scope is showing only one out of every 500 pulses on the screen, on average!

This is why DSO manufacturers report a “waveform/sec” value in their specs. In this case, we are getting 2,000 waveforms per second, even though a scope could theoretically sweep 500,000 times per second on this.

An analog scope would have no problem whatsoever with this. To show the same two pulses in each sweep, it could trigger a new sweep 500,000 times per second, or maybe even “only” 100,000 but that would still show 10 glitches per second, i.e. a nearly constant visual display of the glitches. Fifty times more often than my DSO, anyway.

That 2,000 wf/s figure is an optimistic one, BTW. With more channels enabled, or things like signal stats calculated or the math function applied, this value can drop substantially. Meaning you’ll see even less glitches.

What this tells me, is that the Hameg needs about 500 µs of processing time to get 1 channel of acquired data onto the screen in its most basic form.

Don’t get me wrong: technically that’s an astonishing achievement. It’s not just copying a few bytes and setting a few pixels. It’s (always!) performing the emulated-persistence trick – because with persistence turned off, I still see a glitch every few seconds, which means that the LCD display is showing the glitch for a substantial fraction of a second – much longer than the 1 µs (or even 500 µs) sweep rate would suggest. Besides, you can see that fading is also implemented, so it’s not just drawing pixels but actually fooling around with color intensities.

There are some scopes which get much higher waverform/sec rates, such as the Agilent 2000X (50,000 wf/s) and the Agilent 3000X (1,000,000 wf/s) series. But they are twice the price, and even have lower specs in other areas.

Does it matter? Not for me. Being aware of this is good, though – far more important than fixing it. Note also that IF – that’s a very big if – you know what you’re looking for, then there are usually other ways to find these things. In this case, triggering on a negative pulse width under 900 ns captures all those glitchy pulses, for example.

As so much in life, it’s all about trade-offs. Analog / digital, brands, and of course… your needs and budget.

## The beat still goes on

In Hardware on Jan 19, 2012 at 00:01

Recently, the radioBlip sketch reached yet another milestone: it’s been running for 500 days on one LiPo charge!

Seems like a good time to start a new duration test, this time with a JeeNode Micro:

Since I don’t want to have to wait yet another 500 days, I decided to up the ante:

The JeeNode Micro includes holes for a CR2032 3V battery holder, so why not try that for a change, eh?

The sketch was modified slightly, to set the proper clock divider on startup:

I’ve set it up as node 18, and it’s been blipping happily:

Let’s see how many days that little JNµ can dance the Sputnik shuffle…

## Putting the JNµ to sleep

In AVR, Hardware, Software on Jan 18, 2012 at 00:01

The Sleepy::loseSomeTime() code in the Ports library was never tested on a JeeNode Micro. Turns out that only a minor library difference kept it from working (the arduino-tiny library has its own version of millis(), etc):

So now, the JNµ can be put to sleep as well. Here’s the jouleTest sketch I used, tweaked to run on the JNµ as well:

And sure enough, about once every 10 seconds it shows that familiar packet-transmit current consumption:

The blue line is the AC-coupled supply voltage, a 3x AA Eneloop battery pack in this case. It supplies about 3.8V, but when running off a 1000 µF cap, it looks like this continues to work down to 1.8V (well below the RFM12B’s minimum 2.2V specs) – although with only about half the transmit power by then.

This current use fingerprint is almost identical to the ATmega328 running this same code. Not surprising really, since it’s the RFM12B which determines most of the power consumption, not the ATmega vs ATtiny difference.

Onwards!

## Pushing the scope limits

In Hardware on Jan 17, 2012 at 00:01

After having become reasonably familiar with the new Hameg HMO2024 oscilloscope, I wanted to find out just what its limits are. Came up with this screenshot:

There’s quite a bit of information in here.

First of all, these scopes can do double-rate sampling when you don’t activate all the channels. Channels 1 and 2 share some hardware, and so do 3 and 4, so by enabling only one of each block, the scope can actually double its sampling rate to 2 GSa/s i.s.o. 1 GSa/s and also “stack” its memory depth to 2 MB per channel, i.s.o. 1 MB. Or to put it another way: a 4-channel oscilloscope can be used as a 2-channel unit with twice the specs.

I switched the acquisition to display in “sample-and-hold” mode instead of the normal Sin X interpolation mode, so the steps shown above represent the real sampling that’s taking place. As you can see, there are 4 steps per division, with 2 ns/div, so that’s indeed 2 billion samples per second.

The top was zoomed out as far as I could while still showing the fastest supported 2 ns divisions in the detail window, which ends up being 50 µs/div. Running the scope timebase any slower will cause it to reduce its sample rate so it can still capture the required 12 horizontal divisions full of sampling data. In this case we see 12 x 50 µs = 600 µs of data on the screen, while the detail view is zoomed in to 2 GSa/s (25,000x).

That’s 1.2 million samples of data – a hefty pile of bits flying around in this thing while it’s running!

But there’s actually more, because of the stacked memory. When I pan across the 50 µs/div display, I can see that data was collected from 575 µs before the trigger point to 525 µs after the trigger point. Which is 1100 µs of collected data, IOW that’s 2.2 MB of acquired sample data – again, more than the specs in the brochure!

The vertical signal acquisition hardware is also very impressive. This is one of the few scopes I know of which will go down all the way to 1 mV per division. That’s real sampling, not some sort of digitally enhanced sensitivity, as you can see from the fact that the data steps really are 1 pixel in the vertical direction.

It might not seem important to go down that low, but it’s quite useful actually when measuring voltage drop over a shunt resistor. Which is what I’ve been doing quite a bit to display current usage of JeeNodes while in ultra low-power sleep. The other benefit is that you can still go down to 10 mV/div with the standard 1:10 probes that come with the scope (I’ve got a few 1:1/1:10 switchable no-brand probes for when I really need the extra sensitivity).

The red line is created by using the “Quick Math” function, subtracting the channel 3 signal from channel 1 in this case. The nice thing is that the math function supports 20x more magnification than the input channels. So with some trickery, this scope can display down to 50 µV/div: subtract a spare channel set to “GND” from the input signal, and magnify the resulting math output 20x. It’s a coarse (digital) way of magnifying the display, but still.

The actual data shown above is what the scope displays with no probe connected, BTW. This is the residual noise in the scope’s input circuitry and it really is impressively low-noise – just a quarter millivolt peak-to-peak.

At the other end of the range, the scope will go up to 10 V/div, i.e. 80V full scale. That’s ≈ 6 orders of magnitude of usable range on each channel. Wow… Hameg (and R&S) did some pretty serious engineering to achieve this.

PS. I’m ready to ditch my DSO-2090 USB scope – it’s unlikely that I’ll use it with this HMO2024 now at hand.

Update – same for the Logic Analyzer – a LAP-16032U, if you’re interested in it, let me know.

## Another AA booster

In Hardware on Jan 16, 2012 at 00:01

Out of curiosity, I’ve been doodling around with the AS1323 boost regulator chip, as suggested by someone in the comments. It’s not super efficient, but it does claim an extraordinarily low quiescent current of 1.6 µA.

Hooking up such a tiny chip is quite a challenge:

The trouble is that this stuff can’t be spread out too much – the specs say that both input and output caps have to be within 5 mm of the chip. So I tied it to a pcb – mostly for stability – and then wired everything up around it.

Without any load, this thing operates in quite an efficient mode:

The yellow trace is the voltage drop across a 10 Ω low-side resistor, the blue trace is the output, but AC coupled, i.e. showing only the ripple voltage.

The red line is the math function to integrate total power use in Coulombs – more on that later.

If you look at the top overview graphs, you can see the current blips which are over 160 ms apart, i.e. this thing is activating only 6 times a second. And each current pulse lasts only about 150 µs. The peak current on the input side, i.e. drawn from the battery, is about 12.5 mA.

Let’s put a 1 kΩ load on the 3.3V output line:

I’ve adjusted the scale a bit. The switcher is now operating at about 11 KHz. The peak current drawn is almost 18 mA, but note also that the current never drops to 0 anymore – the baseline of that yellow trace is 2 divisions down from the top, so that’s about 6 mA (as expected, since the load is always drawing current).

Now let’s push it and change the output load to 100 Ω, i.e. about 33 mA @ 3.3V. To make that work, I had to change the input sense resistor to 1 Ω:

The baseline for the yellow trace is now halfway, same as for the blue line.

I also added a third probe, the green line monitors output voltage, which is indeed steady at 3.3V (both red and green lines are based at the bottom of the screen). Note the huge peak current draw on the battery: over 290 mA!

Let’s try to understand what’s going on in this last case. First of all, with a 1 Ω sense resistor, a 190..290 mA current draw creates a voltage drop of around 0.25V – which means the battery voltage isn’t really reaching the switching regulator. The battery was measured to be at 1.37V, so the switcher is getting only about 1.1V on average. The datasheet says that it will only be 70..75% efficient on such an input voltage, when generating the 3.3V output.

The 100 Ω output load draws about 33 mA. That’s at 3.3V, so a perfect step-up regulator would need to draw 3x as much when running off 1.1V, i.e. 100 mA. A 70% efficient switcher would draw about 150 mA (0.70 x 150 ≈ 100). What I’m seeing here is more like a 40% efficient switching result (0.40 x 250 = 100) – hm, not sure why…

The other way to determine average current consumption, is to do some Coulomb counting…

In the first screenshot, each blip uses about 900 nanocoulombs (the red line rises 4.5 divisions over the entire width of of the screen). With 6 blips per second, we use 5.4 µC each second, i.e. 5.4 µA average current draw (not quite the 1.6 µA I expected, but still very impressive for an unloaded step-up regulator).

The second graph is trickier. We need to figure out the Coulombs increase per repetitive cycle. My guess would be around 820 nC. Multiply by the switching frequency of 11.25 KHz, and you get 9.2 mC per second, i.e. 9.2 mA average battery current to deliver about 3.3 mA @ 3.3V.

Gotta be a bit careful here. It turns out that the battery (which is a bit old), still delivers 1.44V at this lower power level. Also, since I’m using a 10 Ω current sense resistor in this case, there’s 92 mV wasted in that resistor. That leaves about 1.35V going in. A perfect switcher would draw 3.3V / 1.35V * 3.3mA = 8.07 mA. We’re pulling 9.2 mA, which is about 87% efficiency. That seems a bit optimistic, since the AS1323 doesn’t really go much further than 80%. Oh well, there are probably several measurement errors in my quick and dirty test setup.

For the third case with the 100 Ω load, I end up with a figure of 215 mC/s, i.e. an average current draw of 215 mA. Better than before but still under 50% efficiency.

One more datapoint: with a 100 kΩ load, the switching frequency goes to 120 Hz, while still using about 800 nC per cycle, i.e. ≈ 100 µC per second, or 100 µA. Again, pretty good for what is essentially a 33 µA load @ 3.3V – even if all these estimates are off by perhaps 25%.

So this chip might work quite well for bursty ultra-low power contexts such as a mostly-sleeping JeeNode!

## New payment options

In Musings on Jan 15, 2012 at 00:01

The JeeLabs Shop has gained a new payment option, as provided by the DIRECTebanking service:

This is a German site which supports direct bank-to-bank transfers. Looks like it’s working in 5 countries:

• Austria
• Belgium
• Germany
• Netherlands
• Switzerland

I can’t find a trace of UK or Italy in the setup, even though it’s mentioned on their web site. My impression is that this service is still very young – the “Payment Network AG” company behind this was registered last October. But the good news is that their support is responsive and effective, by email as well as by phone.

One benefit for customers is speed: I get immediate notification, avoiding the usual 1..3 day delay normally involved with bank transfers. The other benefit is convenience, since you can complete the payment as part of the order, instead of having to switch to your online bank account and manually copy all the relevant info.

The benefit for me is lower cost: a third of what PayPal charges (it does add up: VAT, payment/bank/shop fees).

The thing with this sort of service, is that it’s very hard for me to get an impression of how well it works in practice. I did a “test payment” while setting things up, but that’s a weak approximation of the whole process when using it for real, and I can only do a more realistic test with my own country and my own bank account.

So if you ever feel an uncontrollable urge to order something from the JeeLabs web shop (yeah, I know, it’s unlikely) and live in one of the above-mentioned countries, then please feel free to give this a go:

The name is in German (Sofort Überweisung), but the page will be in English by default (all pages are available in multiple languages by clicking on the flag – top right).

Please feel free to email me with anything odd (or neat) which comes up, especially if it doesn’t work as expected of course. I can easily cancel an entire transaction if things get really out of hand.

But with a little luck, life will simply have become one notch simpler with this new option – for everyone!

## Manual V-scoring

In Hardware on Jan 14, 2012 at 00:01

V-scoring is a low-cost way to cut up printed circuit boards. I use it in combination with routing to get al ’em plugs made out of larger panels. It consists of slightly cutting into the PCB material from both sides – when done properly, the resulting boards can be snapped off quite easily by hand.

Recently someone gave me a really neat breakout panel for SOIC and TSSOP IC’s. These are useful to try out SMD chips on a breadboard. Except that the board I got was still panelized…

Can’t look a gift horse in the mouth, and since I don’t have a mini bandsaw or such, I had to find another way.

As it turns out, it’s quite easy to do the v-scoring by hand:

The basic idea is to lightly scratch all the lines about three times, and once there’s a decent groove, just take the hobby knife and cut two more times, pressing down fairly hard. Rinse and repeat for all the cuts on both sides, and things will come apart by pressing down firmly. Here’s what I ended up with after about 15 minutes:

The edges can be a bit rough, as usual with v-scoring, but those rough bits can easily be scratched off with the knife.

And this is what it’s all about:

## Solder fumes

In Hardware on Jan 13, 2012 at 00:01

Have you noticed that solder fumes always tend to rise up into your nose? As the type of solder I’m using is particularly irritating, I decided to do something about it, ending up with a very low-tech solution…

Normal fume extractors (Dutch link) tend to suck the air in, filtering it through a carbon filter to actually remove the fumes from the air, but I find them a bit unwieldy. Yet another power cable to clutter my workbench.

Here’s my solution:

A small 12V brushless PC fan, which happens to still start up and rotate reliably at 3.6V, as provided by three Eneloop AA batteries. Stuck to a battery pack (with on/off switch) using hot glue, which also doubles as weighted base for it all. The fan is slanted slightly downwards, to better cover the area on the table.

The result is whisper quiet and generates a micro breeze which gently diverts the solder fumes away from my nose. This particular fan draws only 30 mA @ 3.6V, so it’ll last some 70 hours on a single battery pack. And since these are rechargeable batteries of which I keep a constant supply, that’s plenty for me.

Long live re-use!

## Ground noise

In Hardware on Jan 12, 2012 at 00:01

To try and improve noise levels during measurements (and as general ESD precaution), I went “green”:

That’s a green ESD mat, covering almost the entire workbench. It’s hooked up to the radiator for grounding. Note that the mat only provides a “dissipative” connection to ground, the surface still has several MΩ’s of resistance. It’s just to get rid of static electricity and to offer a clean protective working surface. Got the mat from Farnell, BTW.

Here’s what I see when pushing a scope probe onto the mat:

A clear 50 Hz pattern of a couple of volts (the amplitude increases when the probe is pushed more firmly onto the mat). This is with a standard 10 MΩ high impedance probe. The big puzzle is: where does this come from?

My explanation for now, is that the scope ground is “floating” a bit, due to the different devices hooked up to the house wiring. Note that the mat is tied to the radiator, not to the ground of AC mains. Since there isn’t any current flowing through the heating system (I hope!), I’m inclined to trust it more as being the “real” ground potential.

It’s no doubt completely harmless. Measuring AC current between these two ground levels with my most sensitive multimeter (a Voltcraft VC940), I see a very occasional blip of up to 0.20 µA flowing. Well under a microwatt.

To give an idea how crazy things can get, here’s the mat with nothing connected – turning it into one big antenna:

Who knows, maybe one day we could harvest even this sort of energy, eh?

## Frequency generator

In Hardware on Jan 11, 2012 at 00:01

A long time ago, I got this DDS-60 kit, which is a small circuit based on an AD9851 DDS chip:

It has everything on board to generate a sine wave from 0..30 MHz, and my intention was to hook it up to a JeeNode (as part of a long term plan of mine to set up a more extensive wirelessly-controlled electronics lab):

Never got it to work at the time, but now with the new scope, there really is no excuse anymore. First check, as indicated in their build instructions, is to verify that the crystal oscillator is feeding a 30 MHz clock into the chip:

Looking good. Very impressive rise and fall times, BTW.

When driven at 30 MHz, the AD9851 output frequency is settable in steps of 0.006984919 Hz. In other words, a multiplier of 1000 will generate a sine wave of ≈ 7 Hz.

Here’s the output when programmed to generate 10 MHz (multiplier 1431655765, i.e. 9999999.9977 Hz):

Whoa… it’s 10 MHz, but a far cry from a sine wave. Ah, but that’s not really surprising: this thing uses DDS to synthesize a sine wave, as recently described on this weblog. With 30 MHz sample rate, i.e. 3 samples per wave, it’s not really possible to create a decent 10 MHz sine wave (not even a symmetrical shape in fact, as you can see).

But the AD9851 has a trick up its sleeve: it includes a “6x” multiplier option, which causes it to internally generate a reference frequency which is 6x the incoming clock, i.e. 180 MHz in this case.

Using that, and adjusting the frequency setting to work at 180 MSa/sec, we get a much better approximation:

Still not perfect, but by analyzing the FFT of this signal, we can find out what’s going on:

This output signal is made up mostly of a 10 MHz sine, with another peak at 90 MHz.

Unfortunately, the output circuit on this board isn’t working yet (this is what probably threw me off when trying this circuit before), so I can’t test the effect of the 60 MHz low-pass filter yet. It won’t filter out the 30 MHz residue visible in that last picture, but should definitely reduce the frequency components over 60 MHz.

Ok, all the important bits seem to work – I “only” need to troubleshoot that analog back end a bit more.

Update – I found the problem: the SMD trimpot was fractured, i.e. no contact. I’ve replaced it with a fixed 220 Ω resistor for now – this brings the output to ≈ 680 mVpp (or 350 mVpp into 50 Ω) – the sine wave output is now considerably cleaner, but several of the frequency peaks ≥ 90 MHz are still present:

I suspect that the 30 MHz clock is “feeding through” somewhere, perhaps better decoupling would avoid that.

## Browsing the Arduino run-time code

In AVR, Software on Jan 10, 2012 at 00:01

The Arduino IDE is a thin wrapper around the avr-gcc compiler and the avr-libc run-time library. It also includes a fairly basic IDE, i.e. a text editor and conventions for managing projects, in the form of “sketches” and libraries.

I prefer to use my own programmer’s editor, because it supports multiple programming languages and has a lot more features for software development (such as Git integration, code folding, and save-on-lose-focus). The Arduino IDE supports external editors by disabling its own one – which is an option in the preferences:

Now I can simply use my own editor and switch to the Arduino IDE for compiling and uploading.

One advantage of using an external editor, is that you can look at other source code than just your own sketches. In the rest of this post, I’m going to describe how to look at one of the most interesting parts of the Arduino IDE: its run-time library, i.e. the Wiring code which adds supports for everything which makes an Arduino different from the ATmega’s on which it is based.

Note: what follows is specific for Mac OSX, but apart from the location of these files and the editor used, you should be able to transpose all of this to your own beloved computer environment.

The first task, is to figure out where the Arduino IDE’s run-time code is located. In Mac OSX, this code is located inside the Arduino application. To view this area, you can right-click on the Arduino app:

This leads to the following directory structure:

The interesting bits are inside the “hardware” folder:

Here are the first few lines of “Arduino.h”, for example (this used to be “WProgram.h”):

These source files are where everything specific to the Arduino IDE’s runtime happens. The “Serial” object, and the “millis()” code, for example. If you want to really understand what the Arduino is about, then it’s well worth going through some of these files. As you’ll find out, there’s no magic once you start looking in the right places.

Try it!

## Fritzing

In Hardware on Jan 9, 2012 at 00:01

The quickest way to describe what Fritzing is about, is to quote the first paragraph on their site:

Fritzing is an open-source initiative to support designers, artists, researchers and hobbyists to work creatively with interactive electronics. We are creating a software and website in the spirit of Processing and Arduino, developing a tool that allows users to document their prototypes, share them with others, teach electronics in a classroom, and to create a pcb layout for professional manufacturing.

It has been around for a while, evolving and improving at a steady pace. Here’s a screen shot of the main window:

The neat bit is that support has now been added for the JeeNode, as well as support for the main two prototyping / extension mechanisms, the JeePlug and the Carrier Card. Just search for the “JeeLabs” keyword:

So now you can use Fritzing to design and document projects, and create printed circuit boards for them!

In Hardware, Software on Jan 8, 2012 at 00:01

Here is a new snoozeBlink sketch which can run off the new experimental 12 mW Low-power Supply:

It does all the right things to start off in low-power mode and puts the ATmega to sleep, even as the LED blinks!

The LED is a normal red LED with a forward voltage of about 1.6V and with a 470 Ω series resistor. The result:

(lots of noise because I’m using the default 1:10 probe and the scope at its most sensitive 1 mV/div setting)

Voltage over the 100 µF reservoir cap in blue, current consumption in yellow. You can see the startup dip when the cap reaches about 6V, then the 2s wait, and then the LED blink at about 2 Hz with a 10% duty cycle. There’s not much energy to spare – the reservoir cap doesn’t even get a chance to fully re-charge between blinks.

After about 4 seconds, I turned off the power to find out what would happen. Yet there’s still enough energy left to get two more full blinks, and then an aborted blink as the reservoir cap voltage drops below 3V.

Note how the power consumption is just 3 mA while the LED is turned on. The ATmega itself is hardly ever running (the very brief 10 mA peaks got filtered out in this scope capture).

It can even be made to flash with a 26 mA LED current (omitting the resistor) for 16 ms @ 2 Hz. In this case the reservoir cap voltage varied from 9.4 to 4.4 V, again leaving very little energy to spare. Maybe one day this can be refined to drive a TRIAC, which needs very frequent but brief pulses (a BT137, BTA312, or L6004L3?).

But there’s actually something extra-ordinary going on with that power-up sequence – let’s investigate:

The BIG surprise? This is running on a standard JeeNode with standard bootstrap – no power-up troubles at all!

Let me try and interpret everything happening in that last image:

• the initial very high blip (over 25 mA) is the JeeNode’s on-board 10 µF capacitor charging up
• the 65 ms @ 3.2 mA is the clock startup delay, as defined by the default fuse setting
• up to this point, the reservoir cap has lost some 2V of its charge
• the next blip is the boot loader passing control immediately to the sketch (!)
• then there’s the 32 ms loseSomeTime() call in setup(), with the ATmega finally powered down
• the last blip at the right-end side of the screen puts the RFM12B into low-power sleep mode

So what’s going on, and above all why is the boot loader problem gone, after all that trouble it gave me before?

The only explanation I can think of lies in the one change I made since then: I’m now using OptiBoot v4.4 … and it probably does the right thing, in that it skips the boot loader on power-up and only goes through a boot-loader sequence on reset. This is the well known ladyada fix. I guess my previous boot loader setup wasn’t using that.

This is really good news. It means you just need a recently-flashed ATmega and you can continue to use the normal FTDI upload mechanism while fooling around with this ultra low-power stuff. Even the 10 µF cap and regulator on the JeeNode can be left in when powering it from the new Low-power supply.

## Getting ready for OptiBoot 4.4

In AVR, Hardware, Software on Jan 7, 2012 at 00:01

Ok, it’s official – starting this week, all new ATmega’s here will be flashed with the OptiBoot 4.4 boot loader.

It’s going to take a while for all current inventory units to “flush through the system” so to speak (both DIPs and SMDs), but at some point this month all ATmega’s will be running the same boot loader as the Arduino Uno. Faster, smaller, and – hopefully – no more troubles with Windows being unable to upload sketches through FTDI.

One of the things I’ve done is to turn one of the new JeeNode Blocks into a dedicated Portable ISP Programmer for DIP-28’s. It’s the same isp_repair2 sketch as before (modified for the Block’s minor pin allocation diff’s):

Note the 16 MHz resonator behind the ZIF socket. Here’s the wiring:

There’s no 10 kΩ pull-up resistor for RESET, because ATmega’s have a (weak) built-in pull-up.

To avoid the delay-on-hardware-reset, I’ve added a push-button which briefly shorts +3V and GND together through a 10 µF electrolytic cap. Enough to force the JeeNode Block into a hardware reset. There’s a 10 kΩ resistor across the cap to discharge it afterwards. This is really quick because the reset occurs on button press i.s.o. release.

The savings are minimal – just 1..2 seconds more for the standard bootstrap – but for production, it matters. Total flash time, including boot loader, RF12demo sketch, and setting all the fuses is now just a few seconds:

• insert DIP chip
• close ZIF socket
• press button
• wait for two LED blinks
• open ZIP socket
• remove programmed chip
• rinse and repeat…

When a serial port is connected via FTDI, you can see the progress of it all:

Now let’s just hope that this version of OptiBoot doesn’t lead to the same mess as the previous one.

If you have older JeeNodes or other ATmega328 boards running previous bootstrap loaders, I suggest looking at the recent ISP programmer post and the older summary. You might consider bringing all units up to date, because with a mix of boot loaders you end up constantly using the wrong one in the IDE and having to adjust board types each time.

Just be careful when messing with boot loaders. If the process goes wrong and you pick the wrong fuse settings, then you can end up with a “bricked” unit (only a high-voltage programmer can recover from such a state).

But apart from that: enjoy the doubled 115.2 Kbaud upload speed and the 1.5 Kb extra space for sketches!

## Pin-change interrupts for RF12

In Software on Jan 6, 2012 at 00:01

The recently released (limited-edition) JeeNode Block has a couple of changes w.r.t. pin allocation, most notably the RFM12B’s “nIRQ” interrupt pin. This was moved from PD2 to PB1 (Arduino digital pin 2 to pin 9). The main reason for this change was to free the entire set op pins on PORTD, i.e. PD0..PD7 – in Arduino-speak: digital pin 0 through 7.

That means interrupts are no longer coming in over the INT0 line, and can no longer use the attachInterrupt() and detachInterrupt() functions in the Arduino run-time library. Instead, the RF12 driver needs to switch to pin-change interrupts, which I’ve now added to the /code.

To use the RF12 driver with the JeeNode Block, you need to make the following changes:

2. Enable pin-change interrupts by removing the comment so it defines `PINCHG_IRQ`:

``````    #define PINCHG_IRQ 1
``````
3. Change the `RFM_IRQ` define (make sure you pick the ATmega328 case):

``````    // ATmega168, ATmega328, etc.
#define RFM_IRQ 1
``````
4. If you plan to use `RF12demo.ino` – don’t forget to change the LED pin to match the JeeNode Block:

``````    #define LED_PIN 8
``````
5. Compile and upload, and things should work as on any other JeeNode.

Note that pin-change interrupts are a bit tricky. First of all, changes are not the same as responding to a level interrupt, but the new code should take care of that. More importantly, the RF12 driver assumes it’s the only one using pin changes on the corresponding “port” (in Atmel datasheet terminology). If you use more pins for port interrupts, you may have to adjust the RF12.cpp file.

These changes are not on by default, the latest RF12 driver comes configured for the original JeeNodes.

Update – 2014-11-23: RFM_IRQ changed from 9 to 1

## ISP Programmers – part 2

In AVR, Hardware on Jan 5, 2012 at 00:01

In yesterday’s post, I presented my latest ISP programmers, based on the isp_repair2 sketch.

I made a few small improvements to that sketch:

1. the RFM12B is powered down at the end, so that the unit only consumes a few µA’s once done
2. the programming rate has been improved by getting rid of those horribly slow digitalWrite() calls, etc.
3. updated RF12demo and OptiBoot to the latest version (v8 and v4.4, respectively)

Furthermore, I switched from the funky switches to plain jumpers, with the following layout:

Another change is that the default with no jumpers is now to burn RF12demo w/ OptiBoot for use with a 16 MHz resonator – this is a good default for JeeNodes, JeeNode USB’s, and JeeNode SMD’s. To select the other options, just hook this up to USB, change the jumpers, and watch the serial output report on reset.

This is the output with no jumpers and no target board attached:

This is the output after a normal programming cycle (again, the default case, no jumpers installed):

Programming takes only a few seconds. Note that this programmer is fully self-contained and includes its own LiPo battery, so all you need to do is press the 6 pins on the ISP header pads. The neat thing is that due to the normally-discharged cap on the target board, the brief power dip caused by touching the ISP pads will generate a hardware power-on reset in the programmer, which then immediately starts its programming cycle.

So the the whole workflow is now as follows:

• grab this thing – and let’s call it a “Portable ISP Programmer” (PIP!)
• press the pins against the ISP header of the unit to be re-flashed
• watch the initial LED blink on the programmer as it comes out of reset
• wait 2..3 seconds
• watch the second LED blink, indicating that it has successfully completed programming

There is no power switch, since the programmer enters total power down when done. To re-charge, plug the programmer into a USB port and wait for the “charge” LED to turn off. Note that pressing the reset button also works, but that it adds a small boot loader delay before the isp_repair2 sketch gets started.

This has become so convenient, that I can now take any old JeeNode lying around here, and reset it to a well-known state in just a few seconds, before re-using it for some project or experiment.

## ISP programmers

In AVR, Hardware on Jan 4, 2012 at 00:01

ISP (re-)programming is going to become more important in the future, so I’ve built a few more of these:

The problem was to come up with a robust way to connect to the target board, but I think I’ve found a solution:

Take a 4-pin header, slightly enlarge the holes in the plastic, and then gently-but-forcefully press a couple of Pogo pins in there. I’m using the type with a large head with sharp edges. Here’s the whole assembly:

After that, it’s a matter of attaching all the wires and tying / glueing things together:

These units are all refurbished ones with a defective radio, since that’s not needed here.

The ZIP straps hold the battery and wires in place. The hot glue does the rest:

These programmers are considerably more effective than you might think – tomorrow, I’ll explain why…

## Bit-banged I2C timing

In Hardware, Software on Jan 3, 2012 at 00:01

The JeeNode Ports library has supported software-based I2C right from the start. There are some limitations to this approach, but it’s been very useful to allow connecting lots of I2C-based plugs on any of the 4 JeeNode “ports”.

I’ve always suspected that the timing of this software “bit-banging” was off. Well… it’s waaaaay too slow in fact:

That’s a JeeNode talking to an RTC Plug over I2C, set to 400 KHz. Except that it’s talking at a mere 40 KHz!

The code works, of course. It’s just far from optimal and wasting time. The main reason for this is that the Arduino’s digitalWrite(), digitalRead(), and pinMode() calls take a huge amount of time – due to their generality. A second problem is that the delayMicroSeconds() call actually has a granularity of 4 µs.

As a quick test, I hard-coded the calls in the Ports.h header to use much more efficient code:

The result is that I2C can now run at over 300 KHz, and it still works as expected:

It can even run at over 600 KHz, which is beyond the official I2C specs, but it works fine with many I2C chips:

Except that this now requires a pull-up resistor on SDA (i.e. the AIO pin). The rise-time of the data pulses is now too low to work reliably off the internal ATmega pull-up resistors. I used a 1 kΩ resistor, as pull-up to 3.3V:

Note the glitch at the end – it’s probably from emulating open-collector logic with the ATmega’s three-state pins.

Pull-ups are also a very good idea with shorter bus lines, because they also lower the impedance of the wire, reducing noise. These tests were all done with the RTC Plug stuck directly into the Port 1 header, BTW.

Here’s the SDA signal on a 5 µs/div scale – via 4 Extension Cables back to back, i.e. 65 cm – with 1 kΩ pull-up:

And without – showing abysmal rise times and lots of crosstalk, making I2C on this hookup totally useless:

I’ll need to figure out how to properly implement these software optimizations one day, since that means we can’t just use the generic I/O pin calls anymore. There are several cases: different speeds as well as different ports (including “port 0” which uses A5 and A6, the official I2C pins – but still in bit-banged mode).

All in all, this software-based I2C works fine, with the advantage of supporting it on any two I/O pins – but it could be optimized further. The other thing to keep in mind is that the SCL clock line is not open-collector, but driven by a normal totem pole output pin, so this doesn’t support I2C clock stretching for slow (or busy) slaves.

## Scheduler power optimization

In Software on Jan 2, 2012 at 00:01

Last year’s post showed how a packet transmission w/ ACK reception works out in terms of power consumption. It also uncovered a fairly large “power consumption bug”, with the scheduler idling only 0.1s at a time, causing the ATmega to exit power-down mode through its watchdog far more often than necessary.

Here’s the relevant code in the general-purpose Scheduler class in Ports.cpp:

And here’s what I ‘m going to change it to, to optimize and stay powered-down much longer:

This changes the wake-up period from 30 times per second, to roughly once every 8s, with blips like this:

My interpretation of this picture, is that the ATmega on this JeeNode needs a whopping 10 mA of power for 50 µs once every eight seconds to keep going. That 1 ms “lead-in” at < 1 mA is probably clock startup, or something.

This current draw is the same as before (this capture was with PIR installed). But instead of 1800 wake-ups per minute, there will now be 10 or so. This will reduce the power consumption from 2,000 µC to roughly 10 µC!

Does that mean the Room Node will now last 200 times longer on a single battery? Unfortunately, no. With these low-power games, the weakest link determines total battery life. In this case, there’s a PIR sensor which has to be constantly on, drawing about 50 µA. That’s 3,000 microcoulombs per minute.

But still, this little optimization should add quite a bit to the lifetime of a battery:

• old: 3000 (PIR) + 130 (radio) + 600 (estimated) ATmega/regulator + 2,000 (scheduler) = 5730 µC/min
• new situation, again per minute: 3,000 + 130 + 600 + 10 = 3740 µC/min

If you’re wondering what “microcoulombs/minute” means: that’s just current, so rescaling it to µC/s (i.e. µA’s), we get: old ≈ 96 µA, new = 63 µA. With a 2000 mAh 3x AA battery pack, that’s 2.5 vs 3.6 years of run time.

Note that these values are fairly optimistic. With motion in the room, there will be more than one packet transmission per minute. I have yet to see the real-life battery life of these room nodes, although right now it’s looking quite good: the nodes I have around here have been working for many months – 2012 will tell!

But either way, that change of just a few lines of C code should add about 50% to the battery life. Crazy, eh?

## Happy tinkering in 2012!

In News on Jan 1, 2012 at 00:01

Happy 2012. We each have roughly 5,000 waking hours ahead of us in 2012. Let’s use ’em – slowly and wisely.

As my contribution to slowing down, I’d like to encourage everyone interested in Computing Stuff tied to the Physical World to deepen your understanding and broaden your experience. So allow me to introduce a little tinkering kit, for those of you who are into ATmega’s and wireless stuff – the JeeNode Block:

This is a recent experiment to fool around with the JeeNode form factor, as a way to create a little self-contained unit which needs no wires to operate. I’m using these blocks to try things out on my desktop (you know, the real physical one), without turning it into a huge spaghetti bowl of power supply wires, USB cables, and test hookups.

It’s basically just a JeeNode, but with a different layout (and RFM12B’s “INT” pin reallocated from PD2 to PB0):

It’s exactly the right size to support simple low-cost 5×7 cm prototyping boards (lets not call ’em “shields”, ok?):

The three headers at the bottom are: 8 digital I/O pins, 4 power pins, and 6 analog I/O pins. The two headers at the top are JeeNode ports 1 and 2. There’s a reset button, an LED, and an FTDI header for uploading new code. The 3x AA battery pack will power the whole thing at 3.6 .. 4.5 V, depending on the type of batteries used. There’s a regulator on board to run at 3.3V, as with all the other JeeNode variants.

Note that this is not a product in the shop. It’s just an exploration by yours truly. And it’s also a one-time offer:

As special encouragement to “start 2012 by tinkering”, I’ll add a JeeNode Block PCB and a prototype board for free to the first three dozen or so people who order a JeeNode from the shop and ask for it. You can then simply re-use all the JeeNode parts for this board (except for the JeeNode’s PCB), since everything is more or less the same. A few missing components will also be included: extra headers, an LED, and the reset button. To take advantage of this offer, select “JeeNode w/ extra Block” from the pop-up list on the order page. Note: this offer is limited to at most one Block per person.

If you come up with a neat project for the JeeNode Block, I encourage you to share your invention on the forum.