Getting the A9 rolling in Windows

Having issues with the site, hardware, source code, or any other issues?

Moderator: robert.ghilduta

Post Reply
mawelsh
Posts: 4
Joined: Mon Aug 13, 2018 12:06 pm

Getting the A9 rolling in Windows

Post by mawelsh » Tue Aug 14, 2018 3:26 pm

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.

mawelsh
Posts: 4
Joined: Mon Aug 13, 2018 12:06 pm

Re: Getting the A9 rolling in Windows

Post by mawelsh » Tue Aug 14, 2018 6:40 pm

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?
Last edited by mawelsh on Wed Aug 15, 2018 5:14 am, edited 2 times in total.

robert.ghilduta
Posts: 30
Joined: Thu Feb 28, 2013 11:14 pm

Re: Getting the A9 rolling in Windows

Post by robert.ghilduta » Tue Aug 14, 2018 6:46 pm

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

robert.ghilduta
Posts: 30
Joined: Thu Feb 28, 2013 11:14 pm

Re: Getting the A9 rolling in Windows

Post by robert.ghilduta » Tue Aug 14, 2018 6:50 pm

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

mawelsh
Posts: 4
Joined: Mon Aug 13, 2018 12:06 pm

Re: Getting the A9 rolling in Windows

Post by mawelsh » Wed Aug 15, 2018 5:12 am

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?

robert.ghilduta
Posts: 30
Joined: Thu Feb 28, 2013 11:14 pm

Re: Getting the A9 rolling in Windows

Post by robert.ghilduta » Thu Aug 16, 2018 1:35 am

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 .

Post Reply