Sample Rate & SDR# dropouts

[pmmeasures]

Not quite sure where to post so here I think is as good as any for now as I am sure it will peak somebody's interest.

So got myself a BladeRf and love it a step up from an RTL based one that was quoted to be good upto 2 Ghz but really sucked prettymuch after 1ghz.

But like many I like at times to have that full spectrum of capture aka 40Msps sampling rate.

But OMG it drops out like a trooper, so 20Msps turned out to be where the dropout ceased, brought a posh superspeed cable thinking the one supplied was not quite upto the task but no change

Puzzled Now I have a beefy machine CPU is no more than 15% I have choice of USB3 outlets Intel & Asmedia (AsMedia works fractionally better)

Anyhow I had been messing with the config of SDR# and made a booboo BUT noticed something interesting in doing so

*****Turns out in SDR# that the "Audio Latency" has an effect on the usable sample rate
This can seen and backed up by LED3 on the BladeRF

The mistake I made was setting the Audio Latency to "Zero" in the config which gave awful sound but no TX overruns on the Bladerf LED3 solid

So after upping the latency to get the audio right the sample rate dropped but I found a balance where 26Msps runs nice and upto 30Mps with occasional dropping

I could not see an SDR# forum - I am no expert and do not really understand how xyz do there thing lol

But does anyone understand what the Audio Latency is doing in SDR# ?

Is this purely a failure in code around the Audio Latency having a knock on effect or is the Latency changing a setting more core to the audio system ?

Are there DLL's within SDR# thats part of the audio settings ? that might need updating ?

Would be nice to have the full 40Msps available.

[jump]

Hi,

the current version of SDR# as of today is r1337 if you want to check that you are running the latest one.

There is no forum about it but there is a mailing list, hosted on Yahoo! Group. You have to signup for a Yahoo account if you don't have one yet and then you can request access to the mailing list (https://uk.groups.yahoo.com/neo/groups/SDRSharp/info).
Before reporting the issue to the developers, ensure that you disabled all the plugins that are not bundled with the default installation.

Regarding the bandwidth, if you're not already using it, also try to use the Cypress backend instead of the libusb one to see if that helps.

On my side I can try to give you a new version of the DLL that handles the bladeRF with an increased buffer size to see if that helps fixing your problem but I don't remember having any issue on my computer listening to FM stations with full bandwidth and the transverter...

[pmmeasures]

Hi Jump & thankyou for your brilliant work on the software front, it is what swung my purchasing decision before I clicked the purchase button lol.

Yes this is happening on a clean install of r1337 I ran a fresh install for the Bladerf in a separate folder.

Cypress driver yielded same results which initially lead me to some Red Herrings about the Cypress usb3 controller. Currently it is on libusb

I am up to-date on all files & firmware also for the BladeRF I believe 1.1.2 / 1.2.1 / 1.8.0 / 0.1.2 according to what version says in blade-cli

So yes I would be very interested in trying out the DLL and reporting back if this DLL helps matters , I am open to trying anything and everything at the moment.

Kind Regards
Paul.

[pmmeasures]

Hi Jump

And a very big thankyou for the files

Both brought improvements, the 1st one most certainly was the better of the 2 the double buffer one was still an improvement over the original dll.

Since I posted yesterday I have been tinkering more, Actually got a stable 40Msps with the original dll, lowering the Audio Latency and dropping FFT speed to 32768 and giving the program all cpu cores even though it ticks along between 16-27%.

I think the issue for me was around I had restricted the process to run on only cores 5,6,7,8 instead of all 8 (Due to running GPU Boinc & folding at home projects) even though there is more than enough CPU grunt with 4 cores and no other programs have ever shown any oddballs from doing so.

Restricting CPU infinity back to 4 cores and using your 1st DLL and dropping the audio latency to 38 worked perfectly at 40Msps
Original Dll required 6 cores active with audio latency to 38 to be drop free at 40Msps
Original dll and all 8 cores active with audio latency at 80 to be drop free at 40Msps

So sounds like there is some threading issues with some something along the line in theory I should be able to overclock my cpu a fract and have sdr# running on just 1 core but setting to just 1 pretty much bricked the program lol.

Interestingly.. dropping back to the RTL dongle Sdr# was only using 3% cpu (due to considerably lower sample rate) but when set to 1 core it also dropped samples so I am rightly or wrongly in the belief there is an underlying issue in SDR#

Anyhow your are a superstar the 1st DLL has made my system perfect

/Paul.

[jump]

Cool.

I'll send you a third version then to see this can be improved even more.

Depending on the results of your tests I will do even more testing on my side with different sample rates to adjust some thresholds and will release, thanks to you, a more robust version