Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Hardware

Help Build An Open Tracking And Telemetry System 23

Posted by timothy from the neat-stuff-wants-your-help dept.
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."
This discussion has been archived. No new comments can be posted.

Help Build An Open Tracking And Telemetry System More

Help Build An Open Tracking And Telemetry System

Comments Filter:

  • problems i see in their spec (Score:3, Insightful)

    by Phork ( 74706 ) on Tuesday February 25, 2003 @12:16AM (#5376433) Homepage
    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 (Score:4, Informative)

      by Rorschach1 ( 174480 ) on Tuesday February 25, 2003 @12:42AM (#5376572) Homepage
      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.

      • While AX.25 is (short sightedly) limited to 6 ASCII characters for the callsign field, could not OpenTRAC extend that to say at least 10, perhaps 12 characters? Imagine at least being able to embed a reciprocal operator's callsign into the position reports.

        For example, VE5/KA0RNY sucks up 10 characters right there. I'm sure somebody would try something silly like W0/VE5ABC/M. I think 12 characters would be a useful extension to the AX.25 limit. It would also provide space for more descriptive station identifiers.

  • This is a good move! (Score:3, Interesting)

    by n1ywb ( 555767 ) on Tuesday February 25, 2003 @01:06PM (#5379640) Homepage Journal
    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.
    • I think the key to OpenTRAC's success is how well it supports and integrates the current APRS protocol. Backward compatibility is a nasty fact of life.

      I haven't had time to read the spec closely and I'm not well up on APRS, although I have a weather station ready to hook up to Xastir whenever I get an RF path out of here, so I may be out of line thinking that this protocol intends to replace rather than extend and fix the broken parts of APRS.

    • I believe what killed packet (or, if you prefer, what caused packet not to take off more than it has) is the fact that most hams confuse buad and bits per second.

      The FCC part 97 spec allows for 19.2 kBaud on 2 meters and 56 kBaud on 440MHz. The problem with using 440MHz is propagation - 440 doesn't go as far under normal conditions as 2 meters, so as a result if you want a wide area network you tend to want to use 2 meters so as to have fewer nodes.

      Now, back in the days when I was active in packet, telephone modems were anywhere from 2400 bit per second to 9600 bit per second, and packet was 1200 bit per second. With overhead, collisions, and the fact that packet is a simplex system, you had an effective throughput closer to 300 bits per second. However, that wasn't ENORMOUSLY slower than landline modems, and the fact that you weren't tying up your phone line would offset that.

      However, with the average telephone modem today delivering between 22kBit/sec to 56kBit/sec, and with broadband delivering between 128 kBit/sec to 3MBit/sec, the gulf between packet and modems is just too large to use packet for anything other than APRS, short text messaging, and other very small files like that.

      However, what if you could have a 2 meter packet system that moved a peak of, say, 38.4kBit/sec, so that with overhead+collisions+simplex gave you 9600 bit/sec real throughput. Now, that is within spitting distance of phone modems.

      "But you cannot do 38.4 kBit/sec on 2 meters - the FCC says so!" Wrong - I cannot do 38.4 kBaud on 2 meters.

      But if I use C4FM (4 level FM signaling), I have 2 bits per symbol. A Baud is a symbol per second. At 9600 Baud, and 2 bits/symbol, that gives me 19.2 kBit/sec. Go to 16QAM, and I have 4 bits per symbol, or 38.4 kBit/sec at 9600Baud.

Slashdot Top Deals

BLISS is ignorance.

Close