XLAPRS Development and Internals

This page needs lots of work. Ask me questions!

New Code Update 3/2003

APRS parsing of regular stations and MIC-E is done. Still not parsing WX or messages (old code didn't, either). Moving to M12 GPS code for now, as this has been bugging me for awhile.

New Code Update 2/2003

As of Feb 2003 I am rewriting all my software in Python. C++ just got to be too much of a pain to play around with. This is my first major project in Python, so we'll see what happens. Progress so far:

• eventually: Matrix orbital LCD interface, keypad controller input stuff, revamp display code
• soon: Finish APRS parsing (this goes pretty quickly)
• 2/2003 started on APRS parsing, ported my Waypoint class w/ distance/bearing calculating code
• 1/2003 threaded TCP socket console up and working (so I can test intput w/out the keypad controller)
• 1/2003 got NMEA parsing working, figured out threading

Original Program structure

XLAPRS was originally a multi-threaded C++ application. I used the YSL libraries for container classes and thread synchronization objects. The YSLs also provide a (thin) layer over serial and TCP/IP I/O.

I created C++ classes to abstract I/O to each hardware device (GPS, displays, input devices) as well as for each display element (screens, widgets). Everything is tied together by a "router" class which tells screens when to go active/draw widgets, and ensures that only a screen with focus gets input command messages. GPS and TNC data go into a in-memory database, which maintains a tree-like structure that can store int/string/float/vector data from retreival by the graphical widgets. Another APRS management thread grabs the raw TNC data and handle parsing/storage specific to the APRS data.

The overall structure should allow for relatively painless hardware changes, including different types of GPS receivers (for example I plan to write code to talk to Motorola Oncore receivers). Substituting a different LCD display should be possible, but will cause problems because many of the graphical widgets are tuned to my display's 240x64 resolution. The display classes abstract the Matrix Orbital LCD protocol, but not the fact that it is a slow, limited LCD with specific resolution and capabilities.