I did some more research (although I'm unsure about my ability to resolve this on my own). Here's what I've found so far:
- the functioning of the standard_squelch depends on the audio_rate you set. For the default 32kS/s it doesn't work, everything passes through, and changing the threshold value does not seem to change anything.
- if you lower the audio rate, squelch does seem to work, though the output is rather noisy
- looking at the underlying code, i notice that gr_threshold_ff.cc (used by standard squelch) outputs
if (in[i] > d_hi) {
out[i] = 1.0;
while gr_simple_squelch_cc.cc outputs
if (f >= d_threshold)
out[i] = in[i];
I'm not sure if this is making the difference...
Can someone test and tell me if squelch works in the example usrp/usrp_nbfm_ptt.py for them? Jonathan?
Thank you in advance for your help
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International
On Fri, Sep 12, 2008 at 19:07, Dimitris Symeonidis
<address@hidden> wrote:
yes, it is. for now my programs work because i have replaced blks2.standard_squelch with gr.simple_squelch_cc, which works. I will investigate some more on monday and let you know.
However the other issue (squelch_range) is obviously valid, no?
On Fri, Sep 12, 2008 at 18:48, Johnathan Corgan
<address@hidden> wrote:
On Tue, Sep 9, 2008 at 6:58 AM, Dimitris Symeonidis <
address@hidden> wrote:
> We just realized that blks2.standard_squelch does not work since GnuRadio
>
3.1.2. I installed 3.1.1 from source and it works fine, 3.1.2 and 3.1.3 it
> doesn't (basically everything passes through, independently of the
> threshold). We are using the usrp_nbfm_ptt.py (unchanged) from the
> gnuradio-examples. Anyone else notice this, or is it just our systems?
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
--
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International