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 block will output zeros. This latter is
identical to the existing simple_squelch_cc.
I had previously implemented this as a ‘skipping’ patch to
simple_squelch_cc but because it changes the block from a 1:1
synchronous block to a variable output block (when skipping is on), it
really needs to be a new class derived from gr_block instead of
gr_sync_block.
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, like a “VOX”
switch
gr.ctcss_squelch_ff - gate or zero audio output when a ctcss tone is not
present
gr.noise_squelch_ff - gate or zero audio output when noise is present (I
think this what standard_squelch is detecting)
gr.dcs_squelch_ff - gate or zero audio output when digitally coded
squelch is not present
etc.
(Not that I’m signing up to write all these!)
If anyone thinks this is a misguided approach let me know.
-Johnathan, AE6HO
On Sat, Jun 17, 2006 at 12:58:12PM -0700, Johnathan C. wrote:
I am creating a new squelch block:
gr.pwr_squelch_cc
[…]
think this what standard_squelch is detecting)
gr.dcs_squelch_ff - gate or zero audio output when digitally coded
squelch is not present
etc.
Great!
I would definitely want to see those. In some cases it is nice to have a
recording of all communications without all the noise in between. I’ve
been doing this for some time using the “listener” program
(vanheusden.com) and input through the soundcard
from a radio, but with that approach I need one radio and soundcard for
each channel. I’ve been thinking of using gnuradio and a USRP to record
all channels simultaneously, and that would require some of these
blocks.
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.
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.
(Not that I’m signing up to write all these!)
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.
Regards,
Norvald H. Ryeng, LA6YKA
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 clicks”.
Bob
N4HY
Johnathan C. wrote:
I am creating a new squelch block:
gr.pwr_squelch_cc
–
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as
charged!
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
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 are the same
as “key clicks”.
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?
I better get writing before you guys spec this into oblivion 
-Johnathan, AE6HO
Frank B. 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
Johnathan C. 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 wrote the keyer code that runs in PowerSDR and is distributed with
DttSP and wrote the ramp used in it as well as the agc. It is perfect
shaping. You could derive a Gaussian shape that would minimize the time
bandwidth product but the bandwidth would widen. It is better to spend
slightly more time and narrow the bandwidth of the transition as the
hear can plainly hear in the CW transmissions from the SDR-1000 or the
onset of the agc with very strong signals on a quiet band.
Bob
N4HY
Frank B. wrote:
Yes, although half a cycle of a raised cosine is almost as easy, and
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as
charged!
On Sat, Jun 17, 2006 at 05:20:08PM -0700, Johnathan C. wrote:
“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.
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
Robert McGwier wrote:
Frank wrote the keyer code that runs in PowerSDR and is distributed with
DttSP and wrote the ramp used in it as well as the agc. It is perfect
shaping. You could derive a Gaussian shape that would minimize the time
bandwidth product but the bandwidth would widen. It is better to spend
slightly more time and narrow the bandwidth of the transition as the
hear can plainly hear in the CW transmissions from the SDR-1000 or the
onset of the agc with very strong signals on a quiet band.
The power_squelch_cc block I just checked in implements the raised
cosine shape for attack and decay as Frank suggested.
-Johnathan, AE6HO