Official bladeRF forum

jynik wrote:

Code: Select all

bladeRF -i -v verbose
bladeRF> version
bladeRF> info
bladeRF> load fpga <path to your FPGA rbf file goes here>

Hi Jynik,

Here's the results for the above commands after the update to the Visual Studio 2012 C++ Runtime and using your bladerf.dll as copied into the \Program Files (x86)\bladerf\x64 folder, which is where I'm running bladerf-cli.exe from:



Everything starts out dandy, but as soon as I try to load the fpga the USB disconnect sound comes across the speakers and the error shown appears. To be sure it wasn't random, I unplugged the bladeRF, replugged, and re-ran the procedure with the same results. Unfortunate as USB speed for the first time ever is actually showing SuperSpeed.

Note that "USB Bus: 3" is not saying that your device is connected to a USB 3.0 bus. The "USB speed" field denotes this, as you've seen.

I should have known better than that. Ugh....

I'd be interested to see how that long 2-cable setup performs on your work machine...something tells me you might just see the same thing...

When you say "the same thing" do you mean the disconnect when trying to load the fpga? I took it to work with me today but only brought the supplied cable, and as before it performed flawlessly.

Thanks,

Scott

scancapecod wrote:Unfortunate as USB speed for the first time ever is actually showing SuperSpeed.

I just wanted to make it clear that with that modified DLL, all devices (even on USB 2.0) will show up as SuperSpeed. This is a hackish workaround the libusb issue you're running into where libusb is telling libbladeRF "this device is Hi-Speed" when it's actually SuperSpeed. We're basically hard-coding libbladeRF to use transfer sizes associated with SuperSpeed. So be aware, that if you attempt to use that patched DLL with 2.0, you'll likely run into issues.

scancapecod wrote: When you say "the same thing" do you mean the disconnect when trying to load the fpga? I took it to work with me today but only brought the supplied cable, and as before it performed flawlessly.

Sorry for the confusion. What I meant to say was that I would not be suprised if you saw the device enumerate at Hi-Speed at work (i.e., the machine that's working great), if you were to use both the 6 foot extension together with the supplied cable. I base that on soley on 1 experience I had with a long cable, and the "hit or miss" nature of USB 3.0 extender cable reviews I've seen online.

Unfortunately, I don't have anything to try tonight, but this week I'll poke a few people who might have ideas, and work on getting a Windows 8.1 machine up and running in an attempt to reproduce this failure. After going back over the relevant code a bit more, I might drop off a DLL here with some additional diagnostic messages, if it looks like they'll be of any use.

Stay tuned...and sorry for the delay

There is absolutely NO need to apologize! I appreciate the help and I expect that those that follow will as well, especially if we can work towards getting this working. In the interim I DO have a working bladeRF, just at 2.0 speeds. Honestly, it's not every day that I'd be trying to look at 30 MHz of spectrum, but the bottom line is if it CAN, I want it to, obviously. I should be the one apologizing. I think I know my fair share about PC's and radios, but you folks that have taken the lead with cutting edge technology and made it work through your know-how, patience, and trial and error run circles around me. You surely have my appreciation.

Thanks.

Scott

Scott,

For what it's worth, I really do appreciate your patience, upbeat attitude, and willingness to run some tests.

Since you're up and running to some degree, I think I'll put the WIn 8.1 + libusb debugging on the back burner for a bit, at least until we have an alternative Windows backend (which is the next big task on my TO DO list). I think this a much better use of development time, as it will ultimately benefit Windows users more...so the sooner the better on that task. I've been talking to a few folks about the libusb issue and patches regarding this issue, so hopefully when I come back to it, some of these patches will have been pushed up to mainline, or at least commented on by the devs.

jynik wrote: How about we check a "BLADERF_FORCE_SUPERSPEED" environment variable in libbladeRF? You could set allow folks to effectively set this environment variable if they are running into this, or just have them put it in the environment themselves -- no code change to you.

I really didn't think that one through -- as LazyDodo pointed out to me, instead of this gross kludge, we could instead manually check our descriptors, rather than rely on the libusb_get_device_speed(). So..we'll get that in there shortly.

I win!

I installed the Startech PEXUSB3S400 PCI-e x4 USB 3.0 card in my Gateway i5 Windows 8.1 machine this evening. At first it didn't work with the Microsoft (Microshaft?) drivers installed and exhibited the same behavior that the Intel chipset did, to include the CLI still showing the bladeRF being connected to a "highspeed" USB port. I had nothing to lose at that point so I tried installing the Windows 7 drivers for the card, and lo and behold it worked.

So I'm happy and somewhat relieved to say I have a fully working bladeRF. I will add this working configuration to the Wiki. As I type this I'm looking at just under 40 MHz of spectrum between 460-500 MHz using SDR-Radio software. The CPU is running at anywhere from about 43-50%.

So, it seems to me that any Windows drivers for any USB 3.0 chipset just won't cut it. If you can, find the actual drivers and use them. In the case of my Intel 8/C220 series on board chipset, Intel doesn't have a Windows 8 driver "because Windows has a native driver".....thanks, chumps!

So this saga mercifully for all involved comes to an end....now to wait for the HF/VHF transverter....that's going to be a fun addition.

Thanks again to all for the help!

Scott