[nos-bbs] Collision avoidance

[George (Skip) VerDuin]

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.

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

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.
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.

My questions to this group becomes: 
Is it TNC (in KISS mode) responsibility to avoid transmitting over
on-going traffic?  
It certainly can not be jnos without "carrier detect" signal on RS-232.
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?


73
de Skip k8rra k


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060810/99680723/attachment.html>