Arduinoven – Board Assembly

Assembled the Arduinoven board over the weekend. It wound out being that one of the boards I received had a manufacturing defect, but the other two didn’t.  While it would be pretty straightforward to correct the defect with a craft knife, I decided to just use one of the other boards.  I guess that’s why they sent me three boards and it’s also why you should check over a new board with a continuity tester…  Anyway, after all that, IT WORKS.

Overall board quality was high, although I’m glad I used the wide isolation distance that I did.  There were two other spots where if I hadn’t used a large isolation I probably would have had a short.

Assembled Topside – in Sparkfun project case

Assembled underside

I had a bit of difficulty getting the power and relay LEDs at the right length, hence the dark spots on the underside of the board at that point. Additionally, I didn’t solder the whole way across the locking pins for the DB9 port (they don’t do a whole lot).  I probably should go over the whole board’s topside and fill up any of the through-holes which didn’t wick through completely from the underside.  Might do that later.

First part I assembled was the power supply and power LED, that way I could ensure that power was running through the board correctly.

Second part was assembling the microcontroller, crystal, loading capacitors, reset switch, reset line pullup resistor, ICSP header, and relay LED.  That way I could test that the MCU was operational by programming it with ICSP.  Then I soldered on the FTDI header, auto-reset jumper and capacitor, and made sure I could talk to the MCU via FTDI.  Lastly in this part, I soldered on the LCD i2c header and made sure that I2C was operational.

Part three was assembling the DB9 socket, MAX232 chip, RX/TX leds, and load capacitors for the MAX232.  This allows you to connect a serial cable to the unit and make sure you can talk to the MCU through serial.

Part four was soldering on the right-angle header pins for the thermocouple and relay, and putting in the AD595 thermocouple amplifier.  Then you can test that the amplifier works.

Next up, solder on the I2C pullup resistors and the 24LC256 i2c EEPROM.  A quick run with an I2C scanner shows it works.

And lastly, solder in the resistive network for the buttons and then the buttons and any remaining parts.

Assembling in this way allows each section to be tested and verified before you move onto the next, simplifying debugging if there’s any problems.

At any rate, everything worked first go.  Well, I got a LED around the wrong way, but it happens.  Next up is to start working on the software and cutting out the case.  That may take me a while…

Arduinoven – Boards Received!

Yesterday, I received my delivery of my Arduinoven boards from MakePCB.  Package arrived slightly under a month from when I ordered it, and I got a nice surprise – I’d ordered one, but I was sent three!

All look in good condition, with no visible manufacturing defects (besides a small scratch on the ground plane soldermask during shipping, and a hair lodged in the mask somewhere, but that doesn’t matter).  The fiberglass board is thick and heavy, and the mask itself looks of good quality.  The milling is precise and clean, and the silkscreen is showing up all the detail very well.  The size is just right to fit inside the Sparkfun Project Case (and it does actually fit, which is a relief).

Topside of completed v1.0 board

Underside of completed v1.0 board

Now what remains is to check the board over carefully with a multimeter for any manufacturing defects, and then the moment of truth – assembling components onto the board and hoping I didn’t mess up my design somewhere…

AeroQuad 2.5.1 – Code Upload via ICSP

So I’ve been fooling with the new AeroQuad 2.5.1 code, and I’ve integrated some fixes posted by Kenny9999 (an forum user), as well as integrated my battery level compensation code.  Unfortunately though, putting in both makes the code a little too big to fit into the 32256 bytes you have available on the Uno with the Optiboot bootloader.

Since I have an ICSP programmer (Bus Pirate to the rescue!) I decided I’d go and upload the code directly.  That way I can utilize the entirety of the flash!

As discussed in my post about using a Bus Pirate as an ICSP programmer, you need to set up a new hardware definition for Arduino.  Mine’s called tiny45_85, but we’ll use that for a new ATmega328p definition.

Edit boards.txt in tiny45_85, and add the following; 16MHz (w/ BusPirate)

Essentially what this does is create a new entry in the Arduino IDE’s “Boards” menu, which will upload using the Bus Pirate programmer definition we made in attiny45_85/programmers.txt, setting the maximum upload size to 32760 bytes at 16MHz.  It will use the build core for a normal Arduino.

What’s notable is that the default fuse setup for an Arduino (here) will set the high fuse to 0xD6.  This sets up the Arduino so on boot it will boot the bootloader.  In other words, code execution will not begin at address 0x0000.  This won’t work if you have no bootloader.  The fuses need to be changed so that the BOOTRST flag is unprogrammed.  In AVR-speak, this means it’s set to a value of 1 (0 means “programmed).  So, this means that the high fuse needs to be set to 0xD7.  No other fuses need to be changed.

To change this, you’ll need to run AVRDUDE with a command line like this;

avrdude -p m328p -c buspirate -P COM8 -v -C ..\etc\avrdude.conf -U lfuse:w:0xFF:m -U hfuse:w:0xD7:m -U efuse:w:0x05:m

Once I figure out exactly how to do it through the IDE, I’ll integrate that into boards.txt above and edit this post.  If you don’t change that fuse, your code might work, since the flash will by default be filled up with 0xFF’s, but if your code happens to be big enough to go into where the boot is trying to start, it probably won’t work.  Set the fuses right.

After that’s all done, you should be able to fire up your Arduino IDE, and see a new entry in Boards called “ATmega328p 16MHz (w/ BusPirate)”.  Select that as the target board, upload and voila!  Your code will be burned directly onto the ATmega328p with no bootloader through ICSP.

I’d suggest that you use the bootloader (since then you can use the built in USB upload) unless you have specific reasons not to (eg, pin state on boot causes the bootloader to lock up, or you need the space).

Bus Pirate as FTDI Cable

One of the things I wanted to do with my Bus Pirate was figure out how to apply it like an FTDI cable for the purposes of uploading sketches to an Arduino.  It took me a little stuffing around to do it, but here’s the condensed version of how to make it work;

First, the “black” wire on the proper FTDI cable is pin 1, and the “green” wire is pin 6.  Now, you wire up your Bus Pirate to the FTDI 6-pin header like so;

Pin 1 – Brown (GND)
Pin 2 – Not connected
Pin 3 – Orange (+5V)
Pin 4 – Grey (MOSI)
Pin 5 – Black (MISO)
Pin 6 – Purple (CLK)

Now that’s done, we’ll use the BusPirate in UART mode to get it emulating an FTDI cable.  There’s something important to understand here – the BusPirate cannot switch serial speeds after you put it into transparent mode.  Fortunately we want to program at 115200 baud, and the BusPirate is already connected at that speed by default, so it’ll be all fine.

  1. Open up your terminal emulator, connect to the BusPirate at 115200 baud.  If you use a different speed, connect at that speed, and then press “b” in order to swap to 115200 baud.
  2. Change to UART mode (type “m” and then “3”)
  3. Select serial port speed of 115200 baud (type “9”)
  4. Select 8 data bits, no parity (type “1”)
  5. Select 1 stop bit (type “1”)
  6. Select receive polarity of idle 1 (type “1”)
  7. Select output type of Normal (H=3.3v, L=GND) (type “2”)
  8. Activate the power supplies (skip this step if the circuit is externally powered!) (type “W”)
  9. Type “i” for info.  The pullup resistors should be off.
  10. Type “(3)” including brackets, no quotes.  This will put the BusPirate into transparent bridge mode with flow control.  Once this is done, you’ll have to reset the BP to get a prompt back again.
  11. Close your terminal emulator.
  12. Fire up the Arduino IDE, and upload firmware like you usually would, selecting the BusPirate as the serial port.  It’ll work just like an FTDI cable will, only it can’t change speeds.

All works as expected, and the upload speed is very similar to a real FTDI cable.  It can even auto-reset a Uno for doing the upload.

Bus Pirate as ICSP Programmer

NOTE:  This article was written for the Arduino 022 IDE, not for the release 1.0.  Things are now quite a lot simpler in the 1.0 IDE, so this article will be getting a severe editing once I get to retest everything.  Stay tuned.

As discussed in my last post, I got a Bus Pirate yesterday.  One of the first things I wanted to do with it was use it as an ICSP programmer for an ATtiny85.  The ATtiny85 is an 8-pin microcontroller with (up to) 6 I/O lines and 4 ADC’s.  It can run up to 20MHz with an external crystal or 8MHz with its own internal oscillator.  It has 8k of flash available.

In this post, we’ll discuss hooking it up to the Bus Pirate, getting the BP talking to Avrdude, setting up the efuses to use the internal oscillator, and then configuring the Arduino IDE so you can upload to it through the BP.

Caution:  The BusPirate is really really slow as an ICSP programmer.  It’ll work, but it may take 15 minutes to write and verify the default bootloader on an ATmega328p due to the large flash size.  On an ATmega2650 it might take an hour.  Be patient.  Or use the customized AVRDUDE and BP firmware I discuss here.

Step 1 – Connecting the BP to the ATtiny85


As it turned out, hooking up the BP to the ATtiny is pretty easy.  Just follow the pinouts on the Microcontroller Cheat Sheet;

Microcontroller Cheat Sheet (link above)

Pay particular attention to the fact that the BusPirate I/O header layout on the sheet above is actually reversed compared to the Seeedstudio layout.  Use the pin names and colour reference instead to determine which pin is which;

Color Reference – MISO is pin 10, GND is pin 1

Going from those two, it’s pretty straightforward to wire up the ATtiny85 as follows;

BusPirate Label BP Color ATtiny85 Tag AT Pin
GND Brown GND 4
+5V Orange Vcc 8
CS White RESET 1
CLK Purple SCK 7

After the BusPirate is all wired up, it’s time to set up a new version of avrdude to work with it.

Step 2 – Setting up the new avrdude


Unfortunately, the version of avrdude that comes with the Arduino 22 IDE is positively ancient and doesn’t support the Bus Pirate.  The latest 5.10 version of avrdude does, so you’ll need that.  You can pick up a pre-compiled binary from here.  Extract out the files.

Pop open a command prompt, go to the folder that you put this new version of avrdude in, and then run the following command;

avrdude -c buspirate -P COM8 -p t85 -v

You should see a whole bunch of useful info, and most importantly you should see a list of the fuse settings.  If so, fantastic, it works!

Step 2a – Building your own AVRDUDE


This is an advanced step.  You don’t need to do this if you want to use my pre-compiled AVRDUDE in Step 2.  But if you want to build your own, follow these instructions to make it easy(ish).

  • Download and install MINGW and MSYS.
  • Use TortoiseSVN to fetch the latest AVRDUDE into C:\MinGW\msys\1.0\home\\avrdude
  • Download the latest libusb-win32 from
    • From include\usb.h in that package, copy that to C:\MinGW\include and rename as usb.h
    • From lib\gcc\libusb.a, copy that to C:\MinGW\lib
    • From bin\x86\libusb0_x86.dll, copy that to C:\MinGW\bin, and rename as libusb0.dll
    • Drop a copy of libusb0.dll into your avrdude repository.
  • Update MinGW and install additional components
  • mingw-get update
          • mingw-get install autoconf
          • mingw-get install automake
          • mingw-get install msys-bison
          • mingw-get install msys-flex
          • mingw-get install msys-patch
  • Get and install the BusPirate patch for the AVRDUDE SVN
    • Download the patch file from the link above, and copy it into C:\MinGW\msys\1.0\home\
    • In mingw, do the following;
      • cd avrdude
      • patch < ../avrdude_buspirate.patch
    • You should now have a patched AVRDude, which has some optimizations to make it work a lot faster than default.
  • Configure and build
    • ./bootstrap
    • ./configure
    • make
    • strip avrdude.exe
  • Now, copy out the following files, they make your new avrdude;
    • libusb0.dll
    • avrdude.exe
    • avrdude.conf

Step 3 – Programming Fuses on the ATtiny85


Next up, we’re going to want to set the fuses on the ATtiny85 to suit what we want to do.  In my case, I want to run at 8MHz using the internal oscillator.  Using the link above, this means I want to set the lfuse to 0x62 and the hfuse to 0xDF.  In my particular case, the fuses are set correctly by default, but if they weren’t you could reconfigure them with;

avrdude -c buspirate -P COM8 -p t85 -v -U lfuse:w:0x62:m -U hfuse:w:0xDF:m

Note that the default fuses will set the ATtiny85 to use the internal RC oscillator and divide it by 8.  This means that your ATtiny will actually run at 1MHz.  If that suits your task, fantastic – it’ll draw less power that way.  I’m leaving things at default just for the sakes of making it work.  If you do turn off CKDIV8 to get an 8MHz clock, you’ll have to change below to 8000000L to suit.

And now, a warning.  It’s possible to brick your ATtiny by setting the wrong fuses.  In particular, if you set RSTDISBL=0 (ie, enable the reset pin to be used as an I/O pin), you remove the ability to be able to program the ATtiny with a normal ISP, and you’ll have to use a high voltage programmer in order to fix it.  So don’t do that unless you are really sure your code is going to work and you really need that sixth I/O.

Anyway, set the fuses as required, and then we’re going to integrate it all into the Arduino IDE.

Step 4 – Arduino IDE Integration


First off, we’ll need to copy in our compiled avrdude.  Fortunately, the cygwin1.dll is compatible between the version 22 IDE and the avrdude linked above.  Assuming you installed the IDE into c:\arduino, copy avrdude.exe, libusb0.dll, cygusb0.dll and cygwin1.dll into c:\arduino\hardware\tools\avr\bin .  Then copy your avrdude.conf into c:\arduino\hardware\tools\avr\bin .

Next up, you’ll need to reconfigure your default Arduino boards so that you can upload using the new avrdude (which requires programmer type ‘arduino’ instead of ‘stk500’).  To do this, copy c:\arduino\hardware\arduino to the hardware folder in your sketchbook, so you have a folder hardware\arduino in your sketchbook.  This causes that new copy of the Arduino platform definition to override the built-in version in your IDE.  Edit programmers.txt and comment out (put #’s at the start) of any lines for programmers you don’t have, and then edit boards.txt and comment out any boards you don’t have.  For the Arduino Uno board, edit the uno.upload.protocol line and change it to read uno.upload.protocol=arduino .  This causes the IDE to use programmer type “arduino” when calling AVRdude, which is correct.

Download from the link above.  Follow the instructions in that link in order to extract out the attiny45_85 folder into your hardware folder.  Then, edit your boards.txt file that you extracted.  What you’ll need to do here is to comment out (add #’s at the beginning of the line) any of the options you don’t care about, and add in a new one.  The new option we’re adding down the bottom is like this; (w/ BusPirate)

Next, you’ll need to create a programmers.txt in the same folder as your boards.txt, and set its content to the following;

Once that’s done, you should be set up.  Fire up the Arduino IDE, and in the Board selection, you should see your new “ATtiny85 (w/ BusPirate)” option.

Step 5 – Testing!


We’re nearly home free.  Fire up the Arduino IDE, and open the Blink sketch.  Change any references to pin 13 to 0.  Pin 0 corresponds to physical pin 5 on the ATtiny85, and is the MOSI line on the chip.  That line corresponds to BusPirate pin 8, which is what we’ll be looking at shortly.

Upload the sketch.  You should see some Cygwin warnings, and then a line about putting the BusPirate into binary mode.  You should see nothing else (the IDE is a little quiet, unfortunately).

After that’s done, hopefully everything will work.  In order to avoid having to go as far as pulling out the ATtiny85 and hooking a LED to it, we’ll utilize the BusPirate to monitor that line toggling!

Using a terminal client of some type, connect to the BusPirate.  You should be in Hi-Z mode.  Type “m9” and hit enter to go into Direct I/O mode.  Hit ‘v’ and press enter and you should see all the connected lines in state “I” (input).  That’s what we want.  Now, type “pW” and press enter.  This disables the internal pullups if they happen to be on, and then turns on the power supplies.  This will cause the ATtiny85 to power up and (hopefully!) start pulsing pin 8 on the BusPirate.

Now, type “v” and press enter a few times, and you should see pin 8’s state transition from L (low) to H (high).  If that happened, then that indicates that the ATtiny85 has been successfully programmed with your code from the Arduino IDE!

Coming up soon, some optimizations to AVRdude to make it work faster (I hope).

Arduinoven – Whoops!

I’ve been finalizing the prototyping stage of the Arduinoven, and I’ve discovered something that’s pretty obvious to someone who has worked with thermocouples before.  Not obvious to me though, until now.

Essentially, you can’t run a thermocouple’s electrical connections along a copper cable that’s as long as the thermocouple.  You get enormous errors in the output of the thermocouple (up to 30 degrees!).

Instead, I’m going to have to make a small redesign so I can connect the thermocouple’s cable directly to the Arduinoven board.

Updates once I’ve done so.

AeroQuad 2.4.2 – Barometer with the Uno

I picked up a BMP-085 barometer breakout board for my quadcopter last week.  I decided to pick up one because the new AeroQuad 2.4.2 code is able to be compiled to support altitude hold and be able to fit on an Arduino Uno.

However, there’s an issue.  Apparently the version of the Optiboot bootloader that comes with the Uno has a bug in it where it reserves flash RAM equal to the biggest bootloader (~2k or so), even though Optiboot only takes up 512 bytes.  This means that if your sketch compiles to over ~30k, you can compile but you can’t upload.  You get a very obtuse error message.

There’s a way to fix this though.  Make use of the ArduinoISP I made earlier to reflash the bootloader!

There’s a fixed version of Optiboot that allows upload, but I realized that I could upload the Aeroquad binaries directly to the Arduino and bypass the bootloader entirely, and then I could use the entire 32k flash (!).  Optiboot be damned.

In order to do this, you’ll need to get hold of your compiled code in .HEX format.  The easy way to do this is to hit Ctrl-R in the Arduino IDE, then use Windows Explorer to browse to %TEMP% .  Look around for a folder called buildtmp.XXXXXX where XXXXXX is some random gibberish.  Inside of that will be a copy of all the AeroQuad code source files, a bunch of .o files, and a single .HEX file.  This is what you want.  Copy it somewhere.

After that’s done, you can use avrdude in the Arduino IDE kit to flash the Arduino directly.  The following command assumes you’re using the ArduinoISP and it’s connected to COM4.  It also assumes that the .HEX file is in c:\arduino, and you’ve installed the Arduino IDE as displayed.

C:\arduino\hardware\tools\avr\bin>avrdude -pm328p -cstk500v1 -b19200 -PCOM4 -v -C ..\etc\avrdude.conf -e -U flash:w:\arduino\aeroquad.hex
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            : COM4
         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                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ———– —- —– —– —- —— —— —- —— —– —– ———
           eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 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.04s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as 5
avrdude: erasing chip
avrdude: reading input file “\arduino\aeroquad.hex”
avrdude: input file \arduino\aeroquad.hex auto detected as Intel Hex
avrdude: writing flash (31406 bytes):
Writing | ################################################## | 100% 36.19s
avrdude: 31406 bytes of flash written
avrdude: verifying flash memory against \arduino\aeroquad.hex:
avrdude: load data flash data from input file \arduino\aeroquad.hex:
avrdude: input file \arduino\aeroquad.hex auto detected as Intel Hex
avrdude: input file \arduino\aeroquad.hex contains 31406 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 36.03s
avrdude: verifying …
avrdude: 31406 bytes of flash verified
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.


Ta-da!  After that’s finished, you should have the AeroQuad code running on a Uno, with no bootloader.  One advantage with this technique is I’m pretty sure you can compile it to have BatteryMonitor, AltitudeHold and use DCM instead of ARG, which is a better flight algorithm.

Flight testing on the weekend 🙂

ArduinoISP – Burning the default fuses for an ATmega328p

When you buy a brand new, blank ATmega328p, it comes with a set of fuses (basically hardware settings) which give it maximum reliability, but they aren’t the default that is required for the chip to work with the Arduino IDE and libraries.  In order to burn the correct fuses onto it, run the following command (this assumes that you’re using Arduino-as-ISP on COM4);

avrdude -pm328p -cstk500v1 -b19200 -PCOM4 -v -C ..\etc\avrdude.conf -U lfuse:w:0xFF:m -U hfuse:w:0xD6:m -U efuse:w:0x05:m
Run the command from the hardware\tools\avr\bin directory inside your Arduino IDE install.
Short post, I know.  This info’s mostly for my reference, but should be handy for others too.

New Project – Arduino-based Toaster Oven Controller

Now that I’ve got the MCE Remote all built and in service (works quite nicely!), I need a new project.  I’m interested in getting involved in surface mount devices.  The reason for this is threefold – there are certain devices that aren’t available in through-hole packages, when using SMT you can typically make a board a lot smaller, and lastly individual SMT components not on breakout boards are typically a LOT cheaper than the already-soldered part.

There’s a few ways to handle surface mount.  You can use a normal soldering iron, really steady hands, and a lot of patience.  You can use a hot air gun (I’m probably going to get a rework station for this).  Or you can use a reflow oven.  The reflow oven “cooks” the components onto the board, and if handled properly is the best and easiest way to solder a whole bunch of components onto a board.

A professional reflow oven costs a large amount of money, but it’s possible to press-gang a normal toaster oven into the task by modifying it so that it can be temperature controlled and given a normal reflow temperature profile.  There are kits available to do this, like this.  However, in the spirit of adventure (and not wanting to mess with a PIC when Arduino is familiar), I decided to roll my own…

Behold!  The first schematic of the Arduinoven;

The Arduinoven v1.0

This schematic is entirely theoretical at the moment (I haven’t breadboarded any of it), however much of the design was lifted from the Arduino Severino board, which has many of the features I wanted.  I simply extended it a lot to add all the extra functionality.  The design has been assembled so that each section can be tested largely independently to simplify breadboarding when I come to that stage.  With the design, there were a few key features I wanted to adhere to;

  • Must be suitable for production by somewhere like BatchPCB (and can therefore be two layer).
  • Must have entirely through-hole components.
  • Must use an ATmega328p and be programmable through the Arduino IDE
  • Be able to store a significant amount of temperature data (that’s what the i2c EEPROM is for)
  • Use an LCD and press buttons for an interface (uses an i2c LCD module)
  • Relay and thermocouple connections need to be on the actual oven itself, but the Arduinoven will be a removable device (hence the DIN-5 connector)
  • Be expandable in case additional hardware is desired (hence all the pin headers)
  • Use RS232 for serial communications to a PC
  • Fit onto a Eurocard-sized format PCB (100x80mm)

All in all, I’m pretty happy with how the design’s looking.  More information once I receive my shipment of parts and I can start with the prototyping.  Once I’m happy with the prototyping, I’m intending to get the board manufactured by BatchPCB so I can get something professional looking.

Note:  Call me suspicious, but I think that the Severino’s schematic is in error and C8 (C5 on mine) is around the wrong way.  I’ll look into it more before I actually breadboard anything.

MCE Remote – Board Etching and Assembly

In my last post about the MCE Remote relay I was working on, I prototyped up the circuit and finalized the schematic in Eagle.  After doing that, I worked on a PCB layout ( all related file can be found here ).  It was a bit of a trick getting a suitable layout sorted out in Eagle, but I got it done.  From there, I was able to generate transfers for the top layer (silkscreen), and the bottom layer (etch).  They appear below;

Silkscreen layer (as output by Eagle)

Etch layer (as output by Eagle)
I strongly recommend making sure you put text on all layers somewhere, so you can easily identify if they are reversed or not.  In order to do something useful with that, I decided to do something completely new to me – toner transfer PCB etching.
The principle with toner transfer etching is simple.  Laser printer toner is plastic, and if transferred onto a copper PCB will protect the PCB from the etchant wherever it is.  Since I’d just got hold of a laser printer, I thought I’d make use of the idea.  I went to Jaycar and bought some Press ‘n Peel toner transfer film.
This film is quite expensive per sheet.  Many people do the same thing on magazine glossy paper, but I figured I’d go with the peel just to make things easy for my first go.  I also bought a PCB etching kit which came with PCBs about the right size, a tray, tweezers, and sodium persulphate etchant.
Etch layer printed onto transfer film
The prints that you do should be reversed onto the toner paper (so the silkscreen layer gets mirrored, but the etch layer is printed as is).   One thing I discovered – don’t turn up the toner density too much.  I turned it up to maximum, and I got some of the smears you see there, and there wound out being way too much toner.  In addition to that, I should have made my isolation distances a little bigger because the toner flattens out a bit and makes the traces wider than expected.
After doing that, you simply lay the film on top of the cleaned PCB and iron it with a hot domestic clothes iron (no steam!) for a few minutes, gently moving the iron to ensure even heat transfer.  Afterwards, quench the board in cold water and peel off the film.
Toner transferred to PCB
As you can see, there’s a few spots where the tone squeezed out and made shorts on the tracks.  Those are resolved easily with a sharp knife post-etching, but it would have been better if I’d made the isolations a bit further apart.  I also filled in the (huge) pads of the 2.1mm power jack with an etch resist pen.  Then, it’s in the etchant, following the instructions.  You’ll notice that nearly nothing appears to happen, but then all the copper vanishes within a short period of time.  That’s because of the extremely high opacity of metals – the copper remains opaque until it’s only a few atoms thick, and then it all appears to vanish in a rush.  That’s normal.
Post etch, toner layer still in place
Removing the toner is as simple as giving it a wipe with acetone.  After that, I ironed on the silkscreen layer transfer in the same way on the top, and then drilled all the holes.  Most holes are 0.8mm, with the 2.1mm jack being 3mm.
Silkscreened Layer
The horrible damage on the corners was my highly amateurish attempts at getting the damn board to fit into the jiffy box I got, which was only just big enough for the board.  I’m sure I could have done a much better job of it, but it doesn’t really matter.
And then finally, soldering all the parts on.  The ironed on template on the top makes assembly much much easier, even though it’s not lined up perfectly.
Populated Board
Instead of soldering the infrared LEDs direct to the board, I soldered in female pin headers, so that I can use a cable for one of the LEDs if I want.
On powerup, I noticed immediately that the pin arrangement of the RGB led is different from the schematic!  It doesn’t matter though, I was able to take care of it with a software change (the blue and green pins are swapped).  I also thought that the circuit didn’t work and so wound out doing all sorts of ugly things to the transistor amplifying stage, but it turned out to be perfectly fine and it was simply that I uploaded a copy of the code using the bugged IRremote library instead of my fixed version.  Doh!
Next up is to neatly cut out the jiffy box to suit, and I’m done!