Re: TNC-PI TXdeley - was Re: Routing issue?
What Tadd says is true but irrelevant. He says how it is usually
implemented. The fact is that the TNC-PI does things differently. He does
however point out that the TNC-PI (along with the TNC-X, from which it is
derived) can set TX delay via an analog potentiometer rather than by KISS
command. With this method it has to be set empirically, as there is no
calibration of the pot.
All TNCS, not just the TNC-PI, send audio to the radio during the TXDelay
period. TXDelay is the time between asserting PTT and starting to send the
real data. Although it could be any tone, the ax.25 spec calls for flags to
be used for time fill, and that is what almost all TNCs send. It may be
unusual to time that process by counting the number of flags sent than by
counting millisecond interrupts, but it is simpler to implement. More
importantly on a processor like the PIC with limited programming space it
needs fewer instructions.
Sent: 02 August 2017 08:18
Subject: [Raspberry_Pi_4-Ham_RADIO] Re: TNC-PI TXdeley - was Re: Routing
What I saw about TNC TXDelay's time unit is different from what you
described here. Tadd Torborg, who has also participated in the discussion
here, has a webpage about this topic
"Usually TxDelay is measured in n milliseconds (1/1000ths of a second) or in
10s of milliseconds (1/100ths of a second)" and TNC-Pi is also mentioned at
the end of the page.
It seems that you are saying TNC-Pi must send (or pretend to send) some
dummy bytes to its audio output to emulate a timing latency. Though this is
possible, it is kind of weird to implement timing parameter in this manner,
as we already know that TNC-Pi does have two built-in timing crystals X1 at
3.57MHz and X2 at 20MHz.
We'd better let John Hansen, W2FS confirm on this point. Last time I conta
cted him to ask for the pitnc_getparms and _setparms utilities as the
weblinks he offered in TNC-Pi manual have expired. He didn't reply to me, I
didn't know what happened to him, so finally I had to download the utitilies
from somewhere else. Anybody here knows him personally and can forward the
message to him? Hope this message will find him in good health and spirit.
As to the DCD problem, I am attaching a drawing here to explain it one more
last time. Here the DCD problem is never about the collision, but about the
extra latency introduced. If DCD is fast, then everything is okay.
James Kong, KM6JNN