Re: [Discuss-gnuradio] Is USRP mandatory for gnu radio for cognitive radio

[Derek Kozel]

Hello M S Sumi,

The GNU Radio tutorials are a great place to gain an understanding of doing
digital signal processing without hardware connected and then the later
tutorial covers the use of hardware to see actual RF signals.
https://wiki.gnuradio.org/index.php/Guided_Tutorials

Regards,
Derek

On Mon, Oct 30, 2017 at 3:43 AM, M S SUMI  wrote:

> Thank you for the information. I will go through it.
>
> On 30-Oct-2017 08:02, "Kyeong Su Shin"  wrote:
>
> Dear M S SUMI:
>
> You don't need to have USRPs, but you probably want to have SDR
> transceiver board(s) with you if you want to deal with the real-world
> signals. Without SDR boards, you can only do simulations with synthetic
> data (which is often fine).
>
> Look for RTL-SDR (receive only), ADALM-PLUTO, or LimeSDR Mini (not
> released yet) if you need cheaper alternatives to USRP.
>
> Regards,
> Kyeong Su Shin
>
> On Sun, Oct 29, 2017 at 2:36 PM, M S SUMI  wrote:
>
>> I am learning to use gnu radio for cognitive radio spectrum sensing.
>> Whether gnu radio software can be used for primary signal detection without
>> interfacing a USRP kit...
>>
>> ___
>> 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] Is USRP mandatory for gnu radio for cognitive radio

[M S SUMI]

Thanks, I'll check it out.

On 30-Oct-2017 16:36, "Derek Kozel"  wrote:

> Hello M S Sumi,
>
> The GNU Radio tutorials are a great place to gain an understanding of
> doing digital signal processing without hardware connected and then the
> later tutorial covers the use of hardware to see actual RF signals.
> https://wiki.gnuradio.org/index.php/Guided_Tutorials
>
> Regards,
> Derek
>
> On Mon, Oct 30, 2017 at 3:43 AM, M S SUMI  wrote:
>
>> Thank you for the information. I will go through it.
>>
>> On 30-Oct-2017 08:02, "Kyeong Su Shin"  wrote:
>>
>> Dear M S SUMI:
>>
>> You don't need to have USRPs, but you probably want to have SDR
>> transceiver board(s) with you if you want to deal with the real-world
>> signals. Without SDR boards, you can only do simulations with synthetic
>> data (which is often fine).
>>
>> Look for RTL-SDR (receive only), ADALM-PLUTO, or LimeSDR Mini (not
>> released yet) if you need cheaper alternatives to USRP.
>>
>> Regards,
>> Kyeong Su Shin
>>
>> On Sun, Oct 29, 2017 at 2:36 PM, M S SUMI  wrote:
>>
>>> I am learning to use gnu radio for cognitive radio spectrum sensing.
>>> Whether gnu radio software can be used for primary signal detection without
>>> interfacing a USRP kit...
>>>
>>> ___
>>> 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] Performance monitoring within Gnuradio

[Michael Dickens]

Hi Vipin - To get performance counters, you have to rebuild GNU Radio
and enable them specifically via the cmake command addition
"-DENABLE_PERFORMANCE_COUNTERS=ON". Make sure to review the output of
the cmake command to verify that they have been enabled, then once
you're satisfied do the usual build and install. You'll have to figure
out how to make use of PCs; I think TomR did a presentation on them,
once upon a time, that would be useful.

An alternative is to use "htop" and turn on thread names since GR
internally names all threads based on the block running in the thread.
"htop" won't give you the high level of detail of PCs, but it also
doesn't require you to install Thrift nor rebuild GR; it can be used
with your current GR install & will give you an idea of which blocks are
using the most CPU cycles.

Hope this helps! - MLD

On Sun, Oct 29, 2017, at 10:21 AM, Vipin Sharma wrote:
> I am trying to monitor performance for my custom blocks using GnuRadio's perf 
> monitoring tools. After researching a bit, I found out that I need to install 
> Apache Thrift.
> 
> Do I need to re-build GnuRadio to leverage Thrift?
> 
> If yes, what options should I give to build script so that it recognizes and 
> builds with Thrift?
> 
> I really just want to measure how much time the work function of my custom 
> block is taking. This way of measuring performance sounds very invasive. May 
> be I should just add code to the work function to measure CPU cycles?
> 
> What is the simplest way to do this?

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

[Discuss-gnuradio] Best Way to revert to old releases with PyBombs.

[Richard Mcallister]

Hi all,

I think the question is all in the subject, but basically, I'm having
trouble with using several USRPs. I think it may be an issue with UHD, or
at least I need to verify it isn't. Does pybombs have a command to install
older releases or specific branch tags from git?

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

Re: [Discuss-gnuradio] Performance monitoring within Gnuradio

[Vipin Sharma]

Thanks for the tip!

I will try htop first and then rebuild if necessary.

On Mon, Oct 30, 2017 at 5:29 AM Michael Dickens 
wrote:

> Hi Vipin - To get performance counters, you have to rebuild GNU Radio
> and enable them specifically via the cmake command addition
> "-DENABLE_PERFORMANCE_COUNTERS=ON". Make sure to review the output of
> the cmake command to verify that they have been enabled, then once
> you're satisfied do the usual build and install. You'll have to figure
> out how to make use of PCs; I think TomR did a presentation on them,
> once upon a time, that would be useful.
>
> An alternative is to use "htop" and turn on thread names since GR
> internally names all threads based on the block running in the thread.
> "htop" won't give you the high level of detail of PCs, but it also
> doesn't require you to install Thrift nor rebuild GR; it can be used
> with your current GR install & will give you an idea of which blocks are
> using the most CPU cycles.
>
> Hope this helps! - MLD
>
> On Sun, Oct 29, 2017, at 10:21 AM, Vipin Sharma wrote:
> > I am trying to monitor performance for my custom blocks using GnuRadio's
> perf monitoring tools. After researching a bit, I found out that I need to
> install Apache Thrift.
> >
> > Do I need to re-build GnuRadio to leverage Thrift?
> >
> > If yes, what options should I give to build script so that it recognizes
> and builds with Thrift?
> >
> > I really just want to measure how much time the work function of my
> custom block is taking. This way of measuring performance sounds very
> invasive. May be I should just add code to the work function to measure CPU
> cycles?
> >
> > What is the simplest way to do this?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance monitoring within Gnuradio

[Dave NotTelling]

There is also the Linux tool `perf`.  I use that instead of the GNU Radio
tools due to library compatibility issues (also thrift is a pita to get
working with GNU Radio in my experience).  An example is: `perf top -p
 --call-graph=fp` (use sudo if needed).  If you want to see everything
you can use the PID of the flowgraph itself.  If you want to see individual
modules then you'll need to use `top -H` or whatever htop flags are needed
to see thread names.  From there you can get the PID of a specific block
and use that PID in the call to `perf`.  You can get an idea of where your
module is spending a lot of it's time.  Not sure if you need debugging
symbols installed or not.  I just use the habit of always building
debugging symbols while doing dev work.  An example of usage in the real
world: https://jvns.ca/blog/2016/02/24/perf-top-my-new-best-friend/


On Mon, Oct 30, 2017 at 10:41 AM, Vipin Sharma 
wrote:

> Thanks for the tip!
>
> I will try htop first and then rebuild if necessary.
>
> On Mon, Oct 30, 2017 at 5:29 AM Michael Dickens 
> wrote:
>
>> Hi Vipin - To get performance counters, you have to rebuild GNU Radio
>> and enable them specifically via the cmake command addition
>> "-DENABLE_PERFORMANCE_COUNTERS=ON". Make sure to review the output of
>> the cmake command to verify that they have been enabled, then once
>> you're satisfied do the usual build and install. You'll have to figure
>> out how to make use of PCs; I think TomR did a presentation on them,
>> once upon a time, that would be useful.
>>
>> An alternative is to use "htop" and turn on thread names since GR
>> internally names all threads based on the block running in the thread.
>> "htop" won't give you the high level of detail of PCs, but it also
>> doesn't require you to install Thrift nor rebuild GR; it can be used
>> with your current GR install & will give you an idea of which blocks are
>> using the most CPU cycles.
>>
>> Hope this helps! - MLD
>>
>> On Sun, Oct 29, 2017, at 10:21 AM, Vipin Sharma wrote:
>> > I am trying to monitor performance for my custom blocks using
>> GnuRadio's perf monitoring tools. After researching a bit, I found out that
>> I need to install Apache Thrift.
>> >
>> > Do I need to re-build GnuRadio to leverage Thrift?
>> >
>> > If yes, what options should I give to build script so that it
>> recognizes and builds with Thrift?
>> >
>> > I really just want to measure how much time the work function of my
>> custom block is taking. This way of measuring performance sounds very
>> invasive. May be I should just add code to the work function to measure CPU
>> cycles?
>> >
>> > What is the simplest way to do this?
>>
>
> ___
> 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] Fwd: Random test failures when compiling GNURadio from source

[Kevin George]

Hello,

We have been trying to compile and run GNURadio from source and the make
tests have been failing randomly.

*Machine Details*

*Intel NUC (x86-64 machine)*
*Ubuntu 16.04.03*
*GNU Radio version 3.7.11*
*gcc version 5.4.0 20160609 *

*Commands used*
*git clone --recursive https://github.com/gnuradio/gnuradio
*

*git checkout v3.7.11*

*mkdir build*

*cd build*

*cmake -DENABLE_GR_QTGUI=OFF -DCMAKE_INSTALL_PREFIX=/usr/local ../*

*make -j4*
*make test*

Out of every 4 compilations, 1/2 would fail the make test e.g
qa_constellation_receiver(attached
error with email) or
qa_ofdm_sync_sc_cfb. Our fix so far has been to* re-run the build with no
modifications and the tests pass*.

I have seen similar errors pop up in the mailing lists and the cause is
usually incorrect setting of seed.
e.g
https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00318.html
Does this issue still persist? or known?


-- 
Regards
Kevin
151/213 Testing: qa_constellation_receiver
151/213 Test: qa_constellation_receiver
Command: "/bin/sh" 
"/tmp/workarea-gnuradio/gnuradio/build/gr-digital/python/digital/qa_constellation_receiver_test.sh"
Directory: /tmp/workarea-gnuradio/gnuradio/build/gr-digital/python/digital
"qa_constellation_receiver" start time: Oct 30 19:53 UTC
Output:
--
F.
==
FAIL: test_basic (__main__.test_constellation_receiver)
--
Traceback (most recent call last):
  File 
"/tmp/workarea-gnuradio/gnuradio/gr-digital/python/digital/qa_constellation_receiver.py",
 line 132, in test_basic
self.assertTrue(correct > req_correct)
AssertionError: False is not true

--
Ran 2 tests in 0.725s

FAILED (failures=1)
Constellation is . Differential is True.  
Required correct is 0.8. Correct is 0.773026315789. FAIL.

Test time =   1.62 sec
--
Test Failed.
"qa_constellation_receiver" end time: Oct 30 19:53 UTC
"qa_constellation_receiver" time elapsed: 00:00:01
--
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Random test failures when compiling GNURadio from source

[Sebastian Müller]

I’ve noticed the same on our buildbot setup (and wanted to address this for
a while). `qa_packet_format` is another candidate which seems to randomly
fail. Also compiling on buildbot seems to fail sometimes randomly because
of `M_SQRT2` or `M_LOG2E` undeclared errors.

So, Kevin, without having a deeper look I assume the tests need to be
revised. I’m also glad to have a look as soon as I find some time. Maybe we
can accumulate faulty tests within this thread and start working from there.

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE


Am 30. Oktober 2017 um 21:14:15, Kevin George (ke...@intelligentrobotics.org)
schrieb:

Hello,

We have been trying to compile and run GNURadio from source and the make
tests have been failing randomly.

*Machine Details*

*Intel NUC (x86-64 machine)*
*Ubuntu 16.04.03*
*GNU Radio version 3.7.11*
*gcc version 5.4.0 20160609*

*Commands used*
*git clone --recursive https://github.com/gnuradio/gnuradio
*

*git checkout v3.7.11*

*mkdir build*

*cd build*

*cmake -DENABLE_GR_QTGUI=OFF -DCMAKE_INSTALL_PREFIX=/usr/local ../*

*make -j4*
*make test*

Out of every 4 compilations, 1/2 would fail the make test e.g
qa_constellation_receiver(attached
error with email) or
qa_ofdm_sync_sc_cfb. Our fix so far has been to *re-run the build with no
modifications and the tests pass*.

I have seen similar errors pop up in the mailing lists and the cause is
usually incorrect setting of seed.
e.g
https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00318.html
Does this issue still persist? or known?


--
Regards
Kevin
___
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] AirSpy Mini won't install

[Andrew Rich]

What have I missed ?

sudo port install gnuradio
sudo port install airspy
sudo port install rtl-sdr
sudo port install gr-osmosdr
sudo port install gqrx
sudo port install gqrx-devel
sudo port install libusb
sudo port install libusb-devel
sudo port install hackrf
sudo port install hackrf-devel

Andrew 

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

Re: [Discuss-gnuradio] AirSpy Mini won't install

[Andrew Rich]

> Generating: '/maint/scripts/top_block.py'
> 
> Executing: 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>  -u /maint/scripts/top_block.py
> 
> Mac OS; Clang version 8.1.0 (clang-802.0.42); Boost_105900; 
> UHD_003.010.002.000-MacPorts-Release
> 
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
> built-in source types: file fcd rtl rtl_tcp uhd sdrplay hackrf bladerf 
> rfspace airspy soapy 
> 
> >>> DoneOn 31 Oc


> t 2017, at 7:51 am, Andrew Rich  wrote:
> 
> What have I missed ?
> 
> sudo port install gnuradio
> sudo port install airspy
> sudo port install rtl-sdr
> sudo port install gr-osmosdr
> sudo port install gqrx
> sudo port install gqrx-devel
> sudo port install libusb
> sudo port install libusb-devel
> sudo port install hackrf
> sudo port install hackrf-devel
> 
> Andrew 
> 
> ___
> 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] [USRP-users] Dynamically Sweep Center Frequency for USRP2

[Patrick Sathyanathan]

You can look at usrp_spectrum_sense script. This sweeps a specified frequency 
range, does an FFT, and outputs one line for every bin where the magnitude 
exceeds a specified limit.


You could modify it to just write the samples to a file/pipe like uhd_rx_cfile.


--Patrick


From: USRP-users  on behalf of Rohit 
Kulkarni via USRP-users 
Sent: Sunday, October 29, 2017 6:02 PM
To: usrp-us...@lists.ettus.com
Subject: Re: [USRP-users] Dynamically Sweep Center Frequency for USRP2

Hi,

Can someone help me with this?


Thanks,
Rohit

On Thu, Oct 26, 2017 at 2:47 PM, Rohit Kulkarni 
mailto:k.rohi...@gmail.com>> wrote:
Hi,

I am working on a project that requires capturing the analog signal in a 
particular band with the help of USRP2 and then it sends the data over the GigE 
connection to the host machine for further processing. Currently, I am using 
uhd_rx_cfile -A $ANTENNA -r $SAMPLE_RATE_SPS -f $FREQ_HZ -g $GAIN command to 
set the center frequency.

Next, I want to write a program/use an existing program/script which uniformly 
sweeps the center frequency in some particular range (say 100MHz to 1 GHz). Can 
you tell me if there is any existing script that does this? Any pointers on how 
I can write a new script from scratch?

Apologies if this exact question is answered before!

Thanks,
Rohit

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

Re: [Discuss-gnuradio] Best Way to revert to old releases with PyBombs.

[Nicolas Cuervo]

Hello Richard,

I believe the best way (so far) would be to actually go to the repository
that you want to rebuild and checkout to the different specific branch/tag
and then trigger the rebuild with

$ pybombs -p *your_prefix* rebuild *uhd*

You can rebuild faster by adding the '-k' flag at the end of the command,
so it won't delete the build directory and start over (depends on the
number of API changes this might be a good or a bad idea).

If you are using GNURadio, don't forget to rebuild is as well so it picks
up the right version. And, if you identify any issues with UHD, please also
start a thread on the USRP-users mailing list in order to discuss them
further.

Regards,
- Nicolas



On Mon, Oct 30, 2017 at 3:05 PM, Richard Mcallister  wrote:

> Hi all,
>
> I think the question is all in the subject, but basically, I'm having
> trouble with using several USRPs. I think it may be an issue with UHD, or
> at least I need to verify it isn't. Does pybombs have a command to install
> older releases or specific branch tags from git?
>
> Thanks,
> Rich McAllister
>
> ___
> 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] Best Way to revert to old releases with PyBombs.

[Martin Braun]

You can even specify a git revision, by doing something like

$ pybombs -p  config --package uhd gitrev release_003_009_006

Then, if you do pybombs rebuild (without the -k), it'll update your git
source. (At least it should -- typing this out from memory).

-- M

On 10/30/2017 03:34 PM, Nicolas Cuervo wrote:
> Hello Richard,
> 
> I believe the best way (so far) would be to actually go to the
> repository that you want to rebuild and checkout to the different
> specific branch/tag and then trigger the rebuild with
> 
>     $ pybombs -p /your_prefix/ rebuild /uhd/
> 
> You can rebuild faster by adding the '-k' flag at the end of the
> command, so it won't delete the build directory and start over (depends
> on the number of API changes this might be a good or a bad idea).
>  
> If you are using GNURadio, don't forget to rebuild is as well so it
> picks up the right version. And, if you identify any issues with UHD,
> please also start a thread on the USRP-users mailing list in order to
> discuss them further.
> 
> Regards,
> - Nicolas 
> 
> 
> 
> On Mon, Oct 30, 2017 at 3:05 PM, Richard Mcallister  > wrote:
> 
> Hi all,
> 
> I think the question is all in the subject, but basically, I'm
> having trouble with using several USRPs. I think it may be an issue
> with UHD, or at least I need to verify it isn't. Does pybombs have a
> command to install older releases or specific branch tags from git?
> 
> Thanks,
> Rich McAllister
> 
> ___
> 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