[nos-bbs] Collision avoidance

Thu Aug 10 23:08:13 EDT 2006

Greetings Skip,

On Thu, 10 Aug 2006, George (Skip) VerDuin wrote:

> As I go deeper into jnos operation, I am now beginning to look in detail
> at signals on vhf radio. Not by any means the best, but I find
> "Baudline" fairly useful for that purpose.
> 
> What I see makes me the "bad guy" of the neighborhood. I believe I see
> my station colliding with on-going traffic in situations that "should
> be" avoidable. I hope this group can shed some light on remedial action
> I can take.

   This tells me that your TNC is not detecting the other packets that are 
on the air and transmitting on top of them.

   Things to check:
      1) Your receive audio level.  Too low or too high may distort the 
         received data causing the TNC's modem to not recognize the signal 
         as valid data.

      2) Mis-aligned demodulator (modem).  Run the CALIBRAte routine in 
         your TNC and confirm it is properly aligned.

      3) TNC is using "hardware DCD" verses "Software DCD".
         - In Hardware DCD, the modem simply looks for *ANY* signal (or 
           noise) from the receiver that looks like a 1200Hz or 2200Hz 
           tone.  This style of DCD does not know the difference between a 
           burst of noise and valid data.
         - In Software DCD (or the TAPR DCD Mod Kit), the modem passes 
           everything it demodulates to a State Machine that determines if 
           there is actually a "data stream" present.  If there is, it 
           will then assert the DCD signal.  This mode is preferable as 
           the squelch on your receiver can be left WIDE OPEN thus 
           eliminating the time a signal takes to quiet the FM receiver 
           and then allow the squelch gate to open the audio path between 
           the detector and the audio stage. WAY faster capure rate and 
           far greater noise imunity.

      4) *OPEN* your squelch.  *WIDE* open!  There is no need to use 
         squelch (and thus slow down the responsiveness of the receiver) 
         if you are using "software squelch" (decoding a data stream as 
         opposed to just 1200Hz and 2200Hz tones)

Please see John Ackermann's (N8UR) fine paper on: Let's Not Forget Layer One!
http://www.febo.com/packet/layer-one

> As an example tonight: MKG and GKF, GKF-15 and MSE-7, are two links
> engaged in exchanging AX.25 packets (no IP encap).

   Gosh I would hope not!  IPIP Encap should exist *ONLY* across Internet 
connections and *NEVER* over the air.  But that's a whole 'nother 
discussion...

> The frames are long, packing up to 4 (maybe more) packets, one frame
> measures longer than 13 seconds at 1200B. The excanges are going on for
> over a minute with 1 second dead air times (maybe 250ms minimum)

   Sounds like the NetROM folks need to adjust their settings to be less 
agressive and more polite about channel sharing.  Perhaps they can lower 
their MAXFRAME from 4 to 1 to allow other stations to share the channel.

> then my station "chimes in"... I see my station both broadcast and
> NET/ROM node share on top of a GKF-15 _> MSE-7 frame after two packets
> but clobbering the tail-end of the frame with two one-second frames.  I
> do not know when jnos dispatched the packets/frame, I do see the audio
> sent to the Kantronics 9612 TNC and the jnos trace received by jnos.  
> Because of the tight match of audio to trace I suspect there is no delay
> after dispatch before transmit.

   When you say "the audio sent to the TNC" do you mean that you "hear"  
the audio coming from the receiver, and perhaps you can correlate that
'audio' with the DCD light on the TNC, thus confirming that themodem
detected valid data (or the 1200Hz or 2200Hz tones, anyway)?

   JNOS will send a KISS frame across the serial cable to the KISS-TNC for 
transmission.  The KISS-TNC waits for the channel to be available by 
watching for Data Carrier Detect (DCD).  If the channel is clear, the 
KISS-TNC begins sending SYNC characters (7Ehex), asserts the PTT line, 
continues sending SYNC until the TXDELAY timer expires, then sends the 
actual Packet, ending with a few more SYNC characters, then drops PTT.

   If the KISS-TNC detects that the radio channel is busy (it sees DCD) it 
will simply hold the packet in memory until the channel becomes clear.  
THERE IS NO HANDSHAKING IN KISS TO INFORM JNOS THAT THE CHANNEL IS BUSY 
AND THE PACKET HASNOT BEEN SENT.  So if the Frame Acknowledge (FRACK) 
timer in JNOS expires, it *WILL* send a duplicate KISS frame to the 
KISS-TNC for transmission.

> One potential flaw in my analysis comes from recording at my own
> transciever - I'd be 100% certain at a remote location hearing all 5
> sta.

   Whadya mean, "recording at my own transciever"???  That makes no sense 
to me...sorry...

> However I'm pretty certain my view is accurate even with the limitation.
> 
> So - in seeing the above, I'm pretty certain my TNC is failing to detect
> "channel not busy" prior to activating the T/R switch.

   Again, this can be due to any of the possible problems I outlined at 
the beginning of this email.

> My questions to this group becomes: 
> Is it TNC (in KISS mode) responsibility to avoid transmitting over
> on-going traffic?  

   Yes!  The TNC's modem should detect any possible data activity that is 
picked up by your receiver and control when it will allow your transmitter 
to be keyed up.

> It certainly can not be jnos without "carrier detect" signal on RS-232.

   KISS does not use DCD on the serial cable.  DCD as explained earlier, 
is the responsibility of the KISS-TNC.

> I hope it is tuneable and I have made a configuration mistake - or must
> I toss out and replace the TNC?
> 
> I want to treat the RF space fairly - I suspect I'm not doing a good job
> of it. Right?

   Check out the things I suggested and I'm sure you will figure out why 
your TNC is transmitting when it shouldn't.

      --- Jay WB8TKL

"Getting rid of terrorism is like getting rid of dandruff.  It cannot
 be done completely no matter how hard you try." -- Gore Vidal
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)544-4326/Fax        |
| Nugent Telecommunications  [www.nuge.com]     (734)649-0850/Cell       |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net]   Registrar of the .linux TLD        |
+------------------------------------------------------------------------+
 10:01pm  up 208 days, 22:55,  4 users,  load average: 0.04, 0.05, 0.00
-------------- next part --------------
_______________________________________________
nos-bbs mailing list
nos-bbs at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs