[aprssig] APRS Priority bit

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Robert Bruninga
> Sent: Wednesday, August 19, 2009 9:06 AM
> 
> This last week we did find that one of these bits IS backwards
> compatible with UI-view and so we would like to move forward on
> this issue.  Please read:
> http://aprs.org/aprs12/priority-bit.txt
> 
> Basically, we will use the CASE of the OVERLAY byte to indicate
> ROUTINE or PRIORITY.  If the overlay byte is UPPERCASE or
> missing, then the packet is ROUUTINE.  If the case of the
> overlay byte is -lowercase- then the packet is PRIORITY.
> 
> Last week testing confirmed that UI-view and most other clients
> will display these lower case overlays, or can be updated to do
> so, so this has now been added to the APRS12 addendum.
> www.aprs.org/aprs12.html

Interesting concept.  I foresee two issues (may be overcome, but nonetheless issues).  First is that the compressed posit format (usable in posits, objects, and items) uses overlays a through j to represent actual overlays of 0 through 9.  Therefore, a through j must be ignored as "priority bit" overlays when if used in compressed format posits/objects/items.

Second is the concept that digipeaters will now have to decode the data portion of the AX.25 packet if they are to implement these RF pacing algorithms.  While software-based digipeaters like digi_ned may be able to handle this as-is or with minor modifications, I perceive already memory strapped firmware-based digipeater code may be problematic.

This is not an attempt at discouraging the concept; only pointing out a couple of issues that I foresee could be problematic to implementing it.

73,

Pete Loveall AE5PL
pete at ae5pl dot net