TNC-PI TXdeley - was Re: Routing issue?


John G8BPQ
 

James,

 

As you correctly say, the range of TXDelay in the TNC-PI is 1 to 255, but the units aren’t milliseconds, they are characters - the number of flags sent before the data. So the maximum is about 1.7 seconds (255 * 8 /1200).

 

The rest of the paragraph doesn’t make sense. It seems to totally misunderstand the concept of CSMA. The TNC won’t switch the radio to transmit mode until the channel is sensed as clear even if the host has added more frames to the mac queue in the TNC.

 

I agree that the VOX system of radios designed for speech rarely works well for packet, as the hold time is usually far too long (thus requiring excessive TXDelay in the responding station). Tone sensing PTT circuits designed for data (sometimes called VOX) are a different story.

 

73,

John G8BPQ

(Designer of TNC-PI)


From: Raspberry_Pi_4-Ham_RADIO@... [mailto:Raspberry_Pi_4-Ham_RADIO@...]
Sent: 01 August 2017 00:23
To: Raspberry_Pi_4-Ham_RADIO@...
Subject: [Raspberry_Pi_4-Ham_RADIO] Re: Routing issue?

 

 

In regard to the timing issues, let me show an example why some hardware TNCs do not fit the IP networking scenarios discussed in this thread.

The maximal TXDelay of TNC-Pi is only 255 per pitnc_setparams utility.  The value is calculated by 256-modulo addition.  For example, if you do "pitnc_setparams 1 0 1 256", it will be 0; 257 equals 1, etc.   And the time unit is milli-second (as the Slottime field explicitly says "in 10 mS", but TXDelay field doesn't say so, also the empirical sense of time confirms it is in mS, not in 10 mS).    A separated TNC with maximal 255ms TNC-TXDelay can hardly cope with the transmission delay (which is also called TX delay in many contexts, but it refers to frame-length-in-bits divided by transmission rate, not the TXDelay used in TNC) of a 90-byte ping packet over a 1200bps channel.  Obviously it is designed for uni-directional transmission without expecting the coming back ACK/response traffic.     The transmission sequence of a 90-byte packet is at least 720 bits long (without counting overheads like the frame header and physical sync sequence), and the corresponding transmission delay on a 1200bps channel is at least 600ms.    This implies that, when the ping response comes back at the ping requester/sender side radio, it will incur 600ms delay to keep the sender radio in receiving mode.   But the sender side TNC's waiting time is less than 256ms.  At 256ms timeout or later, any frame in the MAC queue could be sent to the radio and collide with the receiving ping response.

Then I have to switch to software TNC so that it is possible to use larger TNC TXDelay (TNC TX waiting time).  In order to cope with VOX delay, the transmission delay in the above example is increased from 600ms to 1000ms, then still no coming back traffic as the IP protocol stack is upset by this long latency (i can see from wireshark the ping request is successfully received, but no ping response is firing back).  To make the thing worse, lots of the timeouts in the TCP/IP protocol stack is not adjustable at user level, you have to modify the kernel source code and rebuild the kernel to update the value, and the updated value is not guaranteed to work.   Well, you do the math.

Finally by using hardwired PTT to get rid of VOX, I figured out a TNC TXDelay around 750ms will get the job done with near optimal result.   The TCP (by wget or ftp) goodput can be as large as 140 byte-per-second (1120bps) over the 1200bps AFSK channel.  If the extra delay caused by VOX is added back by DCD, I expect that things go back to the case described in the previous paragraph.

However, if the DCD/CS delay is only a few milli-seconds, like what happens in 802.11 or some DMR radios, then it will be a different story.

Best Regards,
James Kong, KM6JNN

Join RaspberryPi-4-HamRadio@groups.io to automatically receive all group messages.