<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.10.1">
</HEAD>
<BODY>
Thanks for the analysis Jay,<BR>
Here is a little more info...<BR>
AND a probably solution at the end!<BR>
<BR>
On Thu, 2006-08-10 at 23:08 -0400, Jay Nugent wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Greetings Skip,</FONT>
<FONT COLOR="#000000">On Thu, 10 Aug 2006, George (Skip) VerDuin wrote:</FONT>
<FONT COLOR="#000000">> As I go deeper into jnos operation, I am now beginning to look in detail</FONT>
<FONT COLOR="#000000">> at signals on vhf radio. Not by any means the best, but I find</FONT>
<FONT COLOR="#000000">> "Baudline" fairly useful for that purpose.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> What I see makes me the "bad guy" of the neighborhood. I believe I see</FONT>
<FONT COLOR="#000000">> my station colliding with on-going traffic in situations that "should</FONT>
<FONT COLOR="#000000">> be" avoidable. I hope this group can shed some light on remedial action</FONT>
<FONT COLOR="#000000">> I can take.</FONT>
<FONT COLOR="#000000"> This tells me that your TNC is not detecting the other packets that are </FONT>
<FONT COLOR="#000000">on the air and transmitting on top of them.</FONT>
<FONT COLOR="#000000"> Things to check:</FONT>
<FONT COLOR="#000000"> 1) Your receive audio level. Too low or too high may distort the </FONT>
<FONT COLOR="#000000"> received data causing the TNC's modem to not recognize the signal </FONT>
<FONT COLOR="#000000"> as val</FONT>id data.
</PRE>
</BLOCKQUOTE>
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).
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> 2) Mis-aligned demodulator (modem). Run the CALIBRAte routine in </FONT>
<FONT COLOR="#000000"> your TNC and confirm it is properly </FONT>aligned.
</PRE>
</BLOCKQUOTE>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> 3) TNC is using "hardware DCD" verses "Software DCD".</FONT>
<FONT COLOR="#000000"> - In Hardware DCD, the modem simply looks for *ANY* signal (or </FONT>
<FONT COLOR="#000000"> noise) from the receiver that looks like a 1200Hz or 2200Hz </FONT>
<FONT COLOR="#000000"> tone. This style of DCD does not know the difference between a </FONT>
<FONT COLOR="#000000"> burst of noise and valid data.</FONT>
<FONT COLOR="#000000"> - In Software DCD (or the TAPR DCD Mod Kit), the modem passes </FONT>
<FONT COLOR="#000000"> everything it demodulates to a State Machine that determines if </FONT>
<FONT COLOR="#000000"> there is actually a "data stream" present. If there is, it </FONT>
<FONT COLOR="#000000"> will then assert the DCD signal. This mode is preferable as </FONT>
<FONT COLOR="#000000"> the squelch on your receiver can be left WIDE OPEN thus </FONT>
<FONT COLOR="#000000"> eliminating the time a signal takes to quiet the FM receiver </FONT>
<FONT COLOR="#000000"> and then allow the squelch gate to open the audio path between </FONT>
<FONT COLOR="#000000"> the detector and the audio stage. WAY faster capure rate and </FONT>
<FONT COLOR="#000000"> far greater nois</FONT>e imunity.
</PRE>
</BLOCKQUOTE>
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. <BR>
Significally - the LED now is only "ON" in the presence of a packet signal.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> 4) *OPEN* your squelch. *WIDE* open! There is no need to use </FONT>
<FONT COLOR="#000000"> squelch (and thus slow down the responsiveness of the receiver) </FONT>
<FONT COLOR="#000000"> if you are using "software squelch" (decoding a data stream as </FONT>
<FONT COLOR="#000000"> opposed to just 1200Hz and 2200H</FONT>z tones)
</PRE>
</BLOCKQUOTE>
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". <BR>
<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Please see John Ackermann's (N8UR) fine paper on: Let's Not Forget Layer One!</FONT>
<FONT COLOR="#000000"><A HREF="http://www.febo.com/packet/layer-one">http://www.febo.com/packet/layer-one</A></FONT>
</PRE>
</BLOCKQUOTE>
I will do this immediately...
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">> As an example tonight: MKG and GKF, GKF-15 and MSE-7, are two links</FONT>
<FONT COLOR="#000000">> engaged in exchanging AX.25 packets (no IP encap).</FONT>
<FONT COLOR="#000000"> Gosh I would hope not! IPIP Encap should exist *ONLY* across Internet </FONT>
<FONT COLOR="#000000">connections and *NEVER* over the air. But that's a whole 'nother </FONT>
<FONT COLOR="#000000">discussion...</FONT>
</PRE>
</BLOCKQUOTE>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> The frames are long, packing up to 4 (maybe more) packets, one frame</FONT>
<FONT COLOR="#000000">> measures longer than 13 seconds at 1200B. The excanges are going on for</FONT>
<FONT COLOR="#000000">> over a minute with 1 second dead air times (maybe 250ms minimum)</FONT>
<FONT COLOR="#000000"> Sounds like the NetROM folks need to adjust their settings to be less </FONT>
<FONT COLOR="#000000">agressive and more polite about channel sharing. Perhaps they can lower </FONT>
<FONT COLOR="#000000">their MAXFRAME from 4 to 1 to allow other stations to share the channel.</FONT>
</PRE>
</BLOCKQUOTE>
Actually - I don't mind the wait to get a 1/2 second opening to jump into.<BR>
My trouble is not waiting...<BR>
<BR>
This is a side-light information...<BR>
I found some distressing frames I don't know how to produce even if I tried.<BR>
MAXFRAME allows packing multiple packets into a frame / however / I see multiple repeats of the SAME packet in a frame.<BR>
This smells BAD to me.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> then my station "chimes in"... I see my station both broadcast and</FONT>
<FONT COLOR="#000000">> NET/ROM node share on top of a GKF-15 _> MSE-7 frame after two packets</FONT>
<FONT COLOR="#000000">> but clobbering the tail-end of the frame with two one-second frames. I</FONT>
<FONT COLOR="#000000">> do not know when jnos dispatched the packets/frame, I do see the audio</FONT>
<FONT COLOR="#000000">> sent to the Kantronics 9612 TNC and the jnos trace received by jnos. </FONT>
<FONT COLOR="#000000">> Because of the tight match of audio to trace I suspect there is no delay</FONT>
<FONT COLOR="#000000">> after dispatch before transmit.</FONT>
<FONT COLOR="#000000"> When you say "the audio sent to the TNC" do you mean that you "hear" </FONT>
<FONT COLOR="#000000">the audio coming from the receiver, and perhaps you can correlate that</FONT>
<FONT COLOR="#000000">'audio' with the DCD light on the TNC, thus confirming that the</FONT> <FONT COLOR="#000000">modem</FONT>
<FONT COLOR="#000000">detected valid data (or the 1200Hz or 2200Hz tones, anyway)?</FONT>
</PRE>
</BLOCKQUOTE>
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...
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> JNOS will send a KISS frame across the serial cable to the KISS-TNC for </FONT>
<FONT COLOR="#000000">transmission. The KISS-TNC waits for the channel to be available by </FONT>
<FONT COLOR="#000000">watching for Data Carrier Detect (DCD). </FONT>
</PRE>
</BLOCKQUOTE>
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).
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">If the channel is clear, the </FONT>
<FONT COLOR="#000000">KISS-TNC begins sending SYNC characters (7Ehex), asserts the PTT line, </FONT>
<FONT COLOR="#000000">continues sending SYNC until the TXDELAY timer expires, then sends the </FONT>
<FONT COLOR="#000000">actual Packet, ending with a few more SYNC characters, then drops PTT.</FONT>
</PRE>
</BLOCKQUOTE>
I have seen exactly that. BTW - do you know there are two SYNC varieties - I believe the other is 01hex?
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> If the KISS-TNC detects that the radio channel is busy (it sees DCD) it </FONT>
<FONT COLOR="#000000">will simply hold the packet in memory until the channel becomes clear. </FONT>
<FONT COLOR="#000000">THERE IS NO HANDSHAKING IN KISS TO INFORM JNOS THAT THE CHANNEL IS BUSY </FONT>
<FONT COLOR="#000000">AND THE PACKET HASNOT BEEN SENT. So if the Frame Acknowledge (FRACK) </FONT>
<FONT COLOR="#000000">timer in JNOS expires, it *WILL* send a duplicate KISS frame to the </FONT>
<FONT COLOR="#000000">KISS-TNC for transmission.</FONT>
</PRE>
</BLOCKQUOTE>
I see no evidence of duplication thus FRACK may be OK...
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">> One potential flaw in my analysis comes from recording at my own</FONT>
<FONT COLOR="#000000">> transciever - I'd be 100% certain at a remote location hearing all 5</FONT>
<FONT COLOR="#000000">> sta.</FONT>
<FONT COLOR="#000000"> Whadya mean, "recording at my own transciever"??? That makes no sense </FONT>
<FONT COLOR="#000000">to me...sorry...</FONT>
</PRE>
</BLOCKQUOTE>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> However I'm pretty certain my view is accurate even with the limitation.</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> So - in seeing the above, I'm pretty certain my TNC is failing to detect</FONT>
<FONT COLOR="#000000">> "channel not busy" prior to activating the T/R switch.</FONT>
<FONT COLOR="#000000"> Again, this can be due to any of the possible problems I outlined at </FONT>
<FONT COLOR="#000000">the beginning of this email.</FONT>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">> My questions to this group becomes: </FONT>
<FONT COLOR="#000000">> Is it TNC (in KISS mode) responsibility to avoid transmitting over</FONT>
<FONT COLOR="#000000">> on-going traffic? </FONT>
<FONT COLOR="#000000"> Yes! The TNC's modem should detect any possible data activity that is </FONT>
<FONT COLOR="#000000">picked up by your receiver and control when it will allow your transmitter </FONT>
<FONT COLOR="#000000">to be keyed up.</FONT>
<FONT COLOR="#000000">> It certainly can not be jnos without "carrier detect" signal on RS-232.</FONT>
<FONT COLOR="#000000"> KISS does not use DCD on the serial cable. DCD as explained earlier, </FONT>
<FONT COLOR="#000000">is the responsibility of the KISS-TNC.</FONT>
</PRE>
</BLOCKQUOTE>
This is good to know.<BR>
I do see various timers in jnos, and I now understand that none are using the DCD as a reference.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">> I hope it is tuneable and I have made a configuration mistake - or must</FONT>
<FONT COLOR="#000000">> I toss out and replace the TNC?</FONT>
<FONT COLOR="#000000">> </FONT>
<FONT COLOR="#000000">> I want to treat the RF space fairly - I suspect I'm not doing a good job</FONT>
<FONT COLOR="#000000">> of it. Right?</FONT>
<FONT COLOR="#000000"> Check out the things I suggested and I'm sure you will figure out why </FONT>
<FONT COLOR="#000000">your TNC is transmitting when it shouldn't.</FONT>
</PRE>
</BLOCKQUOTE>
As of this moment I am very HAPPY to report I believe I found the reason for my problem...<BR>
<BR>
I believe the sample I used to begin the process of building my personal "autoexec.nos" contained the line like:<BR>
param vhf-1 FullDup 1 <BR>
This parameter defeats PERSIST and SLOTTIME and in effect causes exactly my problem.<BR>
Checking this parameter on a running jnos produces the response "This parameter is not supported".<BR>
Checking this parameter on the TNC using terminal mode displays it has in fact been set by jnos.<BR>
<BR>
I can report with a little embarrassment that I did not fully research this situation prior to Jay's response.<BR>
It is clear I did not comprehend the impact of the specific parameter nor did I dig deep enough to find it's setting.<BR>
<BR>
If there is a lesson in this, it is:<BR>
"In using the works of others - understand the impact on your own situation before proceeding."<BR>
I have a little more research to do...<BR>
<BR>
<BR>
THANKS JAY FOR THE STEER IN THE RIGHT DIRECTION.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> --- Jay WB8TKL</FONT>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">"Getting rid of terrorism is like getting rid of dandruff. It cannot</FONT>
<FONT COLOR="#000000"> be done completely no matter how hard you try." -- Gore Vidal</FONT>
<FONT COLOR="#000000">+------------------------------------------------------------------------+</FONT>
<FONT COLOR="#000000">| Jay Nugent <A HREF="mailto:jjn@nuge.com">jjn@nuge.com</A> (734)484-5105 (734)544-4326/Fax |</FONT>
<FONT COLOR="#000000">| Nugent Telecommunications [<A HREF="http://www.nuge.com">www.nuge.com</A>] (734)649-0850/Cell |</FONT>
<FONT COLOR="#000000">| Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |</FONT>
<FONT COLOR="#000000">| ISP Monitoring [<A HREF="http://www.ispmonitor.net">www.ispmonitor.net</A>] ISP & Modem Performance Monitoring |</FONT>
<FONT COLOR="#000000">| Web-Pegasus [<A HREF="http://www.webpegasus.com">www.webpegasus.com</A>] Web Hosting/DNS Hosting/Shell Accts|</FONT>
<FONT COLOR="#000000">| LinuxNIC, Inc. [<A HREF="http://www.linuxnic.net">www.linuxnic.net</A>] Registrar of the .linux TLD |</FONT>
<FONT COLOR="#000000">+------------------------------------------------------------------------+</FONT>
<FONT COLOR="#000000"> 10:01pm up 208 days, 22:55, 4 users, load average: 0.04, 0.05, 0.00</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>