<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
It might have been used in Australia but the protocol development
was done by me here in California, back when I was active on SAR
myself. The basic idea was a simple type-length-value format with
efficient binary encoding, no weird math required (Mic-E uses
exponents that were easy for Bob in GWBASIC but were a pain for
embedded developers), extensibility, and graceful handling of
unsupported features.<br>
<br>
One of my favorite aspects of it (which I totally cribbed from
MIL-STD-2525B) was the object type/symbol system. Bob's scheme was
very ad hoc and symbol types got added as he saw fit with no
particular system. It was fine in the early 90s when there weren't a
lot of station types but it got unwieldy. The OpenTRAC scheme is
hierarchical and makes it easy to add fine-grained distinctions
between station types while letting clients not up to date on the
latest still figure out roughly what it is - like you can tell
something is a ground vehicle even if you don't know that the rest
of the code specifies a class A RV. The protocol finds use in some
of my totally unrelated projects - if you go to a Cirque du Soleil
show where a performer has several LED hula hoops on stage and sniff
WiFi traffic you might see OpenTRAC packets over UDP advertising a
station type of 3.2.10.15.0 for ground
equipment/lighting/display/portable.<br>
<br>
One thing I really wanted to do back then was to allow efficient
real-time and non-real-time traffic handling for SAR situations
where teams and vehicles were moving in and out of contact with each
other and with network infrastructure, so the latest information
would propagate through the network even if portions were isolated
for hours. A vehicle passing over a ridge might pick up a field
team's transmissions, and then move back into network coverage later
and pass those updates on. Another thing I wanted to do that would
be a lot more feasible now was to support RFID-based tracking of
vehicle contents, including passengers, so the command post would
know that Rescue-3 had a 400 foot rope bag and a Stokes litter, for
example. People and equipment have a way of getting shuffle around
in the field such that the command post loses track of who and what
is where.<br>
<br>
Cheap, ubiquitous satellite data coverage is coming so maybe none of
this will matter. I've made it part of the informal mission
statement of the radio side of my company, though, that we're here
to develop solutions that don't <i>require</i> constant
connectivity. Silicon Valley likes to operate on an assumption of
reliable data coverage, to the extent that I can't even reliably
listen to my downloaded music on my favorite music app because when
you move out of coverage the app simply hangs for 10 minutes or
more. Yeah, it'll play offline, it just doesn't gracefully handle <i>going</i>
offline and no one cares to test it.<br>
<br>
Man, I haven't ranted on the SIG in ages. Feels like the old days.<br>
<br>
Scott<br>
N1VG<br>
<br>
<div class="moz-cite-prefix">On 8/7/2023 6:48 PM, wa7skg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:daa60fc8-7b07-c9a8-4be6-f6125a02d608@wa7skg.com">IIRC,
OpenTRAC was something going on in Australia. There was an
offshoot SARTrac used for Search and Rescue operations that is
still used in some areas. There are a few SAR teams around here
that use SARTrac on both amateur and public safety frequencies
(not the standard APRS channels) to keep track of search teams and
put them up on big screens at the search base.
<br>
<br>
Michael WA7SKG
<br>
<br>
Stephen H Smith via aprssig wrote on 8/7/23 9:58 AM:
<br>
<blockquote type="cite">On 8/7/2023 8:33 AM, Greg Troxel wrote:
<br>
<blockquote type="cite">John Gorkos<a class="moz-txt-link-rfc2396E" href="mailto:jgorkos@gmail.com"><jgorkos@gmail.com></a>
writes:
<br>
<br>
<blockquote type="cite">In the deep corners of my brain, I
recall there was an alternate
<br>
protocol written Once Upon A Time that supported location
<br>
tracking/telemetry/messaging over AX.25, but was NOT APRS
and not
<br>
limited to non-commercial use. Does anyone have the name
and/or links
<br>
to something like that? I'm working with a non-profit for
event asset
<br>
tracking, and I don't want to cross any lines. We're using
LoRa for
<br>
short- to mid-range vehicle/personnel tracking and I'd
rather not
<br>
reinvent wheels.
<br>
</blockquote>
</blockquote>
<br>
<br>
You may be thinking of Scott Miller N1VG's (of Argent Data and
OpenTracker fame) OpenTRAC protocol. It was proposed as an
alternative to the increasingly kludged APRS protocol. It was
intensively discussed on this list in the 2003-2004 time frame,
but apparently went nowhere. It's website still exists at:
<br>
<br>
<a class="moz-txt-link-rfc2396E" href="http://opentrac.org/"><http://opentrac.org/></a>
<br>
<br>
but there appears to have been no activity for nearly 20 years.
A standards document IS on the web site that you might find
useful as a starting point for your project.
<br>
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
aprssig mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<br>
<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>
<br>
</blockquote>
<br>
</body>
</html>