SDR# support

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

Moderator: robert.ghilduta

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

Re: SDR# support

Post by scancapecod » Fri Jul 11, 2014 5:40 am

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

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

Re: SDR# support

Post by LazyDodo » Fri Jul 11, 2014 12:22 pm

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.
Last edited by LazyDodo on Fri Jul 11, 2014 3:50 pm, edited 2 times in total.

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

Re: SDR# support

Post by jump » Fri Jul 11, 2014 1:01 pm

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

Re: SDR# support

Post by LazyDodo » Fri Jul 11, 2014 3:20 pm

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

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

Re: SDR# support

Post by LazyDodo » Fri Jul 11, 2014 4:06 pm

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

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

Re: SDR# support

Post by jump » Sun Jul 13, 2014 10:26 am

Done :)

Now the bandwidth is configurable. I also increased the buffer size to avoid underruns as mentioned by LazyDodo
I also added the two new options for automatic selection of XB-200 filters (1dB and 3dB). In case the libbladerf is too old to handle those values, there is a fall back in software (I hope)

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

Re: SDR# support

Post by scancapecod » Mon Jul 14, 2014 6:41 pm

New version seems to be working well thus far. I still can't get this to work on the PC I want it to, unfortunately. If it's a .dll issue I'm not sure which one it might be.

One question, and maybe this is outside of the scope of the bladeRF, but is it a plug-in limitation or an SDR# limitation that prohibits one from adjusting the bandwidth and MSPS on the fly? I realize there is a "zoom" feature to reduce the size but it would be nice to have the capability of increasing without having to stop and restart.

Is anyone noticing besides me that the transverter is really "hot", as in the gain seems to need to be reduced generally much more than for signals that are above 300 MHz?
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 » Mon Jul 14, 2014 9:55 pm

scancapecod wrote:One question, and maybe this is outside of the scope of the bladeRF, but is it a plug-in limitation or an SDR# limitation that prohibits one from adjusting the bandwidth and MSPS on the fly? I realize there is a "zoom" feature to reduce the size but it would be nice to have the capability of increasing without having to stop and restart.
It's done in the plugin. While the streaming is on, I explicitly disables some of the controls.
Once the RX streaming thread is started I don't think you can adjust the samplerate anymore without restarting it. And I wasn't sure about the bandwidth. If it is 100% safe to adjust is dynamically while streaming, I just have to remove 2 lines in my code to keep that configurable while streaming samples :)


Regarding your DLL problem, the only one that I can think of is MSVCR110.DLL which is a dependency of bladerf.dll
Try to install/update the MS C++ Runtime http://www.microsoft.com/en-us/download ... x?id=30679

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

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

Re: SDR# support

Post by scancapecod » Tue Jul 15, 2014 5:53 am

It's done in the plugin. While the streaming is on, I explicitly disables some of the controls.
Once the RX streaming thread is started I don't think you can adjust the samplerate anymore without restarting it. And I wasn't sure about the bandwidth. If it is 100% safe to adjust is dynamically while streaming, I just have to remove 2 lines in my code to keep that configurable while streaming samples :)
I don't want to get into an SDR# vs. SDR Console debate as both are outstanding and this is not the venue in any event, but in SDR-Console it is possible to adjust it on the fly in a few different manners. That's why I wondered if it might be the way SDR# is written, as it's not possible to adjust the bandwidth for an RTL dongle either while it's running.
Regarding your DLL problem, the only one that I can think of is MSVCR110.DLL which is a dependency of bladerf.dll
Try to install/update the MS C++ Runtime http://www.microsoft.com/en-us/download ... x?id=30679

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 :)
Unfortunately I've already tried it with your latest version; noticed that you had a new one up so I downloaded it last night. No go on the Windows 8.1 64 bit machine I want the bladeRF to run on, same error. Works fine on the other Windows 8.1 64 bit PC. As a matter of fact I didn't have any crashes while running it last evening.

EDIT: Well now that I look again I see that the LibBladeRF folder is just 9 hours old. I'll try that again tonight; sorry, my error. Hopefully it'll fly!
Scott
Webmaster - Scan New England
http://www.scan-ne.net

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

Re: SDR# support

Post by LazyDodo » Tue Jul 15, 2014 8:10 am

sdr# did not support on the fly sample rate changes until rev 1302. If jump implements ISampleRateChangeSource (on the same class that implements IFrontendController) you should be good to go with that.

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

Re: SDR# support

Post by jump » Tue Jul 15, 2014 11:06 am

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

Re: SDR# support

Post by LazyDodo » Tue Jul 15, 2014 11:58 am

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

Re: SDR# support

Post by scancapecod » Tue Jul 15, 2014 5:44 pm

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

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

Re: SDR# support

Post by LazyDodo » Tue Jul 15, 2014 8:33 pm

I don't have sdr-radio installed but on my i7-3770, 40msps pulls about 23-24% cpu with sdr#

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

Re: SDR# support

Post by jump » Wed Jul 16, 2014 1:12 pm

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.
scancapecod wrote: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.

Post Reply