SDR# support

[scancapecod]

I can report that the latest update to this plugin is working well for me on a Windows 8.1 64 bit PC. Unfortunately this PC does not have compatible USB 3.0 ports so I'm restricted on bandwidth but it's a nice confirmation that the XB-200 is functioning. For some reason the Windows 8.1 64 bit PC that I normally use the bladeRF with does not like the modification of SDR# to support the bladeRF. When I add the frontendPlugin line and try to start the program it throws up an exception and then continues....but without bladeRF support. All other test platforms have allowed for SDR# to run.

It ain't easy being me.

But I can at least confirm that as a simple end user of the bladeRF as a receiver it is functioning for me. Ironically as I was typing this (on the same PC SDR# is running on) SDR# crashed with no explanation. Restarting it went without a hitch though.

Thanks for your efforts Jump!'

Quick followup: FM Broadcast band reception is crystal clear and RDS info is displaying perfectly.

[jump]

Many thanks for your tests Scott!

It helped me find the problem. At some point I thought it was a cabling issue but my SMA cables were fine. The culprit is in fact the USB driver. I still don't know why but it seems that the driver does not handle USB3 properly, messing all the samples.

My laptop only has USB3 ports and as soon as I started using a USB2 cable to connect the bladeRF, everything was working perfectly. Well... except that at some point I got a BSOD But the BSOD only confirms that the USB driver is crappy and is the one in fault here.



Regarding the exception you have on one of your PC, it is a DLL issue. The problem is to find which one is causing this error But there is not a lot of candidates for that as it has to do with native code. I am providing most of the involved DLLs in my Github repository so you should check the MS Visual C runtime DLL. Try to install the latest one from Microsoft's website

[LazyDodo]

I can't seem to spot the bug just by looking at the code on github, but for some reason half your samples are 0's?

[jump]

I can't seem to spot the bug just by looking at the code on github, but for some reason half your samples are 0's?

You can't spot the bug because there is no bug (at least on that part)
Like I said on my previous post, the problem comes from the USB driver. It cannot run correctly with USB3. Plugging a USB2 cable (without the extra USB3 connector) solved the sampling problem.
I even got a BSOD while trying to adjust the frequency under USB2 so I will try to have a look at the memory dump and see what part of the libusbk driver is faulty.

It is very interesting to know that half the samples are nulled. I will try to snoop at the USB bus to see where things are starting to be messed up.

[LazyDodo]

Libusb isn't great on windows (hardware not being found is the main problem really) there's some work in the pipeline that switches to an alternative driver on windows (the cypress one), which should make things a little better.

On the bsod, you could use something like zadig to swtich between a few drivers on windows (winusb,libusb, libusbk) libusbk gets a little bsod-ish when you don't properly close the device at times give the others a whirl

[jump]

As libusbK was mentioned in the wiki as the driver to be used for the bladeRF I was just assuming that samples were sent over an isochronous endpoint. But it seems to be through bulk endpoints so there is no reason to use that specific driver indeed. Moreover they are still being flagged as experimental drivers compared to WinUSB

I will try to see if one works better than another tonight.

Regarding the BSOD, I also want to investigate it in order to see if this is exploitable, at least as a local privilege escalation and try to add a working payload for the Facedancer

[LazyDodo]

I did some bandwidth testing a couple of months ago on all 4 drivers (winusb,libusb-win32, libusbk, cypress) libusbk was the worst of the bunch started losing data around 20 msps, both the cypress and libusb-win32 made it up to 56msps without losing a single sample, with winusb starting to drop packets around 46msps (still comfortably above the max supported sample rate of the blade though) if you have no weird enumeration issues i'd say go with libusb-win32 otherwise wait it out until the cypress stuff makes it into mainline.

[jump]

Thank you for your feedback.

Unfortunately, whatever driver I tried, I still get crappy samples when I try with a USB3 cable. So I guess the only option is to wait for your cypress backend to be merged into the mainstream.
I saw messages about Renesas USB controlers that seems to be known to have issues but I have an Intel USB controler and there is no driver update for it.

Do you know what slows down the integration of your work? Maybe I can help the team and issue a pull request on GitHub if it's just a matter of time & test.

[LazyDodo]

The way it usually works it i take a first stab at the code, get the main parts done, send my code to jynik who cleans it up, spits and shines it and gets it merged into mainline, problem is he has a lot on his plate in the last little bit.

[scancapecod]

As we say up here in the Boston area, this is "wicked cool".

Here's a screenshot of the 49 meter shortwave broadcast band. I need to play with the gain adjustments, but I also had some aeronautical radio on 5616 KHz USB with Gander Newfoundland Radio and a few in-flight aircraft.

On a more constructive note pertinent to this thread, I am using a Renesas Electronics 4 port PCIe USB card with success on the PC that usually runs the bladeRF. Here's a link to it: http://www.startech.com/Cards-Adapters/ ... EXUSB3S44V . I found it considerably cheaper than the price listed there, but it came on the recommendation of another forum member and it works. The only Intel based USB 3.0 chipset I got the bladeRF to work with was on my work PC, a Dell running Windows 7 Pro 64 bit. In Windows 8 Intel decided to let Microsoft provide the USB 3.0 drivers, which from what I read has caused considerable issues with a wide range of USB 3.0 products. Go figure.

This stuff is really finicky though. The same Renesas chipset card in my other Windows 8.1 PC absolutely refused to work. Again, go figure!

Edit: Looking at the 40 meter amateur band and running the FFT at 32k it is possible to actually read the CW (morse code) signals that are being sent. They display perfectly. Cool beans!

[scancapecod]

While using SDR# last night with the bladeRF I had a considerable amount of crashes. It seemed when I ran the program in the background while doing other things on the PC this occurred. When I actually had the program in the foreground it did not. It would simply quit with "SDRSharp has stopped working" with a Debug and Quit (I think) option. If there will be usable info in the Debug I can provide it going forward. I had only one crash the first night this worked for me, but another difference may be that I was only running primarily 2 MSPS samples.

I would guess you would like to have reports made to your Github regarding problems/enhancement requests specific to the plug-in.

With regards to my potential .dll issue I'll check into that but as far as I know I should be up to date. I'm not sure if it makes any difference but I've never had any issues running the bladeRF on that PC using SDR-Console.

[LazyDodo]

I kept it running in the background for a few hours, can't seem to reproduce the crash, also I noticed a fair amount of rx overruns on the higher sample rates but i not sure where that's coming from. As a feature request i'd like to control the bandwidth parameters, the default bw seems a little wide to my taste.

[jump]

Bandwidth is computed as 3/4 of the selected sample rate. I took that from gr-osmosdr.
But that can be added pretty quickly. Do you want it to be fully adjustable (text box) or, like sample rates, restricted to a dropdown list that has the advantage of avoiding typing errors?

Regarding the crash, I got no idea on what can cause that. Probably a memory leak if this happens only after a long time. But again, that may be a USB driver related thing.

[LazyDodo]

There's only 16 options, so a combo-box will probably be best

[LazyDodo]

Also fixed the rx underruns, the 4k samples buffer used was too small, problem went away with a larger buffer