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.

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.

This is a good move!

[n1ywb]

I LOVE APRS. Bob was a real visionary to come up with it when he did and make it so popular. We all owe him a debt.

I have some problems with APRS though. Bob is the sole copyright holder. The protocol hasn't gotten much attention lately. There isn't much free APRS software (other than XASTIR which rules), and Bob maintains DosAPRS as the reference implementation (ugh dos).

I would like to begin supporting OpenTRAC. I currently run an APRS digipeater in Randolph Vermont. So has anybody written a libax25 based OpenTRAC repeater yet? If not it's something I may find time to do someday. If OpenTRAC is to get off the ground, it needs to receive a groundswell of support. Otherwise it's likely to wind up on the isle of misfit protocols.

The real problem is that APRS, with all of it's shortcomings, is now FIRMLY entrenched in the amateur community. I know hams that refuse to operate anything but morse code on a separate vacuum tube transmitter and receiver. Nothing EVER goes away in ham radio. This is why it's so hard to get anything NEW going in hamming, everyone is always so stuck in a rut. I swear the only thing that's ever gone away in ham radio is spark-gap transmitters and that was only because you could get killed for operating one. Shit, nobody operates packet over 1200 baud. How backward is that? Are we going to STILL be using 1200/2400hz FSK in 10 years? Probably. God damn it... */rant*

There are several radios and TNCs on the market with built-in APRS support. There are APRS applications for nearly every modern OS. There is a world-wide network of APRS digipeaters, backbones, and internet gateways. At a minimum, OpenTRAC will have to be able to operate on the same channel as APRS without confusing existing APRS equipment. If we show enough support for it, we can cajole the manufacturers into supporting it.

That's assuming it's worth supporting. I haven't read the spec yet. But I will. And if it looks good, I'll support it.