Thursday, September 30, 2010

Re: [Discuss-gnuradio] rssi question

HI,

I am working on the USRP2 and gnuradio. And I want to use them to get the rssi (like bluetooth). Through reading the former posts for rssi on GNU Radio mailing list, using the rssi.v is the solution. But I still have some questions about the rssi.v. I am a fresh man and looking for some helps through with baby step questions as follows:
 
1. I can not find any rssi.v in lastest version gnuradio (version 3.3.0), instead, the rssi.v file is found in gr-bluetooth project folder (it is another project which set up based on the gnuradio and used to deal with the bluetooth signal). Is it OK to copy the rssi.v file from the Internet and add it into the gnuradio folder?
 
2. The rssi.v file is a  Verilog file?? I do not how to use it. Is there any links to explain this?? (I try.. but did not find it)
 
Thanks a lot.
 
------------ LION
 
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Since it's a Verilog file, I assume that it's for deriving RSSI values in the firmware in the FPGA, or perhaps for reading whatever RSSI
  registers a given hardware RX module might provide.

But signal strength (RSSI) can b easily computed in software from your signals--there's an RMS Power block that can be used.
  It produces linear units, but you could then plug that into a log power block to get dB if you want dB units.  There's no need to
  have the hardware do that calculation--it's very simple and straightforward.



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

[Discuss-gnuradio] About synchronize two USRP2s using external reference (SMA)

I tried to synchronize two USRP2s using external reference (SMA).
I input 10-MHz signal to REFCLOCK pin and a trigger in PPS IN.

I modified rx_streaming_samples.cc and wrote the following code
u2->config_mimo(usrp2::MC_WE_LOCK_TO_SMA);
I use txrx_raw_eth_20100608.bin and u2_rev3-20100603.bin.
but I failed to synchronize two USRP2s.

I synchronized start timing using PPS but two USRP2's signal
have phase difference. This phase difference change every observation.
Some figures are attached.
In this case, I input RF signals of 130 MHz + 0.05 MHz to RF1 and set as follows:
Center frequency: 130 MHz
Decimation: 4

When I don't set center frequency, two USRP2's signal don't have phase difference.
So I suppose this is due to the phase difference between NCOs of two USRP2.

What should I do?

Many Thanks.

Youhei Wakisaka.

Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?

Hi Nick,

I have a USRP2 + RFX2400 which I'd like to use as a transceiver. here
are my questions:
1- Assuming I get two antennas, one connected to TX/RX port and the
second one connected to RX2 port, Can I get the first antenna to act as
the TX (driven only by DAC) and the second one act as RX (driving only
ADC)? If so, do I get 30MHz of bandwidth on each antenna?
2- Is that true that if I don't configure the DAC, it will use its
default values for example for the modulation, upsampling factor, ....?
3- I understand the default modulation of DAC is "NONE", what is the
default interpolation rate (none, 1x, 2x or 4x)?
4- Assuming I configure the DAC IF frequency to be 0 (modulation
="NONE"), does that mean if I pick the RF center frequency of the TX and RX
to be the same, I need no demodulation (to be implemented inside FPGA
)on the data captured from ADC and this data is all baseband?
5- At the TX side, does the dac_a carry interleaved I/Q? or dac_a
carries only I and dac_b carries only Q of the same samples?
6- At the RX side, does the adc_a carry interleaved I/Q? or adc_a
carries only I and adc_b carries only Q of the same samples?

Thanks,
Malihe

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A/D Output

Hello,

I am using gnuradio and a usrp2 to capture samples (shorts) to a file,
that is 16 bit I and 16 bit Q.
I looked at this data in matlab and noticed that in many instances the
samples exceed 13 and 14 bits
for both positive and negative numbers (ie -12567 or +12989).

I was under the impression that a 14 bit a/d meant 13 bits plus a sign
bit so max 8191, min -8191.

Should I expect this behavior, am I interpreting something incorrectly.
If this is expected
can someone please explain. I though the rx_gain was applied before the
a/d so the max
output would be be 13 bits plus a sign bit.

Thank you,
Sharif

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] rssi question

HI,

I am working on the USRP2 and gnuradio. And I want to use them to get the rssi (like bluetooth). Through reading the former posts for rssi on GNU Radio mailing list, using the rssi.v is the solution. But I still have some questions about the rssi.v. I am a fresh man and looking for some helps through with baby step questions as follows:
 
1. I can not find any rssi.v in lastest version gnuradio (version 3.3.0), instead, the rssi.v file is found in gr-bluetooth project folder (it is another project which set up based on the gnuradio and used to deal with the bluetooth signal). Is it OK to copy the rssi.v file from the Internet and add it into the gnuradio folder?
 
2. The rssi.v file is a  Verilog file?? I do not how to use it. Is there any links to explain this?? (I try.. but did not find it)
 
Thanks a lot.
 
------------ LION

Re: [Discuss-gnuradio] two USRP2 simulin

On 09/30/2010 01:29 PM, Laser_s wrote:
>
> Hello!
>
> I have tow USRP2.
> Can I connect both boards thougth a switch gigabit ¿???
> I know that it is impossible with the ethenet firmware because the boards
> use the pause time of the gigabit protocol.
>
> But if I use simulink with the udp firmware I can use a switch?? or is
> impossible???
>

You cannot because of the use of pause frames for flow control:
http://www.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking

I dont think the gnuradio mailing list is an appropriate place to ask
simulink questions... Please use usrp-users@lists.ettus.com

Thanks,
-Josh

> Best regards

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] About a typeerror

Hi, everyone,

When I ran a python program, I met such a question, can you holp me to point out where the problem is?

The problem is as follows:

Traceback (most recent call last):
  File "MainFrame.py", line 106, in OnDBPSK_Demodulate
    objDemod = DBPSKDemod.dbpsk_demod(fg)
  File "/home/cwang/prj/ufl/source_code/Receiver/DBPSKDemod.py", line 153, in __init__
    gr.hier_block2.__init__(self, self._fg, self.pre_scaler, self.unpack)    #changed from block to block2, cwang 9.29
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/hier_block2.py", line 42, in __init__
    self._hb = hier_block2_swig(name, input_signature, output_signature)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1015, in hier_block2_swig
    return _gnuradio_swig_py_runtime.hier_block2_swig(*args, **kwargs)
TypeError: in method 'hier_block2_swig', argument 1 of type 'std::string const'


Thanks.

Cheng

 

[Discuss-gnuradio] two USRP2 simulin

Hello!

I have tow USRP2.
Can I connect both boards thougth a switch gigabit ¿???
I know that it is impossible with the ethenet firmware because the boards
use the pause time of the gigabit protocol.

But if I use simulink with the udp firmware I can use a switch?? or is
impossible???

Best regards
--
View this message in context: http://old.nabble.com/two-USRP2-simulin-tp29852117p29852117.html
Sent from the GnuRadio mailing list archive at Nabble.com.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Link Improvement via Feedback

Hello all, 


We're interested in using USRP2s and GNURadio for a wireless link, and adding a cognitive engine to it to improve link performance (PHY only).

 

Currently, we are using benchmark_rx.py and benchmark_tx.py (from digital folder). Each USRP is connected to a seperate laptop via Ethernet.

 

We can change knobs (eg: transmit power) at the transmit side (Node1) now during transmission. We are working on getting meter values (metrics such as SNR, BER, RSSI, etc.) from the receiver (Node2) and then passing them back to Node1.


We've noticed that there is digital-ber rx scripts, can this be used with the digital/benchmark_tx.py in order to transfer a file? We did not see support for a specified file in the digital-bert/benchmark_tx.py script.

 

What kind of set-up have people used for Cognitive radio feedback? If anyone has done this before and has suggestions, please let us know! Thanks in advance.


--
Daniel Ali
Graduate Student
Electrical and Computer Engineering
Virginia Tech

Re: [Discuss-gnuradio] Optimal way of performing multiple FFTs on a stream of data

Thanks Eric. My FFTs are not that big so I guess I will be fine.

On Wed, Sep 29, 2010 at 4:59 PM, Eric Blossom <eb@comsec.com> wrote:
On Wed, Sep 29, 2010 at 01:47:22PM -0700, John Andrews wrote:
> Hi,
> This is more of a programming question than a gnuradio question.
>
> I am writing a C++ block that takes in a stream of complex data, an N
> element block {B} is chosen from the stream, this block is multiplied with a
> set {M1, M2, M3...Mn} where size of each set element is N (same as data
> block) too. I want to find FFT using FFTW library on each of the products
> {B.M1, B.M2, .... B.Mn} in the general_work() function. As this can be an
> intensive task can someone suggest me what could be the optimal strategy to
> do without compromising efficiency and risk losing samples that is entering
> the machine from the USRP. I was thinking about multithreading. Do you think
> this is the way to go?
>
> Thanks,
> John

I'd measure first, and see if you've really got a problem.
(Premature optimization is the root of all evil.)

Note also that GNU Radio itself is multithreaded, and if you're doing
substantial work in other blocks, your cores may already being put to
productive work.

Make sure that the version of FFTW you're using was built with SSE
support enabled.

 http://fftw.org/fftw3_doc/Installation-on-Unix.html

 ./configure --enable-sse --enable-float

Measure again :-)


If you do have a problem, and your cores are not already 100%
utilized, then you may want to look at using the FFTW's suport for
multithreading (inside of the package).  Note that it will only make
sense if you use one of the advanced interfaces that allows you to ask
it to compute multiple FFT's in one call to the API.  The standard
interface won't help, unless your FFTs are seriously big -- say, > 1M
points.

http://fftw.org/fftw3_doc/Multi_002dthreaded-FFTW.html
http://fftw.org/fftw3_doc/Advanced-Complex-DFTs.html

Eric

Re: [Discuss-gnuradio] No Gui Gnu Radio Companion

Hello,
 
Im running GRC and I have a grc file with no gui. When I run the file a python window displays and then disappears. I want to read whats in that window since it seems there is a problem with my file and its not printing to any where else. How do I do this? Is there a way to run the GRC file from the command line?
 
Thanks,
Justin
 
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
GRC produces a python program, which you can run directly.

If your flow-graph is named "foo", GRC will produce two files:

   o foo.grc
   o foo.py



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

[Discuss-gnuradio] No Gui Gnu Radio Companion

Hello,
 
Im running GRC and I have a grc file with no gui. When I run the file a python window displays and then disappears. I want to read whats in that window since it seems there is a problem with my file and its not printing to any where else. How do I do this? Is there a way to run the GRC file from the command line?
 
Thanks,
Justin

[Discuss-gnuradio] Syncronize a DSSS signal

Dear all, 
I'm trying to syncronize  the receiving signal from a Direct Sequence Spread Spectrum.
I have to divide the receiving signal by the code sequence, and i thought to put a delay block (gr_delay) betwen the spreading code and the division operator. Then I want to set the delay with a close loop control using my output signal, but the problem is that I'm not able to refresh the delay value, it stay only at the initial value.
I've tryied also to change it with a slide bar, but when I'm going to change the value I find an error : TypeError: in method 'gr_delay_sptr_set_delay', argument 2 of type 'int'
How can I make it work? Or have you other ideas to syncronize the system?

Thank you all.

Mauro Bressan

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

Hi !

Eric, thanks for your advise. Some results here.

I set my computer into "performance mode". At first sight nothing improves.

With the example usrp2_fft.py I can low the decimation to 5 and the application works ok.

As I said the FM modulator works ok by itself. The FM demodulator also works ok by itself. The problem is when I run both in the same flowgraph. I think it is not a problem of performance since my CPUs are not very work-loaded when my application is running.

My problem is that changes, in the FM modulator, which I think they would increase performance (like increasing my 13 interpolation in the USRP and decreasing my software interpolation) make my receiver chain non-working (SSS messages) although the transmitter outputs a perfect FM signal.

I do not understand these mesages since my CPUs are less than 15-20% used. However something is stopping the received data because I got a lot of dropped frames in my rx Ethernet interface (saw with ifconfig). I tried to increase the RX Ethernet buffer (sysctl -w net.core.rmem_max=XXXXX) but it didn't work. I also tried to set in my generated code the USRP source instance before the USRP sink but it didn't work neither.

Could be any reason why by decreasing software computation (and Ethernet traffic as well) in the transmitter path affects the performance of the RX path?

Many thanks,
Jorge.

On 28 September 2010 05:43, Eric Blossom <eb@comsec.com> wrote:
On Mon, Sep 27, 2010 at 10:07:07AM +0200, Jorge Miguel wrote:
> Hi all!
>
> I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS
> messages that mean my CPU cannot keep up with all frames generated by the
> USRP2 and drop most of them.
> However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
> M 520  @ 2.40GHz  on Ubuntu 10.4
>
> I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
> balance the workload among all my four cores to see if my application
> improves (ethernet interface doens't drop any frame).
>

First off, you don't really have 4 cores.  You've got 2 cores +
hyperthreading (they may have renamed it, but that's what you've got).

GNU Radio will automatically use whatever you've got, without you
having to do anything special.

Be sure that your laptop is in "Performance mode", and not trying to
save energy, or throttle back etc.  There are also some laptops out
there that have poor thermal design and can't really run at full speed
without overheating and thus throttling back the CPU.

Start with something like usrp_fft.py and see how low of a decimation
factor you can work with reliably.  That will give you a basic idea of
how your system is working.

If you're building your own flow graphs, it's quite easy to string
together more blocks, or use a a higher sample rate, than your machine
can keep up with.

After you've ruled out the stuff above, oprofile will help you sort
out which parts of your application are burning the most time.

Eric

[Discuss-gnuradio] using external front ends

Hi

I wanted to find out if it is possible to use daughterboards other
than the basic rx and tx with external front ends. Ie is it possible
to use the WBX daughterboard with an external front end?

Regards

Stacey

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Wednesday, September 29, 2010

[Discuss-gnuradio] Re: UHD Announcement - September 23rd 2010

> -------------------------------------------------------------------------
> In other news,
> UHD can now compile against pre-built libusb1.0 windows binaries:
> http://www.libusb.org/wiki/windows_backend#LatestBinarySnapshots
> Runtime operation has yet to be confirmed.
>
> Thanks!
> -Josh
>

For those of you following the uhd windows support: usrp1 seems to be
working with libusb-1.0 under windows. See the build notes here:
http://www.ettus.com/uhd_docs/manual/html/build.html#libusb-cmake-notes

Here is a link to the windows drivers on the main wiki page:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

And for those Gentoo/Ricer/Overclocker types: bulk transfer send and
recv parameters are now exposed to the user through the device address:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#change-usb-transfer-parameters

Enjoy!
-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Optimal way of performing multiple FFTs on a stream of data

On Wed, Sep 29, 2010 at 01:47:22PM -0700, John Andrews wrote:
> Hi,
> This is more of a programming question than a gnuradio question.
>
> I am writing a C++ block that takes in a stream of complex data, an N
> element block {B} is chosen from the stream, this block is multiplied with a
> set {M1, M2, M3...Mn} where size of each set element is N (same as data
> block) too. I want to find FFT using FFTW library on each of the products
> {B.M1, B.M2, .... B.Mn} in the general_work() function. As this can be an
> intensive task can someone suggest me what could be the optimal strategy to
> do without compromising efficiency and risk losing samples that is entering
> the machine from the USRP. I was thinking about multithreading. Do you think
> this is the way to go?
>
> Thanks,
> John

I'd measure first, and see if you've really got a problem.
(Premature optimization is the root of all evil.)

Note also that GNU Radio itself is multithreaded, and if you're doing
substantial work in other blocks, your cores may already being put to
productive work.

Make sure that the version of FFTW you're using was built with SSE
support enabled.

http://fftw.org/fftw3_doc/Installation-on-Unix.html

./configure --enable-sse --enable-float

Measure again :-)


If you do have a problem, and your cores are not already 100%
utilized, then you may want to look at using the FFTW's suport for
multithreading (inside of the package). Note that it will only make
sense if you use one of the advanced interfaces that allows you to ask
it to compute multiple FFT's in one call to the API. The standard
interface won't help, unless your FFTs are seriously big -- say, > 1M
points.

http://fftw.org/fftw3_doc/Multi_002dthreaded-FFTW.html
http://fftw.org/fftw3_doc/Advanced-Complex-DFTs.html

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ubuntu 10.10 source build pre-requisites

Are there any news about the pre-requisites for source build for the
new upcoming Ubuntu 10.10 distro ?

thx in advance, Arturo

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Same File Size

If throttle is removed then how can we prevent the cpu being used up if there is not rate limiting block in the flowgraph ?

On Wed, Sep 29, 2010 at 1:46 PM, Justin Bracken <scourched@gmail.com> wrote:
---------- Forwarded message ----------
From: Justin Bracken <scourched@gmail.com>
Date: Wednesday, September 29, 2010
Subject: Same File Size
To: Eric Blossom <eb@comsec.com>


Are the samples in the files synced? I.e. The sample at index 1 in
file1 is recorded at the same time as the sample at index 1 in file2?

In which case file length is irrelevant.

On Sep 29, 2010, at 4:20 PM, Eric Blossom <eb@comsec.com> wrote:

> On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote:
>> Hello All,
>>
>> I am expecting to see a similiar file size in a simple test file that im
>> running and I don't get that. Is there something Im missing?
>>
>> USRP2->FileSink
>> SignalSource->Throttle->FileSink
>>
>> I have checked obvious things. The USRP2 block is set to a decimation of
>> 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3
>> MS/s. So I set the overall sample rate to 250e3. I have also set the
>> datatypes of all the blocks to floats. The Throttle is set to 250e3.
>>
>> If it matters the  signal source is set to a saw tooth,1Hz.
>>
>> Im more interested in knowing that samples read back out of the files are
>> synchronized. So I guess it doesn't matter if they are the same length if
>> all this mean is that I need to trim the files to the same length.
>>
>> Thanks,
>> Justin
>
> If you want a particular number of samples in a file, etc.,
> use gr.head.
>
> Generally you SHOULD NOT be using throttle.
>
> throttle causes so much confusion, I'm of the opinion that we should
> remove it from the code base.
>
> Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Optimal way of performing multiple FFTs on a stream of data

Hi,
This is more of a programming question than a gnuradio question.

I am writing a C++ block that takes in a stream of complex data, an N element block {B} is chosen from the stream, this block is multiplied with a set {M1, M2, M3...Mn} where size of each set element is N (same as data block) too. I want to find FFT using FFTW library on each of the products {B.M1, B.M2, .... B.Mn} in the general_work() function. As this can be an intensive task can someone suggest me what could be the optimal strategy to do without compromising efficiency and risk losing samples that is entering the machine from the USRP. I was thinking about multithreading. Do you think this is the way to go?

Thanks,
John


[Discuss-gnuradio] Same File Size

---------- Forwarded message ----------
From: Justin Bracken <scourched@gmail.com>
Date: Wednesday, September 29, 2010
Subject: Same File Size
To: Eric Blossom <eb@comsec.com>


Are the samples in the files synced? I.e. The sample at index 1 in
file1 is recorded at the same time as the sample at index 1 in file2?

In which case file length is irrelevant.

On Sep 29, 2010, at 4:20 PM, Eric Blossom <eb@comsec.com> wrote:

> On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote:
>> Hello All,
>>
>> I am expecting to see a similiar file size in a simple test file that im
>> running and I don't get that. Is there something Im missing?
>>
>> USRP2->FileSink
>> SignalSource->Throttle->FileSink
>>
>> I have checked obvious things. The USRP2 block is set to a decimation of
>> 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3
>> MS/s. So I set the overall sample rate to 250e3. I have also set the
>> datatypes of all the blocks to floats. The Throttle is set to 250e3.
>>
>> If it matters the  signal source is set to a saw tooth,1Hz.
>>
>> Im more interested in knowing that samples read back out of the files are
>> synchronized. So I guess it doesn't matter if they are the same length if
>> all this mean is that I need to trim the files to the same length.
>>
>> Thanks,
>> Justin
>
> If you want a particular number of samples in a file, etc.,
> use gr.head.
>
> Generally you SHOULD NOT be using throttle.
>
> throttle causes so much confusion, I'm of the opinion that we should
> remove it from the code base.
>
> Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Same File Size

On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote:
> Hello All,
>
> I am expecting to see a similiar file size in a simple test file that im
> running and I don't get that. Is there something Im missing?
>
> USRP2->FileSink
> SignalSource->Throttle->FileSink
>
> I have checked obvious things. The USRP2 block is set to a decimation of
> 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3
> MS/s. So I set the overall sample rate to 250e3. I have also set the
> datatypes of all the blocks to floats. The Throttle is set to 250e3.
>
> If it matters the signal source is set to a saw tooth,1Hz.
>
> Im more interested in knowing that samples read back out of the files are
> synchronized. So I guess it doesn't matter if they are the same length if
> all this mean is that I need to trim the files to the same length.
>
> Thanks,
> Justin

If you want a particular number of samples in a file, etc.,
use gr.head.

Generally you SHOULD NOT be using throttle.

throttle causes so much confusion, I'm of the opinion that we should
remove it from the code base.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Same File Size

Hello All,
 
I am expecting to see a similiar file size in a simple test file that im running and I don't get that. Is there something Im missing?
 
USRP2->FileSink
SignalSource->Throttle->FileSink
 
I have checked obvious things. The USRP2 block is set to a decimation of 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3 MS/s. So I set the overall sample rate to 250e3. I have also set the datatypes of all the blocks to floats. The Throttle is set to 250e3.
 
If it matters the  signal source is set to a saw tooth,1Hz.
 
Im more interested in knowing that samples read back out of the files are synchronized. So I guess it doesn't matter if they are the same length if all this mean is that I need to trim the files to the same length.
 
Thanks,
Justin

Re: [Discuss-gnuradio] Stop GRC flow graph after defined time

You can use the Misc->Head block to limit the samples. Then set the flow
graph options to "run to completion", this option is only available in
non-gui mode. See the options blocks.

-Josh

On 09/29/2010 04:31 AM, Thorsten Laude wrote:
> Hallo,
>
> I'm executing a flow graph in GRC and want to stop this flow graph
> after some defined time, for example 3 seconds, or after a defined
> amount of samples.
>
> Currently I stop the flow graph by clicking on "Kill the flow graph".
> How can I implement, that the flow graph is stopped automatically?
>
> Thorsten
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] strange receiver behaviour with UHD

Thanks for all your replies!

We did some additional experiments where we divided our program into 2 phases.

In phase 1 we did all the initialization like setting rx rate, center frequency, gain, synchronizing to ref clock, and finally issued a stream command to receive samples. The received samples are then thrown away as you suggested.

In phase 2 all the settings are already set so we issue a new stream command to receive new samples. If we look at the abs value of these samples we still have the same "spike" in the beginning of the collected set.

Our conclusion is that the stream command somehow introduce this "spike" so we always need to receive more samples with the stream command and throw away the beginning of the collected set. We also tried different stream modes (STREAM_MODE_NUM_SAMPS_AND_DONE or STREAM_MODE_NUM_SAMPS_AND_MORE) but with the same result.

Regards
- Patrik

> -----Original Message-----
> From:
> discuss-gnuradio-bounces+patrik.eliardsson=foi.se@gnu.org
> [mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi.se@gnu.
> org] On Behalf Of Per Zetterberg
> Sent: Tuesday, September 28, 2010 7:46 PM
> To: Marcus D. Leech
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] strange receiver behaviour with UHD
>
> On Tue, 2010-09-28 at 13:34 -0400, Marcus D. Leech wrote:
> > >
> > > It's likely that initialization of the board gain and frequency
> > > settings will take some finite but non-zero amount of time to
> > > settle. It's always a good idea to toss the first few
> samples until
> > > things settle down. The settling time will be different for each
> > > daughterboard and should be experimentally determined in
> your application.
> > >
> > > --n
> > >
> > >
> > Yup, and I'd like to point out that this isn't just a
> "quirk" of this
> > particular hardware. All such hardware takes a finite
> amount of time
> > to "settle" -- the synthesizers often take a handful of
> milliseconds
> > to settle to their final value, and even VGA settings take
> finite time.
> >
> > The A/D has no way of knowing what that time is, so it
> starts sending
> > samples right away--those samples will contain "artifacts" of
> > whatever settling has to take place. Fact of life.
> >
> > I don't know how the filters in the FPGA are coded, but it also
> > wouldn't surprise me if they take some finite amount of
> time to converge
> > on correct output, since they'll have some indeterminate
> startup state.
> >
> >
>
> My experience is that it doesn't matter how long I wait after
> setting the gain and frequency.
>
>
> It could be FPGA filters.
>
> BR/
> Per
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Stop GRC flow graph after defined time

Hallo,

I'm executing a flow graph in GRC and want to stop this flow graph
after some defined time, for example 3 seconds, or after a defined
amount of samples.

Currently I stop the flow graph by clicking on "Kill the flow graph".
How can I implement, that the flow graph is stopped automatically?

Thorsten

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Tuesday, September 28, 2010

[Discuss-gnuradio] WBX transmitting on the TV band?‏‏

As you may know, the FCC has finalized the ruling of the TV white space on Sep. 23
Quoted from:  http://hardware.slashdot.org/story/10/09/24/2124223/FCC-White-Space-Rules-Favor-Tech-Industry

"They dropped the requirement that devices sense TV and wireless microphone signals. Instead, they can geolocate and use an online database to learn which white spaces are available in their area. "

I checked some other related news. It seems FCC only requires the TV band devices to update the channel-availability database on a daily basis.  Does that mean we can use the USRP+WBX to transmit over the TV band, and manually check the availability of channels on an online data base, such as:

http://spectrumbridge.com/products-services/whitespaces/showmywhitespace/single-location-search.aspx

Hope someone can help answer this question.  Thanks for your time!

- Hok

Re: [Discuss-gnuradio] strange receiver behaviour with UHD

On Tue, 2010-09-28 at 13:34 -0400, Marcus D. Leech wrote:
> >
> > It's likely that initialization of the board gain and frequency settings
> > will take some finite but non-zero amount of time to settle. It's always
> > a good idea to toss the first few samples until things settle down. The
> > settling time will be different for each daughterboard and should be
> > experimentally determined in your application.
> >
> > --n
> >
> >
> Yup, and I'd like to point out that this isn't just a "quirk" of this
> particular hardware. All such hardware takes a finite amount of time
> to "settle" -- the synthesizers often take a handful of milliseconds
> to settle to their final value, and even VGA settings take finite time.
>
> The A/D has no way of knowing what that time is, so it starts sending
> samples right away--those samples will contain "artifacts" of
> whatever settling has to take place. Fact of life.
>
> I don't know how the filters in the FPGA are coded, but it also wouldn't
> surprise me if they take some finite amount of time to converge
> on correct output, since they'll have some indeterminate startup state.
>
>

My experience is that it doesn't matter how long I wait after setting
the gain and frequency.


It could be FPGA filters.

BR/
Per

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] strange receiver behaviour with UHD

>
> It's likely that initialization of the board gain and frequency settings
> will take some finite but non-zero amount of time to settle. It's always
> a good idea to toss the first few samples until things settle down. The
> settling time will be different for each daughterboard and should be
> experimentally determined in your application.
>
> --n
>
>
Yup, and I'd like to point out that this isn't just a "quirk" of this
particular hardware. All such hardware takes a finite amount of time
to "settle" -- the synthesizers often take a handful of milliseconds
to settle to their final value, and even VGA settings take finite time.

The A/D has no way of knowing what that time is, so it starts sending
samples right away--those samples will contain "artifacts" of
whatever settling has to take place. Fact of life.

I don't know how the filters in the FPGA are coded, but it also wouldn't
surprise me if they take some finite amount of time to converge
on correct output, since they'll have some indeterminate startup state.


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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] strange receiver behaviour with UHD

It's likely that initialization of the board gain and frequency settings
will take some finite but non-zero amount of time to settle. It's always
a good idea to toss the first few samples until things settle down. The
settling time will be different for each daughterboard and should be
experimentally determined in your application.

--n

On Tue, 2010-09-28 at 15:15 +0200, Patrik Eliardsson wrote:
> Dear List,
>
> We have made a test program using a source and a file sink (see fg.jpg) where we are receiving a fixed number of samples (with UHD and USRP2 and WBX-card) from an AWGN-generator (constant power -19dB). If we plot the abs value of the received signal we always see a "spike" in the 10 first samples (see fig1) before the abs value settles to a more expected value. Sometimes (seldom) there is no "spike" but the result is still not as expected, the received data starts at a higher level and slopes down during a quite long time before settling to a stable level (see fig 2).
>
> Have we missed something or why does this "spike" occur? Is there some initialization time in the hardware that we need to take into consideration before we start to receive samples (recv) after setting all parameters?
>
> Br,
> Patrik
> _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with installation - grc does not start

> Thanks for your answer. I edited config.conf to:
>
> [grc]
> local_blocks_path=/home/gnuradio/gnuradio-uhd/gnuradio/grc/blocks:/home/gnuradio/gnuradio-uhd/gnuradio/gr-uhd/grc
>
> Now I can start grc and see the uhd blocks. The next problem is, that
> I can't execute any flow graphs out of grc, even if I run sudo grc I
> get:
>
> Executing: "/home/gnuradio/top_block.py"
> [Errno 13] Permission denied
>

thats weird, what are the permissions on top_block.py?

> My workaround was to execute the flowgraph from shell which works as
> long as I have no uhd blocks in my graph. With uhd blocks I get:
>
> gnuradio@nb-gnuradio:~$ ./top_block.py
> Traceback (most recent call last):
> File "./top_block.py", line 10, in<module>
> from gnuradio import uhd
> ImportError: cannot import name uhd
>
> What can I do to solve this problem?

When I install my gnuradio/uhd stuff into a non-standard prefix, I setup
the paths in .bashrc like so:

> derp_prefix=/home/jblum/usr
> export PKG_CONFIG_PATH=${derp_prefix}/lib/pkgconfig:${PKG_CONFIG_PATH}
> export PATH=${derp_prefix}/bin:$PATH
> export PYTHONPATH=${derp_prefix}/lib64/python2.6/site-packages:$PYTHONPATH
> export GRC_BLOCKS_PATH=${derp_prefix}/share/gnuradio/grc/blocks
> export LD_LIBRARY_PATH=${derp_prefix}/lib

Hope that helps,
-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] strange receiver behaviour with UHD

On Tue, 2010-09-28 at 15:15 +0200, Patrik Eliardsson wrote:
> Dear List,
>
> We have made a test program using a source and a file sink (see fg.jpg) where we are receiving a fixed number of samples (with UHD and USRP2 and WBX-card) from an AWGN-generator (constant power -19dB). If we plot the abs value of the received signal we always see a "spike" in the 10 first samples (see fig1) before the abs value settles to a more expected value. Sometimes (seldom) there is no "spike" but the result is still not as expected, the received data starts at a higher level and slopes down during a quite long time before settling to a stable level (see fig 2).
>
> Have we missed something or why does this "spike" occur? Is there some initialization time in the hardware that we need to take into consideration before we start to receive samples (recv) after setting all parameters?
>
> Br,
> Patrik
> _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I see also some kind of transient spur the 1000-2000 first samples when
using XCVR2450 (I have mentioned this before on the list :-). Next time
I have a basic dB connected I will check if this behavior is observed
also there. I always discard the 1000-2000 samples to avoid the problem.

BR/
Per


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] strange receiver behaviour with UHD

Dear List,

We have made a test program using a source and a file sink (see fg.jpg) where we are receiving a fixed number of samples (with UHD and USRP2 and WBX-card) from an AWGN-generator (constant power -19dB). If we plot the abs value of the received signal we always see a "spike" in the 10 first samples (see fig1) before the abs value settles to a more expected value. Sometimes (seldom) there is no "spike" but the result is still not as expected, the received data starts at a higher level and slopes down during a quite long time before settling to a stable level (see fig 2).

Have we missed something or why does this "spike" occur? Is there some initialization time in the hardware that we need to take into consideration before we start to receive samples (recv) after setting all parameters?

Br,
Patrik

Re: [Discuss-gnuradio] Problem with installation - grc does not start

2010/9/21 Josh Blum <josh@joshknows.com>:

> Create or edit ~/.gnuradio/config.conf and add the following lines:
>
> [grc]
> local_blocks_path=/path/to/my/blocks
>
> The local_blocks_path can contain multiple paths separated by colons:
> local_blocks_path=/path/to/blocks1:/path/to/blocks2

Thanks for your answer. I edited config.conf to:

[grc]
local_blocks_path=/home/gnuradio/gnuradio-uhd/gnuradio/grc/blocks:/home/gnuradio/gnuradio-uhd/gnuradio/gr-uhd/grc

Now I can start grc and see the uhd blocks. The next problem is, that
I can't execute any flow graphs out of grc, even if I run sudo grc I
get:

Executing: "/home/gnuradio/top_block.py"
[Errno 13] Permission denied

My workaround was to execute the flowgraph from shell which works as
long as I have no uhd blocks in my graph. With uhd blocks I get:

gnuradio@nb-gnuradio:~$ ./top_block.py
Traceback (most recent call last):
File "./top_block.py", line 10, in <module>
from gnuradio import uhd
ImportError: cannot import name uhd

What can I do to solve this problem?

Thorsten

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Monday, September 27, 2010

RE: [Discuss-gnuradio] USRP2 LEDs using UHD

Thanks!
I guess I don't need to look at the blinking B and E LEDs then.

> -----Original Message-----
> From: discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org]
> On Behalf Of Josh Blum
> Sent: Tuesday, September 28, 2010 1:27 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] USRP2 LEDs using UHD
>
> I just added this to the documentation:
>
> http://www.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
>
> -Josh
>
> On 09/27/2010 06:54 AM, Ulrika Uppman wrote:
> > Hi!
> > What does the LEDs indicate when running USRP2 with UHD?
> > I understand some information about whether rx or tx are
> running is presented on the LEDs, but I cannot find any
> information on which ones that is and what the other four
> LEDs are indicating?
> >
> > Best regards
> > Ulrika
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Debugging environment variables

On 09/27/2010 11:47 PM, Eric Blossom wrote:
> On Mon, Sep 27, 2010 at 07:02:34AM -0400, Philip Balister wrote:
>> It seems like there are some environment variables you can set to
>> make GNU radio print some debug info. Does anyone have a list of
>> these?
>>
>> Philip
>
> None that I'm aware of :-)
>
> There are some #define's in parts of the runtime code that will
> produce debugging output if you enable them.
>
> For looking at scheduler behavior the one you want is at the top of
> gr_block_executor.cc.
>
> // must be defined to either 0 or 1
> #define ENABLE_LOGGING 0

Thanks, this is what I was looking for.

Philip

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Debugging environment variables

On Mon, Sep 27, 2010 at 07:02:34AM -0400, Philip Balister wrote:
> It seems like there are some environment variables you can set to
> make GNU radio print some debug info. Does anyone have a list of
> these?
>
> Philip

None that I'm aware of :-)

There are some #define's in parts of the runtime code that will
produce debugging output if you enable them.

For looking at scheduler behavior the one you want is at the top of
gr_block_executor.cc.

// must be defined to either 0 or 1
#define ENABLE_LOGGING 0

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

On Mon, Sep 27, 2010 at 10:07:07AM +0200, Jorge Miguel wrote:
> Hi all!
>
> I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS
> messages that mean my CPU cannot keep up with all frames generated by the
> USRP2 and drop most of them.
> However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
> M 520 @ 2.40GHz on Ubuntu 10.4
>
> I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
> balance the workload among all my four cores to see if my application
> improves (ethernet interface doens't drop any frame).
>

First off, you don't really have 4 cores. You've got 2 cores +
hyperthreading (they may have renamed it, but that's what you've got).

GNU Radio will automatically use whatever you've got, without you
having to do anything special.

Be sure that your laptop is in "Performance mode", and not trying to
save energy, or throttle back etc. There are also some laptops out
there that have poor thermal design and can't really run at full speed
without overheating and thus throttling back the CPU.

Start with something like usrp_fft.py and see how low of a decimation
factor you can work with reliably. That will give you a basic idea of
how your system is working.

If you're building your own flow graphs, it's quite easy to string
together more blocks, or use a a higher sample rate, than your machine
can keep up with.

After you've ruled out the stuff above, oprofile will help you sort
out which parts of your application are burning the most time.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 LEDs using UHD

I just added this to the documentation:

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds

-Josh

On 09/27/2010 06:54 AM, Ulrika Uppman wrote:
> Hi!
> What does the LEDs indicate when running USRP2 with UHD?
> I understand some information about whether rx or tx are running is presented on the LEDs, but I cannot find any information on which ones that is and what the other four LEDs are indicating?
>
> Best regards
> Ulrika
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Good system for 4-channel MIMO?

On 09/27/2010 06:00 AM, Per Zetterberg wrote:
> Hi List,
>
> What computer+network cards (=system) should I have to be able to stream
> to four (or possibly even six) USRP2s at full speed (25Msamp/sec) ?
>
> BR/
> Per


We've had good results with the Intel quad gigabit PCIe card.
Unfortunately, it costs way more than 4 individual cards, but if you're
short on PCIe slots it is your only choice.

Matt


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow

> CPU scheduling is generally the responsibility of the operating system > kernel, *NOT* Gnu Radio.  What Gnu Radio does is schedule > blocks to threads, and the execution of those threads, and CPU  > assignment is up to the kernel.  In general, the kernel does a good > job of CPU scheduling.  > Your problem is probably that your flow-graphs aren't optimal in some > way, and thus take more system resources than they should.  Yes, I do not why it takes a lot of resources alhough I can see with gkrellm application that my CPUs are about 50-60%, so it is not so bad.   
Try making the transition bandwidth on your filters a little wider (like double their current width)--this will make the FIR filters shorter, which
  will reduce computational burden, although the existing filters aren't that long, it's worth a shot.


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

[Discuss-gnuradio] USRP2 LEDs using UHD

Hi!
What does the LEDs indicate when running USRP2 with UHD?
I understand some information about whether rx or tx are running is presented on the LEDs, but I cannot find any information on which ones that is and what the other four LEDs are indicating?

Best regards
Ulrika
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Good system for 4-channel MIMO?

Hi List,

What computer+network cards (=system) should I have to be able to stream
to four (or possibly even six) USRP2s at full speed (25Msamp/sec) ?

BR/
Per

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio supports PWM (Pulse Width Modulation) ?

On Mon, Sep 27, 2010 at 3:56 AM, 전석성 <gee.songsong@gmail.com> wrote:
> I'm curious about it.
>
> I just started some research to transmit message with this PWM.
> However, I couldn't find any PWM block in GNURadio Companion.
>
> I'll be happy and give thanks to someone answer my stupid question.


No, there is no current PWM block in GNU Radio. You'll either have to
put together blocks to do it or create your own.

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow

> CPU scheduling is generally the responsibility of the operating system > kernel, *NOT* Gnu Radio.  What Gnu Radio does is schedule > blocks to threads, and the execution of those threads, and CPU 
> assignment is up to the kernel. In general, the kernel does a good > job of CPU scheduling. > Your problem is probably that your flow-graphs aren't optimal in some > way, and thus take more system resources than they should.
Yes, I do not why it takes a lot of resources alhough I can see with gkrellm application that my CPUs are about 50-60%, so it is not so bad.
> The other issue may be your GiGE network interface might be one that > isn't very good in the buffering department, and thus makes the > system work *much* harder than it should handling continuous packet > traffic. > What bandwidth are you using? (That is, what decimation/interpolation > are you using)?
I am using 30,76Mbps in the transmitter (USRP interpolation sink 104)
I am using  6,25Mbps in the receiver (USRP decimation source 512)

> You haven't shared much in the way of details about your flow-graph, and > I suspect that's where your problem lies.
I can post my .py file which is:
from gnuradio import audio
from gnuradio import blks2
from gnuradio import gr
from gnuradio import usrp2
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import forms
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")

##################################################
# Variables
##################################################
self.tune_osc_dem = tune_osc_dem = 94000000
self.tune_filter = tune_filter = 75000
self.samp_rate = samp_rate = 32000
self.fm_freq_mod = fm_freq_mod = 94000000

##################################################
# Controls
##################################################
_tune_osc_dem_sizer = wx.BoxSizer(wx.VERTICAL)
self._tune_osc_dem_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_tune_osc_dem_sizer,
value=self.tune_osc_dem,
callback=self.set_tune_osc_dem,
label="Tunned frequency demodulator",
converter=forms.float_converter(),
proportion=0,
)
self._tune_osc_dem_slider = forms.slider(
parent=self.GetWin(),
sizer=_tune_osc_dem_sizer,
value=self.tune_osc_dem,
callback=self.set_tune_osc_dem,
minimum=88000000,
maximum=108000000,
num_steps=800,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.Add(_tune_osc_dem_sizer)
_tune_filter_sizer = wx.BoxSizer(wx.VERTICAL)
self._tune_filter_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_tune_filter_sizer,
value=self.tune_filter,
callback=self.set_tune_filter,
label="LPF Cutoff Freq",
converter=forms.float_converter(),
proportion=0,
)
self._tune_filter_slider = forms.slider(
parent=self.GetWin(),
sizer=_tune_filter_sizer,
value=self.tune_filter,
callback=self.set_tune_filter,
minimum=15000,
maximum=150000,
num_steps=1000,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.Add(_tune_filter_sizer)
_fm_freq_mod_sizer = wx.BoxSizer(wx.VERTICAL)
self._fm_freq_mod_text_box = forms.text_box(
parent=self.GetWin(),
sizer=_fm_freq_mod_sizer,
value=self.fm_freq_mod,
callback=self.set_fm_freq_mod,
label="FM frequency modulator",
converter=forms.float_converter(),
proportion=0,
)
self._fm_freq_mod_slider = forms.slider(
parent=self.GetWin(),
sizer=_fm_freq_mod_sizer,
value=self.fm_freq_mod,
callback=self.set_fm_freq_mod,
minimum=0,
maximum=110000000,
num_steps=300,
style=wx.SL_HORIZONTAL,
cast=float,
proportion=1,
)
self.Add(_fm_freq_mod_sizer)

##################################################
# Blocks
##################################################
self.audio_sink_0 = audio.sink(32000, "plughw:0,0", True)
self.blks2_fm_demod_cf_0 = blks2.fm_demod_cf(
channel_rate=320000,
audio_decim=10,
deviation=75000,
audio_pass=1000,
audio_stop=16000,
gain=20.0,
tau=75e-6,
)
self.blks2_rational_resampler_xxx_0_0 = blks2.rational_resampler_fff(
interpolation=5,
decimation=1,
taps=None,
fractional_bw=None,
)
self.blks2_rational_resampler_xxx_1 = blks2.rational_resampler_fff(
interpolation=4,
decimation=1,
taps=None,
fractional_bw=None,
)
self.blks2_rational_resampler_xxx_1_0_0 = blks2.rational_resampler_ccc(
interpolation=100,
decimation=61,
taps=None,
fractional_bw=None,
)
self.gr_frequency_modulator_fc_0 = gr.frequency_modulator_fc(0.980)
self.gr_multiply_const_vxx_1 = gr.multiply_const_vcc((32000, ))
self.gr_wavfile_source_0 = gr.wavfile_source("/home/jorge/Desktop/outfile2.wav", True)
self.low_pass_filter_0 = gr.fir_filter_ccf(1, firdes.low_pass(
3, 320000, tune_filter, 5000, firdes.WIN_HAMMING, 6.76))
self.low_pass_filter_0_0 = gr.interp_fir_filter_fff(1, firdes.low_pass(
1, 240000, 18e3, 2e3, firdes.WIN_HAMMING, 6.76))
self.usrp2_sink_xxxx_0 = usrp2.sink_32fc()
self.usrp2_sink_xxxx_0.set_interp(104)
self.usrp2_sink_xxxx_0.set_center_freq(fm_freq_mod)
self.usrp2_sink_xxxx_0.set_gain(0)
self.usrp2_source_xxxx_0 = usrp2.source_32fc()
self.usrp2_source_xxxx_0.set_decim(512)
self.usrp2_source_xxxx_0.set_center_freq(tune_osc_dem)
self.usrp2_source_xxxx_0.set_gain(10)

##################################################
# Connections
##################################################
self.connect((self.gr_frequency_modulator_fc_0, 0), (self.gr_multiply_const_vxx_1, 0))
self.connect((self.blks2_rational_resampler_xxx_0_0, 0), (self.low_pass_filter_0_0, 0))
self.connect((self.low_pass_filter_0_0, 0), (self.blks2_rational_resampler_xxx_1, 0))
self.connect((self.gr_wavfile_source_0, 0), (self.blks2_rational_resampler_xxx_0_0, 0))
self.connect((self.blks2_rational_resampler_xxx_1, 0), (self.gr_frequency_modulator_fc_0, 0))
self.connect((self.usrp2_source_xxxx_0, 0), (self.blks2_rational_resampler_xxx_1_0_0, 0))
self.connect((self.blks2_fm_demod_cf_0, 0), (self.audio_sink_0, 0))
self.connect((self.blks2_rational_resampler_xxx_1_0_0, 0), (self.low_pass_filter_0, 0))
self.connect((self.low_pass_filter_0, 0), (self.blks2_fm_demod_cf_0, 0))
self.connect((self.gr_multiply_const_vxx_1, 0), (self.usrp2_sink_xxxx_0, 0))

def set_tune_osc_dem(self, tune_osc_dem):
self.tune_osc_dem = tune_osc_dem
self._tune_osc_dem_slider.set_value(self.tune_osc_dem)
self._tune_osc_dem_text_box.set_value(self.tune_osc_dem)
self.usrp2_source_xxxx_0.set_center_freq(self.tune_osc_dem)

def set_tune_filter(self, tune_filter):
self.tune_filter = tune_filter
self.low_pass_filter_0.set_taps(firdes.low_pass(3, 320000, self.tune_filter, 5000, firdes.WIN_HAMMING, 6.76))
self._tune_filter_slider.set_value(self.tune_filter)
self._tune_filter_text_box.set_value(self.tune_filter)

def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate

def set_fm_freq_mod(self, fm_freq_mod):
self.fm_freq_mod = fm_freq_mod
self._fm_freq_mod_slider.set_value(self.fm_freq_mod)
self._fm_freq_mod_text_box.set_value(self.fm_freq_mod)
self.usrp2_sink_xxxx_0.set_center_freq(self.fm_freq_mod)

if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = top_block()
tb.Run(True)


Frequency sample rates are matched.
I cannot understand why changing the USRP sink interpolation affects the FM demodulator.
They should be independent if the Ethernet traffic is under the limit. I see a lot ot SSSSSS mesages and also audio underruns.

Many thanks for your help,
Jorge

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

> Hi all! > > I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS > messages that mean my CPU cannot keep up with all frames generated by > the USRP2 and drop most of them. > However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 > CPU M 520 @ 2.40GHz on Ubuntu 10.4 > > I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I > can balance the workload among all my four cores to see if my > application improves (ethernet interface doens't drop any frame). > > Looking at other post of the mailing list I found: > > 1)"Try using numactl". > Well, for me is not possible, after installing that library and running: > :~$ numactl -s > physcpubind: 0 1 2 3 > No NUMA support available on this system. > > 2)"Look at the output of cat /proc/cpuinfo "physical id" indicates > which cores are in which sockets" > In all four processors physical id : 0 > > Furthermore whe I execute top command I can see: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3022 root 20 0 238m 66m 45m S 166 3.6 > 3:32.12 python > > > Is my GRC file only executing in one core? How can I find it out? > Any idea to fix it? > > Many thanks, > Jorge > > > 

[Discuss-gnuradio] Debugging environment variables

It seems like there are some environment variables you can set to make
GNU radio print some debug info. Does anyone have a list of these?

Philip

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

> Hi all!
>
> I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS
> messages that mean my CPU cannot keep up with all frames generated by
> the USRP2 and drop most of them.
> However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5
> CPU M 520 @ 2.40GHz on Ubuntu 10.4
>
> I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I
> can balance the workload among all my four cores to see if my
> application improves (ethernet interface doens't drop any frame).
>
> Looking at other post of the mailing list I found:
>
> 1)"Try using numactl".
> Well, for me is not possible, after installing that library and running:
> :~$ numactl -s
> physcpubind: 0 1 2 3
> No NUMA support available on this system.
>
> 2)"Look at the output of cat /proc/cpuinfo "physical id" indicates
> which cores are in which sockets"
> In all four processors physical id : 0
>
> Furthermore whe I execute top command I can see:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3022 root 20 0 238m 66m 45m S 166 3.6
> 3:32.12 python
>
>
> Is my GRC file only executing in one core? How can I find it out?
> Any idea to fix it?
>
> Many thanks,
> Jorge
>
>
>
CPU scheduling is generally the responsibility of the operating system
kernel, *NOT* Gnu Radio. What Gnu Radio does is schedule
blocks to threads, and the execution of those threads, and CPU
assignment is up to the kernel. In general, the kernel does a good
job of CPU scheduling.

Your problem is probably that your flow-graphs aren't optimal in some
way, and thus take more system resources than they should.

The other issue may be your GiGE network interface might be one that
isn't very good in the buffering department, and thus makes the
system work *much* harder than it should handling continuous packet
traffic.

What bandwidth are you using? (That is, what decimation/interpolation
are you using)?

You haven't shared much in the way of details about your flow-graph, and
I suspect that's where your problem lies.

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

Hi all!

I am Tx/Rx a FM signal at the same time, but I can see a lot of SSSSS messages that mean my CPU cannot keep up with all frames generated by the USRP2 and drop most of them.
However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz  on Ubuntu 10.4

I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can balance the workload among all my four cores to see if my application improves (ethernet interface doens't drop any frame).

Looking at other post of the mailing list I found:

1)"Try using numactl".
Well, for me is not possible, after installing that library and running:
:~$ numactl -s
physcpubind: 0 1 2 3
No NUMA support available on this system.

2)"Look at the output of cat /proc/cpuinfo "physical id" indicates which cores are in which sockets"
In all four processors physical id    : 0

Furthermore whe I execute top command I can see:
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+     COMMAND 
 3022 root         20   0  238m  66m  45m   S  166         3.6       3:32.12     python


Is my GRC file only executing in one core? How can I find it out?
Any idea to fix it?

Many thanks,
Jorge

[Discuss-gnuradio] GNURadio supports PWM (Pulse Width Modulation) ?

I'm curious about it.

I just started some research to transmit message with this PWM.
However, I couldn't find any PWM block in GNURadio Companion.

I'll be happy and give thanks to someone answer my stupid question.

Sunday, September 26, 2010

Re: [Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

> Hi Marcus,
>
> On 9/26/2010 12:35 AM, Marcus D. Leech wrote:
>>>
>>> In the April/May 2010 SARA Journal, Marcus Leech had an article
>>> entitled
>>> "Building an SDR SID Receiver in an Afternoon" which was highly
>>> information and inspirational.
>
> [...]
>
>> John, let me send you the latest TAR image of my SID receiver work--it
>> has progressed quite a bit beyond that article, and Gnu Radio
>> has also changed since I wrote that article.
>
> If that offer is open to others on the list, I would be interested in
> seeing the updates.
>
> Thanks!
>
>

http://www.sbrac.org/files/sidsuite.tar.gz

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

On Sun, Sep 26, 2010 at 09:40:58AM -0400, Tom Rondeau wrote:
> On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum <josh@joshknows.com> wrote:
> >
> >>
> >> I agree with you it's not exactly right.
> >>
> >> I'm not sure about the right action.
> >>
> >> This issue should probably go onto the list of things to be considered
> >> in the grand build restructuring that was discussed by some of us a
> >> couple of weeks ago.
> >>
> >
> > Autotools is trying to be helpful by setting the "unspecified" prefix to
> > NONE during configure. But since gnuradio is using it as if it was always
> > set I suggest we do the following at the top of configure.ac
> >
> > if test "${prefix}" = "NONE"; then
> >    prefix=${ac_default_prefix}
> > fi
> >
> > We can put it on the next branch and hope it fixes more things than it
> > breaks... at least until the grand rebuild structuring comes along. :-)
> >
> > -Josh
>
>
> Thanks, guys. I've made a note of this to keep in mind while we're
> working on the restructuring.
>
> Tom
>

It looks like it's part of autoconf's machinery...
On my system I found it in /usr/share/autoconf/autoconf/general.m4
around line 558.

AC_SUBST(prefix, NONE)dnl

There's a discussion here that's relevant:

http://www.mail-archive.com/autoconf@gnu.org/msg15773.html


I think Josh's suggestion will work. It probably has to occur after
AC_INIT (or maybe AC_PREREQ). Not sure if there's anything else that
needs to run first.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum <josh@joshknows.com> wrote:
>
>>
>> I agree with you it's not exactly right.
>>
>> I'm not sure about the right action.
>>
>> This issue should probably go onto the list of things to be considered
>> in the grand build restructuring that was discussed by some of us a
>> couple of weeks ago.
>>
>
> Autotools is trying to be helpful by setting the "unspecified" prefix to
> NONE during configure. But since gnuradio is using it as if it was always
> set I suggest we do the following at the top of configure.ac
>
> if test "${prefix}" = "NONE"; then
>    prefix=${ac_default_prefix}
> fi
>
> We can put it on the next branch and hope it fixes more things than it
> breaks... at least until the grand rebuild structuring comes along. :-)
>
> -Josh


Thanks, guys. I've made a note of this to keep in mind while we're
working on the restructuring.

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

Thanks very much Marcus. I eventually figured out that in the variable block, I needed to include:
 

gr.firdes.complex_band_pass (gain,sampling_freq,low_cutoff_freq,

high_cutoff_freq, transition_width, window = WIN_HAMMING,beta = 6.76)

and when I plugged in some variables based on the b/w and centre frequency, the Decimating FIR filter block went good!

Of course, no idea if my guesses are real-world.

Look forward to getting the latest and greatest.

 

           Slainte,

 

                     John

 

Saturday, September 25, 2010

Re: [Discuss-gnuradio] USRP2 1pps synchronization delay

Does this describe what you are seeing?

http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg26328.html

On 09/25/2010 08:50 PM, Kelley, Clifford W wrote:
>
> We are trying to determine how much delay there is between the 1pps pulse and when the samples come out properly time tagged. Using a GPS timing receiver we connected up the 10MHz clock and 1pps to the USRP2. The software is set up to reset on the next 1pps pulse. With a GPS software receiver we determined that there is a delay of 3 - 6 microseconds which curiously was 3 with a smaller decimation and 6 at a higher decimation. We've checked over the setup and can't find any reason for this. Does anyone have any ideas?
>
> Thanks,
>
> Cliff
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

>
> In the April/May 2010 SARA Journal, Marcus Leech had an article entitled
> "Building an SDR SID Receiver in an Afternoon" which was highly
> information and inspirational. While my sound card only goes to 48 KHz
> sampling, I decided to try his implementation and in terms of entry into
> GRC, things have gone well except for the taps and their variables and a
> non-cooperative import box.
>
> While the screenshot in the article shows variables of ID: c1..4_taps
> and value of gr.firdes.complex_b... the text hints are band_pass and the
> variable blocks do accept this though it is displayed as value:
> <functio.... 0x8801ae4> , however, the Decimating FIR Filters complain
> about:
>
> Problem 1
>
>
>>>> Param - Taps(taps):
>>>>
> Expression "[<function complex_band_pass at 0x8801ae4>]" is invalid for
> type complex vector.
>
> no matter which "type" I specify for the filter.
>
> Problem 2
>
> import :notchfilt
>
> >>> Param - Import(import):
> Bad import syntax: "notchfilt".
>
> have tried notchfilter etc. but without success. Not sure if this is
> related to Problem 1?
>
> Kind Regards,
>
> John
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
John, let me send you the latest TAR image of my SID receiver work--it
has progressed quite a bit beyond that article, and Gnu Radio
has also changed since I wrote that article.


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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 1pps synchronization delay

We are trying to determine how much delay there is between the 1pps pulse and when the samples come out properly time tagged. Using a GPS timing receiver we connected up the 10MHz clock and 1pps to the USRP2. The software is set up to reset on the next 1pps pulse. With a GPS software receiver we determined that there is a delay of 3 - 6 microseconds which curiously was 3 with a smaller decimation and 6 at a higher decimation. We've checked over the setup and can't find any reason for this. Does anyone have any ideas?

Thanks,

Cliff


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

In the April/May 2010 SARA Journal, Marcus Leech had an article entitled
"Building an SDR SID Receiver in an Afternoon" which was highly
information and inspirational. While my sound card only goes to 48 KHz
sampling, I decided to try his implementation and in terms of entry into
GRC, things have gone well except for the taps and their variables and a
non-cooperative import box.

While the screenshot in the article shows variables of ID: c1..4_taps
and value of gr.firdes.complex_b... the text hints are band_pass and the
variable blocks do accept this though it is displayed as value:
<functio.... 0x8801ae4> , however, the Decimating FIR Filters complain
about:

Problem 1

>>> Param - Taps(taps):
Expression "[<function complex_band_pass at 0x8801ae4>]" is invalid for
type complex vector.

no matter which "type" I specify for the filter.

Problem 2

import :notchfilt

>>> Param - Import(import):
Bad import syntax: "notchfilt".

have tried notchfilter etc. but without success. Not sure if this is
related to Problem 1?

Kind Regards,

John


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

>
> I agree with you it's not exactly right.
>
> I'm not sure about the right action.
>
> This issue should probably go onto the list of things to be considered
> in the grand build restructuring that was discussed by some of us a
> couple of weeks ago.
>

Autotools is trying to be helpful by setting the "unspecified" prefix to
NONE during configure. But since gnuradio is using it as if it was
always set I suggest we do the following at the top of configure.ac

if test "${prefix}" = "NONE"; then
prefix=${ac_default_prefix}
fi

We can put it on the next branch and hope it fixes more things than it
breaks... at least until the grand rebuild structuring comes along. :-)

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

On Sat, Sep 25, 2010 at 12:32:36PM -0700, Josh Blum wrote:
>
> >Fair enough, Eric. So do you suggest another approach that allows
> >boostrap/configure/make to "just work", or simply more notes
> > about this in the build instructions when you're using UHD?
> >
> >
>
> The issue being that all the gnuradio dependencies are distribution
> installable (on linux) so you dont need to set special paths and
> environment variables. However, UHD is not ready to be handed out as
> rpms and debs (though it can be) so it may need special paths set to
> use on operating system <X>.
>
> However, it looks like gnuradio wants to set your PKG_CONFIG_PATH to
> include the ${prefix}/lib${lib_suffix}/pkgconfig. So, if you happen
> to use the same prefix and lib_suffix as you built for UHD, gnuradio
> should be able to find the uhd.pc file without you needing to set
> PKG_CONFIG_PATH by hand.
>
> The problem with this being, if --prefix is not set, gnuradio sets
> this to NONE/lib${lib_suffix}/pkgconfig which isnt going to work.
> Maybe ${ac_default_prefix} can be used when ${prefix} is set to NONE

That would probably be better than what we've got.

Independent of the use case you brought up, there's a couple of other
places we run afoul the same issue (prefix == NONE). IIRC it gets
baked into some C/C++ strings somewhere too.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

On Sat, Sep 25, 2010 at 12:23:19PM -0700, Josh Blum wrote:
>
>
> On 09/25/2010 12:01 PM, Eric Blossom wrote:
> >On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
> >>This turns out to be a bug in gnuradio configure - when --prefix is
> >>not specified with ./configure, the ${prefix} variable is set to
> >>NONE
> >
> >Listen guys, you may not like this behavior, but it's not a bug.
> >If you read the makefile standards, it's to allow a package to be
> >installed into a different location at "make install" time.
> >
>
> Thats fine, but is it fine that configure.ac sets PKG_CONFIG_PATH to
> NONE/lib/pkgconfig when --prefix is not specified. Thats not a
> problem?

I agree with you it's not exactly right.

I'm not sure about the right action.

This issue should probably go onto the list of things to be considered
in the grand build restructuring that was discussed by some of us a
couple of weeks ago.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

> Fair enough, Eric. So do you suggest another approach that allows
> boostrap/configure/make to "just work", or simply more notes
> about this in the build instructions when you're using UHD?
>
>

The issue being that all the gnuradio dependencies are distribution
installable (on linux) so you dont need to set special paths and
environment variables. However, UHD is not ready to be handed out as
rpms and debs (though it can be) so it may need special paths set to use
on operating system <X>.

However, it looks like gnuradio wants to set your PKG_CONFIG_PATH to
include the ${prefix}/lib${lib_suffix}/pkgconfig. So, if you happen to
use the same prefix and lib_suffix as you built for UHD, gnuradio should
be able to find the uhd.pc file without you needing to set
PKG_CONFIG_PATH by hand.

The problem with this being, if --prefix is not set, gnuradio sets this
to NONE/lib${lib_suffix}/pkgconfig which isnt going to work. Maybe
${ac_default_prefix} can be used when ${prefix} is set to NONE

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

On 09/25/2010 12:01 PM, Eric Blossom wrote:
> On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
>> This turns out to be a bug in gnuradio configure - when --prefix is
>> not specified with ./configure, the ${prefix} variable is set to
>> NONE
>
> Listen guys, you may not like this behavior, but it's not a bug.
> If you read the makefile standards, it's to allow a package to be
> installed into a different location at "make install" time.
>

Thats fine, but is it fine that configure.ac sets PKG_CONFIG_PATH to
NONE/lib/pkgconfig when --prefix is not specified. Thats not a problem?

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio