[aprssig] More efficient use of channel capicity through shorterpackets

[Ron Stordahl]

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 
my hat.

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!

Ron
N5IN
> 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
> something...
>
> Scott
> N1VG
>
>