Soapy SDR plugin for the Blade RF
Home Page: https://github.com/pothosware/SoapyBladeRF/wiki
I've try to use QspectrumAnalyzer using bladeRF x40 and XB200 daughter board (transverter+filters) but it is not recognized and I cannot tune to lower than 273.5MHz as gqrx can. I've try different device strings according with the help message but i cannot guess the correct format.
SoapyBladeRF correctly detects bladerf v2 board but cannot configure it correctly, as:
the bandwidths are hardcoded in bladeRF_SoapySDR::listBandwidths at https://github.com/pothosware/SoapyBladeRF/blob/master/bladeRF_Settings.cpp#L748 and corresponds to the blade v1. But that may be informative only and without real impact. I don't know which values should be used for the v2.
Similarly, SoapyBladeRF uses constants defined in bladeRF1.h which corresponds to the device version 1. Ex:
BLADERF_BANDWIDTH_MAX is 28MHz but should be 56MHz.
BLADERF_FREQUENCY_MAX is 3,8GHz but should be 6GHz.
The transmit time is recorded in the burst now (aka without a timestamp). The purpose is to store it for the end of burst time to simulate waiting for the end of burst acknowledgement. The problem being that this imposes an extra readback wait to read the tx time, a wait that we otherwise dont need in most cases. Consider testing without the time read and changing the implementation.
//pack the metadata
if (not _inTxBurst)
{
md.flags |= BLADERF_META_FLAG_TX_BURST_START;
if ((flags & SOAPY_SDR_HAS_TIME) != 0)
{
md.timestamp = _timeNsToTxTicks(timeNs);
}
else
{
md.flags |= BLADERF_META_FLAG_TX_NOW;
bladerf_get_timestamp(_dev, BLADERF_MODULE_TX, &md.timestamp);
}
_txNextTicks = md.timestamp;
}
Hello folks,
I have an interest in using the Soapy python bindings with one of the new BladeRF Micro A4 boards. Unfortunately, I have run into problems trying to build SoapyBladeRF against versions of libbladerf that support the new board.
I have created 2 docker containers to help folks replicate my issue. They build the software in an Ubuntu 18.04 environment:
https://gist.github.com/sparklespdx/da169dc2614cf8d5f88751cabd9bc598
You can build and run the containers with something like this:
sudo docker build -f Dockerfile.bladeRF_git_2017.12-rc1 -t soapybladerf-build-test-case-1 . && \
sudo docker run -it --rm soapybladerf-build-test-case-1
The first container builds BladeRF release 2017.12-rc1 and Soapy, and then SoapyBladeRF. This is the version of BladeRF from the PPAs. This build works, but none of the software recognizes the A4 board. I made this test case mainly to validate that my build environment works.
The second container builds BladeRF and Soapy from the current master branch successfully. It tries to build SoapyBladeRF but the build fails. See the output below.
I am not sure if this is an easy or hard problem to solve; I am unfamiliar with the code base. I am going to at least make an attempt to figure out what's wrong and make a PR if I get somewhere. Any help or advice would be much appreciated.
Build failure output:
Step 18/20 : RUN cmake ../ && make && make install && ldconfig
---> Running in a260660b7386
-- The CXX compiler identification is GNU 7.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'libbladeRF'
-- Found libbladeRF, version 2.0.0-git-074f7373-dirty
-- Found libbladeRF: /usr/local/include, /usr/local/lib/libbladeRF.so
-- LIBBLADERF_INCLUDE_DIRS - /usr/local/include
-- LIBBLADERF_LIBRARIES - /usr/local/lib/libbladeRF.so
-- Checking for bladerf_set_gain_mode API...
-- Reading /usr/local/include/libbladeRF.h...
-- libbladeRF supports the bladerf_set_gain_mode API
-- Performing Test HAS_STD_CXX11
-- Performing Test HAS_STD_CXX11 - Success
-- Found Git: /usr/bin/git (found version "2.17.1")
-- Module bladeRFSupport configured with version: 0.3.5-4fa4566
-- Configuring done
-- Generating done
-- Build files have been written to: /work/SoapyBladeRF/build
Scanning dependencies of target bladeRFSupport
[ 20%] Building CXX object CMakeFiles/bladeRFSupport.dir/bladeRF_Registation.cpp.o
[ 40%] Building CXX object CMakeFiles/bladeRFSupport.dir/bladeRF_Settings.cpp.o
/work/SoapyBladeRF/bladeRF_Settings.cpp: In member function 'virtual double bladeRF_SoapySDR::getFrequency(int, size_t, const string&) const':
/work/SoapyBladeRF/bladeRF_Settings.cpp:411:69: error: cannot convert 'unsigned int*' to 'bladerf_frequency* {aka long unsigned int*}' for argument '3' to 'int bladerf_get_frequency(bladerf*, bladerf_channel, bladerf_frequency*)'
int ret = bladerf_get_frequency(_dev, _dir2mod(direction), &freq);
^
In file included from /work/SoapyBladeRF/bladeRF_SoapySDR.hpp:26:0,
from /work/SoapyBladeRF/bladeRF_Settings.cpp:22:
/work/SoapyBladeRF/bladeRF_Settings.cpp: In member function 'virtual long long int bladeRF_SoapySDR::getHardwareTime(const string&) const':
/work/SoapyBladeRF/bladeRF_Settings.cpp:570:49: error: invalid conversion from 'bladerf_channel {aka int}' to 'bladerf_direction' [-fpermissive]
const int ret = bladerf_get_timestamp(_dev, BLADERF_MODULE_RX, &ticksNow);
^
/usr/local/include/libbladeRF.h:2345:15: note: initializing argument 2 of 'int bladerf_get_timestamp(bladerf*, bladerf_direction, bladerf_timestamp*)'
int CALL_CONV bladerf_get_timestamp(struct bladerf *dev,
^~~~~~~~~~~~~~~~~~~~~
/work/SoapyBladeRF/bladeRF_Settings.cpp: In member function 'virtual void bladeRF_SoapySDR::writeSetting(const string&, const string&)':
/work/SoapyBladeRF/bladeRF_Settings.cpp:823:50: error: 'bladerf_module' is not a class, namespace, or enumeration
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_BYPASS);
^~~~~~~~~~~~~~
In file included from /work/SoapyBladeRF/bladeRF_SoapySDR.hpp:26:0,
from /work/SoapyBladeRF/bladeRF_Settings.cpp:22:
/work/SoapyBladeRF/bladeRF_Settings.cpp:823:66: error: expected unqualified-id before '(' token
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_BYPASS);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:823:66: error: expected primary-expression before ')' token
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_BYPASS);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:889:58: error: 'bladerf_module' is not a class, namespace, or enumeration
int ret = bladerf_xb200_set_filterbank(_dev, bladerf_module::BLADERF_MODULE_RX, filter);
^~~~~~~~~~~~~~
In file included from /work/SoapyBladeRF/bladeRF_SoapySDR.hpp:26:0,
from /work/SoapyBladeRF/bladeRF_Settings.cpp:22:
/work/SoapyBladeRF/bladeRF_Settings.cpp:889:74: error: expected unqualified-id before '(' token
int ret = bladerf_xb200_set_filterbank(_dev, bladerf_module::BLADERF_MODULE_RX, filter);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:889:74: error: expected primary-expression before ')' token
int ret = bladerf_xb200_set_filterbank(_dev, bladerf_module::BLADERF_MODULE_RX, filter);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:898:42: error: 'bladerf_module' is not a class, namespace, or enumeration
bladerf_xb200_get_path(_dev, bladerf_module::BLADERF_MODULE_RX, &_bladerf_xb200_path);
^~~~~~~~~~~~~~
In file included from /work/SoapyBladeRF/bladeRF_SoapySDR.hpp:26:0,
from /work/SoapyBladeRF/bladeRF_Settings.cpp:22:
/work/SoapyBladeRF/bladeRF_Settings.cpp:898:58: error: expected unqualified-id before '(' token
bladerf_xb200_get_path(_dev, bladerf_module::BLADERF_MODULE_RX, &_bladerf_xb200_path);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:898:58: error: expected primary-expression before ')' token
bladerf_xb200_get_path(_dev, bladerf_module::BLADERF_MODULE_RX, &_bladerf_xb200_path);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:903:46: error: 'bladerf_module' is not a class, namespace, or enumeration
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_MIX);
^~~~~~~~~~~~~~
In file included from /work/SoapyBladeRF/bladeRF_SoapySDR.hpp:26:0,
from /work/SoapyBladeRF/bladeRF_Settings.cpp:22:
/work/SoapyBladeRF/bladeRF_Settings.cpp:903:62: error: expected unqualified-id before '(' token
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_MIX);
^
/work/SoapyBladeRF/bladeRF_Settings.cpp:903:62: error: expected primary-expression before ')' token
bladerf_xb200_set_path(_dev, bladerf_module::BLADERF_MODULE_RX, bladerf_xb200_path::BLADERF_XB200_MIX);
^
make[2]: *** [CMakeFiles/bladeRFSupport.dir/bladeRF_Settings.cpp.o] Error 1
CMakeFiles/bladeRFSupport.dir/build.make:86: recipe for target 'CMakeFiles/bladeRFSupport.dir/bladeRF_Settings.cpp.o' failed
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/bladeRFSupport.dir/all' failed
make[1]: *** [CMakeFiles/bladeRFSupport.dir/all] Error 2
make: *** [all] Error 2
Makefile:129: recipe for target 'all' failed
The command '/bin/sh -c cmake ../ && make && make install && ldconfig' returned a non-zero code: 2
Calling bladeRF_SoapySDR::setFrequency() with a "timestamp" keyword argument currently requires the timestamp to be in units of "bladeRF ticks". The rest of SoapySDR uses units of nanoseconds. For consistency, I propose that the "timestamp" keyword argument should also be in nanoseconds. Timestamps returned by bladeRF_SoapySDR::readStream() are already in nanoseconds and having consistent units will allow timestamps from received buffers to be directly used when scheduling frequency changes.
Philosophically, an argument can also be made that Soapy should be hiding backend specific details from the user, so BladeRF specific units should be hidden.
The necessary change to the source is:
diff --git a/bladeRF_Settings.cpp b/bladeRF_Settings.cpp
index 3d06548..4f95ef1 100644
--- a/bladeRF_Settings.cpp
+++ b/bladeRF_Settings.cpp
@@ -490,6 +490,9 @@ void bladeRF_SoapySDR::setFrequency(const int direction, const size_t channel, c
auto value = args.find("timestamp");
long long timestamp = value == args.end() ? 0 : std::stoll(value->second);
+ if(timestamp != 0) {
+ timestamp = _timeNsToRxTicks(timestamp);
+ }
retune(direction, channel, timestamp, quickTuneIter->second);
return;
Checking against 0 is a convenience, in that allows "BLADERF_RETUNE_NOW" to still function. I'm not aware that SoapySDR has an equivalent function that BLADERF_RETUNE_NOW can be mapped to in order to hide this bladeRF specifity.
A GR user says the "verbose" setting is very useful for debugging. Add this setting to bladeRF_Settings.cpp getSettingInfo(), readSetting(), writeSetting(). This is a passthru setting, so no logic required.
How should the functions in libbladeRF: Device loading and programming be made available from SoapyBladeRF? Especially interested in the device reset functionality.
It can of course be something on my end, but while trying try to build the latest source with latest comment I get the following,
/opt/build/SoapyBladeRF/bladeRF_Streaming.cpp:320:10: error: ‘memset’ is not a member of ‘std’
320 | std::memset(&md, 0, sizeof(md));
| ^~~~~~
/opt/build/SoapyBladeRF/bladeRF_Streaming.cpp: In member function ‘virtual int bladeRF_SoapySDR::writeStream(SoapySDR::Stream*, const void* const*, size_t, int&, long long int, long int)’:
/opt/build/SoapyBladeRF/bladeRF_Streaming.cpp:420:10: error: ‘memset’ is not a member of ‘std’
420 | std::memset(&md, 0, sizeof(md));
| ^~~~~~
make[2]: *** [CMakeFiles/bladeRFSupport.dir/build.make:89: CMakeFiles/bladeRFSupport.dir/bladeRF_Streaming.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:104: CMakeFiles/bladeRFSupport.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
Hello
I try to test BladeRF under Pothos (built from source) and I get strange errors when using the bladerf soapy sink
[22:22:54.214000] SoapySDR: bladerf_open_with_devinfo()
[22:22:54.394000] SoapySDR: bladerf_get_serial() = 1d62a870f59e65fdd231ced37787b03a
[22:22:54.401000] SoapySDR: setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz
[22:22:54.409000] SoapySDR: setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz
[22:22:54.417000] SoapySDR: setSampleRate(Rx, 0, 4.800000 MHz), actual = 4.800000 MHz
[22:22:54.421000] ::1: [INFO @ fpga_common/src/lms.c:2258] Clamping frequency to 237500000Hz
[22:23:04.972000] ::1: [INFO @ fpga_common/src/lms.c:2258] Clamping frequency to 237500000Hz
[22:23:05.017000] : 0
[22:23:05.248000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.249000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.250000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.348000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.349000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.350000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.447000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.448000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.449000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
[22:23:05.547000] ::1: [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
.....
the flowgraph is stuck and does not do anything. In gnuradio-companion the BladeRF source behaves similarly but curiously when gr-osmosdr source everything works nicely.
If somebody can help I'd greatly appreciate because I am completely stuck with this.
best regards
aK
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
Hi Josh,
I'd like to access bladerf_get_quick_tune and bladerf_schedule_retune . Do you think we could update the SoapySDR API to handle that? Or is there an easier way to access those methods?
I'm currently modifying the SoapySDR and SoapyBladeRF dlls, but I would rather not have to maintain my own version. Also that would impact all types of device and I'd need to rebuild all other dlls.
Calls to implement:
CMakeList version update:
find_package(SoapySDR "0.4.0" NO_MODULE)Related issue:
I’ve been asking around about this as I test the latest bladerf/libbladerf from nuands githib. I made a short video to show what’s happening. Basically when I use the libbladerf 2.4 I lose gain control, it’s either AGC on or what appears to be max gain as shown in this video. Is anyone else experiencing this? This is with soapy or osmosdr.
Just noticed this will building from latest source.
/opt/build/SoapyBladeRF/bladeRF_Streaming.cpp: In member function ‘virtual int bladeRF_SoapySDR::readStream(SoapySDR::Stream*, void* const*, size_t, int&, long long int&, long int)’:
/opt/build/SoapyBladeRF/bladeRF_Streaming.cpp:395:71: error: ‘SOAPY_SDR_USER_FLAG0’ was not declared in this scope; did you mean ‘SOAPY_SDR_OVERFLOW’?
395 | if ((md.status & BLADERF_META_FLAG_RX_HW_MINIEXP1) != 0) flags |= SOAPY_SDR_USER_FLAG0;
| ^~~~~~~~~~~~~~~~~~~~
| SOAPY_SDR_OVERFLOW
The bladerf tx stream cant recover after being disabled. It just returns error codes. Investigate...
Currently time counters are reset strategically via GPIO to maintain a tx/rx time relationship. We should be able to do this by performing a disable/enable module sequence instead.
//reset the counters with GPIO and stash the offset
//this is the same as setting the time because
//we maintain the offset math within the driver
int ret = 0;
uint32_t original = 0;
ret |= bladerf_config_gpio_read(_dev, &original);
ret |= bladerf_config_gpio_write(_dev, original & ~(BLADERF_GPIO_TIMESTAMP));
ret |= bladerf_config_gpio_write(_dev, original | BLADERF_GPIO_TIMESTAMP);
Hi. I have an up to date Arch Linux, an Bladerf 2.0 micro and osmosdr. When I use osmocom_fft with the native bladerf driver, everything works fine. When I use it with the soapy driver, the graph jitters and I get overflows.
osmocom_fft -a bladerf -g 50 -s 4e6 -f 433e6 # works great
osmocom_fft -a soapy -g 50 -s 4e6 -f 433e6 # makes issues
Video of the issue: http://tests.icaria.de/bladerf-soapy.mkv
Does anybody have the same issues? Any idea what might cause this?
There may be old samples in the internal structures. The stream is not used until activation, this will clear anything streamed in beforehand. Good improvement for reading bursts of samples with the API.
Hi,
I'm not sure this is Soapy related or not. I have a program where I set the gain and then print it, to make sure it was set properly.
It works with a LimeSDR but with the bladeRF 2 the SoapySDRDevice_setGain works (ie it returns 0) but then the SoapySDRDevice_getGain always returns 60, no matter what I asked. I can even ask for a gain of -500 or +500, I won't get any error, while I would expect a Provided parameter is out of range, just like with setFrequency if I ask for 10GHz.
On libbladerf 2021.10 with a bladeRF Micro 2.0 xA4 the following Gist will not correctly receive samples:
https://gist.github.com/AlexFWulff/9c821eb999e9da86404a163fb35b2656
I consistently get errors from libbladerf and cannot receive samples properly. I downgraded libbladerf to 2019.07 (and also downgraded the firmware of my SDR and FPGA), and now this code works with no issues. It appears that somewhere between these two releases something was introduced that breaks 2-channel reception with SoapySDR. On either release I can receive from just one channel with no issues.
When trying to tune to frequencies below 300Mhz using BladeRF 1.0 with the XB-200 extension board enabled, the following error message is shown usuallly:
[ERROR @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:2398] Consider supplying the quick_tune parameter to bladerf_schedule_retune() when the XB-200 is enabled.
Would it be possible to automatically supply this quick_tune parameter in SoapySDR, so that the error disappears?
Referencing this issue, SoapyBladeRF should support the clock source API and trigger source API so it can be used to sync multiple bladerfs -- and be used in SoapyMultiSDR.
setHardwareTime(time, "TRIGGER") API to initiate the trigger, automatically sync'ing the time offsets. This will work a lot like the existing BLADERF_GPIO_TIMESTAMP, but for multiple boards. Internally, the boards must do a receive to get the latest timestamp and adjust the offset. This process will have to re-do itself automatically upon sample rates changes (also like the current BLADERF_GPIO_TIMESTAMP method).I have 2 Blades v2. When using Soapy (tested on Windows), I must load them in a specific order, else I am not able to connect to the 2nd one: [ERROR] bladerf_open_with_devinfo() returned -7 - No device(s) available
It seems that the order is the reverse order of what is displayed when listing all devices. So if SoapySDRDevice_enumerate displays device A then device B, I have to load first device B then device A.
This issue doesn't seem to happen when accessing libbladerf directly.
In 2 terminals, run bladerf-cli -d "*:serial=A" -i and bladerf-cli -d "*:serial=B" -i.
No matter if I connect to A or B first, in both cases it works.
If I connect to A before B, I do get [WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:530] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions. when connecting to B, but I can still use both devices.
I run a simple program that loads both Blades using SoapySDRDevice_make with the driver and serial number.
If I connect to B before A (correct order), I get [WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:345] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions, or because the device is already open. when connecting to A, but I can still use both. Note that with bladerf-cli I don't get any warning when connecting in that order.
When loading A then B (incorrect order), I get the following when connecting to B:
[WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:345] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions, or because the device is already open.
[INFO] bladerf_open_with_devinfo()
[WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:530] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions.
[ERROR] bladerf_open_with_devinfo() returned -7 - No device(s) available
If I try to enumerate through the devices at this point, I get:
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106700; UHD_3.13.1.0-3-g711ec8a3
[WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:345] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions, or because the device is already open.
backend=libusb, device=0x02:0x04, driver=bladerf, instance=0, label=BladeRF #0 [ANY], serial=ANY
backend=libusb, device=0x02:0x03, driver=bladerf, instance=1, label=BladeRF #1 [B], serial=B
The serial number for device B is properly shown, but for device A I just see ANY.
Feature set can now be enabled in a Nuand modified gr-osmosdr. Would it be possible to adopt over to Soapy?
https://github.com/Nuand/gr-osmosdr
Last few commits or so show the changes
https://github.com/Nuand/gr-osmosdr/commits/master
Enabling such features would then allow for the 122Msps setting to be used within CubicSDR, SigDigger and other Soapy backed programs. Basically changing sample format to 8bit and setting the oversample is allowing me to achieve the result in GQRX w/ Gr-osmosdr.
The available package on Ubuntu is 0.4.1, which dates from Jan 2019.
Could a new tag be added? Also should the maintainers be contacted to update the package?
Hi,
The following commit Nuand/bladeRF@e1d8c61 introduces the BLADERF_META_FLAG_RX_HW_MINIEXP1 and BLADERF_META_FLAG_RX_HW_MINIEXP2 flags (as well as BLADERF_META_FLAG_RX_HW_UNDERFLOW). They are added to the status when receiving samples if the corresponding mini expansion IO pin 1 or 2 is asserted.
Those flags are currently not surfaced by the bladeRF_SoapySDR::readStream method. I'm not sure how to update the method as it's probably quite specific to the bladeRF 2.0.
So its not clear as to how the API is being used wrong, but for very low rates, every other call is reporting an overflow
SoapySDRUtil --rate=1e6 --direction=RX --channels="0,1"
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 1016
[NOTICE] md.timestamp = 0x3
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 508
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x1234432112344321
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x3fb
[NOTICE] md.status = 0x1
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x1234432112344321
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x5f7
[NOTICE] md.status = 0x1
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x1234432112344321
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x7f3
[NOTICE] md.status = 0x1
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x1234432112344321
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x9ef
[NOTICE] md.status = 0x1
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0x1234432112344321
[NOTICE] md.status = 0x30001
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
[NOTICE] readStream called with samples per channel = 4096
[NOTICE] calling bladerf_sync_rx(num_samples = 8192)
[NOTICE] md.actual_count = 508
[NOTICE] md.timestamp = 0xbeb
[NOTICE] md.status = 0x1
[NOTICE] numElems read per channel = 254
[NOTICE] BLADERF_META_STATUS_OVERRUN
There are new masked gpio calls, implement the equivalent Soapy calls when the API is released
I modified a simple SoapSDR example to read from two channels from my bladeRF 2.0 micro xA5.
https://github.com/righthalfplane/rfspace/blob/master/simpleReceive3.cpp
It reads successfully reads 254 samples and then gets a SOAPY_SDR_OVERFLOW (-4) error - over and over again
0ret=254, flags=4, timeNs=222220000614250 rec 4096
ret=-4, flags=4, timeNs=222220000741250 rec 3842
0ret=254, flags=4, timeNs=222220000741750 rec 3846
ret=-4, flags=4, timeNs=222220000868750 rec 3592
....
Then it starts erroring in a different fashion -
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:337] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms
ret=-1, flags=0, timeNs=0 rec 4096
[ERROR @ host/libraries/libbladeRF/src/backend/usb/libusb.c:1090] Transfer timed out for buffer 0x7fd8d7821800
ret=-1, flags=0, timeNs=0 rec 4097
....
If I read one channel, every thing works OK.
if I read 254 samples, it goes with out errors for a short time and then it gets the "wait_for_buffer" error again.
I've tried every possible thing I can find, but I cannot get the Bias-T for the Soapy source or sink blocks in GNURadio for the BladeRF 2.0 xA4 to work. Everything else is fine. I am using GR 3.93 and Soapy 0.7x (latest).
I don't know if it's just not supported or what the deal is. The Bias-T does work with the gr-osmocom sink/source, etc. I can also turn it on via the bladeRF-cli.
I've tried all these as arguments, both in quotes and without:
bias=1
biastee=1
biastee=TX
biastee=TX1
biastee=enable
biastee=true
Anyone have any suggesti9ons, or am I going to have to modify source someplace to make it work?
For review and inclusion: http://pastebin.com/AYHdpZVu
I'm using a 10 MHz external reference and need the bladeRF to enable the PLL so it considers it. Given setClockSource does nothing by default and I didn't find any option to enable the PLL, I had to code a workaround to get the native handle to the bladeRF device and make the library call myself, but I guess it shouldn't be too hard to implement. The question would be where is the most appropriate place to do so.
bladerf_set_pll_enable(dev, true);
bladerf_set_pll_refclk(dev, 10000000); // already this value by defaultI know in SoapyUHD they use a call to setClockSource("external"), but for the bladeRF you also need to be able to specify the clock frequency and the SoapySDR interface does not provide that. I'm thinking the best place would probably be in the SoapySDR Settings API, or maybe even a mix of both.
Hi all,
We are trying to control BladeRF by UHD through SoapyUHD and SoapyBladeRF plugins. When running the commands SoapySDRUtil --probe="driver=bladerf" and uhd_find_devices, both of them work well and we can detect the BladeRF. But when we try to run BladeRF, we get the following error:
[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1 ms
We tried to downgrade the BladeRF's FPGA image and FX3 firmware to v0.11.0 (2019-07-31) and v2.3.2 ( 2018-12-16) respectively, but this doesn't solve the problem.
Does anyone have a solution for this problem? Thanks for your help!
Best,
Haoxin
Hi .
f4exb/sdrangel#248
Hello,
I use Bladerf 2.0 A4 with soapysdr and gr-soapy.
It want to set 2 different frequencies on 2 input channels, but it seems that
both channels are set to same frequency.
Is it possible?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.