[aprssig] What is a position report?

Andrew Pavlin spam8mybrain at yahoo.com
Sat May 23 21:42:11 EDT 2020


 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
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200524/745636c3/attachment.html>


More information about the aprssig mailing list