[aprssig] OpenTRAC (was: Re: New IGate Operator)

[spam8mybrain]

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 
> road…
>

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 
information exchange.

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.

Scott
N1VG
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170105/d6ced9b3/attachment.html>