<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Lynn !<br>
<br>
On 21/06/2011 21:11, Lynn W. Deffenbaugh (Mr) wrote:
<blockquote cite="mid:4E00ECDD.5080409@homeside.to" type="cite">I
think you all need to read carefully and completely the AX.25
specification paying particular attention to the framing
characters and their relationship to bit stuffing. I suspect
you'll find that a tilde in the middle of an AX.25 packet actually
does NOT look like a framing character because the framing
character really isn't a "character" per se, but is actually a bit
pattern. </blockquote>
<br>
What would change to the eyes of a machine between a character (that
would be printed off as tilde) and 0x7e or 01111110 ?<br>
<br>
<blockquote cite="mid:4E00ECDD.5080409@homeside.to" type="cite">And
with bit stuffing, there are defined bit sequences that are NOT
allowed to appear in the bit stream representation of a packet,
but characters that may cause confusion within a packet have extra
bits stuffed (and removed) on the air, but you'll never see such
things in any byte-wise representation of the packet.
<br>
</blockquote>
<br>
Yes, I am going to read it immediately, but in the meanwhile you
please read below (you could even leave the above note)...<br>
<br>
<blockquote cite="mid:4E00ECDD.5080409@homeside.to" type="cite">
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32
<br>
<br>
On 6/21/2011 3:04 PM, Guido Trentalancia wrote:
<br>
<blockquote type="cite">Actually I have to correct myself here and
take the opportunity to suggest a minor improvement to the AX.25
protocol itself (say for a whole-new second generation of AX.25
and APRS because it won't be backwards compatible):
<br>
<br>
tilde is widely used for example to represent Unix home
directories and therefore it is also widely used in URLs (when
they are hosted on Unix-like platforms) as in very popular ones:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.baycom.org/~tom/ham/soundmodem/">http://www.baycom.org/~tom/ham/soundmodem/</a>
<br>
</blockquote>
</blockquote>
<br>
What I would like you to double-check (takes 30 seconds including
downloading and opening the file) is:<br>
<br>
APRS spec version 1.0.1 page 71 ("Messages", roughly in the middle
of that page)<br>
<a class="moz-txt-link-freetext" href="http://www.aprs.org/doc/APRS101.PDF">http://www.aprs.org/doc/APRS101.PDF</a><span class="f"><cite><br>
<br>
</cite></span>And then tell me if you still think that I am wrong
about the above...<br>
<br>
<blockquote cite="mid:4E00ECDD.5080409@homeside.to" type="cite">
<blockquote type="cite">So one ham that needs to send to another
ham the HTTP link to Tom's Soundmodem software (supposedly under
his own Unix-like home directory on Unix-like host
<a class="moz-txt-link-abbreviated" href="http://www.baycom.org">www.baycom.org</a>) would not be able to do that...
<br>
<br>
It's not that common nowadays, but it still happens often enough
to potentially cause troubles.
<br>
<br>
One of the first 32 unprintable ASCII values or something beyond
127 would perhaps do a better job (ideally something which
changes more often to bring other advantages as well, as 0x7e is
7 consecutive ones and only one zero at the end).
<br>
<br>
Guido, IZ6RDB
<br>
</blockquote>
</blockquote>
<br>
Now I am going to have a look at what you say and we'll update each
other later on.<br>
<br>
Thanks.<br>
<br>
Guido, IZ6RDB<br>
</body>
</html>