Order Tray | Contact Us | Home | SIG Lists

[wxsig] Problem with open squelch or carrier preventing T238 fromtransmitting

Will Beals will at beals5.com
Sat Aug 12 19:30:10 UTC 2006


Mark (and all):

I do just look at the signal detect line (same one that drives the yellow
LED) to determine if it is safe to transmit or not, so if there is an open
carrier on frequency, I won't be transmitting.

As it turns out, I am somewhat releived to hear that as I thought the
detection was more sophisticated than that and when I was testing the T238's
ability to hold off transmitting if there was someone else on frequency, I
wasn't really sure how to test it.  Never thought of just opening the
squeltch!

I assume the software carrier detect functions are looking for legit data
packets rather than simply energy on the line.  Right now I only start
looking as soon as data is ready to transmit, I do not monitor the data all
the time.  I have some important reasons for doing that as I have to send
each bit of data in software rather than relying on a hardware port such as
as a serial interface.  That is very CPU-intensive work while I am
simultaneously doing the same thing for the 1-wire communications.  

Will do some more poking around.

will 

-----Original Message-----
From: wxsig-bounces at lists.tapr.org [mailto:wxsig-bounces at lists.tapr.org] On
Behalf Of M PATTON
Sent: Friday, August 11, 2006 3:35 PM
To: wxsig at lists.tapr.org
Subject: [wxsig] Problem with open squelch or carrier preventing T238
fromtransmitting

Below is a discussion that I started as an email thread with Will and Russ
concerning some issues that I've been having with the T238  not transmitting
due to some carrier signals on 144.390 locally in the Denver area.  I
thought that others may be interested or may have the same issue or ideas on
how to resolve it.

Mark

==============
Hi Will,

I thought you might be interested in what I've found out.  I did some
research on the MX614 modem chip and one of the "features" is that it is
sensitive and the "detect" signal will come on with almost any signal it
seems.  Here's from the data sheet:

"The DET output will be set high when the level has exceeded the threshold
for a sufficient period of time. Amplitude and time hysteresis are used to
reduce chattering of the DET  output in marginal conditions.
Note that this circuit may also respond to non-FSK signals such as speech."

It turns out that open squelch or a blank carrier will trigger it.  The
"Channel Busy" LED comes on with any signal - including a carrier or open
squelch.

>From what I can tell, you use this signal to determine if the channel
is busy.   I don't know what others see, but I've verified that I have
periods of time where I get a carrier on 144.390.  I've watched to see when
the T238  doesn't transmit for a while and I check the frequency. I can hear
a low level carrier on it.  After some time, it will go away.
Other APRS traffic seems to do just fine including the digi that is at the
same location as the T238 .  I've tried tightening the squelch  but the
signal is strong enough to open it regardless - thus preventing it from
transmitting for long periods of time.

In doing further research, this is a known problem.  This is the reason that
the KPC3  and other TNC's have gone with a software carrier
detect.   For instance if you check the recommended configuration using
a KPC3  for a digi, they suggest that you use software carrier detect for
"better collision avoidance".  I've been tracking the development of the
Tracker2 (follow-on to the Open Tracker) and Scott has implemented a
software carrier detect.

I don't know how exactly they implement this.  Scott may be willing to give
you some ideas.  I think he looks for valid data being transmitted (how
exactly he does this I have no idea).

Mark

===============

The transmit state machine waits for a clear channel for up to 25 seconds.
If it can't get 500ms of no data by that time, it gives up.

The MX-614 should only fire if there is real data.  I tried just opening the
squelch on the radio for my T238  setup, but appear to have some kind of
problem as my Rx LED won't even light when I have real data.  I suspect a
busted cable so will go get it fixed hopefully tomorrow night and let you
know.

will

================
Hi Russ,

An update on the signal on 144.390.  It was a stuck mic.
A few guys from the local club went out and DF'd it this evening and found
it.  It was up in an area North of town.

Mark

==============

Hi Russ,

When I got home this afternoon I checked 144.390 and I can definitely hear a
carrier.  I heard some faint audio (radio station) but I can't make it out.
The signal is about S2.  I went out and checked, and this is opening the
squelch on the radio on my weather station so it evidently is not
transmitting.  I tightened the squelch (a lot) and we'll see if this helps
until the issue with the radio station is resolved.

Interesting that my KPC3  I'm using as a digi (which will be relocated to
Franktown soon) has a software carrier detect set so it doesn't see the
interference on 144.390.  I think it is looking for an actual signal
- not just static or a carrier.

Will - What does the T238  do in this case?  Does it just sit and wait for
an opening (ie no carrier) to transmit and if it can't find an opening then
eventually give up?  Since the hardware is there on the RX side, would it be
possible to look for a a real signal (like the KPC  does) to detect if the
channel is open rather than just a carrier?  The other reason this might be
helpful is that my weather station is going out in a field where the radio
is going to get very cold.  I've had radios that when they get cold, the
squelch level changes dramatically (ie opens).  I don't know if this radio
does that or not, but I'll probably find out this winter!

Mark

===============

Mark,
I looked at your weather data, and those drop-outs are not what I've seen
from my station over the years that I've run it.  However, in just the past
few days, an interference has appeared on 144.390 and that may be causing
problems in the Denver area.  I did check Will's N0XGA station and it seems
to be working OK and not seeing drop-outs.

This interference is apparently a spur associated with a broadcast station,
perhaps KHOW as that has been heard through the static.  I live NE of
Boulder a few miles and it appears to be either to the general NE or SW of
my location.  I'll let you know if I hear more info on it.

Russ   KB0TVJ

=============
Hi Russ,

I have my stand-alone solar weather station up and running as K0YG-6 in my
back yard.  I plan to move it out this fall to it's final destination as I'm
still wringing out the bugs.

I am puzzled by one issue that you may have an answer to.  I keep getting
gaps in the data.  Usually it's fine and reporting every 5 minutes for a
while then I miss a couple of packets.  This I would consider "normal" due
to possible collisions on the frequency.
Recently I've noticed some sizable gaps. 30-45 minutes and last night I had
one that was 4 hours!

Nothing changed, it just quit and then picked up 4 hours later.

In looking at some other ham WX stations, that are close, I see that they
also have some gaps in their data.  Not at the same time as mine, but some
pretty sizable.  In others, I don't see this issue.

Do you normally see gaps like this in the data?  I'm trying to figure out if
I have an issue with my weather station or not or if it is somehow network
related.  I can't quite figure out what would cause this.  Any ideas?

If you don't consider this "normal", I may move my WX station off on to
another frequency and let it run for a few days and copy the packets
independently to avoid the network and collision issues and try to debug it
that way.

Mark



_______________________________________________
wxsig mailing list
wxsig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/wxsig







More information about the wxsig mailing list