[aprssig] What is a position report?

[Robert Bruninga]

As I am retiring next month, I do hope to eventually sit down and clean up
the APRS1.1 and APRS1.2 portions of the spec and help remove any
inaccuracies or conflicts.  I welcome identifications of these things to
look at.

Bob


On Sat, May 23, 2020 at 9:42 PM Andrew Pavlin via aprssig <
aprssig at lists.tapr.org> wrote:

> Hello, Ian.
>
> I'm afraid you have a few misunderstandings, and a long uphill row to hoe
> to do what you're trying to do.
>
> 1. APRS was not created by a central standards body, but by many people
> working independently. Although Bob Bruninga WB4APR is technically the
> final authority on anything in APRS, people don't always check with him
> (even though they should). And once some of these things get out there,
> they're out there forever. It's like trying to erase something from the
> Internet: impossible, because there are too many copies scattered around.
>
> 2. Because of this, APRS has grown organically for several different
> purposes that share a common infrastructure, so there are several different
> ways to do things, optimized for different use cases. For example, Mic-E
> was originally optimized for a very short signal "burp" at the end of a
> voice transmission, so as to not extend the transmission significantly
> while still getting position data piggybacked on the voice transmission.
> But now, every single designed-for-APRS radio, including the Kenwoods and
> Yaesus, plus remote-operator devices like the Byonics MT-AIO, and many
> stand-alone TNCs all support this position format, either by default or as
> the only position format choice. Other use-cases can't use this format
> because they can't type the control codes into the packets, so they have to
> use an all-printable-ASCII format like the uncompressed position report.
> And a general-purpose APRS client like Xastir, APRSIS32, YAAC, APRSdroid,
> or aprs.fi has to support all of them, because it doesn't know who or
> what other stations the user is going to be working with.
>
> 3. Amateur radio infrastructure changes _very_ slowly, because changes
> come literally out of the wallets of individual radio operators. If
> something works, they're not going to replace it just because someone else
> says the change is a good idea, but only because they personally get a
> benefit from the time and money spent. For example, Bob proposed the New-N
> paradigm to fix digipeating issues in 2004. That should only be a software
> change, so existing hardware could do it with a simple firmware change. Yet
> there are _still_ not only leaf-node stations, but digipeaters doing it the
> old way (and, alas, non-updated webpages still telling them to do that).
> Backwards compatibility is a very important issue. UI-View is a dead
> program; its author has been a Silent Key since 2004, and the program
> cannot be upgraded. Yet people are still using it. Scott Miller N1VG tried
> to come up with a next-generation APRS, called OpenTRAC, making the message
> formats more consistent so support of multiple varying use cases would be
> easier, and systems who didn't care about a particular use case could
> ignore it with impunity, and leaving behind some of the kludges from
> no-longer-necessary restrictions of obsolete hardware. OpenTRAC was (and
> still is) a very nice clean specification, but it sank like a lead balloon
> because it wasn't backwards compatible with the existing APRS
> infrastructure (even though it could co-exist with APRS) and OpenTRAC
> didn't add enough value over the existing support of the outstanding
> hodge-podge in APRS for very many people to make the effort to support it.
>
> So you can't just say "message format XXX is no longer supported", because
> people are still using that format, and are going to keep using that
> format. Even Bob WB4APR can't stop existing use-cases. Some message formats
> are declared deprecated (ex.: RELAY and WIDE digipeating aliases,
> Maidenhead format position reports), and new implementations should not
> transmit them, but, because of existing users, support for receiving them
> can't go away. Different variations of position reporting exist for
> different use cases. For example, compressed mode positions have higher
> position precision than human-readable ASCII position reports (even more
> than Mic-E can do), but not all implementations can understand them. Is
> that a reason to discard them? Mic-E is unreadable by human beings
> examining binary packets, but extremely compact, saving bandwidth and air
> time as long as you have the minimal receiving-end computer power needed
> to decode it. The !DAO! hack was introduced to increase precision while
> being backwards-compatible, but it's less efficient (more bytes per
> packet), and just as human-unreadable as Mic-E and compressed-mode text.
>
> You quoted Postel's Law, so I'm assuming you're familiar with some of the
> rules that manage the Internet. Remember the rest of Postel's Law: "Be
> conservative in what you send, be liberal in what you accept". Jon Postel
> _knew_ he was herding cats (to use the simile for managing computer
> programmers). The Internet's protocol stack allowed developers to do
> different things in different ways compatibly, so (for example) you don't
> have to use HTTP for something it is manifestly unsuitable for (such as SSH
> terminal sessions). Alas, APRS didn't have a tall enough layered stack to
> separate different use cases cleanly, because of the primitive hardware it
> was originally developed on, which often required an actual human being to
> be the data interpreter rather than a computer.
>
> Creating an APRS 1.2 complete protocol specification is a worthy task,
> bringing the APRS 1.0.2 spec up-to-date with the 1.1 and 1.2 changes. But
> you can't just throw out sub-protocols that are still being used (bad as
> they may be), or mandate new special-use-case features at users who don't
> need them and will never implement them. You could consider APRS 1.0.2 as
> the common baseline (and even parts of that are optional for certain use
> cases, such as an originating station's free choice of which position
> format to use), and APRS 1.1 and 1.2 as collections of extensions, most of
> which are optional, but should be implemented as specified if they are done
> at all. Of all of APRS 1.1 and 1.2, only the New-N paradigm is really
> required (because it affects every user); nearly everything else is special
> use-cases (for an Internet equivalence, compare the use cases of FTP, SMTP,
> HTTP, and Telnet, all radically different use cases that work over common
> TCP and IP lower-level protocols).
>
> The tocall specification and 1.2 symbol overlay specification are living
> documents of common conventions used to identify station and object types.
> Not knowing a new one won't kill a receiving station, because it doesn't
> change the way the receiving station handles the packets.
>
> So whether you want to write one new specification, or a core
> specification and a sheaf of extension specifications (as the Internet
> protocols are done), up to you. The latter makes more sense from an
> aesthetics point of view, but makes it more likely something will be missed
> (unless you have a master document equivalent to STD 3 on the Internet).
>
> How can I stand on my soapbox and proclaim all this? I've been a
> professional software and network engineer for over 40 years (!), and I'm
> the author of YAAC ("Yet Another APRS Client"), which I began implementing
> in 2011, long after APRS started; YAAC didn't go public until 2012 (which
> is still nearly 9 years of APRS experience since the first line of code,
> but a mere fraction of the 26+ years the current form of APRS has been
> around in its various permutations). I tried to write my implementation
> from scratch (as you are apparently trying to do) as an exercise for the
> student, so I would know how APRS really works by hands-on experience. But
> I also tried to follow the APRS specs and Postel's Law rigorously, in full
> conformance with Bob Bruninga's expectations and intentions, even when they
> all were contradictory, and so I was able to support anything unexpected
> the network threw at me. Yes, I had to make a lot of fixes over the years,
> but many of those were due to my lack of understanding as I expanded YAAC
> to include more use cases, not necessarily a protocol violation on a
> sending station's part. On the other hand, there are still a lot of errors
> on the part of sending stations due to their protocol violations
> (especially on the stations where the packets are created by hand [by an
> operator lacking understanding or typo-free data entry] through editing the
> BEACON command of a TNC), and we just have to deal with it (Postel's Law
> again) and gently steer those users to the correct way, without encouraging
> them to continue in error by actively supporting their error.
>
> Note that your idea of updating the spec is great for that gentle
> steering, as long as it accounts for the issues mentioned above (and is
> cleared by the Father of APRS, Bob Bruninga). Doing otherwise would be like
> hacking the Linux kernel against Linus Torvalds' directions.
>
> Note that there are already a large number of programs available for
> FreeBSD that do APRS, so you don't need to re-invent the triangular wheel
> for HamBSD. I see that you already have written your own applications to
> try to replace the connected-mode-oriented AX.25 stack available for
> Unix/Linux/FreeBSD with a stack oriented towards APRS. Will that obstruct
> doing other protocols (such as the Fldigi suite or Winlink) or other
> interfaces (such as DireWolf over sound cards instead of hardware TNCs, or
> YAAC or Xastir's UIs)?
>
> I am preparing to review your entities.txt document, which I see you
> carefully structured in standard Internet RFC format. Are you interested in
> review comments?
>
> Andrew, KA2DDO
>
>
> On Saturday, May 23, 2020, 3:41:13 PM EDT, Iain R. Learmonth <
> irl at hambsd.org> wrote:
>
>
> Hi,
>
> In attempting to write code that produces position reports for stations,
> objects, and items I have ended up with some notes. They are far from
> being complete but I'm already starting to find some contradictions and
> perhaps some things that need changing now time has moved on.
>
> In particular, I think there needs to be some application of Postel's
> Law to the specs. We should determine what the correct thing is to send
> now, and what things you might be expected to receive. We should also
> consider what the correct thing to send might be in the future, and
> prepare implementations for that change.
>
> Items are not recommended in APRS 1.1, however this appears to be a
> mistake according to an email from Bob that recommends only against the
> compressed format for items, which I guess also applies to objects? So
> it's not really clear if we should be avoiding compressed formats
> everywhere.
>
> There is also the Mic-E format, which I haven't looked at at all yet. I
> wonder to what extent that can be treated as an extension to the APRS
> specification rather than a core part of it. Would it be recommended to
> implement Mic-E position reports over an uncompressed/compressed
> position report?
>
> Finally, has anyone worked on combining the spec addendums with the spec
> to form a coherent document? The editing process for that would surely
> work out some of the bugs. I might volunteer to do this if it has not
> been done and there is support for such a thing.
>
> My notes so far are attached. The references section at the end contains
> all the documents that were drawn on in order to put together the notes
> so far, but as you'll see there are still lots of holes.
>
> Thanks,
> Iain.
> _______________________________________________
> 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/20200524/6eead7b9/attachment.html>