SDR# support

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

LazyDodo
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Wed Jul 09, 2014 9:08 am

Bypass the possible problem for now by just doing value/2048.0f? see if that improves things? it'll be slower, but at this point i'll take slower over scary pointer magic?

Can anyone record a couple of seconds of FM baseband (at like 1-2 msps) and post it? lets see if we can figure out what's wrong from the signal.

jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump » Wed Jul 09, 2014 9:16 am

LazyDodo wrote:Bypass the possible problem for now by just doing value/2048.0f? see if that improves things? it'll be slower, but at this point i'll take slower over scary pointer magic?
I started using a LUT. Then, being unsure of the values mapping, I removed it, doing simple conversion as you mentioned.
After several tries in a test progam, I restored the LUT because values where 100% correct this way.

Can anyone record a couple of seconds of FM baseband (at like 1-2 msps) and post it? lets see if we can figure out what's wrong from the signal.
I'll do that this evening and put the sample file online. Just wait for a couple of hours :)

jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump » Wed Jul 09, 2014 12:18 pm

Here is the raw file as recorded by SDRSharp https://mega.co.nz/#!dtZVXBRB

Central frequency was 102.455 MHz as noted in the file name, 1 Msps.
The FM radio station is at 102.3 MHz

LazyDodo
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Wed Jul 09, 2014 3:19 pm

It wants a decryption key?

jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump » Wed Jul 09, 2014 4:43 pm

Sorry, not used to mega :)
This one should be better:
https://mega.co.nz/#!dtZVXBRB!FaIjaFf4S ... ENsCFri0tU

scancapecod
Posts: 83
Joined: Tue Jan 21, 2014 6:38 pm
Location: Cape Cod, Massachusetts, USA
Contact:

Re: SDR# support

Post by scancapecod » Wed Jul 09, 2014 7:06 pm

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.
Scott
Webmaster - Scan New England
http://www.scan-ne.net

jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump » Thu Jul 10, 2014 1:20 am

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
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Thu Jul 10, 2014 2:43 am

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?

Image

jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: SDR# support

Post by jump » Thu Jul 10, 2014 3:53 am

LazyDodo wrote: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
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Thu Jul 10, 2014 6:29 am

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

Re: SDR# support

Post by jump » Thu Jul 10, 2014 6:49 am

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
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Thu Jul 10, 2014 7:44 am

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

Re: SDR# support

Post by jump » Thu Jul 10, 2014 11:27 am

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
Posts: 30
Joined: Fri Mar 01, 2013 6:49 am

Re: SDR# support

Post by LazyDodo » Thu Jul 10, 2014 1:55 pm

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
Posts: 83
Joined: Tue Jan 21, 2014 6:38 pm
Location: Cape Cod, Massachusetts, USA
Contact:

Re: SDR# support

Post by scancapecod » Thu Jul 10, 2014 5:25 pm

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!
Scott
Webmaster - Scan New England
http://www.scan-ne.net

Post Reply