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


JJ
 

I will add that some radios (like the IC-756) allow setting the VOX delay to zero!! Verified here and works well on HF 20m 300b lsb and 10 meters 1200b FM..


On 2017-08-01 07:08 AM, 'John Wiseman' john.wiseman@... [Raspberry_Pi_4-Ham_RADIO] wrote:
�

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



jiejun.kong@...
 

Hi John,

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  http://tarpn.net/t/faq/faq_txdelay.html
 
"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 contacted 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.

 
Best Regards,
James Kong, KM6JNN


John G8BPQ
 

James,

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.

73,
John


________________________________________
From: Raspberry_Pi_4-Ham_RADIO@yahoogroups.com
[mailto:Raspberry_Pi_4-Ham_RADIO@yahoogroups.com]
Sent: 02 August 2017 08:18
To: Raspberry_Pi_4-Ham_RADIO@yahoogroups.com
Subject: [Raspberry_Pi_4-Ham_RADIO] Re: TNC-PI TXdeley - was Re: Routing
issue?

 
Hi John,

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
 http://tarpn.net/t/faq/faq_txdelay.html
 
"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.


https://ibb.co/jRwwEk
 
Best Regards,
James Kong, KM6JNN


JJ
 



On 2017-08-02 06:01 AM, 'John Wiseman' john.wiseman@... [Raspberry_Pi_4-Ham_RADIO] wrote:
 

James,

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.

Actually, not just any tone, but valid tones to assert DCD in any other TNC within hearing range so that collisions do not occur...

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.

73,
John

________________________________________
From: Raspberry_Pi_4-Ham_RADIO@...
[mailto:Raspberry_Pi_4-Ham_RADIO@...]
Sent: 02 August 2017 08:18
To: Raspberry_Pi_4-Ham_RADIO@...
Subject: [Raspberry_Pi_4-Ham_RADIO] Re: TNC-PI TXdeley - was Re: Routing
issue?

 
Hi John,

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
 http://tarpn.net/t/faq/faq_txdelay.html
 
"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.

https://ibb.co/jRwwEk
 
Best Regards,
James Kong, KM6JNN



John
 

Sorry to be late to the party.  I did get the link to the pitnc programs fixed several months ago.  I'm sorry I missed your email.  It may be because I received several emails about this and may have thought I had responded to all of them.  John Wiseman is correct about the implementation of TXDelay.  Either flags (0x7E) or zeros (0x00) have been used for this since the beginning of packet.  For a deep dive into this see:

PIC-et Radio: How to Send AX.25 UI Frames Using Inexpensive PIC Microprocessors (1998):


It doesn't make much sense to try to set the TXDelay precisely because the optimum value is determined by the T/R turnaround speed of the receiver.  In most cases with packet, you don't actually know who the receiver is or what radio is being used.  This is why I originally implemented the TXDelay value as a potentiometer... it made it very easy to do quick adjustments so you could experiment with it.  

John Hansen W2FS
Coastal ChipWorks



On Wed, Aug 2, 2017 at 3:18 AM, jiejun.kong@... [Raspberry_Pi_4-Ham_RADIO] <Raspberry_Pi_4-Ham_RADIO@...> wrote:
 

Hi John,


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  http://tarpn.net/t/faq/faq_txdelay.html
 
"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 contacted 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.

 
Best Regards,
James Kong, KM6JNN



 

I’m a little confused by this discussion.

James Kong, KM6JNN  wrote:
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.  


My text on FAQ-TXDELAY was about a TXDELAY figure that is used, not to emulate timing latency, but to overcome switching latency on the transmitter end.  
The lead-in characters sent during the TXDELAY interval on my professional systems are the same signals used to sync the target packet receiver under the notion that additional syncing opportunity could help and doesn’t hurt.   In addition the sync data would be detected by target packet receivers as Data Carrier.  I presumed they were that way in ham radio packet.  Are they not?  

On 2017-08-02 06:01 AM, 'John Wiseman' john.wiseman@... [Raspberry_Pi_4-Ham_RADIO] wrote:
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

I did not know that the TNC-PI used characters instead of time to parcel out TxDelay duration but I certainly won’t add that to the FAQ-TXDELAY page.  The explanation for what that is about would double the length of the FAQ answer!   My target audience varies wildly from professional coders of processors used in digital radio to people who have never heard of a modem or used packet radio, linux, a soldering iron, or even a transmit antenna before this project.  

For the sake of those who participate in the Raspberry_Pi_4-Ham_Radio page, it would be handy to review what this topic is about.    Are we trying to delay transmit on one end so the receiver can get around to listening again?  Why does TXDELAY need to be precisely configured?  In my ham radio packet experience the TXDELAY just needs to be long enough for the transmitter to get on-the-air and maybe a smidgen longer (precise time unit here) so the receiver can sync to the incoming packet.  

Thanks for elucidating!  

Tadd Torborg/ KA2DEW
Raleigh NC  FM05pv

“Packet networking over ham radio": http://tarpn.net/t/packet_radio_networking.html

“Raleigh-centric ham radio resources page": http://torborg.com/a





jiejun.kong@...
 

Hi Tadd,

Sorry I missed one sentence after quoting your webpage.  I should add "Unlike the quoted description" before "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."       What John described is not a timing parameter directly obtained from clock mechanisms, but derived from 255 bytes PHY transmission delay over a 1200bps channel (255*8bits/1200bit-per-second= 1.7second)

Best Regards,
James Kong, KM6JNN

---In Raspberry_Pi_4-Ham_RADIO@..., <tadd@...> wrote :

I’m a little confused by this discussion.

James Kong, KM6JNN  wrote:
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.  


My text on FAQ-TXDELAY was about a TXDELAY figure that is used, not to emulate timing latency, but to overcome switching latency on the transmitter end.  
The lead-in characters sent during the TXDELAY interval on my professional systems are the same signals used to sync the target packet receiver under the notion that additional syncing opportunity could help and doesn’t hurt.   In addition the sync data would be detected by target packet receivers as Data Carrier.  I presumed they were that way in ham radio packet.  Are they not?  

On 2017-08-02 06:01 AM, 'John Wiseman' john.wiseman@... [Raspberry_Pi_4-Ham_RADIO] wrote:
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

I did not know that the TNC-PI used characters instead of time to parcel out TxDelay duration but I certainly won’t add that to the FAQ-TXDELAY page.  The explanation for what that is about would double the length of the FAQ answer!   My target audience varies wildly from professional coders of processors used in digital radio to people who have never heard of a modem or used packet radio, linux, a soldering iron, or even a transmit antenna before this project.  

For the sake of those who participate in the Raspberry_Pi_4-Ham_Radio page, it would be handy to review what this topic is about.    Are we trying to delay transmit on one end so the receiver can get around to listening again?  Why does TXDELAY need to be precisely configured?  In my ham radio packet experience the TXDELAY just needs to be long enough for the transmitter to get on-the-air and maybe a smidgen longer (precise time unit here) so the receiver can sync to the incoming packet.  

Thanks for elucidating!  

Tadd Torborg/ KA2DEW
Raleigh NC  FM05pv

“Packet networking over ham radio": http://tarpn.net/t/packet_radio_networking.html

“Raleigh-centric ham radio resources page": http://torborg.com/a