Page 1 of 1

Getting the A9 rolling in Windows

Posted: Tue Aug 14, 2018 3:26 pm
by mawelsh
Hi folks, it was a pleasure getting to meet the team at DC26 and I'm excited to have a new piece of kit. I'm stoked to see the new windows drivers went up today (2018.08-rc1) but it looks like I'm getting some libUSB access errors. Running probe both running as admin and as a standard user yields:
bladerf-cli -p -v verbose
[VERBOSE @ host/libraries/libbladeRF/src/backend/usb/libusb.c:255] Found a bladeRF
[DEBUG @ host/libraries/libbladeRF/src/backend/usb/libusb.c:304] Could not open device: LIBUSB_ERROR_ACCESS
[WARNING @ host/libraries/libbladeRF/src/backend/usb/libusb.c:309] Found a bladeRF via VID/PID, but could not open it due to insufficient permissions.
Info, Print and Open all seemed to work OK so I tried running a simple RX flow through GRC and I'm getting similar errors there.

Info:
bladeRF> info

Board: bladerf2
Serial #: xxxx
VCTCXO DAC calibration: 0x1e57
FPGA size: 301 KLE
FPGA loaded: yes
USB bus: 3
USB address: 2
USB speed: SuperSpeed
Backend: libusb
Instance: 0
GNU Radio:
Opening nuand bladeRF with device identifier string: "*:instance=0"
[DEBUG @ "Z:\\gr-build\\src-stage3\\oot_code\\bladeRF\\host\\libraries\\libbladeRF\\src\\device_identifier.c":104] Instance: 0
[VERBOSE @ "Z:\\gr-build\\src-stage3\\oot_code\\bladeRF\\host\\libraries\\libbladeRF\\src\\backend\\usb\\libusb.c":593] Using libusb version: 1.0.21.11156
[DEBUG @ "Z:\\gr-build\\src-stage3\\oot_code\\bladeRF\\host\\libraries\\libbladeRF\\src\\backend\\usb\\libusb.c":602] No devices available on the libusb backend.

FATAL: [bladeRF source] Failed to open bladeRF device *:instance=0
This is running on a Win10-1803 device that's fairly recent and all USB-c. I do have a C-A converter in the loop but it should just be a physical pass through of USB 3.1 but I'm wondering if the C/thunderbolt controllers are to blame. I'm going to try on an older desktop here in a bit to see if the results are any different but I figured I'd start a thread and see if there were any suggestions.

Re: Getting the A9 rolling in Windows

Posted: Tue Aug 14, 2018 6:40 pm
by mawelsh
It looks like it's not a USB-C problem, possibly just some kind of permissions issue on install?

I was able to successfully probe the device after:
  1. Launch the blade-cli as administrator
  2. Issuing - jump-to-boot
  3. Installing the driver for the new unrecognized westwood device. I just isntalled from the "program files\bladerf" directory and it picked the cypress driver.
  4. Issuing - recover 0 1 ./xf3_images/bladeRF_fw_v2.2.0.img
  5. Issuing - open
  6. Issuing - load ./hostedxA9.rbf
  7. Disconnecting and reconnecting.
Working through getting it going with gnuradio now. I suspect that I need to replace the existing bladerf bits with the ones from the fresh bladerf install?

Re: Getting the A9 rolling in Windows

Posted: Tue Aug 14, 2018 6:46 pm
by robert.ghilduta
Hi Mawelsh,

Just to make sure, are you using this installer? https://www.nuand.com/windows_installer ... 08-rc1.exe
It was updated earlier this morning.

While the installer ran, did you see a line for PID=5250 the driver installation part?
VIDsandPIDs.png
Also, what does the device properties say about the bladeRF if you right click it? Does it say the device is functioning correctly?
deviceproperties.png
Please right click on the bladeRF in device manager and select "update driver" and try the automatic route, if that doesn't work manually point the driver updater to C:\Program FIles\bladeRF\

Please let us know if this helps!

-Rob

Re: Getting the A9 rolling in Windows

Posted: Tue Aug 14, 2018 6:50 pm
by robert.ghilduta
Oh, if it went back to the Westbridge it means the FX3 firmware was somehow cleared out.
Before loading the FPGA image to flash, ensure that is is able to load from USB first.
To wipe the FPGA image in flash run:

Code: Select all

bladeRF-cli -L X 
To load the FPGA over USB run:

Code: Select all

bladeRF-cli -l hostedxA9.rbf -i
Please also include an output of

Code: Select all

bladeRF-cli -p

Re: Getting the A9 rolling in Windows

Posted: Wed Aug 15, 2018 5:12 am
by mawelsh
The driver was enumerating correctly, and for the most part, gnu-radio and the bladerf-cli were identifying the A9 correctly but weren't able to access it. On the initial install I chose to "update" the firmware to 2.2.0 through the installer and that seemed to go smoothly but probe was failing. The re-flash seems to have fixed it though. Now I'm just sorting through getting osmocom sync pointing to the right direction. Despite the new bladerf.lib/dll, drivers, etc, it looks like osmocom is still targeting the older generation of devices.

Code: Select all

gr-osmosdr c653754d (0.1.5git) gnuradio 3.7.12.0
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy redpitaya 
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_3.11.0.0-0-unknown
Opening nuand bladeRF with device identifier string: "*:instance=0"
 Serial # xxxx
 FW v2.2.0 FPGA v0.7.3
Automatic DC correction mode is not implemented.
Traceback (most recent call last):
  File "C:\development\gnu-radio\bladeRF_rx.py", line 582, in <module>
    main()
  File "C:\development\gnu-radio\bladeRF_rx.py", line 570, in main
    tb = top_block_cls(dc_offset_i=options.dc_offset_i, dc_offset_q=options.dc_offset_q, instance=options.instance, num_buffers=options.num_buffers, num_xfers=options.num_xfers, rx_bandwidth=options.rx_bandwidth, rx_frequency=options.rx_frequency, rx_lna_gain=options.rx_lna_gain, rx_sample_rate=options.rx_sample_rate, rx_vga_gain=options.rx_vga_gain, serial=options.serial, verbosity=options.verbosity)
  File "C:\development\gnu-radio\bladeRF_rx.py", line 292, in __init__
    self.osmosdr_source_0.set_bb_gain(gui_rx_vga_gain, 0)
  File "C:\Program Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 2511, in set_bb_gain
    return _osmosdr_swig.source_sptr_set_bb_gain(self, gain, chan)
RuntimeError: bladerf_source_c::set_gain could not set VGA2 gain: Operation not supported
Is there a new field in the osmoscom args string that will re-target or are there modifications that need to be made in osmocom to support the micros?

Re: Getting the A9 rolling in Windows

Posted: Thu Aug 16, 2018 1:35 am
by robert.ghilduta
There was a number of changes pushed to gr-osmosdr. (I assume you are building from source)
Please make sure you are at least on commit 0e068cc2bf2508fe7cee0302302a2ff57d3b8c82 in gr-osmosdr .

Re: Getting the A9 rolling in Windows

Posted: Sun Oct 28, 2018 12:58 am
by TomL
I have yet to get the blade rf a9 to work.

it had a permissions problem wich i never resolved, I was trying to get it to work in matlab with no success. OS win 10.

then i ran the jump_to_boot commannd wich seems to have made things worse. now it will not respond in the cli. it no longer appears in the device manager.

Re: Getting the A9 rolling in Windows

Posted: Mon Oct 29, 2018 11:47 am
by bglod
TomL wrote: Sun Oct 28, 2018 12:58 am I have yet to get the blade rf a9 to work.

it had a permissions problem wich i never resolved, I was trying to get it to work in matlab with no success. OS win 10.

then i ran the jump_to_boot commannd wich seems to have made things worse. now it will not respond in the cli. it no longer appears in the device manager.
TomL, you need to follow the recovery procedure that mawelsh outlined in their post (also in our wiki).

Re: Getting the A9 rolling in Windows

Posted: Tue Oct 30, 2018 5:26 pm
by rtucker
FYI: the issues with the "probe" command not working under Windows have been fixed in the latest libbladeRF. Also, the Windows installer now creates the proper mapping for the bootloader recovery mode VID/PID, so recovery can be done entirely with bladeRF-cli and without using zadig (hopefully), just like on every other OS.

You can snag a Windows installer for 2018.10-rc1 from https://www.nuand.com/win_installers/

Thanks! -rt