[aprssig] WB4APR SK

[Andrew Pavlin]

 I coded in support for OpenTRAC in my APRS program, so it can work both protocols. It was kind of cool, and OpenTRAC being extendible such that I could _ignore_ any new data fields that were added that I didn't understand was nice, but the worst I've seen is that somebody must have turned OpenTRAC format on while transmitting on the APRS frequency, because I was seeing packets forwarded to the APRS-IS that could not be understood (but were using the AX.25 PID claimed by OpenTRAC). And, alas, due to the sub-entity structure of OpenTRAC, it's difficult to map OpenTRAC frames back to standard APRS packets as a protocol gateway.
I thought about writing an OpenTRAC I-gate, but what was the point until there was a sufficient customer base to justify the effort. Plus I'd be plagiarizing from the work the APRS-IS folks did in solving most of the networking issues (like packet redundancy removal) while still trying to solve insanely difficult weaknesses (like authenticating that only real amateur radio operators could get on it without having one body be a gatekeeper).

Andrew, KA2DDOauthor of YAAC

    On Friday, February 11, 2022, 07:45:36 PM EST, Weston Bustraan <wbustraan at gmail.com> wrote:  
 
 "infinitely extensible by its very design with all applications instantly supported"
As a developer, this is mildly amusing to me. Sure, the data format might be designed so that one can add additional data to a packet without breaking existing apps, but that doesn't mean that those applications know what to do with the additional data.
Recently, I took a look at whether I should add OpenTRAC support to QTH.app and the question I left with was, why? I didn't see much information that an OpenTrac packet can carry that we're not already communicating via APRS packets. OpenTRAC has an uphill battle; there is an entire ecosystem built around APRS, so there has to be a compelling reason for radio manufacturers, software developers, tracker builders, and Internet infrastructure to change from APRS.
I can say that it was not easy to navigate the many exceptions and and oddities in the APRS 1.0.1 spec when implementing a parser, and OpenTRAC seems much more consistent, but the OpenTRAC spec does not seem to be fully complete. For example, I would expect that any new protocol that would supplant APRS would be supporting a UTF-8 character set instead of just ASCII.
I can't find any plan for how the creators planned to roll OpenTRAC out. What does infrastructure look like? Is this intended to be transmitted on the standard APRS frequency? Or another frequency? So many questions.
Don't get me wrong; I'm willing to code in support for a new system, but I would like to see a lot more activity in that space.
73s Wes Bustraan W8WJB

On Fri, Feb 11, 2022 at 6:27 PM Gregg Wonderly <gregg at wonderly.org> wrote:

I would much rather the attention be put into a much richer yet simpler design such as OpenTrac!  It is so much more ready to be used by tiny systems for simple as well as complex tasks and becomes infinitely extensible by its very design with all applications instantly supported!

Gregg Wonderly
W5GGW

Sent from my iPhone

> On Feb 9, 2022, at 11:46 AM, steve at dimse.com wrote:
> 
> 
> 
>> On Feb 9, 2022, at 12:06 PM, R Kirk <isobar at verizon.net> wrote:
>> 
>> Maybe this is time to let APRS decline gracefully. 
> 
> I hope not, but it is certainly a possibility. And it will happen if new leadership does not emerge.
> 
> Steve K4HG
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220212/8fc1f89d/attachment.html>