Byassing LPF

Discussions related to schematic capture, PCB layout, signal integrity, and RF development
Post Reply
staticfloat
Posts: 5
Joined: Sun Dec 20, 2015 2:26 pm

Byassing LPF

Post by 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?
Last edited by staticfloat on Mon Feb 01, 2016 12:11 pm, edited 1 time in total.
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Byassing Rx LPF

Post by 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
Posts: 5
Joined: Sun Dec 20, 2015 2:26 pm

Re: Byassing LPF

Post by 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
Posts: 5
Joined: Sun Dec 20, 2015 2:26 pm

Re: Byassing LPF

Post by 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.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Byassing LPF

Post by jynik »

It might be worth double checking some LMS6 register settings in the CLI to ensure we are actually disabling it when you request it. Keep me in the loop if you think we have a defect here -- disabling the filters is something that we don't have many people doing (and as such don't regularly test), so I wouldn't be surprised if a bug was lurking.

As an alternative quick hack, this nugget of information may be of use... From our findings, you can actually widen the LPFs out well beyond 28MHz (I think we can hit the full 40MHz...) by playing with the RCCAL_LPF value in LMS6002D registers 0x36 and 0x56. This is basically just abusing the calibration knobs for the LPF tuning, allowing pushing the filter 3 dB points out.
staticfloat
Posts: 5
Joined: Sun Dec 20, 2015 2:26 pm

Re: Byassing LPF

Post by 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.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Byassing LPF

Post by jynik »

There's certainly not additional front-end filtering on the board itself -- it's designed with the intent of the user adding external filtering as required by their application.

I would say it's still worth referencing the LMS6002D datasheet and confirming we are doing things appropriately. There's always those cases where one needs to flip on some control or test bit elsewhere in order for one to work... we could have overlooked something.

Keep us posted.
Post Reply