<div>You'll need to know the nuts and bolts of ax.25 if you are building the raw frames (packets) that would be sent/received from a TNC in KISS mode. If you look at the text output, all TNCs perform some (ahem) readability enhancements by chopping off the padded space characters in callsigns shorter than 6 characters. The SSID is stored in a separate byte and the TNCs append a "-" and the number to the end of the callsign. So there is no "-" in the callsign portion of the ax25 header. The SSID is a whole 'nother byte.</div>
<div> </div>
<div>Also, there is a difference in the way that KPC brand TNCs and TAPR derived TNCs mark the "has been digipeated" flag. I can't rmeember which way it goes but one of them marks each digipeater path element as digipeated, the other kind marks only the /last/ digpeater element. You have to be tolerant of this when you write code to accept these frames off air.</div>
<div> </div>
<div>A word of caution when dealing with KISS frames. Once you construct your ax25 frame you'll have to check it for $c0 characters. If one appears in the frame you have to use the FESC and FEND characters to transpose it. Otherwise the TNCs will think you are at the end of a frame just because $c0 appears somewhere in your data. Then you send $c0, $00 (or port number - which is usually 0 anyway) <your packet here> $c0.</div>
<div> </div>
<div>Wes<br><br></div>
<div class="gmail_quote">On Tue, Oct 27, 2009 at 11:46, Greg Clark <span dir="ltr"><<a href="mailto:K7RKT@bigredbee.com">K7RKT@bigredbee.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I have two questions regarding building up AX.25 packets.<br><br>1) If the "path" fields are shorter than 7 characters, what do they<br>
get padded with. Spaces? Nulls? Most "common" paths don't have this<br>problem, since WIDE3-3 is seven characters. I'm trying to configure<br>my tracker for use with the ISS using the paths ARISS and SGATE, and<br>
I'm not sure what to put in the two remaining bytes when I build the<br>packets. I'm asuming this field is fixed in length at 7 characters.<br><br>2) What about the '-' in the path WIDE3-3, is it really a 'dash' in<br>
the packet? or is it a "space". I'm pretty sure that at this point in<br>time, I'm sending a "space", but not sure if that's the correct way to<br>build the packet. It does, however, seem to be working properly as<br>
is.<br><br>Yes, I am aware that everything needs to be shifted left by one bit,<br>and the last entry in the string of paths has the least significant<br>bit set.<br><br>Thanks,<br><br>Greg K7RKT<br>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br><a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Wes<br>---<br>God help those who do not help themselves.<br>