discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Squelch developments


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] Squelch developments
Date: Sat, 17 Jun 2006 17:20:08 -0700
User-agent: Thunderbird 1.5.0.2 (X11/20060522)

Norvald H. Ryeng wrote:

> I've been thinking of using gnuradio and a USRP to record
> all channels simultaneously, and that would require some of these
> blocks.

In case you missed it, I posted a couple weeks ago a "channelizer.py"
program that does exactly this.  You give it a frequency range and
channel spacing, and some filtering parameters, and it will save to raw
files all the NBFM demodulated audio in the range.  It used the
"skipping squelch" patch to prevent any audio when the carrier power was
below threshold.

I'm going to clean this up a bit and make it look more like the existing
examples in the code tree, then check it in.  But you can use the one
previously posted to try out and it will use the regular (non skipping)
squelch block if can't find the patched one.  Beware, it has no
parameter sanity checking and there's a list of parameter constraints in
the email when I posted you'll need to understand.

> There is one nice feature in listener that I would really like to see in
> these blocks: the ability to start output a few seconds (or rather a
> given number of samples) before the squelch opens and keep it open for a
> while after the signal disappears. This corrects for bad tone modulation
> and weak signals that otherwise would make the squelch block cut the
> transmission into several chunks. Also, for my purposes, it makes the
> squelch stay open during the "think time" between request and reply.

Well, a 'hang' time parameter implementing a delay before closing
squelch would be easy, but the pre-threshold opening would require
buffering.  Not sure the best way to do that.

> Listener also has parameters that set a minimum and maximum time for the
> squelch to stay open. The last one could easily be implemented as a
> separate block, but the first one has to be implemented in the squelch
> block. I'm not sure how useful these options are (I'm not using them),
> but implementing them should be fairly straight-forward.

I think about this.  But I'll probably get something simple working
first and add features later.


> Me neither. I'm new to gnuradio (hi to the list, by the way -- I've been
> lurking for a few months) and still at the getting-things-to-work stage.
> I hope to spend some time this summer learning more about gnuradio, but
> I'm still far from writing my own blocks.

Welcome.  And writing blocks isn't that hard if you do it inside a CVS
checked out repository.  Writing blocks outside the source tree is more
difficult but the how-to covers it all.

-Johnathan, AE6HO




reply via email to

[Prev in Thread] Current Thread [Next in Thread]