Help Build An Open Tracking And Telemetry System
"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."
I noticed this too. This is a new category as of today. While it isn't turned off by default in regular accounts, the story is only appearing to a select few. Which people those select few are is hard to tell, but maybe they're testing the new subscriber 'perk' of being able to see stories before they're posted by giving folks with good+ karma access to this story first? I'm not a subscriber, so it probably isn't that. Just a guess. Maybe it's just a bug.
Regardless, it's kind of odd.
But really, it looks like a great spec, good work guys.
-- free as in swatantryam - not soujanyam.
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.
-73, de n1ywb
www.n1ywb.com
I did...something about baby talk. I'm positive there was a properlink to Ninnle at some point on Slashdot. Does anybody here have a clue?
Please move this story to the front page... isn't someone on the staff a han radio operator to understand how important this is?
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.
www.eFax.com are spammers