Posts Tagged ‘open source’

XBoot – Quick Start Guide (for a sweet XMega bootloader!)

So in my recent XMega wanderings,  I needed a good bootloader.  After muddling through various app notes and forum postings, I came across the culmination of what I couldn’t do on my own – XBoot!

In my defense, I’ve worked on bootloaders before.  But the errata sheet on the XMegas is longer than the list of men Princess Leia has broken the hearts of.  And I’ve become one of the many casualties of that list.  (Erm, the errata list…  awkward…)

Big thanks to Alex Forencich!  XBoot, a fantastic reincarnation of the AVR1605 app note, is open source and highly configurable bootloader, which at the time of writing is capable of UART or I2C bootloading XMega processors.  I believe his intentions are to expand both processor compatibility and protocol options, so visit the XBoot Google Code project for more info.

I’ll  be going through and explaining the options that I used, so this isn’t an exhaustive tutorial.  This guide assumes you have a working XMega development environment, AVRDude installed, and SVN (if you want to download the code this way).  WinAVR should work just fine with a few minor alterations, but I’ve only tested this on Kubuntu with the development environment described in this previous blog post.  Also, as a side note, I’ve been using XBoot with XBee Series 1 wireless modules and it works fantabulous (that’s so good, I had to come up with a new word for it).


Here’s the step-by-step big picture:

  1. Download the code.
  2. Pick a bootloader entry method.
  3. Configure communication parameters (Port/Baud Rate/I2C addressing, etc.).
  4. Compile & program XBoot onto the MCU.
  5. Send main application via XBoot and AVRDude.

Download the Code

So let’s get started.  Download the code from the XBoot download page and uncompress it, or (my preference) use SVN to download the code:

svn checkout avr-xboot

Configure XBoot

Once the code is downloaded, find the file named “xboot.h”.  Most configuration changes, if not all, will be made here.  We’ll take it one section at a time.  Line item references are from Rev12 out of the repository, but you should be able to match them up to any version.  The idea is that all available options are enabled, so comment out what you won’t be using.

// AVR1008 fixes
// Really only applicable to 256a3 rev A and B devices
//#define USE_AVR1008_EEPROM

Uncomment this line if you’ll be using an XMega256a3.  This fixes certain problems (remember Princess Leia the errata list?). I’ve heard this has hit some people but not others, even on the same silicon revision.  It may be useful for certain other chips and families – YMMV.  Check with Google if concerned.

Line 64:
// bootloader entrance
//#define USE_ENTER_PIN
//#define USE_ENTER_I2C

Here I picked the “USE_ENTER_DELAY” and “USE_ENTER_UART”, hence I commented the other two out.  Note that the “USE_ENTER_DELAY” just puts a delay at the start of the program, and isn’t mutually exclusive with the other options.  Here’s what the options mean:

  • USE_ENTER_DELAY: Delays entry by a timeout.  Timeout is set by “ENTER_BLINK_COUNT” and “ENTER_BLINK_WAIT”, but I found the default settings worked well.
  • USE_ENTER_PIN: Select this option if you want to enter the bootloader when a pin is in a certain state at power on.  Ex: You press a switch when you power cycle to enter the bootloader.  You’ll have to configure which port/pin at line 95, at the section titled “ENTER_PIN”.
  • USE_ENTER_UART: Select this option if you want to enter the bootloader if a character is received on the UART.  This requires using “USE_ENTER_DELAY” by necessity.  You’ll need to configure the UART options at line 111.
  • USE_ENTER_I2C: Select this option if you want to enter the bootloader if a byte is received through I2C.  I haven’t used this option, hence I won’t try to elaborate.

On to the next section:

Line 73:
// bootloader communication
#define USE_LED
#define USE_UART
//#define USE_I2C
//#define USE_ATTACH_LED

I’ll be using the UART and LED, so everything else is commented out.  If you use the LED, configure the next section also:

Line 106:
// LED
#define LED_PORT                PORTA
#define LED_PIN                 0
#define LED_INV                 1

If you’re using the UART, configure this section:

Line 111:
#define UART_BAUD_RATE                  19200
#define UART_PORT                       PORTD
#define UART_DEVICE_PORT                D1
#define UART_DEVICE                     token_paste2(USART, UART_DEVICE_PORT)
#define UART_DEVICE_RXC_ISR             token_paste3(USART, UART_DEVICE_PORT, _RXC_vect)
#define UART_DEVICE_DRE_ISR             token_paste3(USART, UART_DEVICE_PORT, _DRE_vect)
#define UART_DEVICE_TXC_ISR             token_paste3(USART, UART_DEVICE_PORT, _TXC_vect)
#define UART_TX_PIN                     PIN7_bm

Should be pretty self-explanatory.  You should only need to change UART_BAUD_RATE, UART_PORT, UART_DEVICE_PORT, and UART_TX_PIN.  If you use an exotic baud rate (non-standard and/or fast), you might want to change the settings at line 51 and select the 32MHz clock option.

That’s pretty much it for this section!

Compile & Program

This should work if you’re using AVR-GCC in Linux.  I can’t vouch for WinAVR, but it shouldn’t take much to change it.  That said, the only thing that really needs to change in the Makefile is the programmer name and the chip you’re compiling it for:

Line 42:
# MCU name
## MCU = atxmega16a4
## MCU = atxmega32a4
## MCU = atxmega64a1
## MCU = atxmega64a3
## MCU = atxmega64a4
## MCU = atxmega128a1
## MCU = atxmega128a3
## MCU = atxmega128a4
## MCU = atxmega192a1
## MCU = atxmega192a3
## MCU = atxmega256a1
## MCU = atxmega256a3b
MCU = atxmega256a3
#MCU = atxmega64a3
#MCU = atxmega128a1
#MCU = atxmega32a4

For me, I’ve been using the XMega256A3 chip.  At random, I decided to uncomment the atxmega256a3 line.  YMMV.

Line 209:

And I’m using an AVRISP mkII programmer, which is pretty cheap for an authentic Atmel programmer.  It only does PDI programming (no debugging), and needs to be updated to the latest firmware using AVR Studio (sorry, penguins – you’ll have to boot into Windows), but it does the XMega trick right nicely.

To compile and subsequently program:

$ make
$ make program

This should compile and program XBoot into the programmer.  Shazaam!  If you get any errors, feel free to leave me a comment and I’ll try to help you out.

Programming an Application Via XBoot

So now that you’ve got XBoot loaded, you can use AVRDude again to program your application to your XMega:

avrdude -p atxmega64a3 -P /dev/ttyUSB0 -c avr109 -b 19200 -U flash:w:main.hex

For those of you who may have installed Eclipse as described in previous posts, you can make Eclipse use the bootloader by:

  • Click on “Run -> Run Configurations…”
  • Right click on “C/C++ Application” on the left and select “New”
  • In the “Name:” textbox, enter “Program via XBoot”
  • In the “C/C++ Application:” textbox, enter “/usr/bin/avrdude” (or where ever it’s installed if you’re using Windows)
  • Click on the “Arguments” tab.  Enter the following line, modify to suit your needs, and then click “Apply” and “Close”
-c avr109 -p x256a3 -P /dev/ttyUSB0 -b 19200 -e -U flash:w:Debug/eclipse_project_name.hex

There you have it.  As always, if you need any help just ask in the comments below!


svn checkout avr-xboot-read-only

XMega Solution for Kubuntu

29 April 2010 5 comments

Howdy folks.  For any penguin heads out there trying to get an XMega development setup for Linux, I finally got it working, and didn’t even have to compile anything!

My setup is a SparkFun XMega breakout board ($25) and an AVRISP mkII programmer, which I bought from Mouser (~$35) specifically for the new PDI programming.  Seems Atmel ditched the venerable ICSP programming method with these new chips.  The AVRISP mkII can program over the new “Programming and Debugging Interface”, but can’t debug.  If you want to be able to debug over the PDI interface, go for the JTAGICE mkII or another programmer.

I’m running Kubuntu Linux 9.10.  This solution probably won’t be all that useful for that long, because I imagine (but haven’t checked so I don’t know for sure) that Kubuntu 10.04 will have these updated packages.  Regardless, some of the advice that follows will still be pertinent to some people.

So here’s what I’m going to do: Set up my Kubuntu 9.10 installation to be able to compile for XMegas using AVR-GCC, program XMegas using AVRDude, and use Eclipse as an IDE for all this.

Install AVR-GCC and AVRDude

Since the packages in the Kubuntu 9.10 repository aren’t up to date enough to work with the XMega, we’ve got to get them from somewhere else.  I default to the Debian repositories, which 9/10 times work with Kubuntu.  I’m not sure if there are other packages you need installed, because I started with a working standard AVR and GCC development environment already working.  If installing these packages complains about dependencies (beyond those in the list below), using “apt-get” to install them from the normal repository should be fine.

Download the following “squeeze” packages for your system from here:

NOTE: Just install these from the repository using apt-get if using Kubuntu version 10.04.

There’s a specific order you have to install these in – I can’t remember exactly what it is.  Right click on the files in Dolphin (or, as I prefer to use, Konqueror) and use the GDebi package installer to install these files graphically, or dpkg to install from the command line.  Once these are installed, you can compile and program your XMegas from the command line!

Install Eclipse and AVR Plugins

Eclipse has some features that I’ve heard are pretty nice.  Traditionally, I’ve used and really liked KATE (KDE Advanced Text Editor), and recently I’ve gotten hooked on VIM, but I’m not a bigot about things I haven’t tried.  So here’s me trying Eclipse for AVR programming.

First stop, install Eclipse.  You’ll want Eclipse CDT, which is geared towards C/C++ development instead of Java.  You can download it here.  Install it by extracting it, pretty much anywhere.  I installed it into my development tools folder – another standard place is the opt folder (/opt/eclipse).  Further instructions on this can be found on this UbuntuForums post.

Once Eclipse is installed, you’ll want to add the AVR plugin.  Follow these instructions.

Start a New AVR Project

To start a new AVR project for an XMega, follow these steps:

  1. Click “File -> New -> C Project”
  2. Enter a new project name, and under the “AVR Cross Target Application” select “Empty Project”.  AVR-GCC Toolchain should be selected on the right side.  Click “Next”.
  3. Click “Advanced settings…”
  4. Click the “AVR->AVRDude” option on the left.
    1. Under the “Programmer” tab, select your programmer.  If it’s not in the list, or the list is empty, click “New…” and select your programmer.  For me, it was “Atmel AVR ISP mkII”.  Click “OK”.
    2. The rest of the options under the tab should be left with defaults.
  5. Click the “AVR->Target Hardware” option in the left pane.
    1. Select your processor.  For me, the “ATXMega128A1”.
    2. Select the frequency your processor will run at.  For me, 32MHz.
  6. Click “C/C++ General->Indexer”, then click the link on the top right titled “Configure Workspace Settings”
    1. Check the “Index unused headers” option.
    2. Check the “Index source files not included in the build”.
    3. Check the “Allow heuristic resolution” option, then “OK”.
  7. Click “Next”.
  8. Select your MCU type and frequency (again, I know…)
  9. Click “Finish” to create the project!

Setup Auto Programming

I think there’s another way to make this happen, but I couldn’t figure out how to make it program the chip.  So I did the following as well:

  1. Click “Run->Run Configurations…”.
  2. In the “Name:” box, type “Program Chip”.
  3. In the “C/C++ Application:” box, type “/usr/bin/avrdude”.  Make sure the “Connect process input & output to a terminal” is checked.
  4. Under the “Arguments” tab, type the following: “-c avrispmkii -p x128a1 -P usb -e -U flash:w:Debug/<project-name>.hex”
  5. Click “OK”.

Now at this point clicking the “Run” button on the toolbar (or its shortcut, Ctrl-F11) will program the chip.  We’re not out of the woods yet, though.  By default, a program needs root privileges to access USB devices.  So when you hit Run, it will ask you to enter your password (which will, stupidly, appear in plain text).  To make the AVR-ISP mkII programmer available to mere mortal (non-root) users, do the following:

1.  Open a terminal.  Start a text editor as root to create the file “/etc/udev/rules.d/50-usbavrispmkII.rules”.  For example:

> sudo kate /etc/udev/rules.d/50-usbavrispmkII.rules

2.  Paste the following into the editor:

SYBSYSTEM=="usb", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="users", MODE="0666"

3.  Run the following command in the terminal:

> sudo udevadm control --reload-rules

Now there’s no need to enter the password!  To recap, to build without programming hit “Ctrl-B”.  To build and program, hit “Ctrl-F11”.

That’s about all I can think of for settings I use, but if I think of anything else I’ll update the post.

An update to the post:

I found a little item I forgot.  In order for Eclipse to output a hex file (needed for the above instructions to work), you need to go to the project properties -> Settings, then check “Generate HEX file for Flash memory”.  Hit the build button again, and behold the appearance of a hex file.


A very nice feature Eclipse has is that it hyperlinks variables,  functions, and defines when you hold the Ctrl button and click.  For files within your project, it works pretty nice, but usually you already know most of those well because you wrote them.  Step 6 above allows the  indexer to look through the AVR include folder as well.  This makes any standard definition of a port, register, enum, or struct (of which there are many) easy to find.

Also, you don’t have to manage your makefiles.  Eclipse will take care of all that for you, so you just have to worry about programming.  One thing I haven’t figured out yet is how to get it to get the equivalent of  “make clean && make all && make program” happen, which I typically use when doing AVR programming.  I periodically have to use the “Clean…” menu option when things start acting strange.

As a side, make sure to check out the XMega app notes on the Atmel website, and download both the PDF and the source code.  I’ve found myself primarily using their drivers, which has really sped up getting started with this chip (even though the drivers do have their limitations).

Happy programming!  I imagine this post will be the cause of a lot of late night hacking and Mtn Dew sales …

ZephyrEye: LCD functions

11 February 2010 Leave a comment

So, how do I get all these different components to play nicely together?  Lots of time in the datasheets, browsing forums for tips, and a perpetual lack of anything better to do.  That’s because of the inherent coolness of the project, obviously, and not from lack what “y’all call da social skills“…

I’ll be going through each of the components in the chip and talk about how I interfaced them to the ATMega128 AVR microcontroller.  I’ll try to give enough detail so that someone could rewrite this in a different language if they felt like it.  Once the component interfaces have been described, I’ll go through and describe the remaining functions (menuing, GPS, games, etc.).

This handy little LCD display is pretty easy to use.  SparkFun sells them standalone as well as with a sweet little breakout board, which handles the hard to solder connector and funky backlight voltage nicely, allowing just about anybody with a spare micro lying around to use this display in their projects.  Here are some simplified pin descriptions (but remember the datasheet is the final reference) for those setting up their own display.

  • 1) V_digital: Supply voltage for internal logic circuitry.  Should be separate from V_display.
  • 2) LCD_reset: Resets the LCD.  Necessary for communications.
  • 3) DIO: Data input pin, connect to the MOSI line of your MCU’s SPI hardware.
  • 4) SCK: Serial clock input pin, connect SCK line of your MCU’s SPI hardware.
  • 5) CS: Connected to the chip select line of your MCU’s SPI hardware
  • 6) V_DSP: Display voltage.  This supply voltage is the one that actually drivers the liquid crystals, and therefore needs to be very solid.  The datasheet recommends it has its own voltage regulator, which is not always necessary (it can be tied to Vcc) but I have conceded as it reduces flickering.
  • 8 & 9) GND & LEDGND: Connect to ground.
  • 10) V_LED: White LED Backlight voltage.  +6.8V required to drive these little suckers.  I’ve used the TPS61040 boost regulator to do this, it works nicely.

Note that pin 7 is NC.  It’s also worth pointing out, since this is a battery driven project, that it’s useful to have enable lines connected to GPIO pins on your MCU.  In particular, I’ve been pleased that the +6.8V regulator can simply be turned off when the display is dormant – this saves between 40 and 60 milliamps, which can extend battery life a LOT.

BASCOM-AVR has some very nice routines to use knock-off cell phone displays with the Phillips and Epson chipsets.  However, it didn’t quite work with this particular display from SparkFun so well.  Luckily, I’d already been using this display for a while before Bascom added a library for it, and by using my init routine after calling theirs, it seemed to work out OK.  Here’s the relevant pieces of code (remember, the code can be found on the Google Code repository).

If this LCD worked directly with BASCOM, setting it up would be easy peasy:

  'Configure Display
$lib "LCD-epson.LBX"                                        'Library for LCD screen
Config Graphlcd = Color , Controlport = Porte , Cs = 5 , Rs = 6 , Scl = 3 , Sda = 4

I had to add on my custom init routine to get things to work right, as well as a few helper functions:

'Sends initialization data to LCD screen
Sub Init_lcd()
   Lcd_cs = 0

   Waitms 10

   Snd_cmd Disctl
   Snd_data &H03
   Snd_data 32
   Snd_data 12
   Snd_data &H00

   Waitms 10

   Snd_cmd Comscn
   Snd_data &H01

   Snd_cmd Oscon
   Snd_cmd Slpout

   Snd_cmd Volctr
   Snd_data 5
   Snd_data &H01

   Snd_cmd Pwrctr
   Snd_data &H0F

   Waitms 100

   Snd_cmd Disinv

   Snd_cmd Datctl
   Snd_data &H00
   Snd_data 0
   Snd_data &H01
   Snd_data &H00

   Snd_cmd Rgbset8                                          'Set up the color pallette
   Snd_data 0
   Snd_data 2
   Snd_data 4
   Snd_data 6
   Snd_data 8
   Snd_data 10
   Snd_data 12
   Snd_data 15
   Snd_data 0
   Snd_data 2
   Snd_data 4
   Snd_data 6
   Snd_data 8
   Snd_data 10
   Snd_data 12
   Snd_data 15
   Snd_data 0
   Snd_data 4
   Snd_data 9
   Snd_data 15

   Snd_cmd No_op

   Snd_cmd Paset
   Snd_data 2
   Snd_data 131

   Snd_cmd Caset
   Snd_data 0
   Snd_data 131

   Snd_cmd Ramwr

   Clr_scr 255

   Snd_cmd Dison

   Waitms 200

   For B = 0 To 140
     Snd_cmd Volup
     Waitms 2
   Next I
End Sub

Wow, I should have commented that a LOT better … bad Brad! (hitting myself with rolled up newspaper)

Here’s the helper functions.  Normally I’d just refer you to the code, but for those of you trying to get this LCD to work, using the 9-bit frame is a little tricky.  I will refer you to the code for pin definitions and constants, however.  I ended up bit-banging it – YMMV.  Be careful with the polarity and phase of the SPI signal, it’s very particular.  Lastly, note the syntax of BASCOM-AVR for addressing a bit in a byte is the dot operator (e.g. Dab.7 returns the value of the 7th bit of the byte variable Dab).

Sub Snd_data(byval Lcddata As Byte)
  Lcd_sck = 0
  Lcd_dio = 1                                               'Data = 1
  Lcd_sck = 1

  Shiftbits Lcddata
End Sub

Sub Snd_cmd(byval Lcdcmd As Byte)
  Lcd_sck = 0
  Lcd_dio = 0                                               'Commands = 0
  Lcd_sck = 1

  Shiftbits Lcdcmd
End Sub

Sub Shiftbits(byval Dab As Byte)
   Lcd_sck = 0
   Lcd_dio = Dab.7
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.6
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.5
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.4
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.3
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.2
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.1
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.0
   Lcd_sck = 1
End Sub

After that, it’s smooth sailing as all of BASCOM’s internal drawing and text display functions work just fine.  Here’s all it takes to draw the setup screen.  The “splash” picture was included in the program, and is loaded from flash program space.  Pixels are set using the Pset command.  Drawing text at certain coordinates and with a defined forecolor and background is done using the Lcdat command.

'Display Picture
W1 = 0
For Y = 2 To 80
  For X = 0 To 127
    B1 = Lookup(w1 , Splash)
    Pset X , Y , B1
    Incr W1
  Next X
Next Y

Setfont Color8x8

Lcdat 88 , 20 , "Start Game" , Black , Gray
Lcdat 96 , 20 , "Join Game" , Black , White
Lcdat 104 , 20 , "Options" , Black , White
Lcdat 112 , 20 , "Settings" , Black , White
Lcdat 120 , 20 , Unit_name , Gray , White

... (near bottom of program)

'Extra include files - Fonts
$include "color16x16.font"
$include "color8x8.font"
$include "smallfont.font"

$include "zephyreyepic.txt"

So there you have it, how to use the SparkFun LCD display.  Hopefully that helps somebody understand how to use it.

As I’ve stated before, I also hope the lengthy explanation helps get all this converted into AVR-GCC.  As a side note, I would like to develop the component libraries into a more useful place: the avr-libc-corelib project.  This would make libraries for all the components readily available for others to use.

As always, if you have any questions about using this display, feel free to leave comments or email me!

ZephyrEye: Source Code

5 February 2010 2 comments

To lead up to further descriptions about the firmware, and in order to be qualify for invitation to bodacious Silicon Valley parties, I thought it would be good to release the CAD files and code.  Everything on this project is being released under the BSD license.

The code can be found on Google Code under the project name zephyreye.  Feel free to check it out.  It will likely undergo massive changes as the code is ported to GCC, but the original BASCOM-AVR code will also remain a branch for both reference and for the BASCOM community if anyone wants to hack it up, reference the code, or continue ZephyrEye development in Basic.

If anyone does proceed working on the Basic code, it needs cleaning up and most likely a thorough overhaul as I didn’t originally plan this as a collaborative project.  There is no GCC code yet – I’ll get started on some as my other responsibilities allow.

The CAD files are in EagleCAD format.  EagleCAD is nice and handy because, even though it’s not open source, it does run natively on Linux, Windows, and even Mac.  The CAD files also need some cleanup, and in order to get a version of the ZephyrEye that actually would be usable and durable in a paintball match, there will need to be a revision change because:

  • The current hardware construction would be demolished by a direct paintball hit
  • A few of the components need to be replaced for different parts to meet the specs better.

So there you have it.  Feel free to join the project on Google Code, I think there’s a lot of potential for this fun little project.  Also feel free to branch this project if you see other uses for the hardware: cat tracker, robot remote control, whatever!

Now that the code is posted, it will be a little easier to dive into hacking into the code.  Over the next few posts I will start describe the lower level functionality to aid anyone attempting to port it, and also to help anyone looking to use these components to understand them better.

ZephyrEye: Schematics

26 January 2010 Leave a comment

So here’s the start of the design section of the project.  I’m releasing this project and related information under the BSD license.  I’m not into the viral type of Open Source licenses, but if you make a buck let me know about it cuz I’d l0ve to hear about it.  And maybe you can buy me some draft root beer … and if it’s a lot of money, maybe a Tesla

I thought I’d put one of the many logos I made for it here.  Amazing what a guy with a hamster wheel in place of right brain functionality can do with a few GiMP filters…  Well, maybe not as amazing as I think, considering I am the one with the hamster wheel brain.

Before I dive in too deeply, lemme run over the development cycle that will ensue now that I’ve got my spec:

  • Draw up a schematic
  • Lay out a circuit board (e.g., place drawings of the parts on a printed circuit board document and draw metal wires between all of the parts that need to be there).
  • Break piggy bank.
  • Send the circuit board to a “board house” to get it fabricated.
  • Purchase parts needed from online electronic component suppliers like DigiKey, SparkFun, and Mouser.
  • Assemble the parts.
  • Write the code.
  • Field test the result at various steps along the way.

I’m definitely a bottom-up developer, meaning I take the skills and parts I know well and attack the given problem with those first, and only add in new skills/parts as my existing skills/parts set prove unsatisfactory.  I’ve tried to break this habit, but it gets really cool results really fast and it’s hard to part with that (at the expense of a most likely higher quality project that might be achieved using a top-down approach).

I’ll hit you with a brief overview on the parts that I picked, and then I’ll show the schematic at the bottom:


  • ATMega128 from Atmel
  • 128KB Flash program space, 4KB RAM
  • 54 I/O pins
  • 8 ADC channels, for power monitoring and microphone reading
  • Clocked at 8MHz and powered at 3.3V (because all cool components run at 3.3V ;)
  • It’s one of the easiest microcontrollers to use these days, and ridiculously capable.
  • Programmed in BASCOM-AVR.  More on that later …


  • EM-406 GPS module from SparkFun.
  • 20 channel (e.g., can track up to 20 satellites simultaneously)
  • 5m accuracy
  • Small and works pretty standalone
  • Connects through a UART to the Mega128


  • Color LCD Nokia Knock-Off from SparkFun.
  • 128×128 Pixels
  • 4096 possible colors, but only 256 at a time in the palette
  • Not that great, but it does the job about as good as an old cell phone LCD display would

Wireless Transceiver:

  • Digi XBee Pro, also available from SparkFun among many other vendors
  • 1 mile line of sight range, 300yd urban range
  • Easy as pie.  And like Jack Handy says, “If you get the chance to choose between regular heaven and pie heaven, choose pie heaven.  It might be a joke, but if not, mmm boy!”  Mmm, XBee!
  • Flexible addressing and self-healing mesh networking capabilities


  • FM24C64 chip from Ramtron.  I’ve only found it from Mouser.
  • 64KB of high-speed, non-volatile RAM.
  • Cheap (~$3.50)
  • Used to store field and game information, along with user settings
  • Every project with small non-volatile needs should use one of these.  They’re fantastic.


  • 1100 mAh Lithium Polymer battery from SparkFun.
  • MAX1555 Li-Ion battery charger.
  • This is a pretty good and easy to use combination, and I’ve had great luck with the crazy easy to use charging circuit in the MAX1555 datasheet.

Those are at least the main parts that drive all the primary functionality of the system.   Drum roll ….


Schematic time!  I use EagleCAD from CadSoft ( for drawing schematics and laying out PCBs.  They have a free version for non-commercial use, which is great for open source and hobby stuff.  SparkFun releases EagleCAD libraries for almost all the parts they sell, which kicks development speed up to .5 past lightspeed.  Eagle is also cross-platform compatible, for all you fellow penguins out there.

ZephyrEye Schematic

Sorry for the under-impressive image on this page.  Click through to zoom in for readability.  You’ll notice I organize my schematics by net names rather than running crazy lines all over the page.  Please don’t ever make schematics like that.  Every time you make a rats nest out of nets running all over the page, a devil gets his horns.  Just don’t do it.

Instead, label the crap out of EVERYTHING.  It’s best to not leave any nets with a default net name (e.g, N$42).  You’ll notice that it’s usually fairly easy to follow the document this way, especially when you’re using a printout, PDF, or some lame JPEG on a blog instead of Eagle to view the schematic.

Rant time’s up.  Anyways, I know I messed a few things up.  I’ll make an errata list if I can remember what they are …  Also, it’s OK if you don’t have a clue what’s going on.  I’ll explain most of the connections in later posts, especially once I start talking about the software (because that’s where the pin functionalities and inter-IC signals really get defined).

Also, you may have noticed I like SparkFun (woot!).  They’ve got some great stuff that hobbyists normally can’t source, like the GPS module, LCD display, and lithium ion batteries.  They also have a lot of great tutorials for beginners, for everything from Arduino to basic soldering.  Shameless plug: buy stuff from them.  Every time you place an order, a devil gets his horns removed.  (No, I don’t work for them … that’s a pipe dream …)

Next time, on Brad’s Projects: Board Layout!  Yay!

Paintball Radar: Birth of the ZephyrEye

26 January 2010 1 comment

To my wife’s great chagrin, I like playing video games on occasion.  She equates it to the worst form of self-indulgence there is, and a complete waste of time, but it’s relaxing and I rarely (read: less often than not) let it interfere with things I’ve got to get done.  All said and done, I go through spurts where I’ll play for a few hours for a couple days in a row maybe once a month.

My favorite game is Battlefront.  Yes, the original – Upper management won’t approve expenditures on new video games so the ones I get are usually pretty old.  Woot to the stormtrooper.  Enough digression – One day I was playing and thought, “Wouldn’t it be cool to have the enemy radar in real life?”  To which I responded casually to myself, “Heck yes, it would.”

So I made one.  Loosely based off of Halo and Battlefront radar, I designed one for the only acceptable (upper management required non-lethal) recreational war I could think of: Paintball!

I toyed around with the thought of actually making a product out of it for a while.  I didn’t because paintballers I talked with just weren’t willing to part with $200 for what they considered a gimmick.  But it did give me a reason to blow several hundred dollars on something my wife would marginally approve of.  It’s all about working the system (erm, I mean, I love you honey!).

So I came up with a fancy project name, ZephyrEye, drew up a quick concept screen, and wrote up some project specs.

Hardware Specs:

  • Color LCD screen
  • Should be able to monitor ammo levels by detecting shots fired using a microphone
  • Must be hardened to survive a direct blow
  • Uses GPS for localization
  • Uses ZigBee mesh networking modules for up to 1 mile transmissions
  • Must be reprogrammable via wireless bootloader.
  • Must use an AVR processor.
  • Battery must last at least an hour.

Software Specs:

  • Both friendly and opposing players can be identified by color and/or symbol.
  • Visibility of friendly/opposing players can be user selected per game.
  • “The Walking Dead” can be identified by color/symbol (so they don’t get shot again ;)
  • Players can be “respawned” by waiting in a neutral “base” zone for a timeout period after being shot.
  • Can keep score of different styles of games: Capture the Flag, Elimination, King of the Hill, etc.
  • Players can report being hit, which removes them from play and shows others their location as they withdraw.
  • Field objects (such as bunkers, bases, field boundaries, etc.) can be programmed in, saved, and restored.

I’m sure I’m forgetting something, but that’s more or less what I set out to create.  Here’s what I came up with using a cross-platform compatible and open source 3D rendering software called Blender, with a few post-processing effects using GiMP.  I’m really not an artist, but I think it gets the point across.  I’ve never actually integrated a ZephyrEye into a hopper, but I thought it would be cool.

I should also note that while I’ve really enjoyed my paintballing experiences (heck, I went paintballing for prom one year ;), I don’t own any equipment and I don’t go very often.  So, like almost all of my inventions, it’s a solution looking for a problem (bad Brad!).  But even Sir Mix-A-Lot can’t deny the coolness factor.  It’s there, baby.

Next: Schematics and design files.  Hopefully by the third or fourth post on this topic, I’ll have some videos of the functioning prototypes (cause I still don’t have any that look decent…).