Windows Driver and USB Issues

[jynik]

Hi Serge,

By design, you should not to change your code (or transmit data) to account for the different backend, so I think all is well there.

From what you, Brian, and I have discussed in this thread, it sounds like both libusb and the Cypress driver work on other machines, but not this one, correct? What is the USB 3 controller on the machine that's exhibiting this issue? (Specifically, what make and model?)

In terms of the versions you've listed, I believe those should all be fine. In fact, I was using the same setup on my laptop today with the Cypress backend while testing the new MATLAB & Simulink libbladeRF bindings in Windows.

Best regards,
Jon

[sergemalo]

Hi Jon,

Thanks for the info. There must be something wrong with my driver or USB Controller.
I have a ASUS Z97-A USB 3.1 Mobo.
It has 2 USB Controllers: the one from the Intel Z97 chipset and a ASMedia XHCI 1.1 USB 3.1 controller.
I have tried both USB 3.0 ad USB 3.1 ports: No success with Cypress driver, but they work fine with libusbK driver.
The Intel USB Controller is using the generic driver from Microsoft. The Intel driver won't install on Windows 10 x64.

I will try to update my BIOS later today or tomorrow.

Best regards,
Serge

[sergemalo]

Hi all,

I have reproduced the Cyrpess driver issue I'm facing with a 3rd computer (Macbook pro, running Windows 8.1).

Here are the detailed steps I do to see that issue:
1- Install "BladeRF for Windows" from this installer:
http://www.nuand.com/windows_installers ... latest.exe
2- During the installation, select "Cyoress CyUSB3 driver"
3- Copy my files "br_script.txt" and "GPS10s.iq" to "C:\Program Files\bladeRF\x64"
4- Open a Windows command-prompt in C:\Program Files\bladeRF\x64
5- Call "bladeRF-cli.exe -s br_script.txt"

Then, no Tx is actually going on, and bladerf-cli seems hung. The binary file is 10s long, so bladerf-cli should exit after 10s.
At step #2, if I select "WinUSB" driver, then bladerf-cli runs the script as expected, Tx is going on, and it exists after 10s.

Versions are:
bladeRF> version

bladeRF-cli version: 1.2.1
libbladeRF version: 1.4.3

Firmware version: 1.8.0
FPGA version: 0.3.4

Content of the "br_script.txt":
set frequency 1575420000
set samplerate 2500000
set txvga1 -4
set txvga2 0
tx config file=GPS10s.iq format=bin
tx start
tx wait

I would like to know how I can use the Cypress Driver under Windows.
Is there anything different I should do, or another version I should use?

Best regards,
Serge

[jynik]

Hi Serge,

Base upon what you've provided, the versions of everything you're using are fine. I do not believe you have a software configuration problem.

Just to be thorough, I created 10 seconds worth of samples and followed your exact procedure using your script and locations. I have not been able to reproduce this lock-up that you're seeing on your machines.

However, one perhaps key difference here is that we generally do our testing and developing on Windows 7 machines. On the other hand, you noted being on Windows 8 machines. I'm in the process of getting a Windows 10 machine setup, and will have to see if I can resurrect a Windows 8 machine, do some re-testing there, and revisit the Cypress driver change logs and known-issues. (Perhaps there are updates to the Cypress driver for Windows 8 that we're not shipping.) I will keep you posted...

In the meantime, you could try building the latest and greatest from source, if you'd like. When configuring the build with CMake, there's a ENABLE_LIBBLADERF_SYNC_LOG_VERBOSE that one can check to enable (ON). This will compile in a lot more output into the transmit path code, and hopefully we could get some insight as to where in the code it's hanging when the Cypress backend is in use. You would just need to append -v verbose to your command-line arguments.

Best regards,
Jon

Just some other unrelated tips for you... just some things I noticed in the script.

• Use set frequency tx instead of set frequency. We've found that tuning both the RX and TX PLLs within 1 MHz of one another causes potential for signals to interfere internally in the LMS6. Therefore, if you're only TX'ing, you can ensure you avoid this by only tuning TX.
• You were not specifying the desired LPF filter bandwidth in your script -- you will probably want to do this.

[sergemalo]

Hi,

I've updated to latest-and-greatest. Here's the output from my script:
C:\bladeRF\host\build\output\Release>bladeRF-cli.exe -v debug -s br_script.txt
[DEBUG @ bladerf.c:1317] Log verbosity has been set to: 1[DEBUG @ libusb.c:431] Could not open bladeRF device: LIBUSB_ERROR_NOT_SUPPORTED
[DEBUG @ libusb.c:545] No devices available on the libusb backend.
[DEBUG @ tuning.c:82] Default tuning mode: FPGA

bladeRF-cli version: 1.2.1-git-19c7f7c
libbladeRF version: 1.4.3-git-19c7f7c

Firmware version: 1.8.1
FPGA version: 0.4.1


Using device string: cypress:device=0:18 instance=0 serial=94ea0bdd54d55619b94c592068132875
[DEBUG @ device_identifier.c:82] Device: 0:18
[DEBUG @ device_identifier.c:100] Instance: 0
[DEBUG @ tuning.c:82] Default tuning mode: FPGA


[DEBUG @ tuning.c:134] Setting TX frequency to 1575420000
Set TX frequency: 1575420000Hz


Set TX bandwidth - req: 2500000 Hz actual: 2500000 Hz


Setting RX sample rate - req: 2500000 0/1Hz, actual: 2500000 0/1Hz
Setting TX sample rate - req: 2500000 0/1Hz, actual: 2500000 0/1Hz


TXVGA1 Gain: -4 dB


TXVGA2 Gain: 0 dB

[DEBUG @ bladerf.c:345] Enable Module: TX - True
[DEBUG @ sync.c:832] sync_tx: Worker is now running.
[DEBUG @ cyapi.c:745] Non-blocking buffer submission requested, but no transfers are currently available.[DEBUG @ cyapi.c:647] Steam timed out.


We can see "No transfers are currently available". I'm using the default buffer sizes, as you can see in my script:

Code: Select all

version
open cypress:device=0:18 instance=0 serial=94ea0bdd54d55619b94c592068132875
set frequency tx 1575420000
set bandwidth tx 2500000
set samplerate 2500000
set txvga1 -4
set txvga2 0
tx config file=GPS10s.iq format=bin buffers=32 xfers=16 samples=32768
tx start
tx wait

Any idea of what is wrong?
Thanks!

[pmmeasures]

I have never tried transmitting i only use SDR#

But I do have a ASUS Z97 motherboard also and i have issues on receive with Cypress (Bizzarly works set on 40Msps but drops at lower rates))

I am ok using the Lib drivers so to be sounds like your hitting a cypress issue.

[jynik]

Serge,

I'll spend some time looking into this to determine if the underlying issue is in our codebase or in the Cypress's driver. Unfortunately, if it's the latter, there's not much we can do other than run it up the flagpole to them.

In the meantime, it might be worth sticking with the libusb driver.

Best regards,
Jon

[sergemalo]

Hi Jon,

Thanks for your feedback. I really have no clue of what's the problem.
Let me know if you want me try something on my end, it's very quick to setup.
Also, I can recompile easily libbladerf under Windows now, if you want me to try a modification in a special branch.

Regards,
Serge