SDR# support

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

[LazyDodo]

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]

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]

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]

It wants a decryption key?

[jump]

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

[scancapecod]

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.

[jump]

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]

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?

[jump]

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]

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