[aprssig] More efficient use of channel capicity through shorterpackets

[Rick Green]

On Thu, 12 Oct 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.
>
  So, to summarize what I'm reading here, TXDelay needs to be large enough 
to span:
   1) Transmitter synth lock-up delay
   2) Transmitter PA Key-up delay
   3) Receiver squelch open time

In addition, there may also be a delay for the Receiver's modem.  At 1200 
baud FSK, the detection of the tones is fairly quick, but does the modem 
actually deliver good data immediately?  Or does it need to see multiple 
bits fly by before its local bitclock is sync'd, and it can reliably 
deliver data to the PAD.
   With 9600baud modems which use more complicated encoding schemes, I 
suspect this modem clock recovery/bitclock sync time may be longer as 
well.

Another short-packet data application, the ubiquitous credit card 
authorization terminal, is still using 300 baud modems to this day, simply 
because the handshake/lockup time on the faster codecs adds more time than 
is saved during the data-transfer phase.

-- 
Rick Green, N8BJX

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin