[aprssig] What is a position report?

Sun May 24 18:50:45 EDT 2020

Iain R. Learmonth wrote:
> 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.

I've had a bunch of similar Qs.

Does the "APRS Working Group" still exist or has it been disbanded? Does
this mailing-list supersede it? If not, is it worth (re)forming one?
What would one do to apply to get into an APRS-WG?

I've been doing a LOT of parsing of a LOT of APRS-IS captures recently,
as part of wanting to get all the IRLP nodes on APRS (not just 10% of
them running a defacto standard script, but ALL of them in a way that
works usefully with TUNE/QSY buttons etc) and maybe revive the AVRS
concept/server, but in the process I don't want to just create another
non-standard-standard that's going to have other current/future
developers pulling their hair out to work with the mess I've made.
> 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.
Compressed are obviously FAR less human-readable, I mean about the best
you could hope to do would be to recognise "Oh hey they share some of
the most significant chars with me so might be somewhat
local-ish-kinda". They seem to only make sense in those scenarios where
you're trying to save every possible byte for things that will only EVER
want to be machine-readable. Speaking of which...
> 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.

Mic-E seems to be *THE MOST* severe attempt to pack as much as possible
into the smallest packets possible. "Hey let's pack data even into the
TOCALL"  :-D

I think the intention was that you'd pack a very short position report
into a quick "chirp" on the end of your voice transmissions in place of
an "over beep".

... so I find it particularly hilarious when I find Mic-E with really
long comments like...

'\xl X_/WX: 11,8V B4+05,68B3+04,00AT-03,62WT-03,62B2+03,00B1+02,25B5+06,75IT+01,93B6+07,31X1+02,06B7+07,50X2+04,81

... which is NOT Mic-E telemetry even, just a really long Mic-E packet

Bob says:

> Note, Mic-E is used in evry Kenwood and Yaesu radio so it should be
> the most important protocol to decipher first since that is the
> majority of off-the-shelf mobiles.
Well if you were just after sheer "bang for the buck", MicE is way down
the list - a typical day in April saw:

6096737 packets, which start...
1614069 ! (position, of which...)
1600658 !n (probably uncompressed)
1315009 ; (object, of which...)
1307698 ;ValidName* (valid object name, and not killed, of which...)
1307668 ;ValidName*n (valid named not-killed obj probably with uncompressed position)
 849295 @ (time+position, of which...)
 848013 @nnnnnn (have a 6-digit timestamp, SOME of which might not be valid but...)
 738602 @nnnnnnz (DDHHMM Zulu/UTC)
 100901 @nnnnnnh (HHMMSS Zulu/UTC)
   4264 @nnnnnn/ (DDHHMM local)
   5528 @something-else (various invalid timestamps EG @Greetings or @yyyy.yyN/xxxxx.xxW)
 834407 @nnnnnn[zh/]n (probably valid object, uncompressed pos)
   8261 @nnnnnn[zh/][\/] (probably valid object, compressed pos, main/alt symbol tabs)
 640626 = (position, message-capable, of which...)
 619533 =n (probably uncompressed)
 341197 : (messaging)
 341191 T (telemetry)
 283104 > (status)
 270164 ` (Mic-E with GPS fix)
 109269 < (capabilities)
  75077 / (time+position)
  74072 ) (Item)
  52309 ' (Mic-E with old GPS fix, I think)
  33037 _ (positionless WX)
  13773 $ (NMEA / Ultimeter2k)
  10114 U Starting to get into packets without type-chars here like:
<CALL>-2>UIDIGI,qAR,<DIGI>-1:UIDIGI 1.9
<CALL>-10>UIDIGI,qAR,<DIGI>-12:UIDIGI 1.9

I say "probably uncompressed" but if some of the symbols are allowed
overlay chars of 0-9, we presumably need to parse further to decide if
this is a valid Pos, Compressed Pos, or garbage?

In any case, if your goal is to "decode as much APRS-IS as possible",
start with uncompressed positions, then timestamps (because that's the
same with a prefix), then objects (another prefix before that) and
you've already got 70% of packets on APRS-IS. Be a bit more tolerant of
objects with invalid name lengths and you'll get a few more. Add items
(objects without timestamps but variable name lengths) and you're well
on your way to 75%. Mic-E is honestly only 5-6%, although Bob could be
right about "majority of off-the-shelf mobiles" if most of them are
non-mobiles, especially considering "a typical day in April" is actually
April 2020 during covid lockdown and there might be much less mobile
activity than normal? (Hmmm, THERE'S an interesting idea for a research
project!)

Expect A LOT of crap packets - I've already mentioned objects with
inappropriate length names, but packets with no/invalid types, packets
with Longitude like -12.3456W (WAT?), non-ascii symbols, plenty of
overlays on symbols that probably aren't supposed to have overlays, all
sorts of things wrong lengths or in wrong places...

EXTENSIONS are messiest of all. The spec implies you get ONE of them, so
are you allowed a CSE/SPD (course and speed) AND a PGHphgd (power,
height, gain directivity?) AND a /A=nnnnnn (altitude in feet)? Is
/A=nnnnnn allowed ANYWHERE in the comment? There's an example:

 !4903.50N/07201.75W-Test /A=001234

... so presumably mid-comment or end of comment? So is this (genuine
packet) legal?...

!12.34.56NR12345.67W&/A=000348PHG0430/iGate

Even if it's not legal, should we attempt to parse it, or abandon all
hope? Does /A=123456 have to be 6 digits? How would/should we handle (say)

/A=12345Short test?
/A=1234Shorter test?
/A=-00012 Negative OK? Is it above mean sea level or above ground or above terrain?
/A=1234567 Over-long OK? If so...
/A=00123444.123MHz ?

Max 999999ft altitude (FEET?!? that's a different argument, but I'm just
going to point out that only 5% of the world still uses imperial units,
despite most of those 5% having cast off their imperial shackles 244
years ago... where was I...) 999999ft is good enough for most (all?)
High Altitude Balloons, but not enough for LEO satellites, ISS, never
mind geosynchronous, would be nice to know if it's OK to use more digits
or not.

How about all the weather extensions - are they ONLY allowed on packets
with symbol "/_" or type-char "_"? If other packets look like they have
WX info despite other symbols, should we attempt to parse it?

WX dir/spd (or cnnnsnnn in positionless wx) and "gust" and "temp" seem
to be mandatory but are allowed to be spaces or "." if not available. Is
"0.3" acceptable? The various rains rnnn pnnn Pnnn hnn bnnnnn (or bnnnn
depending on what you're reading) are optional, but for all of these,
does ORDER matter, or am I allowed p123g123b12345t123? The L/l
luminosity, s snowfall, # raw rain counter, do they have to appear AFTER
the others, in that order? How long are they allowed to be? If someone
sends r4p0P3 (much too short) should I assume corruption or try to parse
as r004p000P003? In which case how was there more rain in the last hour
than there was since midnight, when there's been none in the last 24hrs?

... and should /A=123456 or PHGphgd appear before, after, or in the
middle of the WX data? What if they do all of the above?

> Finally, has anyone worked on combining the spec addendums with the spec
> to form a coherent document?
Not as a document, but somewhat in parser form.
> 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.
Smells like a job for a small-ish APRS-WG, hence my Q
> 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.

Spot the RFC editor   ;-)

Y'know what, this COULD BE and RFC it is after all (at least part of) an
Internet Protocol.

>    It is intended that inanimate things are reported as items, while
>    things that move are reported as that reported as objects.
Is it? I think you got that from APRS101 p57, but all examples of
repeater objects seem to be OBJECTS not ITEMs. I suppose some repeaters
can get quite animated though   ;-)

I've always thought "Does it benefit from having a timestamp? If so,
object", and it could be argued that repeater objects benefit from
having a timestamp if that shows "Was idle/busy/offline at this time"
but then I find http://www.aprs.org/info/object-perm.txt which suggests
using an object with a timestamp of 111111z, which...

A) Is then different from an item how? Just in name length/padding?
B) Is a perfectly good timestamp for real objects updated at 11:11 on
the 11th day of the month. Are they accidentally permanent unless
otherwise updated later?
C) I've also seen 000000z in use - midnight at the start of the ZEROth
day of the month? Nice idea for a deliberately invalid time, can't
happen accidentally, but should this be treated as permanent, or
unknown/undefined, or something else?

> Nick's previous email regarding the precedence bit is exactly the
> kind of data that would be good to look at in making these decisions.

Happy to help - I seem to be the self-proclaimed APRS big data
statistician   :-D

Nick

-- 
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig at noseynick.net
DOS: Defunct Operating System

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200524/586fb63c/attachment.html>