[aprssig] More efficient use of channel capicity through shorterpackets
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
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."
More information about the aprssig