XB 200 - Works

[SDR-Radio.com]

Hi,

The problem was the libusb - using 1.0.19 it's OK. FWIW I linked libusb as a static library into the bladerf.dll. I'll probably link bladeRF as a static lib later today.

I must now enable the IQ calibration to remove the spur, but in the screenshot I'm running with a 30 MHz bandwidth.

Next trick is to add CUDA 6 support for the FFT so I can run much higher quality with significant FFT overlapping, especially with boards using the Analog Devices chips.

Screenshot here.

https://www.flickr.com/photos/simonhb9drv/14720811874/

[SDR-Radio.com]

Hi Brian & John,

When running in synchronous mode I get an error when I change the frequency (bladerf_set_frequency): File or device I/O failure, and when I try to read the frequency (bladerf_get_frequency): Invalid operation or parameter.

It seems that I can only set the frequency before reading data . You could reproduce this in your test program, I'll try that myself now.

ETA: Bugger - test program works .

ETA: But you don't attach the XB 200 in the test program. Please have a think about this...

[bpadalino]

That is great news Simon. Sorry that libusb was the issue, but I am glad it's figured out.

We will try to reproduce the issue you're seeing. Just curious, are you running in a multithreaded context? Do you do all your control calls in a single thread, or from different threads?

Jon is working on a thread-safe version of the library which should alleviate those concerns, but as of master that isn't the case.

Either way, we'll try to reproduce with the test program attaching the xb200 and seeing if the problem occurs on our end.

Let us know if we can be any more help.

Brian

[SDR-Radio.com]

Another issue, related.

Any bladerf_set_XXX() call will randomly fail once bladerf_sync_config() has been called, possibly due to you using a thread? I think I (we) need a way to pause the sync thread so that commands can be sent to the LMS6002D. No matter what I do I can't change the frequency without completely stopping and starting the radio which isn't a fantastic solution.

Any thoughts?

[SDR-Radio.com]

That is great news Simon. Sorry that libusb was the issue, but I am glad it's figured out.

We will try to reproduce the issue you're seeing. Just curious, are you running in a multithreaded context? Do you do all your control calls in a single thread, or from different threads?

Jon is working on a thread-safe version of the library which should alleviate those concerns, but as of master that isn't the case.

Either way, we'll try to reproduce with the test program attaching the xb200 and seeing if the problem occurs on our end.

Let us know if we can be any more help.

Brian

Hi Brian,

All my use of the DLL (my BladeRF DLL which in turn uses your DLL) is in its own one and only thread, I'm using 'proper' Windows threading. I actually tried your sync program and bodged a frequency change in but that worked, so it's not a definitive test. What I will have to do to be able to drive all the way down the code is to copy your DLL project into my solution, I already have ~ 40 projects . If / when I do this I'll know exactly where your code is complaining.

I'm more than happy to wait for better code as I have to add support for FFT using CUDA, 30MHz bandwidth rounded up to a power of two with extra overlap for higher resolution can cause any i7 4th generation to sweat hard!

At least I can make some nice 30MHz-wide recordings for testing.

[SDR-Radio.com]

I'm 'playing' with SetStdHandle to capture your diagnostics and errors so I can display them in my own console's logfile.

ETA: Nothing of interest except zillions of: [WARNING] unexpected value from events processing: -1: LIBUSB_ERROR_IO

[jynik]

Just had a come minutes here to check my mail...wanted to "ACK" items here. I'll look to get some of the additional thread safety stuff merged in the next day or too...probably a great time for some of that fun CUDA stuff.

The libbladeRF_test_ctrl has an option to run tests with the XB-200 attached...I'll go over that again and report back by Friday, if all goes well.

- Jon

[SDR-Radio.com]

Jon,

I'll wait until you're thread safe, then we can talk further, this avoids wasting your time too much. I am now capturing your diagnostics, so between us we'll get the beasty working.

[jynik]

Simon,

Just wanted to touch base, as not to leave you in the dark.

I had a bit of a busy week and didn't get as far as I hoped with the thread safety items; I'm aiming to have the libbladeRF changes and associated test(s) available in master the end of the weekend, and will plan to post back here Sunday night with a status.

If you're happy waiting until then to get back to anything bladeRF-related, you can just ignore the rest of this post. Otherwise, you may find some of the below information helpful or interesting. I will probably not be around much to answer questions on the below items, as I will want to remain focused on the items promised above.

Since the last post...

• We've tagged another release candidate that's a cleanup of some bugs, so you may want to update to that in the near future.
  • A firmware update is available to address a fix that caused stale samples left over in the first few buffers of data.
  • An FPGA update is available to fix a defect in the reading back of IQ correction values.
• The Getting Started: Windows guide has been updated to recommend libusb 1.0.19, and the Verifying Basic Device Functionality wiki content has been moved to a common, more OS-agnostic page, with some more information about just testing a few operations in the bladeRF-cli program.

Regarding using the XB-200 in test programs...

libbladeRF_test_sync may soon be replaced by functionality present in the bladeRF-cli, which allows you to tune tune the lower ranges after running, xb enable 200. Specificically, a community member is working on having the CLI use those sync functions instead of the async ones. If that turns out not to get merged in soon, I will add an --xb200 option to libbladeRF.

The libbladeRF_test_ctrl program that currently gets built with libbladeRF basically just exercises the "control and configuration" functions (e.g., the accesssor functions for knobs like gain, bandwidth, loopback mode, etc). This has an --xb200 to indicate that the tests should be run with the XB-200 enabled.

Below the invocation and contents of log.txt from running this on my Windows machine. Don't worry about the [Warning] messages about the samplerate rounding errors -- this is harmless and we'll be making that a "debug" output (that wouldn't show up here), rather than a warning in an upcoming commit. You should only be concerned if you see [Error] messages or non-zero failure counts at the end.

Note that this output is on a device running the new firmware and FPGA mentioned above. If you do not run FPGA v0.0.6, you will see a high failure count in the "correction" tests.

Code: Select all

C:\Users\Jon\Documents\projects\bladeRF\host\build\output\Debug\libbladeRF_test_ctrl.exe --xb200 > log.txt

    test_sampling: Setting and reading back sampling modes...
    test_lpf_mode: Setting and reading back RX LPF modes...
    test_lpf_mode: Setting and reading back TX LPF modes...
    test_enable_module: Enabling and disabling modules...
    test_loopback: Setting and checking loopback modes...
    test_xb200: Setting and reading back filter bank settings...
    test_xb200: Setting and reading back path settings...
    test_correction: Sweeping RX corrections...
        I DC offset
        Q DC offset
        Phase
        Gain
    test_correction: Random RX corrections...
        I DC offset
        Q DC offset
        Phase
        Gain
    test_correction: Sweeping TX corrections...
        I DC offset
        Q DC offset
        Phase
        Gain
    test_correction: Random TX corrections...
        I DC offset
        Q DC offset
        Phase
        Gain
    test_samplerate: Sweeping RX sample rates...
      Sample rate currently set to 39580000   Hz...
    test_samplerate: Applying random RX sample rates...
      Sample rate currently set to 16264520   Hz...
    test_samplerate: Applying random RX rational sample rates...
      Sample rate currently set to 16429220   3543      /21836      Hz...
    test_samplerate: Sweeping TX sample rates...
      Sample rate currently set to 39580000   Hz...
    test_samplerate: Applying random TX sample rates... 
      Sample rate currently set to 17750480   Hz...
    test_samplerate: Applying random TX rational sample rates...
      Sample rate currently set to 9791200    8902      /15513      Hz...
    test_bandwidth: Sweeping RX bandwidths...
    test_bandwidth: Applying random RX bandwidths...
    test_bandwidth: Sweeping TX bandwidths...
    test_bandwidth: Applying random TX bandwidths...
    test_gain: Performing gain sweep...
        TXVGA1
        TXVGA2
        LNA
        RXVGA1
        RXVGA2
    test_gain: Applying random gains...
        TXVGA1
        TXVGA2
        LNA
        RXVGA1
        RXVGA2
    test_frequency: Performing RX frequency sweep...
      Currently tuned to 3750000000 Hz...
    test_frequency: Performing random RX tuning..     
      Currently tuned to 1538458020 Hz...
    test_frequency: Performing TX frequency sweep...    
      Currently tuned to 3750000000 Hz...
    test_frequency: Performing random TX tuning...
      Currently tuned to 175694550  Hz...
     
    Failure counts
    --------------------------------------------
            sampling 0
            lpf_mode 0
       enable_module 0
            loopback 0
               xb200 0
          correction 0
          samplerate 0
           bandwidth 0
                gain 0
           frequency 0

Regarding the current state of thread-safety
Again, you may rather just wait until the end of the weekend than spend any further time with any of this. I just wanted to elaborate on a few items...

It is already possible to use the async and sync interfaces without any risk of race conditions, if you follow some guidelines noted in the async section of the docs. You shouldn't have to shut down the sync interface to change frequency, gains, bandwidth, samplerate, etc.

For example, we are happily streaming data (both half and full duplex) while concurrently tuning frequency, gains, bandwidth, etc. in the gr-osmosdr's bladeRF support. (One can see view FFTs or waterfalls while changing parameters via their osmocom_fft program).

The general guidelines are as follows:

• Have a separate "control" thread and a separate "data thread".
• The "control" thread only calls the functions to tune freq, set gains, etc. This thread must not make bladerf_sync_* calls.
• The "data thread" only calls the bladerf_sync_ calls. This thread must not attempt to call any other API functions.

Under the hood, the data and control functions are specifically crafted to allow for this.

With that said, the above stipulations have confused people, and hence, we'll be adding more thread-safety guarantees in the API.

Enjoy your weekend,
Jon

[SDR-Radio.com]

Jon,

Thanks, I'm sure you'll fix it. I've put the bladeRF to one side at the moment and am:

• Getting to grips with the CUDA FFT library as high quality output (low RBW) means lots of FFT overlap and FFT uses so much CPU it's not possible to do this on a normal Intel PC without raising the temperature etc. CUDA going well, something I wanted to do for a long time.
  
  Then I have a very nice SDR radio in a case with knobs to support.
  
  Then in early August there's the hackRF which seems to have a stable interface (I do hope).
  
  Then there's Direct-X coding to master, should take a lifetime or two.

So take it slowly, get it right and I'll give it another bash, but you must be prepared to talk via SKYPE if there are issues - it's so much more efficient, being an early adopter is amazingly frustrating. Get this right & I'll be promoting the bladeRF at the RSGB Convention in October 2014 where I have a couple of SDR presentations.

For the time being I am not shipping bladeRF support in my internal (test-team only) betas.

[jynik]

Simon,

Sounds like a good plan. I'll touch base soon.

[jynik]

Hi Simon,

The thread-safety changes are up in master and seem to have been holding up well; I've been beating the changes up with some tests and a few other SDR programs. The Doxygen pages have been updated accordingly.

If what you were seeing was the result of calling bladeRF "control" calls from multiple threads, this should help. As I mentioned earlier, it was previously possible to concurrently to do things like change frequency/bandwidth while a stream was running, if one was careful to keep control calls in one thread, and data stream calls in another (and be sure not to cross the streams!).

If you run CMake with -DENABLE_LOCK_CHECKS (or from the GUI, check the ENABLE_LOCK_CHECKS checkbox), all lock acquisition functions be wrapped with an assert() for success, quickly causing any deadlock scenarios to grind to a halt at the line they occur.

The libbladeRF_test_ctrl program now contains a "threads" test, which can be run on its own via:

Code: Select all

libbladeRF_test_ctrl.ext -t threads

Not that these test take a while to run. Without the "-t" argument, all tests shown by libbladeRF_test_ctrl -L will be run. If you want to run tests with the XB-200 attached and in use, there's a --xb200 argument.

I'll be AFK this weekend while at DEFCON, but some other folks on here might be able to offer assistance. Just wanted to post an update so you can take a look at your leisure -- I know you're working on lots of other cool stuff in the meantime.

Have a good one!
Jon