SDR# support

[jump]

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

[bpadalino]

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?

[jump]

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

[jynik]

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.

This sounds oddly familiar.... like something I fixed back in Feburary. The Windows installer doesn't get updated anywhere nearly enough (we're working on addressing this problem!) -- any chance the DLL contains the LMS SELOUT defect that we addressed in the aforementioned commit?

If you could save off and share the output generated when the libbladeRF verbosity set to BLADERF_LOG_LEVEL_VERBOSE, perhaps we'll see something suspicious.

[jump]

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.

[jynik]

[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.

Just as a sanity check for the LUT you mentioned, the int16_t IQ values coming from the bladeRF in the range [-2048, 2048) should map to floats in [-1.0, 1.0). So the LUT is just scaling by 2048.0, right?

Do you see signals up at 2.4GHz with GQRX? Any chance your antenna just isn't the right tool for the job up there?

[jump]

Here is the code I wrote to generate the LUT:

Code: Select all

            const float scale = 1.0f / 2048.0f;
            for (int i = 0; i < 4096; ++i)
            {
                _lutPtr[i] = (((i + 2048) % 4096) - 2048) * scale;
            }

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

[jynik]

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

Mind sharing/linking the helpful hint(s) here for historical purposes? Thanks!

[jump]

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

[jynik]

Hi jump,

Any chance a link or attachment got clobbered? I suspect there was supposed to be something after, "Here is the log I got."

Thanks,
Jon

[jump]

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

bladerf-logfile.zip

[jynik]

jump,

Sorry for the delay - been sick.

So to summarize the log, it looks like:

• We start at 1 GHz
• Tune to 2.403 GHz
• Start receiving
• Tune LMS to 2.302 GHz
• Tune LMS to 2.202 GHz
• Tune LMS to 2.102 GHz
• Tune LMS to 1.102 GHz
• Call to attach transverter?
• Tune LMS to 1.145 GHz

Note that the mixer on the transverter is at 1.248 GHz, so the deviations from that get us to about 146 MHz and 103 Mhz, respectively, on the last two items.

One thing that jumped out at me a bit is that it seems bladerf_expansion_attach() is being called in the middle of things. You should be able to call this at startup, and libbladeRF should take care of switching back over to its normal tuning as you cross 300 MHz.

I'm not really seeing anything indicative of why you wouldn't be able to receive anything at higher frequencies, or why the samples you get appear to be bad.

I'll keep taking a gander later. Perhaps if you share some quick build instructions, I can test drive your code on GitHub and see for myself.

[jump]

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.

[LazyDodo]

Code: Select all

 ptrIq->Imag = _lutPtr[*ptrSample & 0x0fff];

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

[jump]

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:

Code: Select all

ptrIq->Imag = _lutPtr[*ptrSample + 2048]

But this code may overflow if ptrSample value gets out of the expected range, which cannot happen by masking the 12 less significant bits.