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