Computing stuff tied to the physical world

Archive for 2008


In AVR on Dec 21, 2008 at 15:56

Microcontrollers with attached RF transceivers are starting to multiply like rabbits around here:


This is an Arduino Mini Pro with an RFM12B. The nice property of this combo is that the mini has on-board 3.3V regulation, which is the voltage required for RFM12B’s, and with a little tweaking of the FTDI connector the Arduino itself can be made to run at that same voltage. This avoids the need for level conversion.

That brings the total number of functioning RFM12B’s to four right now. Two have been in permanent use for monitoring energy & gas consumption for over a week now.

The other two, including this new unit, will allow me to further refine the software. A first advance has already been implemented: the receiver code is now interrupt-based, leaving the MCU free to handle other tasks at the same time.


In AVR on Dec 20, 2008 at 15:56

Failures are worth documenting too… here is one:


This was intended to become a general-purpose 868 MHz wireless solution: a low-end receiver + transmitter from Conrad, alongside an 868 MHz RFM12B which is likely to become my workhorse module. The receiver + transmitter are compatible with the FS20 wireless remote protocol, and allow listening as well as controlling these devices.

Well, most of this stuff didn’t work once hooked up. For various reasons actually – from bad sensitivity to using the wrong module (turns out that RFM12 unit was in fact for 433 MHz, doh).

In an attempt to salvage this thingamagic, I decided to replace & rewire the whole thing. It is now a 433 MHz receiver + transmitter, and an RFM12, also working on 433 MHz. The whole has been put aside for now, but maybe one day it can be made to work with some 433 MHz stuff, such as this or some cheap weather sensors.

Due to the switch to a lower frequency band, all three antennas are now 17 cm long wires.

The microcntroller is an Arduino Nano, btw. This is a 16 MHz 5V unit with a mini-USB port.

More readings

In Software on Dec 19, 2008 at 15:55

Here is the latest display showing on my screen:


Updated in real time, with new readings coming in every few seconds for electricity and gas and every few minutes from the weather station (still sitting here in the office for now, so the values are bogus).

Different 868 MHz units

In AVR on Dec 18, 2008 at 15:54

Here’s a small but fairly general-purpose setup:


At the top right is the NSLU2, a very useful little NAS box with two USB ports plus Ethernet. It has been re-flashed to run a standard Debian Etch Linux system – using a 4 Gb USB stick plugged into the upper USB slot on the back. The other three connections are: ethernet, power, and an un-powered USB hub.

Plugged into the USB hub are three RF units – from left to right:

  • the RFM12B, hooked up to an Arduino Mini Pro
  • a simple 868 MHz receiver, connected to a USB Boarduino
  • the CUL plug, with its own ATmega and CC1101 transceiver

Each of these uses the same 868 MHz RF band, but with different transmission modes and protocols.

You’re looking at a micro-power 4-CPU cluster with a total power consumption of 3.5 watt. This is now a test rig for collecting various kinds of data.

This is not a mouse

In AVR, Hardware on Dec 17, 2008 at 15:53

The CUL is a small gadget which combines a CC1101 RF module with a USB-enabled ATmega processor in a very small unit:


So, yes, it has a tail and it plugs into a USB port, but it’s not a mouse. This thing can receive and decode messages from 868 MHz devices such as the FS20 home control unit, the KS300 weather sensor, and more. Technically, it could also send out such messages since the CC1101 is a transceiver, but apparently the 1.07 firmware isn’t quite there yet.

Switching stuff

In Hardware on Dec 16, 2008 at 15:51

Today, some simple “KAKU” remote switches came in. These are both by KlikOn-KlikOff – the first one is an older setup I was already using, with up to 12 different codes:


The second is a newer model with up to 256 different codes – it’s heavily discounted (€14 for 2 units plus transmitter), probably because this type is being replaced by a newer model which uses unique unit codes:


The drawback with both of these, as compared to the FS20 models by Conrad, is that you can’t control them at the plug – you have to locate the remote and press buttons on it. But then again, at these low prices per unit … you get what you pay for.

These units use 433 MHz signalling, there’s code for Arduinos which understands the KAKU protocol.

Energy & Gas Consumption

In Uncategorized on Dec 14, 2008 at 15:49

These last few days, a little application has been running here which tracks energy (i.e. electricity) and gas consumption in the house, in a little window of its own:


That’s 640 watt and 1.333 m3/hr. These values are normally updated a few times a minute. There are still some wrinkles in the software, such as the gas consumption not adjusting properly when the meter stops fully, i.e. when no pulse is received once the central heating turns off.

The following systems are involved in this setup:

  • some sensors and a transmitter based on an RBBB Arduino with an RFM12B
  • a USB-powered receiver based on an Arduino Mini Pro with its own RFM12B
  • a Linux server, i.e. a modified version of the Bubba/II NAS in this case
  • the Mac notebook I usually work on, though it could be anything really

Only the first 3 items above need to be always on, with a combined power usage of less than 10W. Every 3 seconds, sensor readings are transferred and stored on the server, using a trivial text format for now. This proof-of-concept setup uses rsync to transfer the log from the server to the notebook every 20 secs, so the above window isn’t yet as real-time at it could be.

But even with such a crude setup it is easy to keep an eye on consumption – and by simply switching appliances on and off one can deduce their approximate power consumption.

Better Mousetrap

In AVR on Dec 12, 2008 at 15:48

Now that RF transmissions work better, it was a small step to create a better house usage monitor. This one supports four sensors:


Only two sensors are being used so far (all sensor inputs are identical).

Sensor #1 watches the electricity meter rotations using the SY310 sensor:


Sensor #2 is a QRD1114 which tracks a little mirror mounted on the last digit “0” of the gas meter:


The sensors were described in a previous post. Proper positioning turned out to be crucial, so there’s a fair bit of scotch tape to hold everything in place!

Good RF with RFM12B

In AVR, Software on Dec 11, 2008 at 15:38

Yippie. Got a simple blinking LED demo running on RFM12B’s after lots of head-scratching. Had to understand ATmega’s SPI mechanism to get there, but these two boards now talk to each other over the air, uni-directionally:

Good RF

That’s an Arduino Mini Pro (which runs at 3.3V internally, as does the RFM12B). Power comes from the FTDI cable, but with a special hack to drive the raw power input from it, not the default VCC connection. This way, the on-board 3.3V regulator is used to lower the voltage for both the MCU and the wireless module.

The other board is a bit of a mess, has the same Mini Pro, but some other stuff which is partly a left-over from earlier experiments:

Good RF

Here a USB interface is used to provide 3.3V power. It’s functionally identical to the first board: with RFM12B’s the same setup can be used as transmitter or as receiver.

The top board is the receiver – its picture shows the green LED on, i.e. correct packet reception!

The hookup is very simple, just 5 wires between RF module and MCU, and 2 power pins / 1 pull-up / 1 antenna wire on the RF module is all it takes. The 5 wires are standard SPI plus an IRQ line:

  • MOSI (MCU) –> SDI (RFM)
  • MISO (MCU) <– SDO (RFM)
  • SCK (MCU) –> SCK (RFM)
  • SS (MCU) –> nSEL (RFM)
  • PD2 (MCU) <– nIRQ (RFM)

It took some work to get the software working. The trouble with this stuff is that until you get both transmitter and receiver working properly, it all remains a bit hard to debug. And there are quite a few registers to set up on the RFM12B to make it do its magic.

But after some tweaking, the rfm12xmit and rfm12recv sketches for the Arduino IDE started working. First with bit-banged SPI coding, but then also with the ATmega168’s built-in SPI hardware. Which is nice, because all exchanges now take place at 1..2 MHz (i.e. 8..16 µsec per 16-bit command). All I/O with the RF module uses simple busy polling for now.

The RF range and quality of reception with the RFM12B is considerably better than my earlier 868 MHz AM setup. Packets now easily get across 3 layers of stone/concrete and all of them appear to be arriving properly.

Update – here’s the C source code for the xmit and recv sides.

Update 2 – the connections for MISO and MISO as listed above were reversed – many thanks to José Xavier for pointing this out. The text above has been fixed.

Wireless RFM12B Module

In Hardware on Dec 10, 2008 at 15:36

A new 868 MHz module came in today, which uses FSK as modulation method:


This is a tiny 16×16 mm RFM12B module. It contains a transceiver and can be connected with a 4-pin SPI bus plus an IRQ pin to send/receive bytes using interrupts. Documentation is a bit sketchy, but there are a few different code samples on the net.

This version is for SMD mounting (with 2mm pins, again). But it’s easy to add a few wires and use this in a 0.1” grid breadboard. The antenna used here is an 82 mm straight wire.

IR Sensors

In Uncategorized on Dec 8, 2008 at 15:35

Here are two new home-made sensors, improving on this one they will soon replace:


The top one uses a QRD1114 sensor, which produces an analog signal, whereas the lower one is based on the SY310 with a built-in comparator to generate a digital output. The intended range is around 5..15 mm, hopefully just right to detect the 0-digit reflector on the gas meter and the the rotations of the energy meter, respectively.

Both of these sensors are connected to a 3-wire audio jack cable: shield = ground, ring = +5V, and pin = signal. Both sensors use a 330..470 Ω resistor to drive the IR-LED and a second one of 10..100 KΩ as pull-up for the output signal.

Home Control

In Hardware on Dec 7, 2008 at 15:34

The FS20 system by Conrad is a simple RF-based set of modules to turn various appliances on and off. The transmitter looks like this:


The most basic on/off remote control switches are as follows, shown with central European power plugs:


They have an on/off toggle on the unit, which is a big plus over simpler units. The other useful aspect of these units is that they operate over the 868 MHz band, and that the details of the FS20 protocol are available. Several projects exist which can receive and/or transmit the corresponding signals.

Definitely not the most beautiful design, but hey, they get the job done…

Timer Interrupts

In AVR, Software on Dec 6, 2008 at 15:33

Here is some new interrupt-driven receiver code. This receiver is considerably better at identifying correct packets, regardless of what other bit patterns are coming in. The new code is based on a state machine which takes pulse times and gaps into account, detecting all valid sequences of pulse widths and rejecting all outliers. The main code is:


Then, in the main loop, this code picks up the results:


Also, with an interrupt driven design the receiver no longer depends on timing loops and is free to spend its time in other logic. It is now possible to run multiple state machines in parallel, decoding a variety of different signal patterns.

Bad Reception

In AVR, Hardware on Dec 5, 2008 at 15:32

This is a USB Boarduino with an 868 MHz receiver connected to it:


The antenna is a short 82 mm wire. Just like the one used in this setup. Given the same software, it receives the same signals.

But somehow, it’s considerably less sensitive – so far this unit won’t pick up the (faint) transmissions from the energy monitor nearly as reliably as the first setup. It’s not a matter of noise signals, antenna placement, or any hardware differences (all physical variations give the same result). Must be moon phases, or something. I’m going to let it rest and focus on other RF options instead.

The original polling setup has been working fine for several days now, btw.


In AVR on Dec 4, 2008 at 15:31

This watchamacallit is a hookup to the electricity meter downstairs:


It has a sensor concocted from an ultra-bright LED and a phototransistor, which senses when the black marker on the rotating wheel passes underneath it.

This sensor is tied to an RBBB Arduino which tracks and transmits the rotation count every 3 seconds on 868 MHz, using the previously created setup:


The green transmitter PCB is in front at the top. The whole thing is powered by a 9V adapter.

To deal with quick rotations, the sensor is read out about 100 times per second, also during each 100 msec transmission. These were rough calculations and the transmissions no doubt have considerable jitter due to inaccurate timing. A timer- / interrupt-driven version will probably improve accuracy and transmit range. But for now this crude setup appears to provide acceptable readings.

This Tcl script saves the results to file on MacOSX:


And this is an extract of that log file (showing roll-over and some missed packets):


The 94..97 values are the rotation count. This also shows that the log remains usable even when packets are missed.

Success @ 868

In AVR, Software on Dec 3, 2008 at 15:29

As expected, a lot of the bit-level reception problems with the 433 & 868 MHz wireless issues can be resolved with better packet framing and reception logic. Here’s part of the latest reception log, alll the way across those elusive 3 stone/concrete walls:


There are still times when proper reception stutters, but as long as reception recovers within a minute or so that’ll be fine for the purpose of low-rate data logging.

The send format now includes an old-fashioned SYN-bytes-plus-SOH header:


Reception takes a bit more code, here’s the basic frame reception loop:


And here’s the bit-level decoder:


The receiver + serial debugging code takes a mere 3208 bytes so far.


In Hardware on Dec 2, 2008 at 15:27

The nice part of this transceiver by Ideetron is that it’s cheaper yet more advanced than the 433 & 868 MHz radio modules by Conrad:


I does have that awkward 2mm pin header, but Ideetron most generously threw in a few female headers for free.

This modules uses a CC2500 chip operating at 2.4 GHz. The interface is via SPI commands, which provides various registers to exchange data both ways. All the bit manipulation and byte synchronization is handled, and the communication is bi-directional, allowing for a packet-oriented design with positive acknowledgement.

Unlike the iDwarf kit there is relatively little sample software to get started with this module, so it will take more work to get this going. Having an on-board antenna just like the iDwarf and XBee and using the same 2.4 GHz frequency band, the range might again be insufficient to pass through a few stone walls, but that’s just guessing for now.

From 433 to 868

In AVR, Hardware on Dec 1, 2008 at 15:26

These are the 868 MHz modules from Conrad – receiver on the left, transmitter on the right:


Worked as straight replacements in the 433 MHz setup, but there seems to be some problem with noise. It got a bit better when the receiver was tied to an 82 mm wire as antenna (as shown), i.e. exactly 1/4 wavelength. And that funny transmit antenna wire/coil probably isn’t optimal either…

Still, a bit noisy, lots of spurious pulses, and only occasional CRC-valid reception. It looks like much of the problem is caused by the crude bit-start synchronization software. Needs more work, clearly.


In AVR, Hardware on Nov 30, 2008 at 01:06

The iDwarf system is a wireless 2.4 GHz radio module with an ATmega168 inside. The starter kit comes with two sensor nodes with built-in battery holder and one “hub” which interfaces to (and runs off) USB:


The daughterboards showing on top are the actual modules, the rest is part of the starter kit, i.e. sensor node and hub interface boards.

Several software examples were included, with hex files ready to try. It took me a while to figure out that I had to also set up the fuse bits – as delivered, the 168 is completely empty:


And just changing some ’s to /‘s in the source was all it took to re-compile these examples from source on MacOSX (the actual radio driver code is linked in from a library, no source, though).

Having a fully programmable chip to customize, with over half of its memory free makes this a more flexible option than XBee’s, at about the same price.

First trials indicate that the range of these little modules is a bit limited. They didn’t maintain a connection across three layers of stone & concrete (floors / walls) – a hefty requirement, but all within a single home. Still, it’s impressive what a pair of tiny on-board antennas can accomplish.

Wireless at 433 MHz

In AVR, Hardware on Nov 29, 2008 at 01:03

This was an experiment to learn about low-power / low-range wireless communication using a 433 Mhz transmitter / receiver set from Conrad. The transmitter was tied to an RBBB board and accessed via an FTDI-USB cable:


The receiver was mounted on a proto shield with breadboard, on top of a standard Arduino:


The software for this requires some attention due to the crude communication system.

Basically, the transmitter is turned on and off by a serial bit stream, i.e. this is not FM or even AM, just the presence and absence of a signal. To make this work properly and get say 20 bytes of data across, you have to go through the following sequence:

  • turn on the signal for a few milliseconds so the receiver adjust its AFC (assuming it has one)
  • send a unique bit pattern so the receiver can synchronize to receive data as individual bytes
  • send the data bytes, i.e. the “payload”
  • send a 2-byte CRC so the receiver can verify proper reception
  • turn off the signal for at least a few dozen milliseconds to avoid hogging the radio channel
  • re-send the whole packet one or more times to deal with interference and collisions

Even then, correct reception is not guaranteed – that would require a transceiver setup with two-way acknowledgement.

Data is sent using Manchester code, a phase change trick which keeps the on and off times equal, on average. The signalling rate is only 1000 baud (i.e. 1 millisecond per bit) and even then the error rate is quite substantial.

The CRC is calculated via standard code from the avr-libc library. A little trick is used to simplify the code: when the two CRC bytes are appended in little-endian format, the receiver can calculate its CRC including these bytes and verify that the result is zero.

The C test code is in the download area – for both the transmission and the reception version. It uses busy loops for (rough) timing. An interrupt-driven version using one of the 168’s hardware counters would have been preferable, to generate a jitter-free signal and to be able to handle other tasks during reception.

The results indicate that the transmitter really needs an external antenna wire to cross more than a meter (!) or so of air. With antenna, the signal barely makes it through one (reinforced) concrete wall in the house, which is insufficient for my purposes, but an 868 MHz version will probably overcome this limitation.

Interface Woes

In Uncategorized on Nov 25, 2008 at 00:59

Ouch. It looks like there are two different Arduino Mini Pro’s around – a 5V @ 16 MHz and a 3.3V @ 8 MHz version. I thought I had the latter, but a quick check tells me otherwise. Which is no good when you’re trying to hook up 3.3V modules that do not tolerate 5V levels!

Oh well, just order the right one and wait for it to arrive…

Meanwhile, here’s another kind of impedance mismatch:


The obnoxious 2 mm vs. 2.54 mm pinout. Yuck.

Sequential Clock

In AVR on Nov 24, 2008 at 00:58

Here’s a little clock project with a twist – it displays the current time on a single large 7-segment LED display, by briefly showing each of the digits one after the other.


Note the transition from 12:20 to 12:21. The little red blinking light at the bottom is the actual DCF77 radio signal, one pulse each second, with a long/short duration to encode each bit.

This project uses a Boarduino as brains, a DCF77 radio receiver, a large Kingbright 7-segment display, a 2981 LED driver, a bunch of 470 Ω current limiting resistors (1K for the decimal point), and a 6..12V DC power supply:


On the left are the power plug and 5V regulator, on the right of the Boarduino you can see the reset button, 2×3-pin ICSP header, and 6-pin header used for programming with a USB-FTDI cable. On the far right is the 2981 chip used to drive the LED segments with 8..14V.

The radio print is soldered directly to the Boarduino (digital I/O pins 2..5) in such a way that the reception antenna with L/C circuit fits is snugly between the radio print and the display module. For simplicity, the radio’s +5V and ground are also provided by the Boarduino via digital I/O pins – they are fixed on startup as “1” and “0” outputs, respectively.

I used wire-wrap wire to make the connections because it’s so thin and solders very easily:


One nice software gimmick is that the clock starts by displaying a personalized greeting, since this project was made as birthday gift for a friend. Once the proper DCF77 radio signal has been decoded, the display switches to showing the current time; this usually takes two to three minutes after power-up. The clock will continue to run on its own with ≈ 0.5% accuracy in the absence of valid radio signals.

The C source code can be downloaded here. It decodes the DCF signal and encodes / drives the 7-segment display in a continuous loop.


In AVR on Nov 23, 2008 at 00:56

Several times now, I had to use an Arduino board to program an ATmega chip via the ICSP socket (to change fuse bytes or to set up / change the bootloader). Which works fine, but at some point the IC socket is probably going to wear out.

So I made this ZIF-socketed board, just for ICSP programming use:


The LED and 16 MHz resonator are not strictly needed, but this way the board also lets me run a test program at full speed and report its status via the LED.

XBee Adapters

In Hardware on Nov 21, 2008 at 00:55

Apart from the XBee shield, there are several other options to hook into that module with its non-standard 2-mm connector.

The simplest is a little breakout board which brings things back to “normal” 2.54 mm PCB units:


Next up is AdaFruit’s adapter which connects to an FTDI cable or plugs into a breadboard:


Finally, there is the Xbee Explorer USB which ties it directly to a slave USB port:


The adapter is probably the most convenient to embed and to use stand-alone, since it does all the voltage regulation and conversion in a simple package.


In AVR on Nov 19, 2008 at 00:54

The AVR Raven is an interesting successor to the AVR Butterfly. It has two ATmega processors on board, one drives an advanced transceiver for wireless use. This explains the double set of ICSP/JTAG headers:


Haven’t had much chance to play with it yet, other than to verify that the Ravens and the USB-stick base station work (current software requires a Windows server).

Mini Pro

In AVR on Nov 16, 2008 at 00:53

The Mini Pro Arduino (specs) is another way to embed an ATmega168 processor:


I added the pin headers, though one could also use this as a very flat embedded module by wiring directly to the circuit pads.

This one runs at 8 MHz and uses a 3.3V regulator (which means the I/O pins are also at that level). It’s not a kit, due to the use of SMD components.


In AVR on Nov 14, 2008 at 00:51

The USBtinyISP is a kit for a USB-connected AVR compatible ICSP programmer:


On the left are two cables, with 6-pin and 10-pin ICSP plugs, respectively. Inside is a pre-programmed ATtiny chip plus some level converters for use with 3.3V hosts (do need to remove a jumper for that).

Built into avrdude by using the “-c usbtiny” option. No need to specify port or baudrate (unlike some other programmers). To make this the default programmer, I added this line to my ~/.avrduderc:

        default_programmer = “usbtiny”;

This little device works really well.

Arduino on Lithium

In AVR on Nov 13, 2008 at 00:50

LiquidWare has a Lithium Backpack which goes underneath an Arduino:


It needs two wires to feed the regulated 5V power + ground lines directly into the Arduino (I could have also connected them to the ICSP header). The switch on the battery board which is just visible in the lower left corner let’s you select between using and charging the Li-Ion battery.

Which is good, given that Lithium batteries can be a bit, ehm, finecky to deal with…


Pololu 3π

In AVR on Nov 12, 2008 at 00:47

Pololu produces the robot, with two independently driven wheels plus ball caster, an ATmega 168 for smarts, and on-board power that allows it to autonomously move around. The 3pi comes pre-assembled, and is smaller and much more maneuverable than the Asuro kit I built recently.

There’s an impressive intro on the Pololu site:

The nice thing about the 3π is that it is fully Arduino-compatible and that it comes with two nice programs, for advanced line-following and maze searching, respectively.

So I set up a little track in a drawing program and printed it out, taping the 3 x 4 pages together to create a little track. Unfortunately, I couldn’t get 3π to successfully follow the line; perhaps the printed inkjet ink does not have sufficient contrast for its infrared eyes? The robot only barely follows the line, and goes off track into a spin all the time.

I will need to create a better track with black tape one day, as suggested on the Pololu site.

Still, this was very educational. I found out about proportional–integral–derivative (PID) controllers, and how they help create feedback-based control loops that push mechanical systems to their limits without overshoot or erratic behavior.

Update 2008-11-29 : indeed, with black masking tape 3π works just fine!

XBee shield

In AVR, Hardware on Nov 11, 2008 at 00:46

Here’s an Arduino shield for the XBee wireless 2.4 GHz module (v2, as kit from NKC Electronics):


I haven’t been able to find the hardware schematics or board layout, looks like it’s proprietary…

If you look closely, you’ll see that the board underneath it is a new Arduino Duemilanove, which auto-senses power between the plug and the USB port.


In AVR on Nov 9, 2008 at 00:45

The Wii Nunchuk controller is really just an I2C device, with a triple-axis accelerometer, an X-Y proportional joystick, and two push buttons. Breaking it out of its case allows us to connect it in ways it was never meant for:


It’s very easy to hook up to an Arduino and there’s a good example on the web to read out all the sensors. I’ve tweaked it a bit to use pins 8 and 9 as the I2C/TWI interface.

Connections above are as follows: red = +3.3..5V, white = ground, green = SDA, yellow = SCL.

Boarduino & RBBB

In AVR on Nov 7, 2008 at 00:44

The Boarduino is an Arduino clone intended for use on a breadboard (the picture below is from another project):


There’s a DC version with an FTDI connector for programming (shown above), as well as a USB version (which powers and programs the board). Since there is an ICSP header, I decided to leave out the IC socket from this kit.

The Real Bare Bones Board (RBBB) is an even lower-end version. It’s smaller than the Boarduino and omits the ICSP header:


Due to its low cost as a kit, this would be a great option for permanent embedded use.


In AVR on Nov 6, 2008 at 00:43

The AVR Butterfly is a cheap demo board for the ATmega169V with on board LCD, sensors / switches, and RS232 interface:


I added the RS232 and ICSP headers to be able to boot-load and re-program it, and successfully tried Forth on it.


In AVR on Nov 3, 2008 at 00:42

Asuro is a simple robot, which I ordered as a kit from Conrad. The mechanical construction is entirely based on an epoxy board which also holds the electrical circuit. The brains consist of a C-programmable ATmega8, the older 8 Kb version of the 168 chip used by Arduino’s.

Here’s the result of a few hours of tinkering:


Another cost saving feature is the IR-link, which can be used to re-flash the program. It does require line-of-sight to function, and has a limited range of 1 to 2 meters as far as I can tell:


The above image shows the RS232 serial board that came with the kit. I must have made a mistake while building it – because it didn’t work. Luckily, I had also ordered the ready-made USB version, which works fine.

The test program pre-loaded into the Asuro activates all elements (LEDs, front switches, motors) as a way to test proper operation of each of them. It was most useful to chase down and resolve a few small build problems. There are photo-sensors which can be mounted underneath for line-following, but I chose to add some connectors for a prototype board instead. The reasoning being that these sensors could always be added back via such a prototype board.

So, does it work? I can’t really tell.

I couldn’t find any ready-made programs to make it do anything robot-like such as driving around and dealing with obstacles, or light-seeking/-evading behavior. And it’s clear that any form of intelligent control will require some serious programming and testing. Besides, the motors were very noisy and coarsely controlled, so I doubt it really can do things with any level of grace…

But I had a good time building this thing, and learned quite a bit about what it takes to make a little autonomous robot.

Minty Boost

In Uncategorized on Nov 1, 2008 at 00:39

Intrigued by LadyAda’s description of the Minty Boost kit, I ordered and built one. It delivers a stable 5V supply from 2 AA batteries to a USB plug, so you can use it to charge/power USB devices.


Trivial to build and works as advertised.

Garage LED

In Uncategorized on Oct 31, 2008 at 00:37

Solder fumes, ahhh that brings back memories…

Today, I built a little ultrasonic sensor to help me park the car. Took the easy way out and just purchased a simple kit from Conrad:


Now, instead of driving the car up to the point where some cardboard boxes leaning against the wall move, and then backing up, I can drive until a red LED comes on, and then, ehm… back up ever so slightly until the LED goes off. Progress!

Well, at least it gets rid of the old cardboard junk I was using as “bumper”.


In AVR on Oct 25, 2008 at 00:32

Fascinating: the AVR “ATtiny” and “ATmega” chips from Atmel can be programmed in standard C and C++. The chips cost a few Euro each, the compiler is gcc, and there’s a ready-to-run package for Mac, Linux, and Windows. There’s even a low-cost standardized hardware platform, called Arduino. It’s all open source, software as well as hardware designs.

Here’s the Nano version (specs), with on-board USB, ready to be plugged into a breadboard:


Wow. Low-end computing sure has come a long way.