The C source code that I have written so far is for a "come home" feature, so there is only one waypoint. My intent is that this platform is for do-it-yourselfers to extend the firmware for features that they want, such as multiple waypoints. This would not be hard to do, since you would not have to change any of the interrupt drivers that handle tasks like generating pulses for the servos or communicating with the GPS. All you would have to do is extend the navigation routine.
As far as loading the waypoints, you could do this prior to launch either through a PIC debugger, or by writing your own command interface that would communicate through the spare serial link on the board.
Off the top of my head I cannot give you a complete answer. I will tell you what I know right now and get back to you with a more definitive answer.
The self test software and the "gentleNav" navigation software that I wrote for the board were developed using and EM406A SiRFIII, available from SparkFun for $59.95. If you have one of those, you can plug it into the board running my firmware and everything will work fine. That would be my recommendation.
You also should be able to interface with any of the other SiRFIII GPS radios if they have the same connector as the EM406A.
The board has a spare UART, so you could also work out a way to connect to it, and modify the firmware to use the spare UART.
The firmware expects the GPS to be running at 4800 baud, but it would be a very simple matter to change it to a different baud rate, all you have to do is load a different constant into the baud rate generator register.
I must say I like the idea of a 5Hz refresh rate, so as soon as I have some time, I will take a closer look at the LS2003X and get back to you with a better answer.
What you have achieved here is incredible!
Sure, it's been done before... but not in civilian laboratories.
Back in the 1980's, I was tasked to build a 3 axis IMU from the existing Copperhead missiles' roll rate sensor.
The unit had a Coriolis effect rate sensor and an accelerometer for each axis. The mission was to provide data to a flight controller for an ejection seat system, controlling a gimbal mounted rocket motor for propulsion.
The unit was able to turn on and provide calibrated data within 140 mS. It had a maximum angular rate of 3000 degrees per second and an acceleration limit of > 2000 G. However, the unit was 4" cubed and weighed ~ 1.8 pounds. It consumed ~ 5 watts of electrical power!!!
I have checked out your test-code and I would like to use this board to test autonomous flight. You mention that you have written a come home feature. Does this mean that you have stabilization code that I could take a look at as well ?
I am writing the documentation to go along with the stabilization code as we speak. It should be available on this website in a few weeks. It will cover how the code works, how to integrate it into an electric sailplane, and how to use it.
By the way, anyone who tries out the stabilization code on their board should be aware of the following: The test-code that comes with the board uses the NMEA interface to the GPS. The stabilization code uses the binary interface, and issues an NMEA command to switch to binary. At that point the LED on the GPS will stop blinking. Don't worry, nothing is broken, its just that the LED only blinks for the NMEA interface.
If you go back and reload the self-test code immediately after running the stabilization code, the GPS will not switch back to NMEA, because it ignores the messages in the self-test code, because they are in NMEA format! I think if you wait long enough, the GPS will eventually default back to NMEA, but I don't know for sure, I've never waited long enough.
In any case, if you want to switch back to NMEA after switching to binary, you will have to issue a command in binary. I plan to cover the issue in more detail in the documentation that I am writing.