You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By following the guide from the wiki on how to compile bladeRF lib and tools under Windows, we are told to use libusx-1.0.18.
At least under my setup (Win8.1 64bits Intel USB3 controller), I had corrupted samples: 1 sample out of 2 was zeroed. It took me some time to figure out that the libusb-1.0.dll is the root cause of that.
I updated the wiki and adjusted the CMake LIBUSB_PATH default to libusb-1.0.19. In the future, I'll look to add some sort of warning, or just skip over libusbx entirely in the CMake module.
Closing this for now, as I think we've resolved the main issue of instructions and the defaults being out of date.
By following the guide from the wiki on how to compile bladeRF lib and tools under Windows, we are told to use libusx-1.0.18.
At least under my setup (Win8.1 64bits Intel USB3 controller), I had corrupted samples: 1 sample out of 2 was zeroed. It took me some time to figure out that the libusb-1.0.dll is the root cause of that.
Moving to the latest libusb-1.0.19 ( http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.19/ ) and recompiling bladeRF lib + tools (just in case) solved that problem.
In addition, libusbx is deprecated since January (source: http://libusbx.org/ ) as it was merged back into libusb.
It might be worth updating the wiki and also issuing a warning in CMake if trying to build against libusbx
The text was updated successfully, but these errors were encountered: