Mac 10.9.5 Challenges gnuradio and gr-osmosdr and gqrx

[djdonovan]

So the latest issue when trying to run the osmocom fft app

Code: Select all

$ osmocom_fft -a bladerf -v -f 900e6 -s 1e6
Mac OS; Clang version 6.0 (clang-600.0.57); Boost_105800; UHD_003.009.001-0-unknown

gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace soapy 
Opening nuand bladeRF with device identifier string: ""

FATAL: [bladeRF source] Failed to open bladeRF device 

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

Source has no sample rates (wrong device arguments?).

I can't run my brew installed version of gqrx now which is strange. But if/when I get that back up and running, I will try those values.

Couple other questions. Should I not have the BladeRF running in -i mode? Also it would be helpful if there was a way to debug connections to the board though the cli just to see if there are communications to the board from other applications.

[djdonovan]

So after reinstalling osmosdr and gqrx and using your parameters I am getting some action!

Still getting a Python error when trying to load osmocom_fft -a bladerf -v But I am making progress! Thanks again

gqrx.jpg

[djdonovan]

Another thing to note, don't run the bladerf-cli while trying to start gqrx. Obvious in hindsite, but good to be aware of:)

[djdonovan]

Couple more questions. To hear frequencies in the FM radio range, do I need the LF/MF/HF/VHF transporter?

Also I am tuned to 476.43750, shouldn't I be picking something up on Policeband? I'm on normal, narrow fm,

[djdonovan]

Another whoops moment on my end, I didn't have my RP-SMA to SMA plug adaptors in.

Getting some better reception now

[jynik]

OpenBTS here I come!

Just to save you some debugging time later... you'll want to use FPGA version <= v0.1.2 with OpenBTS and YateBTS.

I still have to spend some time figuring out what changes need to be made to the transceiver code to work with our newer FPGA images. In the FPGA >= v0.2.x we separated some sample counters, which broke some of the transceiver's assumptions about the order in which you could perform "set sample rate" and "enable timestamps" operations.

[djdonovan]

Good to know and thanks again for your help!

I'm already eyeing the transverter board:)

[math]

Fatal Python error: PyThreadState_Get: no current thread

This error is due to mixed versions of python - like OSX's and Homebrew's.

To clear up conflicts, you can specify which python to use using some cmake variables:

Code: Select all

cmake .. -DPYTHON_LIBRARY=$(brew --prefix python)/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib -DPYTHON_INCLUDE_DIR=$(brew --prefix python)/Frameworks/Python.framework/Versions/2.7/include/python2.7

The homebrew recipies I have seen usually do this, but it's a common thing to have to manually do when manually compiling gnuradio components

Mathieu