Windows Driver and USB Issues

[sergemalo]

Hi All,

I am testing the BladeRF on different computers, and I observe different performance results, depending on the computer.
So far, newer computers with Windows 8 or 10 performed well, I was able to Tx over USB 3.0 at 25MSPS without drops, using the libusbK driver.
(MacbookPro, ASUS Z97)

On older computers, its a different story.
Some of them would only see the bladeRF when using the Cypress Driver. But using Cypress driver, the Tx would timeout.

Q1: Is there a general recommendation between Cypress and libusbK driver on Windows?
Q2: Is it possible to get good performances (25MSPS) under Windows 7 and USB 3.0, with a 4-5 year old computer (Intel core i5/i7 of 2nd/3rd generation)? Any rule-of-thumb/general guideline would be appreciated!

Best regards,
Serge

[sergemalo]

I forgot to mention:
I'm using libbladeRF 2015.07 and firmware 1.8.0

[bpadalino]

I think the Cypress driver typically works a little better, but jynik knows for sure.

It typically comes down to the XHCI performance and which one you're using. You can check the working configurations on the wiki and see if one of the USB controllers that is in that system is also listed there.

Typically the Intel controllers do best and are the gold standard.

Are you using default buffering configurations? TX timing out definitely sounds very bad. You're just taking a file and using the CLI to try to transmit it at 25Msps?

[jynik]

It definitely would be good to identify what USB 3 controller(s) are on the systems that are not performing well. I've been happy with the Intel series 8 and 9 controllers. In my experience with the bladeRF and other USB 3 devices, there are some controllers on older machines that did an absolutely horrible job with USB 3.

Also, you noted using libusbK. When using Zadig, try using the WinUSB option instead. I've seen significant differences reported between the two.

On the machine that couldn't see the bladeRF with libusb, and would only timeout using the Cypress Driver -- it sounds like there's a larger problem here and more information about it would be good to hear.

Best regards,
Jon

[sergemalo]

Hi all,

Thanks for the information.
There is certainly something wrong in my side when using the Cypress Driver, it times out during the first samples transfer. I'm not using the default buffer size, but it is a multiple of 1024. I will try different values tomorrow and give you the results. I will focus on that first.

The controller that is giving me a hard time is a Renesas Electronics USB 3.0 Controller. It is installed on my Intel DH67BL M/B.

Thanks again,
Serge

[jynik]

Hi Serge,

Just wanted to try to give you a few additional thoughts and items that you can look into...

It might be good to track down the exact model of the Renesas controller, and do some searches online pertaining its compatibility with the Cypress FX3 to see what turns up. (Perhaps someone on the Cypress forums has experienced similar issues?)

Back in 2013 I had a Renesas card that was giving me some serious trouble and it turned out that the card needed a firmware update.

To further isolate the issue to libbladeRF, Windows and/or the driver, or the hardware itself, I would suggest booting and trying out the GNU Radio Live SDR Environment. Once you're in that, you can see how things go with bladeRF-cli, osmocom_fft, or GQRX.

In the past when I had to deal with some problematics chipsets and the FX3, I would usually try to reproduce issues using the Cypress-provided firmware examples, and slight modifications of that. This allowed me to more easily query the Cypress community and experts, given that the problem scope could be constrained to code that everyone was familiar with.

Best Regards,
Jon

[sergemalo]

Hi,

Thanks again for the feedback.
So far, I haven't be able to use the Cypress driver correctly, even with a newer computer and the bladerf-cli. Something must be wrong on my side, I'll have to take more time to verify everything.

I have changed the number of Buffers from 500/250 to 32/16 (Default). It seems to run smoother at any sampling rates. But again, I have to run more tests.

I will also try to run on GNU-Radio Live SDR image in Linux to see if I get better results.

One question I have:
When I call bladerf_sync_tx, does it matter if I send a number of samples lower than the buffer size? Does it have an impact on performance if this number is not aligned on 1024?

Best regards,
Serge

[jynik]

Hi Serge,

Keep us posted on your Cypress backend findings. The last time I tested out the Cypress backend, it was working great with SDR# and SDR-Console, so I'm a little surprised to hear this.

One question I have:
When I call bladerf_sync_tx, does it matter if I send a number of samples lower than the buffer size? Does it have an impact on performance if this number is not aligned on 1024?

It should not matter, so long as the rate at which you're providing samples is able to sustain the stream without underruns.

The sync interface takes care of filling up a buffer (whose size you configure) and shipping it off for you. You should be able to call bladerf_sync_tx() with as few or as many samples as you'd like. If you provide a large number of samples, this call may block until it can get its samples buffered.

By the way, I just pushed a fix to master today that addresses TX underruns that we were seeing. You can find more info about this on Issue #438 on our tracker.

Best regards,
Jon

[sergemalo]

Hi Jon,

Thanks for the update regarding the Tx under-runs, I'd like to try this today.
I have tried to compile and used the latest code.
Its running fine with libusbK driver, but I still can't use Cypress the driver correctly: I always get timeouts on the bladerf_sync_tx.
Should my could be different when using Cypress vs libusbK?

I'm using:
Windows 10
fx3 image: 1.8.1
FPGA: 0.4.1
latest code from master
Cypress SDK 1.3.3
--> Cypress driver from "latest BladeRF Windows installer". Is this the driver I should use?

Best regards,
Serge

[sergemalo]

Hi Jon,

Thanks for the update regarding the Tx under-runs, I'd like to try this today.
I have tried to compile and used the latest code.
Its running fine with libusbK driver, but I still can't use Cypress the driver correctly: I always get timeouts on the bladerf_sync_tx.
Should my code be different when using Cypress vs libusbK? I suppose not.

I'm using:
Windows 10
fx3 image: 1.8.1
FPGA: 0.4.1
latest code from master
Cypress SDK 1.3.3
--> Cypress driver from "latest BladeRF Windows installer". Is this the driver I should use?

I also have reproduced the Cypress driver timeouts with bladerf-cli.
I run the attached script file perfectly with libusbK driver (10s Tx streaming)
But with Cypress driver, it seems hanging forever.
Let me know if you need the bin file I'm streaming, I can share it via Dropbox.


Best regards,
Serge

[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!