pothosware / SoapyBladeRF

Soapy SDR plugin for the Blade RF
https://github.com/pothosware/SoapyBladeRF/wiki
23 stars 19 forks source link

SoapySDR sink BladeRF crashes #12

Closed BogdanDIA closed 5 years ago

BogdanDIA commented 6 years ago

Ubuntu 16.04.3, kernel 4.13.0-32-generic Pothos and all Soapy modules installed from git.

Running a simple SoapySDR source and a histogram gives the following error. It continues cycling through this error even the flow is not started.

If I choose an RTLSDR as a source it just works fine.

I am using bladerf with the following FW and FPGA bitstream versions:

bladeRF> version

bladeRF-cli version: 1.5.0-git-6116d09-dirty libbladeRF version: 1.8.0-git-6116d09-dirty

Firmware version: 2.0.0 FPGA version: 0.6.0

2018-01-29 00:37:27 PothosFlow.EnvironmentEval: zone[]: I/O error: RemoteProxyEnvironment::recvDatagram(): recvDatagram(): stream end - Remote environment crashed 2018-01-29 00:37:28 SoapySDR: bladerf_open_with_devinfo() 2018-01-29 00:37:28 SoapySDR: bladerf_get_serial() = 9eeeeecf610343cba827a9889dcc9c23 2018-01-29 00:37:28 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 00:37:28 SoapySDR: setSampleRate(0, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 00:37:28 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 00:37:28 PothosFlow.EnvironmentEval: zone[]: I/O error: RemoteProxyEnvironment::transact(): connection inactive - Remote environment crashed

guruofquality commented 6 years ago

Looks like the recent gain mode stuff causes the error print to bomb out. The error happens on older devices, so it probably wasnt seen otherwise. Not sure I like the call erroring out though, older devices where technically manual mode, so that should be fine. Anyway, I think you should install SoapyBladeRF from source, and removing its apt package. Everything else can stay installed as is until the repo gets updated.

BogdanDIA commented 6 years ago

HI Josh, thanks

I am not sure what you mean by older devices. Is it the HW, the libbladerf or the FPGA/firmware? I might update those SW as I see new versions on the bladerf site.

I pulled your changes, seems that even though the CMake finds the new bladerf_set_gain API it still cannot use it.

-- Checking for bladerf_set_gain_mode API... -- Reading /home/bogdan/projects/gnuradio/include/libbladeRF.h... -- libbladeRF supports the bladerf_set_gain_mode API -- Configuring done -- Generating done

2018-01-29 11:28:25 SoapySDR: bladerf_set_gain_mode(manual) returned -8 - Operation not supported 2018-01-29 11:28:25 SoapyBlock: call setGainMode threw: Exception: setGainMode() -8 - Operation not supported.

commenting add_definitions(-DHAS_BLADERF_GAIN_MODE) in CMakeLists.txt allows me to get going.

I will update libbladerf and firmware/fpga bitsream to see if anything changes.

BogdanDIA commented 6 years ago

Quick update

I installed latest bladerf and FPGA (the FX3 firmware seems alread the latest) and I get the same result:

bladeRF> version

bladeRF-cli version: 1.5.1-git-8b420eb libbladeRF version: 1.9.0-git-8b420eb

Firmware version: 2.0.0 FPGA version: 0.7.1

2018-01-29 12:27:00 SoapySDR: bladerf_open_with_devinfo() 2018-01-29 12:27:00 SoapySDR: bladerf_get_serial() = 9eeeeecf610343cba827a9889dcc9c23 2018-01-29 12:27:00 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 12:27:00 SoapySDR: setSampleRate(0, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 12:27:00 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 12:27:00 SoapySDR: bladerf_set_gain_mode(manual) returned -8 - Operation not supported

guruofquality commented 6 years ago

2018-01-29 12:27:00 SoapySDR: bladerf_set_gain_mode(manual) returned -8 - Operation not supported

But the crash has fixed right? Otherwise that print should be harmless.

Someone added support for the gain mode stuff, but I don't know what to do about the call failing. It seems to do a compatibility check for the feature and bomb out otherwise, I dont think it should do this for manual mode, so I opened a bug: https://github.com/Nuand/bladeRF/issues/542

I assumed the check was for older reversions of the bladerf, but I really dont know. My blade gives me the same error message. But I assume it worked on the person's that added the gain mode calls.

BogdanDIA commented 6 years ago

The crash as reported initially seems to be gone with the changes you have made. However, the flow cannot run due to the same issue so still not good unless undefining the HAS_BLADERF_GAIN_MODE. See below the log:

2018-01-29 18:04:47 PothosFlow.TopologyEval: Failed to commit: Framework Topology Connect Error: Pothos::Topology::commit(): Framework Topology Connect Error: SoapySDRSource0.activate(): Exception: setGainMode() -8 - Operation not supported

2018-01-29 18:04:47 SoapySDR: bladerf_close() 2018-01-29 18:04:47 SoapySDR: bladerf_open_with_devinfo() 2018-01-29 18:04:47 SoapySDR: bladerf_get_serial() = 9eeeeecf610343cba827a9889dcc9c23 2018-01-29 18:04:47 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 18:04:47 SoapySDR: setSampleRate(0, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 18:04:47 SoapySDR: setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz 2018-01-29 18:04:47 SoapySDR: bladerf_set_gain_mode(manual) returned -8 - Operation not supported 2018-01-29 18:04:47 SoapyBlock: call setGainMode threw: Exception: setGainMode() -8 - Operation not supported

My HW version is the latest so I assume it is not related to the HW. I know from bladeRF forum that there were some changes in bladeRF FPGA and libbladeRF for adding AGC. But as I assumed this was already integrated in the new libbladeRF v1.9 and the FPGA 0.7.x.

Did you try to cal the failing function within a separate app, e.g. not from Pothos?

guruofquality commented 6 years ago

I see what you mean, it is throwing after-all: So I changed the call to ignore errors when setting manual mode. It shouldnt print or throw anything unless the mode is changed to automatic. As far as what version of bladerf supports automatic mode, I have no idea, have to ask nuand about that.

BogdanDIA commented 6 years ago

That should work as a workaround.