[aprssig] WB4APR SK

Fri Feb 11 21:15:04 EST 2022

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.

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.

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.

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.

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.

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. ;)

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.

Scott
N1VG

On 2/11/2022 4:44 PM, Weston Bustraan 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/20220211/64c50a8e/attachment.html>