[aprssig] OpenTRAC (was: Re: New IGate Operator)
spam8mybrain at yahoo.com
Thu Jan 5 12:32:57 CST 2017
I wonder if anyone is using OpenTRAC intentionally. Since I included OpenTRAC support in YAAC, I occasionally see error reports in the APRS-IS where someone actually tries to I-gate an OpenTRAC packet (the '[ PID 77 ]' error kind of identifies it), so apparently someone is using YAAC in dual-protocol mode on the same frequency.
Andrew, KA2DDOauthor of YAAC
-------- Original message --------
From: Scott Miller <scott at opentrac.org>
Date: 1/5/17 12:35 PM (GMT-05:00)
To: aprssig at tapr.org
Subject: Re: [aprssig] New IGate Operator
> I’d vote for using OpenTrac instead of APRS and just move on down the
I definitely need to revisit the protocol. I'm actually using a small
subset of it over UDP for an unrelated project but beyond that I haven't
had time to mess with it in years.
Now that microcontrollers aren't as resource-constrained I might make
some changes to the protocol to bring it more in line with other data
interchange formats. If bandwidth wasn't an issue, you'd probably want
to implement it as XML. Today we have BSON and some binary XML formats
that are more compact than their text counterparts, but still not as
efficient. OpenTRAC was supposed to be a very compact way of
representing data with a well-defined schema. It lacks rigor in how it
associates and nests elements, though, and is still best suited to
fairly 'flat' messages.
When it comes to simply replacing APRS packets, I think it's more than
adequate. It's still not where I wanted it to be for more complicated
What makes APRS special (as a system, not so much the specifics of the
protocol) is that it functions with low bandwidth, horribly asymmetric
and uncoordinated networks, slow transmit/receive turnaround times, and
can use any old junker of a 2-meter radio.
To stay relevant, I think any evolution of APRS ought to hang on to
that. If we want a shiny new system that's going to require all new
radios and network coordination, we should probably be running LTE or
something where we can spit out multi-kilobyte reports and not worry
about squeezing every bit out of it and trying to accommodate old
hardware. And there's room in ham radio for someone to be doing that.
The commercial carriers are generally going to do a much better job of
it in that space, though. I find more satisfaction in working in the
ugly, messy, low-bandwidth world. We can make the protocols better, add
FEC and better channel access control and more efficient data
representation, but the value comes from being able to make it work in
adverse conditions and with minimal resources. To use an analogy,
optical fiber networks are amazing and we probably shouldn't be running
anything else to homes, but if I need to splice a pair of copper wires I
can strip them with my teeth and twist them together, in pitch dark, and
make it work. I'd like to see us hams keep pushing the envelope of what
can be done with bailing wire when everyone's focused on fiber.
aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig