On January 2nd, 2001 I entered the contest sponsored by:

• Specialized Systems Consultants, Inc: Publishers of Linux Journal and Embedded Linux Journal
• Tri-M Systems: Manufacturer of the MZ104 system that will be the basis for my system
• ZF Linux Devices: Manufacturer of the MachZ PC-on-a-Chip
• M-Systems: Makers of the DiskOnChip flash disk
• LynuxWorks: Creator of the BlueCat embedded Linux distribution
• O'Reilly for their book Programming Embedded Systems in C and C++

From the announcement e-mail sent out by Don Marti on 01 Feb 2001:

Neil McNeight
Napravlyeniye (it's Russian for 'direction')
mcneight@umich.edu
http://www.mcneight.org/Projects/

This project will integrate a GPS receiver and magnetic compass, as
well as a simple LCD and keypad interface to provide a basic navigation
unit. When combined with astronomical or satellite tracking software,
it can be a powerful field utility for determining the best position
for a telescope or antenna. This unit will be able to perform a
number of functions, from performing as the core of a moving map
display to providing instant tracking information for satellites and
constellations.

And here is a copy of my original application.
This contest has even made it's way to Slashdot and All Linux Devices

A weblog of my progress is now available thanks to Chris Gushue and bplog

Final Notes:

I love deadlines.
I love the whooshing sound they make as the fly by.
			--Douglas Adams

At any rate, since I wasn't capable of producing an actual working open-source product, I can at least open-source the potential secrets of my success and hope that someone else is capable of putting this all together.

First, my own theories on why this project might be successful, and why it might not. I suppose it was all started by a long-time fascination with GPS technology and the lack of GPS integration with existing software ranging from mapping programs to my telescope. GPS also has a limitation in that it can tell you where you are on the Earth, but it can't tell you which direction you are facing. It can fake it if you are moving by determining your speed and heading, but if you stand in a spot and rotate 360 degrees, the GPS will give you no other information. Combining a GPS unit with a digital compass gives location, time (also through the GPS) and direction, which is all you really need to find the location of a known object. This known object could be anything from your Aunt Iva's house to the Horsehead Nebula.

Interfacing all of that hardware, with an LCD panel and keyboard on top of it all, was going to be tricky. I figured I could combine it all in the following manner:

1. GPS: 1 serial port (4800 baud NMEA strings decoded and reformatted by the device)
2. Compass: this specific one uses a Motorola protocol called Serial Peripheral Interface (SPI). Although the MZ104 system does not have a built-in SPI port, I believe it is possible to interface to it through a normal serial port.
3. Serial Output: This would allow for interfacing to a telescope or laptop running a mapping program or any other sort of use for the device. Note that, at this point, I have run out of serial ports. I believe that Tri-M sells a carrier board for the GPS module I have that will allow it to operate as /dev/ttyS2 (COM3), but I never asked for confirmation on that.
4. LCD Display: It is possible to connect up a 20 character by 4 line LCD panel directly to the parallel port, with a couple of pins left over for input from buttons. More information is available at the LCDproc site.
5. Input: Although the parallel port would allow limited program input, another option I considered was the inclusion of a small keyboard connected to the PS/2 port. The L3 Systems WristPC keyboard was seen advertised in Linux Journal, but it was prohibitively expensive. Normal sized keyboards were considered, but their size would impact on the portability of this device.
6. Power: I hadn't completely figured out how the system was going to be powered, but some form of battery would be ideal. The ability to use the device at night in the middle of a field when looking for astronomical events was an integral part of the design.

For software, I started looking at the astronomical routines. I was prepared to write my own from scratch, but I discovered that a satellite tracking program called XEphem not only contains the astro functions I was looking for, but automatically compiles into a neat library called, ironically, libastro. If you want to write your own from scratch, I highly suggest either Astronomical Algorithms by Jean Meeus or Practical Astronomy With Your Calculator by Peter Duffett-Smith. Both books not only spell out the math behind astronomical calculations, as well as giving short code examples, but they also explain the "why" behind their methodology, especially when it comes to the precision of their results. For software to predict satellite passes, PREDICT seemed to make the most sense to me, as it is a text-based program which should require little modification to run with an LCD panel.

Other software included the LCDproc package for driving an LCD panel, and my own routines for pulling information from a GPS and processing it. The routines were written for another project I worked on, and the hardware and software requirements were completely different that those for this project, but I felt I could use the same framework here.

After obtaining the information needed and making the calculations, formatting for output to a serial connection would be trivial, whether it was NMEA 0183 output (official documentation is costly, but some have published the specs online) or Meade LX200 (also well documented). There are also smaller projects such as this homebrew antenna controller

The reasons that I discovered along the way for the potential lack of success for this project included too much power in the wrong places and existing competing products. The MZ104 is a great general-purpose embedded system, but I believe that my design calls for a system with a lot of I/O and not a lot of horsepower. Lower cost embedded systems such as the Rabbit 2000, Atmel AVR, some form of Motorola HC11 or even the uCsimm or uCdimm platforms from Lineo would probably be a more appropriate choice for this particular project.

Also, although no one single device combines all of this functionality, modern consumer devices are approaching the ideas presented in this project. For example, Celestron sells a line of computer guided telescopes with an integrated GPS receiver. Garmin makes handheld GPS units (the eTrex Summit and eTrex Vista) which combine a GPS recieiver with a digital compass and even a barometer for more accurate altitude readings. They also interface with a standard serial port, and can store topographical maps internally for display later on their LCD screens.

In conclusion, I would like to thank Embedded Linux Journal and all of the other sponsors for their goodies and their time. Although I obviously could have done more with this project, it has certainly been a learning experience for me. And though this design might never see the light of day, I am already thinking of broader and more powerful uses for the MZ104 and embedded Linux.