Date   

Re: TNC-PI TXdeley - was Re: Routing issue?

 

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





Re: TNC-PI TXdeley - was Re: Routing issue?

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



Re: TNC-PI TXdeley - was Re: Routing issue?

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



Re: TNC-PI TXdeley - was Re: Routing issue?

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


Re: TNC-PI TXdeley - was Re: Routing issue?

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


Re: TNC-PI TXdeley - was Re: Routing issue?

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



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


Re: Routing issue?

jiejun.kong@...
 

Hi Jim,

Thanks.  I am trying to build a MANET (mobile ad hoc networks) using ham radios.  Glad to have you try for it.

Warm Regards,
James Kong, KM6JNN


Re: Routing issue?

jiejun.kong@...
 

Hi David,

This very article says "Note that these tests are done with squelched receiver for convenience of triggering the data logger, normal operation is with open squelch wich the TNC-X supports."

I think by the very sentence the author really means his practice won't affect the validity of his conclusion.

" I still argue that squelch is NOT the same as the DCD recognition. "

I never said squelch is the same as the DCD recognization.  I said DCD is an RS-232 counterpart of CS (carrier sensing in medium access control protocols).

"TXDelay and TNC"

See more details in my previous reply to Bill.  It is complicated, but I believe the status quo of TNC design can be improved to be more friendly to bi-directional IP traffic.

"802.11, OFDM and DTN"

802.11b uses BPSK,QPSK,QAM16 and QAM64.  802.11a, 802.11g, 802.11n etc. use OFDM which in turn uses BPSK,QPSK,QAM as its sub-channel building blocks.   It is kind of distractive to get into such details.  What I meant by referring to 802.11 is that the 802.11 radios carrier-sensing latency (of ALL 802.11-conforming radios) is very short (measured by 1024micro-seconds ~1ms) and its impact to the IP protocol stack is negligible.  If this assumption is true for all (or most) ham radios, I guess we don't need squelch in ham radios as well.

My research group worked with Kevin Fall's DTN group some years ago.  It is a different topic.  Delay-tolerant basically means that the "store-and-forward" packet switching (which is the reason of inventing the TCP/IP Internet when circuit-switching telephone network was the only option in 1960s) can have an alternative approach by emphasizing on the "store" part.   As the hardware storage technology gives us cheap TB harddrives, we can go around to collect all data and store as much as we can, then forward them when the network is available.   This approach is not friendly to data traffic with real-time constraints.

Best Regards,
James Kong, KM6JNN

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


Hello James,


Here is an interesting article about TNC misbehaviors causing DCD failures.  TNC-X ( http://www.tnc-x.com ) and Argent Data OT3 ( https://www.argentdata.com/catalog/product_info.php?products_id=155 ) are incompatible with each other in regards to DCD.   


This may explain another reason why open squelch leads to performance degeneration.

This very article says "Note that these tests are done with squelched receiver for convenience of triggering the data logger, normal operation is with open squelch wich the TNC-X supports."  I still argue that squelch is NOT the same as the DCD recognition.  With that said, I do agree with that article that some of the preamble signatures from these PIC-based TNCs are wrong but as long as their TXDELAY is long enough, most TNCs will essentially ignore the tones and properly sync up once they sync on the HDLC pattern.  Can this lend other TNCs to transmitting nearly at the same time as the improper TXDELAY header from the poor TNCs?  Maybe but relying on squelch alone isn't good either due to variable suburban noise levels.


I've never heard of the term "squelch" in IP protocol stack (e.g., no such thing in mac protocol CSMA design).  If ham radio and TNC are fused together as a single-board device and related carrier sensing standards are enforced, like what happens in the 802.11wifi industry, I totally agree we would be able to get rid of squelch as well.

You're incorrectly mixing technologies here.  Packet, as *commonly* found on one packet frequency is an audio frequency technology in half duplex mode.  That means one transmitter at any one time.  802.11 is also a half duplex technology but with very wide bandwidths, very short transmit times, with many overlapping OFDM carriers (https://en.wikipedia.org/wiki/IEEE_802.11#General_description).  It should also be noted that AX.25 is the base transport  regardless if you're running basic layer-2 AX25 data [different layering than the classic OSI model) which is a classic connected session, layer-3 AX.25 connection (an AX.25 connection over Netrom), etc. 

If you really want to do networking over packet radio (and you're willing to deal with the protocol overhead and delays), you should consider changing part of the stack to DTN:

   https://www.google.com/search?q=delay+tolerant+network+over+AX.25+packet+radio&oq=delay+tolerant+network+over+AX.25+packet+radio

--David
KI6ZHD

 


Re: Routing issue?

jiejun.kong@...
 

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


Re: Help for the noob: I can't receive stations for chatting on Packet

David Ranch <dranch@...>
 


 
Any terminal program you can install 'should' be able to interface with your tnc-x as long as you know what port and /dev module to connect to. At least in theory and from personal use years ago with jnos.

The TNC-X device is a KISS only TNC which means you can't just use any old serial terminal program (minicom, screen, Putty, whatever) to interface with it.  You have to use another software stack to interface with it be it the Linux kernel AX.25 stack, JNOS and it's own AX.25 stack, etc.

--David
KI6ZHD


Re: Help for the noob: I can't receive stations for chatting on Packet

James French
 

Any terminal program you can install 'should' be able to interface with your tnc-x as long as you know what port and /dev module to connect to. At least in theory and from personal use years ago with jnos.

Actually used the original dos aprs program after it came out to dial a landline 56k modem and download a proper modem software from a chat bbs as I had corrupted the original terminal program file on the 386s' 20meg hard drive and didn't have a backup disk on hand. Was the only thing I had handy at the time.

James W8ISS 


Re: Routing issue?

wb4jfi
 

Not really accurate.  In the old days, we used to run radios with squelch.  Granted, the Tx/Rx transition took longer, but with older radios and actual Dataphone 1800 modems, or other Bell 202 style modems at the time (WB4APR modified modems, EXAR chips, etc), there was enough false-positives with the random noise, that it drastically affected/held-back a TNC from transmitting.  An extended period of flags was used, which also helped lock the receiver up.

This from someone that use the original Vancouver TNC board, Dataphone 1800 Bell 202 modem, and Kenwood 7400 radio.  And a lot of stuff newer than that.

I'm not saying that this is the best method now, but clarifying history.  Also, some radios are good for packet, and some are not.

73, Terry, N4TLF (formally WB4JFI, AX.25 principal architect)



Re: Routing issue?

Jim WB9QPM
 

Hi James,

The basic squelch used in packet radio is simply the received signal strength. 
It is generated in the radios receiver.
Normally used to un-mute the speaker.

DCD or Data Carrier Detect is just an acknowledgement that the modem chip
in the TNC has a valid data stream.
In simple terms it tells the state machine in the TNC to process the data.

DCD and squelch are two different birds in the same tree. 

The seven layer OSI model does not apply directly to packet. 
There are common areas, but the TCP model we use is a four
layer model. The two models overlap somewhat, but are not
the same.

We use AX.25 routing, Net/ROM routing and IP routing depending
need. 

The only thing packet has in common with the other transmission schemes
(Ethernet, WiFI, CDMA, et all) is data being moved in packets or frames.

As hams, we experiment. Is our model a mess, most likely. Does it work,
absolutely.

Have fun. Invent something new. I'll give it a shot.

73,
Jim WB9QPM









Re: Help for the noob: I can't receive stations for chatting on Packet

Alejandro Gómez García <agomezmv@...>
 

Thanks for the help David  and Ryan. Installed LinPac and works like a charm!

El jul 29, 2017 3:25 PM, "Ryan Tourge ryan.tourge@... [Raspberry_Pi_4-Ham_RADIO]" <Raspberry_Pi_4-Ham_RADIO@yahoogroups.com> escribió:
 

He would only connect to you for service such as mailbox or something like that. other wise you just type back and forth in converse mode. 

On Sat, Jul 29, 2017 at 4:34 PM, agomezmv@... [Raspberry_Pi_4-Ham_RADIO] <Raspberry_Pi_4-Ham_RADIO@yahoogroups.com> wrote:
 

Hello all. Newbie here on RPi and TNC-Pi. 


I have been trying to find out how to accept a conversation request when somebody calls at my station. I am using Debian and basic setup from TNC-Pi manual. TNC and radio are working fine, I can connect to other BBS's no problem. But if someone calls me he gets the terminal window and I get nothing, I only notice the other station calling my station from traffic monitoring but don't know how to proceed...


If I call another station, then the other station can start chatting with me no problem. Local hams are working on other platforms so they can't help me.



73's from Alejandro, TI2DYS 




Re: Routing issue?

David Ranch <dranch@...>
 


Hello James,


Here is an interesting article about TNC misbehaviors causing DCD failures.  TNC-X ( http://www.tnc-x.com ) and Argent Data OT3 ( https://www.argentdata.com/catalog/product_info.php?products_id=155 ) are incompatible with each other in regards to DCD.   


This may explain another reason why open squelch leads to performance degeneration.

This very article says "Note that these tests are done with squelched receiver for convenience of triggering the data logger, normal operation is with open squelch wich the TNC-X supports."  I still argue that squelch is NOT the same as the DCD recognition.  With that said, I do agree with that article that some of the preamble signatures from these PIC-based TNCs are wrong but as long as their TXDELAY is long enough, most TNCs will essentially ignore the tones and properly sync up once they sync on the HDLC pattern.  Can this lend other TNCs to transmitting nearly at the same time as the improper TXDELAY header from the poor TNCs?  Maybe but relying on squelch alone isn't good either due to variable suburban noise levels.


I've never heard of the term "squelch" in IP protocol stack (e.g., no such thing in mac protocol CSMA design).  If ham radio and TNC are fused together as a single-board device and related carrier sensing standards are enforced, like what happens in the 802.11wifi industry, I totally agree we would be able to get rid of squelch as well.

You're incorrectly mixing technologies here.  Packet, as *commonly* found on one packet frequency is an audio frequency technology in half duplex mode.  That means one transmitter at any one time.  802.11 is also a half duplex technology but with very wide bandwidths, very short transmit times, with many overlapping OFDM carriers (https://en.wikipedia.org/wiki/IEEE_802.11#General_description).  It should also be noted that AX.25 is the base transport  regardless if you're running basic layer-2 AX25 data [different layering than the classic OSI model) which is a classic connected session, layer-3 AX.25 connection (an AX.25 connection over Netrom), etc. 

If you really want to do networking over packet radio (and you're willing to deal with the protocol overhead and delays), you should consider changing part of the stack to DTN:

   https://www.google.com/search?q=delay+tolerant+network+over+AX.25+packet+radio&oq=delay+tolerant+network+over+AX.25+packet+radio

--David
KI6ZHD


Re: Routing issue?

 

DCD-capable TNCs don't care if you are running unconnected mode, connected
ax25 layer 2 or 4, ip-over-ax25, aprs, or whatever, but the physical limits
such as the large processing latency and TCP/IP timeouts will cause big
problems. When discussing IP networking instead of APRS style ham
applications, many ham digital communication approaches need rechecks and
revisions as the underlying assumptions have changed a lot.
We hams were doing IP networking on AX25 1200 baud packet long before
APRS was invented.. TCP timeouts and retries of seconds or tens of
seconds was not uncommon. Running open squelch with carrier detect
was preferred as it improved reliability and reduced necessary delays
on the lowest level - AX25 packet - of the system.

Bill, WA7NWP


Re: Routing issue?

jiejun.kong@...
 

"Most TNC hardware built in the last 25 years uses DCD to eliminate the need to run the radio squelched. This doesn't effect the TXDelay. "

Here is an interesting article about TNC misbehaviors causing DCD failures.  TNC-X ( http://www.tnc-x.com ) and Argent Data OT3 ( https://www.argentdata.com/catalog/product_info.php?products_id=155 ) are incompatible with each other in regards to DCD.   


This may explain another reason why open squelch leads to performance degeneration.

I've never heard of the term "squelch" in IP protocol stack (e.g., no such thing in mac protocol CSMA design).  If ham radio and TNC are fused together as a single-board device and related carrier sensing standards are enforced, like what happens in the 802.11wifi industry, I totally agree we would be able to get rid of squelch as well. 

Best Regards,
James Kong, KM6JNN


Re: Routing issue?

jiejun.kong@...
 

"With data radios (TEK etc) this is a few ms. With PLL radios this could be 500 ms or more. "

I think the processing latency from a VHF/UHF radio to a separated TNC is hundreds of milliseconds (like 500 ms as you said).    By TEK you mean TEKK?  I haven't yet tried a TEKK radio. It seems to me that such a radio must have a built-in TNC fused together with the radio to reduce the processing latency to several milli-seconds.  You don't need a separated TNC-X or TNC-Pi as the TNC is built-in.

Best Regards,
James Kong, KM6JNN


Re: Routing issue?

jiejun.kong@...
 

I think you are talking about the concept of "carrier sensing"(CS) in the multiple-access (MA) problem of MAC (Medium Access Control) protocols, which is common to ISM band radios such as the popular 802.11wifi.
In ISM band radios, the link layer (layer 2) and the physical layer (layer 1, the radio) are typically fused together as a single waveform device (or in other words on a single motherboard).  Unlike this practice, in ham radios the link layer(TNC and AX25) and the radio are separated.   This separation makes it very difficult to control the medium access.

For example, DCD is an RS-232 counterpart of the abovementioned CS.  But due to the separation of TNC and radio, the processing latency will be in the scale of nearly a second (or hundreds of milli-seconds), which is two or more orders of magnitude larger than the single motherboard approach.  Like the VOX problem, this will likely mess up with multiple timeouts in the IP protocol stack which normally assumes the global round-trip-time(RTT) is less than 500 milli-seconds (e.g., a ping delay from USA to Russia is less than 300 milli-seconds) and times out accordingly.     Surely the DCD-capable TNCs don't care if you are running unconnected mode, connected ax25 layer 2 or 4, ip-over-ax25, aprs, or whatever, but the physical limits such as the large processing latency and TCP/IP timeouts will cause big problems.  When discussing IP networking instead of APRS style ham applications, many ham digital communication approaches need rechecks and revisions as the underlying assumptions have changed a lot.

Best Regards,
James Kong, KM6JNN 
 

7061 - 7080 of 14145