Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dual Channel RX gain issue #947

Closed
ScottTilley opened this issue Oct 5, 2023 · 9 comments
Closed

Dual Channel RX gain issue #947

ScottTilley opened this issue Oct 5, 2023 · 9 comments

Comments

@ScottTilley
Copy link

ScottTilley commented Oct 5, 2023

I've tried to read dual channel IQ samples from two bladerf2s I have using the bladeRF-cli and the gr-bladerf and osmocom blocks in gnuradio and find that the gain of RX2 is always stuck way lower than where I set it and RX1. The plot below demonstrates this issue.

plot1

Here's a brief script I used to generate this data:

rx config file=dual_test.bin n=10M channel=1,2
set frequency rx 2211.5e6
set samplerate 2e6
set agc 0
set clock_ref 1
rx start

And the info and print outputs from the BladeRF used:

bladeRF> info

Board: Nuand bladeRF 2.0 (bladerf2)
Serial #: 59fffd81411f48a6bdc07828e6d80651
VCTCXO DAC calibration: 0x1ecf
FPGA size: 49 KLE
FPGA loaded: yes
Flash size: 32 Mbit
USB bus: 2
USB address: 17
USB speed: SuperSpeed
Backend: libusb
Instance: 0

bladeRF> p

RX1 Bandwidth: 18000000 Hz (Range: [200000, 56000000])
RX2 Bandwidth: 18000000 Hz (Range: [200000, 56000000])
TX1 Bandwidth: 18000000 Hz (Range: [200000, 56000000])
TX2 Bandwidth: 18000000 Hz (Range: [200000, 56000000])

RX1 Frequency: 2211500000 Hz (Range: [70000000, 6000000000])
RX2 Frequency: 2211500000 Hz (Range: [70000000, 6000000000])
TX1 Frequency: 2400000000 Hz (Range: [47000000, 6000000000])
TX2 Frequency: 2400000000 Hz (Range: [47000000, 6000000000])

Tuning Mode: Host

Bit Mode: 16 bit samples

Feature: Default enabled

RX1 AGC: Disabled
RX2 AGC: Disabled

Clock reference: REFIN to ADF4002 (locked)
REFIN frequency: 10000000 Hz
Clock input: Onboard VCTCXO
Clock output: Disabled

RX1 RSSI: preamble = -97 dB, symbol = -115 dB
RX2 RSSI: preamble = -96 dB, symbol = -111 dB

Loopback mode: none

RX mux: BASEBAND - Baseband samples

RX FIR Filter: 4x decimation
TX FIR Filter: 4x interpolation

Gain RX1 overall: 60 dB (Range: [-15, 60])
full: 71 dB (Range: [-4, 71])
Gain RX2 overall: 60 dB (Range: [-15, 60])
full: 71 dB (Range: [-4, 71])
Gain TX1 overall: 66 dB (Range: [-23.75, 66])
dsa: -10 dB (Range: [-89.75, 0])
Gain TX2 overall: 66 dB (Range: [-23.75, 66])
dsa: -10 dB (Range: [-89.75, 0])

RX1 sample rate: 2000000 0/1 (Range: [520834, 122880000])
RX2 sample rate: 2000000 0/1 (Range: [520834, 122880000])
TX1 sample rate: 2000000 0/1 (Range: [520834, 122880000])
TX2 sample rate: 2000000 0/1 (Range: [520834, 122880000])

Bias Tee (RX1): off
Bias Tee (RX2): off
Bias Tee (TX1): off
Bias Tee (TX2): off

Current VCTCXO trim: 0xc000
Stored VCTCXO trim: 0x1ecf

Hardware status:
RFIC status:
Tuning Mode: Host
Temperature: 35.1 degrees C
CTRL_OUT: 0xf8 (0x035=0x00, 0x036=0xff)
Power source: USB Bus
Power monitor: 4.84 V, 0.57 A, 2.76 W
RF routing:
RX1: RFIC 0x0 (A_BAL ) <= SW 0x0 (OPEN )
RX2: RFIC 0x0 (A_BAL ) <= SW 0x0 (OPEN )
TX1: RFIC 0x0 (TXA ) => SW 0x0 (OPEN )
TX2: RFIC 0x0 (TXA ) => SW 0x0 (OPEN )

bladeRF-cli version: 1.9.0-git-9fc57e6c
libbladeRF version: 2.5.0-git-9fc57e6c

Firmware version: 2.4.0-git-a3d5c55f
FPGA version: 0.15.0 (configured from SPI flash)

@rthomp10
Copy link
Collaborator

rthomp10 commented Oct 6, 2023

Mind giving this .grc a shot? I was able to reproduce the issue within the cli. Currently able to circumvent the issue with this .grc.

test.zip

@ScottTilley
Copy link
Author

Seems to work if I change the frequency while it streams.

@rthomp10
Copy link
Collaborator

Turns out we were able to reproduce the result, but by splitting the siggen out through an SMA splitter. Isolating RX1 from RX2 rids the issue. Also ensure RX1 and RX2 gains are set once the AGC has been disabled.

@ScottTilley
Copy link
Author

Thank-you. I assume you are referring to the CLI? How would one do this using the gr-bladerf with say gnuradio? Can you clarify what you mean by 'but by splitting the siggen out through an SMA splitter. Isolating RX1 from RX2 rids the issue'?

@rghilduta
Copy link
Collaborator

We've tested RX1 vs RX2 in SISO and MIMO mode on a bladeRF 2.0 micro REV 1.3 and this is roughly what we see:
image

There is minimal difference in performance in feeding in a signal into a specific RX port's between when the port is in MIMO or SISO mode (with AGC disabled and manual gains). We did however see a difference between SISO and MIMO mode performance, when a signal was split using a Y SMA cable causing transmission line effects (instead of an actual power splitter or circulator).

Please note to set a manual frequency after setting agc to 0. RX gain calibration is not run until a gain is set for each channel.

@ScottTilley
Copy link
Author

With gnuradio I manually command the bladerf to change frequency after I start a stream and the RX2 channel pops to life and closely matches RX1. As you note if I send a command to the unit after the script starts it also comes to life as expected. Would be nice to have this no need manual stimulus as I'm not sure how to do this in applications like gnuradio without manual intervention. I'm finding the average gain offset between the channels to be very low even when using my orthogonal RF paths so the results above support Robert's analysis.

@rghilduta
Copy link
Collaborator

I think this is safe to close? Please feel to reopen if needed!

@rghilduta
Copy link
Collaborator

Hi Scott, hope all is well. We showed a chart with test points gathered using a standard bladeRF-cli / libbladeRF basically showing there not being much of a power difference between RX1 and RX2 under various conditions. Please see the chart above ( #947 (comment) ) .
When we were able to recreate the issue you described it was because of transmission line effects with a simple Y splitter, as opposed to a power divider. Once we got rid of the Y splitter, and thus the reflections, RX1 and RX2 showed the results we provided in the chart. Since this was neither a hardware issue nor a software fix on our end we assumed it was not a bladeRF/libbladeRF (this repo) issue, so the product and device work.

To make sure we're heading in the right direction, is the GNURadio bladeRF source configuration the (remaining) issue you'd like to see addressed? Upon a quick inspection, I think the order in which we receive GR element updates has changed, so the gain is set prior to the AGC mode being changed. Thinking out loud here: this may be a gr-osmosdr/gr-bladeRF change as opposed to a libbladeRF fix. Does this sound right? Can you give us your GRC flowgraph so we can make sure our patches work with your flowchart?

@rghilduta
Copy link
Collaborator

Can you try out this gr-bladeRF commit Nuand/gr-bladeRF@27de289 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants