<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
There wasn't ever an overall plan to roll out OpenTRAC - it was my
pet project, when I got into APRS and realized how much of a mess
the spec was. I created the OpenTracker as a test platform for my
protocol ideas. The early versions supported both OpenTRAC and APRS
and you could have them send both formats in the same transmission.<br>
<br>
That board had an 8-bit MCU with 8k of flash and 192 bytes of RAM.
When they started to sell in significant numbers, 95% of the
customers only cared about APRS and eventually OpenTRAC support got
put on the back burner.<br>
<br>
It was about 20 years ago that I started that project, and it's
definitely imperfect and incomplete. I still think it's a better
direction for new development than the way things were added to the
APRS spec. It was certainly easier to implement on a small MCU, but
now that's not nearly the concern it used to be. At the low end, the
new designs I have in production use 32-bit Cortex M4s with floating
point and 16 kB of RAM or more. We're not as constrained by the
hardware, but getting an APRS implementation right is harder than
ever.<br>
<br>
One feature of OpenTRAC that I really like is the hierarchical
symbol system - and I can't take credit for designing that, I just
borrowed it from MIL-STD-2525B and adapted it. That's one place
where it really helps future-proof things. If you add a new APRS
symbol, no client knows anything about it until developers get
around to adding it. With the hierarchical system you can still
interpret all of the parts your client knows and come up with some
less granular but still appropriate symbol.<br>
<br>
A big reason I haven't been as active in APRS development as I used
to be is that several years ago a side project developing fancy
programmable LED hula hoops took off and that's been better than
half of the company's revenue since. Some of the hoops (and related
LED performance props) have WiFi support, and they actually use
OpenTRAC over UDP to coordinate with each other. There was never a
'hoop' symbol added to the protocol, but the props all identify as
3.2.10.15.0.x, which works out to
ground.equipment.lighting.display.portable.x and something decoding
the packets could still show a useful symbol. It might be the same
symbol as a light trailer but it's something. And it lets you filter
by useful categories, like equipment or vehicles.<br>
<br>
I'd hoped that we could have a dual protocol system to ease the
transition if it caught on. You can do both protocols without
greatly increasing the length of a transmission. I'm sure some of
you remember what happened when someone flew an OpenTracker set to
dual protocol mode on a balloon, though. Someone had a misconfigured
TNC on an IGate that was passing OpenTRAC packets to the APRS-IS,
FindU's parser choked on the packets, and it kicked off a raging
week-long debate (with me and Bob making up the majority of the
traffic) about what traffic is appropriate in 144.390 and who gets
to decide. (For the record Bob quit the list for a while after that,
which means I won. ;)<br>
<br>
If we're stuck with the APRS protocol forever, I'd at least like to
see some things deprecated. I'm sure the most controversial item on
my own hit list would be the MIC-E format, mostly for the way it
violates separation of protocol layers by reusing a callsign field
for data. Base91 can do the same job more cleanly.<br>
<br>
Scott<br>
N1VG<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/11/2022 4:44 PM, Weston Bustraan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEeLBeXrKNnOkwM-xm58am0Hi+MdRRBtzdqN-QBrZipU_CJoFA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">"infinitely extensible by its very design with all
applications instantly supported"
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>73s Wes Bustraan W8WJB</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022 at 6:27
PM Gregg Wonderly <<a href="mailto:gregg@wonderly.org"
moz-do-not-send="true" class="moz-txt-link-freetext">gregg@wonderly.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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!<br>
<br>
Gregg Wonderly<br>
W5GGW<br>
<br>
Sent from my iPhone<br>
<br>
> On Feb 9, 2022, at 11:46 AM, <a
href="mailto:steve@dimse.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">steve@dimse.com</a>
wrote:<br>
> <br>
> <br>
> <br>
>> On Feb 9, 2022, at 12:06 PM, R Kirk <<a
href="mailto:isobar@verizon.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">isobar@verizon.net</a>>
wrote:<br>
>> <br>
>> Maybe this is time to let APRS decline gracefully. <br>
> <br>
> I hope not, but it is certainly a possibility. And it
will happen if new leadership does not emerge.<br>
> <br>
> Steve K4HG<br>
> <br>
> <br>
> _______________________________________________<br>
> aprssig mailing list<br>
> <a href="mailto:aprssig@lists.tapr.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">aprssig@lists.tapr.org</a><br>
> <a
href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">aprssig@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
<br>
</body>
</html>