Byassing LPF

[staticfloat]

I see in the LMS6002D programming guide (on page 12), that I can bypass the Rx LPF filter by setting BYP_EN_LPF to 1 (and perhaps EN_LPF to 0 as well?); is there any way to do this via libbladeRF? I want to hook up my own filter and bypass the LMS's builtin Rx filter, is such a thing possible? Also, is there some resource I can look through to determine what will be emitted if I disable the Tx LPF filter?

[bpadalino]

Check out the bladerf_lpf_mode enum in libbladeRF.h. That should bypass the LPF.

As for what you'll get when you transmit without a reconstruction filter, you will just get repetitions of your spectrum with a sinx/x rolloff. Disabling the TX LPF is not really recommended because there isn't anything you can do to help mitigate the transmit images - it's just what happens with any DAC output.

[staticfloat]

Is there anything I need to do other than call

Code: Select all

bladerf_set_lpf_mode(dev, BLADERF_MODULE_TX, BLADERF_LPF_BYPASSED);

before I enable the TX module? I have my bladeRF hooked up to a 5 gigasample/second scope, and the bandwidth emitted by the bladeRF does not seem to increase when compared to a transmission with the LPF activated.

[staticfloat]

So I came back to this project after a while, and I've collected more data. Bypassing the TXLPF filter does not seem to be doing what I want it to; I want to disable the antialiasing filter on the LMS6002 so as to purposefully leak extra spectrum, but investigating what's being transmitted by the bladeRF doesn't match what I would expect.

I have an IPython notebook that shows the traces taken on a spectrum analyzer for two separate cases, that in which the TX and RX lowpass filters are supposedly disabled, and that in which they are enabled. In short, there's no difference between the two cases, so I'm wondering if I am doing something wrong, or if bypassing the TX filters does not result in the kind of signal I am expecting. I would expect to see many copies of the transmitted signal sprayed out all over the spectrum, but perhaps there is a step inside the chip that is filtering them out even though the TX LPF is disabled.

The IPython notebook and all supporting files are available as a part of this gist, which uses this bladeRF client to slam barker 11 codes out of the bladeRF while (optionally) disabling LPF filters. Usage of the "radar" client is shown in the gist.

[staticfloat]

It looks like things are working as they should be, so no bug in libbladeRF. After running my code, then opening up the CLI, I get the following:

Code: Select all

bladeRF> peek lms 0x35; peek lms 0x55

  0x35: 0x4c
    [7:7]       0 (0x00)      Not used
    [6:6]       1 (0x01)      BYP_EN_LPF
    [5:0]      12 (0x0c)      DCO_DACCAL[5:0]


  0x55: 0x4c
    [7:7]       0 (0x00)      Not used
    [6:6]       1 (0x01)      BYP_EN_LPF
    [5:0]      12 (0x0c)      DCO_DACCAL[5:0]

I suppose there must be some other element about the board that is filtering things.