GNU Radio Companion Flow Graph for Blade?

Follow our development of DSP and SDR tutorials

Moderator: robert.ghilduta

2011EE10487
Posts: 18
Joined: Tue Feb 25, 2014 6:39 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by 2011EE10487 » Sat Mar 15, 2014 8:37 am

Hi jynik,
I've solved the issue of cloning the latest git repo. But now when I'm building the osmocom block (using the wiki http://sdr.osmocom.org/trac/wiki/GrOsmoSDR) I could successfully complete the command cmake ../ but when I've given the command make, it gave the following error

/home/shubham/Documents/gr-osmosdr/lib/bladerf/bladerf_source_c.cc: In member function ‘virtual int bladerf_source_c::work(int, gr_vector_const_void_star&, gr_vector_void_star&)’:
/home/shubham/Documents/gr-osmosdr/lib/bladerf/bladerf_source_c.cc:163:65: error: ‘bladerf_sync_rx’ was not declared in this scope
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/bladerf/bladerf_source_c.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
make: *** [all] Error 2.

If you have any idea how to solve this problem then please help me out.

Thanks

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by jynik » Sat Mar 15, 2014 9:27 am

A new, easier to use interface for RX'ing and TX'ing samples has recently been added to libbladeRF, in v0.14.0.

gr-osmosdr master now includes an update to use that new interface. However, from the version number you posted earlier, I see that you're using a slightly dated libbladeRF version, which does not yet include this new interface.

So what you'll need to do is...
  • Put the latest software from the bladeRF git master. From the bladeRF repo directory, run:

    Code: Select all

    git pull master
  • rm your build/ directory, re-create it, and then run cmake ../ from inside that new build directory. This may be excessive, but I find that it rules out any doubt of properly reconfiguring things.
  • Rebuild and re-install the bladeRF software. When you run the CLI's version command, you should now see libbladeRF v0.14.0.
  • I'd rebuild gr-osmosdr, just to be thorough
  • Try running osmocom_fft -- you should now be up and running
In the near future, I'll be sending a patch to the gr-osmosdr maintainers to have the build complain about not seeing libbladeRF v0.14.0, rather than error out as you saw. Just need to get some time to do so :).

2011EE10487
Posts: 18
Joined: Tue Feb 25, 2014 6:39 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by 2011EE10487 » Sat Mar 15, 2014 12:30 pm

Thanks for your help. I could solve that issue after getting the new version of libbladerf. But after getting the new version of all(libbladerf, bladerf-cli an osmocom), when I tried to run osmocom_fft I got the following message.
linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.006.002-64-g92b0b7ab

gr-osmosdr v0.1.0-78-g1e8b45d0 (0.1.1git) gnuradio 3.7.2.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN e713...5981 FW v1.6.1 FPGA v0.0.2
LNA gain range: start 0 stop 6 step 3
VGA1 gain range: start 5 stop 30 step 1
VGA2 gain range: start 0 stop 30 step 3
Supported sample rates 160000-40000000 step 40000.
Using Volk machine: avx_64_mmx_orc
Set center frequency to 1000000000.0
python2: /home/shubham/bladeRF/host/libraries/libbladeRF/src/sync_worker.c:78: rx_callback: Assertion `b->status[samples_idx] == SYNC_BUFFER_IN_FLIGHT' failed.
Aborted (core dumped)
.
I tried creating my own flowgraph for spectru analyser in gnuradio and execute it but I got the same error in that too. So if you could please help in solving this out.

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by jynik » Sat Mar 15, 2014 1:08 pm

That looks like a bug...specifically, a callback is happening with the provided transfer not being in the expected state...hence the assertion failure.

This may have been introduce in commit 06776a5f. Could you help me verify that by checking out the previous commit, and re-running?

Code: Select all

$ git checkout 5f8bcae45a7ce376e1dc0d9e0faab0e2ade9a481
$ rm -rf build
$ mkdir build && cd build
$ cmake ../
$ make && sudo make install
$ bladeRF-cli -i
bladeRF> version

 ... Verify the git tag portion of the version numbers match up with the first digits in the above changeset you checked out.
I will continue to look into this further.

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by jynik » Sat Mar 15, 2014 4:48 pm

I pushed a band-aid of a fix to master for this, just so it isn't in a totally broken state while I further dig into some other issues. While looking at this, I see that the sync interface doesn't correctly handle timeouts in the underlying async threads. I've opened issue #229 to track progress on fixing this.

With that said, I believe you should be up and running again, once you pull the latest from master.

My apologies for the bumpy ride...hopefully you should have smooth sailing for a while. :)

2011EE10487
Posts: 18
Joined: Tue Feb 25, 2014 6:39 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by 2011EE10487 » Sun Mar 16, 2014 10:48 pm

Hi,
I've pulled the latest from master and the error is removed now. But after all this it seems that I'm still getting the discontinuites as the output of spectrum analyser that I got is same as before.

bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by bpadalino » Mon Mar 17, 2014 12:22 pm

Can you run the osmo FFT command with "--oscilloscope" at the end of it and show a movie or describe what the output looks like on the XY tab? This will give us time domain information. Looking at spectrum like that doesn't really give me a good understanding other than "Things are bad". Time domain will let me know if you are saturating (which is my guess) and by how much.

If you are saturating - lower your gains until you aren't. Things should appear much more sane at that point.

Brian

2011EE10487
Posts: 18
Joined: Tue Feb 25, 2014 6:39 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by 2011EE10487 » Tue Mar 18, 2014 1:29 am

Hi Brian,
I've run the osmo FFT with oscilloscope. Here is the link to the video of the output https://drive.google.com/file/d/0B5ZnEv ... sp=sharing. I hope this gives you the required time domain information.

Thanks

bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by bpadalino » Tue Mar 18, 2014 5:35 am

You should have been on the XY tab instead of the CH1 tab on the right hand side. That should show me the polar plot of what IQ looks like. From that view, it still looks pretty terrible, though. Something isn't right.

Do you have any input signal going into the device at all, or is it just open or terminated?

Brian

2011EE10487
Posts: 18
Joined: Tue Feb 25, 2014 6:39 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by 2011EE10487 » Tue Mar 18, 2014 6:34 am

Here is the link to video with XY mode https://drive.google.com/file/d/0B5ZnEv ... sp=sharing.
I haven't got any input signal on the device. I've an antenna on the RX port of the device an trying to get the spectrum of signals present in the air with bladeRF. I got a good spectrum with USRP board and was hoping to get a similar from the bladeRF but something isn't right. Further can you tell me what should be the relationship between the sample rate and bandwidth. Shouldn't sample rate >= 2*bandwidth (Nyquist Criteria).

bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: GNU Radio Companion Flow Graph for Blade?

Post by bpadalino » Tue Mar 18, 2014 6:59 pm

It looks like your I signal is just very erratic. Your Q signal seems fine tho. Also note that you should always turn off the Autorange option in those viewers. It's difficult to make sense of what you're actually seeing when it's jumping all around.

Your board may be malfunctioning but with no signal going in I am not sure what you're expecting to see other than just noise? Are you trying to transmit or receive?

The bandwidth is setting some internal low pass filters. The bandwidth should match to be around 1.25*(bandwidth of signal of interest) so the low pass corners don't encroach on your actual signal. Does that make sense?

Brian

yvesined
Posts: 5
Joined: Tue Mar 25, 2014 6:51 am
Location: Germany
Contact:

Re: GNU Radio Companion Flow Graph for Blade?

Post by yvesined » Fri Mar 28, 2014 3:13 am

wx5cw wrote:Here is the setup I have that currently works for the bladerf in gnuradio.
However make sure to load the setup.txt file for the inital configuration of the sytem via bladerf-cli then exit that and then load the gnuradio-companion and lauch the grc. Note: you might have to chmod 757 /dev/bladerf to get the grc to load and connect to the bladeRF. I will be posting a detailed walk though soon to help others get up and running with gnuradio.
bladeconfig.png
gnuradio-bladerf.png
Thank you! This worked fine for me!!! :geek: :D

poi
Posts: 4
Joined: Mon Mar 23, 2015 5:16 am

Re: GNU Radio Companion Flow Graph for Blade?

Post by poi » Thu Apr 09, 2015 4:40 am

2011EE10487 wrote:Here is the link to video with XY mode https://drive.google.com/file/d/0B5ZnEv ... sp=sharing.
I haven't got any input signal on the device. I've an antenna on the RX port of the device an trying to get the spectrum of signals present in the air with bladeRF. I got a good spectrum with USRP board and was hoping to get a similar from the bladeRF but something isn't right. Further can you tell me what should be the relationship between the sample rate and bandwidth. Shouldn't sample rate >= 2*bandwidth (Nyquist Criteria).
Hi 2011EE10487,

I'm trying to get spectrum of signals present in the air with bladeRF too. However, I don't have USRP board to compare the spectrum with bladeRF. The spectrum that I get is a noisy spectrum. I'm trying to remove noise with filtering but I couldn't obtain satisfying results.

BTW the aim is to obtain center frequency of a signal detected in the air. I'll determine the frequency then, it will be scanned in LTE-Cell-Scanner. I've tried to use peak detector to obtain, however it is useless as far as I can see.

Is your work still in progress?

Thanks

Post Reply