Re: [Discuss-gnuradio] Squelch developments

[Norvald H. Ryeng]

On Sat, Jun 17, 2006 at 05:20:08PM -0700, Johnathan Corgan wrote:
> 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.

Yes, I saw the post, but I haven't had time to check it out yet. It's
very close to what I need. I'll need the tone squelch blocks, though,
but the channelizer is a very good starting point.

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

Note that it only needs to put samples in the buffer while the squelch
is closed, so it shouldn't have any effect on timing etc. when the
squelch is open. However, when it opens it must flush the whole buffer
before it starts outputting new samples. A ring buffer of n samples that
just keeps overwriting when it is full should do the job. But as I said,
I'm not familiar with the internals yet. There might be problems with
this approach.

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

Do that. Maybe I can add the features later when I understand more about
block internals.

Regards,

Norvald H. Ryeng, LA6YKA