Skip to content

Troubleshooting

Jump to bottom
Brian Glod edited this page Jan 10, 2019 · 79 revisions

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!

Table of Contents

Configuration and Compilation Issues

Build fails due to a warning being treated as an error

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 ../

libbladeRF

Missing libusb

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.

Outdated libusb

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.

libusb_get_version() is undefined

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.

Cannot build libtecla under Mac OSX 10.9 due to missing libgcc.a

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.

Runtime Issues

Failing to see or connect to the device

Linux: udev and permissions

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.rules file has been installed to /etc/udev/rules.d/
    • When building from source, the CMake option INSTALL_UDEV_RULES defaults to ON
  • The user is in the group specified by the CMake variable BLADERF_GROUP
    • BLADERF_GROUP defaults 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-rules and then re-plugging the device.
If you have verified the above items and still cannot see the device:
  • 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

PyBOMBS

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:

  1. Copy each 88-nuand-*.rules.in to 88-nuand-*.rules.
  2. Edit each 88-nuand-*.rules file and replace all instances of GROUP="@BLADERF_GROUP@" to GROUP="plugdev".
    1. This assumes your user is in the plugdev (default) group. Change as needed.
  3. 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
  4. Reload rules: sudo udevadm control --reload-rules && sudo udevadm trigger
  5. Replug the device.

Device may only be opened by one program

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

Device's VID and PID

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.

Virtual Machines

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.

Windows

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.

Mac OSX

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

Host or Device-specific Issues

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.

Issues with XHCI and Linux

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)

Working configurations

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 [email protected] Syba SD-PEX20139, uPD720201 Fedora 21 x86_64. Max RX sample rate measured using bladeRF-cli: 31Msps
piranha32's desktop Asus P6T/i7 [email protected] IOCrest/Syba SY-PEX20140, Etron EJ188 Fedora 21 x86_64. Max RX sample rate measured using bladeRF-cli: 83Msps

Problematic Configurations

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 [email protected] 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.

Outdated firmware warning

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.

Outdated FPGA warning

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.

bladeRF-cli detects device in bootloader mode

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>
In this situation, you should see a USB device enumerated as a Cypress Westbridge device. If the only FX3-based device plugged into your machine is a bladeRF you can continue to reflash it. Otherwise, ensure you're not flashing bladeRF firmware onto some other device.

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 t

This 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.

FPGA load failures

Operation Timed Out

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.

File or device I/O failure

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.

Linux: Failure to find libbladeRF.so or libbladeRF.so.0

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`
If running 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/lib to the file. If you specified something other than /usr/local for CMAKE_INSTALL_PREFIX (the default), adjust this line accordingly.
  • Run sudo ldconfig and then try running bladeRF-cli --help. The library search issue should now be resolved.

[ERROR] Could not write to si5338 (-5): File or device I/O failure

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.

Mac OSX Superspeed issues

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.

Hardware

Power Rails

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.

bladeRF Classic

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.

  1. 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.
  2. Probe VBUS_IN at J70 pin 3 or 4. Top side, near DC barrel jack. It should read at least 4.5 V.
  3. 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.
    1. Probe each side of FB4 (bottom side, near USB port)
    2. Probe each side of FB5 (bottom side, near USB port)
    3. Probe each side of FB6 (bottom side, near USB port)
    4. Probe each side of FB7 (top side, between USB port and U43/FPGA)
  4. Probe the 3.58 V switcher output at C329. Top side, top-middle, center-left. It should read ~3.58 V.
  5. U49 VA1P8: top side, top right corner
    1. Pin 1 should read ~3.58 V
    2. Pin 5 should read ~1.8 V
  6. U50 VD1P8: top side, bottom center-right
    1. Pin 1 should read ~3.58 V
    2. Pin 5 should read ~1.8 V
  7. U66 VA2P5: top side, left of GPIO connector U74
    1. Pin 1 should read ~3.58 V
    2. Pin 5 should read ~2.5 V
  8. U55 VD3P0_CLK: top side, top center board
    1. Pin 1 should read ~3.58 V
    2. Pin 5 should read ~3.0 V
  9. U53 V3P3_RX_LMS: top side, top right corner
    1. Pin 1 should read ~3.58 V
    2. Pin 4 should read ~3.3 V
  10. U54 V3P3_TX_LMS: top side, bottom right corner
    1. Pin 1 should read ~3.58 V
    2. Pin 4 should read ~3.3 V
  11. U65 VD3P3: top side, bottom center-right
    1. Pin 1 should read ~3.58 V
    2. Pin 5 should read ~3.3 V
  12. U37: top side, middle-top, center-left
    1. Pin 5 USB3_VBUS should read at least ~4.5 V
    2. Pin 4 FLAG should read at least ~4.5 V.
If any of these rails seem lower than nominal, please contact Nuand via e-mail for assistance. Please include a brief description of the problem, expected results, any relevant log information, and the voltage rail(s) that seem suspect.

bladeRF 2.0 micro

TODO

Clocks

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.

bladeRF Classic

  1. 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.
  2. 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.
    1. 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.
    2. Pin D2: probe at U68 pin 3 (IN3). A 3.0 V clock at 38.4 MHz should be visible.
  3. 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.
    1. Pin 21 (OUT0B): LMS_CLK LMS6 PLL clock
    2. Pin 22 (OUT0A): C4_CLK main FPGA clock
    3. Pin 18 (OUT1A): LMS_RX_CLK LMS6 RX data interface clock*
    4. Pin 14 (OUT2A): LMS_TX_CLK LMS6 TX data interface clock*
    5. Pin 13 (OUT2B): C4_TX_CLK FPGA TX data interface clock*
    6. Pin 10 (OUT3A): SMB_CAP off-board SMB connector*
    7. Pin 9 (OUT3B): EXP_CLK Expansion interface clock*
* Clock may not toggle unless it is enabled or in use.

bladeRF 2.0 micro

TODO

Getting help

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), the version command 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.
  • Any relevant error messages or warnings.
    • Run the bladeRF-cli with -v verbose to 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.
  • 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?
Clone this wiki locally