[aprssig] More efficient use of channel capicity through shorterpackets

Rick Green rtg at aapsc.com
Thu Oct 12 09:46:15 CDT 2006

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 

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

More information about the aprssig mailing list