OpenBCM V1.08-5-g2f4a (Linux)

Packet Radio Mailbox

IZ3LSV

[San Dona' di P. JN]

 Login: GUEST





  
ZL1ANM > NETWRK   30.07.08 23:44l 39 Lines 1576 Bytes #999 (0) @ WW
BID : ZL1ANM34
Read: GUEST
Subj: Re: TXDs and DCD
Path: IZ3LSV<IK2XDE<DB0RES<DK0WUE<7M3TJZ<ZL2BAU<ZL1AB
Sent: 080730/2238Z @:ZL1AB.#06.NZL.OC #:16480 [AUCKLAND] FBB7.00i $:ZL1ANM34
From: ZL1ANM@ZL1AB.#06.NZL.OC
To  : NETWRK@WW


>From: KV7J@KV7J.#WNV.NV.USA.NA
>To  : NETWRK@USA
>
>                                NET-2.TXT
>                               TXDs AND DCD
>                               ------------
>
>Affecting all network configurations is TXD.  This is the period following
>transmitter key-up and beginning of the packet.  Its purpose is to allow
>time for the transmitter to become fully turned on before the packet
>commences.

Yes, but that's not its entire purpose.  A receiving TNC requires quite a few
bytes of flag signal to synchronize its clocking mechanism with the incoming
data, and to determine that this data is in fact flags of the expected baud
rate.  The presence of flags indicates that a packet frame will soon follow.

If TXD is reduced to too small a value, the receiving TNC can miss packets,
which will have to be resent.

In general, where there is any doubt, an extra 50 milliseconds of TXD flags
will guarantee good reception while hogging only 50mS of extra channel time
on each transmission.  If those extra 50mS of flags are removed so that TXD
is at a bare minimum, the time penalty when a frame is missed is not less
than the time consumed by a repeat request + retransmission of (M x PACLEN),
where M = Maxframe.

You can see that the benefits of reducing TXD towards absolute minimum become
scarcely worthwhile, while greatly increasing the danger of missed frames and
channel overloading due to repeats.

73 de Neil ZL1ANM

                                                                     T4 1.5à24


Read previous mail | Read next mail


 03.11.2024 14:41:42lGo back Go up