Troubleshooting
This page provides some quick tips on troubleshooting problems.
If you run across an issue not listed here and find a solution, please feel free to post it here!
By default, builds use -Werror or /WX to treat warnings as errors, with the intent of forcing developers to address any warnings.
Occasionally, we've seen different compiler versions throw errors that were not seen on developers' machines, breaking master for users.
Master is intended to always build. If you suspect a build is broken due to a warning being treated as an error, please report it via IRC or the issue tracker, and run the following from your build directory as a temporary workaround:
cmake -DTREAT_WARNINGS_AS_ERRORS=No ../If the libusb is reported to not be found, it may be the case that pkgconfig was not able to locate libusb. (This will certainly be the case for Windows.) Check your PKG_CONFIG_PATH variable, and ensure that libusb is installed to a location in your system's library search path.
Users that are in a *nix environment and have installed libusb via a package manager, should double check that both the library and development packages for libusb-1.0 (sometimes packaged as libusbx-1.0) are installed.
Windows users should use the LIBUSB_PATH CMake variable to specify the location of a the libusb(x) binary distribution.
If you receive a message similar to the following when running CMake, you'll need to obtain a more recent version of libusb:
A newer libusb version is needed by libbladeRF. libusb >= v1.0.10 is required to build. libusb >= v1.0.16 is recommended.
For some distributions, it may be possible to simply pull in a package from an upstream source for a later distro version. However, this is not always possible, as more recent versions of libusb packages may require a newer libc or libudev.
For example, Ubuntu 12.04 users will find that libusb-1.0.9 is provided in the repositories. In this case, it is recommended to upgrade to a more recent distribution (a 3.8+ kernel is also highly desirable). If this is not possible, these users may want to try obtaining a libusb package from the 12.10 repositories (this has not been tested), or attempt to build a slightly newer version from source.
Note: This build issue has been resolved as of commit 95a6c1d0e098. If you see this issue, ensure that you've checkout out the lastest codebase, remove and recreate your build directory, and re-run CMake.
If you see an error about being unable to find the libusb_get_version function, the version of libusb installed on your machine needs to be updated. Updating to >= 1.0.10 for Linux is required, but >= 1.0.16 is highly suggested.
There is an open action item to change the CMake configuration to detect and complain about this, prior to compilation.
Please take a look at Building libtecla and note the sed script required to remove the link to libgcc.a in the Makefile. This is due to the fact that the configure script for libtecla uses gcc -print-libgcc-file-name, which does not provide a full-path.
Removing all notion of libgcc.a from the Makefile appears to alleviate the problem. Alternatively, one may be able to replace this item with the full path the the clang-provided libgcc.a.
If you are unable to access the bladeRF in Linux, it may be the case that your user does not have ample permissions to access the device.
As of git commit 0a2a3ac (2015-10-08), libbladeRF will print a warning if it is unable to probe/open a device due to insufficient permissions:
jon@nocontrol % bladeRF-cli -p
[WARNING @ libusb.c:292] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions.
probe: No devices are available. If one is attached, ensure it
is not in use by another program and that the current
user has permission to access it.
jon@nocontrol [1] % bladeRF-cli -i
[WARNING @ libusb.c:428] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions.
No bladeRF device(s) available.
If one is attached, ensure it is not in use by another program
and that the current user has permission to access it.
bladeRF> q
If using an older version, note that using the bladeRF-cli -v verbose will print out more information about error codes, and that setting BLADERF_LOG_LEVEL=debug in your environment will provide additional debug output.
In order to access the bladeRF, Linux users must ensure:
- The
88-nuand.rulesfile has been installed to/etc/udev/rules.d/- When building from source, the CMake option
INSTALL_UDEV_RULESdefaults toON
- When building from source, the CMake option
- The user is in the group specified by the CMake variable
BLADERF_GROUP-
BLADERF_GROUPdefaults to `plugdev`, because Debian/Ubuntu users are typically in this group when allowed to access removable USB storage devices. You may wish to change this to conform to your security policies or distribution.
-
- The udev rules have been reloaded since the installation of the aforementioned rules file
- This can be done via
sudo udevadm control --reload-rulesand then re-plugging the device.
- This can be done via
- Confirm that you see the device in the output of
lsusb -v - Look for any information about the device's connection in the output of
dmesg
Because PyBOMBS allows users to perform installations as non-root users, it uses -DINSTALL_UDEV_RULES=OFF when configuring the bladeRF project with CMake. (Copying a file to /etc/udev/rules.d/ requires root access, which a PyBOMBS user may not have.)
Therefore, if you've installed bladeRF support via PyBOMBS you will need to manually install the udev rules:
- Copy each 88-nuand-*.rules.in to
88-nuand-*.rules. - Edit each
88-nuand-*.rulesfile and replace all instances ofGROUP="@BLADERF_GROUP@"toGROUP="plugdev".- This assumes your user is in the
plugdev(default) group. Change as needed.
- This assumes your user is in the
- Copy this file to the udev rules directory:
sudo cp 88-nuand-*.rules /etc/udev/rules.d/ && sudo chmod 644 /etc/udev/rules.d/88-nuand-*.rules - Reload rules:
sudo udevadm control --reload-rules && sudo udevadm trigger - Replug the device.
Currently, only one program may have a device open at a time. Any additional calls to bladerf_open() or bladerf_open_with_devinfo() will fail with BLADERF_ERR_NODEV.
Under the hood, this is due to the first caller opening a device claiming the device's interfaces via libusb_claim_interface(). Further attempts to claim an interface will fail with LIBUSB_ERROR_BUSY.
Setting the libbladeRF log level to DEBUG or VERBOSE will generally make this issue apparent. See the bladeRF-cli -v option, or libbladeRF's bladerf_log_set_verbosity() function for information on setting the log level.
For example, if a first instance of the bladeRF-cli is started:
$ bladeRF-cli -i -v verbose bladeRF> info Serial #: 00000000000000000000000000000000 VCTCXO DAC calibration: 0x8100 FPGA size: 40 KLE FPGA loaded: yes USB bus: 2 USB address: 6 USB speed: Hi-Speed Backend: libusb Instance: 0
If another instance of the CLI is run simultaneously, we'll see the aforementioned libusb error about a device being busy (as its interfaces are already claimed by a different device handle.):
$ bladeRF-cli -i -v verbose ~ [VERBOSE] Found a bladeRF [DEBUG] FPGA currently does not have a version number. [DEBUG] Could not claim interface 0 - LIBUSB_ERROR_BUSY No device(s) attached. bladeRF>
If you're encountering the following error message with GNU Radio programs, but have verified that the device operates in the CLI, double check that no other programs have the device open:
FATAL: bladerf_source_c failed to open bladeRF device libusb:instance=0
Under normal operation, the bladeRF should appear with VID=1d50 and PID=6066.
If you see a Cypress device with VID=04b4 and PID=00f3, your bladeRF's FX3 may be in its bootloader mode. In this case, you may see a message in the bladeRF-cli program that notes a potential bladeRF running in bootloader mode. See the firmware upgrade wiki page for information on flashing the device.
If you are using a Virtual Machine, there have been issues reported when changing the interfaces or claiming different interfaces. The level of success has been varied depending on the type of port (XHCI or EHCI) and the VM software used.
It has been reported that some VM software does not fully support USB 3.0. Verify the speed that the VM detects the device at, and try falling back to 2.0 if 3.0 does not work.
Note that you may have to enable USB support in your VM's configuration. For example, in VirtualBox, one must check the "Enable USB Controller" and "Enable USB 2.0 (EHCI) Controller" options under a VM's USB settings.
To see the device in Windows, ensure you have the appropriate inf installed so that Windows associated the bladeRF with a libusbK driver. Verify that you've followed these steps in the Getting Started guide for Windows.
Windows driver signing enforcement may cause driver installation problems. Try using the latest Zadig on the computer you want to install the driver on. Zadig will self-sign the driver package and install the corresponding certificate.
In Windows 8, Libusbx may incorrectly report USB 3.0 SuperSpeed connection as Hi-Speed.
If you have performed an operating system update, and a previously working bladeRF stops working, you might have a mismatch between the OS and libusb. (For example moving from OSX 10.9.0 to 10.9.1). A sign of this will be that you can see the device via bladeRF-cli -p, but you cannot send or receive any data and instead you will see error messages like [ERROR] Failed to access peripheral. In this case, reinstall libusb:
$ sudo port -f uninstall libusb $ sudo port install libusb
As USB 3.0 is still relatively new, we've heard reports of some controller working great, and others not working at all. Ensure you have the latest drivers (and firmware, if needed) for your USB controller.
If possible, try testing the device on both USB 2.0 and USB 3.0 ports, as well as other host machines.
Previously, there was a known problem with Intel XHCI controllers in Linux when killing an application using libbladeRF in a manner that didn't allow libusb_close() to be called. This caused the device to not open again until a power-on reset was performed. This has been resolved in libbladeRF v1.2.0, via commit 2c48ba9e.
Other reported problems with Linux and XHCI drivers range from poor transfer rates to system-wide lockups. Should you encounter these, it is recommended that you try to use a more recent kernel version.
For example, the 3.13 kernel shipping with Ubuntu 14.04 is reported to cause system lockups when using a Renesas uPD720202-based USB 3.0 controller. However, the 3.16 kernel shipping with Ubuntu 14.10 does not appear to be affected. (For those needing to remain on the 14.04 LTS, it is recommended that you build a more recent kernel)
Below is a list of configurations that people have reported success on. Feel free to add to this list. (Please try to keep it reasonably organized.)
| Configuration Name | Device/Motherboard/CPU | Controller or Chipset | Operating System(s) |
| jynik's Desktop | EVGA x58 FTW3, Intel i7 | Onboard NEC/Renesas controller and 2-Port PCIe card NEC/Renesas | Windows 7, XUbuntu 12.10, 13.04, 13.10 (All 64-bit) |
| jynik's Laptop | Thinkpad W530, Intel i7-3630QM | Intel 7 Series/C210 Series xHCI (VID=8086, PID=1e31) | Windows 7, XUbuntu 13.04 (All 64-bit). Note: The XHCI issues mentioned above applies to the Linux configuration here. Able to process 40 Msps in osmocom_fft without overruns. |
| drmpeg's Desktop | Dell T3600, Intel E5-1607 | Onboard NEC uPD720200 xHCI | Ubuntu 13.04 (32-bit just to run old XView stuff). Able to process 36 Msps in osmocom_fft without overruns. |
| tnt's laptop | Apple Mac Book Pro Late 2008 (MacBookPro5,1) | ExpressCard ASM1042 (VID=1b21, PID=1042) | Gentoo (3.8.10-gentoo x86_64) |
| Anker PCI-E card | Uspeed USB 3.0 PCI-E Express Card with 4 USB 3.0 Ports | VL805 Chipset (VIA Technologies, Inc. Device 3483 (rev 01)) | Ubuntu 13.04 x86_64. osmocom_fft runs without issue at 40Msps |
| bglod's desktop | MSI X99A SLI Plus | VIA VL805 (VID=2109, PID=3431) | Arch Linux 4.10.6-1-ARCH |
| bglod's desktop | MSI X99A SLI Plus | Intel X99 (VID=8087, PID=8002 and PID=800a) | Arch Linux 4.10.6-1-ARCH |
| bglod's desktop | MSI X99A SLI Plus | ASMedia ASM1142 USB 3.1 (PCIe VID=1b21, PID=1242) | Arch Linux 4.10.6-1-ARCH |
| scancapecod's at work desktop | Dell Optiplex 9020 / i5-4570 @ 3.20GHz | Intel 8 Series/C220 Series USB Enhanced Host Controller, Intel USB 3.0 eXtensible Host Controller | Windows 7 Pro 64 bit Service Pack 1. SDR-Radio 30 MHz display |
| HoopyCat's desktop | ASUS Z87-PRO / i7-4770 | Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) | Linux Mint 16 x86_64 |
| piranha32's desktop | Asus P6T/i7 920@2.66GHz | Syba SD-PEX20139, uPD720201 | Fedora 21 x86_64. Max RX sample rate measured using bladeRF-cli: 31Msps |
| piranha32's desktop | Asus P6T/i7 920@2.66GHz | IOCrest/Syba SY-PEX20140, Etron EJ188 | Fedora 21 x86_64. Max RX sample rate measured using bladeRF-cli: 83Msps |
Issues have been reported on the following configurations:
| Configuration Name | Device/Motherboard/CPU | Controller or Chipset | Operating System(s) | Issues and symptoms |
| steve-m's desktop (with onboard xHCI controller) | ASRock Z68 Pro3 Gen3, Z68, Intel i5-2500K | Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) | Xubuntu 13.10 x86_64, Linux 3.11 | "Failed to access peripheral", libusb timeouts, kernel reports "Not enough bandwidth for altsetting 0" and other xHCI related errors |
| Orico PCI-E card | PVU3-4P USB 3.0 PCI-Express Host Controller Card | VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03) | Ubuntu 13.04 X86_64 | Hard lock while loading firmware |
| piranha32's desktop | Asus P6T / i7 920@2.67GHz | SABRENT CP-4PTU USB3 PCIe card with VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 02) | Fedora 19 x86_64. | The card worked flawlessly for about a month, but after that time started to hard lock the motherboard on every attempt to stream from bladeRF. |
| 3.5" 4 Port USB 3.0 Bay Hub with All-in-One USB 2.0 Card Reader | lsusb output: 2109:0811 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller | Arch Linux w/ kernel 3.13.5-1-ARCH | Hard lock when reading samples. Needed to reboot. |
This warning comes up if you have a that is considered out-of-date. It may be considered out of date due to libbladeRF requirements, or based upon the FPGA version that was detected.
Please update to the latest firmware, per the instructions in this wiki page.
libbladeRF prints a warning if it detects that the device's firmware requires a more recent FPGA version. If you see this message, fetch the associated FPGA image from the FPGA download page.
In the event that flash is corrupted, the bladeRF falls back to a bootloader mode, courtesy of the Cypress FX3 USB 3.0 peripheral controller. From this bootloader, we can re-flash the firmware.
The current bladeRF-cli version should detect and report FX3-based devices found in bootloader mode, as shown below:
$ bladeRF-cli -i
NOTE: One or more FX3-based devices operating in bootloader mode
were detected. Run 'help recover' to view information about
downloading firmware to the device(s).
No device(s) attached.
bladeRF> Per the CLI's instructions, we can get additional information on how to recover from the bootloader:
bladeRF> help recover
Usage: recover [<bus> <address> <firmware file>]
Load firmware onto a device running in bootloader mode, or list all
devices currently in bootloader mode.
With no arguments, this command lists the USB bus and address for
FX3-based devices running in bootloader mode.
When provided a bus, address, and path to a firmware file, the
specified device will be loaded with and begin executing the provided
firmware.
In most cases, after successfully loading firmware into the device's
RAM, users should open the device with the "open" command, and write
the firmware to flash via "load fx3 <firmware file>"In short, we can run recover to tell us the USB device and address in the bootloader mode, and then we can use this to specify which device to write the firmware to:
bladeRF> recover
FX3 bootloader devices:
---------------------------------------------------------
Backend: libusb
Bus: 1
Address: 5
Use 'recover <bus> <addr> <firmware>' to download and boot
firmware to the specified device.Assuming we have the firmware, bladeRF_fw_latest.img in our current directory, we see that our next command should be recover 1 5 bladeRF_fw_latest.img:
bladeRF> recover 1 5 bladeRF_fw_latest.img
Success! Use "open" to switch to this device.
Note that a "load fx3 <firmware>" is required tThis recover command does not yet actually flash anything. It writes to and boots from RAM on the FX3. This is intended to allow developers to quickly experiment with different firmware loads, without having to always write to flash.
Next, we can open the device and write this firmware to flash.
bladeRF> open
bladeRF> version
bladeRF-cli version: 1.1.2
libbladeRF version: 1.2.1
Firmware version: 1.8.0
FPGA version: Unknown (FPGA not loaded)
bladeRF> load fx3 bladeRF_fw_latest.img
Flashing firmware from bladeRF_fw_latest.img ...
[INFO @ usb.c:611] Erasing 3 blocks starting at block 0
[INFO @ usb.c:616] Erased block 2
[INFO @ usb.c:624] Done erasing 3 blocks
[INFO @ usb.c:818] Writing 479 pages starting at page 0
[INFO @ usb.c:822] Writing page 478
[INFO @ usb.c:831] Done writing 479 pages
[INFO @ flash.c:110] Verifying 479 pages, starting at page 0
[INFO @ usb.c:716] Reading 479 pages starting at page 0
[INFO @ usb.c:719] Reading page 478
[INFO @ usb.c:730] Done reading 479 pages
Done. Cycle power on the device.
bladeRF>
At this point, one can exit the bladeRF-cli and power cycle the device. It should be detected as a bladeRF when it is next plugged in.
In many cases, load failures have been the result of trying to load the wrong size FPGA image for the board in question. Check to make sure you are using the 40kLE FPGA for x40 and the 115kLE FPGA for x115.
If you're unsure which FPGA size is on your board, identify the the Altera Cyclone IV package on the top of the bladeRF. You should see text on the package that reads EP4CExxxF23C8N, where xxx is the size -- either 40 or 115.
If you're unable to load the FPGA using a USB 3.0 port while successfully doing so via USB 2.0, edit /linux/drivers/usb/host/xhci.h by changing TRBS_PER_SEGMENT from 64 to 256, and recompiling the kernel.
Ensure the location that you installed libbladeRF to is in your library search path. If you can't recall where this location is:
- Check the install_manifest.txt from your build directory, if you built from source
- Make note of the libbladeRF location in the output of:
ldd `which bladeRF-cli`
sudo ldconfig -v does not resolve the issue, you may have to add an ldconfig entry to ensure the proper libraty path is searched by the dynamic loader. To do this::
- As root (i.e., use sudo) create an /etc/ld.so.conf.d/bladeRF.conf and open it with your favorite editor
- Add a single line containing
/usr/local/libto the file. If you specified something other than /usr/local for CMAKE_INSTALL_PREFIX (the default), adjust this line accordingly. - Run
sudo ldconfigand then try runningbladeRF-cli --help. The library search issue should now be resolved.
One possible reason for this error is a mismatch between the FPGA bistream and the firmware being used. As of firmware v1.6.0 and FPGA v0.0.1, the UART bridge baudrate has been increased. Therefore, a mismatch would result in peripheral communication failures, as the FX3 and the FPGA are unable to communicate.
If you're seeing this issue, ensure that you've updated both your firmware (cycle power after flashing), and FPGA. Ensure you've disabled FPGA autoloading before flashing the new firmware, otherwise the (old) autoloaded FPGA will be attempting to use the lower bridge baudrate.
To disable FPGA autoloading: bladeRF-cli -L X
$ dmesg | grep xhci xhci_hcd 0000:03:00.0: Too many fragments 73, max 63
Affected Linux kernel versions: 3.12.6 to 3.12.9.
This has been patched in 3.12.10.
If you've used ports to get libusb installed, there is a high likelihood that it is version 1.0.9. Unfortunately, libusb didn't add superspeed support until version 1.0.15 for OSX. libusb v1.0.17+, works on OSX.
When first plugging in the bladeRF, a single LED should illuminate to indicate power is being delivered to the board. On the bladeRF Classic, this is D1. On the bladeRF 2.0 micro, this is D4. If the power indicator does not turn on and 5 V is being supplied, then it is likely there is something wrong with the power supply rails on the board. However, it is also possible for this LED to be illuminated and still have a power issue.
With the board power connected and a voltmeter (multi-meter set to Volts) in hand, proceed with the following probe points to narrow down the source of the power failure. Remember to pick a solid ground reference for the black probe. A good place is the body of the SMA or SMB ports.
For the purposes of positioning consistency, orient the board so the USB port is on the left and the component side is facing up.
Open the bladeRF Classic schematic.
Page 1 shows the general power architecture. The main 5 V rail feeds a 1.2 V SMPS and a 3.58 V SMPS. The 1.2 V switcher provides the core voltage to the FX3 and FPGA. The 3.58 V switcher supplies several low-dropout linear regulators that drop the voltage down to 3.3 V, 2.5 V, and 1.8 V for various components including the LMS6.
- Probe the 5 V rail at J70 pin 2 or 5. Top side, near DC barrel jack. It should read at least 4.5 V.
- Probe
VBUS_INat J70 pin 3 or 4. Top side, near DC barrel jack. It should read at least 4.5 V. - Probe the 1.2 V switcher output at C368. Top side, top-middle, center-left. It should read ~1.2 V, same with each sub-point below.
- Probe each side of FB4 (bottom side, near USB port)
- Probe each side of FB5 (bottom side, near USB port)
- Probe each side of FB6 (bottom side, near USB port)
- Probe each side of FB7 (top side, between USB port and U43/FPGA)
- Probe the 3.58 V switcher output at C329. Top side, top-middle, center-left. It should read ~3.58 V.
- U49
VA1P8: top side, top right corner- Pin 1 should read ~3.58 V
- Pin 5 should read ~1.8 V
- U50
VD1P8: top side, bottom center-right- Pin 1 should read ~3.58 V
- Pin 5 should read ~1.8 V
- U66
VA2P5: top side, left of GPIO connector U74- Pin 1 should read ~3.58 V
- Pin 5 should read ~2.5 V
- U55
VD3P0_CLK: top side, top center board- Pin 1 should read ~3.58 V
- Pin 5 should read ~3.0 V
- U53
V3P3_RX_LMS: top side, top right corner- Pin 1 should read ~3.58 V
- Pin 4 should read ~3.3 V
- U54
V3P3_TX_LMS: top side, bottom right corner- Pin 1 should read ~3.58 V
- Pin 4 should read ~3.3 V
- U65
VD3P3: top side, bottom center-right- Pin 1 should read ~3.58 V
- Pin 5 should read ~3.3 V
- U37: top side, middle-top, center-left
- Pin 5
USB3_VBUSshould read at least ~4.5 V - Pin 4
FLAGshould read at least ~4.5 V.
- Pin 5
TODO
If the device is not detected by the host and the voltage rails are within their nominal ranges, it is possible there is an issue with the main 38.4 MHz clock or its distribution to the FX3. Armed with an oscilloscope and a fine-tipped probe, proceed with the following debug steps.
- U42 is the VCTCXO crystal itself, the raw source of the 38.4 MHz clock. Probe U42 pin 3 with the oscilloscope. A 3.0 V clock at 38.4 MHz should be visible.
- U67 is a 1:2 clock buffer. Pin A2 (
CLK_OUT1) goes to the FX3. Pin D2 (CLK_OUT2) goes to U68, the Si5338 clock generator.- Pin A2: the only way to probe this clock output is to scrape off the solder mask on a via along the trace. This can damage your board and may void your warranty. If you suspect this clock output to be problematic, please contact Nuand via e-mail.
- Pin D2: probe at U68 pin 3 (
IN3). A 3.0 V clock at 38.4 MHz should be visible.
- U68 is the Si5338 clock generator. It has 7 clock outputs in use. None are critical for initial board detection by the host. For proper operation, all clocks should be functional.
- Pin 21 (
OUT0B):LMS_CLKLMS6 PLL clock - Pin 22 (
OUT0A):C4_CLKmain FPGA clock - Pin 18 (
OUT1A):LMS_RX_CLKLMS6 RX data interface clock* - Pin 14 (
OUT2A):LMS_TX_CLKLMS6 TX data interface clock* - Pin 13 (
OUT2B):C4_TX_CLKFPGA TX data interface clock* - Pin 10 (
OUT3A):SMB_CAPoff-board SMB connector* - Pin 9 (
OUT3B):EXP_CLKExpansion interface clock*
- Pin 21 (
TODO
If you're really stuck, join the #bladeRF channel on Freenode or post to the Nuand Troubleshooting forum.
Folks in the community are generally very happy to help. However, to make the most of everyone's time, please try to have as much of following information available as you can. Providing this information up front can help you get to the bottom of things much quicker.
- Information about the target host machine
- Are you in a VM? See the Virtual Machines section for some known problems.
- Are you running on a 32-bit or 64-bit processor?
- What is your USB controller? Given that USB3 is still moderately new, some controllers have found to perform significantly better (or worse) than others.
- Are you connecting your device to a 2.0 or 3.0 port? If a 3.0 port, is it actually enumerating at SuperSpeed (or at Hi-Speed?)
- Is this a tablet or smartphone?
- The OS you're using
- For Linux, please note your distribution (and that distribution's version), as well as kernel version
- Version information for the items you're having issues with
- When running the bladeRF-cli in interactive mode (
bladeRF-cli -i), theversioncommand may be used to display information for both host items and the attached device. This is generally helpful in identifying if a problem you're seeing has been fixed in more recent versions.
- When running the bladeRF-cli in interactive mode (
- Any relevant error messages or warnings.
- Run the bladeRF-cli with
-v verboseto enable all output - (Linux users) Check the output of dmesg and lsusb
- For GNU Radio and gr-osmosdr issues, note the versions of these you're running.
- Run the bladeRF-cli with
- Have you followed the steps in the Getting Started guides?
- If you're currently in the process of following these guides, which steps have you already performed, and at which step are you encountering problems with?