OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL1ANM > NETWRK   31.07.08 00:47l 39 Lines 1576 Bytes #999 (0) @ WW
BID : ZL1ANM34
Read: GUEST DH1NFJ
Subj: Re: TXDs and DCD
Path: DB0FHN<DB0MRW<OK0PKL<OK0PCC<OM0PBC<OK0PPL<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


 19.05.2024 00:00:27lGo back Go up