SDR# support

[jump]

Done

Now the bandwidth is configurable. I also increased the buffer size to avoid underruns as mentioned by LazyDodo
I also added the two new options for automatic selection of XB-200 filters (1dB and 3dB). In case the libbladerf is too old to handle those values, there is a fall back in software (I hope)

[scancapecod]

New version seems to be working well thus far. I still can't get this to work on the PC I want it to, unfortunately. If it's a .dll issue I'm not sure which one it might be.

One question, and maybe this is outside of the scope of the bladeRF, but is it a plug-in limitation or an SDR# limitation that prohibits one from adjusting the bandwidth and MSPS on the fly? I realize there is a "zoom" feature to reduce the size but it would be nice to have the capability of increasing without having to stop and restart.

Is anyone noticing besides me that the transverter is really "hot", as in the gain seems to need to be reduced generally much more than for signals that are above 300 MHz?

[jump]

One question, and maybe this is outside of the scope of the bladeRF, but is it a plug-in limitation or an SDR# limitation that prohibits one from adjusting the bandwidth and MSPS on the fly? I realize there is a "zoom" feature to reduce the size but it would be nice to have the capability of increasing without having to stop and restart.

It's done in the plugin. While the streaming is on, I explicitly disables some of the controls.
Once the RX streaming thread is started I don't think you can adjust the samplerate anymore without restarting it. And I wasn't sure about the bandwidth. If it is 100% safe to adjust is dynamically while streaming, I just have to remove 2 lines in my code to keep that configurable while streaming samples


Regarding your DLL problem, the only one that I can think of is MSVCR110.DLL which is a dependency of bladerf.dll
Try to install/update the MS C++ Runtime http://www.microsoft.com/en-us/download ... x?id=30679

EDIT: just grab the latest version of bladerf.dll in my repository. I now compile them so the lib & tools do not depend on the MS C Runtime anymore. That should solve your problem

[scancapecod]

It's done in the plugin. While the streaming is on, I explicitly disables some of the controls.
Once the RX streaming thread is started I don't think you can adjust the samplerate anymore without restarting it. And I wasn't sure about the bandwidth. If it is 100% safe to adjust is dynamically while streaming, I just have to remove 2 lines in my code to keep that configurable while streaming samples

I don't want to get into an SDR# vs. SDR Console debate as both are outstanding and this is not the venue in any event, but in SDR-Console it is possible to adjust it on the fly in a few different manners. That's why I wondered if it might be the way SDR# is written, as it's not possible to adjust the bandwidth for an RTL dongle either while it's running.

Regarding your DLL problem, the only one that I can think of is MSVCR110.DLL which is a dependency of bladerf.dll
Try to install/update the MS C++ Runtime http://www.microsoft.com/en-us/download ... x?id=30679

EDIT: just grab the latest version of bladerf.dll in my repository. I now compile them so the lib & tools do not depend on the MS C Runtime anymore. That should solve your problem

Unfortunately I've already tried it with your latest version; noticed that you had a new one up so I downloaded it last night. No go on the Windows 8.1 64 bit machine I want the bladeRF to run on, same error. Works fine on the other Windows 8.1 64 bit PC. As a matter of fact I didn't have any crashes while running it last evening.

EDIT: Well now that I look again I see that the LibBladeRF folder is just 9 hours old. I'll try that again tonight; sorry, my error. Hopefully it'll fly!

[LazyDodo]

sdr# did not support on the fly sample rate changes until rev 1302. If jump implements ISampleRateChangeSource (on the same class that implements IFrontendController) you should be good to go with that.

[jump]

I sure can do that
I started writing my code based on rtlsdr / hackrf plugins and those were not implementing that interface because it didn't exist. I think rev1302 might be after Youssef stopped making the source code available.

What about the bandwidth? Because supporting a bandwidth change dynamically while sampling is purely on bladeRF side. I hope this is supported without having to restart the RX sampling thread.
If writing to the LMS register is enough, I only have to remove 2 lines in my code so that's a very simple quick win that should not require a lot of testing.

[LazyDodo]

Yeah the only plugin that supports it right now is the airspy, sdr# doesn't care about the bandwidth in my old plugin you could change it on the fly if i remember correctly.

[scancapecod]

EDIT: just grab the latest version of bladerf.dll in my repository. I now compile them so the lib & tools do not depend on the MS C Runtime anymore. That should solve your problem

And indeed it did! Excellent work.

So I'm back on the PC I want to be on, and experimenting. The bladeRF is running via its customary USB 3.0 port, but with SDR# it is struggling at 20 MSPS. Audio is chugging, FFT is showing "fuzzy" looking signals. I was trying to look at the entire civilian aircraft band of 118-137 MHz. When I back down to 10 MSPS it's fine. Not sure where the restriction is, but it's nice to be back on the right PC again. SDR-Console did run fine up to the full bandwidth capability of the bladeRF when connected to USB 3.0, at about 30% CPU use. I noticed SDR# was consuming 30-35% of CPU when trying to run 20 MSPS. This is SDR# 1313 with a pretty full boat of plugins on board, the sdrsharpplugins offering, the CTCSS decoder, and the DSD interface, if that makes any difference. I did not test with a bare version; I can easily enough.

The machine in question is as mentioned running Windows 8.1 64 bit. The processor is an Intel Core i5-4440 CPU @3.10 GHz, 8 GB of RAM.

All of the above said though, progress is being made. The bladeRF is happy to be "home". Thanks, Jump!

[LazyDodo]

I don't have sdr-radio installed but on my i7-3770, 40msps pulls about 23-24% cpu with sdr#

[jump]

All required changes/improvements are done and seem to be working
Both bandwidth and samplerate can now be changed while sampling. Thanks LazyDodo for pointing me the new interface to implement. I wouldn't have found it by myself.

This is SDR# 1313 with a pretty full boat of plugins on board, the sdrsharpplugins offering, the CTCSS decoder, and the DSD interface, if that makes any difference. I did not test with a bare version; I can easily enough.

Honestly, I don't think it would make any difference because the DLL are loaded but you probably haven't activated all the plugins at once.
Could be a latency issue due to moving data between managed and unmanaged memories. But it is just a supposition, I am neither a developper nor a C# skilled person
I can try to send you a DLL with even more increased buffer size to check if that helps. But I moved from 4k buffer to 16k buffer due to LazyDodo's feedback. I thought it would be enough.

From my side, I still have issues while using USB3 that lead to corrupted samples so I can't test high samplerates on my main laptop which is the only one to have USB3 controller...

EDIT: Just got the USB3 issue fixed! Libusb was too old, moving to the latest version (1.0.19) solved everything Even at 40 Msps SDR# seems to do the job like a treat at 33% CPU usage with the libusb-win32 driver selected in Zadig.

[scancapecod]

The latest files make a marked difference in performance. But even so at 20 MSPS I'm running about 39% CPU. That's fine though given that it's the only task running. Great strides! I'm looking at the entire civilian aircraft band now and it's very clean, fast, no chugging in the audio.

EDIT: Of course I walk out of the room for 2 minutes and come back to the "SDRSharp has stopped working" pop-up on the screen. Hopefully just random.

[cwiener]

Is there a way that the plugin can be configured to take input signals from the ADC connector of the XB200? This bypasses the LMS6002 and allows feeding low frequencies directly into the ADC.

It looks like there is an API to allow this:

/**
* Configure the sampling of the LMS6002D to be either internal or
* external. Internal sampling will read from the RXVGA2 driver internal
* to the chip. External sampling will connect the ADC inputs to the
* external inputs for direct sampling.
*
* @param[in] dev Device handle
* @param[in] sampling Sampling connection
*
* @return 0 on success, value from \ref RETCODES list on failure
*/
API_EXPORT
int CALL_CONV bladerf_set_sampling(struct bladerf *dev,
bladerf_sampling sampling);

[LazyDodo]

There's already a dropdown box with those options calling this api.

[jump]

That's awesome! Thank you jynik for the job and for notifying

I will give it a try this week or the next one depending on my weekly workload.

[drbob]

Yo ho ho... I think this calls for a bottle of rum!

I decided to try out SDR# and followed the instructions to the letter - I can use SDR# on an RTL dongle and it's happy... However, I get this lovely error with the bladeRF:

Error loading 'SDRSharp.BladeRF.BladeRFIO,SDRSharp.BladeRF' - Could not load file or assembly 'SDRSharp.BladeRF' or one of its dependencies. The module was expected to contain an assembly manifest.

Have I done something 'bad'? Zadig sees the unit and builds a driver for it, reports that it was successful.

Any guidance would be appreciated.

Bob