I am creating a new squelch block:
gr.pwr_squelch_cc
..that will replicate the current functionality of simple_squelch_cc,
and add an optional gating function. When gating is on, there will be
no output samples when the historical power is below threshold. With
gating off (the default), the blo
I'm trying to use a function in the usrp_basic class, but there's no
SWIG .i script for it. While looking at the tutorials, I read that all
processing blocks need to derive from the class gr_block. However, this
isn't the case for usrp_basic. I guess this makes sense, as usrp_basic
isn't really a p
On Wed, 2006-06-14 at 22:09 -0700, Eric Blossom wrote:
> On Thu, Jun 15, 2006 at 12:35:50AM -0400, Ilia Mirkin wrote:
> > Quoting Michael Ford <[EMAIL PROTECTED]>:
> >
> >
> > A somewhat more generic answer than Eric's:
>
> Thanks Ilia.
>
> > Python and threads don't mix easily. There's one pyt
On Sat, Jun 17, 2006 at 12:58:12PM -0700, Johnathan Corgan wrote:
> I am creating a new squelch block:
>
> gr.pwr_squelch_cc
[...]
> As far as naming goes, calling this pwr_squelch_xx is anticipation of
> other squelch type blocks:
>
> gr.pwr_squelch_ff - same as pwr_squelch_cc but for audio, l
May I sound a cautionary note. Squelches that do not have a ramp are
not particularly kind to your listening sensibilities if this is to be
used to produce an audible signal. This means that the squelch will
ideally need a setting function for the ramp. The events are the same
as "key click
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 an
Robert McGwier wrote:
> May I sound a cautionary note. Squelches that do not have a ramp are
> not particularly kind to your listening sensibilities if this is to be
> used to produce an audible signal. This means that the squelch will
> ideally need a setting function for the ramp. The events
Johnathan Corgan wrote:
Good catch. Would a linear ramp from 0.0 to 1.0 as a multiplier against
the audio stream, applied over a user specified number of samples, be
sufficient?
Yes, although half a cycle of a raised cosine is almost as easy,
and analytically correct.
73
Frank
AB2KT
_
Frank Brickle wrote:
> Yes, although half a cycle of a raised cosine is almost as easy, and
> analytically correct.
1/2 - cos(x)/2, for x from 0 to pi?
Should this be applied (in reverse) as a decay window when squelch cuts
in, as well as the attack window we've been talking about?
-Johnathan
Exactly.
73
Frank
AB2KT
Johnathan Corgan wrote:
Frank Brickle wrote:
Yes, although half a cycle of a raised cosine is almost as easy, and
analytically correct.
1/2 - cos(x)/2, for x from 0 to pi?
Should this be applied (in reverse) as a decay window when squelch cuts
in, as well as the a
I've just checked in a bugfix for the TVRX2 and TVRX3 boards. If you
have one of them, please update to the latest CVS version of gr-usrp.
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discu
11 matches
Mail list logo
