Official bladeRF forum

Hi everybody,

As I have two computers, one running Linux and the other one running Windows, I like to use SDR# because it can run seemlessly under both operating systems. But it lacked bladeRF support... until today

There were a first project hosted with SDR# source code but unfortunately, due to licence violation issues, the code repository is not publicly available anymore.
In addition to that, bladeRF API has evolved a lot during past months so I doubt it was working.

You can find source code + pre-compiled version of the driver in my Github account:
https://github.com/jmichelp/sdrsharp-bladerf

Don't hesitate to test it and give me feedback (on this forum or, even better, through the github issue tracker). I haven't thoroughly tested it. I just managed to get samples and it seems to work at first glance.
XB200 is not supported yet.
I may remove the FPGA bitstream field in future versions now that the library is able to autoload it from the disk as well as DC correction tables.


Jean-Michel

This is great, thanks!

I haven't used SDR# much but getting into other tools is always good. Even though the project is not open source anymore, do you know if it is possible to get this into their "official" release?

I don't know if this is going to be mainstreamed or not.
But first my code has to be cleaner and more stable

Right now I am still encountering a weird issue I don't have with gqrx: once set to the higher band (freq > 1.5 GHz or < 300 MHz with XB-200 attached), I don't get samples anymore! Well, I still get the DC spike at center frequency but except that, everything is at the noise floor.
At first glance, SDR-Console seems to have the same behavior. I am not aware of other similar tools that supports bladeRF under Windows to test if they are impacted too.


BTW, side effect of developping the plugin is that I embed a pre-compiled 32 bit version of libbladerf + CLI tools to ease the installation.
As I regularly pull from github to check for improvement, It's pretty up-to-date

The DLL (bladerf.dll) I use has been compiled by myself, using the latest github revision of the code (i.e. it matches a v0.16.0 of the lib). The SDRSharp plugin checks for the lib version too and refuses to work with a version older than 0.14 due to recent API changes.
Windows installer being known to be outdated, I have put precompiled 32bits version of the bladerf.dll and all the CLI tools (bladeRF-cli.exe, etc.) in my github repository.

I will try to get the output from libbladerf and post it here. Not an expert in C# so I don't know how to grab it yet

I also tried to call bladerf_select_band() after a frequency change (even though the lib already does that automatically) without any luck.

[Edit] While trying to grab the logs from libbladerf, I've fixed a nasty bug that was responsible for the lack of sample on XB-200 frequency range. It was due to a bad handling of the filter banks. Samples are back, now
Still have the issue not seeing any signal at 2.4 GHz though. And FM radio audio is really crappy (no pb on Linux under gqrx with the exact same parameters). Yet, I am pretty comfident that the lookup table used to convert signed 12 bit integers into float is correct.

Here is the code I wrote to generate the LUT: To avoid exception due to an index overflow/underflow in the table, I am masking incoming int16 samples with 0xfff and directly use that value as an index in the table, so the formula here above takes care of generating signed values at the correct position.


Antenna is fine. When going to 2.4 GHz I am using an omni tuned for that frequency.


I am definitely not an expert in C# but I tried several methods and none worked so far to redirect logs from libbladerf to a file. The file remains empty.

[EDIT] Finally got a log file thanks to someone on SDRSharp mailing list

Here is the log I got.

Launching SDRSharp @2.4 GHz, start sampling, going down progressivly to 102 MHz, stop sampling.
Hope this would be helpful to track why I don't get samples at high frequencies and why samples don't seem right (base on inaudible quality on WBFM decoding that works fine with an RTL-SDR).

As a sidenote, I was trying to acheive too complex stuff in C# to grab this logfile (stderr redirection within the software) while simply lauching sdrsharp from a console (sdrsharp.exe 2> bladerf-logfile.txt) was enough...
I should have tried easy solutions first

I didn't noticed the error message while attaching the file: "txt extension is not allowed"

So here it is, zipped to be allowed by the forum

Thanks jynik.

I am calling bladerf_expansion_attach() right from the beginning. In addition, the checkbox to enable XB-200 expansion is disabled as soon as the samples streaming begins (only the gains can still be adjusted during sampling). So I don't know why this line appears at that point.
Same thing happens for the 1 GHz frequency start. I was starting right at 2.403 GHz. Then I decreased the frenquency 100 MHz at a time until being at 2.1023 GHz. And then I decreased it 1 GHz at a time down to 102.3 MHz which is a local FM station here that I should be able to ear correctly.

You can use the prebuilt versions on the Github. The Debug version is able to produce the logfile by launching SDRSharp from a console and redirecting stderr into a file.
If you want to compile it, you will need Visual Studio. Then simply copy the 2 required DLL from SDRSharp into both Debug and Release directories (SDRSharp.Common.dll and SDRSharp.Radio.dll).

It should be possible to compile it from the command line (C# compiler, csc.exe, is always provided with the framework). But I don't know the exact command line to do so.

Given ptrSample is an *Int16 with values -2048 .. 2048 (give or take..) what will happen when you read elements -1 .. -2048?

Unless C# does very weird things, it cannot happen due to the binary mask (0x0fff) that is applied before using the sample value as an index.
It should automatically strip the sign as it zeroed the 4 most significant bits, and that's why the LUT initialization seems a bit weird in its formula ; I had to map correctly negative index values (-1 = 0x0fff and -2048 = 0x800)

But I can also change the lut to map the values differently and replace the lookup by: But this code may overflow if ptrSample value gets out of the expected range, which cannot happen by masking the 12 less significant bits.

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.

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

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

It wants a decryption key?

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