XB 200 - Firmware Update

Discussions related to embedded firmware, driver, and user mode application software development
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: XB 200 - Firmware Update

Post by bpadalino »

Sorry - I didn't get to this post until late tonight.

You can try to use the synchronous interface instead of the async one. It should be much simpler to work with. Just be sure you are thread safe when calling the functions.

Do you have verbose log outputs from the library? You can set the output using bladerf_log_set_verbosity().

If you remove the xb200, do the samples look normal again? Do these problems only exhibit themselves in the FM band?

There is a way to put the FPGA in a 32-bit counter mode if you want to look for discontinuities in your data.

Hopefully this is helpful in some sense. Like jynik said, looking at the verbose logs from your output with the USB transactions would be useful.

Brian
SDR-Radio.com
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by SDR-Radio.com »

Hi Brian,

I think I'll try the synchronous interface, IMO the asynchronous interface is clearly broken. I don't know when I'll get time - this evening maybe.

If this approach doesn't work I'll remove support for the bladeRF until your next software release, this will ensure there's no confusion.

As an aside I've now got the waterfall running very smoothly with a 30MHz span.
SDR-Radio.com
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by SDR-Radio.com »

As you say, the sync interface is much simpler - let's see. It'll be a nice sunny day here, things to do in the garden.
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: XB 200 - Firmware Update

Post by bpadalino »

Hi Simon,

Sounds great that you've gotten the waterfall to work. Not sure if it means using the sync interface that things are much better now, or since the day was nice and gardening had to get done - you put away the technical things?

Are there still issues? Sorry for the confusion.

Brian
SDR-Radio.com
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by SDR-Radio.com »

Hi Brian,

Weather's nice, I've looked at your sync program and it does seem simple, so I'll give it a go this evening. Currently I'm in and out of the garden, when in the office I'm writing a shapefile class to draw timezone info on a map of the world.

So there!
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: XB 200 - Firmware Update

Post by 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
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by 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
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: XB 200 - Firmware Update

Post by jynik »

Hello Simon,
SDR-Radio.com wrote: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.
SDR-Radio.com wrote: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.
SDR-Radio.com wrote: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
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by 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
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: XB 200 - Firmware Update

Post by jynik »

Hi Simon,
SDR-Radio.com wrote: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
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: XB 200 - Firmware Update

Post by 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
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: XB 200 - Firmware Update

Post by 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
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: XB 200 - Firmware Update

Post by 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
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by SDR-Radio.com »

Jon,

FWIW there are no problems with data overruns or underruns, the data is streaming perfectly.
SDR-Radio.com
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: XB 200 - Firmware Update

Post by SDR-Radio.com »

bpadalino wrote: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...
Post Reply