What is a remote accelerometer? It’s a tiny device that has a three axis accelerometer and transmit the acceleration values to a remote host. And what is it good for? There are various uses for it. One is you attach the sensor to someone and let him jump around. On your remote machine you can use the data to produce sound or modify music. Think of it as a simplified Wiimote.

Last year Jan of electronicperformers.org came to me with the idea to make the jumping of people on a trampoline audible. We thought about it and it seemed to be easy. I tinkered with some XBees and ADXL acceleration sensors. They worked quite ok, but we had some trouble with the transmission, which sometimes just stopped for a couple of seconds. Maybe some kind of resetting, I really don’t know. Here is a video of the installation.

After that I thought, nice, but can’t we get it smaller and cheaper? So I sat down and designed a tiny custom PCB.

Features

I had already two JeeNodes laying around. These boards are using a RFM12B transceiver board to communicate with each other. So I decided to use the RFM12B as XBee replacement. They are really cheap, around 3 to 4 Euros.
The device should be Arduino compatible. Mostly because of the ease of development and available libraries.

• ATmega328P, Arduino compatible microcontroller, running at 8 MHz
• ADXL335, 3 axis accelerometer, +/- 3g
• RFM12B radio transceiver, 868 MHz, range of up to 100 meters
• MCP1702 linear, low-drop voltage regulator for 3.3 V, 250 mA
• powered by a 3.7 V lipo cell, 100-300 mA
• 6 pin ISP header for programming the bootloader
• 6 pin serial header to attach an FTDI-cable
• voltage sensor to tell when the battery goes low

Assembly

This is my second try on SMD. Resistors and capacitors are sized 0805. The controller is TQFP and the ADXL335 is LFCSP. LFCSP has not even pins you can hand solder. A very tiny package. As I had no stencil to place the solder paste (because I still have no laser cutter) I had to place the paste by hand. Pressing hard on the syringe and trying to work precisely at the same time is not that easy. After placing a tiny bubble of paste on every pad and gently placing all components, I heated up my hot-air rework station. Soldering with the hot-air station was easy. Not all components are well aligned, maybe because I used not enough solder paste. Often mis-aligned parts slide into place as soon as the paste gets liquid.
Next were the headers, battery connector and the RFM12B module. These were soldered traditionally with an iron.

Here is a picture of the back with the RFM12B module. The red wire is the antenna.

Software

After having the thing assembled it’s time to test it out. First is to program the Arduino bootloader. For that you need an ISP programmer. I used the USBtinyISP from adafruit. Simply select the target (Arduino Pro Mini @ 8 MHz w/ ATmega328), programmer and the port in the Arduino IDE and select “burn bootloader”. Worked on the first try.
Next is a blink sketch to check if the serial connection and the LED works. It turns out that I used too little solder paste on the controller. After resoldering that pin the LED worked.
Next sketch was to check if the ADXL works correctly, which it did. All three axis seem to work great.
After that I had to get the transceiver working. I took the RFM12 lib from Jee Labs. You have to download the Ports lib as well to get it running. First I uploaded the RF12demo sketch, which allows to setup the RFM12 module and store the configuration in EEPROM. The module was recognized and configured with no problem at all.

Time to develop the actual firmware. Here is the sketch for the sensor.

// RF12B ADXL sensor
// config D i4 g212 @ 868 MHz

#include "Ports.h"
#include "RF12.h"

int xPin = 0;
int yPin = 1;
int zPin = 2;
int ledPin = 5;
byte buf[6];

void setup() {
  rf12_config();
  pinMode(ledPin, OUTPUT);
}

int x, y, z;
unsigned long time;
byte ledOn;

void loop() {
  rf12_recvDone();
  if (rf12_canSend()) {
    x = analogRead(xPin);
    y = analogRead(yPin);
    z = analogRead(zPin);
    buf[0] = x >> 8;
    buf[1] = x;
    buf[2] = y >> 8;
    buf[3] = y;
    buf[4] = z >> 8;
    buf[5] = z;
    rf12_sendStart(0, buf, 6);
  }
  if (time < millis()) {
    time = millis() + 200;
    if (ledOn) {
      digitalWrite(ledPin, HIGH);
    }
    else {
      digitalWrite(ledPin, LOW);
    }
    ledOn = !ledOn;
  }
}

It's really easy. You have to call the rfm12_recvDone() to make sure the driver is still working. You have to call it, even if you are not trying to receive anything. If rfm12_canSend() returns true, we can transmit our data. We read the 3 axis acceleration and pack it into a byte array. This byte array is then transmitted. No more, no less. No acknowledge, nothing.

The receiver part looks almost the same, it receives the data and prints it on the serial port. From here on, you can do almost anything: Processing, Pure Data, Python, what ever fits best. You only have to be able to read a serial port.

Demo

For the demo I used Processing to draw a graph of every acceleration value. The red one is a bit hard to see in the video. Then I used Python with pyglet to play short wave sounds.

Outlook

The picture above shows three generations of this device. On the left is the first implementation, using an XBee and an ADXL335, both on breakout boards, wired on a prototyping board. In the middle is the first custom PCB. As you can see, there are two air wires. That happens, when you get distracted while designing a PCB. On the right is the current version.

For the next design I would include an ON/OFF switch so you don't have to pull off the battery all the time. And maybe add a small tactile button to make more Wii-like projects possible.

Downloads and Links

• Eagle files and Arduino sketches, remote_accell.zip
• RFM12 lib at Jee Labs, great stuff!

If you’ve missed Marcus post, here is another on the same topic.

Nearly every other Thursday Marcus and I are hanging out together for having a beer and chatting about all things geek, especially electronics, CNC, 3D-printing, micrcontroller and Arduino. But there’s no limit, everyone interested in tinkering and making is welcome. It takes place at Saal II in Schanze. Try us, we’re kind

You can take a look at Marcus’ or mine twitterfeed to checkout when the next #palo_altona will be.

We already had guests sometimes but yesterday’s drinkup was great as we had two new guests. Feels as if there is something moving in Hamburg. Yeah!

Update 2010/02/16: Palo Altona is now scheduled biweekly. Every Thursday was a bit stressing for everybody.

It’s Advent season. And what do you do to let your geek shine? An LED Advent wreath of course.

The idea came to me after seeing Sprite’s minimalistic version of the Hackaday’s Flickering LED circuit. It’s a simple circuit that flickers LEDs and detects darkness. I thought that this could make a great little Advent wreath. My version should have 4 LEDs and should be support first, second, third and fourth Advent.

Parts and Schematic

The parts list is rather short:

• ATtiny13V, 8-bit microcontroller, 1k flash RAM, 64 bytes SRAM
• 4 * 3mm LEDs, yellow or orange, forward voltage ~ 2.0 V
• CR2032 coin cell, 3 V, 230 mAh
• Paperclip

There are no current limiting resistors in this circuit. Normally operating LEDs without them is not advisable because the LEDs will get damaged. But under certain conditions the resistors can be left out. For more on this topic, see Sprite’s computation or mine here.

How does it work

The nice thing about this circuit is, that it needs no special components to detect darkness. It uses an LED for that. An LED is also a photodiode that can detect light of the same wavelength it emits. See here for more details. Sprite used an available ADC of the ATtiny13 instead of the “Reverse Bias” method.

Software

The software is heavily based on Sprite’s version. Things I’ve changed:

• Added support for four LEDs.
• Removed calibration, replaced with hard wired values.
• Added a bit sampling to the light measurements, because the values were a bit erratic.
• Added a mode for first, second, third and fourth Advent, stored in EEPROM. Gets incremented at every reset.
• Modified the watchdog code a bit to keep it generating interrupts instead of resets.

After power up, the watchdog gets enabled to generate an interrupt every two seconds. Then the current mode (0-3) is read from EEPROM, incremented and stored back. Then the endless loop is entered, where random values are used to flicker the LEDs. The ISR checks the ambient lighting and if it is higher than a certain level, sets a sleep flag. This flag is monitored in the main loop. If set it sends the controller in to power down mode to save battery power. The next interrupt will wake up the main loop.

Assembly

This circuit is soldered in “free form”, so no PCBs. It takes some time to get it done but it’s worth it.
All cathodes of the LEDs are connected to form the ring. The anodes are bent inwards to be soldered to pin 2, 3, 6 and 7 of the ATtiny13. A short piece of wire is connected to the common cathode and soldered to the GND pin.

The microcontroller lies “dead bug” style on the coin cell. The GND pin is bent to the top, now connecting to GND of the battery. The VCC pin is bent to the bottom and soldered to the coin cell holder. The coin cell holder works as a clip, pressing the microcontroller onto the cell.

Some random notes:

• Be patient.
• Use as less solder as possible.
• Don’t heat the pins of the controller for too long.
• Be gentle while bending the controller pins. They come off easily. I added a tiny bit of solder.
• BE patient

The Result

If you make one, please let me know. Send me a picture or post it on the tinkerlog flickr pool.

Happy third Advent …

Downloads and Links

• Source advent.zip
• Minimalistic flickering LEDs at Spritesmods
• Flickering LED circuit at Hackaday
• LED Menorah, also free form at Evil Mad Science

A couple of weeks ago Jan came to me and asked me if I could build a special kind of twitter wall. At our company CoreMedia we do an Open Space every 3 months or so. This time we had a Hacking Day as well, so we needed something special. After throwing some ideas around, we came up with a twitter client that should print out tweets with an electric typewriter. A short google showed, that that has been done already (of course!). See it at oomlout.

But that couldn’t stop us. Jan scanned ebay for a nice electric typewriter and found a Commodore SQ 1000. It was in really good condition, probably rarely used. It worked as advertised.

Take it apart

First step is to take it apart. That reveals a small PCB and the connections of the keyboard. Later I realized that I hadn’t to open up the keyboard itself, because there is nothing of interest in there. It is a simple keyboard matrix.

The big chip on the right is a SEC microcontroller. The smaller chips should be there for driving the barrel etc. but I haven’t investigated that. The green foil in the middle is the connection to the keyboard. Actually there are two connections, each with 8 lines, one for the rows, one for the columns to form a matrix.

I decided, that the easiest way to simulate key presses was by shorting the switch of the desired key. I soldered two 8 line cables to the solder joints on the bottom side of the PCB. Actually there were 12 lines on one of the connectors, but 4 of these lines are used to drive LEDs for caps lock and power.

How does it work

Putting everything back in to place I tried to understand, how the keyboard matrix works. Very helpful was this tutorial, that connects a keypad to an AVR.

All 16 lines are directly connected to the controller, no external pull-up or pull-down resistors. As already said, the 16 lines are arranged to form a 8 by 8 matrix, giving 64 possible key codes. 8 lines are supplying 5V (called out) and the other 8 lines are low (called in). The controller then cycles through all out lines, pulling it down, one at a time. Then it checks if one of the in lines is pulled to low to identify the pressed key.
To simulate the key press I have to wait for low on a specific out line and then pull one of the in lines low. I used my oscilloscope to see what’s really going on. It turns out that the controller scans for key strokes with 87 Hz. Every line is low for about 150 us. I used the Arduino to record the sequence and calculate how wide the low phase is. When I would find a low on line 1 of the out line, I could use it as trigger and compute when the other lines would be pulled down. That way I would only use a single wire (and Arduino input) to detect the out line.
To set a specific in line to low I am using a 74HC595, a shift register with tristate output. The tristate is nice, because if it is disabled, the keyboard is fully functional as if the Arduino is not connected at all.

Here is everything connected on a breadboard. On the left is a standard Arduino with an Ethernet Shield.

On the right is the shift register. In the middle is a pull up resistor connected to line 1 of the out lines. That is used to be able to “see”, when the line goes down.

Reading twitter

The software part to connect to twitter is straight forward. I used the twitter search API to pull tweets that contained the word #cos09, which was the hashtag used at the CoreMedia Open Space. The query is executed every 60 seconds and the query string looks like this:

http://search.twitter.com/search.json?q=cos09&since_id=0

Parsing the json formatted response is a bit ugly, mostly because memory is very limited on the ATmega168. After fetching and parsing a complete response, the max_id is stored and used for the next query. That way only new tweets are printed.

Demo

So far everything worked well, except the hash sign (#), the @ and … umlauts (*sigh*). The hash sign is not available because it only accessible by pressing the code key simultaneously, which is not possible with the current setup. The @ is not available at all, I simulate it by the sequence O-backspace-a. Umlauts are missing because … I’m lazy.

Final twitter wall setup

This is the setup as twitter wall. On the right is a video camera, recording incoming tweets and displaying them via a projector on the wall. The notebook is only bridging WiFi to Ethernet.

After all, the retro twitter wall was fairly successful. People stood around with a smile, tweeting with their iPhone, waiting for an intense “rattatatat rattatat …”.

Here is another action shot, taken by Jörn.

Links and Downloads

• Source: twypper.zip
• Twitter Monitoring Typewriter at oomlout
• Connecting a keypad to an AVR
• Keyboard Matrix Help

Niklas did an amazing job, letting fireflies play some tunes. It’s almost as if they are alive.

Niklas, I owe you a beer (or Club-Mate or whatever), should we ever met. You made my day!

For my latest projects I used a lot of single cell lipo batteries. They are really nice. High power density, low self-discharge, no memory effect and they can deliver quite an amount of current.
But lipo battery handling is a bit more complicated as with other rechargeable batteries. You have to take care of under voltage and over charging as that may destroy the battery.

I used the Sparkfun LiPoly charger, based on MAX1555, for some time and it works really well. The only thing I missed was a way to control the current. After some research I decided to try another chip, the Microchip MCP73833.

Features of the MCP73833

Copied from the specs:

• High accuracy preset output voltage regulation
• Regulated output voltage options
• User-programmable charge current up to 1A
• Two open-drain Status outputs
• Preconditioning and end-of-charge ratio options
• Under-voltage lockout
• Power Good output

What I like is the ability to adjust the charging current and the status outputs, which should get really useful if integrated into a greater application.

The schematic

The schematic is mostly a copy of the reference design. It has three LEDs, one for power good, one for charging and one for charging complete. All pins of the chip itself are also available on two header rows. The idea was to enable easy integration on a breadboard. Actually I misplaced the rows, so they don’t fit (#fail).

The resistor R4 is used to control the charge current. I used a socket for that, so I am able to adapt the current for different batteries. The 10k resistor results in a charge current of 100 mA.

The result

All components were 0805 SMD parts, despite the MCP73833, which is 10-MSOP. This was my first attempt to do something useful with SMD. I used my brand new hot air reflow station, which turns out to work as expected. Only I had to be very precise at dosing the solder paste. Applying too much had to be removed with solder wick later on.

Issues

The next version should include a jack for a wall adapter. The two header pins are not really useful to connect to a power supply. And of course the two rows of header pins should be aligned correctly to fit on a breadboard.

As a sidenote: as you see, the board has a mini-USB connector to be able to connect the charger to a notebook.
I stronly recommend to use some kind of USB hub to test any newly build USB hardware.
I didn’t. And now I have a burned first prototype of my charger and only one USB port left on my MacBook. Although the OS warned me with “something is sucking too much, port gets shut down”, it wasn’t fast enough. So, you have been warned.

Links

• Microchip MCP73833

Again a Braitenberg vehicle. This one is even smaller, than the previous one and comes on a custom PCB. It weighs 17 gramms, is driven by two pager motors, powered by a small lipo cell and controlled by an 8-pin ATtiny25V.

Schematic and parts

This tiny robot has a very low component count. At least for a robot, based on a microcontroller. That has, of course, some implications. It can handle only two sensors and the motors run only in one direction. A full H-bridge for both motors would need 8 transistors and more lines to control it.

So I decided to just use a single transistor to drive the motor. That means it can only run forward. Not a big deal for a Braitenberg vehicle.

Here is the parts list. Most parts are very common.

• ATtiny25V, 2 kB flash RAM, ATTINY25V-10PU-ND
• MPC1700 3.3 voltage regulator, MCP1700-3302E/TO-ND
• 2 * light dependent resistors (LDR)
• 2 * 10 kOhm resistor
• 2 * 470 Ohm resistor
• 2 * 2n3904 transistor
• 2 * 1n4148 diode
• 100n capacitor
• 100u capacitor
• Lithium-polymer battery, 3.7 V, 100mAh, HobbyCity
• 2 * fuse holder
• 2 * pager motor
• heat shrink tubes
• rubber tube
• custom PCB
• 6-pin ISP header

A bit tricky was to find the right rubber tube to build the wheels. I found these, which are normally used to connect tiny motors to a model stern tube. Because the inner diameter is a bit to wide, I used short pieces of cable isolation as an adaptor.

If you have pager motors with an attached weight on their shaft, you may want to take a look at the RobotRoom for instruction on how to get rid of the weights. I had no locking pliers, maybe that’s the reason why I ruined at least three motors. Mostly by twisting the shaft while trying to pull off the weight.

Software and programming

The software is straigt forward. Reading two inputs, the light sensors, and driving two ouput lines accordingly with a PWM signal.

But it turns out, that the software needs a lot of adjustments. First you have to figure out in what range the light sensors report values. Next, check at what PWM level the robot starts to move. Maybe even adjust the directional stability.

Programming the robot in circuit via the 6-pin ISP header didn’t work out in the first place. The programmer was not able to set the lines to high that were driving the transistors. So I soldered a socket in place and can now pull off the two 470 Ohm resistors. After programming I can re-insert the resistors. Can be seen on the left critter on the picture above. A bit awkward, but it works.

Demo

You should have a very clean surface for them to run on. If you put them on a table, as I did, be sure to have very good reflexes or put a kind of fence around them. Mine dropped off the table a couple of times. Mostly no dramatic damage, but the sensors got twistet and the motors sprung out of their holders.

Depending on the ambient light, the light source itself and the nature of the surface you may have to adjust the light sensors. As an example, if the surface is white and diffuses the light, then you would have to bend the sensors away from the surface, because the surface looks bright, even if the robot turns away from the light source.

Issues and conclusion

There are still a couple of issues to resolve.

• Software improvements, use ADC in free running mode and use hardware PWM to drive the motors
• Place the skid in the middle of the PCB.
• There is no protection of deep discharging the battery, no idea how to solve this.
• Add a small power switch.

Someone wanting to volunteer for some private beta testing and helping with improvements?

Besides these issues, these two critters are fun. There was a lot of testing, reprogramming and re-adjustment needed, to get them doing, what I thought they should do. But hey, that’s the way to learn something.

Links and downloads

• Braitenberg vehicle with Arduino mini
• Arduino powered Braitenberg vehicle
• Formica, swarm bots
• Source code and Eagle CAD files, really BETA, tiny_braitenberg.zip

Here is my very first article. It is published in c’t, one of the best known computer magazines in Germany. wOOt!

It shows some basic Arduino examples and how to build a Wiimote-like controller. The controller consists of an 3-axis accelerometer, a push button and an Arduino nano on a breadboard. This combination is used to control a Lunar Lander type of game, programmed in Processing.

• c’t article Shake, rattle ‘n’ roll, as full text
• wiki with more images, links and downloads

While we were at cheating, here is a new sticker for your notebook. It helps you to read and learn resistor values.

The first 10 direct messages to me will get one for free. And of course every next order at the Tinker Store will include one of these.

Last week I invested some time to solder 64 Firefly boards. Only 2.432 solder joints later I was ready for some videos.

Every firefly acts completely autonomously, it has its own tiny controller, eye and luminary. They are all connected for power supply only.

Here are some different configurations.

Links

• See how it’s done in the Synchronizing Firefly Howto
• Grab a Firefly kit at the Tinker Store