<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Iain R. Learmonth wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>I've had a bunch of similar Qs.</p>
<p>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?<br>
</p>
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.<br>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
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...<br>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>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</p>
<p>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". <br>
</p>
<p>... so I find it particularly hilarious when I find Mic-E with
really long comments like...</p>
<pre>'\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</pre>
<p>... which is NOT Mic-E telemetry even, just a really long Mic-E
packet<br>
</p>
<p>Bob says: <br>
</p>
<p>
<blockquote type="cite">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.<br>
</blockquote>
Well if you were just after sheer "bang for the buck", MicE is way
down the list - a typical day in April saw:<br>
</p>
<pre>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
</pre>
<p>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?<br>
</p>
<p>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!)</p>
<p>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...</p>
<p>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:</p>
<pre> !4903.50N/07201.75W-Test /A=001234</pre>
<p>... so presumably mid-comment or end of comment? So is this
(genuine packet) legal?...</p>
<pre>!12.34.56NR12345.67W&/A=000348PHG0430/iGate
</pre>
<p>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) <br>
</p>
<pre>/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 ?
</pre>
<p>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.<br>
</p>
<p>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?</p>
<p>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?</p>
<p>... 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?</p>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">Finally, has anyone worked on combining the spec addendums with the spec
to form a coherent document?</pre>
</blockquote>
Not as a document, but somewhat in parser form.<br>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
Smells like a job for a small-ish APRS-WG, hence my Q<br>
<blockquote type="cite"
cite="mid:3afe6804-c4a3-bce1-38ca-303a16d8689b@hambsd.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>Spot the RFC editor ;-)</p>
<p>Y'know what, this COULD BE and RFC it is after all (at least part
of) an Internet Protocol.<br>
</p>
<p>
<blockquote type="cite"> It is intended that inanimate things
are reported as items, while<br>
things that move are reported as that reported as objects.</blockquote>
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 ;-)</p>
<p>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
<a class="moz-txt-link-freetext" href="http://www.aprs.org/info/object-perm.txt">http://www.aprs.org/info/object-perm.txt</a> which suggests using an
object with a timestamp of 111111z, which...</p>
<p>A) Is then different from an item how? Just in name
length/padding?<br>
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?<br>
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?</p>
<pre class="moz-quote-pre" wrap=""><blockquote type="cite"><pre class="moz-quote-pre" wrap="">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.
</pre></blockquote></pre>
<p>Happy to help - I seem to be the self-proclaimed APRS big data
statistician :-D</p>
<p>Nick<br>
</p>
<pre class="moz-signature" cols="72">--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; <a class="moz-txt-link-abbreviated" href="mailto:sig@noseynick.net">sig@noseynick.net</a>
DOS: Defunct Operating System
</pre>
</body>
</html>