XB 200 - Firmware Update

[jynik]

Hi Simon,

I think that switching to the sync interface would be a great idea, even if the async i/f was working fine for the following reasons:

It's simpler to use and maintain.
If you don't need to really have full control over buffer management for very low-latency, the extra complexity doesn't buy you much. The sync interface spawns a worker thread under the hood to take care of all the buffer management. You can just call it and receive and arbitrary number of samples.

It's more foregiving.
With the async interface, you cannot do any heavy processing or major I/O in the callbacks without risking losing samples, especially with higher sample rates. With the sync interface, you have N buffers worth of time to read out and process your data before you hit an overrun.



With respect to the async issues you're seeing...

The major changes since the last version you were using largely consisted of holding a per-device lock while executing a callback, which would prevent two simultaneous RX or TX callbacks from occurring during full-duplex operation.

Are you doing any substantial processing or other operations in the callbacks? I'm wondering if you just happened to have ample time previously, but the aforementioned change someone resulted in a smaller window of time? Based upon the screenshot and obeservations you shared...it really sounds like the symptoms I've seen where buffers are getting dropped.

The wiki describes a way to use the CLI to check for dropped samples by having the FPGA replace samples with a 32-bit counter value, as Brian noted. This might be a good "sanity check" to perform along with the other tests I mentioned a few posts back.

Note that the sync interface is built atop of the async interface -- if there's something very wrong with the async interface, the former will not work. Any info (e.g., verbose logs) you can provide from async failures would help us to diagnose issues that we may not be currently exposing in our tests.

Lastly, I apologize if you feel that we're not giving you enough time this weekend, and can understand any frustration. We're really trying to squeeze 50 hours into 48 in order to get some tasks completed and work toward a stable release. If you continue having problems, one or more of us devs can schedule a Skype call sometime next week. (Bear in mind, a number of us work dayjobs until 6-7 Eastern Time, so we'll probably need to set up something in the early morning for us, or very late for you.)

With that said, I personally find that I can generally only be useful and helpful when I'm given sufficient information to review and understand ahead of time, such as verbose logs, code snippets, etc.

Best regards,
Jon

[SDR-Radio.com]

Jon,

A problem for both of us is that you will not necessarily see any bugs in your own code unless you write or at least modify a rudimentary waterfall / demodulator program as a proof of concept. It is a massive help when the hardware guys have their own small program, this is almost always available.

Anyway, I hope to have the synchronous interface in place this evening, if this doesn't work with the same defaults that are used in your test software I'll just put the bladeRF to one side for a while and get on with the hackRF and the many other SDR radios I've been asked to support.

And the garden, must get into the back garden, there are 'things' living there...

[jynik]

Hello Simon,

A problem for both of us is that you will not necessarily see any bugs in your own code unless you write or at least modify a rudimentary waterfall / demodulator program as a proof of concept. It is a massive help when the hardware guys have their own small program, this is almost always available.

We generally use GNU Radio via the gr-osmosdr driver and related programs (e.g., GQRX) and flow graphs to perform such testing. So, for what it's worth, that code isn't going entirely untested in some crazy manner. Granted, I know this doesn't help you much on the Windows side of things. What you've described sounds like RX buffer overruns -- I'll continue looking for any bugs that may cause or exacerbate this on our end.

We definitely plan on getting some samples and demos into the codebase -- a crude waterfall and some simple demod programs are reasonable requests. A number of devs and community members have really enjoyed working (and have done some awesome stuff) with LiquidDSP, so we'll likely go that route with examples. From my understanding, this library is very lightweight and is now building nicely on Windows.

Anyway, I hope to have the synchronous interface in place this evening, if this doesn't work with the same defaults that are used in your test software I'll just put the bladeRF to one side for a while and get on with the hackRF and the many other SDR radios I've been asked to support.

That sounds totally reasonable to me -- there's no doubt that your time is limited and you have to a lot of radios to support. You must do what's best for yourself and your community.

If you want to mess around with some other buffer/transfer configurations, here are a few. For what it's worth, when using GQRX in Linux, I usually have it set to 128 buffers with 16-20 transfers, and do not run into any issues with audio breaking up.

• 16 buffers, 8 transfers
• 32 buffers, 8 transfers
• 32 buffers, 16 transfers
• 64 buffers, 8 transfers
• 64 buffers, 16 transfers
• 64 buffers, 32 transfers
• 128 buffers, 16 transfers
• 128 buffers, 16 transfers

In the meantime, in addition to the aforementioned waterfall test, is there some way we or other members of the community can be more proactive about getting some "drop-in" code to you? When possible, we like to try to submit patches to projects, or provide implementations of desired interfaces or classes.

And the garden, must get into the back garden, there are 'things' living there...

Best of luck! If any plants become sentient and start singing "feed me", run away!!!

Regards,
Jon

[SDR-Radio.com]

Hi,

The result with the synchronous interface is identical - please see the asynchronous screenshot I posted on page 1. I've also listed all the information I have which shows you the image / fpga version. The result is the same at 420MHz with and without the XB 200 board. Are you possibly using a newer or somehow different version of LibUSB.

For the time being I will remove bladeRF support until we find out what's wrong.

You can call me any time on SKYPE, I'm sdr-radio.com .

[jynik]

Hi Simon,

Are you possibly using a newer or somehow different version of LibUSB.

You would have selected your desired libusb version when you build the code from source via the LIBUSB_PATH parameter in the CMake GUI, so it should be a quick test to switch to an earlier or later version.

For what it's worth, in another thread jump reported that he was seeing something potentially similar, which he tracked down to being a libusb issue that went away when he upgraded to 1.0.19. Here is a link to libusb 1.0.19 binaries.

I guess we'll have to see if anything comes up in the meantime. Until then, any information you can provide that I've asked about earlier in this thread (e.g., looking for gaps in samples via the FPGA counter) could help expedite things. That screenshot doesn't really give us much to go on; like I've said, it looks like it might be symptomatic of RX overruns. Until we have a good handle on what exactly is going on with the samples you're getting, I'm afraid I won't have any more answers on a Skype call -- just more questions.

- Jon

[bpadalino]

Hi Simon,

To help figure out the problem, can you set the verbosity of the logging to debug in the library itself and give us the output? It could potentially contain such useful information as:

[DEBUG] sync_rx: Worker is idle. Going to reset buf mgmt.
[DEBUG] sync_rx: Reset buf_mgmt consumer index
[DEBUG] sync_rx: Worker is now running.
[DEBUG] RX overrun @ buffer 6
[DEBUG] RX overrun @ buffer 1
[DEBUG] RX overrun @ buffer 28
[DEBUG] RX overrun @ buffer 14
[DEBUG] RX overrun @ buffer 11
[DEBUG] RX overrun @ buffer 30
[DEBUG] RX overrun @ buffer 29

If that is happening, you'll have discontinuities everywhere. Also, are you doing this with an XB-200 attached or only the bare bladeRF? What are your gains set at when you see the issue? Can you try setting the output of the FPGA to be the 32-bit counter mode and see if you get discontinuities?

I want to rule out and see if it is a way in which the samples are getting to your host, or if it is a problem in the way the LMS part is being configured.

Brian

[bpadalino]

Going back through your logs I see that you end up setting RXVGA1 to 30dB and RXVGA2 to 20dB. It's recommended in the LMS6002D FAQ in section 5.18 to remove gain from RXVGA2 followed by RXVGA1 followed by the LNA. Can you try to ensure you remove gain in such a fashion? I've seen some interesting things happen when the gain stages are in weird configurations.

Brian

[bpadalino]

One last thing - the screen shot you posted says the LPF is bypassed which you should not do unless you are already bandlimiting your input signal at the RF input.

The log states the LPF is in Normal mode.

Do you notices differences when you have it bypassed versus in normal mode?

Brian

[SDR-Radio.com]

Jon,

FWIW there are no problems with data overruns or underruns, the data is streaming perfectly.

[SDR-Radio.com]

Hi Simon,

To help figure out the problem, can you set the verbosity of the logging to debug in the library itself and give us the output? It could potentially contain such useful information as:

[DEBUG] sync_rx: Worker is idle. Going to reset buf mgmt.
[DEBUG] sync_rx: Reset buf_mgmt consumer index
[DEBUG] sync_rx: Worker is now running.
[DEBUG] RX overrun @ buffer 6
[DEBUG] RX overrun @ buffer 1
[DEBUG] RX overrun @ buffer 28
[DEBUG] RX overrun @ buffer 14
[DEBUG] RX overrun @ buffer 11
[DEBUG] RX overrun @ buffer 30
[DEBUG] RX overrun @ buffer 29

If that is happening, you'll have discontinuities everywhere. Also, are you doing this with an XB-200 attached or only the bare bladeRF? What are your gains set at when you see the issue? Can you try setting the output of the FPGA to be the 32-bit counter mode and see if you get discontinuities?

I want to rule out and see if it is a way in which the samples are getting to your host, or if it is a problem in the way the LMS part is being configured.

Brian

Brian - you've lost me totally here, this is why talking on SKYPE would achieve a great deal in a short space of time.

* Do you want me to generate this output from my own software or your utilities?
* How do I set the FPGA to 32-bit?

No doubt this is in the FAQ somewhere...

[SDR-Radio.com]

Going back through your logs I see that you end up setting RXVGA1 to 30dB and RXVGA2 to 20dB. It's recommended in the LMS6002D FAQ in section 5.18 to remove gain from RXVGA2 followed by RXVGA1 followed by the LNA. Can you try to ensure you remove gain in such a fashion? I've seen some interesting things happen when the gain stages are in weird configurations.

Brian

Brian,

Sadly no change - overall gain changes as expected, data still as shown in the screenshot.

[SDR-Radio.com]

One last thing - the screen shot you posted says the LPF is bypassed which you should not do unless you are already bandlimiting your input signal at the RF input.

The log states the LPF is in Normal mode.

Do you notices differences when you have it bypassed versus in normal mode?

Brian

Brian,

I've tried many combinations as I was also thinking along the same lines. Bypass / anything makes no difference, in fact the changes made to the gains and LNA make no difference, I'm convinced the issue is in the area of firmware / libusb. I'm just about to try libusb 1.0.19, then I'll put together a full static build of all the code (libusb, libbladerf) and take it from there.

[SDR-Radio.com]

One thing I failed to mention - I am using Windows 8.1 .

[jynik]

Mind if I mark this thread solved, due to issues being resolved via the upgrade to libusb v1.0.19? Also -- the Windows 8.1 + libusb issue seems to be consistent with what was reported earlier -- thanks...that's a very good thing for us to be aware of. (When I get some more time, an alternative driver to libusb is in the works for Windows...so we're not at the mercy of libusb working on all systems.)

I just like to avoid creating this frustrating situation for people.