SDR# support

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

[jynik]

jump,

Thought you might be interested -- I just added the first cut of the Cypress CyUSB/CyAPI backend to master, thanks to LazyDodo's efforts on spearheading that effort. After installing the Cypress FX3 SDK and running a clean CMake, you should now be able to build that backend.

You'll have to uninstall the libusb driver for the bladeRF first (it seems to have taken me a few tries at it before the device was associated with no driver). After that, you can point the driver install to the bladeRF built "output" directory, where the driver files will have been copied to.

Also, it is possible to have one device associated with libusb and another associated with the Cypress driver, and have them concurrently running. However, I've been seeing a bit of flakiness from the Cypress driver if I don't specify exactly which device to use.

Cheers,
Jon

[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

[jynik]

Hi Bob,

Which instructions were you following? Are you referring to jump's intstructions in his SDR# plugin repo?

With respect to testing out if the libusb driver is associated with the device properly, a good way to check is to run bladeRF-cli.exe -e info -e version with a device plugged in. If that can read the device's state and version info, it means that libusb is happily talking to the bladeRF.

I still have to try out the above when I get a few spare minutes. Will report back when I do.

- Jon

[jump]

Hi,

just in case, if you are experiencing issues with the github master version, which is basically the dev version, give a try at the archive from the Release section: https://github.com/jmichelp/sdrsharp-bladerf/releases
The bundles here are known to work.

I try to keep everything updated as frequently as I can (and tested) but I have moved to another country and I am not fully settled at the moment which makes it a bit harder for me to work on that project

[jump]

Hi there,

I just pushed a new version on the Github repository that allows to use both libusb and cypress backend.
Keep in mind that the latter is still untested regarding bandwidth and stability
Pre-compiled binaries have been upgraded accordingly

[drbob]

Since everyone else seemed to be entertaining the idea of swapping countries, I decided to try a change of scenery as well. I'm currently about 120 nm off the coast of WA, heading south to warmer waters - hopefully for the remainder of the winter. LOL - long story. A special thank you to the fine folks at Inmarsat...

At any rate, I've returned to playing with this project again (in an environment with less interruptions) and wanted to report back on this topic.

I've grabbed the stable release as suggested from https://github.com/jmichelp/sdrsharp-bladerf/releases and followed the instructions on GitHub here: https://github.com/jmichelp/sdrsharp-bladerf

When I run the command bladeRF-cli.exe -e info -e version I'm clearly seeing and having some level of conversation with the blade, as it returns the following:

bladerf1.PNG

Obviously there's some complaining about FPGA version, and I'm not sure that has a bearing on the remainder of my woes.

bladerf2.PNG

If things are working for others, clearly I am a dolt and have failed to follow instructions properly.

To be clear, I have done the following:

1. Download the latest version of SDR# from http://sdrsharp.com/#download
2. After unpacking, I went to https://github.com/jmichelp/sdrsharp-bladerf/releases , grabbed the package, unzipped and put everything in the sdr-install/sdrsharp directory
3. I followed the instructions at https://github.com/jmichelp/sdrsharp-bladerf regarding this item:
<add key="BladeRF" value="SDRSharp.BladeRF.BladeRFIO,SDRSharp.BladeRF" />
4. Start SDRSharp.

no bueno

An FYI/Update to this message: I reset the machine to factory (Win 7 Home Premium with all service packs, updates, etc.) so I knew I was working with a 'fresh, clean' install and nothing else in the way. After following steps 1-4, above, I launch SDR Sharp and immediately get "SDR Sharp has stopped working". bladeRF-cli.exe -e info -e version returns the same info posted, above.

A further FYI/Update to this message: The crash file says:

Could not load type 'SDRSharp.Radio.HookManager' from assembly 'SDRSharp.Radio, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
at SDRSharp.MainForm..ctor()
at SDRSharp.Program.Main()

Running the bladeRF-cli.exe -e info -e version command from the bladeRF install, I get this response:

yasc2.PNG