[aprssig] Precedence Bit and IP Encapsulation

Iain R. Learmonth irl at hambsd.org
Wed May 20 11:15:18 EDT 2020


Hi,

So I think my main takeaway here is that the precedence bit was not
widely deployed, and so it's not possible to draw on existing
deployments as inspiration for how to treat these packets.

I do think that the ability to have QoS support in APRS is a good thing,
especially on the low speed links commonly utilised. Unless there are
objections, I will stick with "best effort" for low precedence, AF11 for
standard traffic, and optionally AF21 for operator present traffic.

Thanks,
Iain MM0ROR.

On 20/05/2020 15:22, Nick VA3NNW wrote:
> Robert Bruninga wrote:
>> I'd love to hear if any system in APRS actually implemented the Precedence
>> bit?
>> http://aprs.org/aprs12/precedence-bit.txt
>> Basically it is making the Table-Overlay character a lower case character.
>
> I was about to process all of April's APRS-IS through
> Ham::APRS::FAP.pm but was suspicious when there were *NO* lowercase
> symbols.
>
> Then I found in the code:
>
>         if ($symboltable !~ /^[\/\\A-Z0-9]$/) { _a_err($rethash,
> 'sym_inv_table'); }
>
> ... which basically means it accepts / \ A-Z (upper) or 0-9 (lower) or
> considers it to be INVALID   :-D
>
> I believe aprs.fi is based around this library, but possibly a newer
> version of it?
>
> So re-parsing myself, and looking at the entire APRS-IS for April, I see
>
> 148019309 packets parsed with symbols for the month
> 147998954 packets parsed with GOOD symbols ("approx ASCII")
>  90278050 use table "/" (which obviously can't be upper/lower case
>   4944477 use alternate "\" (ditto)
>  50955070 use UPPERCASE symbol table overlay
>   1717233 use 0-9 as an overlay
>     72662 use LOWERCASE symbol table overlay
>     28403 use bad (8-bit / control-char / corrupt) symbol tables
>     23414 use ASCII symbol table overlays like ~@#$%^&*() (ASCII but non-alphanumeric)
>     20355 use bad symbols (not the table, the actual symbol is non-ASCII)
>
> So... lowercase symbols DO happen, but less than 0.05% of the time.
> Hard to tell how many of those might be deliberate "precedence" vs
> "Just didn't know and thought lower-case was fine" vs "data
> corruption" but they are quite a bit higher than (ab)use of 8-bit.
>
> For comparison, the upper/lowercase of the LatLon N/S/E/W chars:
>
> 129128571 NS=N (Notable bias toward Northern hemisphere as well)
>   7279962 NS=S
>  77838643 EW=E (E/W a bit closer but bias to E, yes I was surprised)
>  58559906 EW=W
>     77842 NS=n
>     11534 NS=s (Still a notable N bias, but notably less - interesting?)
>     18753 EW=e
>     80607 EW=w (... but much more westerly bias in the lowercase - WAT?!?)
>
> I see (from the same doc) there's also a standard to use an overlay of
> "O" for "Operator Present".
>
> I've seen that used far more on repeater objects to mean OFFLINE! This
> is almost but not quite the opposite of "Operator present"!  :-D
>
> They'll use I0 for idle/IRLP, C0 for Connected, B0 for Busy, O0 for
> Offline (not Operator Present)
>
> Nick VA3NNW - self-declared APRS "big data statistician" nosing around
> APRS data  ;-)
>
> -- 
> "Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
> use Std::Disclaimer;    sig at noseynick.net
> Men still remember the first kiss after women have forgotten the last..
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org


-- 
https://hambsd.org/




More information about the aprssig mailing list