Help Build An Open Tracking And Telemetry System

Rorschach1 writes "Many /.'ers are already familliar with APRS, the Automatic Position Reporting System that's been mentioned here numerous times, most recently in the article on the Linux-powered weather balloon. It's one of the coolest things going in ham radio these days, but the APRS message protocol itself is rather hairy and bloated, and suffers from a distinct lack of extensibility. The OpenTRAC project aims to fix it, but we need your help." Read on to find out the details of what sort of help they're looking for as well as some more information about the project generally.

"For those who don't know, APRS is a messaging system used primarily on the amateur radio 2-meter band for relaying position reports, telemetry, weather data, and other such bits of information. The network has grown to the point where it can get your packets from almost anywhere in the US (and much of the rest of the world) to one of countless Internet gateways. Writing software (especially for embedded systems) for use with APRS, though, can be a real nightmare. OpenTRAC (for Open Tactical Reporting and Communications) is an open-source effort to develop an APRS-like protocol that builds on what we've learned over the past decade of APRS use, and avoids much of the ugliness of the APRS specification.

So far, though, we've got a small handful of developers working on the project. Input from people like the hackers building Linux weather balloons and such would be much appreciated. We're also in need of someone familliar with public key cryptography, particularly ECDSA. (No, the traffic won't be encrypted - only signed.) AX.25 gurus are also welcome, though the protocol isn't restricted to AX.25.

Linux and ham radio have always shared a kind of symbiosis, and I'd really like more input from the OS side. So check out the website, read the (very much in-work) specification, and let me know what you think."

Re:problems i see in their spec

[Rorschach1]

1. The SSID field is the suffix. The callsign element is based on the AX.25 address field, which also allows 6 characters with a SSID.

2. The altitude format is biased to -10,000 meters MSL - about 200 meters short of being able to handle reports from the Challenger Deep. Assuming you're able to transmit through 7 miles of seawater. =] For satellites, I think providing Keplerian elements would be more effective. AO-40 goes very quickly from hundreds of kilometers to tens of thousands of kilometers in altitude. If someone can present a good case for having extended altitude support, though, I'm all ears.

3. Driving backwards would just change the reported heading. I think reporting actual vehicle direction wouldn't be terribly practical since it'd require a separate input - either manual or a magnetic compass. Maybe there would be a need for this with ships?

4. The maidenhead grid locator is admittedly kind of redundant, and I'm considering dropping it (hence the note in red.) The spec tries to address the needs of BEACONet.25, which commonly uses maidenhead grids in its propagation reports.

5. The radio capabilities field is still being tweaked. I think it needs some more refinement to adequately represent modes in use, and things like digital PL tones.