Byassing LPF
-
- Posts: 5
- Joined: Sun Dec 20, 2015 2:26 pm
Byassing LPF
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.
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Byassing Rx LPF
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.
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.
-
- Posts: 5
- Joined: Sun Dec 20, 2015 2:26 pm
Re: Byassing LPF
Is there anything I need to do other than call 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.
Code: Select all
bladerf_set_lpf_mode(dev, BLADERF_MODULE_TX, BLADERF_LPF_BYPASSED);
-
- Posts: 5
- Joined: Sun Dec 20, 2015 2:26 pm
Re: Byassing LPF
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.
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.
-
- Posts: 455
- Joined: Thu Jun 06, 2013 8:15 pm
Re: Byassing LPF
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.
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.
-
- Posts: 5
- Joined: Sun Dec 20, 2015 2:26 pm
Re: Byassing LPF
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:
I suppose there must be some other element about the board that is filtering things.
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]
-
- Posts: 455
- Joined: Thu Jun 06, 2013 8:15 pm
Re: Byassing LPF
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.
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.