Windows 8.1 + USB 3.0 = EXTREME Frustration

[scancapecod]

Hello,

I bought the bladeRF because of its capability to view wide chunks of radio spectrum at a time, up to just under 40 MHz worth when interfaced to a PC via USB 3.0. The following two .jpg files show the results on two different Windows 8.1 PC's, one Dell and one Gateway (specs to follow). The bladeRF is of course connected via USB 3.0 ports on both PC's. I am able to communicate with the bladeRF from the CLI with both PC's and load the FPGA. I have version 1.6 of firmware and the latest FPGA image (1/28/14 I believe). The first .jpg below is a narrow view of spectrum, the second a wide one, and this is the result I get across the entire frequency coverage of the bladeRF, on both PC's.

https://dl.dropboxusercontent.com/u/360 ... owview.jpg
https://dl.dropboxusercontent.com/u/360 ... deview.jpg

I have tried different antennas. I have tried shutting down equipment to see if it is causing some type of interference. I have run the bladeRF connected to a USB 2.0 port on both machines and had absolutely no issues, but of course I can't use it to look at more than 10 MHz of spectrum at a time.

Machine #1: Dell - Intel Core i7-4770 CPU @ 3.40 GHz 3.40 GHz, 8.00 GB RAM, Windows 8.1 64 bit. USB controller is an Intel 8 Series/C220 Series, USB 3.0 eXtensible Host Controller - 0100 (Microsoft).
Machine #2: Gateway - Intel Core i5-4440 CPU @ 3.10 GHz 3.10 GHz, 8.00 GB RAM, Windows 8.1 64 bit. On board USB controller is again the Intel 8 Series/C220 Series, USB 3.0 eXtensible Host Controller - 0100 (Microsoft). I also installed a PCI-E USB card with the Renasas USB 3.0 eXtensible Host Controller - 0096 (Microsoft). It produces nearly the exact results, although the display is a "little" clearer.

In all cases if I'm lucky enough to even see something remotely resembling a signal, the demodulated voice (FM Narrow) sounds like it is in "slow motion".

Naturally the PC I use at work handles the bladeRF via USB 3.0 perfectly. It is a Dell Optiplex 9020, Intel Core i5-4570 @ 3.20 GHz. It uses the EXACT same Intel USB 3.0 as listed in the two above. The difference? It runs Windows 7 Pro 64 bit. With it I had no trouble at all looking at 30 MHz of spectrum.

I originally bought the above Renasas card for use in an older Windows 7 32 bit PC I had here, running an AMD Phenom Processor at I think 3 GHz, but the card would not even see the bladeRF when operating the CLI.

I am not prepared to switch to Linux in order to use the bladeRF.

Can anyone comment on the screenshots and shed some light as to what is going on? I'm extremely frustrated, and moving forward, if I can't use this device to its fullest extent I will be extremely disappointed.

Thank you.

Scott

[scancapecod]

No performance difference but I did find that I was not using the latest firmware or FPGA; I downloaded them both from http://hoopycat.com/bladerf_builds/ and updated the bladeRF. Tried it again in a USB 3.0 port and I noticed that despite being plugged into a 3.0 port bladerf-cli is showing that I'm plugged into a 2.0 port when I run the "probe" command. "USB Bus: 2".

Same results as in the pic's in the original post.

Edit: if it helps any, more info:

bladeRF-cli version: 0.10.3-git
libbladeRF version: 0.12.1-git
Firmware version: 1.6.1-git-bc88a82-buildomatic
FPGA version: 0.0.3

[jynik]

Hi there,

When a device is enumerating as 2.0 instead of 3.0, your max achievable samplerate is usually 5-6 Msps. (However, I've occasionaly heard people report better results.) For the 30 MHz of bandwidth you're looking for, the trying to operate at buffer sizes for USB 2.0 probably is resulting in timeouts and other such failures.

I asked around on IRC, as I don't have an Windows 8.1 box to test on. stephenong noted that he identified this to be a libusbx issue, stemming from a change in the Windows USB API.

As you'll see there, this item's a bit lower on the libusbx folk's priority list and hasn't been addressed yet, as far as I can tell. Note that the libusbx project has been marked discontinued and is now being continued over at http://www.libusb.info, so you might want to keep an eye on that site to see what comes of this issue.

stephenong's solution was to patch libbladeRF to always report that the device was 3.0, since he only uses it in the 3.0 port. To make this change in the source, you'll want to edit this file and replace that lusb_get_device_speed function with this:

Code: Select all

static int lusb_get_device_speed(struct bladerf *dev,
                                 bladerf_dev_speed *device_speed)
{
    *device_speed = BLADERF_DEVICE_SPEED_SUPER;
    return 0;
}

I can't guarentee it will work, but I've posted a x64 release build of libbladeRF (bladeRF.dll) with the aforementioned change up here: http://nuand.com/~jon/bladeRF-git-bc88a ... rspeed.dll
(You'll want to rename that file to bladeRF.dll -- the wacky name is just a reminder for me.)

If you're up for it, you can build from source via the instructions posted on the Wiki.

From the bladeRF side of things, windows-specific alternatives to libusb are also in the works.

Another community member has been working on a Cypress driver-based backend for libbladeRF, as he's had a number of libusb(x) issues with his Asmedia controller. We'll be teaming up with him within the next couple weeks to refactor the backend interface in libbladeRF, and pull in his support for the Cypress driver alternative. So far, he's been reporting far better results with his driver-based backend -- these preliminary results are very encouraging.

Frustrating indeed...hopefully you'll find something of use here. I know "wait until someone pushes a fix" response always sucks.

[scancapecod]

That is a FANTASTIC response, jynik, and I greatly appreciate it. I will work on this during the week; I'm in Super Bowl mode right now even though my team (New England, don't hate) is not in it this year.

Many thanks, and I'll report back with results!

[LazyDodo]

If you're able to compile stuff your self (and really know what you're doing, not 'what button do i press?') my cypress backend code is available here, it's all rather experimental, and due to way sdr-radio works i'm fairly sure it won't work with this new backend. also Rx only for now...

[SDR-Radio.com]

That is a FANTASTIC response, jynik, and I greatly appreciate it. I will work on this during the week; I'm in Super Bowl mode right now even though my team (New England, don't hate) is not in it this year.

Many thanks, and I'll report back with results!

I thought Super Bowl was yesterday? I'll look at the bladeRF code I have and see if I can make this setting an option. Will report back or something...

[SDR-Radio.com]

From the bladeRF side of things, windows-specific alternatives to libusb are also in the works.

That would help, Windows seems to be the poor relation here and with another SDR manufacturer. In the end it's the Console programmer who gets it in the neck .

[scancapecod]

I can't guarentee it will work, but I've posted a x64 release build of libbladeRF (bladeRF.dll) with the aforementioned change up here: http://nuand.com/~jon/bladeRF-git-bc88a ... rspeed.dll
(You'll want to rename that file to bladeRF.dll -- the wacky name is just a reminder for me.)

Hi Jynik,

I tried your method above with the bladeRF plugged into a USB 3.0 port. First I switch to the \Program Files (x86)\bladeRF\x64 folder. I rename the existing bladeRF.dll to oldbladeRF.dll, and then replace it with your file. When I run bladeRF-cli -i at the command prompt I get a pop up error:

"bladeRF-cli.exe - System Error
The program can't start because MSVCR110.dll is missing from your computer. Try reinstalling the program to fix this problem."

So then I deleted your bladeRF.dll file and renamed the old one back to bladeRF.dll. I unplugged, replugged, and tried to reload the FPGA. It appears to load and then I hear the familiar USB disconnect noise from my speakers. If I then type "info" at the bladeRF prompt it tells me "file or device I/O failure". A reboot did not solve the problem either, same result. So I remove the bladeRF from a USB 3.0 port and plug it into a USB 2.0 port, load the FPGA and it's fine again. Bizarre behavior, to me anyway.

On another somewhat related note, before I tried the above, just for laughs I tried a USB 3.0 6' extension cable connected to the cable Nuand supplied when I purchased the bladeRF. I obviously plugged that into a USB 3.0 port. And it worked normally with a 10 MHz bandwidth, but started to exhibit similar but not quite as bad behavior as shown in my above screenshots when I tried to increase to 30 MHz and then even 20 MHz bandwidth. At the bladeRF prompt it the probe command was showing "USB Bus: 3" but listed it as "high speed".

Ironically after completing the file changes noted above, just now even plugged into a USB 2.0 port it is showing now as "USB Bus: 3". So uh....I'm confused! I expect at the very least I should probably re-run the Windows installer and start fresh.

Thanks to all for the continued help; of all of this I find the increased length of the cable causing different results when plugged into a USB 3.0 port of the most interest....

Scott

[jynik]

Hi Scott. Ah bummer, sorry! Let's try to go chunk by chunk here...

I tried your method above with the bladeRF plugged into a USB 3.0 port. First I switch to the \Program Files (x86)\bladeRF\x64 folder. I rename the existing bladeRF.dll to oldbladeRF.dll, and then replace it with your file. When I run bladeRF-cli -i at the command prompt I get a pop up error:

"bladeRF-cli.exe - System Error
The program can't start because MSVCR110.dll is missing from your computer. Try reinstalling the program to fix this problem."

Ok, so I screwed up there (did I mention I'm more of a Linux guy? ) in the sense that I built the DLL with a different version of Visual Studio the guy that's been doing the Windows installers. I built it with Visual Studio 2012 Express, so if you wanted to install the MSVCR110.dll, you could fetch the Visual Studio 2012 C++ Runtime Environment from Microsoft. From my understanding, one generally bakes this runtime environment installation into the installation of their application.

I'd say it's definitely worth a shot to try this again after installing the VS 2012 runtime components. You'll probably end up installing these runtime components in the future (perhaps unknowingly), when you install some program that uses them, so it's not like you're installing too much extra junk.

So then I deleted your bladeRF.dll file and renamed the old one back to bladeRF.dll. I unplugged, replugged, and tried to reload the FPGA. It appears to load and then I hear the familiar USB disconnect noise from my speakers. If I then type "info" at the bladeRF prompt it tells me "file or device I/O failure". A reboot did not solve the problem either, same result. So I remove the bladeRF from a USB 3.0 port and plug it into a USB 2.0 port, load the FPGA and it's fine again. Bizarre behavior, to me anyway.

This seems a little bizarre - every thing should have been working the same way it was prior to trying out that DLL. Would you mind doing the following on the 3.0 port, and then posting the full results here? There will be quite a bit of output. I'd like to see this just to understand why that error is occurring.

Code: Select all

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

On another somewhat related note, before I tried the above, just for laughs I tried a USB 3.0 6' extension cable connected to the cable Nuand supplied when I purchased the bladeRF. I obviously plugged that into a USB 3.0 port. And it worked normally with a 10 MHz bandwidth, but started to exhibit similar but not quite as bad behavior as shown in my above screenshots when I tried to increase to 30 MHz and then even 20 MHz bandwidth. At the bladeRF prompt it the probe command was showing "USB Bus: 3" but listed it as "high speed".

I saw similar behavior with a very long Amazon cable, while working with a USB 3 device at my dayjob. I can't recall what the max length is...3 meters? Googling around, I've seen people have trouble with longer cables too...

I can't say that I'm terribly surprised though... things like cable length generally do play a very important role in high-speed busses. Throw in the fact that the two cables you connected may have had different impedance characteristics and you have a recipe for trouble. (Granted, I'm just grasping at straws here - I know very little about the USB 3.0 PHY layer.)

Ironically after completing the file changes noted above, just now even plugged into a USB 2.0 port it is showing now as "USB Bus: 3". So uh....I'm confused! I expect at the very least I should probably re-run the Windows installer and start fresh.

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.

The bus and address essentially describe where the device is connected in the topology of the USB system. (Quick reference)

On the following posts, feel free to lean toward including more info than less (e.g., you can post the whole 'info' output) -- we all might make note of some other small detail that isn't readily obvious as being different/suspicious.

Thanks to all for the continued help; of all of this I find the increased length of the cable causing different results when plugged into a USB 3.0 port of the most interest....

We'll get you up and running, one way or another. And as I mentioned before, future efforts are looking to provide nice clean solution, rather than the work around we're discussing here.

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

[jynik]

I thought Super Bowl was yesterday? I'll look at the bladeRF code I have and see if I can make this setting an option. Will report back or something...

Until either a libusb fix is pushed or our new backend is in place, I think we'll need to expose some sort of opt-in workaround in libbladeRF. I don't think there's really a nice knob for you here that you could bake into SDR-Radio, so we'll have to put something in for this. However, I don't want to taint the API with workaround-related stuff...as that's quite gross.

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.

[scancapecod]

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

[jynik]

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.

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

[scancapecod]

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

[jynik]

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.

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.

[scancapecod]

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