Closed BogdanDIA closed 5 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.
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.
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
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.
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?
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.
That should work as a workaround.
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