Archive

Posts Tagged ‘soldering’

ZephyrEye: Parts List

11 February 2010 2 comments

So, the stats tools on WordPress are kind of impressive … and useful at correcting idoits like me.  I’ve talked all around it, but I noticed I haven’t released an actual bill of materials and noticed quite a few people have been searching for it.  Maybe they want to build a ZephyrEye?  I’ll try to do my best to appease the masses.  It’s been quite a while since I actually built the hardware, but here it goes…

Lucky for me, and anyone else using EagleCAD, there’s a handy User Language Program (ULP) called bom.ulp that autogenerates a BOM.  It only lists items that are actually on the schematic, however, so don’t forget things: the LCD connector denotes you should also buy an LCD display.  I’ve never made that mistake though.

Partlist exported from /home/brad/Development/zephyreye/trunk/cad/ZephyrEye Rev0.2.sch at 2/11/10 1:32 PM

Qty Value Device Parts
2 LED1206 LED1, LED2
1 LIPOLY-GEN BAT1
1 PINHD-1X2 MIC
1 POWER_JACKPTH PWR
8 TAC_SWITCHPTH SW_DOWN, SW_IN, SW_LEFT, SW_OK, SW_ONOFF, SW_OUT, SW_RIGHT, SW_UP
1 .01uF C-USC0603K C5
7 .1uF C-USC0603K C3, C7, C17, C18, C21, C22, C23
2 1.5K R-US_R0603 R4, R7
1 1K R-US_R0603 R1
3 1uF CAP_POL1206 C8, C9, C12
1 2.2K R-US_R0603 R2
2 2.2uF (TANT) C-USC0603K C14, C15
1 4.7K R-US_R0603 R9
1 8MHz CRYSTAL XTAL-MCU
4 10uF CAP_POL1206 C1, C2, C6, C10
1 10uH INDUCTOR0603 L7
2 18pF C-USC0603K C19, C20
1 22K R-US_R0603 R55
2 100K R-US_R0603 R5, R54
1 100pF C-USC0603K C11
3 470 R-US_R0603 R6, R8, R16
1 470K R-US_R0603 R3
2 470pF C-USC0603K C13, C16
1 1000pF C-USC0603K C4
1 AVR_SPI_PROG AVR_SPI_PROG HDR1
1 BC108B BC108B Q1
1 DATAFLASH ATMEL_DATA_FLASH IC2
1 EM408 EM408 GPS
1 MAX1555 MAX1555 MAX1555
1 MBRA140 DIODE-DO214AC D1
1 MEGA128-A MEGA128-A IC1
2 MIC5205 V_REG_LDOSMD VR1, VR2
1 NOKIA6100_LCD NOKIA6100_LCD LCD
1 TPS61040 TPS61040 VR_LCD
1 XBEE-PRO XBEE-PRO XB1

Most of the “primary” components are from Sparkfun, with most of the passives, voltage regulators, etc. coming from Digikey.  So, on top of this list, you’ll also need:

If anybody is seriously interested in making one of these guys, let me know.  If at least 10 people are interested, I would be willing to make kits at cost (should be ~10-20% cheaper), and help those wary of the SMT soldering (for a nominal reimbursement).  Keep in mind the programming either comes from you, me, or the community and that the software has basic functionality but is not yet complete.  Also, you’ll want at least two (unless you want to use it for something other than paintball/laser tag gaming).

Note: I’ve started adding a few product links in.  As I have time, I’ll fill in the rest.  Feel free to help out in the comments if you find links to products (from SparkFun or DigiKey generally) before I do.

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.