Official bladeRF forum

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.

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);

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

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

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.

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

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

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

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

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:
Obviously there's some complaining about FPGA version, and I'm not sure that has a bearing on the remainder of my woes.
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:

drbob wrote:I'm currently about 120 nm off the coast of WA

120 nano meters seems very close to the coast


Thanks a lot for testing. Your feedback is very important to help me improve the stability and the reliability of this plugin.
Regarding your issue, could you confirm that the following files are all present in the same directory:

• bladeRF.dll
• libusb-1.0.dll
• plugins.xml
• pthreadVC2.dll
• SDRSharp.BladeRF.dll
• SDRSharp.exe

The default behavior of Windows is to first try loading DLL from the current directory before going through its search path. Your error message seems to tell us that at least one of the required DLL could not be found by Windows or at least not the version it was supposed to have. I tried to tamper my system, messing with the DLLs but I couldn't get the exact error message you have. I will try to explicitly add a manifest to the plugin to see if that solves your issue. What version of Windows are you running?

You could indeed discard the warning message for the FPGA. The "stable" release is a bit old compared to the fast evolving libbladerf so the provided version of bladerf.dll just doesn't know about your FPGA version because it didn't exist back then
BTW as the stable version did not solve the issue, you can go back to the "bleeding-edge" version from git to get all the improvements that have been made.

Hello jump, drbob,

I ran into the same issue as drbob:

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.

Any suggestions?

Thanks.

Which version have you tried? The problem of a missing manifest should have been fixed by a commit on November 2014.

BTW it's been quite a while now since I updated it so I will probably update it during the weekend now that bladerf tools are labelled as stable and see if there's some improvements to be done on the SDR# plugin.

Fortunately the API hasn't changed a lot and did not break my code. The update was pretty quick

Release v0.2.1 has been released: https://github.com/jmichelp/sdrsharp-bl ... tag/v0.2.1

Please give it a try and report any bug you find

Hello jump,

Using your new v0.2.1, i got it running with SDRSharp r1337 !

Many many thanks for this wonderful driver!