[aprssig] More efficient use of channel capicity through shorterpackets
ron.stordahl at digikey.com
Thu Oct 12 15:50:54 CDT 2006
scott at opentrac.org wrote:
> And after TXD, you've got a minimum of 20 bytes of data - flag (1),
> desination (7), source (7), control (1), pid (1), fcs (2), and flag (1).
> Each byte is 8 bits, though bit stuffing can increase the number of bits
> sent. Ignoring bit stuffing, 20 * 8 = 160. 160 / 1200 bps = 133.3 msec. I
> think the tail is hardcoded as two extra flag characters on the OpenTracker.
> Never had any trouble with that, at least not on VHF.
I have done some testing with two MFJ1270C's and a Motorola Micor as
well as a Kenwood TM261. I am able to establish a link and move data
with each side set at a TXD of 90 milliseconds. At 80 milliseconds the
link fails. I was a bit surprised to see that the Kenwood TM261 could
operate at that short a TXD, I knew the Motorola Micor would get down to
100 milliseconds. In testing I had one side long and kept trimming the
other until it failed. I have no control over TXTail, and really don't
know how long it is, but I am going to guess it's 100 milliseconds.
It's possible if I would repeat this using KISS I could control this.
For my calculations I am going to pull a TXD of 100 milliseconds out of
So here are some computed packet lengths for TXD=330 milliseconds which
I believe is commonly used, a TXTail = 100 milliseconds. 20 bytes (as
listed above by Scott) plus space used in the digipeater address field
(adding on the average of 6 bytes times 2 = 12) bringing the 'overhead'
to 32 bytes. This 32 bytes will be roughly 32 * 8 / 1200 = about 215
millisecond. So without the information field the total is up to 645
milliseconds. Looking at some raw packets sending only Mic-E I see 14
bytes in the information field. Adding this bring the total to 645 +
(14*8/1200) = 645 + 93 = 738 milliseconds. If instead the information
field is 40 bytes, the total time becomes 912 milliseconds. Looking at
raw packets from Minneapolis mobiles via Findu it appears about half are
using Mic-E, mostly without extraneous comments, and the rest are
sending uncompressed data in the 40 character range.
The average length is thus about 825 milliseconds. This 825
milliseconds is made up of TXD+TXTail of 430 milliseconds and 395
milliseconds of data. If you reduce the data to the bare minimum the
corresponding numbers are 430 msec and 308 msec.
So TXD and TXTail are apparently eating up more than half of the on the
air time. If these could be reduced to 100 ms and 50 ms each, the
numbers would be 150 msec (TXD+TXT) and 308 msec (data packet) for a
total of 458 msec.
It has been suggested that we move to 9600. If we would do so would the
150 msec TXD+TXT be reduced proportionally, thus to 38 ms? This seems
highly unlikely. The data packet portion should be however reduced to
about 77 msec (for bare minimum Mic-E data).
If the TXD+TXT can't be reduced (at 9600) to less than 150 msec, then
the 1200 baud vs 9600 baud packets consume 458 msec vs 227 msec, i.e.it
requires 4 times the baud rate to reduce the time used by a minimum
position packet by half.
As things stand now, with 1200 baud on 144.39, reducing TXD+TXT to the
bare minimum nearly cuts the typical on air time in half, perhaps
efforts should be expended in that direction first?
There very easily could be problems with my calculations, fire away, I
don't mind in the least!
> Also, I think you'll find that most ham rigs are slower to key up than
> commercial mobiles. Some are really bad, at 200 msec or more. Though I
> still have no idea what possessed Kenwood to hard-code the TXD at half a
> second on the TM-D700 - I know of no radio that REQUIRES such a long TXD.
> Unless maybe you're trying to catch a receiver in power save mode or
More information about the aprssig