SDR# support

Discussions related to embedded firmware, driver, and user mode application software development
scancapecod
Posts: 83
Joined: Tue Jan 21, 2014 6:38 pm
Location: Cape Cod, Massachusetts, USA
Contact:

Re: SDR# support

Post by 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.
Scott
Webmaster - Scan New England
http://www.scan-ne.net
cwiener
Posts: 11
Joined: Sat Mar 15, 2014 4:52 pm

Re: SDR# support

Post by 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);
Chris Wiener N2CR
Morris Plains, NJ
LazyDodo
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo »

There's already a dropdown box with those options calling this api.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: SDR# support

Post by 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
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by 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
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: SDR# support

Post by 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
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: SDR# support

Post by 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
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by 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
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by 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
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: SDR# support

Post by 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
jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump »

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.
sbt
Posts: 2
Joined: Mon Aug 26, 2013 11:01 pm

Re: SDR# support

Post by sbt »

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.
jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump »

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.
jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump »

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
sbt
Posts: 2
Joined: Mon Aug 26, 2013 11:01 pm

Re: SDR# support

Post by sbt »

Hello jump,

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

Many many thanks for this wonderful driver!
Post Reply