Packet TNC settings

 

TXD = Switching Time

 

From ÔX to RX

 

  Switching between transmit and receive is often a difficult problem for new packeteers to overcome. The reason the  TXD becomes so difficult is due to the "key-up time" of most transceivers.

  Some of us have added Linear amplifiers to the VHF packet station in an effort to claim the territory between us and the far of node. When we add the extra power amplifiers, we fail to consider that the built-in antenna change-over system within the power amplifier is an electro-mechanical device. This electro-mechanical relay takes
time to traverse from the receive state to the transmit state. Many of us also have the Linears which have an internal receive pre-amplifier. This too adds more time to the transmit "
õp time," or transmit delay.

 

  Ây now you should have figured out that the acronym TXD means transmit delay. The transmitting station is ready to send data, and the operator inputs a Line of text to send to the station connected at the distant end. The <enter> key is pressed to send the packet of text, but instead of an ACKnowledgement returning from the distant station, there is a ÍAÊ, or Non-ACKnowledge returned. This means the distant station never received the complete packet. Thus there will be a retry, or worse, there will be many retries and the connect request will retry OUT. Á disconnect message will appear ïn your screen. This could be an indication that your TNC ÔXD is too short.

We don't want the transceiver to start sending usable data at the exact instant the radio keys õp, so we install a delay stream of maybe Çex7Es or  ÇEX00s at the beginning of each packet. This transmit delay period between the radio key õp and the beginning of the data stream is what we are referring to when we talk about the TXD.

The TXD is used to give the radio enough time to reach full output before the usable data begins to flow.




Most VHF radios need 100 to 150 milliseconds to come õp to power, or  full output. Én addition, there is the key-up time for the Linear amplifier . This too is measured in milliseconds. The key-up time for the power amplifiers varies from 50 ms to 150 ms, depending ïn the type and number of relay(s) used inside the Linear.

  Since most TNC and data-controller ÔXD time is measured in 10 millisecond blocks, we use the sum of all the times listed above and divide by 1 0. Our answer is somewhere between 20 and 30, give or  take 5 (50 ms). Since we want to be ïn  the safe side and also consider the time it takes the receiving station to open its squelch, we “take” the 5 ms.

Let's enter this number 35 into the TNC with the ÔXD command (TXD 35), and quite possibly this TXD will allow the connect  to that distant station to hold. This time the ACK from the connected station will not let us retry out.

 

lightbar.gif - 11170 Bytes

 

FRame ACKnowledge (FRACK)

 

We can make this TNC command short and sweet, or  we can complicate it to the greatest possible level. I 'm for reducing the complications within  the command structure of the packet TNC. Ôïo often I see new writers going after the complicated rendition of the TNC commands, only to end õ  confusing themselves.

Packet radio is very easy to use, and as long as we keep it this way, we all will benefit from it and more users will enter its ranks.

 

FRACK should never be set below 3!

FRACK has a rule of order that can be used in the following manner. If you are about to connect to a friend who is 3 nodes away, add that number to the TNC setting of 3; thus we have 6. If the station to which you wish to connect is only one node away , use that number to add to the TNC FRACK of 3 (3 + 1 = 4). This is the manner with which I make the system work for me, and at the same time it "un-complicates" the FRACK command for us.

 

lightbar.gif - 11170 Bytes

 

DWait (Digipeater Wait)

 

DWait was once the means used to allow the radio/TNC combination to handshake ith each other . It was considered by many users that DWait was used toallow the AGC to recover after returning to the receive mode from the transmit mode.

 

In a sense, this thought has some merit, because if you set the DWait too short, you may discover that the receiver in your radio will be unable to recover fast enough to allow the first of each received packet to get to the TNC on time. That is the long xplanation. Following is the real purpose of the DWait command. The DWait command is a command agreed upon by all members of a Local Area Network (LAN). This is why it is good to have packet users groups, or  a packet club where the LAN members can meet so that issues of this kind can be talked through and agreed upon by the users of the LAN. Ây  so doing the LAÍ members are establishing a means to reduce the number of collisions. Even with the new "anti-collision" features in many of the TNCs, we must remember that all LAÍ users do not have this new feature in their TNC. Most TNCs support a DWait of 16 as the default setting, but we have found that a DWAIT on our LAN of 8 to 12 is suitable for our needs and for use when downloading files from the local BBS.

 

lightbar.gif - 11170 Bytes

 

PACLen

 

Let's really uncomplicate these final two commands. I can bet on at least 40 letters from some of my friends and some users who are old-timers (or who think they are) giving me "the dickens" or a rebuttal about these next two commands. I'm about to simplify these two commands to the point of possible over-simplification. Over-simplification of a command is not to the liking of a few users.
They feel that because their early packet, days were difficult, so should be every one else's.
Ío  one has more reason to complain about those days than I do, but who wants to complain?   Even in those days we were having fun with packet.

The only difference between packet  radio now and then is now we have more packeteers with whom to QSO, and the terminal program features have given us a medium that is far more than the  ÔYPE”  and  “SEND"  system of six or  seven years ago.

Now that the history lesson is over, let's get to the PACLen setup of the TNC.
There are three simple rules for this command, and they are:

 

  1. When using nodes or digipeaters on VHF, set PACLen 128 (normal default of most TNCs).

 

2. When using direct connects, and with near perfect connect paths, set PACLen 255 (some TNCs accept PACL 0 as 255).

 

3. When operating HF packet, set PACLen 32 for300 b/s or  PACLen 64 for 1200 b/s. (Note: 1200 b/s is Iegal above 28 Ì HÆ).

 

 

lightbar.gif - 11170 Bytes

 

 

MAXFrame

 

Again, let's not complicate the commands any more than we have to. This is another of the "throughput' , timing commands in the TNC which can be made into a monster. Let's use some common sense and simplify its use by applying two simple and easy-to-remember rules for its use.

 

1.               When operating VHF, use the (default) value of  4. If connected direct with good connect path and no other traffic, use MAXFrame 7 .

 

2.     When using the HF bands, good or favorable conditions use 2 FAIR,

or  poor conditions use 1.

 

 

 

                                 9600 BAUD PARAMETERS

 

   As you'd expect, the parameters we all know and love at 1200 baud don't work very well at 9600 baud.  These are what we've found work well at 9600.

 

                                 AX.25 PARAMETERS

 

TXDelay…….between 8 and 15 - set for best throughput BUT that depending upon your RIG. Several commercial rigs they don’t accepts TXD less than 25-30 because they needs enough time to "LOCK-on" the PLL unit, otherwise the TX signal is unusable. Of course, if you want that values (8-15), we talking for modern Transmitters using PIN-diodes and very fast PLL-units for RX-TX swithces and NOT for RIGs with Relays in the output and slllooowwww PLLs... Relays and slow-PLLs have extremely large values between RX-TX, which that means Hi-Value TXD settings!

 

RESPtime …..100 mS seems to have better results than 0

 

Frack……….. 8 seconds on a busy channel; but never less than 5 sec

 

PERSIST…….128/users; if it's a pretty clean channel, 64 is nice; if it's busy, guesstimate the average number of users and divide 128 by this number, i.e. 4 users = 128/4 = 32

 

SLOTTIME… 20

 

MAXFrame… If the channel is great, 7; average, 3; rough, 1

 

RETry……….15

 

Check………. 300 seconds