<table cellspacing='0' cellpadding='0' border='0' ><tr><td valign='top' style='font: inherit;'>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.<br>
<br>
it is a simple sum type checksum?<br>
<br>
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?<br><br>-- <br>
73, Steve, K9DCI<br><br>--- On <b>Wed, 7/16/08, Robert Bruninga <i><bruninga@usna.edu></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Robert Bruninga <bruninga@usna.edu><br>Subject: Re: [aprssig] Mic-E Issues<br>To: "'TAPR APRS Mailing List'" <aprssig@lists.tapr.org><br>Date: Wednesday, July 16, 2008, 1:35 PM<br><br><pre>> ... _all_ of the OpenTracker/Tracker2 products <br>> [and] UI-View, Xastir, ... Support base-91...<br>> I'd expect some backlash if you decide arbitrarily <br>> to cut it from the spec via the latest addendum.<br><br>Base-91 compressed remains in the spec. But the use of Base-91<br>for ITEMS and OBJECTS are not recommended.<br><br>> I've already seen "Items" and "compressed" <br>> objects/items come under the knife (which I <br>> still disagree with). Cutting pieces of a spec<br>> because some clients didn't fully
implement <br>> the spec or didn't implement it properly isn't <br>> good.<br><br>My job is to assure that APRS works and is something that<br>newcommers to APRS can implement and have good faith that what<br>they transmit will be properly received and displayed by all<br>recepients. Since we have found that over 80% of all mobiles<br>(the D7 and D700) do not properly decode or display compressed<br>ITEMS/OBJECTS, it only makes sense to recommend that they not be<br>used. (60 out of 76 mobiles right now on RF in my area are D7<br>or D700's)...<br><br>> Some of us rather dislike Mic-E protocol. <br><br>But 93% of all mobiles on the air use it (70 of 75 on my local<br>RF here). So it should continue to be supported.<br><br>> A better alternative exists in the form of Compressed <br>> (base-91) packets.<br><br>No problem for STATION POSITION. Just don't use compressed<br>ITEMS or OBJECTS if you want them to be seen by 80% of
all<br>mobiles.. And what mobiles "see" is a lot of what APRS is all<br>about...<br><br>> To extend that quite a bit further:<br>> *) Find bits of the spec that weren't implemented <br>> in some client or implemented incorrectly.<br>> *) Decide not to use that piece of the spec.<br><br>No, there is a big difference between "some" client, and "80% of<br>all" mobile clients. Again, I see no value in cutting off 80%<br>of all mobile users from seeing something by insisting on<br>transmitting something that you know most people will not<br>properly see.<br><br>> Eventually there wouldn't be anything left of the <br>> spec to use. If_everybody_ can't use one of the <br>> bits, then _nobody_ should use it.<br><br>The spec is quite solid now. And hopefully all new major<br>products that are coming out these days, will support field<br>upgrades and bug fixes as needed. I don't see any need to<br>remove anything else from the
spec.<br><br>Bob, WB4APR<br><br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</pre></blockquote></td></tr></table><br>