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

 

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