[nos-bbs] Collision avoidance
George (Skip) VerDuin
k8rra at ameritech.net
Fri Aug 11 10:40:51 EDT 2006
Thanks for the analysis Jay,
Here is a little more info...
AND a probably solution at the end!
On Thu, 2006-08-10 at 23:08 -0400, Jay Nugent wrote:
> 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.
Not adjustable actually - fixed output voltage level after squelch is
broken. FYI: The open squelch signal has higher peaks (93db) than a
packet signal (87db) but the frequency distribution is "white noise" vs
spread between 1100hz and 2300hz. If you are interested in the fft
analysis, I'll send you a picture (I presume the reflector etiquette
frowns on attaching it here).
>
> 2) Mis-aligned demodulator (modem). Run the CALIBRAte routine in
> your TNC and confirm it is properly aligned.
I selected "no eq" because the "rcv" LED is more stable... The only
tool I'm aware of beyond what I have done is to build an interface
filter specifically for the radio/TNC pair.
>
> 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.
Presently using the CD setting "Internal" - as a result of your feedback
I will change this to "software" and open squelch prior to sending this
reply.
Significally - the LED now is only "ON" in the presence of a packet
signal.
>
> 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)
These four parameters were "probably" OK measured by the number of
dropped packets - only a few are missed and those are flawed when I look
at the wave form on the "scope".
I don't know this for certain, but the evidence suggests that DCD is not
used by the TNC in selecting a time to transmit... The front of the
machine has a "Rcv" LED that was most definitely "ON" at the time the
T/R switch was activated in the original setup with radio squelch set to
silence "no-signal" audio. However it remains to be seen if the
"software" setting will prevent collisions after more monitoring.
>
> Please see John Ackermann's (N8UR) fine paper on: Let's Not Forget Layer One!
> http://www.febo.com/packet/layer-one
I will do this immediately...
>
>
>
> > 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...
Perhaps "encap" is my bad choice of words... My meaning is that no IP
traffic is encapsulated into AX.25 at the time of failure - it was all
conventional AX.25 BBS kind of traffic.
>
> > 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.
Actually - I don't mind the wait to get a 1/2 second opening to jump
into.
My trouble is not waiting...
This is a side-light information...
I found some distressing frames I don't know how to produce even if I
tried.
MAXFRAME allows packing multiple packets into a frame / however / I see
multiple repeats of the SAME packet in a frame.
This smells BAD to me.
>
> > 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 the modem
> detected valid data (or the 1200Hz or 2200Hz tones, anyway)?
The detail: The TNC audio is provided on the radio back as a fixed
level audio signal (for 1200B) prior to the front AF gain. The "scope"
audio is provided by the back side external speaker connection after AF
gain that is set to deliver a "0db" level measured on a mixer board
during packet audio. As noted earlier the open squelch "hiss" is
running about +2 db over the legit signal...
>
> 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).
This concept of waiting for NO-DCD is exactly what I believe might be
broken. Is there a persistence timer setting under KISS? This DCD
might be dropped much faster than I can track even though I see audio
events below 5500hz (11025 samples per sec).
> 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.
I have seen exactly that. BTW - do you know there are two SYNC
varieties - I believe the other is 01hex?
>
> 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.
I see no evidence of duplication thus FRACK may be OK...
>
>
> > 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...
I'm using the audio signal from the same radio doing the transmitting.
If I was remote, I expect to hear all stations involved including my own
transmission. There is a small transition time involved in switching
T/R that audio is not available to record, I don't expect it is critical
to this analysis, but I'd prefer to have a separate receiver to record
audio from.
>
>
> > 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.
This is good to know.
I do see various timers in jnos, and I now understand that none are
using the DCD as a reference.
>
>
> > 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.
As of this moment I am very HAPPY to report I believe I found the reason
for my problem...
I believe the sample I used to begin the process of building my personal
"autoexec.nos" contained the line like:
param vhf-1 FullDup 1
This parameter defeats PERSIST and SLOTTIME and in effect causes exactly
my problem.
Checking this parameter on a running jnos produces the response "This
parameter is not supported".
Checking this parameter on the TNC using terminal mode displays it has
in fact been set by jnos.
I can report with a little embarrassment that I did not fully research
this situation prior to Jay's response.
It is clear I did not comprehend the impact of the specific parameter
nor did I dig deep enough to find it's setting.
If there is a lesson in this, it is:
"In using the works of others - understand the impact on your own
situation before proceeding."
I have a little more research to do...
THANKS JAY FOR THE STEER IN THE RIGHT DIRECTION.
>
> --- 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
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
73
de Skip k8rra k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060811/37da289c/attachment.html>
More information about the nos-bbs
mailing list