<div dir="ltr">Woah woah woah... We shouldn't be adding stuff to APRS1.1 when there's an APRS1.2. The 1.1 page literally says "But it was decided best to finally Freeze the accumulation in June 2004 as APRS1.1 and then after public posting approve it."<div><br></div><div>Can we please have this <a href="http://aprs.org/aprs11/C-bits-SSID.txt">http://aprs.org/aprs11/C-bits-SSID.txt</a> document under the APRS1.2 page instead of 1.1? 1.2 already has a link to the RR bits page.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<br><div class="gmail_quote">On Fri, Jun 9, 2017 at 4:05 PM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Never thought of them before. So I added this description to the APRS11<br>
spec update page.<br>
<a href="http://aprs.org/aprs11.html" rel="noreferrer" target="_blank">http://aprs.org/aprs11.html</a><br>
<br>
(So I can find it next time.)<br>
Bob, WB4aPR<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: aprssig [mailto:<a href="mailto:aprssig-bounces@tapr.org">aprssig-bounces@tapr.<wbr>org</a>] On Behalf Of John Langner<br>
WB2OSZ<br>
Sent: Friday, June 09, 2017 6:25 PM<br>
To: <a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
Subject: [aprssig] AX25 / KISS questions<br>
<br>
The AX.25 spec says this about the "C" bits in the destination and source<br>
addresses. Section 6.1.2, figure 6.1.<br>
<br>
Frame Type Dest.SSID C-Bit Source SSID C-Bit<br>
--------------- --------------- -----------------<br>
Previous versions 0 0<br>
Command (V.2.X) 1 0<br>
Response (V.2.X) 0 1<br>
Previous versions 1 1<br>
<br>
The two "C" bits must be the opposite of each other. This is very important<br>
for the traditional "connected" mode.<br>
<br>
I could find no mention of these two bits in the APRS protocol spec or other<br>
literature.<br>
<br>
After spending a lot of time studying the AX.25 spec, I think "command"<br>
would be correct. The state diagrams, in the back, indicate that a UI frame<br>
that is not a "command" is an error. APRS is built on top of AX.25 so we<br>
would expect it to follow the same rules unless explicitly mentioned<br>
otherwise.<br>
<br>
When this question came up before, I hacked together something to observe<br>
what is actually used in practice.<br>
<br>
Source C Dest C meaning, examples.<br>
-------- ------ ------------------<br>
<br>
0 0 (previous versions) WXtrac, APRS+SA, KPC-3, Tiny Track,<br>
Xastir<br>
0 1 (command) Uidigi, UIview, APRSISCE, APRSdroid<br>
1 0 (response) Kenwood, Yaesu, APRSISCE<br>
1 1 (previous versions) OpenTrack<br>
<br>
<br>
We can have philosophical discussions about what they "should" be but the<br>
reality is that we find all 4 combinations being used.<br>
<br>
Any implementation should simply ignore them for incoming frames.<br>
<br>
<br>
______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a><br>
______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a><br>
</div></div></blockquote></div><br></div>