XLAPRS

Update Feb 2003

I recently started reworking the entire codebase and my hardware setup -- see the links
on the right for the new hardware and software re-write info.

XLAPRS is an APRS implementation for mobile Linux computers. The name is pronounced
like slappers, a combination of the last two letters of my ham radio callsign
and APRS. If you don't know what APRS is, search on google and then come back here.
The rest of this web site assumes that you understand what APRS is about; I don't want
to spend my time writing what would turn out to be an inferior APRS tutorial.

XLAPRS provides an interface
similar to the HamHUD, but I use a bigger
display and a real CPU/OS instead of a microcontroller. This lets me do all sorts of
neats things in software that neither the HamHUD nor the commercially-available
Kenwood TM-D700 can do. The keypad interface on the matrix orbital LCD makes for an
easy connection of a 6-button controller built out of simple pushbutton switches, for
up/down/left/right/enter/escape functionality.

Motivating forces

I created XLAPRS after having owned a Kenwood TM-D700 for about two years (yes, I
bought one when they first came out!) The radio served me well as an introduction to
APRS and GPS -- I ran the radio for months before I even had a GPS receiver. However,
after about a year of mobile use the Kenwood's weaknesses started to show through. I
also discovered what I liked most about APRS, and why the d700's software wasn't
really set up to give me the information that I found interesting.

What I like to do with APRS is perhaps different from what others do with it. I use
APRS in two contexts: First, just to entertain me while driving around. It's operating
ham radio without having to make smalltalk with strangers. While on the road, I like to
be able to find interesting APRS stations around me and look at what's happening on the
network. This includes asking questions like: "Where are the local digis?", or "What
nearby stations are mobile?"
The second way I use APRS is at public service events. The only one of these I
regularly participate in is the Wildflower Triathlon, for
which communications is provided by W6BHZ
Cal Poly Amateur Raio Club. After two years with a Kenwood d700, I decided
that there had to be something better.

The Kenwood d700 is a neat radio, but it's limited by its software. Here are the
main shortcomings I've found after two years of use:

Staion detail shortcomings:

Small compass rose graphic is nearly useless

Incoming GPRMC packet overwrites info from GPGGA packet

Won't show mobile station's altitude simultaneously with course/speed

List of stations can only be shown in order of packet arrival time

No provisions for filtering stations other than fixed distance

Distance filtering removes station data rather than simply hiding it

Inadequate display of NMEA/GPS data, slow display updating

Neither hackable nor upgradable :)

To its credit, the d700 does support the APRS spec quite well, including good
handling of APRS messenging, object reports,

Okay, so build a HamHUD and solve all these
problems, right? Not for me. There are lots of neat things about the HamHUD, like
SmartBeaconing
(invented by Tony Arnerich KD7TA and Steve Bragg KA9MVA), and the digimeter
. But there are things I don't like, too:

Static display format -- certain info always appears on line 1, no provisions
for switching to different views of the data, etc. This goes back to the problem of
being microcontroller-based! Good user interfaces are just really hard to do when
you're limited to a tiny CPU and code space.
Tha HamHUD is a neat project and has had a lot of work put into it. What it comes
down to thought is that it's just not my style. I'm a software guy. I know unix,
programming languages, object-oriented design, that sort of thing. When I'm hacking
my APRS, I want a command line and a full-blown CPU because it's more fun that way.
XLAPRs isn't a purpose-build APRS machine. It's a mobile computing platform for me
to experiement with. APRS funcationality is just what I'm playing with on it right now.

Although XLAPRS is functional, it still has some rough edges. Here are the
features that I believe set it apart from other APRS implementations currently
out there: