19 February 2010

Work and FIRST Robotics

    Not much new has happened since my last post. I've been very busy at work and I've been volunteering for the FIRST robotics competition. My team, Rolling Thunder Robotics, is almost finished assembling our robot. We have one last night of building before the scrimmage Saturday morning. Being a FIRST mentor has been great and I encourage anyone who is interested to join in. You don't need to know anything about robots to help, but most of the work is about designing and building a robot...mechanical things seem to be the stumbling point for most teams. www.usfirst.org
    With my excuses and public service announcements out of the way it's on to some firmware! As I've mentioned before I decided to use Atmel's ATmega128 microcontroller for this project. There are actually two of them (one for the GPS and cellular module and one for the temp, pressure, acceleration, and rotation sensors). I could have gotten away with just one, but they're cheap and I have room to expand this way. Each micro will have an SD card with a FAT32 file system for data logging. It's somewhat scary using file systems for the first time, but you'll find it can be very easy! I've found a pre-made FAT32 library for AVR's from Dharmanitech (www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html). It is written with the ATmega32 in mind, but it's easy enough to change the UART and SPI definitions for use with any AVR. I highly recommend running the example project before trying to modify it. Since the code is a little bit hard to follow it will give you a much better idea of how it works. Below are some pointers on how to get your custom version up and running.

SD FAT32 Initialization:
You must run the following functions to setup communications and the FAT32 tables:
  • spi_init()
  • SD_init()
  • getBootSectorData()
SD FAT32 File Operations:
Reading, writing, and deleting files is as easy as calling a function...
  • readFile(READ, fileName)
    • fileName is a null terminated string containing the name of the file and the extension
    • the output is sent to whatever UART port is defined in the UART_routines.h file
  • writeFile(fileName, dataString)
    • fileName is a null terminated string containing the name of the file and the extension
    • dataString is the text to write to the file terminated by the '~' character
    • this function will append dataString to a file if it already exists or create the file if it doesn't
  • deleteFile(fileName)
    • fileName is a null terminated string containing the name of the file and the extension
!!!!BUG REPORT!!!!
    I found a bug in the SD FAT32 library that really made me scratch my head for a while. The problem happens when you use the readFile, writeFile, or deleteFile functions with the file name entered directly.

e.g. writeFile("Test.txt", data);

    Inside these functions the file name gets expanded to a format that is expected by the FAT32 file system. This format is 13 bytes long. If your file name is shorter than 12 characters you will overwrite whatever data is in memory behind the fileName variable used by these functions... The fix is pretty easy and hopefully it will be integrated into the library for the next update. Follow the steps below and you're all set until then!

In FAT32.c:
1. Place this code at the top of convertFileName:
int j=0, k;

// Copy the file name to a large buffer so memory isn't corrupted by the convertFileName function
while((fileName[j] != 0) && (j<16))
{
FName[j] = fileName[j];
j++;
}
FName[j] = 0;
j=0;

2. In the writeFile function change "dir->name[j] = fileName[j];" to "dir->name[j] = FName[j];"

3. In the readFile function change "dir = findFiles(GET_FILE, fileName); //get the file location" to dir = findFiles(GET_FILE, FName); //get the file location"

4. In the deleteFile function change "findFiles(DELETE, fileName);" to "findFiles(DELETE, FName);"

In FAT32.h:
1. Place this variable declaration with the other global variables:
volatile char FName[16];

12 February 2010

D.C. Blizzard of 2010

    I'm finally back to work after 4 days of online training from home. I don't particularly enjoy giving up my time to work for someone else, but today I'm actually happy to get away from my apartment and do something other than stare at a computer screen. The blizzard of 2010 was very unspectacular to me, but there were 40 MPH winds and about 1.5 feet of snow. The biggest problem I see is that the roads and parking lots here weren't designed with snow in mind. For that matter they weren't even really designed with cars in mind...they are really meant for horses... Since the snowplows have nowhere to push the snow to most people just have to wait for it to melt before they can drive anywhere.
    Now on to the important stuff! I did not make any progress with being able to program the microcontrollers on my board. I actually have no idea what the problem is. I checked proper voltages, the programming connections, clock sources, part numbers, and my sanity several times. Nothing seems to work, but there is another way. The plan is to work with my STK600 to develop the code as best I can and use it to program the chips through a ZIF socket. Then I can solder the programmed chips onto the board and see if the program runs as expected. I was smart enough to bring UART connections to some headers for debugging purposes so it will be easy to verify that my programs and circuits work. This is definitely not an ideal situation, but it will save me from spending more money on redesigning the balloon board.
    I have also enlisted the help of my friend Arhan to create a tracking application for the balloon's flight. The idea so far is to send periodic SMS messages from the balloon to a second cellular module connected to a laptop. The laptop will take in the SMS messages over USB and plot GPS coordinates, altitude, speed, etc. I have not tested any of my antenna ideas yet, so I don't know if we will achieve constant communication, but any time the balloon is below 30,000 feet we will be able to track it. I'm really only concerned about knowing where it lands. All the data collected during the flight will be stored on SD cards on the payload so we can always reconstruct the flight if we can recover the payload. See you next time space cowboys!

05 February 2010

PCB's are in!!!

    The circuit boards are in and I've partially assembled them. The weather forecast is predicting a top 10 worst snow storm for the D.C. area. I was sent home early from work because of the paranoia. Having grown up in Montana I'm not scared by any amount of snow. Let's see how the weather was when I started the assembly...
 

    Below you can see the circuit board, my soldering iron, and some bread. Bread...never solder without it! Seeing as my kitchen counter tops are the only solder resistant surfaces in the apartment that's where I decided to work. I've decided to put on the two ATmega128 micros, their crystals, and the programming headers. With those components on the board I should be able to load a program into the micros and set the fuses to use the external crystals.
 


     When I hooked the board up to my STK600 for programming I couldn't get a connection. I checked through the schematics, took some measurements with my multimeter, and retried several times. Since I had no luck there I decided the STK600 may not be providing enough power through the ISP cable so I soldered on the regulators and battery connector. I connected the battery and measured all the voltage rails. Everything looked good, so I tried the programming again... Still no luck. My thoughts now are that the micros have not been completely soldered to the board. Since they are the QFN style package with a very tiny bit of pin showing it is extremely hard to solder properly. Seeing as I don't have a microscope it's even harder. I may wait until Monday and use the hot air rework station at work...after hours of course.
    Now, about four hours after I started assembling and pretty close to when my work day should have ended...

     This tiny amount of snow wouldn't have stopped even the most timid of D.C. drivers, but I'm happy to have an early Friday off so I could work on the balloon computer and share the progress with you. Maybe tomorrow will include a revelation on my microcontroller programming problems.

02 February 2010

The VectorNav VN-100

    VectorNav is currently a one product company. That is music to my ears when it comes to electronics. It means I will most likely get fantastic support and a great quality product from a small company that will treat me like royalty. I haven't actually had to ask for help on this module yet, so I couldn't say for sure on the support. The module is a great piece of design and functionality though. In the space of a large postage stamp (it even has the castellations like a stamp would have) VectorNav has managed to cram in three axis of accelerometer, three axis of gyro, and three axis of magnetometer. The best part is that the on-board processing power takes care of all the analog, fills up some well defined registers, and lets you choose between reading the registers manually or getting NMEA formatted sentences automatically.


    Probably the most useful part of this module is the ability to get an accurate yaw/pitch/roll in degrees with zero work. The module reads its sensors and computes the angles for you. There is also the ability to upload the current magnetic map of your area, just in case the government finally created that machine that stops the Earth's core from spinning. The Russians are also trying to steal the magnetic north pole by quietly moving it towards themselves about 40 miles per year*. There is a fantastic development kit that allows RS-232, USB, or your own hand soldered connections to the module. The software that comes with it will give you all the sensor data and display real-time 3D rotating version of the board.
    I plan on using this sensor to measure my heading and also test the effectiveness of a small gyro placed inside the capsule to keep it from spinning like so many other balloon projects have. It's not very fun to look at blurred pictures of the landscape whizzing past because your capsule won't stay still. The other key component of this will be a rotatable clip to attach the balloon to the capsule. Something like those plastic key chains with the stretchy coiled cord should work. Now, why do I really need to know my heading....something to do with the circular shaped PCB no doubt.


* The Russians are not actually attempting to steal the magnetic north pole. It is a natural phenomenon that has been observed to happen in geologic studies several times over Earth's history. In fact many believe that the magnetic poles will flip sometime in the near future based on those geologic records.

01 February 2010

The Printed Circuit Board (PCB)

I finished the schematic capture and PCB layout about a week ago and finally my PCB is being manufactured! I did the design using Altium Designer. It's an easy to use tool that is almost as powerful as the industry leader, Cadence. It also costs much much less than Cadence. The quote for my PCB came in at $650 for two boards on a 10 day build schedule. The component cost came in at about $200, but I am reusing some parts from previous projects like the GM862 and some SD memory cards. You can enjoy some PCB pron below and I'll be sure to take pictures during the assembly of the real board when it comes in. Does this circular shape allude to some devious plan that I have for my payload capsule?