ArduinoISP – Completed!

In my last post on the topic, I assembled the majority of the ArduinoISP shield I’d prototyped.  Last night, I finished assembly, and attached an ICSP header to it for performing the last step.

ArduinoISP Shield – Top View

Adding the ICSP header wasn’t too hard – in the above photo it’s at the bottom left.  Pin 1 is the bottom left-most pin, and pin 1 on the FTDI cable (the ground pin) is on the left as well.  The miniature black reset button on the right causes the underlying Arduino to reset.  The big red reset button at the top resets the microcontroller in the ZIF socket.

I made a minor boo-boo.  I should have put the ICSP header one row up from the bottom of the board.  As it is, pins 1 & 4 are very close to interfering with the top of the USB plug on the Arduino, which is rather bad.  I’ll take care of that with a spot of hot glue as insulation tonight.  Might also take the opportunity with the hot glue gun to glue down some of the wires on the underside to ensure they don’t come to grief.

ArduinoISP Shield – Underside

Anyway, testing was all successful first go.  Onboard/offboard ISP, FTDI programming, and blink test all work fine, as well as both reset buttons.  Success!

One comment though – wire wrap wire for doing this kind of wiring is very, very, very fiddly.  But it works reasonably well.

AeroQuad Shield – Assembly

This post has been delayed for a few days because I was awaiting my replacement BMA180 Accelerometer breakout board.  I had soldered in the gyo and other components, but held off on this final post until I’d got it all finalized.  The short story?  It works!  Read on for a couple of pics and comments.

AeroQuad v1.9 Shield Package

AeroQuad v1.9 Shield Package

The shield arrived in a well-packed box from the AeroQuad store, along with a sticker.  The contents of the shield package include everything required to assemble the shield, and also include a fair few spare pin headers.  The board is good quality – nice and thick, with a well-made solder mask, every thru-hole is plated and tinned.  The silkscreening is a little blurred, but it’s good enough for assembly.  The stackable header kit (bought seperately) has good-quality headers, with fairly thick pins, also tinned.

The logic level converter breakout is at the top left.  I didn’t actually use that board, since I already had one soldered up, so I used that.  This means I’ve now got a spare I need to solder at a later stage, but that can wait until I need an LLC for something.

Shield Assembly

Assembly is very straightforward.  I messed up one of the pin headers a small amount, it’s lifted about 1mm off the board.  It doesn’t really matter, it’s not enough to be noticeable, and I’d rather not try and fix it and wreck the board or something, so I just left it alone.  The offsetting on some of the pins means that the headers go in fairly tight, and the pre-tinning means they’re very easy to solder.  Assembly went off without a hitch, and everything just fitted.

Shield with all non-breakouts attached

I attached a few connectors that are not strictly required, so I have some flexibility – namely the spare I2C lines and the extra digital and analog breakouts.  The empty 6×1 pin header just below the receiver input grid is for a barometer, which can’t currently be used with the Uno, so I’ve left that blank.  The prototyping area at the bottom left of the board has also been left empty.  Pay particular attention to the receiver grid when soldering it – do them one at a time.  I didn’t, so I had to spend 15 minutes melting the solder and pushing the pins around with a pair of pliers to get them straight…

As for the breakout boards, the pins stick out the bottom quite a long way, and may possibly intercept the Atmega328p under it.  This would be very bad.  My solution there was to push the breakout board into a piece of stripboard I had (which was the same thickness as the Shield), and then cut the pins off sticking out about 1mm from the stripboard.  From there, I could then solder the breakout to the Shield without having the pins sticking out.

Completed Shield

Completed Shield with receiver cables attached

The process took me a few hours, on account of how I spend a lot of time checking my joints with a magnifying glass, testing everything again and again with a multimeter and such.

After soldering on each pin header and breakout board, I ran over it with the continuity tester checking for shorts between pins, and making sure the pins had continuity with every point on the board they connect to (as per the schematic).  That way I could be sure that if I had a problem it must be with the piece of work I just did and not with some other piece of work I did a while ago.

After soldering on the gyroscope, I did the same continuity tests, but then (after making sure that +5V and GND wasn’t shorted or something horrible like that) connected up the shield to the Arduino and ran tests on the gyro itself (ie, run the i2c scanner and AeroQuad configurator).  That way I could prove that the gyro worked on the i2c line.  The same was done after adding the accelerometer.

As a last step, I hooked up the receiver to the channels according to the documentation and fired it up.  I noticed inconsistent behaviour, and realized this was caused by the power drain of the whole kit exceeding the 100mA allowed by USB.  Plugging in an external power supply stopped that issue immediately.

100mA?  Whoops…

Running everything through the configurator from there was easy.  Everything worked, although I needed to reverse a couple of the channels on my transmitter to have the movement direction match up correctly.

Next steps are to wait for the rest of the hardware to arrive and build a frame.  I’ll be hunting for a suitable carrier for the electronics tomorrow.

Parts Arrival!

Just received a set of packages for most of the remaining parts for what I’ve ordered!  Busy night coming up tonight in that case 🙂

I’ve got the ITG-3200 gyro at home, but I’m still waiting on the replacement BMA180, so I’m not quite done yet.  I’ve also just received confirmation that my shipment of a lot of jumper cable hardware (of various sizes to make receiver and ESC cables) is on its way by express post, so I should have that in the next day or two.  I’ll start on assembling the shield tonight.

It’s now time for me to start looking at a frame & ordering motors/esc’s/propellors.  I’ve decided to get a whole bunch of spare props and a few spares motors just to ensure I’m covered for…  collisions.

ArduinoISP – Construction

Edit:  Looks like my post order got a bit scrambled from me trying to edit the tags…  Doh.  So I’m reposting this to get it at the top and restore a bit of timeline continuity.  Sorry…

From my last post, I breadboarded a design for an Arduino shield which turns it into an ISP and a few other functions.  This post will detail how I went about constructing the final shield onto a Freetronics prototype shield.

The shield can be constructed in a number of phases, which simplifies testing since you can test functionality at the end of each stage to make sure your core assembly is working as expected.  I’d strongly recommend also testing each wire link you make with a continuity tester to make sure that they’re actually connected right and that there aren’t any shorts.

Phase 1 – Atmega328p Support Parts

The first phase is getting enough parts onto the shield in order to be able to fire up the Atmega328p and get the Blink sketch working.  From the breadboard assembly I did earlier, the Atmega328p was already programmed with the sketch.

Step 1 – Basic setup (top view)

Step 1 – Basic setup (underside)

The extra parts are a 3mm LED and a 330r carbon film resistor, for showing power status.  This is built onto the shield, and appears on the bottom right of the top view.  I only soldered the pins on the ZIF that I wasn’t going to be using in the whole assembly, leaving the others unsoldered (for now).

The big bit of wire on the top of the underside view is the resistor leg of the 10k reset pullup resistor.  That gives me a bus that I can use to hook up other things to the reset line (of which there’s a lot).  The blue wires are 30AWG wire wrap wire.  Wire wrap wire is very thin, and the insulation is made from a flourocarbon that burns away quite readily under a soldering iron.  It’s very fiddly to work with though, but it does the job.  It’s thin enough that it can fit into the same hole as another component to make a joint when you solder it.

Finishing up the job, I carefully checked to make sure there were no shorts (including checking continuity from +5v to ground).  Note that when you check +5V to GND, don’t be worried if the continuity testers gives a brief buzz, that’s just the 100nF noise suppression capacitors charging up.

Phase 2 – ArduinoISP Interface

The next phase is to connect up all the components required for the ArduinoISP to burn bootloaders into the ZIF socket.  This doesn’t include the outbound ICSP header or the FTDI plug.  Results are below;

Step 2 – ArduinoISP Interfacing (top)

Step 2 – ArduinoISP Interfacing (underside)

More of the same, really.  The only real deviation from design is that the 330R resistors in series with the LEDs are actually on the positive side of the LED, and are 470R’s.  Doesn’t make much difference, if any.

Again, after assembly test for shorts, and make sure every connection goes where you expect.  Check against the device, not the solder joint, since the joint may have flux on it, and the dry joint may be inside the joint too.  So you want to check the pin (for example) that goes to the Arduino, and the matching ZIF socket hole on the top.

Results were good!  It works first time.  Next up is to attach the FTDI interface plug so that sketches can be uploaded.

Phase 3 – FTDI Socket

Following the pinout for the Arduino Pro Mini, attaching an FTDI interface isn’t hard.  There’s enough room on the bottom of the board for it to fit, so I attached a 6-pin male header there.  Wires were routed along the top of the board for this into their respective locations, with ample use of solder bridges between pads where required.

Phase 3 – Testing the FTDI interface

I had a few issues with my home-made FTDI cable.  I thought I got one of the connectors around the wrong way and pulled it apart, but then it turned out I’d made it correctly after all..  D’oh.  Since I haven’t made my FTDI adapter yet, the other end of the cable in the photo has a bunch of M-M breadboard jumper leads stuck in the end of the cable.

I won’t be attaching the ICSP_OUT header yet, since I don’t have a proper ICSP cable.  Once I’ve got one, I’ll attach the header and test it.  At any rate, it’s been pretty successful so far, no major slipups and everything’s worked pretty well first go.

The programmer board should prove quite handy in the future, I think.

AeroQuad – Sensors (Part 1)

As discussed in my last post about the AeroQuad, I wasn’t having much luck with the Wii sensors and wound out getting a BMA180 accelerometer and ITG3200 gyroscope ordered in.  Short results:  Gyroscope’s fine, accelerometer’s not.  But it’s being replaced by the supplier, so all’s good.

The BMA180 Breakout Board

The BMA180 board was fitted up to a breadboard using the following schematic (courtesy Sparkfun Forums);

BMA180 Wiring Schematic

After wiring, I went and set up an I2C Scanner sketch which I found at  The idea here was to just see the BMA180 respond on the I2C bus.  However, it didn’t work.  After a lot of stuffing around, checking wiring, and reading the Sparkfun schematic and the Bosch datasheet, I did a brief experiment.

The BMA180 was locking up the I2C bus whenever it was connected, which made me think that SDO (which was tied to ground) may have been dragging SDI to ground also.  SDO is used in I2C mode as the address select switch – tie it to ground to select I2C address 0x40, tie it to Vccio to select I2C address 0x41.  So I decided to leave SDO floating instead of tying it to ground.

The BMA180 then worked fine!  Cracking out the multimeter after a lot more reading, I checked pins 6 and 7 on the breakout board for a short, and sure enough they’re shorted.  So I then very carefully went over my soldering job with a big magnifying glass to make sure there’s no bridges, and everything looks fine on my side;

BMA180 Breakout Board

Pins 6 and 7 are on the right on that picture.  Significant gap between the two.  Then I came across threads on forums with other people who have had similar problems, and looking at the BMA180 chip itself, I notice that the soldering looks a bit heavy (pretty big blobs of solder under the chip).  Therefore it’s pretty likely that the chip is shorted under the board.  Unfortunate, but the manufacturer is replacing it for me.

The ITG3200 Breakout Board

The ITG3200 is a much happier tale.  Note that both the BMA180 and the ITG3200 are 3.3v devices, so you need to push their signals through a logic level converter to get them to the 5v required by the Arduino.  You should use the Tx0 and Tx1 lines, since they are bidirectional.

Wiring was very straightforward, I just followed the AeroQuad v1.7 wiring schematic and linked up the gyroscope as appropriate.  The SCL (I2C clock) is the yellow line and should go to Analog Pin 5 on the Arduino.  SDA (I2C data) is the green wire and should go to Analog Pin 4.

ITG3200 Test Overview
ITG3200 Closeup

LLC Closeup

I2C Wiring to Arduino

Pay special attention to the breadboard.  The left side of the breadboard is the “high voltage” side, where the +5V from the Arduino goes onto the power rails, and the right side is the “low voltage” side, where the +3.3V from the Arduino goes in.  Note that the logic level converter bridges the “middle”, with the HV side on the left, and the LV side on the right.  It’s very important you don’t mix them up, since if you do you’ll blow up your gyro.

Anyway, after wiring, I used the I2CScanner sketch I found.  I had to modify it slightly to scan above 100, since the I2C address for the ITG3200 is 0x69, which is 105 in decimal.  No matter, I just set up the scanner to scan up to 127.  Found it first go.

Then, I uploaded and ran this itg3200_test.pde sketch (on my GoogleCode repository).  Sketch runs, and shows valid data coming from the gyro – I pitch, yaw, and roll it and the X,Y,Z figures change.  All’s good!

Next Steps

I’ve verified the gyro works fine, so that’s going back in the ESD bag and into my breakout box.  Now I need to wait for a replacement BMA180 and test that.  I’m also still waiting for my receiver and AeroQuad shield.

ArduinoISP-Shield – Prototyping

As discussed in my last post, I intended to make up a prototype shield in order to supply three main functions – ICSP programmer, breakout to allow ICSP programming off-board, and FTDI serial input to allow comms with the inserted Atmel chip.  This post will discuss how I went with the schematics and breadboarding of the planned device.

The Schematic

ArduinoISP-Shield Schematic

You can get the Eagle schematic and PDF at my GoogleCode Repository here.  In essence, this shield is intended to function in a couple of modes;

  • Onboard ICSP Programming – In order to do this, plug the shield into an Arduino, then put an Atmel chip into the ZIF socket, and run ArduinoISP as you usually would.  FTDI and the ICSP outbound header should be disconnected. The LEDs will indicate programming status.
  • Offboard ICSP Programming – Plug the shield into an Arduino, then hook up an ICSP programming cable to the ICSP outbound header.  Run ArduinoISP as you usually would, and the LEDs will indicate programming status.  FTDI should be disconnected and the ZIF socket should be empty.  Note, this mode is for outbound ICSP (ie, the shield is burning a bootloader on something else), and you shouldn’t have a chip in the ZIF socket.
  • FTDI Link to ZIF Socket – Plug an FTDI cable into the FTDI header, and make sure an Atmel chip is in the ZIF socket.  Make sure that the shield is not plugged into an Arduino.  You can connect an external ICSP programmer if you want.  You can now use the FTDI cable to communicate to the Atmel on the shield and upload sketches to it.

I’m not entirely sure what would happen if you plug in the FTDI link and the Arduino at the same time, since the VCC lines are tied together.  It might be bad, so don’t do it.  If you are gonig to, then the power sources must come from the same place so they’re at the same potential.  At any rate, there are a number of LED’s and items on the shield, namely;

  • Pin13 – Connected to Digital Pin 13 on the ZIF socket.  This is so if you upload the Blink sketch, you can see the Atmel blink the LED if the programming worked.
  • Prog – Lights up when the underlying ArduinoISP is burning a bootloader.
  • Error – Lights up and stays on when the underlying ArduinoISP had some kind of problem burning the bootloader.  This may blink when you first start a burn.
  • HBeat – Heartbeat.  When the ArduinoISP programmer is running, this light will fade on and off.
  • RESET – Reset for the ZIF socket.  Pressing this will reboot the Atmel in the ZIF socket.

Right, now the schematic’s done, time to assemble the prototype!

The Prototype

I’ve greatly shortened the development cycle here, but essentially what I did was assemble the prototype in three parts – first assemble the Atmel onto a breadboard with the connecting components (capacitors, reset switch, LED, resonator).  Once that was verified to work, I then assembled the FTDI cable parts onto the board using the FTDI Adapter I wrote about earlier;

Arduino Breadboard & FTDI Adapter

The Arduino-on-a-breadboard is at the top and the FTDI adapter is on the bottom breadboard.  Note that the upper breadboard is missing the reset switch – I wired that up later.  To start with I only had the 10k pullup and the 0.1uF capacitor on the reset line.  Running that, I verified that I could upload a sketch and have it work – for starters I used the Blink sketch.  All worked.  Great.

Next up is to disconnect the FTDI cable and set up the ArduinoISP to be able to burn the bootloader.  For this, I cheated a little.  Because it’s on a breadboard, I just hooked up the Arduino direct to the ZIF socket as the schematic shows and ran it;

Arduino Breadboard & ArduinoISP

Notice the three LEDs on the breadboard on the left – that’s the ISP status LEDs.  You’ll also notice that the reset switch is in place on the right breadboard.  Anyway, running that showed it all worked.  I was able to burn the bootloader through the Arduino GUI, and also by running AVRDUDE by hand like this;

C:\arduino\hardware\tools\avr\bin>avrdude -pm328p -cstk500v1 -b19200 -PCOM3 -v -C ..\etc\avrdude.conf

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean,

         System wide configuration file is “..\etc\avrdude.conf”

         Using Port            : COM3
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
         AVR Part              : ATMEGA328P
         Chip Erase delay      : 9000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ———– —- —– —– —- —— —— —- —— —– —
— ———
           eeprom        65     5     4    0 no       1024    4      0  3600  36
00 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  45
00 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0
 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0
 0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as 5

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Note that when using the Arduino IDE version of AVRDUDE, you need to point it at the config file, hence the command line above.  Anyway, that all worked.  I wanted to run AVRDUDE by hand because the Arduino IDE gives you no feedback besides “Yay, it worked!”, which doesn’t tell me quite enough.  I wanted to be really sure it actually worked.

Next Steps

Well, the prototype on breadboard works.  The next thing to do is to arrange all the parts onto a prototype shield to make sure it’ll all fit, and then start assembly.

Photos and blog post when it’s done.

FT232R to FTDI-cable Adapter

I got myself one of Sparkfun’s FT232R Breakout Boards, but I didn’t get the basic version (whoops).  Now, the advanced version breaks out every pin of the FT232R, but it doesn’t have a direct pinout to an FTDI cable such as what the FT232R Basic supplies.  Oh, and it’s set by default to 3.3v, but that’s adjustable through a solder jumper.

I needed an FTDI adapter and a way to switch it between 5v and 3.3v sensibly.  No problem, as it turned out.

The very first thing to do is to desolder the solder jumper on the top of the board.  That jumper fixes the VccIO line to 3.3v, which is not what we want.  We want it to be 5v in this case.

Second thing is to come up with a mapping of pins on the FT232R to pins on a normal FTDI cable.  Consulting the schematic for the basic version makes this pretty simple.  Then we simply map that back to what we have on the breakout board, add in a line to link up VccIO to 5v, and we’re sorted;

FTDI Adapter – 5 volt version

You can find the PDF and Eagle schematic files on my repository at this link.  Take careful note, the FTDI connector on that view is from the top, whereas the view of the breakout board is from the bottom.  Be careful not to wind up with one of the connectors upside down.  I’ve labelled every pin to reduce confusion in that regard.

Making a 3.3v version of this should be trivial, simply change the link from VccIO to 5v by moving it to 3.3v.  You could even do it with a switch, but I wouldn’t advise that because fumble fingering it runs the risk of blowing up whatever you plug it into.  Just make two boards, and clearly label them.

Right now, I’ve only got it on a breadboard, but once my female pin headers come in, I’ll build it onto a piece of stripboard to make a permanent adapter.

Arduino Uno as ISP

So, I’m planning on building up an Arduino-compatible breadboard in order to prototype my MCE Remote IR Blaster. In order to do this, I decided I needed a few extra components so I can program the ATmega328p microcontroller without needing to go and pull chips out of sockets on my current Uno boards;

  • An AVR ISP device of some type (used to program the bootloader)
  • An FTDI-to-serial adapter and cables to connect a (relatively) bare ATmega328p to a PC for programming
  • A board to connect up an ATmega328p through a ZIF (zero insertion force) socket

The ISP (In-System Programmer)

When you upload a program to an Arduino, what actually happens is the microcontroller is reset, and then during the first few seconds of boot, a piece of code (the bootloader) runs. The bootloader listens on the serial port for an incoming sketch and commits it to flash if it receives one. If it doesn’t, it just marches along and runs whatever sketch is already in flash.

This means that if your microcontroller has either no bootloader (ie, bought without one) or if something bad happened to its bootloader, it’s basically bricked unless you can reprogram the bootloader. That’s where the ISP steps in. The ISP allows you to program the microcontroller from scratch.

There’s a couple of different ways to get an ISP. You can make a parallel port version, you can buy several different types of AVR ISP, or you can do what I did, and press-gang an existing Arduino Uno into becoming an ISP for you.

Turning the Arduino Uno into an ISP

Simply follow the instructions at – they work just fine. Note that the instructions say that the code won’t work with the Uno, but this doesn’t appear to be the case. I ran it just fine with an original Arduino Uno, running v0022 of the IDE. Note that my Uno is not the SMD version, I don’t know if this will make any difference.

What Next?

Well. Now that I’ve discovered it appears I really can use an existing Arduino Uno as an ISP, that opens up a world of possibilities. Namely, I can make up a prototype shield to go onto a Uno which has a ZIF socket installed onto it, and does all the connections required to turn it into an ISP straight up.

So the plan is to fit up the prototype shield with the ZIF socket, some status LEDs, and also put in a breakout for a 2×3 ICSP pin header to program stuff external to the shield. Then I can also put in the appropriate 6-pin FTDI interface so the chip in the socket can be programmed.

Schematics and such will be coming as I make them. Phew, I’m getting a lot of projects on the go…

MCE Remote – IR Blaster Prototyping

I’m currently forced to use three remote controls, and I don’t particularly want to shell out for a Logitech Harmony universal remote. So, I got the idea to construct an IR relay myself, which would pick up signals from the Media Center Remote (the one that I use all the buttons for), and then be able to replicate the functionality of the two remotes that I only use power bottons on.

Why not just buy the universal?  This is for a couple of reasons;

  • I’d have to instruct my wife on how to use the thing, and she’s only just gotten used to using the Hauppauge Media Center Remote I currently have.
  • The Hauppauge remote has an IR blaster built in, but I (probably) can’t use it for this kind of purpose.
  • It’s a good learning opportunity.
  • It will cost under $20 in parts, whereas a Logitech Harmony is pretty expensive.
  • I don’t want an expensive remote mauled by the baby.
  • And likewise, I don’t want an expensive remote eaten by my dog.  Seriously.  This dog chewed a palm tree off at ground level.  An expensive remote control would be a tasty snack.

So, doing a bit of digging around, I came across Ken Shirriff’s blog and the IRremote library he wrote.  Exactly what I need!

So, consulting his demo programs, I assembled some hardware as follows;

  • An IR Receiver.  I got a ZD1952 IR Receiver from Jaycar, since it’s multi-frequency and outputs TTL.  Connecting the pins up as per the datasheet to +5V and GND, the signal pin goes to Digital Pin 5 (for my program, it’s 11 for Ken’s demos).
  • An IR LED.  I used a ZD1945 5mm IR LED from Jaycar.  Initially I used a 100 ohm resistor in series to ground from the LED, and connected the LED to Digital Pin 3 on the Arduino.  Later I made a driving circuit with a transistor for the LED.  For testing, I replaced the IR LED with a normal 5mm LED so I could see if anything happened.
  • An RGB LED.  I used the RGB LED that came with the Sparkfun kit, but something like this ZD0012 RGB LED should be suitable.  Remember to use something like a 330 ohm series resistor with it to avoid blowing anything up.  The red pin attaches to digital pin 9, the green to digital pin 10, and the blue to digital pin 11.

Assembling the hardware together and using Ken’s demo programs, the first step required is to discover what is emitted by my current remotes when their buttons are pressed.

The Finished Breadboard

TV & Amp Remotes

Anyway, it turns out that the amp was easy.  Its power button uses the NEC protocol, command code is 0x10ef08f7.  Very simple to send that out again through the IR LED.

A great trick that can be done with any digital camera.  Point an infrared remote at it and hit the button.  Digital cameras can see infrared, so this is a good way to see if your transmitter is actually working.  Of course, you can’t see the signal pulses, but you can see the IR LED light up.

The TV on the other hand was not as easy.  It’s a Panasonic, and IRremote doesn’t understand the protocol.  Fortunately, we can fall back to raw mode.  Grabbing the raw output from IRdemo, in order to massage the figures into something that’s appropriate to send back out again, you need to chop the first entry off (which is just a gap), and then remove all the signs from all the entries (negative is a space).  That gives me this;

// Sends a power-on signal to the Panasonic TV
void powerTV()
     // Panasonic TV, output is raw (unfortunately)
     // Much of this is probably repeated, but so what.
     const unsigned int rawCodes[] = {
     irsend.sendRaw((unsigned int *)rawCodes, sizeof(rawCodes)/sizeof(int), 38);

The odd entries are the marks (where the LED is on), and the even entries are the spaces (where the LED is off).  It’s very likely that code has spurious stuff in it that’s not required, but sending that signal out makes the TV turn on and off, so I don’t care.  You define the array as a const because it’s not being changed and therefore you want it in code space (32k) and not RAM.  The Atmega328p used in the Arduino Uno only has 2kb of RAM, and some of that is blown by libraries and other stuff.

Next up is the Media Center Remote.  I needed to actually decode the protocol for that, since I’d definitely run out of memory on the Atmega if I didn’t, and besides, it’s cooler.

Media Center Remote Protocol

The code for the IR Blaster can be found at MPC_IR_Blaster.pde at my GoogleCode repository.  To make the decoding of the protocol easier, rather than write my own custom handler in the IRremote library, I just leveraged the existing libraries, and then wrote a custom decoder that handled the raw code.

Fuzz factor is required, since when you receive a raw code with IRremote, the figures you get are fudged to be approximate durations of marks and spaces.  So if you’re trying to match those to bits, you need a little fuzz factor to help out.  Values received in the raw buffer are in 50us ticks, so a single tick worth of fuzz is enough.

From examining every button on my remote, I noticed that the protocol has six values that it uses, with approximate values of;

  • Mark Long and Space Long – 18 ticks
  • Mark Short and Mark Short – 9 ticks
  • Special Mark Long – 54 ticks
  • Special Mark Short – 27 ticks

The “special marks” always appear in the same place in the received buffer, that is, they’re the first mark, and the tenth.  They are always followed by a long space.  In between those two marks are always eight marks and eight spaces, which are always the same.  Following that is a set of 24 marks and 24 spaces which is always the same, followed by another set of up to 32 marks and 32 spaces which are variable.

So, using a quick bit of coding theory, we can assign bits to the marks and spaces, as so;


So each pair of mark and space gives us two bits.  From there, we can assemble groups of 4 bits into hex digits, and we get the following example packet;


x = Special long mark/space pair
y = Special short mark/space pair
A = Static value of 0x05000008, assumed to be the ID of the remote or a special marker
C = Command code.  Variable length, assumed any missing least significant bits are zeroes.  The high byte toggles between 0x10 and 0x04 on each keypress, assumed to be for detection between multiple keypresses and holding a key down.

Now, given the above, we can do some pretty basic bit arithmetic and shifting to convert the incoming raw buffer into a single unsigned long command code, which we can easily process and match against.

Don’t forget that the marks and spaces are matched against the template values above using the fuzz factor, to account for variance!

Putting it together

Reading the code of MPC_IR_Blaster.pde, you can see how I’ve done the matching, and what happens.  If we get a valid MCE command code, we match it against any of the coloured button codes, light up the RGB LED as appropriate, wait for SEND_DELAY milliseconds, then transmit (if appropriate).  If we match the code as an MCE code, but don’t know what it does, we print the code to the serial port.

Note that DEBUG should be undefined if the Arduino won’t be connected to a serial port, otherwise it appears to wait for one, so it won’t work off your computer.

Also, in IRremoteInt.h, change the line around line 178 which reads;


Change it to read;


So, I assembled the whole thing onto a breadboard and ran it.  After a lot of stuffing about and debugging, it works!

However.  The illumination angle for the IR LED I have is a bit too narrow.  I need to get either a very high powered LED so it can just bounce the IR off the walls, or get one that’s much wider angle.


The drive current of the digital pins of the Atmega isn’t very high.  In order to get a really bright LED, you should really use a driving circuit, such as a transistor.

For this, I used a BC548C NPN transistor (I have dozens of them handy) and a 10k resistor.  The output pin of the Arduino goes in series through the 10k resistor to the base of the BC548C.  The emitter of the BC548C goes straight to ground.  The collector of the BC548C goes to the cathode (negative) terminal of the IR LED, and the anode of the IR LED goes in series with a 100 ohm resistor to +5V.

Prototype Schematic, including driving circuit

Driving the LED through a transistor should mean you can swap out for a much more powerful LED (say a 300mw model!) without being at risk of blowing up your Arduino.  Note that the BC548c I’m using has a maximum collector current of 200mA, and a maximum base-emitter voltage of 5v, so you’ll have to change transistors to drive something really powerful.

Next Steps

Now I know the prototype works, the next thing is to wait for my new Atmega328p and associated hardware to arrive, and then set up a basic Arduino-compatible breadboard.  Then I can assemble my prototype onto that, make sure everything still works, and then transfer it all to Veroboard.

I should be able to power it from the +5V on USB from the media center, although if I can scavenge a wall wart from something I’m chucking out, I’ll use that instead with a voltage regulator.

Next update on this project will be discussing building the Atmega onto a breadboard.

AeroQuad – Wii Sensors and IMU

Update:  Well, I got a logic level converter, and it made no difference to the outputs.  Seems the clones just weren’t any good.  No matter, I’ve already got an ITG-3200 gyro and a BMA180 accelerometer waiting in the wings. Chalk that one up to experience.

On Friday, I got the Wii nunchuk and Wii Motion Plus that I picked up from eBay.  Unfortunately, it turns out that they’re clones, and not original Nintendo parts.  However, for the price I paid, I really can’t be surprised.  Clones however can be …  difficult.  So, let’s get unpacking and assembling, and see how we go.

WMP board (top), and Nunchuk (bottom)

Unpacking the two boards, and then desoldering the connectors to get the raw PCBs didn’t take long and wasn’t very hard.  But first, I matched up all the pins using a multimeter to verify that the pinout is how I expected it to be.  The pinouts were fairly similar between the two boards, and fortunately the coloured wires used a sane colour scheme which I duplicated when I made the jumpers that go to the Arduino.

So, following this tutorial on the AeroQuad forums, I marched ahead.  First, I discovered that I need desoldering braid – a solder sucker isn’t good enough for that kind of tiny work.  Second, the tip on my iron is too big!  I need a smaller tip, really.  But I made do anyway.

In essence, the nunchuk is attached to the WMP board, then the WMP board is connected to the Arduino.  First, I attached the nunchuk, as here;

Connecting the WMP to the Nunchuk

The grey wire is the Device Detect line on the nunchuk, which isn’t needed.  Note the jumper on the WMP that links VCC to the WMP’s Device Detect line.

After that, it’s necessary to get the WMP and the nunchuk aligned properly.  This alignment is the same alignment that’s used for the MultiWii.  “Forward” is at the top of the picture.

Sensor orientation – up is “front”

So, with the sensors in that orientation, I attached the coloured wires from the nunchuk to the location where you see the grey wires on the WMP, and then attached wires using the same colour scheme to the WMP so they could go to the Arduino.  Attaching the whole kit to a breadboard gives this;

Attached to a breadboard

The yellow wire is SCL, the green wire is SDA, black is GND, and red is +VCC.  SDA connects to analog pin 4, and SCL connects to analog pin 5.  VCC is set to 5 volts.

So, how did it work?

Not so well, to be honest.  The WMP appears to be rather intermittent as to whether it works or not.  It either just returns zeroes or some garbage value that doesn’t change.  Power cycling the WMP repeatedly can cause it to come good and then work fine, but losing the IMU appears to make the AeroQuad software crash, requiring a reset.  And the reset kills off the WMP again.

However, putting MultiWii onto the Arduino had a slightly different result.  The WMP still would often not initialize properly, but when it did I could connect the MultiWii configurator and have the pitch/roll meters work properly.  That’s a start, but it’s not exactly what I want.

I asked the good folks at AeroQuad for help on the forum, but it looks like my problem may be the clone sensors.  Not much I can do there, at least until I get a logic level converter so I can try and run it off 3.3v and see if that stabilizes things.

What now?

Well, I’m thinking what I’ll do is order in an ITG-3200 gyro and a BMA180 accelerometer, which are the recommended parts to go onto the AeroQuad v1.9 shield I’ve got coming in.  That shield does come with a logic level converter board, so I’ll test the WMP using it, but I’ll use the “correct” parts anyway.  If the WMP works fine with the LLC, then I’ll keep them aside for a miniquad or something similar.

It’s a bit disappointing to get roadblocked straight out of the gate, but I went with the Wii sensors knowing they were dirt cheap and with the view that I might have to get the expensive breakouts anyway.  Looks like that happened, and I’ll put more time into diagnosing it later.

I have a pretty good hunch the problem is going to be the 5v feed.