Disclamer: This is a heavy complaint post.
So,
I have been watching the changes to the repository with a lot of attention, day by day.
I have read contributors battling over licence purism, not so much on real stuff.
Almost two months later, I pulled today the git archive to see if I can do something with the two boards I have.
Well, turns out I cannot.
On Linux Ubuntu 13.10 64-bit (it should be the optimal platform!!) bladerf-cli has still the problems it had back then.
It even fails the "info" command because of incompatibility with the library API.
Thus, a newbie is not even capable of following the Linux start-up guide. Well done.
On Windows, bladeRF is not detected on my USB3.0 ports (although it correctly enumerates as libusbx device).
Ok, could be a host problem.
In fact on USB2.0 ports bladeRF is detected but transmission stops (and coherently the "tx" command reports "idle") after less than a second, no matter the "samplerate".
It's been 6 months since I have these boards and I wasted a lot of time following upgrades that eventually seem to change errors, not fix them.
I do not want to spend half a day on each machine I use bladeRF on, just to download, compile and install GnuRadio from GIT (yes, because the repository version is not good of course).
I do not understand why I need 5 Gigabytes of software-maze plus the Osmocom driver to use the minimal set of features that one would expect from the Nuand product:
1) receive without missing samples, with I being in-phase and Q being quadra-phase (consistently)
2) transmit, as above
3) full duplex communication
Since nobody else seems to be complaining, I am either stupid (could be) or the moderator is making up this forum.
Guys! Please provide a minimum working set of software for the boards, even if constrained to a specific platform host, OS, PC or whatever.
In any (other) Company this should be priority number 1.
Disregards,
Michele
Frustration
-
bobdvb
- Posts: 2
- Joined: Fri Mar 01, 2013 4:22 am
- Location: London
Re: Frustration
I don't have much to contribute to the above except to say that I second most of these comments.
I am an engineer, not a programmer, and I invested in bladeRF because I really wanted a diagnostic tool with great potential. Currently it sits at the side of my desk waiting for me pluck up the courage to try again.
On my Windows 7 laptop it is quite hit and miss as to if the board will be recognised today, on USB3.0 today is never (the board connects but bladerf-cli doesn't find it). I was happy to see SDRConsole (SDR-Radio V2) become available but this is really a tool for hams and there must be some mystery to it because I've only had it working once.
I'm holding out, I am holding out for the "Work in progress" items on the Nuand homepage, because I really want a decent spectrum analyser and frankly I would pay handsomely for that software if it was like a real piece of RF test equipment (think R&S or Agilent) instead of a radio scanner. I am now building my own home lab after years at well funded companies, so while I can't afford the likes of Agilent, I do aspire to recover some of the capabilities I once had.
Bob
I am an engineer, not a programmer, and I invested in bladeRF because I really wanted a diagnostic tool with great potential. Currently it sits at the side of my desk waiting for me pluck up the courage to try again.
On my Windows 7 laptop it is quite hit and miss as to if the board will be recognised today, on USB3.0 today is never (the board connects but bladerf-cli doesn't find it). I was happy to see SDRConsole (SDR-Radio V2) become available but this is really a tool for hams and there must be some mystery to it because I've only had it working once.
I'm holding out, I am holding out for the "Work in progress" items on the Nuand homepage, because I really want a decent spectrum analyser and frankly I would pay handsomely for that software if it was like a real piece of RF test equipment (think R&S or Agilent) instead of a radio scanner. I am now building my own home lab after years at well funded companies, so while I can't afford the likes of Agilent, I do aspire to recover some of the capabilities I once had.
Bob
-
drmpeg
- Posts: 62
- Joined: Fri Mar 01, 2013 3:58 am
- Location: Silicon Valley
- Contact:
Re: Frustration
An SDR is not the best choice since you'll need to perform your own calibration (and at many frequencies). May I suggest:bobdvb wrote:...because I really want a decent spectrum analyser...
Bob
http://www.rigolna.com/products/spectrum-analyzers/
EDIT: I see you're in London, so a better link would be:
http://www.eu.rigolna.com/products/spectrum-analyzers/
Ron
-
bpadalino
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Frustration
I am sorry for the frustration you're feeling, and I hope you understand I am sincere when I say I really do appreciate your support.
Our goal and intentions are to provide a light weight library to access the RF spectrum. We've spent the vast majority of our main development time trying to get easy access for those who like to use GNU Radio as well as those who wish to just use a command line. You do not need to use GNU Radio, but, as of right now, if you want to display spectrum in real time then GNU Radio with fosphor is the best option. Please see this video of people currently using both of those together at 40Msps for a simple spectrum analyzer.
I agree that Ubuntu linux should work since that is what I have been using for development on multiple machines.
Michele - if you don't mind, could you elaborate a bit on the info command not working correctly? It might be that you're suffering from some old or stale libraries sitting around which are being linked against instead of the new ones. You might also be suffering from old firmware on the device itself.
I'd love to help you remedy the situation. I do believe, for Ubuntu, the device should be working well. You should be able to use the bladeRF-cli and baudline to examine the spectrum you're receiving.
I am sorry that you have such a high level of frustration, and I hope you believe me that we are working tirelessly to make things better. We have not delivered on everything but we absolutely plan on continual improvements.
If I have not addressed anything in particular, please feel free to keep us honest and post more questions, comments or rants. We want your feedback - both positive and negative.
Please let me know what issue you're having with the CLI as that should be your go-to tool for testing and exercising the hardware. GNU Radio is not a requirement.
Brian
Our goal and intentions are to provide a light weight library to access the RF spectrum. We've spent the vast majority of our main development time trying to get easy access for those who like to use GNU Radio as well as those who wish to just use a command line. You do not need to use GNU Radio, but, as of right now, if you want to display spectrum in real time then GNU Radio with fosphor is the best option. Please see this video of people currently using both of those together at 40Msps for a simple spectrum analyzer.
I agree that Ubuntu linux should work since that is what I have been using for development on multiple machines.
Michele - if you don't mind, could you elaborate a bit on the info command not working correctly? It might be that you're suffering from some old or stale libraries sitting around which are being linked against instead of the new ones. You might also be suffering from old firmware on the device itself.
I'd love to help you remedy the situation. I do believe, for Ubuntu, the device should be working well. You should be able to use the bladeRF-cli and baudline to examine the spectrum you're receiving.
I am sorry that you have such a high level of frustration, and I hope you believe me that we are working tirelessly to make things better. We have not delivered on everything but we absolutely plan on continual improvements.
If I have not addressed anything in particular, please feel free to keep us honest and post more questions, comments or rants. We want your feedback - both positive and negative.
Please let me know what issue you're having with the CLI as that should be your go-to tool for testing and exercising the hardware. GNU Radio is not a requirement.
Brian
-
bobdvb
- Posts: 2
- Joined: Fri Mar 01, 2013 4:22 am
- Location: London
Re: Frustration
Ron, I know, I would like a Rigol, all I need now is €3000drmpeg wrote:An SDR is not the best choice since you'll need to perform your own calibration (and at many frequencies). May I suggest:bobdvb wrote:...because I really want a decent spectrum analyser...
Bob
http://www.rigolna.com/products/spectrum-analyzers/
EDIT: I see you're in London, so a better link would be:
http://www.eu.rigolna.com/products/spectrum-analyzers/
Ron
For what I want to do, general spectral viewing and individual carrier analysis I don't consider calibration to be that important.
Bob
-
dsalomon
- Posts: 25
- Joined: Fri Jul 19, 2013 4:56 pm
Re: Frustration
Nuand -
Sorry to pile on here, but I'm in the same boat and need to provide a little more input to the team.
I was using my BladeRF successfully under Windows 7 64-bit and Windows 8 64-bit connected via USB3 with SDR-Console for a short time. At some point (exact time unknown), it stopped working under USB3 entirely. What changed? The firmware changed, and my driver versions changed, and my USB3 board firmware changed.
I have 3 different USB3 connectivity choices - my laptop with an Intel USB3 chipset (Win 8), and my desktop with 2 cards: ASMedia based and Via based (Win 7). Initially, the board worked great on the Intel and ASMedia connections. I had USB3 speeds and could get a 40MHz bandwidth. It never worked on the Via chipset board.
Today, the board is still recognized by the OS on all 3 devices, i.e. it shows up properly in device manager. However, the CLI doesn't recognize it. On the Intel chipset, the CLI recognizes the board, but only at USB2 speed. On the 2 desktop boards, the CLI doesn't recognize it at all. It works fine on all my USB2 connections, but I can get only about 4-6 MHz bandwidth.
I've been getting advice to downgrade my USB3 board drivers/firmware and/or use a different LibUSBk driver version. To be blunt, that's just crap. While I understand that USB3 is still fairly new territory, this board needs to "just work" on USB3...at USB3 speeds.
You guys need to understand that users ARE going to update their drivers and firmware. The FX3 firmware needs to be written in a manner that will connect regardless of driver version. If the PC enumerates the BladeRF, then the firmware must work with it.
While I appreciate the suggestions I get from various people on irc.freenode.net, they are just that, suggestions. Where's the support from Nuand? Where are the updates to the user base that you recognize there are issues and are working on them? Where are the updates showing what the status is of the issue resolution?
I cannot speak for any users other than myself, but for me, you're not doing good enough. Your people on freenode have asked me to test with various versions of the FX3 firmware. I've done that and am willing to continue helping with the testing effort (as I assume are many other people). However, I need more consistent communication. I need feedback that something is being done. I need to know that Nuand is behind this, not just a volunteer or two on freenode. And, by the way, I expect that a typical user is not hanging around on freenode monitoring to see what's going on. You need to be more active on this board and provide more communication.
Sincerely - David Salomon
Sorry to pile on here, but I'm in the same boat and need to provide a little more input to the team.
I was using my BladeRF successfully under Windows 7 64-bit and Windows 8 64-bit connected via USB3 with SDR-Console for a short time. At some point (exact time unknown), it stopped working under USB3 entirely. What changed? The firmware changed, and my driver versions changed, and my USB3 board firmware changed.
I have 3 different USB3 connectivity choices - my laptop with an Intel USB3 chipset (Win 8), and my desktop with 2 cards: ASMedia based and Via based (Win 7). Initially, the board worked great on the Intel and ASMedia connections. I had USB3 speeds and could get a 40MHz bandwidth. It never worked on the Via chipset board.
Today, the board is still recognized by the OS on all 3 devices, i.e. it shows up properly in device manager. However, the CLI doesn't recognize it. On the Intel chipset, the CLI recognizes the board, but only at USB2 speed. On the 2 desktop boards, the CLI doesn't recognize it at all. It works fine on all my USB2 connections, but I can get only about 4-6 MHz bandwidth.
I've been getting advice to downgrade my USB3 board drivers/firmware and/or use a different LibUSBk driver version. To be blunt, that's just crap. While I understand that USB3 is still fairly new territory, this board needs to "just work" on USB3...at USB3 speeds.
You guys need to understand that users ARE going to update their drivers and firmware. The FX3 firmware needs to be written in a manner that will connect regardless of driver version. If the PC enumerates the BladeRF, then the firmware must work with it.
While I appreciate the suggestions I get from various people on irc.freenode.net, they are just that, suggestions. Where's the support from Nuand? Where are the updates to the user base that you recognize there are issues and are working on them? Where are the updates showing what the status is of the issue resolution?
I cannot speak for any users other than myself, but for me, you're not doing good enough. Your people on freenode have asked me to test with various versions of the FX3 firmware. I've done that and am willing to continue helping with the testing effort (as I assume are many other people). However, I need more consistent communication. I need feedback that something is being done. I need to know that Nuand is behind this, not just a volunteer or two on freenode. And, by the way, I expect that a typical user is not hanging around on freenode monitoring to see what's going on. You need to be more active on this board and provide more communication.
Sincerely - David Salomon
-
dk5ras
- Posts: 70
- Joined: Fri Mar 01, 2013 3:23 am
Re: Frustration
I had very similar problems, but they all were gone when I wiped the board, wiped all (!) bladeRF remains from the PC, reprogrammed the bladeRF with the latest fx3 image, using the Cypress tools, then loading latest fpga image, installed drivers and cli, flashed the latest fpga image to SPI EEPROM using latest bladeRF-cli.
From this moment everything was fine, it just works.
This is an experimental board, with experimental software and firmware, and all bugs and issues I had reported to Brian got solved within shortest time. I have not very often experienced such great support like with the bladeRF.
Ralph.
From this moment everything was fine, it just works.
This is an experimental board, with experimental software and firmware, and all bugs and issues I had reported to Brian got solved within shortest time. I have not very often experienced such great support like with the bladeRF.
Ralph.
-
dsalomon
- Posts: 25
- Joined: Fri Jul 19, 2013 4:56 pm
Re: Frustration
Ralph -
Been there, done that, got the t-shirt. Didn't help.
Been there, done that, got the t-shirt. Didn't help.
-
bpadalino
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Frustration
Thanks for being honest and frank with us, David. I know our support on Windows has been relatively mediocre and I don't blame anyone but ourselves, especially my lack of how to use libusb on Windows properly.
The only thing I can recommend is making sure the example programs with libusb can see the device VID/PID. I don't know what stops libusb from seeing that, but there is a way to let libusb be verbose about what it's seeing. Does the device show up under libusbK devices or as something else? The best I can do is say to check with the libusb-win32 documentation.
I'm truly sorry the support has been lacking for Windows. When we follow the wiki, we have had a lot of users claim success. I just don't know what diverges between those with success and those with failures.
One last ditch effort, have you tried a different USB cable? Can you try booting a linux livecd and plugging the device in to see if it shows up as high speed or superspeed?
Brian
The only thing I can recommend is making sure the example programs with libusb can see the device VID/PID. I don't know what stops libusb from seeing that, but there is a way to let libusb be verbose about what it's seeing. Does the device show up under libusbK devices or as something else? The best I can do is say to check with the libusb-win32 documentation.
So, from the perspective of the FX3 - if it is being shown in device manager, then the system sees it. Why libusb can't - I have no clue? Quite honestly, I just don't know why it would break like that. Was there a recent Windows update to their xhci that overwrote some of the filtering rules that maybe libusb added?dsalomon wrote:I've been getting advice to downgrade my USB3 board drivers/firmware and/or use a different LibUSBk driver version. To be blunt, that's just crap. While I understand that USB3 is still fairly new territory, this board needs to "just work" on USB3...at USB3 speeds.
You guys need to understand that users ARE going to update their drivers and firmware. The FX3 firmware needs to be written in a manner that will connect regardless of driver version. If the PC enumerates the BladeRF, then the firmware must work with it.
I'm truly sorry the support has been lacking for Windows. When we follow the wiki, we have had a lot of users claim success. I just don't know what diverges between those with success and those with failures.
One last ditch effort, have you tried a different USB cable? Can you try booting a linux livecd and plugging the device in to see if it shows up as high speed or superspeed?
Brian
-
bpadalino
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Frustration
I guess the last small thing to mention would be regarding the tracking of issues and problems.
The most public and best trackable way to do this is using the issues section of github. We track source code, pull requests, resolution of issues, etc all using that.
We try to, at least.
Brian
The most public and best trackable way to do this is using the issues section of github. We track source code, pull requests, resolution of issues, etc all using that.
We try to, at least.
Brian
-
dsalomon
- Posts: 25
- Joined: Fri Jul 19, 2013 4:56 pm
Re: Frustration
One more bit of info...
On my laptop with the Intel USB3 chipset, absolutely nothing changed EXCEPT the BladeRF firmware. Same USB3 driver, same libusbk driver, different BladeRF firmware. Worked at USB3 speed before, drops back to USB2 speed now.
So, this can't be a USB3 driver problem, and it can't be a libusbk problem. It MUST be a FX3 firmware problem. That's the ONLY thing that changed in that environment.
On my laptop with the Intel USB3 chipset, absolutely nothing changed EXCEPT the BladeRF firmware. Same USB3 driver, same libusbk driver, different BladeRF firmware. Worked at USB3 speed before, drops back to USB2 speed now.
So, this can't be a USB3 driver problem, and it can't be a libusbk problem. It MUST be a FX3 firmware problem. That's the ONLY thing that changed in that environment.
-
bpadalino
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Frustration
OK - I'm willing to accept that. We have the different FX3 firmware to download and try, but I believe you tried to reflash everything and it still shows up as being high speed instead of Superspeed? Telling us which firmware works as Superspeed versus High Speed would be crucial in understanding where to look in the firmware code. But maybe now it seems it's always High Speed all the time? That's why I was wondering if a different cable might help? How often do you plug/unplug? I wonder if there has been a stress somewhere either in the cable itself or on the connector causing a flaky differential pair for Superspeed?
The github history for the FX3 firmware doesn't have anything that really pops out at me.
Do you run automatic updates on that machine? Has the Windows XHCI driver been updated inbetween that time? Do the libusb-win32 example programs show the device in the device listing?
Brian
The github history for the FX3 firmware doesn't have anything that really pops out at me.
Do you run automatic updates on that machine? Has the Windows XHCI driver been updated inbetween that time? Do the libusb-win32 example programs show the device in the device listing?
Brian
-
schrambo
- Posts: 16
- Joined: Sat Mar 02, 2013 1:33 am
- Location: Perth, Western Australia
Re: Frustration
I think the people here complaining about the "lack" of support and features have got the whole wrong idea behind this project and really didn't think hard enough as to what they were getting themselves into.
As I see it, the bladeRF is a development / test unit, built by an upstart company. For development enthusiasts of RF, software and hardware. Us the users were or should be expecting to at least have a bit of an uphill battle with implementing features, testing software etc. Half the fun is the journey of getting there. If i wanted something that works straight out of the box with 100% working functions and features, I would have purchased something off the shelf. (How boring!)
And as far as the support side of things go. Well.. in the world of FOSS projects and endeavors. 99% of the people who are giving out help and support are the users themselves and not the actual developers or employees. So I don't really see what the complaint is about here because that's the nature of how FOSS projects work. The people who are serious and passionate about the project generally are the users themselves and the best way they can find to help the project out. Is to help others. If we relied and expected Nuand to do everything for us. well It may as well be a closed source and proprietary owned.
The only suggestion I can make is that maybe update the blog site a bit more, maybe have a weekly news roundup on current project trends etc. But keep it up Nuand, you are very much still loved by me.
As I see it, the bladeRF is a development / test unit, built by an upstart company. For development enthusiasts of RF, software and hardware. Us the users were or should be expecting to at least have a bit of an uphill battle with implementing features, testing software etc. Half the fun is the journey of getting there. If i wanted something that works straight out of the box with 100% working functions and features, I would have purchased something off the shelf. (How boring!)
And as far as the support side of things go. Well.. in the world of FOSS projects and endeavors. 99% of the people who are giving out help and support are the users themselves and not the actual developers or employees. So I don't really see what the complaint is about here because that's the nature of how FOSS projects work. The people who are serious and passionate about the project generally are the users themselves and the best way they can find to help the project out. Is to help others. If we relied and expected Nuand to do everything for us. well It may as well be a closed source and proprietary owned.
The only suggestion I can make is that maybe update the blog site a bit more, maybe have a weekly news roundup on current project trends etc. But keep it up Nuand, you are very much still loved by me.
-
dsalomon
- Posts: 25
- Joined: Fri Jul 19, 2013 4:56 pm
Re: Frustration
More details on my USB 3.0 problems for you guys...
I got a new USB 3.0 PCI Express board today. This one has a Renasys chipset (http://www.amazon.com/gp/product/B00AXJ ... UTF8&psc=1).
Once I got the board installed and the drivers loaded, the BladeRF worked perfectly with it at full bandwidth/speed using SDR-Console on Windows 7 64-bit.
I still cannot get it to work with my 3 other USB 3.0 cards:
VIA VL800 (http://www.amazon.com/gp/product/B00871 ... UTF8&psc=1)
ASMedia 104x (Asus P9X79PRO motherboard)
Intel (USB 3.0eXtensible Host Controller - 100)
Despite what some others are saying about my expectations, I still expect that if the OS enumerates the BladeRF and it shows OK in Device Manager then the software should work with it. I do not think this is an unreasonable expectation.
If there is anything I can do to work with anyone to provide testing results, debugging, etc. please let me know. I work from home and am here most of the time. I'm happy to help in any way I can most any time.
73 - David, AG4F
I got a new USB 3.0 PCI Express board today. This one has a Renasys chipset (http://www.amazon.com/gp/product/B00AXJ ... UTF8&psc=1).
Once I got the board installed and the drivers loaded, the BladeRF worked perfectly with it at full bandwidth/speed using SDR-Console on Windows 7 64-bit.
I still cannot get it to work with my 3 other USB 3.0 cards:
VIA VL800 (http://www.amazon.com/gp/product/B00871 ... UTF8&psc=1)
ASMedia 104x (Asus P9X79PRO motherboard)
Intel (USB 3.0eXtensible Host Controller - 100)
Despite what some others are saying about my expectations, I still expect that if the OS enumerates the BladeRF and it shows OK in Device Manager then the software should work with it. I do not think this is an unreasonable expectation.
If there is anything I can do to work with anyone to provide testing results, debugging, etc. please let me know. I work from home and am here most of the time. I'm happy to help in any way I can most any time.
73 - David, AG4F
-
jynik
- Posts: 455
- Joined: Thu Jun 06, 2013 8:15 pm
Re: Frustration
I'd be particularly interested to get some verbose logs from those 3 cards where the OS detects the bladeRF, but the bladeRF-cli does not. If you have a chance to grab the latest commit (d24bf009a7d2), and post some logs as shown below, I think that could give us some clues as to what's going on.dsalomon wrote: If there is anything I can do to work with anyone to provide testing results, debugging, etc. please let me know.
To get the most of out the debug logs, configure the build by passing a -DENABLE_LOG_FILE_INFO=ON to CMake. This will include the source file and line number for output messages.
If you could provide the verbose output for a bladeRF-cli probe and an attempt at entering interactive mode (which should attempt to open the first available bladeRF) for as many cards as you'd like, that'd be appreciated. Below are some samples from my machine.
Code: Select all
$ bladeRF-cli -p -v verbose
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 04f2, PID b2eb
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 0a5c, PID 21e6
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 147e, PID 2020
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:2048] Found bladeRF (based upon VID/PID)
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:2061] Added instance 0 to device list
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0003
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0002
Backend: libusb
Serial: 00000000000000000000000000000000
USB Bus: 4
USB Address: 2
$ bladeRF-cli -i -v verbose
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:544] Using libusb version: 1.0.16.10774
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 04f2, PID b2eb
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 0a5c, PID 21e6
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 147e, PID 2020
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:273] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:552] Found a bladeRF (based upon VID/PID)
[DEBUG @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:489] FPGA currently does not have a version number.
[VERBOSE @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:668] Claimed all inferfaces successfully
[DEBUG @ /home/jon/projects/bladeRF/host/libraries/libbladeRF/src/bladerf.c:137] bladerf_open_with_devinfo: fw=v1.5.3-git-276379e serial=00000000000000000000000000000000 trim=0x8100 fpga_size=40
bladeRF>
There's a number of folks around the IRC channel who have quite a bit more knowledge and experience than myself on the Windows side of things. I know there's been some talk of patching libusbx to address some issues with certain controllers in Windows. If I remember correctly, there was some issues with a(n ASMedia?) card opening devices because of a hub driver reporting a device's port incorrectly...but I may be wrong.
At any rate, it might be very beneficial to ask around and see if we can get some get some collective discussions and debug sessions going on for some of these failing configurations.
Thanks,
Jon