In case you’ve noticed, my last few posts have not been about the ZephyrEye. Not to fear – ZephyrEye is alive and well! Boards should be readily available soon. So for everyone out there interested in hacking together some Battlefront radar screens with your paintball/laser tag buddies, it is coming shortly. Of course, if you can’t wait, feel free to grab the schematics and spin your own PCB ;)
So what the heck have I been posting about? As I mentioned previously, I’m taking a Mechatronics course where we have to build a checker playing robot. Here’s a conceptual animation for the design that my team and I came up with:
I used Blender3D to animate this video. I’ve found with several of my robotics projects that most people get confused when I try to describe it. By making a rough 3D sketch and animating the intended functionality, I’ve been able to talk with people much more effectively and get faster and better feedback about what will or won’t work. It also helps me get several jumbled and mixed together concepts in my head down to a single, better defined concept. If you’re planning on doing robotics, especially if you’re working on it from an electronics point of view, I’d highly recommend learning a 3D sketching system. But I digress…
So this checker playing robot needs to be able to play checkers completely autonomously. Most teams used either a stationary robotic arm or gantry style approach. I’ve never been a big fan of either, in fact, I’m pretty enamored with the concept of small autonomous mobile robots. A big reason for this is the ability to quickly apply swarm concepts to these robots if you build a few up, which is something I always toy around with in the back of my head but never do.
Here’s some of the primary system components and a simple description of each of them:
- XMega256: Pretty powerful little chip. I both appreciate this chip and its potential, and at the same time can’t believe how long the errata list is. It’s pretty bad, but fortunately I haven’t run into too much trouble yet. I’ll be using this for all of the checker-playing AI, computer vision, and localization tasks. Yep, you heard me: computer vision on an AVR!
- C328: OK, so the computer vision isn’t as hard as it could be – the COMedia C328 is a pretty easy to use (relatively speaking) UART camera. The datasheet sucks, and it looks like it’s being discontinued. I’m sure other similar parts will crop up soon, though. I’ve been reading in raw 565 RGB images into the XMega RAM and finding color blobs with it. I can also transmit a JPEG to a computer via XBee.
- XBee: I use these for just about everything. I usually write up a debug interface between the computer terminal and the robot so I can debug very quickly, and portably – it’s just as easy to debug and control from my desktop as it is my laptop, making presentations a lot easier.
- Servos: We went with servos for motor control. As my other posts have alluded, I’m using some hacked for continuous rotation, and instead of controlling position I’m controlling their speed with a standard servo signal. To maintain balance (I didn’t want to go down the inverted pendulum road…), the bot also has a servo with a “propeller” mounted in front. The propeller slides over checkers as the bot goes forward and backwards, but rotates when the bot turns to avoid strafing the board and moving checker pieces all over the place.
- IR Sensors: There’s a bank of 6 IR emitter/detector pairs on the front of the bot. These are used to detect where the bot is at on the checkerboard. By monitoring the difference between when a left and IR detectors hit a checker square, you can also correct and maintain orientation so you don’t knock checkers all over the board.
- Odometer Sensors: More IR sensors, this time the QRE1113 reflectance sensors. These sensors monitor a band of alternating light/dark colors on the inside of the wheel, so every time the wheel moves a certain distance, the XMega gets a “tick” that’s worth a certain distance.
- Chassis: A benefit of being in school, I have access to 3D printers that can take certain CAD files and actually “print” 3D objects in ABS plastic. We used this for the chassis, which put all of our servo mounts, sensor mounts, and other typically difficult-to-make-precise-on-prototype features a lot more accurate. It cost about $30 – not bad for what we get.
That’s the general idea. Here’s a picture of where it’s at right now:
Here’s hoping that I get it done in time! I don’t think it’ll get done in 12 parsecs, but that’s a measurement of space and not time anyway …
Thought I would blog about hacking the 9g servos from SparkFun and converting them to continuous rotation since I’m performing said hack for an upcoming project. I’m sure there are more and better instructions on how to do this, but I’ve looked at tutorials before for larger servos and noticed these little guys are a bit different.
What I’m doing is changing a servo that normally has around 90-120 degrees of motion to have full 360 continuous rotation. Instead of the servo reacting to the standard PWM signal as a position signal, it will now act as a velocity signal with full forward/stop/reverse control! Best of all, when people tell you the servos on your YT-1300 look like a piece of junk, you can tell them you’ve made a few special modifications yourself.
Apology in advance for the images – I promise to never use my cell phone cam for blogging again! It’s abysmally unfit for close up pictures of electronics.
Take the servo apart
Remove the sticky label (goo-be-gone is needed) and remove the screws. You’ll likely need a jewelry screw driver. Pull all three sections apart, remove the gears, and remove the white plastic cover over the potentiometer. Easy peasy.
Cut out the stops
I’m running on memory, so feel free to correct me in comments if I’m wrong. I recall this as the part that’s different from the standard sized servos. There are stops on the potentiometer and you practically have to cut out half of the pot to get it to rotate properly. This is because the pot shaft is used as the axis for the gears and external drive shaft. Boo to the man that designed it this way, unless it made it significantly cheaper. In that case, yay… but boo.
Warning: The plastic on the pot is EXTREMELY brittle. If the pot case crumbles, your servo is trashed.
Proceeding onward. You’ll see two plastic stops in the pot – cut it out in small pieces. Once that’s gone, you’ve got to remove the potwiper. The copper-colored middle terminal of the pot should come out with a little force at this point. There are a couple of “C” shaped metal tabs that will come out with it. Now cut the entire terminal off and leave the wire hanging for now.
On one of my servos, I cut it out without pulling the shaft out. On another, the shaft hole cracked cand the whole shaft came out which made this easier – but I’ll have to report later as to whether it still works well or not.
You also need to cut out the springy piece. You can’t remove it completely, it appears to be connected with the shaft itself, so you’ll need to cut it flush against the remaining metal flange.
The final stop that has to be cut is on the actual case, just inside the hole where the shaft exits the case. Flush cutters make quick work of this, but an Xacto knife could probably work too.
Solder resistors in place of pot
So that the potentiometer has a reference point for its control loop, we need to solder resistors in place of the pot. I used two 10K resistors, which will make the signal that would have centered the servo be the stop position. Positions signals right from the signal will be forward, and positions left from the signal will be reverse.
Solder the two 10K resistors (surface mount or 1/8W or smaller should fit) in series between the two remaining posts. Then solder the currently-floating middle terminal wire in between the two resistors.
Put the servo back together
Pretty straightforward. Do step one in reverse. The gears may feel like a puzzle, but there’s only one way they fit. Lastly, be careful with the screws – they strip out pretty easy.
Shazaam! Full control of a motor with great torque/gear ratio with only a half hour’s worth of effort.
There are a few inevitable truths in this world. Taxes will rise, Wookies shed all over the furniture, Luke and Leia are related, and there is no such thing as a perfect first draft schematic.
The Rev2 circuit is nearly complete. It looks AMAZING if I do say so myself. That’s the problem, though: I’m inundated with excitement and therefore am unable to find things that are wrong because I don’t want to find any reason that might delay getting the circuit boards back as soon as possible.
I’m calling out for a few extra set of eyes to look over the schematic If anyone could please go to the Google code, download the Eagle CAD files and take a look, I’d really appreciate it. If you want to make changes, let me know so I can arrange for them to be merged back in properly. Even if you’ve never looked at schematics before, take a look and as always, feel free to ask what’s going on in the comments.
This is also a great chance to give suggestions on functionality. I should add, it may be your LAST chance! Please give some comments if you think you might ever build one, if nothing else just to say you think it works for what you’d like to use it for.
If you’re not familiar with CAD schematics and circuit board layouts, it might be interesting to look at the history of the .sch and .brd files in the Google Code repository. By looking at older revisions, you can see the steps taken along the way chronologically. I commit changes at least at the end of almost every day I work on the project.
The current Bill of Materials can also be found at this Google Docs spreadsheet. It includes estimated pricing – it currently comes in at just under $200. A little bit higher than I was hoping, but about the same cost as Rev1 and Chuck Norris (adverbicized) packed with new extra features!
The schematic is hopefully organized well enough for someone not intimately familiar with this project to try and understand one section of the schematic at a time. The capacitive touch schematic is separate, because it will be a separate board. The way it works is you put copper pads on the board, glue it to the inside of your enclosure, and it senses you touching it on the outside of the enclosure. Pretty nifty, and a great way to avoid milling the enclosure.
Please post comments below, or add to the Google Groups discussion page.
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.
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.
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.
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
|8||TAC_SWITCHPTH||SW_DOWN, SW_IN, SW_LEFT, SW_OK, SW_ONOFF, SW_OUT, SW_RIGHT, SW_UP|
|7||.1uF||C-USC0603K||C3, C7, C17, C18, C21, C22, C23|
|3||1uF||CAP_POL1206||C8, C9, C12|
|2||2.2uF (TANT)||C-USC0603K||C14, C15|
|4||10uF||CAP_POL1206||C1, C2, C6, C10|
|3||470||R-US_R0603||R6, R8, R16|
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:
- Case: Pac-Tec PP Enclosure
- 1/16″ Acrylic, available from local hobby shop
- LCD connector
- EM408 GPS module connector
- 2mm headers for the XBee
- An extra 500mA rated LDO regulator for the GPS.
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.
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 'RED Snd_data 0 Snd_data 2 Snd_data 4 Snd_data 6 Snd_data 8 Snd_data 10 Snd_data 12 Snd_data 15 'GREEN Snd_data 0 Snd_data 2 Snd_data 4 Snd_data 6 Snd_data 8 Snd_data 10 Snd_data 12 Snd_data 15 'BLUE 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!
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.