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."

Comments

problems i see in their spec

[Phork]

I see several things in their specification doc that i consider problems, well maybe not problems, but at least short commings.

1. call sign is only 6 bytes, therefore 6 ascii chars, my call sign is 6 ascii chars, so if i have more than 1 station i can not put a suffix on them to differentiate between them, also i think in some foreign countries the lowest class liscense may get assigned more than 6 char calls.
2. altitute is an unsigned 24 bit value, in my opinion it should be 32 bit signed, because sometimes people opperate from death valley, and some satelites and space stations will want to have stations if this catches on(there are sattelites more than 167 km up, right?).
3. speed should proably be velocity, not speed, because sometimes people drive backwards(this is already noted in the spec)
4. I think having fields for both grid square and absolute locate(lattitude and longitude) is a littl eredundant, unless only one of them is used, because grid square can be determined by the receiver from the absolute position
5. the maximum freq that can be sent is 42ghz, arent there people doing 40ghz work now?(ok, this is proably irrelavent)
6. 
   But really, it looks like a great spec, good work guys.