<div dir="ltr"><div>On Fri, Jun 9, 2017 at 3:24 PM, John Langner WB2OSZ <span dir="ltr"><<a href="mailto:wb2osz@comcast.net" target="_blank">wb2osz@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>[...snip...]</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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><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.</blockquote></div><div><br></div><div>For reference, since APRS is more based on AX.25 v2.0, the same figure is in section 2.4.1.2 in that document.</div><div><br></div>Agreed; since at the AX.25 level everything is UI beacon frames, I vote for the commad flag.<div><br></div><div>Begin spec proposal:</div><div>All APRS AX.25 frames SHOULD use the 'command' C bits - 0 in the source callsign and 1 in the destination (TNC ID) callsign.</div><div>All APRS stations MUST ignore all incoming C bits, as the fields are deprecated.</div><div>End spec proposal<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<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 3:24 PM, John Langner WB2OSZ <span dir="ltr"><<a href="mailto:wb2osz@comcast.net" target="_blank">wb2osz@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>
</blockquote></div><br></div></div></div>