-
Notifications
You must be signed in to change notification settings - Fork 457
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
Comments
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. |
Seems to work if I change the frequency while it streams. |
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. |
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'? |
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. |
I think this is safe to close? Please feel to reopen if needed! |
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) ) . 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? |
Can you try out this gr-bladeRF commit Nuand/gr-bladeRF@27de289 ? |
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.
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)
The text was updated successfully, but these errors were encountered: