Archive

Posts Tagged ‘testing’

ZephyrEye Video

5 February 2010 Leave a comment

I found some old video I took of the ZephyrEye.   I originally threw it out because it’s blurrier than Han Solo’s post carbon freezing vision, but I’ve annotated it heavily so you’ll get the gist. One of these days I’ll get a hold of a decent camera so I can take a decent video … it’s almost impossible to force a cheap one to focus on the LCD display outdoors well enough to be able to read what’s on it.

Here’s another video, showing just the game setup process.

As always, if anyone has any questions about this project or even just about how to use any of the components I used on this project, feel free to leave a comment or email me!

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.