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

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

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