Archive

Posts Tagged ‘atmega128’

ZephyrEye: Rev1 vs Rev2

11 February 2010 7 comments

OK folks, I’ve received quite a few requests so here’s what’s up with the circuit boards I have available.  They are Revision 1, and have some hardware bugs (all of which can be corrected with a scalpel, soldering iron, and a fair amount of skill).  I’d like to go through the rundown once here so everyone understands what’s up.

The plan is to get started with Revision 2 soon.  There are quite a few feature improvements that would make the ZephyrEye work a lot better, and I’d like to list them.  I’m not trying to talk anyone out of a Rev1 board, I will gladly send them (without charge but unpopulated) to anyone until I run out, but I would like to avoid anyone having false expectations of what it can do.  That being said, it will probably be at least a few months before Revision 2 is ready.

If you are thinking about building a ZephyrEye, please use this post to consider your options.  Remember, it really can’t do much of anything by itself – it only tracks other ZephyrEyes, so think in pairs.  And Rev2 is very unlikely to be backwards compatible with Rev1.

Revision 1

I feel kind of like I’m hanging out my dirty laundry, these are some pretty silly mistakes:

  • LCD connector is missing two traces, which requires hand soldering wires to this connector.
  • Traces ran too close under the LCD connector, so installing the connector requires bending the pins down at an angle and soldering them without the connector having full flush contact with the board.  This bug proudly brought to you by the autorouter.
  • An extra voltage regulator needs to get patched in for the XBee, which outdid the current supply capabilities of the original regulator.

Hardware that is still untested:

  • Microphone to ADC
  • ADC channel for voltage monitoring
  • Charging indicator from LiPoly chip

State of Software:

  • Has a bootloader for easy, wireless program updates
  • Can do simple system setup
  • Can play King of the Hill, but currently limited to 2 players (I currently only have two ZephyrEyes to play with ;)
  • Still has a few bugs, graphic artifacts, etc.
  • Still needs other games programmed into it.

I only have unpopulated circuit boards (e.g., bare as the day they were born), so it’s up to you to have the tools, AVR programmer, XBees, GPS module, and pretty much every other part if you are considering putting one of these together.  Alternately, if enough people request it and are interested, I might put together some kits.  Email me or leave a comment if interested.

Revision 2

On top of the features Revision 1 already has, I would like to add the following features.  Note that some of these are crucial to be successful in playing paintball with a ZephyrEye.

  • Clear epoxy filled case that can take direct paintball impact and other abuse
  • Capacitive touch buttons, which would enable the above feature.  These would replace the tact switch buttons for the menu, zoom, and power buttons.
  • Digital compass for heading compensation.  This way the “radar” is oriented the direction you’re facing, rather than just pointing north, which is a little confusing if you aren’t a well-oriented person.
  • Helical GPS antenna, for better reception when near other objects (like your arm, body, or hopper)
  • GPS module (or chipset) with higher sensitivity and output frequency (> 1Hz)
  • Swap out the Series 1 XBee for either a 900MHz XBee or a MeshNetics ZigBit module, which have longer range and more complete, ZigBee compliant firmware.
  • If possible, an optional external ZigBee antenna for better transmissions in, say, densely forested or urban arenas.
  • Use the newer, faster XMega256.  More peripherals, and runs at a blazing 32MHz.  She’s fast enough for you, old man.

Make sure and post comments here or join the Google Code project if you’d like to have input on what Version 2 will be able to do.

Edit: I’ve also just created a Google Group for project development discussions.  If you think you’d ever be interested in using a ZephyrEye, for paintball or other, please join the group and put your thoughts up.  Revision 2 hardware development will begin in earnest soon, so now is the time to ask for features.  I’m torn between adding a can-opener or laser pointer … surely your ideas are better.

ZephyrEye on Tom’s Hardware

9 February 2010 15 comments

Hmm, my blog hit count is going through the roof … This project must be the coolest thing ever, all your base are belong to me!

Oh wait, the stats beg to differ … Aha, the project was featured on Tom’s Hardware!  That makes sense.

I realize there’s not a lot yet – I’m still catching up!  That being said, please feel free to leave comments.  Is it cool?  Is it useful, in paintball? As a paperweight?  Let me know!  And as always, feel free to ask questions in the comments or email me at nelsobra@onid.orst.edu anytime.

For those of you coming from Tom’s Hardware, I realize the image was a bit of a letdown – my blog at the time of writing was a little short on options for them.  I’m jumping ahead of my original posting plan, but for all Tom’s geeks I thought it might be worthwhile to add a small gallery that goes through the setup screen to help understand the project a little better.

ZephyrEye: Assembly and Testing

27 January 2010 Leave a comment

So now we’re getting into the nitty gritty: time to put this sucker together!  I actually really like soldering.  It’s kind of like knitting.  You put your soldering iron on a TV tray, turn on the Price is Right and some soap operas, and make wonderful Christmas presents.

As promised, here’s the top side and bottom side of the 2-layer PCB returned from Sunstone Circuits.  I usually go without silkscreen and solder mask (the green coating on PCBs) because it’s cheaper and a little more convenient to solder patches onto.

The best way to test a new circuit board is to assemble and test one section of the circuit at a time.  Of course, I never do this.  But you should.  If you haven’t noticed so far, I have no issue using hypocrisy to control others actions.  I’ll make a great politician someday.

The alternate method that I more typically use is that I will cut traces on the board using an Xacto knife and then put a dab of solder over the cut when I get ready to test it.  Sometimes it works well, sometimes I end up doing a lot of cutting, fixing, cutting, and fixing …  kind of a Michael Scott/Jan Levinson relationship goin on with my boards, snip snap, snip snap …

On this particular project I did a blended approach of the above – I did a few things at a time, and some cutting as necessary.  The first thing you want to solder on is the voltage regulators and associated passives.  Check to make sure you get the voltages you expect with a voltmeter, because if you don’t it could be the end for any chips attached to that voltage rail.

What’s that? VR4, you say?  Where’s that on the schematic? Well, it turns out I didn’t do a great job of specing VR2.  For a while, whenever the XBee transmitted a packet, it would reset the GPS.  Undervoltage!  It couldn’t source the current needed when transmitting.  So I cut Vcc loose from the XBee and tacked on an extra LDO regulator to provide power for it since it draws more current than anything else.  This seemed to fix the problem.  Snip, snap, snip, snap…

The LCD datasheet recommends two separated 3.3V voltage rails, one shared with VCC and one for internal needs, on top of a 6.8V white LED backlight voltage.  The TPS61040 boost regulator worked great for this source.

Next I soldered on the MCU, LEDs, the XBee module, the GPS connector, and all the associated passives.  Touch bases with Starfleet Command by writing a quick program to test that the microcontroller is running.  The best test is the “blinky” test.  If you get the LED to turn on and off, you’ve got things going for you.  If you don’t get a blink or if you notice your one second toggle is actually eight seconds, check the MCU fuse bits.  Shorted crystal leads is typical if you fail to get anything, or check the “divide clock by 8” fuse bit if you get an 8-second “1-second” blink.  Alternately, check that time has not been scaled by LHC tests.

I’ll mention some about the programming, etc., but if it feels like I’m talking about it briefly, it’s because I am.  The next blog topic is programming, where I’ll dive into the programming details, fuse bits, chip communication protocols, etc.

The XBee was the first part to get going.  It’s even easier than a MAX232 chip.  Just connect the UART lines up and start sending bytes.  Whatever you get on one end, you get on all the others (at least in out of the box configuration).  So it’s really great for diagnosing problems early on.  On the other end, I’ve got another XBee chip connected to my computer through an FTDI UART-USB chip.

After I got the XBee transmitting and receiving (transceiving?), I programmed a UART based bootl0ader into the Mega128.  BASCOM-AVR provides a very easy to use and easy to modify bootloader that receives programs via XModem.  It works like a charm with only slight modifications (baud rate set to 38400).  A bootloader acts like a separate program whose sole function is to copy the main program into Flash memory.  It runs at startup, or if called from the main program, and checks to see if it is receiving the a particular byte sequence.  If yes, it does it’s thang.  If not, then it just calls the main program.  This speeds up development time a billion, because I can reprogram it anywhere.  From across the house or across the street even.  Kinda fancy, yeah?

Next, I checked reception on the GPS.  Since the Mega128 has two UARTs, I used one for XBee and one for GPS.  The GPS transmits NMEA strings, which provides localization information.  This one was pretty straightforward, just parse the GPRMC sentence to extra heading, latitude, and longitude info.  And it can be simplified if you assume it’s only used in the Northern hemisphere, which of course, I simplified.  I did add a 2.2K pullup on the GPS Enable line which helped it ride through the power dips during XBee transmission.

Last but not least, the LCD display.  This one took a little bit of soldering iron sorcery to get it to work.  I forgot (gulp!) to connect the data and clock lines on the display.  That makes it a beautiful blue PCB decoration with no function.  If you look closely at the display connector (just north of the AVR), there are two little strands of wire that pull those signals off the 0.5mm pitched (spacing from center of one pin to the next).  I soldered them to a couple of cut out vias and then soldered a strand of ribbon cable to suitable pins on the MCU.  The screens are a little fragile because of this…

Last and, since I almost forgot about it probably least, the battery and charging circuit.  The battery is an 1100 mAh Lithium polymer from SparkFun.  According to my scope, the circuit drew about 250 mA, which if the circuit was optimized to draw all the juice out of the battery, would last for four hours.  In reality, the Low Drop Out (LDO) regulators require about 0.3V about 3.3V to properly regulate, so they will source from 4.2V down to 3.6V properly, but without crunching a lot of math I should be able to get about an hour per charge.  The MAX1555 is a super simple Lithium Polymer battery charger that can charge the battery through either USB or DC power sources.  When the battery is full, it automatically goes into trickle charge mode to keep the battery topped off.  It works perty good.

I just said perty.  My redneck past is always nipping at my heels …

Anyway, the final physical appearance of the jobber looks like this, next to a couple of common objects for size comparison:

And just to make sure things would look right, I programmed in a quick and dirty static screen that represents what the game screen might look like:

Next post, we’ll dig into the firmware.