[aprssig] APRS spec 101

[Steve Noskowicz]

That's the version number ... one I have printed out.  
Thumbing throiugh it for some light reading, [yea, right]  I can't
find where / if it describes the Frame Check Sequence.



it is a simple sum type checksum?



Now one may correctly argue that I don't *really* need to know this,
but being so possessed, I'm curious.   OR should we just
assume it is covered int the  AX.25 spec?

-- 

73, Steve, K9DCI

--- On Wed, 7/16/08, Robert Bruninga <bruninga at usna.edu> wrote:
From: Robert Bruninga <bruninga at usna.edu>
Subject: Re: [aprssig] Mic-E Issues
To: "'TAPR APRS Mailing List'" <aprssig at lists.tapr.org>
Date: Wednesday, July 16, 2008, 1:35 PM

> ... _all_ of the OpenTracker/Tracker2 products 
> [and] UI-View, Xastir, ... Support base-91...
> I'd expect some backlash if you decide arbitrarily 
> to cut it from the spec via the latest addendum.

Base-91 compressed remains in the spec.  But the use of Base-91
for ITEMS and OBJECTS are not recommended.

> I've already seen "Items" and "compressed" 
> objects/items come under the knife (which I 
> still disagree with).  Cutting pieces of a spec
> because some clients didn't fully implement 
> the spec or didn't implement it properly isn't 
> good.

My job is to assure that APRS works and is something that
newcommers to APRS can implement and have good faith that what
they transmit will be properly received and displayed by all
recepients.  Since we have found that over 80% of all mobiles
(the D7 and D700) do not properly decode or display compressed
ITEMS/OBJECTS, it only makes sense to recommend that they not be
used.  (60 out of 76 mobiles right now on RF in my area are D7
or D700's)...

> Some of us rather dislike Mic-E protocol.  

But 93% of all mobiles on the air use it (70 of 75 on my local
RF here).  So it should continue to be supported.

> A better alternative exists in the form of Compressed 
> (base-91) packets.

No problem for STATION POSITION.  Just don't use compressed
ITEMS or OBJECTS if you want them to be seen by 80% of all
mobiles..  And what mobiles "see" is a lot of what APRS is all
about...

> To extend that quite a bit further:
> *) Find bits of the spec that weren't implemented 
>    in some client or implemented incorrectly.
> *) Decide not to use that piece of the spec.

No, there is a big difference between "some" client, and "80% of
all" mobile clients.  Again, I see no value in cutting off 80%
of all mobile users from seeing something by insisting on
transmitting something that you know most people will not
properly see.

> Eventually there wouldn't be anything left of the 
> spec to use.  If_everybody_ can't use one of the 
> bits, then _nobody_ should use it.

The spec is quite solid now.  And hopefully all new major
products that are coming out these days, will support field
upgrades and bug fixes as needed.  I don't see any need to
remove anything else from the spec.

Bob, WB4APR


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/aprssig/attachments/20080716/cce8723e/attachment.htm