Home

XLAPRS

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:

  • Microcontroller-based: no trig for great-circle calcs, limited code space
  • Tiny LCD display -- 20x4 chars doesn't seem like much
  • Monolithic box construction -- brains, display, and UI all crammed together
  • 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:

  • Nice big 240x64 graphical display
  • Keypad separately cabled from display
  • Excellent station filtering & display sort capability
  • Ample CPU power: real-time sorting, great circle distance/bearing are no problem
  • My todo list:
  • Save config changes to the flash card
  • APRS messenging support
  • WX station decoding & display
  • Basic waypoint-to-waypoint navigation (APRS stations, arbitrary points as waypoints)
  • Eventually add a graphical map