bladeRF-cli: Failed to open device Operation timed out [SOLV

[jynik]

You'll be the second person I've helped this week on this exact issue -- so it's a big red flag that we need to find a way for libbladeRF to allow users to get out of this situation. I need to think a bit more about a clean solution, and have registered issue #327 for this, which I will plan to tackle over the next week or so.

In the meantime, I can give you a work-around if you want to follow this wiki page on building the code from source.

First, following the instructions in the linked wiki page, fetch the lastest code from master (changeset 7c0969a44deca4583ce5aa6dc3f8dc32a1ab7a82 at the time of writing).

To start, just go through a normal build to ensure you've got your environment up and running. Without a device plugged in, you can do a bladeRF-cli.exe -e 'version' to see the bladeRF-cli and libbladeRF version info, and verify you're running the newly built code.

Next, change this line from:

Code: Select all

return result;

to

Code: Select all

return 0

By doing this you are hard-coding the usb code to always report "no FPGA is loaded." As a result, the library will not attempt to initialize the FPGA, which involves fetching the FPGA version #, where you're seeing that failure occur.

Once you've made that change, you should be able to run bladeRF-cli.exe -L X to erase the FPGA from flash, disabling the autoload.

Once that succeeds, restore the above line of code to its original state.

Next, check out this wiki page on where you can store FPGA bitstreams (the .rbf) on your host machine such that libbladeRF will automatically load them for you. If you're always using a host machine with the bladeRF, this solution is faster than the flash-autoload and you can this sort of tricky situation you're currently in. To update the FPGA, you'd just need to replace a file on your host machine.

Best regards,
Jon

[[email protected]]

Jon,

Thanks! This all makes perfect sense, and gives me an excuse to delve into the code. I'll give it a try later this weekend and report on the results.

Rob

[jynik]

Hi Rob,

I pushed a workaround for this to the repo. If you build the latest and greatest code, you can now simply set a BLADERF_FORCE_NO_FPGA_PRESENT environment variable to instruct libbladeRF to essentially do what I suggested with the code changes.

Below is log from me replicating this on my Linux box and recovering from the situation, leveraging the newer host-based FPGA autoload. It's largely the same process in Windows; you'll have to just run set BLADERF_FORCE_NO_FPGA_PRESENT=1 prior to running the CLI.

Code: Select all

# Reproduce the symptoms of having a pre-v0.0.1 FPGA autoloading
# from the bladeRF's SPI flash

$ bladeRF-cli -i -v verbose 
[VERBOSE @ libusb.c:333] Using libusb version: 1.0.17.10830
[VERBOSE @ libusb.c:341] Found a bladeRF (based upon VID/PID)
[VERBOSE @ usb.c:251] Changing to USB alt setting 0
[VERBOSE @ usb.c:251] Changing to USB alt setting 1
[DEBUG @ usb.c:168] Failed to read FPGA version[0]: Operation timed out
Failed to open device (first available): Operation timed out


# Erase the FPGA region of SPI flash by forcing libbladeRF to always
# report that no FPGA is available.

$ BLADERF_FORCE_NO_FPGA_PRESENT=1 bladeRF-cli -L X
Erasing stored FPGA to disable autoloading...
[INFO @ usb.c:567] Erasing 55 blocks starting at block 4
[INFO @ usb.c:572] Erased block 58
[INFO @ usb.c:580] Done erasing 55 blocks
Done.


# Fetch the latest FPGA (at the time of writing) and copy it
# to a directory that libbladeRF search for host-based auto-loading 

$ wget nuand.com/fpga/v0.0.6/hostedx40.rbf
$ mkdir -p ~/.config/Nuand/bladeRF
$ mv hostedx40.rbf ~/.config/Nuand/bladeRF


# Power cycle the bladeRF and run the CLI again. We're back up and
# running, as shown by the version and info commands!
$ bladeRF-cli -i
bladeRF> info

  Serial #:                 00000000000000000000000000000000
  VCTCXO DAC calibration:   0x8102
  FPGA size:                40 KLE
  FPGA loaded:              yes
  USB bus:                  10
  USB address:              11
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

bladeRF> version

  bladeRF-cli version:        0.11.1-git-f8a6b91
  libbladeRF version:         0.16.2-git-f8a6b91

  Firmware version:           1.7.1-git-ca697ee
  FPGA version:               0.0.6

Cheers,
Jon

[[email protected]]

Jon,

I'll build it tonight and let you know if I have problems.

Thanks Again,

Rob

[[email protected]]

Jon,
Successfully built and ran your patched bladeRF-cli and it all seems fine. Ran with the -L X option, ran again loading the latest .rbf, and all seems fine. Then I ran SDR-Radio and ran into the next problem. The board seems to only be showing "birdies" or fft artifacts, and the audio is a repetitive noise burst followed by silence, at about 2 second period. I reduced the sampling rate, and tried both USB 3.0 and USB 2.0. I plan to confirm the rev levels of everything and try GNURadio apps and SDR# to help track down the issue. Any suggestions?

Thanks Again,
Rob

[[email protected]]

Jon,
Confirmed all revs are the same as those in your last post. The board is not "deaf", it just gets stuttering in the stream, even at 2MHz on 3.0. I'm pretty sure the board is functioning properly now, but I have another (USB?) issue.

Thanks again for all your help. Even with the stuttering I was able to confirm the operation of the transverter. Great Product!

Rob

[jynik]

Hi Rob,

I'm glad to hear you got though that firsts set of hurdles. That stuttering is concerning, as the device should certainly be keeping up. That behavior is generally indicative of the host/software not keeping up with the sample rate and dropping buffers. However, that seems strange, given the low sample rates you've mentioned that should work fine on both USB 2.0 and 3.0.

If the software you're using gives you the ability to enable verbose output, you can usually set the libbladeRF log level to "debug" to get some printouts for when RX overruns occur.

I suspect that there's a libusb.dll shipped with SDR-Radio -- you'll want to ensure it's v1.0.19, as I've been told v1.0.18 in Windows has a number of issues. Simon's a pretty responsive guy -- perhaps you could touch base with him if nothing I say here seems to help. If he has the same problems, we can all work together to figure out what's going on and find a solution.

I would say it's definitely worth trying a few apps, just to rule out any device or build-specific problems. As you mentioned, SDR# is another good one to try.

As I'm more familiar with development and daily life on the Linux side of things, I would highly suggest giving GNU Radio a shot; I think I can offer a bit more in the way of assistance and debugging strategies there. The bootable GNU Radio Live image ships with support for a number of SDRs, including the bladeRF, and would be a quick way to get GQRX up and running to listen to some audio. When running GQRX, be sure to set your samplerate to 2Msps, and ensure your bandwidth is <= your samplerate.

Update: I belive the Pentoo live image should also contain bladeRF support -- but I haven't had a chance to test drive this yet, so I won't be of much use there.

Best regards,
Jon

[jynik]

Rob,

While trying to help answer a similar question, I came upon this sdr-radio group post. If you weren't trying the beta mentioned in this post, maybe it's worth a shot?

Cheers,
Jon

[cwiener]

The bladeRF DLL that's included in the current beta builds has some stuttering issues for me (USB 2.0 at 8 MHz). Replacing it with the latest from Nuand's Gighub seems to resolve the issue.

When I mentioned this on the beta list Simon said he's waiting for the bladeRF DLL to stabilize before updating the version he's including.

I've bad decent reults with his betas and the transverter board. The biggest issue at lower frequencies is the numerous false images that the bladeRF currently has.

Chris

[[email protected]]

Chris, Jon

Many thanks! That (my newly built bladeRF.dll) did it. Now on to GNU Radio on my Banana PI or the new ASUS AM1I-A I just picked up... Plan to build a standalone radio with USB option ala CR-1a. This is so much fun. Looks like <50MHzish is going to need some help in the filtering though...

Rob

[jynik]

Just another thought with regard to stuttering (likely caused by dropped samples) in Windows -- try using Zadig to switch from the libusbK to the WinUSB driver. I've been hearing reports that the latter libusb driver has been yielding better performance and stability for folks.

[[email protected]]

Will do, and report on the results...