<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">A first step might be conceiving and convening a standards adoption process for APRS, like used by IETF.<div><br></div><div> <a href="https://en.m.wikipedia.org/wiki/Internet_Standard">https://en.m.wikipedia.org/wiki/Internet_Standard</a></div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Feb 26, 2024, at 18:22, Gregg Wonderly <gregg@wonderly.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">I agree that it’s not dead.  But, we have lots of things about it that will require a lot of agreement.<div><br></div><div>The foundation needs to provide a C++ library for radio manufacturers to use that implements packet coding and decoding as a standard.  That will allow embedded radio systems to have the same functionality. </div><div><br></div><div>But then all the python, Java, C# and other languages also need implementations.  The problem is that it’s extremely tedious to create such code bases and this is the primary reason we have very few fully featured applications or libraries around.</div><div><br></div><div>It’s just way too much to do over and over.</div><div><br></div><div>This is why I keep talking about switching to something more OpenTrac like!  We need simple codecs with simple libraries behind them!</div><div><br></div><div>There’s the whole layer 1/2 networking protocol conversation too, which is a part of the other discussion around layer 1 bits in layer2.</div><div><br></div><div>We need to really think seriously about actual reduction in complexity and extending things with real functionality where things like RF noise and user error are identifiable and don’t compromise whole systems.</div><div><br></div><div>Gregg Wonderly</div><div>W5GGW<br><div><div><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Feb 26, 2024, at 1:46 PM, Ev Tupis via aprssig <aprssig@lists.tapr.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div class="ydpbb5a91efyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div dir="ltr" data-setdir="false">Of course, the two of you are right.  However,  APRS was (and still is in many ways) a canvass upon which many things can be "painted".  Where others see a protocol that "emerged", I see a robust "blank slate" of possibilities.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Fact-based (not "qualitative") propagation study?  APRS</div><div dir="ltr" data-setdir="false">Small message passing?  APRS</div><div dir="ltr" data-setdir="false">Situational awareness?  APRS</div><div dir="ltr" data-setdir="false">VHF Contesting support?  APRS</div><div dir="ltr" data-setdir="false">Local-area / off-grid event logistic communication?  APRS</div><div dir="ltr" data-setdir="false">Oh yeah, asset location?  APRS</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">All of these applications are in <span><span style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">in stark contrast to the "single purpose" modes that have blossomed in the last decade.</span></span></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">My point is that APRS isn't a dead technology.  We have simply paused innovating with it.  Three (fully unbaked) thoughts include...</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">"Billboard" simplex beacons (not digipeaters) at altitude and with high power to beacon the widest-coverage repeater frequency/PL along with contact information for the area's three largest/most active clubs so newcomers are informed.  They would serve a second purpose as propagation-tracking signal sources for <span><a href="https://vhf.dxview.org/" rel="nofollow" target="_blank">VHF Propagation Map (dxview.org)</a>  I'm actually working on two of these myself.</span></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Inexpensive low-power portable weather stations that EmComm groups could deploy around (but not "inside of the warning tape") some large "event", to feed wind speed and direction, etc to a central data aggregator that could repackage the datagram into a format that can be parsed by mapping systems used by official emergency responders and displayed as a layer for their use.  "Inexpensive" because if the event is a field fire, it is possible that they may get damaged/lost with a shifting wind. :-)</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">A test of NORAD's ability to scramble when an APRS enabled educational balloon is launched. :-)</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Here's a sincere hope that the APRS Foundation is just what we needed to get to thinking more creatively again.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">With sincere respect and hope,</div><div dir="ltr" data-setdir="false">Ev, W2EV</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><br></div><div><br></div>
        
        </div><div id="ydp347563e0yahoo_quoted_9564739217" class="ydp347563e0yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Monday, February 26, 2024 at 11:47:23 AM EST, david vanhorn <kc6ete@gmail.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="ydp347563e0yiv8924923612"><div><div dir="ltr"><div>Not to diss Bob in the slightest, but it was a lot like Verifone's TCL language. It grew rather than being designed. <br clear="none"></div><div>Progress is made, and we should not lame the future to preserve the past. <br clear="none"></div><div><br clear="none"></div></div><br clear="none"><div id="ydp347563e0yiv8924923612yqt04597" class="ydp347563e0yiv8924923612yqt3123833156"><div class="ydp347563e0yiv8924923612gmail_quote"><div dir="ltr" class="ydp347563e0yiv8924923612gmail_attr">On Mon, Feb 26, 2024 at 9:39 AM Dana Myers <<a shape="rect" href="mailto:k6jq@comcast.net" rel="nofollow" target="_blank">k6jq@comcast.net</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="ydp347563e0yiv8924923612gmail_quote">On 2/26/2024 8:32 AM, Gregg Wonderly wrote:<br clear="none">
> I think there’s several things that matter.<br clear="none">
><br clear="none">
> 1. Bob was not a software expert nor was he trained in network protocol design. The ability to process APRS packets is a <br clear="none">
> nightmarish exercise in string interpretation.  This is amplified by user constructed strings, instead of using real <br clear="none">
> applications that manage data/packet formations.<br clear="none">
<br clear="none">
+1     So much so.<br clear="none">
<br clear="none">
Dana  K6JQ<br clear="none">
<a shape="rect" href="mailto:k6jq@comcast.net" rel="nofollow" target="_blank">k6jq@comcast.net</a><br clear="none">
<br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
aprssig mailing list<br clear="none">
<a shape="rect" href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br clear="none">
<a shape="rect" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br clear="none">
</blockquote></div></div><br clear="all"><br clear="none"><span class="ydp347563e0yiv8924923612gmail_signature_prefix">-- </span><br clear="none"><div dir="ltr" class="ydp347563e0yiv8924923612gmail_signature"><div dir="ltr">K1FZY (WA4TPW) SK  9/29/37-4/13/15<br clear="none"></div></div>
</div></div><div class="ydp347563e0yqt3123833156" id="ydp347563e0yqt93456">_______________________________________________<br clear="none">aprssig mailing list<br clear="none"><a shape="rect" href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br clear="none"><a shape="rect" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br clear="none"></div></div>
            </div>
        </div><span>_______________________________________________</span><br><span>aprssig mailing list</span><br><span>aprssig@lists.tapr.org</span><br><span>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</span><br></div></blockquote></div></div></div><span>_______________________________________________</span><br><span>aprssig mailing list</span><br><span>aprssig@lists.tapr.org</span><br><span>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</span><br></div></blockquote></div></body></html>