Computing stuff tied to the physical world

Archive for September 2012

Sending Bencode data

In AVR, Software on Sep 30, 2012 at 00:01

As mentioned a while back, I’m adopting ZeroMQ and Bencode on Win/Mac/Linux for future software development. The idea is to focus on moving structured data around, as foundation for what’s going on at JeeLabs.

So let’s start on the JeeNode side, with the simplest aspect of it all: generating Bencoded data. I’ve set up a new library on GitHub and am mirroring it on Redmine. It’s called “EmBencode” (embedded, ok?). You can “git clone” a copy directly into your Arduino’s “libraries” folder if you want to try it out, or grab a ZIP archive.

This serialSend sketch sends some data from a JeeNode/Arduino/etc. via its serial port:

Screen Shot 2012 09 29 at 20 20 32

Note that we have to define the connection between this library and the Arduino’s “Serial” class by defining the “PushChar” function declared in the EmBencode library.

One thing to point out, is that this code uses the C++ “function overloading” mechanism: depending on the type of data given as argument to push(), the appropriate member function for that type of value gets called. The C++ compiler automagically does the right thing when pushing strings and numbers.

Apart from that, this is simply an example which sends out a bit of data – i.e. some raw values as well as some structured data, each one right after the other.

Here’s what you’ll see on the IDE’s serial console monitor:


(the output has been broken up to make it fit on this page)

It looks like gobbledygook, but when read slowly from left to right, you can see each of the calls and what they generate. I’ve indented the code to match the structures being sent.

You can check out the EmBencode.h header file to see how the encoder is implemented. It’s all fairly straight-forward. More interestingly perhaps, is that this code requires no RAM (other than the run-time stack). There is no state we need to track for encoding arbitrarily complex data structures.

(Try figuring out how to decode this stuff – it’s quite tricky to do in an elegant way!)

Tomorrow, I’ll process this odd-looking Bencoded data on the other side of the serial line.

ARMs on Foam

In Hardware, Linux, ARM on Sep 29, 2012 at 00:01

One of the things I’d really like to do is hack on that Laser Cutter I described recently.

The electronics is based on a LaOS Board, but I’d like to see what you can do with an embedded Linux board such as a Raspberry Pi in this context – driving that LaOS board, for example. Because adding Linux to the mix opens up all sorts of neatness.

So here’s my new prototype development setup:

DSC 4163

That oh-so-neat foam board acts as base, with two PCB’s fastened to it using, heh … remember these?

DSC 4164

They’re called “splitpennen” in Dutch. Long live foam board and splitpennen!

This is a pretty nifty setup, in my opinion. Tons and tons of ways to implement features on this combo, and there’s plenty of power and storage on both boards to perform some pretty neat tricks, I expect.

Anyway – this is more a big project for cold winter days, really. It’ll take a long time before anything can come out of this, but isn’t it incredible how the prices of these things have reached a point where one can now dedicate such hardware to a project?


In News on Sep 28, 2012 at 00:01

There are a couple of disruptions imminent regarding the JeeLabs web sites:

  • First one is a VAT increase in the Netherlands, starting October 1st. This will affect the shop.

  • Second one is the switch from Redmine 1 to Redmine 2, this will affect the café (docs and wiki).

  • Third one is a transition / migration from Drupal to Redmine – this will affect the forum.

Let me assure you that I hate each of the above changes at least as much as you do. Probably more.

But there’s no way around it. The VAT increase from 19% to 21% is a legal requirement, of course, so it’s both necessary and needs to happen on a specific date. A few days from now, that is. More news on that coming.

The switch from Redmine 1 to Redmine 2 was also inevitable, in the long run. I’m quite happy with Redmine as a system, but the current 1.0.1 setup has been out for two years, and I haven’t ever been able to easily update it. Yuck, yuck, yuck. In the end, the only way out was to wait for a solid 2.x release series, which also happens to come with a far better upgrade mechanism.

But instead of doing some sort of 1.x -> 2.x conversion for a range of projects in Redmine 1 (some public, but also several private ones), I’ve decided to just start over. With the help of a couple of people (thank you Steve, thank you Myra), just about all the main content of the café has now been transferred (converted, in fact).

Except the API documentation – this hasn’t been migrated, because I’ve decided been convinced that maintaining API documentation in Doxygen is a far better long-term solution (thanks Jasper). So instead of setting up wiki pages for that, all the JeeLabs libraries can now be extended with comments for Doxygen to generate nice docs from – which I intend to publish as part of the new “” site (for now, you can generate the JeeLib docs yourself, again thanks to Jasper’s check-ins).

The new Redmine website has been around for some time now (at, but largely unexposed.

On October 1st, I’m going to take the plunge, and replace the current site with the new one. This will probably break most URLs out there.

(Did I mention how much I hate these changes?)

Note: to avoid losing essential info, the current site will be moved to “”, for reference. So if you can’t find what you’re looking for, you can prefix the url with “oldred.” and try again.

The fact is, that I’ve not made enough progress in the current situation for some time now, and the only way to get there is to break everything first, and then quickly try to repair the most harmful damage. Evolution just doesn’t cut it for me in a case like this, apparently.

Apart from the URL breakage, there are some additional horrid consequences:

  • To participate (submitting bugs, editing wiki pages, etc), you will need to register as new user again. To make matters even worse, I’m not enabling auto-registration to keep spammers at bay. So new registrations will not be instant.

    (Did I mention that I hate spammers even more than these disruptive changes?)

    Please use the same user name for registration as on the forum (I’ll explain why in a moment).

  • I’m dropping Markdown as wiki formatting language, and switching to Textile. This format comes from the Ruby world and is considerably better supported by Redmine (which is implemented using Ruby On Rails). The good news is that Textile formatting is very similar to Markdown for simple things, and much better at supporting more complex features (such as tables, colours, and even CSS styles).

The third disruption is probably going to cause the most frowning and cursing, but it too is becoming inevitable. Some time later this year, the forum will be migrated to Redmine as well. One reason is practical, in that Drupal admin is too much of a burden (for the three of us sharing the burden: thank you Martyn, thank you Steve again). And since I’m not going to start using it for more tasks here anyway, it really bothers me to have to keep a VM running with 1 GB RAM allocated to it.

This is the reason why registration on the new Redmine site should be done with your existing forum name, where possible: it’ll become a forum as well, once that third big switch is flipped.

But there are also advantages to this forum migration. A major one of them is the nice integration we gain by having forums, issues, source code browsing, and wiki pages all in the same system. Something I’ve always been looking for, and frankly Redmine 2 has been moving in the right direction for some time now.

And lastly, note that “” will keep a copy of all the forum discussions, so those URLs will in fact not break – that forum will merely become read-only (preferably using a static copy, if I can figure out how).

Anyway. Major disruptions. I hope you’ll bear with me as this takes place, and that you’re willing to help out and pinpoint any problematic and painful spots this leads to. First there is trouble, then we can fix it. There’s no way back – so let’s at least try and make the way forward as effective as possible.

Once the big trouble spots have been identified and resolved, I can move forward on the documentation side of things again (hardware as well as software). That too has been long overdue. Jeelabs deserves better. Open source deserves better. And you deserve better from me. A lot better.

Now the good news: the new Redmine setup (currently at has recently been given a major makeover (thank you David), bringing it close in style to the daily weblog. Same logo, same fonts, same looks.

The best news though, I’m sure you’ll agree, is that the daily weblog isn’t going to change!

ARM to ARM upload

In Hardware, Software, ARM on Sep 27, 2012 at 00:01

After yesterday’s basic connection of an LPCXpresso 1769 board to the Raspberry Pi, it’s time to get all the software bits in place.

With NXP ARM chips such as the LPC1769, you need a tool like lpc21isp to upload over a serial connection (just like avrdude for AVR chips). It handles all the protocol details to load .bin (or .hex) files into flash memory.

There’s a small glitch in that the build for this utility gets confused when compiled on an ARM chip (including the Raspberry Pi), because it then thinks it should be built in some sort of special embedded mode. Luckily, Peter Brier figured this out recently, and published a fixed version on GitHub (long live open source collaboration!).

So now it’s just a matter of a few commands on the RPi to create a suitable uploader:

    git clone
    cd lpc21isp
    cp -a lpc21isp ~/bin/

Next step is to get that board into serial boot mode. As it turns out, we’re going to have to do similar tricks as with the JeeNode a few days ago. And sure enough, I’m running into the same timing problems as reported here.

But in this case, the boot load process is willing to wait a bit longer, so now it can all easily be solved with a little shell script I’ve called “upload2lpc”:

# export the two GPIO pins to the shell
echo "18" >/sys/class/gpio/export >&/dev/null
echo "23" >/sys/class/gpio/export >&/dev/null

# use them as output pins
echo "out" >/sys/class/gpio/gpio18/direction
echo "out" >/sys/class/gpio/gpio23/direction

# pull ISP low and prepare for reset
echo "0" >/sys/class/gpio/gpio23/value
echo "1" >/sys/class/gpio/gpio18/value

  # it is essential to delay the reset pulse for lpc21isp
  sleep 0.3
  # pulse reset low
  echo "0" >/sys/class/gpio/gpio18/value
  sleep 0.1
  echo "1" >/sys/class/gpio/gpio18/value
  # set ISP line high again
  echo "1" >/sys/class/gpio/gpio23/value
) &

echo "Uploading... "
lpc21isp -debug0 -bin $1 /dev/ttyAMA0 115200 12000 \
  && echo "Done." || exit 1

The result? We can now reset the LPCXpresso from the Raspberry Pi and upload some blink code to it:

    $ sudo ./upload2lpc blink.bin

Yippie: it resets, it uploads, it blinks – and it does so consistently! Onwards! :)

Update – For best results, also add a “sleep 0.1” between those two last echo 1’s.

ARM to ARM serial connection

In Hardware, Linux, ARM on Sep 26, 2012 at 00:01

After connecting a JeeNode to a Raspberry Pi, let’s do the same with the LPCXpresso I mentioned a while back. Let’s do it in such a way that we can upload new code into it.

With an LPC1769, this is even simpler than with an ATmega328, because the serial boot loader is built-into the chip out of the box. No need to install anything. So you can always force the chip back into serial boot loader mode – it can’t be “bricked” !

But the process is slightly different: you have to pull down a specific “ISP” pin while resetting the chip, to make it enter serial boot loader mode. So we’ll need one more GPIO pin, for which I’ll use the RPi’s GPIO 23. The wiring is even cleaner than before, because this time I planned a bit more ahead of time:

DSC 4156

Except that this runs into the same problem as before. The LPCXpresso does not have the essential 3.3V regulator next to the ARM chip, it’s on the part that has been cut off (doh!). So again, I’m going to have to add an SMD MCP1703 regulator:

DSC 4157

(that little critter is between pins 1 and 2, and upside down, to get the pinout right)

Here’s the complete hookup:

DSC 4159

First step is again to make sure that Linux isn’t doing anything with the serial port:

  • remove the two args referring to /dev/ttyAMA0 in the file /boot/cmdline.txt

  • add a hash (“#”) in front of this line in /etc/inittab to comment it out:

    T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
  • make the system aware of the changes in inittab with: kill -1 1 (or reboot)

Tomorrow, I’ll go into actually uploading to that LPC1769 ARM board. Stay tuned!

Note – As of October 1st, VAT prices in the Netherlands will increase from 19% to 21%. As a consequence some adjustments will also have to be made in the JeeLabs Shop. Up or down depends on many obscure factors, including exchange rates, current costs, stock levels, and the wish to stick to decently rounded values – so if you want to avoid any surprises and were planning to order stuff, please keep that switch-over date in mind.

Energia for MSP430

In Software on Sep 25, 2012 at 00:01

There’s a project called Energia, which describes itself as:

Energia is a fork of Arduino for the Texas Instruments MSP430 Micro Controller.

It’s not the first fork, and won’t be the last. And if you’re used to the Arduino IDE, it’ll be delightfully familiar:

Screen Shot 2012 09 18 at 22 57 48

One really interesting aspect of of this project, is that the price of experimenting with embedded controllers drops to about $5 for a TI “LaunchPad” – so any throwaway project and kid-with-little-money can now use this:

DSC 4150

As I found out, these through-hole experimenter’s boards fit quite nicely on top:

DSC 4151

Although if you look closely, it’s actually one row less than the processor board:

DSC 4152

But hey, you end up with a darn cheap setup, and numerous little experiments to try out.

Lots of options, all usable with open source software toolchains: ARM, AVR, MSP!

Linux real-time hickups

In Hardware, Software on Sep 24, 2012 at 00:01

To give you an idea why a simple little Linux board (the Carambola on OpenWrt in this case) is not a convenient platform for real-time use, let me show you some snapshots.

I’ve been trying to toggle two I/O pins in a burst to get some data out. The current experiment uses a little C program which does ioctl(fd, GPIO_SET, ...) and ioctl(fd, GPIO_CLEAR, ...) calls to toggle the I/O pins. After the usual mixups, stupid mistakes, messed up wires, etc, I get to see this:


A clean burst on two I/O pins, right? Not so fast… here’s what happens some of the time:


For 10 ms, during that activity, Linux decides that it wants to do something else and suspends the task! (and the system is idling 85% of the time)

If you compare the hex string at the bottom of these two screenshots, you can see that the toggling is working out just fine: both are sending out 96 bytes of data, and the first few bytes are identical.

The situation can be improved by running the time-critical processes with a higher priority (nice --20 cmd...), but there can still be occasional glitches.

Without kernel support, Linux cannot do real-time control of a couple of I/O pins!

Upload to JeeNode fixed

In Hardware, Linux on Sep 23, 2012 at 00:01

Ok, I finally figured out what caused yesterday’s upload problem. It’s indeed timing.

But not quite as I thought, and I missed a hint in the scope signal capture yesterday (at 322 ms after the reset). My premature conclusion was that resetting the GPIO pin and then starting up avrdude was taking too long, so the boot loader would give up before receiving the proper starting character over the serial line.

But that doesn’t quite make sense. Looking at the screen shot again, we can see that the RF12demo greeting (blue line) starts about 800 ms after the RESET pin gets pulled low. Even though OptiBoot is supposed to wait a full second after power-up. And there are two handshake attempts well within that period.

The other subtle hint was in the not-quite-equidistant characters being sent out (yellow line). Why would handshake chars be sent out in such a repeatable yet irregular pattern?

Having written an avrdude replacement in Tcl for some experiments I did with JeeMon a while back, I decided to try and extend it a bit to toggle the reset pin right before sending out the data. That way no delay would interfere, so the reset would happen moments (probably mere milliseconds) before starting the boot loader serial handshake. I didn’t really want to start hacking on avrdude for such a “simple” task as toggling a GPIO pin on the Raspberry Pi. Besides, that replacement code is only 70 lines of Tcl, if all you have to deal with is the basic stk500 protocol understood by the boot loader.

Controlling the GPIO pin also turned out to be pretty straightforward:

Screen Shot 2012 09 20 at 23 59 50

But no matter what I tried, and no matter what timing delays I inserted, the darn thing just wouldn’t upload!

Then, just for the heck of it, I tried this variation – reversing the open and reset order:

Screen Shot 2012 09 21 at 00 01 18

And lo and behold – now it works: repeatedly and reliably!

Here’s the scope’s serial protocol analyser, showing a proper upload in progress:


You can see data being sent to the JeeNode, and the 0x14h reply sent back to the RPi.

So was this all about timing? Yes and no. Let’s revisit yesterday’s list of pulses again:

Screen Shot 2012 09 21 at 00 06 02

A single pulse 322 ms after reset, and then several pulses at 673 ms (presumably the first boot loader protocol handshake character). The problem is really that first pulse – it’s not a valid character but a glitch!

What I think is happening is that the JeeNode resets, the glitch at 322 ms causes the boot loader to give up and launch the sketch, and then all subsequent boot handshake characters get ignored. Looks like opening the serial port produces a glitch on the transmit output pin.

By first opening the serial port and then doing the GPIO18 reset, the problem is avoided, and then it all works.

Thank you JeeMon – I hadn’t expected to fire you up again, but you’ve saved my day!

Timing troubles with upload

In AVR, Hardware on Sep 22, 2012 at 00:01

Since the Raspberry Pi can now reset a JeeNode, I assumed that uploading would be a piece of cake. Hmmm… maybe not quite.

The trouble is timing, and I’m currently I was pulling my hair out on this one:

  • the plan is to reset the JeeNode and then have avrdude upload new code to it
  • this works automagically when opening a serial port causes DTR to go low
  • but here, we don’t have DTR or RTS, this is a basic serial port on GPIO pins
  • what we do have, is a GPIO pin 18 which can be pulled low to force a reset

At the moment, there seems to be a major problem with timing:


Here’s how to decode this screen shot:

  • the YELLOW line is serial from RPi to JeeNode
  • the BLUE line is serial from JeeNode to RPi
  • the MAGENTA line is the reset pulse on the GPIO pin

The way I test this, is via a shell script which first toggles reset using /sys/class/gpio/…, and then launches avrdude to perform the upload, using these commands:

echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value
sleep 0.1
echo 0 >/sys/class/gpio/gpio18/value
avrdude -pm328p -carduino -P/dev/ttyAMA0 -D -Uflash:w:test.hex:i
echo 18 >/sys/class/gpio/unexport

Here’s what actually happens, I think:

  • the GPIO pin is correctly pulsed high and then dropped low after 0.1 s
  • the scope triggers on that falling edge, presumably same time as the ATmega resetting
  • after 323 ms, I see a 30 µs blip on the outgoing serial pin
  • after 674 ms, it looks like avrdude sends out it’s “0” wakeup character
  • after about 750 ms, the JeeNode starts sending the RFM12demo greeting
  • after 946 ms, the second “0” wakeup goes out
  • after 1197 ms, the third and final “0” goes out

In other words: it looks like avrdude is starting to send the 0’s too late! – and as a result, the JeeNode’s boot loader passes control to the sketch and never enters the upload cycle. After a few seconds, avrdude then gives up:

avrdude: ser_recv(): programmer is not responding

Note that reset and serial communication both work properly, as verified several times.

Trouble is, apart from redoing all in a single app, I see no way to reduce the startup time of avrdude. The SD card is perhaps not the fastest, but it’s no slouch either:

# hdparm -tT /dev/mmcblk0

 Timing cached reads:   248 MB in  2.00 seconds = 123.77 MB/sec
 Timing buffered disk reads:  50 MB in  3.05 seconds =  16.40 MB/sec

Is a reset + upload via GPIO not possible? I’m not giving up, but it sure ain’t workin’ yet!

Update – Problem solved, stay tuned for the explanation tomorrow…

Resetting a JeeNode from a RPi

In Hardware, Software on Sep 21, 2012 at 00:01

Now that the JeeNode talks to the Raspberry Pi, it’d be interesting to be able to reset the JeeNode as well, because then we could upload new sketches to it.

It’s not hard. As it so happens, the next pin on the RPi connector we’re using is pin 12, called “GPIO 18”. Let’s use that as a reset pin – and because this setup is going to become a bit more permanent here, I’ve made a little converter board:

DSC 4149

This way, a standard JeeLabs Extension Cable can be used. All we need is a board with two 6-pin female headers, connected almost 1-to-1, except for GND and +5V, which need to be crossed over (the other wire runs on the back of the PCB to avoid shorts).

This takes care of the hardware side of resets. Now the software. This is an example of just how much things are exposed in Linux (once you know where to find all the info).

There’s a direct interface into the kernel drivers called /sys, and this is also where all the GPIO pins can be exposed for direct access via shell commands or programs you write. Let’s have a look at what’s available by default:

$ sudo ls /sys/class/gpio/
export  gpiochip0  unexport

The “export” entry lets us expose individual GPIO pins, so the first thing is to make pin 18 available in the /sys area:

sudo echo 18 >/sys/class/gpio/export

That will create a virtual directory called /sys/class/gpio/gpio18/, which has these entries:

$ sudo ls /sys/class/gpio/gpio18/
active_low  direction  edge  power  subsystem  uevent  value

All we’ll need is the direction and value of that pin. Let’s first make in an output pin:

sudo echo out >/sys/class/gpio/gpio18/direction

Now, we’re ready to reset the JeeNode. I found out that the pin needs a negative transition (from 1 to 0) to do this, so the following three commands will do the trick:

sudo echo 1 >/sys/class/gpio/gpio18/value
sudo echo 0 >/sys/class/gpio/gpio18/value
sudo echo 1 >/sys/class/gpio/gpio18/value

And sure enough, the JeeNode resets, and the terminal I have running in another window shows the RF12demo startup message again:

Screen Shot 2012 09 18 at 14 32 09

We’re in control – shell over sketch!

Serial hookup JeeNode to Raspberry Pi

In Hardware on Sep 20, 2012 at 00:01

One way to connect an RFM12B to a Raspberry Pi is to simply plug in a JeeLink, using the built-in USB capabilities of the RPi. But that’s a bit of a detour – why go through USB?

Since the JeeNode’s FTDI connector can use 5V power and has TX/RX pins at 3.3V logic level, it’s actually a perfect match for directly connecting to a Raspberry Pi. Let’s do it.

I’ll be using the command shell on the RPi, using a network SSH connection, but this could also be done from the console with a keyboard, of course.

There are a couple of hurdles we’ll need to overcome. First one is to figure out which pins to use on the RPi’s 26-pin I/O connector. I found a good schematic on

Screen Shot 2012 09 16 at 17 26 45

We’re going to use 4 pins: 5V, Ground, TXD, and RXD. But first, let’s figure out how to reach those pins in Linux. I found out that the serial port we need is “ttyAMA0”:

$ ls -l /dev/ttyAMA0 crw-rw—- 1 root tty 204, 64 Sep 16 17:13 /dev/ttyAMA0 $

That port is only accessible by users in access group “tty” (and root). So first, let’s make sure user “pi” can access it, by adding ourselves to that group:

sudo usermod -a -G tty pi

Now logout and log back in to make these changes take effect.

> Note: not all RPi Linux distro’s are set up in the same way. If ttyAMA0’s group is “dialout” instead of “tty”, chances are that you’re already a member (type “id” to find out). In that case, skip the above usermod command.

But that’s not all. By default, there’s a “getty” process running on this serial port:

$ ps ax | grep getty 2126 tty1 Ss+ 0:00 /sbin/getty –noclear 38400 tty1 2127 tty2 Ss+ 0:00 /sbin/getty 38400 tty2 2128 tty3 Ss+ 0:00 /sbin/getty 38400 tty3 2129 tty4 Ss+ 0:00 /sbin/getty 38400 tty4 2130 tty5 Ss+ 0:00 /sbin/getty 38400 tty5 2131 tty6 Ss+ 0:00 /sbin/getty 38400 tty6 2132 ? Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100 2292 pts/0 S+ 0:00 grep getty $

This lets you connect to the serial port and login. Very convenient, but in this case we don’t want to log in, we want to take over control of this serial port for talking to the JeeNode. So we have to disable getty on ttyAMA0:

  1. edit the file /etc/inittab as root (I used “sudo vi /etc/inittab”)
  2. change this line: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 to #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. I.e. comment it out, and save these changes.
  3. run the command “sudo kill -1 1” to pick up these inittab changes

And that’s it. There is no longer a process trying to respond to our serial port.

> Note: again, this may not be needed if you don’t see “ttyAMA0” listed in the ps output.

You also have to make sure that the kernel doesn’t log its console output to this serial port. Look in the file “/boot/cmdline.txt” and remove the text console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 if present. Then reboot.

Now we’re ready for a quick loopback test:

DSC 4143

Connect a single jumper as indicated (a little jumper block would also work), connecting RXD with TXD. This means that everything sent out serially will be sent back and received serially as well. A very convenient test that we’ve got all the Linux stuff set up properly.

Oh, wait – first let’s get the utility installed which lets us type to the serial port:

sudo apt-get install screen

Now we can test the serial port, at last:

$ screen /dev/ttyAMA0 57600 …

You should see a blank screen, and whatever you type in should show up on the screen. If this is indeed the case, then there is data going out and back into the serial port. To really make sure, disconnect the jumper and the echoing will stop. Excellent. Almost there.

Screen is a very convenient utility, but you need to remember how to get back out of it. The key sequence is CTRL+A followed by “\” (the backslash key).

For now, you can leave it running, or start it up again later. The last step is to hook up the JeeNode. This requires 4 wires:

DSC 4144

Note carefully the order of these female-to-female jumper wires, top to bottom:

  • on the RPi: green, white, black, gap, blue
  • on the JeeNode: gap, green, white, blue, gap, black

I used a JeeNode, pre-loaded with the standard RFM12B sketch, and set to receive packets from my main home monitoring setup here at JeeLabs. I also enabled “collect mode (“1c”) so that it wouldn’t try to acknowledge packets, just lurking and reporting what comes in. And sure enough, it works:

Screen Shot 2012 09 16 at 17 17 17

Easy! (once you know how to overcome all the software and hardware hurdles, that is…)

Update – additional contributed notes.

Laser cutter electronics

In Hardware, Software on Sep 19, 2012 at 00:01

The last part of this mini series about a low-cost semi-DIY laser cutter describes the electronics and firmware:

DSC 3506

In the middle is an MBED microcontroller based on an ARM Cortex M3 chip (NXP’s LPC1768). It runs at 96 MHz, has 512 KB flash, 32 KB RAM, USB, and an Ethernet controller on board (but not the magjack).

The whole thing sits on the custom LaOS board, which includes an SD card socket, an I2C bus, some opto-isolators, power-supply interface (+5V and +24V), and two Pololu stepper drivers (or nearly compatible StepSticks).

There’s room for 1 or 2 more stepper drivers, a CAN bus interface, and more connectors for extra opto-isolated inputs and outputs. The on-board steppers can be omitted with the step/direction pins brought out if you need to drive more powerful motors.

The MBED was briefly mentioned in a previous post, and can also be replaced by a suitably modded LPCXpresso 1769 board, at less than half the price.

The software is open source and has just been moved from the MBED site to GitHub. Note that at this point in time, the software is still based on the “” runtime support library, which is unforunately not open source. Work is in progress to move to a fully open source “stack”, but that’s not the case today – the Ethernet library in particular hasn’t been successfully detached from its MBED context yet.

Ethernet connectivity is based on the lwIP code, which in turn is the big brother of uIP. Big in the sense that this supports a far more capable set of TCP/IP features than would be possible with an 8-bit microcontroller and its limited memory. Having 512 KB flash and 32 KB RAM in this context, means that you don’t have to fight the constraints of the platform and can simply focus on getting all the functionality you want in there.

Right now, the LaOS firmware drives the steppers, using a Gcode interpreter adapted from gbrl, and includes support for Ethernet (TFTP, I believe) and the SD card. It also requires the I2C control panel. As a result, you can send a “job” to this thing via VisiCut, and it’ll save it on the SD card. The I2C-based control panel then lets you pick a job and start it. Quite a good workflow already, although there are still a fair number of rough edges.

(Note that if you listen very carefully, you can hear all the pioneers on this project scream for more volunteers and more help, on all sorts of levels and domains of expertise :)

What excites me about all this, apart from those über-cool laser cutting capabilities of course, is the potential to take this further since all the essential bits are now open source – and it’s not even really tied to a specific brand of laser.

So there you have it. It cuts, it burns, it smells, it’s yearning to be taken to the next level :)

What’s in a laser cutter

In Hardware on Sep 18, 2012 at 00:01

Let me describe this thing I ended up with:

  • mechanics: the main part is a solid bright red metal box with a few compartments:
    1. left = X-Y table
    2. right = electronics
    3. back = laser tube
  • electronics: the LaOS main board and an ATmega168 as I2C-connected control panel
  • water reservoir + circulation pump, for cooling, must be on when the laser is on
  • air pump (noisy aquarium type) – for “air assist”, keeps the fumes away from the lens
  • exhaust ventilator, mounted on the back, pushes the smelly & smoky air out

The pumps and ventilator are manually turned on from the front panel with separate switches. Not perfect, since this leaves room or operator error, but hey – it works.

Here’s a peek inside, with some packaging plastic still in place:

DSC 3512

The shiny plate height can be adjusted using 4 connected screws turning in tandem.

You can see a little fluorescent light in the top center, and the air exhaust underneath it.

A 35 Watt infrared laser is serious stuff (it actually requires a few hundred Watt to generate that sort of power). Once focused, that beam can do major harm – cutting through stuff is what it’s supposed to do, after all.

Safety comes in the form of a reed relay which triggers when the lid of this thing is lifted (top right above), another one when the lid of the laser on the back is open, and a mains power switch with a key. The lid for the electronics is locked (from the X-Y compartment). The transparent viewing area is of a special type which blocks laser light, and the whole thing is made of fairly solid steel.

The beam is invisible (scary, eh?), but a tiny red “pointer” laser is mounted inside, showing roughly where the beam will hit. Extremely useful while doing dry runs – which in turn is very easy to do: just start the laser with the lid open, and you can see where it’s going to cut. Given that the cutting area is only about 20×30 cm, that’s not a luxury – you really have to check whether the material is properly placed. Here’s that last mirror, deflecting the beam down into the final focusing lens:

DSC 3489

(Note: that’s not smoke, but the red panel’s reflection on the aluminium work surface)

The hollow tube is the “air assist”, blowing air to push the smoke away from the beam.

All the mirrors come pre-aligned and secured with a bit of hot glue. No need to tweak.

On the side is that little pointer laser. Since it’s tilted, the position of the spot is not exactly where the laser will hit, depending on how far into the material you place the focus spot. Focusing is actually quite simple: the laser comes with a little (lasered) acrylic piece, the side of which has a specific length. To focus, you place that on the work piece, and then lower or raise the object until the plastic spacer aligns with this metal mirror mount.

Raising / lowering the work piece is done manually. The whole thing sits on a (fixed size) “honeycomb” bed, which in turns sits on a manually adjustable metal “table”. Adjustment is done with a screw sticking through the bottom of the laser – and in fact the very first thing you need to cut is a piece of wood to act as large adjustment ring, which can then be grabbed from the front of the laser. Bit hard to explain, but then again this isn’t meant as assembly instruction – I just want to give you an impression of what sort of issues you have to deal with in such a setup. On the plus side: pioneering is fun! – with lots of opportunities to come up with clever improvements :)

Tomorrow, I’ll describe the electronics. This board (and the software developed for it) replaces the original board, which I’m told was hard to use, came with crude Windows-specific software, and was impossible to hack on and improve. The LaOS board has a microntroller, two stepper motor drivers, an Ethernet port, and various other bits and bobs needed to deal with everything in the HPC laser. It’s actually quite general-purpose.

Hello, Laser Cutter!

In Hardware, News on Sep 17, 2012 at 00:01

Yep, it has finally happened… it all started in July, when I got this (without the electronics board) and this (called the LaOS board).

The laser arrived like this:


This summer, a couple of early adopters in the Netherlands got together to figure out all the pesky little details that come up when you’re really just in pioneering mode. Make no mistake: this thing is far from ready for mainstream use. The laser itself is quite nice and ready to go, and definitely workable as far as all the mechanics go. But the electronics and software are still work-in-progress (I’m using the VisiCut software – which includes a driver that talks directly to the laser’s firmware over Ethernet).

Nevertheless – early as it may be, the total cost is less than €1,500 and you end up with an A4-sized laserable workspace which can cut up to 5 mm wood panels and 6 mm acrylic (engraving is more involved, but getting there). One of the first things we tried was this:

Image 1

Sure enough, the circle is a snug fit and turns perfectly. Excellent alignment!

I’ll describe a few more details of this setup in the coming weblog posts, but also want to point out that you too can end up with such a laser cutter (just make sure to arrange for ventilation – you’ll quickly get very tired of the burning smell and fumes).

There’s a project by the designers of the replacement electronics, called LaOS (Laser Open Source) – and it’s definitely the best place to go right now if you want to find out what’s going on. Warning: the site is currently undergoing a messy transition to a new wiki – I’ve helped out a bit and am sure they’d love to see more people join in the effort of making this thing more practical for the non-hacker crowd.

One little gotcha: these 35 W laser cutters are produced in China and then tested/resold by a company in the UK, and they are really large and heavy. Having one shipped from the UK to you is fairly expensive, because of the delicate glass laser tube (several hundred Euro, most likely). We got around that by getting organised and doing a “group buy”, with one person actually volunteering to go to the UK, load his car up with a bunch of laser cutters, and driving back (!). Still pricey, but less so, and I think the UK vendor is in fact willing to make arrangements when enough units are being purchased and shipped at the same time. Anyway – it’s an aspect to keep in mind.

But oy, oy, oy, this personal fabbing is fun :)

This logo is real!

In Musings on Sep 16, 2012 at 00:01

Real as in tangible, that is! (thanks, David)

DSC 4142

That’s MDF, sprayed in black and red, along with a plexiglass inset to hold it all together.

Created with my own laser cutter (sort of). And you can make a laser too, stay tuned :)

One million packets

In AVR, Hardware, Software on Sep 15, 2012 at 00:01

Minutes after this weblog post goes live will be a new milestone for one of the JeeNodes.

This thing has been running for over two years, sending out nearly one million test packets:

Here are the entries from the data logged to file on my central server, minutes ago:

1:40   RF12-868.5.3 radioBlip age       740
1:40   RF12-868.5.3 radioBlip ping      999970

The counter is about to reach 1,000,000 – just after midnight today, in fact.

These log entries come from a JeeNode with a radioBlip sketch which just sends out a counter, roughly every 64 seconds, and goes into maximum low-power mode in between each transmission. That’s the whole trick to achieving very long battery lifetimes: do what ya’ gotta do as quickly as possible, then go go bck to ultra-low power as deeply as possible.

The battery is a 1300 mAh LiPo battery, made for some Fujitsu camera. I picked it because of the nice match with the JeeNode footprint.

Bit the big news is that this battery has not been recharged since August 21st, 2010!

Which goes to show that:

  • lithium batteries can hold a lot of charge, for a long time
  • JeeNodes can survive a long time, when programmed in the right way
  • sending out a quick packet does not really take much energy – on average!
  • all of this can easily be replicated, the design and the code are fully open source

And it also clearly shows that this sort of lifetime testing is really not very practical – you have to wait over two years before being sure that the design is as ultra-low power as it wast intended to be!

If we (somewhat arbitrarily) assume that the battery is nearly empty now, then running for 740 days (i.e. 17,760 hours) means that the average current draw is about 73 µA, including the battery’s self-discharge. Which – come to think of it – isn’t even that low. I suspect that with today’s knowledge, I could probably set up a node which runs at least 5 years on this kind of battery. Oh well, there’s not much point trying to actually prove it in real time…

One of the omissions in the original radioBlip code was that only a counter is being sent out, but no indication at all of the remaining battery charge. So right now I have no idea how much longer this setup will last.

As you may recall, I implemented a more elaborate radioBlip2 sketch a while ago. It reports two additional values: the voltage just before and after sending out a packet over wireless. This gives an indication of the remaining charge and also gives some idea how much effect all those brief transmission power blips have on the battery voltage. This matters, because in the end a node is very likely to die during a packet transmission, while the radio module drains the battery to such a point that the circuit ceases to work properly.

Next time, as a more practical way of testing, I’ll probably increase the packet rate to once every second – reducing the test period by a factor of 60 over real-world use.

Waiting a couple of years for the outcome is a bit silly, after all…

Another embedded ecosystem

In Hardware on Sep 14, 2012 at 00:01

(This post follows up on Reinhard’s clearvoyant comment yesterday..)

The ARM microcontrollers described in the past few days are a big step up from a “simple” ATmega328, but that’s only if you consider hundreds of kilobytes of flash storage and tens of kilobytes of RAM as being “a lot”.

Compared to notebooks and workstations, it’s still virtually nothing, of course.

But there’s another trend going on, with bang-for-the-buck going off the charts nowadays: small embedded Linux systems with integrated wired and/or wireless Ethernet. These are often based on Broadcom and Atheros chipsets – the same as found in just about every network router and gateway nowadays.

One particularly nice and low-cost example of this is the Carambola by 8devices:

Main image 3 40

It has 8 MB flash + 32 MB RAM (megabytes!), on-board WiFi, and runs OpenWrt Linux.

There are I2C and SPI interfaces, which can also be used as general-purpose I/O pins, so this thing will interface to a range of things right out of the box.

One gotcha is that the 2×20 pins are on a 2mm grid, not 0.1″. Small size has its trade-offs!

The board will draw up to 1.5 W @ 3.3V (i.e. roughly 500 mA), but that can easily be reduced to about 0.4 W for a blank board with no wired Ethernet attached.

Here are some more specs, obtained from within Linux on the Carambola itself:

Screen Shot 2012 09 13 at 21 02 59

As you can see, this unit (like many routers) is based on a MIPS architecture. And it’s actually quite a bit faster that the Bifferboard I described a while back.

Like most low-end ARM chips, these systems often lack hardware floating point (its all implemented in software, just like an Arduino does for the ATmega’s). Don’t expect any number-crunching performance from these little boards, but again it’s good to point out that boards like these are priced about the same as an Arduino Uno.

One of the benefits of Linux is that it’s a full-fledged operating system, with numerous tools and utilities (though you often still need to cross-compile) and with solid full-featured networking built in. The amount of open source software available for Linux (on a wide range of hardware) is absolutely staggering.

Among the drawbacks of Linux in the context of Physical Computing, is that it’s not strictly real time, so programming for it follows a different approach (busy loops for timing are not done, for example). Don’t expect to accurately pulse an I/O pin at a few hundred Hz or more, for example. Linux was also definitely not made for ultra-low power use, such as in remote wireless nodes which you’d like to keep up and running for months or years on a single battery – there’s simply too much going on in a complete operating system.

The other thing about Linux is that it can be somewhat intimidating if you’ve never used it before. Part of this comes from its strong heritage from the “Unix world”. But given the current trends, I strongly recommend trying it out and getting familiar with it – Linux is very mature: it has been around for a while and will remain so for a long time to come. With boards such as the Carambola illustrating just how cheap it can be to have a go at it.

Interesting times. Now if only new software developments would keep up with all this!

The ARM ecosystem

In Hardware, Software on Sep 13, 2012 at 00:01

Yesterday’s post presented an example of a simple yet quite powerful platform for “The Internet Of Things” (let’s just call it simple and practical interfacing, ok?). Lots of uses for that in and around the house, especially in the low-cost end of ATmega’s, basic Ethernet, and basic wireless communication.

What I wanted to point out with yesterday’s example, is that there is quite a bit of missed potential when we stay in the 8-bit AVR / Arduino world. There are ARM chips which are a least as powerful, at least as energy-efficient, and at least as low-cost as the ATmega328. Which is not surprising when you consider that ARM is a design, licensed to numerous vendors, who all differentiate their products in numerous interesting ways.

In theory, the beauty of this is that they all speak the same machine language, and that code is therefore extremely portable between different chips and vendors (apart from the inevitable hardware/driver differences). You only need one compiler to generate code for any of these ARM processor families:

arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710 arm710c arm7100 arm720 arm7500 arm7500fe arm7tdmi arm7tdmi-s arm710t arm720t arm740t strongarm strongarm110 strongarm1100 strongarm1110 arm8 arm810 arm9 arm9e arm920 arm920t arm922t arm946e-s arm966e-s arm968e-s arm926ej-s arm940t arm9tdmi arm10tdmi arm1020t arm1026ej-s arm10e arm1020e arm1022e arm1136j-s arm1136jf-s mpcore mpcorenovfp arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-a15 cortex-r4 cortex-r4f cortex-r5 cortex-m4 cortex-m3 cortex-m1 cortex-m0 cortex-m0plus xscale iwmmxt iwmmxt2 ep9312 fa526 fa626 fa606te fa626te fmp626 fa726te

In practice, things are a bit trickier, if we insist on a compiler “toolchain” which is open source, with stable releases for Windows, Mac, and Linux. Note that a toolchain is a lot more than a C/C++ compiler + linker. It’s also a calling convention, a run-time library choice, a mechanism to upload code, and a mechanism to debug that code (even if that means merely seeing printf output).

In the MBED world, the toolchain is in the cloud. It’s not open source, and neither is the run-time library. Practical, yes – introspectable, not all the way. Got a problem with the compiler (or more likely the runtime)? You’re hosed. But even if it works perfectly – ya can’t peek under the hood and learn everything, which in my view is at least as important in a tinkering / hacking / repurposing world.

Outside the MBED world, I have found my brief exploration a grim one: commercial compiler toolchains with “limited free” options, and proprietary run-time libraries everywhere. Not my cup of tea – and besides, in my view gcc/g++ is really the only game in town nowadays. It’s mature, it’s well supported, it’s progressing, and it runs everywhere. Want a cross compiler which runs on platform A to generate code for platform B? Can do, for just about any A and B – though building such a beast is not necessarily easy!

As an experiment, I wanted to try out a much lower-cost yet pin-compatible alternative for the MBED, called the LCPXpresso (who comes up with names like that?):


Same cost as an Arduino, but… 512 KB flash, 64 KB RAM, USB, Ethernet, and tons of digital + analog I/O features.

Except: half of that board is dedicated to acting as an upload/debug interface, and it’s all proprietary. You have to use their IDE, with “lock-in” written on every page. Amazing, considering that the ARM chip can do serial uploading via built-in ROM! (i.e. it doesn’t even have to be pre-flashed with a boot loader)

As an experiment, I decided to break free from that straight-jacket:

DSC 3832

Yes, that’s right: you can basically throw away half the board, and then add a few wires and buttons to create a standard FTDI interface, ready to use with a BUB or other 3.3V serial interface.

(there’s also a small regulator mod, because the on-board 3.3V regulator seems to have died on me)

The result is a board which is pin-compatible with the MBED, and will run more or less the same code (it has only 1 user-controllable LED instead of 4, but that’s about it, I think). Oh, and serial upload, not USB anymore.

Does this make sense? Not really, if that means having to manually patch such boards each time you need one. But again, keep in mind that the boards cost the same as an Arduino Uno, yet offers far more than even the Arduino Mega in features and performance.

The other thing about this is that you’re completely on your own w.r.t. compiling and debugging code. Well, not quite: there’s a gcc4mbed by Adam Green, with pre-built x86 binaries for Windows, Mac, and Linux. But out of the box, I haven’t found anything like the Arduino IDE, with GUI buttons to push, lots of code examples, a reference website, and a community to connect with.

For me, personally, that’s not a show stopper (“real programmers prefer the command line”, as they say). But getting a LED to blink from scratch was quite a steep entry point into this ARM world. Did I miss something?

Two more notes:

  • Yes, I know there’s the Maple IDE by LeafLabs, but I couldn’t get it to upload on my MacBook Air notebook, nor get a response to questions about this on the forum.

  • No, I’m not “abandoning” the Atmel ATmega/ATtiny world. For many projects, simple ways to get wireless and battery-operated nodes going, I still vastly prefer the JeeNode over any other option out there (in fact, I’m currently re-working the JeeNode Micro, to add a bit more functionality to it).

But its good to stray outside the familiar path once in a while, so I’ll continue to sniff around in that big ARM Cortex world out there. Even if the software exploration side is acting surprisingly hostile to me right now.

Interesting gateway

In Hardware on Sep 12, 2012 at 00:01

A while back, I came across this product, called the “mbed Internet of Things Gateway”:


It’s an ARM microcontroller with an Ethernet port, a µSD storage slot, and an RFM12B wireless transceiver. Very nicely packaged in an extruded-aluminium case with laser-cut front and back panels. Here’s what’s inside:

DSC 3833

Not that much circuitry, as you can see – because all the heavy-lifting is done by the MBED board on the left.

That’s a 32-bit microcontroller, with built-in Ethernet and USB, plenty of I/O pins, and lots of features to connect to SPI, I2C, CAN, and other types of devices. Not to mention the 512 KB flash and 32 KB RAM memory – plenty to implement some serious functionality.

MBED comes with an intriguing “cloud-based” compiler and build environment, which is surprisingly effective. Here’s how it works, out of the box:

  1. plug the MBED into USB and it’ll present itself as a memory disk with one HTML file on it
  2. double-click that file to go to the MBED web site
  3. you get a web-based equivalent of a standard Windows IDE, plus a large code sharing community
  4. create your project online, enter your own code, and hit the compile button
  5. if the code compiles successfully, you end up with a file in your download folder
  6. copy that file to the MBED’s USB drive
  7. press on the MBED’s reset button, and that’s it … uploaded and running!

This is a very elegant workflow. No need to install any software to develop for MBED. And you can continue work wherever you are, as long as internet works and you have your MBED with you. You do need to sign up and register a (free) account on that MBED site – in return, they’ll do all the compiles for you.

This board is an exciting development. The cost is higher than with just a JeeNode + EtherCard, but there is also a lot more possible when you don’t have to fight the ATmega328’s strict flash and RAM memory constraints.

I’ll have more to say about this hardware and software tomorrow – stay tuned…

Delayed power-up with P-MOSFETs

In Hardware on Sep 11, 2012 at 00:01

This is a follow-up to the Delayed power-up post, this time using some P-MOSFETs (in SOT-23 SMD form, i.e. tiny). The way I’m testing these, is by using a 1 kΩ resistor as simulated load, and hooking things up as follows:

JC s Grid page 32

These components were not selected for this purpose, in fact, I picked units with a very low switching threshold voltage, so that they can reliably be switched on from an I/O pin, even if we were to run at just 1.8V.

Here are the characteristics of the Philips BSH203 P-MOSFET:

Screen Shot 2012 09 10 at 13 06 34

Just over 1 Ω resistance when driven low by 1.8V, so with a 50 mA load, the voltage drop over this MOSFET will be just over 50 mV.

When placed in the Component Tester, and zooming in on the interesting bit, we get:


Each major horizontal division is 2V, so this thing switches on at about 0.5V.

For comparison, the characteristics of the Vishay SI2333 P-MOSFET:

Screen Shot 2012 09 10 at 13 13 27

And in this case, the Component Tester shows this (sorry, can’t zoom in with this setup):


A slightly higher turn-on voltage, but note that the ON resistance is considerably lower at 1.8V: only 0.05 Ω. Not surprising, when you consider that this MOSFET can probably switch over 5 A (without self-destructing from the heat dissipation).

Here’s what these tiny components look like, with wires soldered on for “debugging”:

DSC 3828

Looks like either of these will do the trick, when switched from an I/O pin anyway.

Function generator weirdness

In Hardware on Sep 10, 2012 at 00:01

Fighting my lab instruments… not good :(

The TG2511 Arbitrary Waveform Generator in my lab is very flexible, and does all the usual things one would expect of a modern signal generator, i.e. setting the shape, frequency, and amplitude of its output signal.

But there’s some weirdness w.r.t. the amplitude. The built-in impedance is quoted as being 50 Ω, no doubt the reasoning being that if you terminate the cable with 50 Ω as well, then a standard coax cable will have the least possible signal degradation (ringing, reflections, and such).

There is a setting to adjust for the assumed load, so that the instrument can adjust its amplitude accordingly. The default is to assume a 50 Ω load at the end of the cable:

DSC 3826

But this is where I get mightily confused. Here’s what I see with the scope set in high impedance mode:


That in itself is actually correct: the output amplitude is twice the expected value, since there is no 50 Ω terminating resistor. So let’s add it in (it’s an option inside the scope):


Huh? – Why isn’t the amplitude 3 Vpp, and ends up being only half that value?

But there’s something even stranger, and far more inconvenient about the TG2511. After a few minutes, I often get a message about the output signal being overloaded:

DSC 3827

Doesn’t make sense. I’m never loading the output with more than 50 Ω, i.e. well within specs. Sometimes this happens even when I completely disconnect the load. Even more suspect: the green “OUTPUT” doesn’t always match what’s happening. Sometimes the light is off, yet the output signal is still present!

In fact, I get this screen in the most unexpected situations. Maybe the TG2511’s output stage is broken? Yuck.

I have contacted the supplier for advice.

Delayed power-up

In AVR, Hardware on Sep 9, 2012 at 00:01

To recall yesterday’s reasoning, I’m looking for a way to keep the RFM12B from starting up too soon and drawing 0.6 mA before the microcontroller gets a chance to enable it’s ultra-low power sleep mode.

The solutions so far require an extra I/O pin, allowing the microntroller to turn power on and off as needed, with the extra detail that power stays off until told otherwise.

But all I’m really interested in, is to keep that RFM12B from powering up too soon. After that, I never need to power it down again (and lose its settings) – at 0.3 µA, the RFM12B’s sleep mode will be just fine.

One solution is to use a dedicated chip for this, which can reliably send out a trigger when a fixed voltage threshold has been exceeded. That would still need a MOSFET, though, so this increases the cost (and footprint) of such a solution.

The other way would be to create a low-speed RC network, gradually charging a cap until a threshold is reached and turns on the MOSFET switch. Lower cost, no doubt, but in fact not flexible enough in case of a very slow power-on voltage ramp, as in the case of a solar cell charging a supercap or small battery. There is just no way to determine how long the delay needs to be – it might take days for the power rail to reach a usable level!

Yet another option is this little gem (thanks for the initial suggestion, Martyn!):

JC s Grid page 32

No I/O pin, no pull-up, nothing!

This trick takes advantage of what was originally considered a drawback of MOSFET switching: the fact that the gate voltage has to reach a certain level before the MOSFET will switch. Assuming that voltage is say 1.5V, then the MOSFET will be turned off as long as the power rail has not yet reached 1.5V, and once it rises above that value, it’ll automatically switch on. Magic!

Does it work? Well, I’m still waiting for some P-MOSFETs to arrive, but I’ve done a little test with an N-MOSFET, connected the other way around and using a 1 kΩ resistor as load. We can look at that combination as a component which has only two pins: a power rail and ground.

If the circuit works as expected, then when applying an increasing voltage, no current will flow until the threshold has been reached, and then it’ll switch on and start drawing current.

As it turns out, this is very easily observable using a Component Tester – like the one built into my scope:


The horizontal scale is the applied voltage (from about -5V to +5V), the vertical scale is the current through that component (from about -5 mA to +5 mA). The straight slanted line is characteristic of a 1 kΩ resistor.

But the interesting bit is that little dent: from under 0V to about 1.5V, the circuit draws no current at all. Once 1.5V or more are applied, the circuit starts conducting, and behaving like a plain 1 kΩ resistor again.

Woohoo, this might actually work: just a single P-MOSFET would be all that’s needed!

Switching with a P-MOSFET

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

One reason for yesterday’s exploration, is to figure out a way around a flaw of the RFM12B wireless radio module.

Let me explain – the RFM12B module has a clock output, which can be used to drive a microcontroller. The idea being that you can save a crystal that way. Trouble is that this clock signal has to be present on power-up, even though it can be configured over SPI in software, because otherwise the microcontroller would never start running and hence never get a chance to re-configure the radio. A nasty case of Catch 22 (or a design error?).

In short: the radio always powers up with the crystal oscillator enabled. Even when not using that clock signal!

The problem is that an RFM12B draws about 0.6 mA in this mode, even though it can be put to sleep to draw only 0.3 µA (once running and listening to SPI commands). In the case of energy harvesting, where you normally get very tiny amounts of energy to run off, this startup hurdle can be a major stumbling block.

See my low-power supply weblog post about how hard that can be, and may need extra hardware to get fixed.

So I’m trying to find a way to keep that radio powered down until the microcontroller is running, allowing it to be put to sleep right away.

For ultra-low power use, yesterday’s PNP transistor approach is not really good enough.

This is where an interesting aspect of MOSFETs comes in: they make great power switches, because all they need is a gate voltage to turn them on or off. When on, their resistance (and hence voltage drop) is near zero, and the voltage on the gate doesn’t draw any current. Just like a water faucet doesn’t consume energy to keep water running or blocked, only to change the state – so do MOSFETs.

But many MOSFETs typically require several volts to turn them on, which we may or may not have when running at the lower limit of 1.8V of an ATmega or ATtiny. So the choice of MOSFET matters.

Just like yesterday, we’ll need a P-channel MOSFET to let us switch the power supply rail:

JC s Grid page 32

Note the subtly different placement of the resistor. With a PNP transistor, it was needed to limit the current through the base (which then got wasted, but that current is needed to make the transistor switch). With a MOSFET there is no current, but now we need to make sure that the MOSFET stays off until a low voltage is applied.

Except that now R can be very large. It’s basically a pull-up, and can be extremely weak, say 10 MΩ. That means that when pulled low, the leakage current will be only 0.3 µA.

The trick is to find a P-MOSFET type which can switch using a very low gate voltage, so that it can still be fully switched on. I’ve ordered a couple of types to test this out, and will report once they arrive and measurements can be made.

All in all, this is a very nice solution, though – just 2 very simple components. The main drawback is that we still need to reserve an I/O pin for this.

Tomorrow, I’ll explore a refinement which does not even need an extra I/O pin.

Switching with a PNP transistor

In Hardware on Sep 7, 2012 at 00:01

This is an exploration to find out what circuit can be used to switch small electronic loads using a digital I/O pin.

The simplest solution by far, is to use the I/O pin to directly drive the circuit. This works great for low currents, such as an LED with series resistor. But there are limits to how much current you can draw:

Screen Shot 2012 09 06 at 22 49 12

As you can see, from the datasheet, drawing 5 mA will already cause a voltage drop of about 0.2V, so the load will not get the full supply voltage. With larger loads, the drop becomes even more pronounced.

Another approach is to use a PNP transistor, as follows:

PNP drop

Here’s how it works, in case you’re not familiar with them PNP transistor thingies:

  • pulling the input pin down towards 0V, will turn the PNP transistor on
  • when on, the transistor will conduct and supply power to the load
  • leaving the pin floating or pulling it up, will cause the PNP transistor to turn off

In my setup, I’m using a very light load for now. The following measurements will be different as the load increases, but not as substantially as with the raw I/O pin drive. A circuit like this could easily drive a 100..250 mA load, if the base resistor has the right value – as we’ll see.

Time to try this out. I am quite interested in how the voltage drop over the transistor depends on the exact voltage placed on the base junction. Or rather: how much current I’ll need (since the resistor passes a known current once we know the voltage drop.

So as input, I’m using a 10 Hz sawtooth signal, which varies from 0 to 3V. Due to the way things are hooked up, it starts at 3V below the 3.3V power rail, i.e. 0.3V, and then rises to the level of the power rail.

Here are the results with a 10 kΩ resistor – both signals have been inverted, as I’m measuring relative to +3.3V:


(oops, ignore the yellow trigger point baseline)

At the start, the transistor is turned on strongly, and then the input voltage falls to zero (yellow trace). As you can see, the voltage drop over the transistor increases non-linearly as it gradually turns off. With only 1V driving it, the voltage drop increases from about 40 mV to 100 mV, i.e. 0.1V. With even less, it starts to switch off and gets the full power supply voltage (so nothing reaches the load).

Now let’s do some math. I used my transistor tester to determine that this particular BC557 PNP transistor had 0.8V drop over its base-to-emitter junction, and that its current amplification factor (hFE) is about 220x.

In other words: with 1.0V on the input, there is 1.0-0.8 = 0.2V on the 10 kΩ resistor. Ohm’s law (E = I x R, or I = E / R) implies that the current through the resistor will be 0.2V / 10kΩ = 20 µA. This current is essentially “wasted”, but given the 220 factor, it will allow the transistor to drive up to 20 µA x 220 = 4.4 mA. Not so great…

Update – not sure what I was smoking at the time I wrote the above paragraph. That’s 1.0V below VCC, roughly the switching threshold of this transistor when used with a 1 kΩ load. I’m not sure what point I was trying to make here, other than that a 20 µA base current is not enough to switch an RFM12B.

But if we pull the input to almost ground level, as would be the case with a digital I/O pin, then the base current increases to (3.3 – 0.8) / 10,000 = 250 µA, supporting a load of up to 250 µA x 220 = 55 mA.

If power waste is not an issue, we could reduce the base resistor to 1 kΩ, and get over 500 mA load switching capability (assuming the transistor is powerful enough). The base current will then be around 2.5 mA, a value which an ATmega I/O pin can still easily supply.

But what if power use is important, i.e. if we can’t afford to waste those 20 µA or more?

Here’s the same circuit, with a 100 kΩ resistor instead:


Note how the emitter-to-collector voltage drop (blue line) rises. With 3V input differential, i.e. almost pulled to ground, the drop over the transistor is still under 0.15V, but we’ll need to keep the input voltage at least 1.5V below the power supply voltage to make this work. So in very low-voltage / low-power scenario’s (i.e. running off two almost-depleted AA cells), this might become tricky.

The current losses are now only 1/10th, i.e. 25 µA when the power supply is 3.3V and the input is tied to ground. Then again, in the ultra-low power world that wasted 25 µA is not really such an impressive figure.

Still, for switching loads which draw up to a few hundred milliamps, this circuit using just a PNP transistor and a resistor is really quite practical. If you use a 1 kΩ resistor, the base current will be well with the I/O pin’s capabilities, and the transistor will usually have enough drive to switch its load.

The only other drawback is that the transistor will always add a small voltage drop of perhaps 50 .. 200 mV.

There is a third solution using MOSFETs, with its own set of trade-offs. To be continued…

Shop trick

In Musings on Sep 6, 2012 at 00:01

The JeeLabs Shop has gained some extra functionality, since about a year, as it now lets you “sign up” and add a password to simplify re-ordering later.

What I didn’t know until today (thanks, Martyn) is that there is actually a way to access the order history and to manage your shipping address(es).

The trick is to go to – which will redirect you to a login page unless your browser has already saved the relevant cookies:

Screen Shot 2012 09 05 at 20 05 43

Once logged in, you can see what you’ve ordered in the past:

Screen Shot 2012 09 05 at 20 09 18

In my case, most of these orders were of course just dummies, which I then cancelled.

Three things to note about this functionality:

  • yes, the shop will use cookies if you decide to sign-up when placing an order
  • you can’t change the info on existing orders (contact order_assistance at jeelabs dot org for that)
  • I’ll update the email confirmations sent out to mention this feature

I still think that there are plenty of smaller and larger inconveniences in this shop (hosted by Shopify), none of which I have control over unfortunately, but it’s good to know that this history mechanism is there if you need it.

Current clamp

In Hardware on Sep 5, 2012 at 00:01

To continue where I left off before the summer, let’s examine what a current clamp like this one does:

DSC 3354

You put it around a single wire in your AC mains cabling and it’ll generate a voltage proportional with the current going through it. This unit has a built-in burden resistor, which means you get a ± 1V (AC!) output when the current through the wire is 30 A. So let’s have some fun and look at a couple of different loads, eh?

Let’s start off with an old-fashioned 25W incandescent light-bulb, which is a resistive load:


Note the vertical scale – these voltage levels are tiny. The scope caclulates the Root Mean Square (RMS) voltage as being 3.52 mV in this case. That’s the voltage you’d need to draw as direct current to dissipate the same amount of power as this alternating current (let’s ignore phase shift and “reactive” vs “true” power for now).

Sure enough, a 75W light bulb draws three times as much power (note the different vertical scale):


Here’s a 2W LED light bulb, which uses an electronic circuit to pulse small amounts of energy from AC mains:


Again, note how this minute RMS reading corresponds quite accurately to the specified wattage.

Now let’s take a vacuum cleaner, which is an inductive load, and quite a lot beefier too:


The “blips” are switching artifacts from the TRIAC control included in this unit. From the RMS value, my estimate would be that it draws about 1500W. Here’s the same vacuum cleaner, with its power throttled back to minimum:


As with the LED light, you can see the electronics kicking in and pulsing AC mains to throttle power back to around 500W.

Conclusion: a current clamp is a safe way to measure current in an AC mains wire, and it more or less reproduces the measured current as a small output voltage. Very small in fact, for light loads. To accurately determine the RMS value of a load as small as our 2W LED light, we’re going to have to read out this signal in the sub-millivolt range, and do so at perhaps 1000 HZ to collect enough readings per 50 Hz cycle.

Tizio LED transplant

In Hardware on Sep 4, 2012 at 00:01

For some time now, there have been two of these Tizio lamps in the house. A gorgeous design and very practical:

DSC 3517

As so many lamps from last century, they come with a halogen incandescent light bulb:

DSC 3507

Lifetimes are great (I don’t think I ever replaced one), but efficiency less so. So I decided to replace them anyway:

DSC 3509

These are simple 1.2W warm-white LED lights with built-in rectifier and current limiting resistors. Here’s the result:

DSC 3508

The transplant ended up being very simple, the UV filter glass is no longer needed, the power consumption has dropped from 50W 35W to 12W 5W, and – if all is well – these LEDs will never need to be replaced again.

Easy peasy! Now if only all our incandescent lights had equally simple alternatives…

Shoppety shop

In News on Sep 3, 2012 at 00:01

Short post, with big consequences for me…

As you might have noticed, the Jeelabs Shop has been kept open and operational during the summer break. The reason for this, is that Martyn and Rohan Judd have set up what is now essentially a fantastic fullfilment service for JeeLabs.

As a result, this welcome message on the shop’s home page is now more or less permanent:

Screen Shot 2012 09 02 at 23 45 26

The limit for free shipping has beeen raised somewhat, due to the higher cost of shipping to “mainland” Europe from the UK. The other major change is that you need to use the indicated email address to make sure your message reaches me and all people involved.

Note that I am out of the loop for day-to-day order processing, but not out of the loop in any other way!

There will be more changes, most of them probably behind the scenes, as we work out all the details of doing business this way. As far as the shop is concerned, the orders are still placed in the Netherlands, and I remain as before fully responsible and accountable for everything that happens – both good and bad. VAT processing (and VAT exemption for EU-based business outside the Netherlands) will also remain exactly as before.

I am quite confident that this change will allow me to spend more time on the R&D side of things regarding all current and future JeeLabs projects.

Which, dear reader, is – and remains – my main motivation for doing all this, of course.


JeeLabs logo

In News on Sep 2, 2012 at 00:01

Tada! I’m really proud to be able to present the JeeLabs new-and-official “look” to you!

Here is the new logo for JeeLabs – nicely distinctive and with a little wink towards battery-powered electronics:

Screen Shot 2012 09 01 at 22 19 14

As you can see, this has been incorporated into the weblog, as header and as “favicon”.

I hope you like it.

The proportions and font used for the “JeeLabs” text in the header above are still work-in-progress. In fact, I just used the Trebuchet MS font with smallcaps for now, because it sort of resembles the letters in the logo. If you have tips or suggestions for this, let me know…

One more announcement tomorrow, then “regular” JeeLabs posts will resume – promise!

Fully recharged

In Musings on Sep 1, 2012 at 00:01

… and ready to go! (is this what they mean by “solar energy”?)

We had a gorgeous vacation. The best part: the car broke down at the start of our trip, forcing us to make some quick decisions. So we ended up in Retournac, a little village in the south of the Auvergne while getting that car fixed (kudo’s to Volkswagen for their splendid service, which included a free rental car replacement). In fact, we liked this place so much that we decided to come back to it in the second part of our vacation – this little spot was unbelievably calm, with a great little Camping Municipal on the border of the Loire, and restaurants with fantastic 4-course plat du jour meals for the price of what would get us just about one pizza back home.


See that little green tent over on the left, under the trees? No? Oh well, that’s where Liesbeth and I set up camp :)

What else to do in France in high season, apart from going on lots of hikes and lazily reading books? Well, we visited lots of smaller and larger villages for one, such as these:


… and we chased all the scents in those gorgeous little markets everywhere:


The other half of our vacation was spent visiting French & Portuguese friends in the area.

It was a truly wonderful break … and now it’s time to get back to Physical Computing!