Aliases and Mirroring Issues

[scancapecod]

Hello,

I'll preface this by offering the disclaimer that I'm still in the fledgling stages of bladeRF use.

Using the BladeRF with SDR-Radio software in Windows, and when looking at a FFT wider than a few MHz or so, I am plagued by a good deal of alias signals and some mirroring, especially where strong signals are concerned. I'm not able to provide a screenshot right now but I'd be happy to this evening if requested.

Searching the forums here I came up with this post: http://www.nuand.com/forums/viewtopic.p ... t=10#p3619

I'm not sure what I should use at the bladeRF command line to implement this but it apparently helped another user that was having similar issues with gnuradio.

Other than that can anyone offer any other suggestions? I understand such things can be "the nature of the beast" so to speak, but there is some frustration when this occurs, so trying to minimize it would be ideal.

Thanks in advance!

Scott

[piranha32]

What FPGA image are you using? I had problem with mirrors and aliases after upgrading bladeRF host software and booting FPGA with old version of bitstream.

j.

[scancapecod]

I'll check the specific one when I get home, but it's from http://hoopycat.com/bladerf_builds/ and not the latest version; probably one from mid-February. That would be great if it were that easy, and I guess maybe I should have thought of that. I should at least upgrade to the newest version if I'm going to opt to use the "bleeding edge" updates. Or....should I (can I) go back to the stable release? As I recall the same issues were there with the stable version, but it's been a while.

Thanks,

Scott

[scancapecod]

I just updated to the latest firmware and FPGA at http://hoopycat.com/bladerf_builds/

Here is the bladeRF using SDR-Radio software looking at 10 MHz of spectrum with 856.000 as the center frequency. Shown are an active Motorola Type II Trunked System Control Channel at 855.5375 and two active voice channels. Although I've marked up the .jpg with explanations it probably doesn't need any. The mirroring is absolutely horrible. If the .jpg doesn't show up well here the direct link is: https://dl.dropboxusercontent.com/u/360 ... 165702.jpg . This is just one example of the problems I am seeing. I could provide many more and at samples far less than 10 MHz at a time.

[scancapecod]

Last pic was overly large but it gives you a good idea. I resized the following one and shows a 3 MHz sample of the same signals, this time with the LNA switched from bypass to middle. The result is quite a mess. I do understand that there is not much if any front end to speak of so I suspect the bladeRF is simply getting croaked by these reasonably strong signals. Or, I'm way off the mark and someone will give me a virtual dope slap and point me in the right direction.



Obviously I know enough to pick out real signals from mirrored ones, but there has to be a way to make at least some improvement to this. I expect it's mostly my being in the early stages of learning how to properly balance its gain and filters.

Thanks for any assistance.

Scott

[scancapecod]

One last screenshot with some progress being made, but at the expense of weak signals. In this one I'm back to a 10 MHz sample, 851-861 MHz as before, but with the LNA and LPF both bypassed, VGA1 at 0 dB, and VGA2 at 3 dB. It has eliminated 90% of the mirroring, but at a cost as mentioned.

[CC90]

Hi Scott,

I had a similar issue after upgrading the firmware mid January. I rolled back to the previous fx3 /fpga and the aliases and mirroring disappeared. I haven't tried a more recent update since to know if this was a one off. I'm not home right now, but will check which version I'm using when I get home.

Colin

[scancapecod]

Does anyone have any more information regarding aliasing and mirroring? I'll reiterate by saying it is primarily an issue with stronger signals, and it's pretty clear to see what's going on with my above screenshots.

What bothers me is if there is an earlier version of firmware/FPGA that this did not occur with, and it is occurring now, are there any steps being taken to eliminate the problem? Is it even perceived by others (including Nuand folks) as a problem?

[drmpeg]

The low-pass filter that's built in to the LMS6002D transceiver chip is your best weapon against aliasing. For the narrow band signals that you're interested, the low-pass filter should be set to it's minimum value (which is 1.5 MHz).

I haven't used SDR-Radio, so I'm not familiar as to how it sets the low-pass filter bandwidth. If you can set it manually to 1.5 MHz, that would certainly do the trick. If the low-pass bandwidth is being set automatically (based on sample rate), then you should lower the sample rate to 1.5 MHz or even less.

If you're not sure how SDR-Radio is setting the low-pass filter, then you can use bladeRF-cli to check the values (after exiting SDR-Radio).

In a command prompt, just do:

bladeRF-cli -i
print bandwidth

The allowable low-pass filter values (in MHz) are:

1.5
1.75
2.5
2.75
3.0
3.84
5.0
5.5
6.0
7.0
8.75
10.0
12.0
14.0
20.0
28.0

Ideally, the low-pass filter should match your signal bandwidth. Unfortunately, the LMS6002D is really designed for wideband signals and the filter choices are geared for that operation. The new LMS7002M is much better, with bandwidths down to 100 kHz (but that will have to wait for some future SDR).

Ron

[scancapecod]

Thanks Ron.

At this time SDR-Radio only offers "Normal", "Disabled", or "Bypass" for the LPF. There is a modified version of SDRSharp software that works with BladeRF but I've never been able to make it work unfortunately. It does offer different settings for the LPF. Maybe in the future Simon can add this feature to SDR-Radio as well as it obviously sounds like it would be very helpful.

I'm not sure if this setting can be manipulated from the command line, but if it could be I guess that SDR-Radio would override the settings in any event.

Thanks for your help!

Scott

[jynik]

What bothers me is if there is an earlier version of firmware/FPGA that this did not occur with, and it is occurring now, are there any steps being taken to eliminate the problem? Is it even perceived by others (including Nuand folks) as a problem?

I agree that it's strange that a previous bundle didn't exhibit this behavior.

Sorry for the lack of response - I've been trying to reproduce this and have been asking people on IRC to take a look at this thread and report back on whether they're able to reproduce it. I've been using GQRX and don't think I'm seeing it, but am not confident that I'm fully reproducing your setup.

This weekend I'm looking to meet up with another dev and go over a few items, including this; I'll try to bring up SDR-Radio on my machine and get a couple pair of eyes looking at it closely.

I believe the following information will be helpful in understanding this. If anyone has time to take a look and report back, it'd be appreciated (and will likely speed things up):

• What firwmare + FPGA+ libbladeRF version is not exhibiting this? What version of SDR-Radio is being used? (I assume for the new stuff, we're talking about FW 1.6.1 and FPGA v0.0.3.)
• How is the device configured when this is observed? As drmpeg noted, some information can be gleaned from the bladeRF-cli program:
  • frequency ('print frequency')
  • bandwidth ('print bandwidth')
  • sample rate ('print samplerate')
  • LMS register values ('peek lms 0 256')
• Is SDR-Radio shipping with and using libbladeRF DLL, or does it use the one you've built/installed?
• Can this be reproduced outside of SDR-Radio? Can you reproduce this with GQRX? Just want to be thorough and rule out app-side issues...
  • Is there any way to look at the raw IQ samples and look for anything strange? (After setting up the device in SDR-Radio, you could use bladeRF-cli to save off some raw samples to a CSV). A short capture may be very helpful.

A while back the FPGA began sign-extending the int16_t I/Q values to the full 16-bit range; previously bits [15:12] were markers to differentiate between I and Q values. This alleviated the need for host-side software to mask off those bits and sign extend. I don't think there should be an issue if the FPGA is doing this, but the host-side SW hasn't changed...it might just be doing unneccessary work. I'll look into this further and review the git logs.

[scancapecod]

Hi,

I'll try to help with what I can provide in response to your questions:

print frequency = RX Frequency: 856000000Hz, TX Frequency: 1000000000Hz (span is set to 10 MHz in SDR-Radio, center frequency is 856.000 MHz)
print bandwidth = RX Bandwidth: 14000000Hz, TX Bandwidth: 28000000Hz (bandwidth is set to 20 MHz, and the sample rate I have SDR-Radio set to is 10 MHz)
print samplerate= RX sample rate: 20000000 0/1, TX sample rate: 1000000 0/1
peek lms 0 256 produces the below:
0x00: 0x1f
0x01: 0xe0
0x02: 0x1f
0x03: 0x08
0x04: 0x22
0x05: 0x3e
0x06: 0x0d
0x07: 0x00
0x08: 0x00
0x09: 0x40
0x0a: 0x00
0x0b: 0x08
0x0c: 0x9a
0x0d: 0xe5
0x0e: 0x01
0x0f: 0x00
0x10: 0x34
0x11: 0x15
0x12: 0x55
0x13: 0x55
0x14: 0x88
0x15: 0x94
0x16: 0x8c
0x17: 0xe3
0x18: 0x40
0x19: 0x9b
0x1a: 0x03
0x1b: 0x76
0x1c: 0x38
0x1d: 0x40
0x1e: 0x00
0x1f: 0x00
0x20: 0x59
0x21: 0x2a
0x22: 0xaa
0x23: 0xaa
0x24: 0x88
0x25: 0xf9
0x26: 0x8c
0x27: 0xe3
0x28: 0x40
0x29: 0xa0
0x2a: 0x03
0x2b: 0x76
0x2c: 0x38
0x2d: 0x40
0x2e: 0x00
0x2f: 0x00
0x30: 0x1f
0x31: 0x00
0x32: 0x1f
0x33: 0x08
0x34: 0x02
0x35: 0x0c
0x36: 0x30
0x37: 0x23
0x38: 0x46
0x39: 0xc9
0x3a: 0x5b
0x3b: 0x4a
0x3c: 0x5f
0x3d: 0x3a
0x3e: 0x00
0x3f: 0x00
0x40: 0x00
0x41: 0x15
0x42: 0x80
0x43: 0x80
0x44: 0x0b
0x45: 0x00
0x46: 0x00
0x47: 0x40
0x48: 0x0c
0x49: 0x0c
0x4a: 0x18
0x4b: 0x50
0x4c: 0x00
0x4d: 0x00
0x4e: 0x00
0x4f: 0x00
0x50: 0x1f
0x51: 0x01
0x52: 0x1f
0x53: 0x08
0x54: 0x0a
0x55: 0x0c
0x56: 0x30
0x57: 0x94
0x58: 0x00
0x59: 0x29
0x5a: 0x20
0x5b: 0x00
0x5c: 0x00
0x5d: 0x00
0x5e: 0x00
0x5f: 0x1f
0x60: 0x1f
0x61: 0x00
0x62: 0x1f
0x63: 0x08
0x64: 0x36
0x65: 0x01
0x66: 0x00
0x67: 0x00
0x68: 0x01
0x69: 0xe9
0x6a: 0xf1
0x6b: 0x23
0x6c: 0xe7
0x6d: 0x7a
0x6e: 0x00
0x6f: 0x00
0x70: 0x01
0x71: 0x80
0x72: 0x80
0x73: 0x00
0x74: 0x00
0x75: 0xd0
0x76: 0x72
0x77: 0x00
0x78: 0x1c
0x79: 0x37
0x7a: 0x77
0x7b: 0x77
0x7c: 0x18
0x7d: 0x00
0x7e: 0x00

The file libbladeRF.dll does not exist in the SDR-Radio folder. As a matter of fact I just searched my entire C drive and no such file exists at all. Maybe I'm getting confused by what you mean.

I tried to get a version of SDRSharp software that is modified for bladeRF use to run, but I can't make it work. I was hoping that I might be able to see something different in it that might point to a source of the problem. I'd have to set up a virtual host to get gqrx working but I can give that a try asap.

If I can learn how to provide raw IQ samples (I'm sure I can) I'll follow up and provide them.

Thanks!

Scott

[LazyDodo]

the file is called bladerf.dll

[scancapecod]

the file is called bladerf.dll

Thanks, and apologies. I should have mentioned that in the previous post. Of course I do have that one, and as I can see it is included in SDR-Radio. It has a date of 10/19/2013 5:56 AM with a file size of 66 KB.

I appreciate the help.

Scott

[scancapecod]

I went back to the standard issue firmware and FPGA today, but it made no difference regarding the problem I'm having. libbladeRF version: 0.12.1-git, firmware version 1.6.1git-b736642, FPGA version 0.0.3.

I also tried replacing the bladerf.dll files and libusb-1.0.dll files that are provided in SDR-Radio (10/19/13 date) with the newer ones generated by the BladeRF Windows installer. SDR-Radio apparently saw the bladeRF but would do nothing on startup. So I copied back the older files and it again runs fine. I suppose that's an aside to the issue at hand but it's worth noting. I'm relatively sure that you guys probably know why this happened...I sure don't!

I thought I saw somewhere that Windows should have a newer version of libbladeRF than what I'm showing, maybe 0.13.?? .

Aside from the imaging, aliasing, it's working very well. I haven't blown it up yet so I'm happy to experiment more if I can help solve the issue. I'll still work on a virtual host for Linux so I can try gqrx and see if there's a difference there. Still no joy with SDRSharp working.