[Discuss-gnuradio] @ACLOCAL@: command not found

[nesimi eldarov]

 Hi all,

I need your help: I want to install some files (old gnu library and developed 
files) for GNU to my new Ubuntu: 13.04. 
All config, makefiles were for old ubuntu. 

I run these:
$ autoscan
then change config.scan to .ac
$ autoconf
$ aclocal
$ automake

when I run 
$ make

it triggers these:
CDPATH="${ZSH_VERSION+.}:" && cd . && @ACLOCAL@ -I config
/bin/bash: @ACLOCAL@: command not found
make: *** [aclocal.m4] Error 127
  Do you know how to fix it?

-- 
NE___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] @ACLOCAL@: command not found

[Marcus Müller]

Hi Nesimi,

I don't know how old your GNU Radio version actually is, but I urge you that if 
you -- by any means -- can convert your application to at least GNU Radio 3.6 
or even better 3.7: do it!
3.6 and 2.7 both build using cmake which is much easier to use than the whole 
auto*-hell and a whole lot easier to debug.

Anyway, even with the old autohell-based solutions you shouldn't have to do the 
steps below. Just run ./bootstrap !

Greetings
Marcus

On 11/17/2013 01:31 PM, nesimi eldarov wrote:

Hi all,

I need your help: I want to install some files (old gnu library and developed 
files) for GNU to my new Ubuntu: 13.04.
All config, makefiles were for old ubuntu.

I run these:
$ autoscan
then change config.scan to .ac
$ autoconf
$ aclocal
$ automake

when I run
$ make

it triggers these:

CDPATH="${ZSH_VERSION+.}:" && cd . && @ACLOCAL@ -I config
/bin/bash: @ACLOCAL@: command not found
make: *** [aclocal.m4] Error 127

Do you know how to fix it?

--
NE


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Convolution

[Robert James]

Hi.  I'm new to GNU Radio but have experience with basic DSP (using
MATLAB for instance).  Which blocks can I use to do these simple
tasks:

1. Convolution with an arbitrary (constant) wave in the time domain?
Example: I provide the wave as a fixed series of constants, I'd like
to convolute with it.

2. The same thing in the frequency domain?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] @ACLOCAL@: command not found

[nesimi eldarov]

 Hi Marcus,

Yes, my GNU radio version is 3.6. 
I used ./bootstrap, that did not work :(

Can you tell me how to use cmake to install the shared library to gnuradio?

Best,
-
NE

Воскресенье, 17 ноября 2013, 14:25 +01:00 от Marcus Müller :
>Hi Nesimi,
>
>I don't know how old your GNU Radio version actually is, but I
  urge you that if you -- by any means -- can convert your
  application to at least GNU Radio 3.6 or even better 3.7: do it!
>3.6 and 2.7 both build using cmake which is much easier to use
  than the whole auto*-hell and a whole lot easier to debug.
>
>Anyway, even with the old autohell-based solutions you shouldn't
  have to do the steps below. Just run ./bootstrap !
>
>Greetings 
>Marcus
>
>On 11/17/2013 01:31 PM, nesimi eldarov wrote:
>>Hi all,
>>
>>I need your help: I want to install some files (old gnu library
  and developed files) for GNU to my new Ubuntu: 13.04. 
>>All config, makefiles were for old ubuntu. 
>>
>>I run these:
>>$ autoscan
>>then change config.scan to .ac
>>$ autoconf
>>$ aclocal
>>$ automake
>>
>>when I run 
>>$ make
>>
>>it triggers these:
>>CDPATH="${ZSH_VERSION+.}:" && cd . && @ACLOCAL@
-I config
>>/bin/bash: @ACLOCAL@: command not found
>>make: *** [aclocal.m4] Error 127
>>  Do you know how to fix it?
>>
>>-- 
>>NE
>>
>>___
Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org
>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
nesimi eldarov
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] @ACLOCAL@: command not found

[Marcus Müller]

I'm referring you to the official build guide, 
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide,
specifically: go to your source directory,
mkdir build
cd build
cmake ..
make
sudo make install


Where did you get your instructions? They are very outdated...

Greetings
Marcus

On 11/17/2013 02:34 PM, nesimi eldarov wrote:

Hi Marcus,

Yes, my GNU radio version is 3.6.
I used ./bootstrap, that did not work :(

Can you tell me how to use cmake to install the shared library to gnuradio?

Best,
-
NE

Воскресенье, 17 ноября 2013, 14:25 +01:00 от Marcus Müller :

Hi Nesimi,

I don't know how old your GNU Radio version actually is, but I urge you 
that if you -- by any means -- can convert your application to at least GNU 
Radio 3.6 or even better 3.7: do it!
3.6 and 2.7 both build using cmake which is much easier to use than the 
whole auto*-hell and a whole lot easier to debug.

Anyway, even with the old autohell-based solutions you shouldn't have to do 
the steps below. Just run ./bootstrap !

Greetings
Marcus

On 11/17/2013 01:31 PM, nesimi eldarov wrote:

Hi all,

I need your help: I want to install some files (old gnu library and 
developed files) for GNU to my new Ubuntu: 13.04.
All config, makefiles were for old ubuntu.

I run these:
$ autoscan
then change config.scan to .ac
$ autoconf
$ aclocal
$ automake

when I run
$ make

it triggers these:

CDPATH="${ZSH_VERSION+.}:" && cd . && @ACLOCAL@ -I config
/bin/bash: @ACLOCAL@: command not found
make: *** [aclocal.m4] Error 127

Do you know how to fix it?

-- 
NE



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--
nesimi eldarov


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What am I really seeing?

[Paul B. Huter]

Thanks for the response.

I am using a USRP2 N210 with the shortwave receiver daughterboard. When I
was playing around, I was getting an error when I set the sample rate on
the USRP source to 30MHz, and was told it had something to do with dividing
100 by 30 and not getting an integer (you get 3.3), so it was
recommended I use 25 or 50, with 25 giving more resolution on the results.
If I am setting the rate to 50MHz on the source and 30MHz on the FFT sink,
and I am actually seeing (and ultimately recording with a file sink) the
whole shortwave spectrum, I will be satisfied.

Thank you.

Paul B. Huter

Andrew Davis  wrote:

Hello, first I think you meant sample rate, not size. Who said you cant use
30Mhz, what kind of hardware are you using? Lastly the FFT algorithms do
not deal with frequency in that way, you are still seeing 0-50Mhz spectrum,
just the label now says 50Mhz.

Andrew


On Sat, Nov 16, 2013 at 10:11 AM, Paul B. Huter wrote:

> I have a GNU Radio setup to look at shortwave. I have my sample size set
> to 50MHz (since I was told I can't use 30). If I set my FFT to 30MHz with a
> baseband of 15MHz, am I actually seeing the shortwave spectrum (0-30MHz)?
> Also, any suggestions on setting the FFT Size?
>
> Thank you!
>
> Paul B. Huter
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] @ACLOCAL@: command not found

[nesimi eldarov]

 Hi Marcus,

that is the instructions of building gnuradio, isn't it?
I wanted to install new library into gnuradio or any new files. 
Is that a different thing?


Best,
-
Nasimi


Воскресенье, 17 ноября 2013, 14:37 +01:00 от Marcus Müller :
>I'm referring you to the official build
  guide, http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide ,
>specifically: go to your source directory, 
>mkdir build
>cd build 
>cmake ..
>make
>sudo make install
>
>
>Where did you get your instructions? They are very outdated...
>
>Greetings
>Marcus
>
>On 11/17/2013 02:34 PM, nesimi eldarov wrote:
>>Hi Marcus,
>>
>>Yes, my GNU radio version is 3.6. 
>>I used ./bootstrap, that did not work :(
>>
>>Can you tell me how to use cmake to install the shared library to
  gnuradio?
>>
>>Best,
>>-
>>NE
>>
>>Воскресенье, 17 ноября 2013, 14:25 +01:00 от Marcus Müller 
>> :
>>>Hi Nesimi,
>>>
>>>I don't know how old your GNU Radio version actually
  is, but I urge you that if you -- by any means -- can
  convert your application to at least GNU Radio 3.6 or
  even better 3.7: do it!
>>>3.6 and 2.7 both build using cmake which is much
  easier to use than the whole auto*-hell and a whole
  lot easier to debug.
>>>
>>>Anyway, even with the old autohell-based solutions you
  shouldn't have to do the steps below. Just run
  ./bootstrap !
>>>
>>>Greetings 
>>>Marcus
>>>
>>>On 11/17/2013 01:31 PM, nesimi eldarov wrote:
Hi all,

I need your help: I want to install some files (old
  gnu library and developed files) for GNU to my new
  Ubuntu: 13.04. 
All config, makefiles were for old ubuntu. 

I run these:
$ autoscan
then change config.scan to .ac
$ autoconf
$ aclocal
$ automake

when I run 
$ make

it triggers these:
CDPATH="${ZSH_VERSION+.}:" && cd .
&& @ACLOCAL@ -I config
/bin/bash: @ACLOCAL@: command not found
make: *** [aclocal.m4] Error 127
  Do you know how to fix it?

-- 
NE 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>___
>>>Discuss-gnuradio mailing list
>>>Discuss-gnuradio@gnu.org
>>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>-- 
>>nesimi eldarov
>


-- 
nesimi eldarov
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

[Frederik Wing]

Hello again,

meanwhile I got some more information about the error.
It occurs when returning the taps from the firdes::low_pass function.
But ONLY under some conditions.
I wrote a simple script which is NOT working and giving the error
mentioned earlier:
> from gnuradio.filter import firdes
>
> f_s = 1e3
> f_c = 0.2e3
> transition_width = 100
> low_pass1 =
> firdes.low_pass(1,f_s,f_c,transition_width,firdes.WIN_KAISER, 5.0)
> print len(low_pass1)
But it does work if I change f_s to 1e6 or higher. There seems to be a
"magic border" at 1GHz.

Can anyone help me?

Frederik

Am 15.11.2013 12:53, schrieb Marcus Müller:
> Hi Frederik, hi rest,
>
> this is an interesting error. You might want to report it.
> The interesting part of your backtrace is
> #8  ~vector (this=0xbee7c59c, __in_chrg=)
> at /usr/include/c++/4.6/bits/stl_vector.h:350
> #9  gr::filter::firdes::low_pass (gain=,
> sampling_freq=, cutoff_freq=0.45001,
> transition_width=, window_type=,
> beta=) at
> /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>
> firdes.cc:136 is the closing bracket of the for loop that iterates
> over both the taps vector and the window vector.
> sadly, gdb doesn't tell us whether the w or the taps vector's
> destructor is being called.
> As a wild guess, the compiler realised w is not being used after the
> last iteration of the loop in the low_pass function.
> Proposal:
> do a
>
> gdb --args python top_block.py #or whatever your file is called
> gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
> gdb>run
> ##at some point, the breakpoint will be reached.
>
> and check if it crashes on the first run, on the last or whenever.
>
> Basically: It's a curious thing that this happens. I do not rule out
> strange and wilde and generally untame things happening in memory here!
>
> Greetings, and look out for memory grues,
>
> Marcus
>
> On 15.11.2013 12:13, Frederik Wing wrote:
>> Hi everyone,
>>
>> I am using the latest GNU Radio version compiled and running on a
>> Raspberry Pi with Raspbian Wheezy.
>> Most of the blocks seem to work. But the Rational Resampler makes
>> problems.
>>
>> Here is my sample python script generated by GNU Radio Companion:
>> http://pastebin.com/R0Z21MfU
>>
>> Running it throws the error:
>> *** glibc detected *** /usr/bin/python2: double free or corruption
>> (!prev): 0x02bee190 ***
>>
>> Debugging it with gdb gives the output here:
>> http://pastebin.com/rXqtkZVG
>>
>> Any ideas how to solve this?
>>
>> Yours,
>> Frederik
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What am I really seeing?

[Tom Rondeau]

On Sun, Nov 17, 2013 at 8:51 AM, Paul B. Huter  wrote:
> Thanks for the response.
>
> I am using a USRP2 N210 with the shortwave receiver daughterboard. When I
> was playing around, I was getting an error when I set the sample rate on the
> USRP source to 30MHz, and was told it had something to do with dividing 100
> by 30 and not getting an integer (you get 3.3), so it was recommended I
> use 25 or 50, with 25 giving more resolution on the results. If I am setting
> the rate to 50MHz on the source and 30MHz on the FFT sink, and I am actually
> seeing (and ultimately recording with a file sink) the whole shortwave
> spectrum, I will be satisfied.
>
> Thank you.
>
> Paul B. Huter

So you set the sampling rate to 50 Msps, which produces complex 8-bit
samples, and so it represents 50 MHz of spectrum.

When you pass this to the FFT sink, you will see all 50 MHz. You're at
complex baseband, so you'll see -25 to +25 MHz. Even if you set the
sampling rate of the sink to 30 Msps, you are still seeing 50 MHz. The
sampling rate to the sink does nothing but set the x-axis. So if you
set it to 30, the x-axis will represent -15 to +15 MHz, but a signal
at -15 MHz will actually be at -25 MHz.

You have to go through a sample rate changing block, like a decimating
FIR filter (which only gives you integer decimation rates), the
rational resampler block (which gives you a rate change of
interp/decim where interp and decim are integers), or the fractional
resampler or PFB arbitrary resampler (where the rate you set is a real
number). See the manual for how to use any of these blocks
(http://gnuradio.org/doc/doxygen/index.html).

Tom



> Andrew Davis  wrote:
>
> Hello, first I think you meant sample rate, not size. Who said you cant use
> 30Mhz, what kind of hardware are you using? Lastly the FFT algorithms do not
> deal with frequency in that way, you are still seeing 0-50Mhz spectrum, just
> the label now says 50Mhz.
>
> Andrew
>
>
> On Sat, Nov 16, 2013 at 10:11 AM, Paul B. Huter 
> wrote:
>>
>> I have a GNU Radio setup to look at shortwave. I have my sample size set
>> to 50MHz (since I was told I can't use 30). If I set my FFT to 30MHz with a
>> baseband of 15MHz, am I actually seeing the shortwave spectrum (0-30MHz)?
>> Also, any suggestions on setting the FFT Size?
>>
>> Thank you!
>>
>> Paul B. Huter
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Convolution

[Tom Rondeau]

On Sun, Nov 17, 2013 at 8:32 AM, Robert James  wrote:
> Hi.  I'm new to GNU Radio but have experience with basic DSP (using
> MATLAB for instance).  Which blocks can I use to do these simple
> tasks:
>
> 1. Convolution with an arbitrary (constant) wave in the time domain?
> Example: I provide the wave as a fixed series of constants, I'd like
> to convolute with it.
>
> 2. The same thing in the frequency domain?

The fir_filter_XXX does time-domain convolution. You'd pass it a
decimation of 1 and the taps would be the signal you want to convolve
against.

The fft_filter_XXX does fast convolution in the frequency domain.

http://gnuradio.org/doc/doxygen/page_filter.html

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rational Resampler throws double free or corruption error

[Tom Rondeau]

On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing  wrote:
> Hello again,
>
> meanwhile I got some more information about the error.
> It occurs when returning the taps from the firdes::low_pass function.
> But ONLY under some conditions.
> I wrote a simple script which is NOT working and giving the error
> mentioned earlier:
>> from gnuradio.filter import firdes
>>
>> f_s = 1e3
>> f_c = 0.2e3
>> transition_width = 100
>> low_pass1 =
>> firdes.low_pass(1,f_s,f_c,transition_width,firdes.WIN_KAISER, 5.0)
>> print len(low_pass1)
> But it does work if I change f_s to 1e6 or higher. There seems to be a
> "magic border" at 1GHz.
>
> Can anyone help me?
>
> Frederik

Not sure if you really meant 1e6 or 1 GHz (1e9).

The complexity of a filter like this is inversely proportional to the
width of the transition band. As you increase f_s, you're normalized
transition band is transition_width/f_s, which is getting smaller and
smaller.

At a sampling rate of 1 ksps, this filter you describe here is 101
taps. At 1e6 sps, you have 11 taps. That's a gigantic filter
already. At 1e9 sps, that creates a filter with 10001 taps. That
is, one hundred million taps.

My i7 processor with 8 GB of RAM took 30 seconds to calculate that
filter. Your RaspberryPi isn't quite that powerful. Most likely, your
running out of RAM and probably writing out of bounds, so strange
things are happening that's causing that double free.

There is absolutely no way that you need that complex of a filter.
Make sure to scale your transition width with your sampling rate.

Tom



> Am 15.11.2013 12:53, schrieb Marcus Müller:
>> Hi Frederik, hi rest,
>>
>> this is an interesting error. You might want to report it.
>> The interesting part of your backtrace is
>> #8  ~vector (this=0xbee7c59c, __in_chrg=)
>> at /usr/include/c++/4.6/bits/stl_vector.h:350
>> #9  gr::filter::firdes::low_pass (gain=,
>> sampling_freq=, cutoff_freq=0.45001,
>> transition_width=, window_type=,
>> beta=) at
>> /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>>
>> firdes.cc:136 is the closing bracket of the for loop that iterates
>> over both the taps vector and the window vector.
>> sadly, gdb doesn't tell us whether the w or the taps vector's
>> destructor is being called.
>> As a wild guess, the compiler realised w is not being used after the
>> last iteration of the loop in the low_pass function.
>> Proposal:
>> do a
>>
>> gdb --args python top_block.py #or whatever your file is called
>> gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136
>> gdb>run
>> ##at some point, the breakpoint will be reached.
>>
>> and check if it crashes on the first run, on the last or whenever.
>>
>> Basically: It's a curious thing that this happens. I do not rule out
>> strange and wilde and generally untame things happening in memory here!
>>
>> Greetings, and look out for memory grues,
>>
>> Marcus
>>
>> On 15.11.2013 12:13, Frederik Wing wrote:
>>> Hi everyone,
>>>
>>> I am using the latest GNU Radio version compiled and running on a
>>> Raspberry Pi with Raspbian Wheezy.
>>> Most of the blocks seem to work. But the Rational Resampler makes
>>> problems.
>>>
>>> Here is my sample python script generated by GNU Radio Companion:
>>> http://pastebin.com/R0Z21MfU
>>>
>>> Running it throws the error:
>>> *** glibc detected *** /usr/bin/python2: double free or corruption
>>> (!prev): 0x02bee190 ***
>>>
>>> Debugging it with gdb gives the output here:
>>> http://pastebin.com/rXqtkZVG
>>>
>>> Any ideas how to solve this?
>>>
>>> Yours,
>>> Frederik
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Font Size in GNU Radio Companion

[Robert James]

The font size in GNU Radio Companion seems to be fixed and quite
small, at least for those with visual impairements.  Is there any way
to change it (either via GUI or via a source edit)?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Rectifying and Low Pass filter

[Robert James]

I'm trying to demodulate AM (I know there are existing blocks to do
that, but I'd like to learn how to do it on my own).

In a real world analog circuit, I would find the envelope by first
rectifying the signal (using a diode), and then using a low pass
filter - that would give me the envelope.

How can I rectify with GNU Radio?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rectifying and Low Pass filter

[Johnathan Corgan]

On 11/17/2013 11:01 AM, Robert James wrote:

> I'm trying to demodulate AM (I know there are existing blocks to do
> that, but I'd like to learn how to do it on my own).
> 
> In a real world analog circuit, I would find the envelope by first
> rectifying the signal (using a diode), and then using a low pass
> filter - that would give me the envelope.
> 
> How can I rectify with GNU Radio?

In GNU Radio, one is typically dealing with complex baseband I/Q
signals, where a "real valued" passband signal has had its carrier
shifted down to zero and what remains is the complex envelope
represented by I and Q.  There are many resources indexed by Google to
help you learn more about this.

To demodulate a passband AM signal represented at baseband, simply take
the magnitude of the I/Q representation, i.e., sqrt(I^2 + Q^2).  GNU
Radio has a block to do this, gr::blocks::complex_to_mag, which you can
also access in Python as blocks.complex_to_mag(), or from GRC under
"Type Converters/Complex to Mag".  It is a synchronous block that
accepts a complex signal stream at an arbitrary sample rate and outputs
the magnitude of that signal as a float stream at the same sample rate.

Depending on what the original signal was that went into the AM
modulator on the transmitter (such as audio like in AM broadcast radio),
you may need to further process the signal in order to use it, such as
removing DC offset, filtering, amplification, or changing the sampling rate.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rectifying and Low Pass filter

[Robert James]

I see.  For those of us who have some background in analog circuits,
is there a way to work with real valued passband signals? For example,
is there a block which takes a complex baseband signal and converts it
to a real valued passband signal?


On 11/17/13, Johnathan Corgan  wrote:
> On 11/17/2013 11:01 AM, Robert James wrote:
>
>> I'm trying to demodulate AM (I know there are existing blocks to do
>> that, but I'd like to learn how to do it on my own).
>>
>> In a real world analog circuit, I would find the envelope by first
>> rectifying the signal (using a diode), and then using a low pass
>> filter - that would give me the envelope.
>>
>> How can I rectify with GNU Radio?
>
> In GNU Radio, one is typically dealing with complex baseband I/Q
> signals, where a "real valued" passband signal has had its carrier
> shifted down to zero and what remains is the complex envelope
> represented by I and Q.  There are many resources indexed by Google to
> help you learn more about this.
>
> To demodulate a passband AM signal represented at baseband, simply take
> the magnitude of the I/Q representation, i.e., sqrt(I^2 + Q^2).  GNU
> Radio has a block to do this, gr::blocks::complex_to_mag, which you can
> also access in Python as blocks.complex_to_mag(), or from GRC under
> "Type Converters/Complex to Mag".  It is a synchronous block that
> accepts a complex signal stream at an arbitrary sample rate and outputs
> the magnitude of that signal as a float stream at the same sample rate.
>
> Depending on what the original signal was that went into the AM
> modulator on the transmitter (such as audio like in AM broadcast radio),
> you may need to further process the signal in order to use it, such as
> removing DC offset, filtering, amplification, or changing the sampling
> rate.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rectifying and Low Pass filter

[Tom Rondeau]

On Sun, Nov 17, 2013 at 2:53 PM, Robert James  wrote:
> I see.  For those of us who have some background in analog circuits,
> is there a way to work with real valued passband signals? For example,
> is there a block which takes a complex baseband signal and converts it
> to a real valued passband signal?

You can always go through a type converter block "complex to float"
which outputs a stream for the real and (if connected) the imaginary.
Or you can just use the "complex to real" block to just get the real
part.

However, and I'm not trying to be glib or insulting, the best thing to
do is really to understand how to work at complex baseband. When
working with software radio, we're not just doing in software what we
did in analog circuits. Sometimes we do, sometimes it looks similar,
but by working in the digital domain, we're changing a lot about how
we work with signals. In many ways, we're now able to more accurately
represent the real mathematics of signal processing where we were only
approximating it in hardware.

Tom


> On 11/17/13, Johnathan Corgan  wrote:
>> On 11/17/2013 11:01 AM, Robert James wrote:
>>
>>> I'm trying to demodulate AM (I know there are existing blocks to do
>>> that, but I'd like to learn how to do it on my own).
>>>
>>> In a real world analog circuit, I would find the envelope by first
>>> rectifying the signal (using a diode), and then using a low pass
>>> filter - that would give me the envelope.
>>>
>>> How can I rectify with GNU Radio?
>>
>> In GNU Radio, one is typically dealing with complex baseband I/Q
>> signals, where a "real valued" passband signal has had its carrier
>> shifted down to zero and what remains is the complex envelope
>> represented by I and Q.  There are many resources indexed by Google to
>> help you learn more about this.
>>
>> To demodulate a passband AM signal represented at baseband, simply take
>> the magnitude of the I/Q representation, i.e., sqrt(I^2 + Q^2).  GNU
>> Radio has a block to do this, gr::blocks::complex_to_mag, which you can
>> also access in Python as blocks.complex_to_mag(), or from GRC under
>> "Type Converters/Complex to Mag".  It is a synchronous block that
>> accepts a complex signal stream at an arbitrary sample rate and outputs
>> the magnitude of that signal as a float stream at the same sample rate.
>>
>> Depending on what the original signal was that went into the AM
>> modulator on the transmitter (such as audio like in AM broadcast radio),
>> you may need to further process the signal in order to use it, such as
>> removing DC offset, filtering, amplification, or changing the sampling
>> rate.
>>
>> --
>> Johnathan Corgan, Corgan Labs
>> SDR Training and Development Services
>> http://corganlabs.com
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Font Size in GNU Radio Companion

[Tom Rondeau]

On Sun, Nov 17, 2013 at 12:27 PM, Robert James  wrote:
> The font size in GNU Radio Companion seems to be fixed and quite
> small, at least for those with visual impairements.  Is there any way
> to change it (either via GUI or via a source edit)?

Nothing right now. In the past, I've used the accessibility options or
universal access options in Linux to change the font size of the
entire system. In this case, it was to make the font of GRC large
enough to show through a projector. However, we're working on
overhauling a lot of GRC in the upcoming months, which will hopefully
allow us to have this sort of flexibility.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Renaming gnuradio/math.h to gnuradio/math_utils.h

[Steve Glass]

Hi,

The gnuradio/math.h header is causing some problems for some
out-of-tree builds that use C code. If these projects add the GNURadio
includes to their build path then the system math.h header is hidden
and cannot be included (this occurs, e.g., in AirProbe's gsm-receiver).

It seems bad form to define a math.h that isn't the system one so the
following pull request renames math.h to math_utils.h and changes the
references to the old header to the new name.

Regards

Steve

--

The following changes since commit
54d3961bdaaa708152e33264b95759bab4d94c87:

  Merge branch 'master' into next (2013-11-14 12:45:59 -0500)

are available in the git repository at:


  g...@github.com:stiabhan/gnuradio.git  math-header-rename

for you to fetch changes up to 7588f1875d1a932464e67b6865476619288fa8b0:

  gnuradio-runtime: Rename math.h to math_utils.h. (2013-11-15
14:53:06 +1000)

- 
Steve Glass (1):
  gnuradio-runtime: Rename math.h to math_utils.h.

 gnuradio-runtime/include/gnuradio/CMakeLists.txt   | 2 +-
 gnuradio-runtime/include/gnuradio/{math.h => math_utils.h} | 6 +++---
 gnuradio-runtime/lib/buffer.cc | 2 +-
 gnuradio-runtime/lib/math/fast_atan2f.cc   | 2 +-
 gnuradio-runtime/lib/math/qa_fast_atan2f.cc| 2 +-
 gnuradio-runtime/lib/math/qa_math.cc   | 2 +-
 gr-analog/lib/fmdet_cf_impl.cc | 2 +-
 gr-analog/lib/pll_carriertracking_cc_impl.cc   | 2 +-
 gr-analog/lib/pll_freqdet_cf_impl.cc   | 2 +-
 gr-analog/lib/pll_refout_cc_impl.cc| 2 +-
 gr-analog/lib/quadrature_demod_cf_impl.cc  | 2 +-
 gr-analog/lib/rail_ff_impl.cc  | 2 +-
 gr-atsc/lib/atsc_fpll.cc   | 2 +-
 gr-atsc/lib/atsci_equalizer_lms2.cc| 2 +-
 gr-atsc/lib/atsci_sssr.cc  | 2 +-
 gr-blocks/lib/complex_to_arg_impl.cc   | 2 +-
 gr-blocks/lib/control_loop.cc  | 2 +-
 gr-blocks/lib/udp_source_impl.cc   | 2 +-
 gr-digital/lib/binary_slicer_fb_impl.cc| 2 +-
 gr-digital/lib/clock_recovery_mm_cc_impl.cc| 2 +-
 gr-digital/lib/clock_recovery_mm_ff_impl.cc| 2 +-
 gr-digital/lib/cma_equalizer_cc_impl.h | 2 +-
 gr-digital/lib/constellation.cc| 2 +-
 gr-digital/lib/constellation_receiver_cb_impl.cc   | 2 +-
 gr-digital/lib/correlate_and_sync_cc_impl.cc   | 2 +-
 gr-digital/lib/costas_loop_cc_impl.cc  | 2 +-
 gr-digital/lib/kurtotic_equalizer_cc_impl.h| 2 +-
 gr-digital/lib/mpsk_receiver_cc_impl.cc| 2 +-
 gr-digital/lib/ofdm_frame_acquisition_impl.cc  | 2 +-
 gr-digital/lib/ofdm_frame_sink_impl.cc | 2 +-
 gr-digital/lib/pfb_clock_sync_ccf_impl.cc  | 2 +-
 gr-digital/lib/pfb_clock_sync_fff_impl.cc  | 2 +-
 gr-noaa/lib/hrpt_pll_cf_impl.cc| 2 +-
 gr-qtgui/lib/HistogramDisplayPlot.cc   | 2 +-
 34 files changed, 36 insertions(+), 36 deletions(-)
 rename gnuradio-runtime/include/gnuradio/{math.h => math_utils.h} (98%)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using rx rate stream tag to control throttle

[Steve Glass]

Hi,

Some minor changes relating to metadata files and stream tags. The first
simply provides a command line option that causes uhd_rx_cfile to write
metadata files. The second modifies the throttle so that it uses the
rx_rate stream tag to change the throttle rate (this behaviour is
enabled only if a rate of <= 0 is passed to the throttle ctor).

Regards

Steve

- -

The following changes since commit 9fb34ce4b3d9c524f687d2e6c106c971541d8921:

  Merge branch 'maint' (2013-11-11 14:36:53 -0500)

are available in the git repository at:


  g...@github.com:stiabhan/gnuradio.git  metadata

for you to fetch changes up to 10ae10dc690604b4316ca044be39ca32030a1a10:

  gr-blocks: modify throttle so it can be controlled using stream tag.
(2013-11-13 22:12:20 +1000)

- 
Steve Glass (2):
  gr-uhd: add option to uhd_rx_cfile to write metadata file.
  gr-blocks: modify throttle so it can be controlled using stream tag.

 gr-blocks/include/gnuradio/blocks/throttle.h |  2 +-
 gr-blocks/lib/throttle_impl.cc   | 26 +++---
 gr-blocks/lib/throttle_impl.h|  1 +
 gr-blocks/python/blocks/qa_throttle.py   | 41 
-
 gr-uhd/apps/uhd_rx_cfile | 35 
++-
 5 files changed, 95 insertions(+), 10 deletions(-)
 mode change 100755 => 100644 gr-uhd/apps/uhd_rx_cfile


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming gnuradio/math.h to gnuradio/math_utils.h

[Tom Rondeau]

On Sun, Nov 17, 2013 at 5:01 PM, Steve Glass  wrote:
> Hi,
>
> The gnuradio/math.h header is causing some problems for some
> out-of-tree builds that use C code. If these projects add the GNURadio
> includes to their build path then the system math.h header is hidden
> and cannot be included (this occurs, e.g., in AirProbe's gsm-receiver).
>
> It seems bad form to define a math.h that isn't the system one so the
> following pull request renames math.h to math_utils.h and changes the
> references to the old header to the new name.
>
> Regards
>
> Steve

Hi Steve

The math.h file should always be included as:

#include 

We've moved everything under the gnuradio/* directory exactly to avoid
these kinds of naming clashes. All projects using GNU Radio should
update to only include header files in this way and should not have
this directory in the include path (e.g., no -I/usr/include/gnuradio).

Tom



> The following changes since commit
> 54d3961bdaaa708152e33264b95759bab4d94c87:
>
>   Merge branch 'master' into next (2013-11-14 12:45:59 -0500)
>
> are available in the git repository at:
>
>
>   g...@github.com:stiabhan/gnuradio.git  math-header-rename
>
> for you to fetch changes up to 7588f1875d1a932464e67b6865476619288fa8b0:
>
>   gnuradio-runtime: Rename math.h to math_utils.h. (2013-11-15
> 14:53:06 +1000)
>
> - 
> Steve Glass (1):
>   gnuradio-runtime: Rename math.h to math_utils.h.
>
>  gnuradio-runtime/include/gnuradio/CMakeLists.txt   | 2 +-
>  gnuradio-runtime/include/gnuradio/{math.h => math_utils.h} | 6 +++---
>  gnuradio-runtime/lib/buffer.cc | 2 +-
>  gnuradio-runtime/lib/math/fast_atan2f.cc   | 2 +-
>  gnuradio-runtime/lib/math/qa_fast_atan2f.cc| 2 +-
>  gnuradio-runtime/lib/math/qa_math.cc   | 2 +-
>  gr-analog/lib/fmdet_cf_impl.cc | 2 +-
>  gr-analog/lib/pll_carriertracking_cc_impl.cc   | 2 +-
>  gr-analog/lib/pll_freqdet_cf_impl.cc   | 2 +-
>  gr-analog/lib/pll_refout_cc_impl.cc| 2 +-
>  gr-analog/lib/quadrature_demod_cf_impl.cc  | 2 +-
>  gr-analog/lib/rail_ff_impl.cc  | 2 +-
>  gr-atsc/lib/atsc_fpll.cc   | 2 +-
>  gr-atsc/lib/atsci_equalizer_lms2.cc| 2 +-
>  gr-atsc/lib/atsci_sssr.cc  | 2 +-
>  gr-blocks/lib/complex_to_arg_impl.cc   | 2 +-
>  gr-blocks/lib/control_loop.cc  | 2 +-
>  gr-blocks/lib/udp_source_impl.cc   | 2 +-
>  gr-digital/lib/binary_slicer_fb_impl.cc| 2 +-
>  gr-digital/lib/clock_recovery_mm_cc_impl.cc| 2 +-
>  gr-digital/lib/clock_recovery_mm_ff_impl.cc| 2 +-
>  gr-digital/lib/cma_equalizer_cc_impl.h | 2 +-
>  gr-digital/lib/constellation.cc| 2 +-
>  gr-digital/lib/constellation_receiver_cb_impl.cc   | 2 +-
>  gr-digital/lib/correlate_and_sync_cc_impl.cc   | 2 +-
>  gr-digital/lib/costas_loop_cc_impl.cc  | 2 +-
>  gr-digital/lib/kurtotic_equalizer_cc_impl.h| 2 +-
>  gr-digital/lib/mpsk_receiver_cc_impl.cc| 2 +-
>  gr-digital/lib/ofdm_frame_acquisition_impl.cc  | 2 +-
>  gr-digital/lib/ofdm_frame_sink_impl.cc | 2 +-
>  gr-digital/lib/pfb_clock_sync_ccf_impl.cc  | 2 +-
>  gr-digital/lib/pfb_clock_sync_fff_impl.cc  | 2 +-
>  gr-noaa/lib/hrpt_pll_cf_impl.cc| 2 +-
>  gr-qtgui/lib/HistogramDisplayPlot.cc   | 2 +-
>  34 files changed, 36 insertions(+), 36 deletions(-)
>  rename gnuradio-runtime/include/gnuradio/{math.h => math_utils.h} (98%)
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using rx rate stream tag to control throttle

[Tom Rondeau]

On Sun, Nov 17, 2013 at 5:03 PM, Steve Glass  wrote:
> Hi,
>
> Some minor changes relating to metadata files and stream tags. The first
> simply provides a command line option that causes uhd_rx_cfile to write
> metadata files. The second modifies the throttle so that it uses the
> rx_rate stream tag to change the throttle rate (this behaviour is
> enabled only if a rate of <= 0 is passed to the throttle ctor).
>
> Regards
>
> Steve
>
> - -
>
> The following changes since commit 9fb34ce4b3d9c524f687d2e6c106c971541d8921:
>
>   Merge branch 'maint' (2013-11-11 14:36:53 -0500)
>
> are available in the git repository at:
>
>
>   g...@github.com:stiabhan/gnuradio.git  metadata
>
> for you to fetch changes up to 10ae10dc690604b4316ca044be39ca32030a1a10:
>
>   gr-blocks: modify throttle so it can be controlled using stream tag.
> (2013-11-13 22:12:20 +1000)
>
> - 
> Steve Glass (2):
>   gr-uhd: add option to uhd_rx_cfile to write metadata file.
>   gr-blocks: modify throttle so it can be controlled using stream tag.
>
>  gr-blocks/include/gnuradio/blocks/throttle.h |  2 +-
>  gr-blocks/lib/throttle_impl.cc   | 26
> +++---
>  gr-blocks/lib/throttle_impl.h|  1 +
>  gr-blocks/python/blocks/qa_throttle.py   | 41
> -
>  gr-uhd/apps/uhd_rx_cfile | 35
> ++-
>  5 files changed, 95 insertions(+), 10 deletions(-)
>  mode change 100755 => 100644 gr-uhd/apps/uhd_rx_cfile

Please use the Issue tracker on gnuradio.org to report this as a
feature. Email is likely to get lost before we can get to it.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OSParam Error

[Paul B. Huter]

I am running a USRP source through a throttle to an FFT sink and a file
sink. Last time I ran it, I got an "OSParam error", followed by a bunch of
"D"s and the FFT was lagging and jumping. Any ideas as to what this is? My
sample rate is 50M.

Paul B. Huter
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OSParam Error

[Marcus D. Leech]

I am running a USRP source through a throttle to an FFT sink and a 
file sink. Last time I ran it, I got an "OSParam error", followed by a 
bunch of "D"s and the FFT was lagging and jumping. Any ideas as to 
what this is? My sample rate is 50M.


Paul B. Huter


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
You only ever need a "throttle" when you don't have hardware in the 
flow-graph pacing things.


AT 50Msps, whatever your flow-graph is doing will be working *really, 
really* hard.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OSParam Error

[Paul B. Huter]

As always, thank you, Marcus.

I am thinking about getting rid of the graph (and throttle, now), and
making another setup to run the output file from the original (through a
throttle?) to the graph to look at smaller pieces. I want to be able to
look at (say) 5MHz-10MHz, so my plan is to set the FFT to be 5MHz centered
on 7.5MHz. However, I am not sure if that is correct. But - first step is
to get my data.

Thanks, again, Marcus.

Paul B. Huter
On Nov 17, 2013 5:41 PM, "Marcus D. Leech"  wrote:

>   I am running a USRP source through a throttle to an FFT sink and a file
> sink. Last time I ran it, I got an "OSParam error", followed by a bunch of
> "D"s and the FFT was lagging and jumping. Any ideas as to what this is? My
> sample rate is 50M.
>
> Paul B. Huter
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  You only ever need a "throttle" when you don't have hardware in the
> flow-graph pacing things.
>
> AT 50Msps, whatever your flow-graph is doing will be working *really,
> really* hard.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FFT --> IFFT

[Robert James]

When I take a signal, stream->vector-->FFT-->IFFT-->vector->stream,
I'd expect to get the original signal back.  Instead, I'm getting
something like the original signal, but following a very low frequency
carrier.

I thought this was due to the limits in vector size, but making this
very high (many times the sample size and signal freq) and the problem
continues,

What's weirdest is that a low pass filter or band pass filter on the
output don't seem to solve the problem!

What is my mistake?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Supress freq below db threshold

[Robert James]

Is there a block that can set a threshold in the freq domain? That is,
any freq with less than x db should have no power whatsoever?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT --> IFFT

[Marcus Müller]

Hi Robert!

This is strange -- but could be explained by the fact that numerical inaccuracy 
don't allow us to *exactly* recreate all values during fft-ifft operation.
Also, make sure you use a rectangular window.

How do you know there is this very low frequency carrier? how low is it? How 
much power does it have?

Greetings
Marcus

On 11/18/2013 03:40 AM, Robert James wrote:

When I take a signal, stream->vector-->FFT-->IFFT-->vector->stream,
I'd expect to get the original signal back.  Instead, I'm getting
something like the original signal, but following a very low frequency
carrier.

I thought this was due to the limits in vector size, but making this
very high (many times the sample size and signal freq) and the problem
continues,

What's weirdest is that a low pass filter or band pass filter on the
output don't seem to solve the problem!

What is my mistake?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OSParam Error

[Marcus Müller]

Don't use a throttle in a flow graph with a hardware source. A throttle block 
is software-limiting the number of samples that pass your flowgraph on average 
in a given time. You have an USRP that produces samples at a constant rate: 
Either this rate is significantly lower than your throttle rate, in which case 
throttle is superflous, or you'll run into problems because throttle is trying 
to throttle what it shouldn't throttle because the hardware defines how fast 
your samples must flow.

For your file-sourced flowgraph, however, throttle is the right way to go -- 
but honestly, with 50Ms/s your PC will most likely get into such heavy work 
that it can't process everything in real-time (otherwise it could do it with 
live data, too) and your throttle doesn't do anything.

I don't know your osparam error. But the D errors are likely caused by your 
computer being to busy to process the samples.
Reduce the sample rate at the usrp, if you want to look at 10MHz of bandwidth, 
anyway.
On 11/18/2013 12:49 AM, Paul B. Huter wrote:


As always, thank you, Marcus.

I am thinking about getting rid of the graph (and throttle, now), and making 
another setup to run the output file from the original (through a throttle?) to 
the graph to look at smaller pieces. I want to be able to look at (say) 
5MHz-10MHz, so my plan is to set the FFT to be 5MHz centered on 7.5MHz. 
However, I am not sure if that is correct. But - first step is to get my data.

Thanks, again, Marcus.

Paul B. Huter

On Nov 17, 2013 5:41 PM, "Marcus D. Leech" mailto:mle...@ripnet.com>> wrote:


I am running a USRP source through a throttle to an FFT sink and a file sink. Last time I ran 
it, I got an "OSParam error", followed by a bunch of "D"s and the FFT was 
lagging and jumping. Any ideas as to what this is? My sample rate is 50M.

Paul B. Huter


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

You only ever need a "throttle" when you don't have hardware in the 
flow-graph pacing things.

AT 50Msps, whatever your flow-graph is doing will be working *really, 
really* hard.



-- 
Marcus Leech

Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio