Support of srsLTE - Githubissues

xaled1 commented 5 years ago

Hi,

Could you share the current status of srsLTE support?

chemeris commented 5 years ago

Unfortunately, srsLTE support is non-existent right now. We did an effort to support srsLTE two years ago but then the API towards radio has changed significantly at srsLTE and someone has to basically write the integration from scratch.

We're looking for a good opportunity to justify the effort from our side.

Meantime, patches are always welcome.

integralpro commented 5 years ago

Hi, it looks like srsLTE support SoapySDR, but I wasn't able to run it from the box.

Opening 1 RF devices with 1 RF channels... 02:35:21.592688 DEBUG: xtrxllpciev0_discovery:264 [PCIE] pcie: Found pcie:///dev/xtrx0

...

[INFO] SoapyXTRX::activateStream(RX) 0 Samples per packet; res = 0 Set master clock rate to 30.72 MHz Set Rx bandwidth to 8.64 MHz Set Tx bandwidth to 8.64 MHz

Warning TX/RX time offset has not been calibrated for device none. Set a value manually

Using sse2 for xtrxdsp_iq16_sc32 02:35:25.737943 INFO: [LMSF] PCI:/dev/xtrx0: AFE TX=[1;0] RX=[1;0] 02:35:25.738094 INFO: [LSM7] PCI:/dev/xtrx0: TBB: path 0 02:35:25.738154 INFO: [LSM7] PCI:/dev/xtrx0: 0x0124[1f, 10] 02:35:25.738335 INFO: [LMSF] PCI:/dev/xtrx0: TBB Restore BW[0]=8640000 02:35:25.738349 INFO: [LSM7] PCI:/dev/xtrx0: TBB: path 2 02:35:25.738424 INFO: [LMSF] PCI:/dev/xtrx0: TBB Restore DSP[0]=0 02:35:25.738442 INFO: [LSM7] PCI:/dev/xtrx0: TXTSP CMIX=0 02:35:25.744446 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:16384 TS:0); TX DMA 16 bit SISO @0.0 [INFO] SoapyXTRX::activateStream(TX) 0 Samples per packet; res = 0 Using sse2 for xtrxdsp_sc32_iq16

==== eNodeB started === Type to view trace 02:35:25.775069 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 9, prev: 0 TS:595712 02:35:25.775813 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 10, prev: 9 TS:572672 STPS:641792 02:35:25.776493 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 10, prev: 10 TS:618752 STPS:641792 02:35:25.777261 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 10, prev: 10 TS:630272 STPS:641792 02:35:25.777967 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 11, prev: 10 TS:607232 STPS:641792 02:35:25.784352 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 20, prev: 11 TS:722432 02:35:25.785089 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 21, prev: 20 TS:733952 STPS:768512 02:35:25.785755 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 22, prev: 21 TS:745472 STPS:768512 02:35:25.786469 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 22, prev: 22 TS:756992 STPS:768512 02:35:25.787961 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 23, prev: 22 TS:710912 STPS:768512 02:35:25.795795 ERROR: [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 32, prev: 23 TS:880384 ...

dchard commented 4 years ago

@chemeris

I attached a full log for XTRX + SRSENB (latest master) via Soapy:

xtrx_srsenb.txt

One thing to highlight from the log:

Setting Sampling frequency 23.04 MHz
02:06:43.284200 INFO:   [LMSF] PCI:/dev/xtrx0: Increase RXdiv= 4 TXdiv=24 => CGEN 368.6 Mhz
02:06:43.287384 ERROR:  [LMSF] PCI:/dev/xtrx0: can't deliver interpolation: 24 of 368.640 MHz CGEN and 1.920 MHz samplerate; TXm = 0.000 RXm = 0.000
[ERROR] SoapyXTRX::setSampleRate(0, RX, 23.04 MHz) - error -22
setSampleRate Rx fail: SoapyXTRX::setSampleRate() unable to set samplerate!

I understand that adding native support for SRSENB might take quite some time, but maybe fixing the Soapy capability is something more easier that can buy time at least. At this point, I am not even sure if this is a general Soapy + XTRX issue, or something on the SRSENB side.

andrepuschmann commented 4 years ago

Hey, as explained on the srsLTE issue earlier we don't see a problem with our SoapySDR RF driver. It works well with a bunch of other devices. Perhaps it makes sense to verify the correct behavior of the XTRX soapy driver in isolation.

dchard commented 4 years ago

@andrepuschmann

Thanks for letting us know!

DevD3339 commented 4 years ago

Unfortunately, srsLTE support is non-existent right now. We did an effort to support srsLTE two years ago but then the API towards radio has changed significantly at srsLTE and someone has to basically write the integration from scratch.

We're looking for a good opportunity to justify the effort from our side.

Meantime, patches are always welcome.

Hi, could it be possible to share the work you have mentioned, may be we can take a look to make it work with srsLTE, patches or even from scratch. Thanks

dchard commented 4 years ago

Hi, could it be possible to share the work you have mentioned, may be we can take a look to make it work with srsLTE, patches or even from scratch. Thanks

Hi,

SrsLTE should work at least via Soapy (non-native). The thing is, there must be some issue with the xtrx sopay support, as srslte is not the only project that does support soapy, yet it does not work with xtrx. Osmocom-analog is another one. And it fails exactly the same way, with the same error message.

iliyankxyz commented 3 years ago

Has anyone successful used srsLTE and XTRX? I have tried to setup srsLTE but as far as I see the behaviour is the same as it had been two years ago.

arun1969 commented 2 years ago

Has anyone successful used srsLTE and XTRX? I have tried to setup srsLTE but as far as I see the behaviour is the same as it had been two years ago. untested XTRX support added.

https://github.com/arun1969/srsRAN.git

arun1969 commented 2 years ago

Hi,

Could you share the current status of srsLTE support?

untested XTRX support added.

https://github.com/arun1969/srsRAN.git

dchard commented 2 years ago

Hi, Could you share the current status of srsLTE support?
untested XTRX support added.
https://github.com/arun1969/srsRAN.git

Thanks, will test it next week, I am not home at the moment :-)

arun1969 commented 2 years ago

Hi, Could you share the current status of srsLTE support?
untested XTRX support added.
https://github.com/arun1969/srsRAN.git
Thanks, will test it next week, I am not home at the moment :-)

Hi I have not faced any TX DMA error. timestamp works fine but not tested the signal on UE. Code works find with Sidekiq and UE is getting register.

following is dump of SRSRAN with XTRX.

--- Software Radio Systems LTE eNodeB ---

Couldn't open , trying /root/.config/srsran/enb.conf Reading configuration file /root/.config/srsran/enb.conf... Couldn't open sib.conf, trying /root/.config/srsran/sib.conf Couldn't open rr.conf, trying /root/.config/srsran/rr.conf Couldn't open rb.conf, trying /root/.config/srsran/rb.conf WARNING: cpu0 scaling governor is not set to performance mode. Realtime processing could be compromised. Consider setting it to performance mode before running the application.

Built in Release mode using 21.10.0.

/home/elcom/work/srsRAN/srsenb/src/enb_cfg_parser.cc:1216: Force DL EARFCN for cell PCI=1 to 1700 Opening 1 channels in RF device=default with args=default Available RF device list: Xtrx Trying to open RF device 'Xtrx' 11:16:20.259963 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000300 11:16:20.272668 INFO: [CTRL] PCI:/dev/xtrx0: XTRX Rev4 (04000113) 11:16:20.272705 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 11:16:20.272721 INFO: [PCIE] PCI:/dev/xtrx0: Device /dev/xtrx0 has been opened successfully CPU Features: SSE2+ SSE4.1+ AVX+ FMA- 11:16:20.385608 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000304 11:16:20.485774 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_GPIO set to 3280mV 11:16:20.485818 INFO: [CTRL] PCI:/dev/xtrx0: LMS PMIC DCDC out set to VA18=1880mV VA14=1480mV VA12=1340mV 11:16:20.489038 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV 11:16:20.499145 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000306 11:16:20.509644 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 11:16:20.516800 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 11:16:20.516857 INFO: [XTRX] refclock 0 11:16:20.517002 INFO: [DBGP] Starting XTRX debug thread 11:16:20.546526 INFO: [XTRX] osc 26058316 cnt 1 11:16:20.547113 INFO: [XTRX] PCI:/dev/xtrx0: Set INT RefClk to 26000000 based on 26058316 measurement 11:16:20.547154 INFO: [LMSF] PCI:/dev/xtrx0: TXm = 61.440 RXm = 61.440 cgen_rate= 61.440 tx_no_decim 0 11:16:20.548316 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 11:16:20.548333 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV 11:16:20.548470 INFO: [LMSF] PCI:/dev/xtrx0: rxrate=1.920MHz txrate=1.920MHz actual_master=61.440MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=15.360MHz TX_DAC=15.360MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0 [XTRX RF INFO] xtrx_set_samplerate srate_hz = 1920000.000000 master=61.440 MHz [XTRX RF INFO] rx_rate = 1.92 Mhz tx_rate = 1.92 Mhz [XTRX RF INFO] xtrx_tune_tx_bandwidth rx bandwidth 1.92 Mhz [XTRX RF INFO] xtrx_tune_rx_bandwidth rx bandwidth 1.92 Mhz RF device 'Xtrx' successfully opened

==== eNodeB started === Type to view trace Setting frequency: DL=1855.0 Mhz, UL=1760.0 MHz for cc_idx=0 nof_prb=50 Using avx for xtrxdsp_iq16_sc32 Using avx for xtrxdsp_sc32_iq16

t Enter t to stop trace.

dchard commented 2 years ago

Well, I will be able to do ref power calibration and modulation analysis, as I have access to a vector signal analyzer that can do LTE FDD and TDD. Atm I cannot do 5G vector analysis, but the important aspect of XTRX support is definitely the thing we can do 10-20MHz 5G reliably with a PCIe based radio.

MOD: a quick question: does MIMO works already, or is it TM1 only?

arun1969 commented 2 years ago

Well, I will be able to do ref power calibration and modulation analysis, as I have access to a vector signal analyzer that can do LTE FDD and TDD. Atm I cannot do 5G vector analysis, but the important aspect of XTRX support is definitely the thing we can do 10-20MHz 5G reliably with a PCIe based radio.

MOD: a quick question: does MIMO works already, or is it TM1 only?

That is very encouraging, i will wait for your test result. i have tested sidekiq in SISO mode only.

is there possibility we can connect directly, and how. i have been working on other project where you can be interested , so we can cooperate.

~Arun

dchard commented 2 years ago

This is just a hobby for me, although I do work in professional telecom. Non the less I will try to look at this next week, and run some tests. As srslte supports TM3/TM4 and LimeSDR with two channels, getting MIMO work on XTRX should be relatively doable.

dchard commented 2 years ago

Just a quick update: your mods were built cleanly, and starts as it should. I have no core on the train, so tests will follow later:

Opening 1 channels in RF device=default with args=default
Available RF device list: Xtrx 
Trying to open RF device 'Xtrx'
10:26:56.188133 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000300
10:26:56.201031 INFO:   [CTRL] PCI:/dev/xtrx0: XTRX Rev4 (04000013)
10:26:56.201091 INFO:   [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0
10:26:56.201104 INFO:   [PCIE] PCI:/dev/xtrx0: Device `/dev/xtrx0` has been opened successfully
CPU Features: SSE2+ SSE4.1+ AVX+ FMA-
10:26:56.314145 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000304
10:26:56.414358 INFO:   [CTRL] PCI:/dev/xtrx0: FPGA V_GPIO set to 3280mV
10:26:56.414396 INFO:   [CTRL] PCI:/dev/xtrx0: LMS PMIC DCDC out set to VA18=1880mV VA14=1480mV VA12=1340mV
10:26:56.418048 INFO:   [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV
10:26:56.428166 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000306
10:26:56.438948 INFO:   [LSM7] PCI:/dev/xtrx0: LMS VER:7 REV:1 MASK:1 (3841)
10:26:56.438974 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e
10:26:56.443550 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e
10:26:56.443550 INFO:   [DBGP] Starting XTRX debug thread
10:26:56.458843 INFO:   [XTRX] PCI:/dev/xtrx0: Set INT RefClk to 26000000 based on 26058316 measurement
10:26:56.458924 INFO:   [LSM7] PCI:/dev/xtrx0: CGEN: VCO/2=1167360000 k/2=19 int=89 frac=835634
10:26:56.460020 INFO:   [LSM7] PCI:/dev/xtrx0: CGEN: binary result: 153
10:26:56.460471 INFO:   [LSM7] PCI:/dev/xtrx0: CGEN: Retuned [153:159] -> 156
10:26:56.460684 INFO:   [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e
10:26:56.460702 INFO:   [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV
10:26:56.460715 INFO:   [LMSF] PCI:/dev/xtrx0: rxrate=1.920MHz txrate=1.920MHz actual_master=61.440MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=15.360MHz TX_DAC=15.360MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0
[XTRX RF INFO] xtrx_set_samplerate srate_hz = 1920000.000000 master=61.440 MHz
[XTRX RF INFO] rx_rate = 1.92 Mhz tx_rate = 1.92 Mhz
10:26:56.460826 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 00]
10:26:56.460943 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
10:26:56.461064 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 02]
10:26:56.461182 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
[XTRX RF INFO] xtrx_tune_tx_bandwidth rx bandwidth 1.92 Mhz
10:26:56.461322 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[0a, 02]
10:26:56.461483 INFO:   [LSM7] PCI:/dev/xtrx0: TIA: CCOMP=8 CFB=865 RCOMP=0
10:26:56.461668 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[0a, 0a]
10:26:56.461828 INFO:   [LSM7] PCI:/dev/xtrx0: TIA: CCOMP=8 CFB=865 RCOMP=0
[XTRX RF INFO] xtrx_tune_rx_bandwidth rx bandwidth 1.92 Mhz
RF device 'Xtrx' successfully opened

==== eNodeB started ===
Type <t> to view trace
Setting frequency: DL=1822.6 Mhz, UL=1727.6 MHz for cc_idx=0 nof_prb=50
Using avx for xtrxdsp_iq16_sc32
Using avx for xtrxdsp_sc32_iq16

dchard commented 2 years ago

@arun1969

I am doing some tests and I have some partial success:

The test phone does see the 5MHz LTE signal at 1822.6MHz. The signal level is very week.
The phone tries a random access (visible on the spectrum analyzer), but nothing in the SRS-RAN log.

Question:

How can I change the transmit power/LNA gain and select the proper antenna ports of the XTRX? "tx_gain" and "rx_gain" does not seems to do anything.

I will get back to you with some vector measurements as it is possible that the frequency error of the XTRX is too big, but would be lovely to get an answer to the above.

dchard commented 2 years ago

This is the vector signal analysis (Equalized to RS) of SRS-RAN LTE with XTRX:

As it is visible, all parameters are within tolerance, except for the freq error, but we can deal with this later. The biggest issue is that after I stop SRS-ENB, some signals are still being transmitted around the previous center frequency:

arun1969 commented 2 years ago

@arun1969

I am doing some tests and I have some partial success:
1. The test phone does see the 5MHz LTE signal at 1822.6MHz. The signal level is very week.

2. The phone tries a random access (visible on the spectrum analyzer), but nothing in the SRS-RAN log.
Question:

How can I change the transmit power/LNA gain and select the proper antenna ports of the XTRX? "tx_gain" and "rx_gain" does not seems to do anything.

I will get back to you with some vector measurements as it is possible that the frequency error of the XTRX is too big, but would be lovely to get an answer to the above.

Antenna port is automatic set by libxtrx. modify enb.conf for tx_gain and rx_gain

one can modify following function to get more log in lib/src/phy/rf/rf_xtrx_imp.c void rf_xtrx_suppressstdout(void *h) { xtrx_log_setlevel(XTRX_LOG_WARNING,NULL); rf_xtrx_logging_level = XTRX_LOG_WARNING; }

I will check again

arun1969 commented 2 years ago

This is the vector signal analysis (Equalized to RS) of SRS-RAN LTE with XTRX:

As it is visible, all parameters are within tolerance, except for the freq error, but we can deal with this later. The biggest issue is that after I stop SRS-ENB, some signals are still being transmitted around the previous center frequency:

great progress. I don't have vector analyzer, but do have spectrum analyzer. will try and do some test in this week "signal after xtrx stop".

~Arun

dchard commented 2 years ago

@arun1969

A couple more information:

That weird signal that stays even after the SRS-ENB is stopped, is also present on TX port 2 during the normal operation. I also tried setting "tm = 2" and "nof_ports = 2", but on the second TX port, only the same weird signal is coming out as I mentioned after the stop. Btw if I run "SoapySDRUtil --probe" after the SRS-ENB is stopped, the weird signal stops being present. I think when the SRS_ENB is stopped, we are missing this:

08:50:02.981801 INFO: [PCIE] PCI:/dev/xtrx0: Device is closing

But there are other things that is worrying me:

After a couple minutes, the vector signal analyzer looses track of the signal. The LTE signal is still present, but demodulation is no longer possible:

I also did a measurement without equalization, and the signal looks pretty bad:

modify enb.conf for tx_gain and rx_gain

That does not work. I tried a couple settings: TX power level stayed the same (very low).

And from time to time, I can see this in the log:

==== eNodeB started ===
Type <t> to view trace
Setting frequency: DL=1822.6 Mhz, UL=1727.6 MHz for cc_idx=0 nof_prb=25
Using avx for xtrxdsp_iq16_sc32
Using avx for xtrxdsp_sc32_iq16
09:04:54.237432 ERROR:  [BPCI] PCI:/dev/xtrx0: RX DMA STAT O- 00000000 Bytes -R03 01/33 I:33
09:04:54.245977 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 9, prev: 0 TS:2186556320
09:04:54.246925 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 10, prev: 9 TS:2186567840 STPS:2186579360
09:04:54.255972 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 19, prev: 10 TS:2186625440
09:04:54.256916 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 20, prev: 19 TS:2186636960 STPS:2186648480
09:04:54.265939 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 29, prev: 20 TS:2186694560
09:04:54.266992 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 30, prev: 29 TS:2186706080 STPS:2186717600
09:04:54.275975 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 39, prev: 30 TS:2186763680
09:04:54.276971 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 40, prev: 39 TS:2186775200 STPS:2186786720
09:04:54.285977 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 49, prev: 40 TS:2186832800
09:04:54.286981 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current skip due to TO buffers: 50, prev: 49 TS:2186844320 STPS:2186855840
09:04:55.020111 ERROR:  [XTRX] PCI:/dev/xtrx0: TX DMA Current delayed buffers: 81, prev: 50 TS:2186861600
[XTRX RF ERROR] xtrx_send_sync_ex returned -22 2186867360

dchard commented 2 years ago

I re-checked the cabling and the weird constellation diagram (with no equalization) is coming from the SDR, no doubt. I also tested with 10 and 20MHz. On 10MHz the signal degradation is worse, on 20MHz it seems to be better. So this is definitely a SW issue.

Would be nice to figure out a way to actually test the hardware with some sample signals (16QAM or something) which can be vector analyzed.

MOD2: I also noticed, that it does not matter if I change the bandwidth (no_prb), the tx and rx sample rate stays the same:

16:08:18.608019 INFO:   [LMSF] PCI:/dev/xtrx0: rxrate=1.920MHz txrate=1.920MHz actual_master=61.440MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=15.360MHz TX_DAC=15.360MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0
[XTRX RF INFO] xtrx_set_samplerate srate_hz = 1920000.000000 master=61.440 MHz
[XTRX RF INFO] rx_rate = 1.92 Mhz tx_rate = 1.92 Mhz
16:08:18.608064 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 00]
16:08:18.608135 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
16:08:18.608208 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 02]
16:08:18.608292 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
[XTRX RF INFO] xtrx_tune_tx_bandwidth rx bandwidth 1.92 Mhz

That must be wrong...

dchard commented 2 years ago

Just out of comparison, this is a LimeSDR Mini outputting the same 5MHz LTE signal (no equalization):

Clearly a lot better, then with the XTRX.

arun1969 commented 2 years ago

I re-checked the cabling and the weird constellation diagram (with no equalization) is coming from the SDR, no doubt. I also tested with 10 and 20MHz. On 10MHz the signal degradation is worse, on 20MHz it seems to be better. So this is definitely a SW issue.

Would be nice to figure out a way to actually test the hardware with some sample signals (16QAM or something) which can be vector analyzed.

MOD2: I also noticed, that it does not matter if I change the bandwidth (no_prb), the tx and rx sample rate stays the same:
16:08:18.608019 INFO:   [LMSF] PCI:/dev/xtrx0: rxrate=1.920MHz txrate=1.920MHz actual_master=61.440MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=15.360MHz TX_DAC=15.360MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0
[XTRX RF INFO] xtrx_set_samplerate srate_hz = 1920000.000000 master=61.440 MHz
[XTRX RF INFO] rx_rate = 1.92 Mhz tx_rate = 1.92 Mhz
16:08:18.608064 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 00]
16:08:18.608135 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
16:08:18.608208 INFO:   [LSM7] PCI:/dev/xtrx0: 0x0124[02, 02]
16:08:18.608292 INFO:   [LSM7] PCI:/dev/xtrx0: TBB: path 2
[XTRX RF INFO] xtrx_tune_tx_bandwidth rx bandwidth 1.92 Mhz
That must be wrong...

quite busy in my profession job.

lot to do after your valuable input. i will recheck code this weekend. thanx for your effort

dchard commented 2 years ago

@arun1969 don't worry, I am also quite busy. I am trying to gather as much useful data for you, as it is possible.

The short summary of all the above findings:

When SRS-ENB stops, the device is likely not closed properly, and some transmission remains around the center frequency: link

The same signal is also present during normal operation on TX port B.

The TX and RX gain control is not working at all, based on the logs these parts are never called:

XTRX_RF_INFO("rf_xtrx_set_rx_gain: rx gain %f\n",actual);
XTRX_RF_INFO("rf_xtrx_set_tx_gain: tx gain %f\n",actual);

It would be also useful to print the TX and RX gains (after set), plus the used TX/RX ports and paths (TX_H, TX_W, RX_H, RX_W etc.)

The un-equalized LTE signal coming from the XTRX is pretty bad: link, compared to LimeSDR-Mini it is significantly worse. The likely reason is some sampling and/or decimation issue as the 1.92MHz sampling rate is not changed even if I set 50 or 100PRB (10 or 20MHz channel bandwidth) for LTE.
I also noticed that after a couple minutes, the Vector Signal Analyzer looses track of the signal. Further testing showed that the likely reason is overheating. After I removed the bottom plate of my laptop and pushed some cool air to the XTRX, this problem was gone. Therefor it would be very useful to poll the board temperature sensor during SRS-RAN operation and print it on the console every minute or so. This would be even more important for 10-20MHz or 5G operation, if the board is showing signs of overheating at 5MHz duplex operation.
The frequency error of the outputted LTE signal of the XTRX is around 1kHz, which is not very bad compared to the initial frequency error of the LimeSDR-Mini (12kHz). Non the less it would be nice if we can set the XTRX reference clock working mode. I believe there are 3 settings: Internal, External and External+PPS, this last one is GPSDO function. When GPS is not available, tuning the clock DAC would be a useful function as well (on LimeSDR Mini this can be changed via the LimeGui tool). Printing the actual refclock mode on the console during startup would be very useful as well.

arun1969 commented 2 years ago

@arun1969 don't worry, I am also quite busy. I am trying to gather as much useful data for you, as it is possible.

The short summary of all the above findings:

1. When SRS-ENB stops, the device is likely not closed properly, and some transmission remains around the center frequency: [link](https://user-images.githubusercontent.com/8152156/155208066-563bee3b-c4b9-41a1-83d5-2a7a79ee9c09.png)

added xtrx_close in rf_xtrx_close

The same signal is also present during normal operation on TX port B.

2. The TX and RX gain control is not working at all, based on the logs these parts are never called:

XTRX_RF_INFO("rf_xtrx_set_rx_gain: rx gain %f\n",actual);
XTRX_RF_INFO("rf_xtrx_set_tx_gain: tx gain %f\n",actual);

info was not able to display due to log level, suppressed by rf_xtrx_suppress_stdout modified log level to info

It would be also useful to print the TX and RX gains (after set), plus the used TX/RX ports and paths (TX_H, TX_W, RX_H, RX_W etc.)

this is automatic done by libxtrx, i have checked again. good suggestion, still i will implement in xtrx driver. for debug purpose

3. The un-equalized LTE signal coming from the XTRX is pretty bad: [link](https://user-images.githubusercontent.com/8152156/155280698-85d44ecf-dbd6-4bde-a822-686497729d07.png), compared to LimeSDR-Mini it is significantly worse. The likely reason is some sampling and/or decimation issue as the 1.92MHz sampling rate is not changed even if I set 50 or 100PRB (10 or 20MHz channel bandwidth) for LTE.

what configuration you are changing, let me know, i will check again.

4. I also noticed that after a couple minutes, the Vector Signal Analyzer looses track of the signal. Further testing showed that the likely reason is overheating. After I removed the bottom plate of my laptop and pushed some cool air to the XTRX, this problem was gone. Therefor it would be very useful to poll the board temperature sensor during SRS-RAN operation and print it on the console every minute or so. This would be even more important for 10-20MHz or 5G operation, if the board is showing signs of overheating at 5MHz duplex operation.

even i have noticed. it means xtrx board required cooling.

5. The frequency error of the outputted LTE signal of the XTRX is around 1kHz, which is not very bad compared to the initial frequency error of the LimeSDR-Mini (12kHz). Non the less it would be nice if we can set the XTRX reference clock working mode. I believe there are 3 settings: Internal, External and External+PPS, this last one is GPSDO function. When GPS is not available, tuning the clock DAC would be a useful function as well (on LimeSDR Mini this can be changed via the LimeGui tool). Printing the actual refclock mode on the console during startup would be very useful as well.

good suggestion, i have to figure out how to implement.

arun1969 commented 2 years ago

@arun1969 don't worry, I am also quite busy. I am trying to gather as much useful data for you, as it is possible. The short summary of all the above findings:
1. When SRS-ENB stops, the device is likely not closed properly, and some transmission remains around the center frequency: [link](https://user-images.githubusercontent.com/8152156/155208066-563bee3b-c4b9-41a1-83d5-2a7a79ee9c09.png)

added xtrx_close in rf_xtrx_close

The same signal is also present during normal operation on TX port B.

2. The TX and RX gain control is not working at all, based on the logs these parts are never called:

XTRX_RF_INFO("rf_xtrx_set_rx_gain: rx gain %f\n",actual);
XTRX_RF_INFO("rf_xtrx_set_tx_gain: tx gain %f\n",actual);

info was not able to display due to log level, suppressed by rf_xtrx_suppress_stdout modified log level to info

It would be also useful to print the TX and RX gains (after set), plus the used TX/RX ports and paths (TX_H, TX_W, RX_H, RX_W etc.)

this is automatic done by libxtrx, i have checked again. good suggestion, still i will implement in xtrx driver. for debug purpose

3. The un-equalized LTE signal coming from the XTRX is pretty bad: [link](https://user-images.githubusercontent.com/8152156/155280698-85d44ecf-dbd6-4bde-a822-686497729d07.png), compared to LimeSDR-Mini it is significantly worse. The likely reason is some sampling and/or decimation issue as the 1.92MHz sampling rate is not changed even if I set 50 or 100PRB (10 or 20MHz channel bandwidth) for LTE.

what configuration you are changing, let me know, i will check again.

4. I also noticed that after a couple minutes, the Vector Signal Analyzer looses track of the signal. Further testing showed that the likely reason is overheating. After I removed the bottom plate of my laptop and pushed some cool air to the XTRX, this problem was gone. Therefor it would be very useful to poll the board temperature sensor during SRS-RAN operation and print it on the console every minute or so. This would be even more important for 10-20MHz or 5G operation, if the board is showing signs of overheating at 5MHz duplex operation.

even i have noticed. it means xtrx board required cooling.

5. The frequency error of the outputted LTE signal of the XTRX is around 1kHz, which is not very bad compared to the initial frequency error of the LimeSDR-Mini (12kHz). Non the less it would be nice if we can set the XTRX reference clock working mode. I believe there are 3 settings: Internal, External and External+PPS, this last one is GPSDO function. When GPS is not available, tuning the clock DAC would be a useful function as well (on LimeSDR Mini this can be changed via the LimeGui tool). Printing the actual refclock mode on the console during startup would be very useful as well.

good suggestion, i have to figure out how to implement.

Please find latest log output with bold

sudo] password for elcom: --- Software Radio Systems LTE eNodeB ---

Couldn't open , trying /root/.config/srsran/enb.conf Reading configuration file /root/.config/srsran/enb.conf... Couldn't open sib.conf, trying /root/.config/srsran/sib.conf Couldn't open rr.conf, trying /root/.config/srsran/rr.conf Couldn't open rb.conf, trying /root/.config/srsran/rb.conf WARNING: cpu0 scaling governor is not set to performance mode. Realtime processing could be compromised. Consider setting it to performance mode before running the application.

Built in Release mode using 21.10.0.

/home/elcom/work/srsRAN/srsenb/src/enb_cfg_parser.cc:1216: Force DL EARFCN for cell PCI=1 to 1700 Opening 1 channels in RF device=default with args=default Available RF device list: Xtrx Trying to open RF device 'Xtrx' 12:06:32.357163 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000300 12:06:32.369889 INFO: [CTRL] PCI:/dev/xtrx0: XTRX Rev4 (04000113) 12:06:32.369917 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 12:06:32.369934 INFO: [PCIE] PCI:/dev/xtrx0: Device /dev/xtrx0 has been opened successfully CPU Features: SSE2+ SSE4.1+ AVX+ FMA- 12:06:32.482870 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000304 12:06:32.583030 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_GPIO set to 3280mV 12:06:32.583080 INFO: [CTRL] PCI:/dev/xtrx0: LMS PMIC DCDC out set to VA18=1880mV VA14=1480mV VA12=1340mV 12:06:32.586274 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV 12:06:32.596371 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000306 12:06:32.606848 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 12:06:32.611759 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 12:06:32.611778 INFO: [XTRX] refclock 0 12:06:32.611759 INFO: [DBGP] Starting XTRX debug thread 12:06:32.626973 INFO: [XTRX] osc 26058316 cnt 1 12:06:32.627011 INFO: [XTRX] PCI:/dev/xtrx0: Set INT RefClk to 26000000 based on 26058316 measurement 12:06:32.627034 INFO: [LMSF] PCI:/dev/xtrx0: TXm = 61.440 RXm = 61.440 cgen_rate= 61.440 tx_no_decim 0 12:06:32.627986 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 12:06:32.627996 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV 12:06:32.628004 INFO: [LMSF] PCI:/dev/xtrx0: rxrate=1.920MHz txrate=1.920MHz actual_master=61.440MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=15.360MHz TX_DAC=15.360MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0 [XTRX RF INFO] xtrx_set_samplerate srate_hz = 1920000.000000 master=61.440 MHz [XTRX RF INFO] rx_rate = 1.92 Mhz tx_rate = 1.92 Mhz [XTRX RF INFO] xtrx_tune_tx_bandwidth rx bandwidth 1.92 Mhz [XTRX RF INFO] xtrx_tune_rx_bandwidth rx bandwidth 1.92 Mhz RF device 'Xtrx' successfully opened 12:06:32.628903 INFO: [LMSF] PCI:/dev/xtrx0: Set gain 27.0 to 0 on 3 channel [XTRX RF INFO] xtrx_rx_gain: rx gain 27.000000 12:06:32.628959 INFO: [LMSF] PCI:/dev/xtrx0: Set gain 1.0 to 3 on 3 channel [XTRX RF INFO] xtrx_tx_gain: tx gain 0.000000

==== eNodeB started === Type to view trace 12:06:33.412503 INFO: [LMSF] PCI:/dev/xtrx0: TXm = 368.640 RXm = 368.640 cgen_rate= 368.640 tx_no_decim 0 12:06:33.417412 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x00031e 12:06:33.417431 INFO: [CTRL] PCI:/dev/xtrx0: FPGA V_IO set to 1800mV 12:06:33.417445 INFO: [LMSF] PCI:/dev/xtrx0: rxrate=11.520MHz txrate=11.520MHz actual_master=368.640MHz rxdecim=8(h_1) txinterp=8(h_1) RX_ADC=92.160MHz TX_DAC=92.160MHz hintr=0 hdecim=0 delay=0 NRXFWD=0 LML1HID=3 LML2HID=1 RX_div=0 TX_div=0 RX_TSP_div=4 TX_TSP_div=4 FclkRX=0.000 (PHS=0) RXx2=0 **[XTRX RF INFO] xtrx_set_samplerate srate_hz = 11520000.000000 master=368.640 MHz [XTRX RF INFO] rx_rate = 11.52 Mhz tx_rate = 11.52 Mhz [XTRX RF INFO] xtrx_tune_rx_bandwidth rx bandwidth 11.52 Mhz [XTRX RF INFO] xtrx_tune_tx_bandwidth tx bandwidth 11.52 Mhz Setting frequency: DL=1855.0 Mhz, UL=1760.0 MHz for cc_idx=0 nof_prb=50 12:06:33.418105 INFO: [LMSF] PCI:/dev/xtrx0: FE_FREQ rx=0 type=1 freq=1855000000.000000 ch=3 [XTRX RF INFO] rf_xtrx_set_tx_freq: actual freq 1855.00 Mhz 12:06:33.422040 INFO: [LMSF] PCI:/dev/xtrx0: FE_FREQ rx=1 type=0 freq=1760000000.000000 ch=3 [XTRX RF INFO] rf_xtrx_set_rx_freq: actual freq 1760.00 Mhz 12:06:33.426186 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA SKIP MIMO @0.0 12:06:33.426324 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA SKIP MIMO @0.0 12:06:33.426336 INFO: [LMSF] PCI:/dev/xtrx0: Auto RX band selection: LNAW 12:06:33.426363 INFO: [LMSF] PCI:/dev/xtrx0: Set RX band to 3 (W) 12:06:33.426505 INFO: [CTRL] PCI:/dev/xtrx0: RX_ANT: 0 TX_ANT: 0 12:06:33.426514 INFO: [LMSF] PCI:/dev/xtrx0: DC START 12:06:33.427201 INFO: [LMSF] PCI:/dev/xtrx0: AFE TX=[0;0] RX=[1;0] 12:06:33.427481 INFO: [LMSF] PCI:/dev/xtrx0: RBB Restore BW[0]=11520000 12:06:33.427697 INFO: [XTRX] PCI:/dev/xtrx0: RX initialized to 65536 bytes packet size 12:06:33.427706 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA 16 bit SISO (BLK:16384 TS:20000); TX DMA SKIP MIMO @0.0 12:06:33.427718 INFO: [CTRL] PCI:/dev/xtrx0: Placing TC @20000 on 0 data: 0 stat:20 Using avx for xtrxdsp_iq16_sc32 12:06:33.431125 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:16384 TS:0); TX DMA STOP MIMO @0.0 12:06:33.431833 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:16384 TS:0); TX DMA STOP MIMO @0.0 12:06:33.431842 INFO: [LMSF] PCI:/dev/xtrx0: Auto TX band selection: W (Band2) 12:06:33.431863 INFO: [LMSF] PCI:/dev/xtrx0: Set TX band to 2 (W) 12:06:33.431885 INFO: [CTRL] PCI:/dev/xtrx0: RX_ANT: 0 TX_ANT: 0 12:06:33.431893 INFO: [LMSF] PCI:/dev/xtrx0: DC START 12:06:33.432588 INFO: [LMSF] PCI:/dev/xtrx0: AFE TX=[1;0] RX=[1;0] 12:06:33.432858 INFO: [LMSF] PCI:/dev/xtrx0: TBB Restore BW[0]=11520000 12:06:33.432976 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:16384 TS:0); TX DMA 16 bit SISO @0.0 Using avx for xtrxdsp_sc32_iq16 ^CStopping .. 12:06:37.425570 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA SKIP MIMO @0.0 12:06:37.425792 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA SKIP MIMO @0.0 12:06:37.425806 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 12:06:37.425922 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 12:06:37.425936 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA SKIP MIMO @0.0 12:06:37.425946 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA SKIP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 12:06:37.426150 INFO: [BPCI] PCI:/dev/xtrx0: RX DMA STOP MIMO (BLK:0 TS:0); TX DMA STOP MIMO @0.0 12:06:37.427329 INFO: [CTRL] PCI:/dev/xtrx0: RFIC_GPIO 0x000300 12:06:37.428407 INFO: [PCIE] PCI:/dev/xtrx0: Device is closing** --- exiting --- elcom@elcom-desktop:~$

arun1969 commented 2 years ago

@arun1969 don't worry, I am also quite busy. I am trying to gather as much useful data for you, as it is possible. The short summary of all the above findings:
1. When SRS-ENB stops, the device is likely not closed properly, and some transmission remains around the center frequency: [link](https://user-images.githubusercontent.com/8152156/155208066-563bee3b-c4b9-41a1-83d5-2a7a79ee9c09.png)
added xtrx_close in rf_xtrx_close
The same signal is also present during normal operation on TX port B.
2. The TX and RX gain control is not working at all, based on the logs these parts are never called:
XTRX_RF_INFO("rf_xtrx_set_rx_gain: rx gain %f\n",actual);
XTRX_RF_INFO("rf_xtrx_set_tx_gain: tx gain %f\n",actual);
info was not able to display due to log level, suppressed by rf_xtrx_suppress_stdout modified log level to info tx gain is loss and range is 52 to 0 i have set 1 dB loss in next log, you can see in bold

It would be also useful to print the TX and RX gains (after set), plus the used TX/RX ports and paths (TX_H, TX_W, RX_H, RX_W etc.)

this is automatic done by libxtrx, i have checked again. good suggestion, still i will implement in xtrx driver. for debug purpose
3. The un-equalized LTE signal coming from the XTRX is pretty bad: [link](https://user-images.githubusercontent.com/8152156/155280698-85d44ecf-dbd6-4bde-a822-686497729d07.png), compared to LimeSDR-Mini it is significantly worse. The likely reason is some sampling and/or decimation issue as the 1.92MHz sampling rate is not changed even if I set 50 or 100PRB (10 or 20MHz channel bandwidth) for LTE.
what configuration you are changing, let me know, i will check again.
4. I also noticed that after a couple minutes, the Vector Signal Analyzer looses track of the signal. Further testing showed that the likely reason is overheating. After I removed the bottom plate of my laptop and pushed some cool air to the XTRX, this problem was gone. Therefor it would be very useful to poll the board temperature sensor during SRS-RAN operation and print it on the console every minute or so. This would be even more important for 10-20MHz or 5G operation, if the board is showing signs of overheating at 5MHz duplex operation.
even i have noticed. it means xtrx board required cooling.
5. The frequency error of the outputted LTE signal of the XTRX is around 1kHz, which is not very bad compared to the initial frequency error of the LimeSDR-Mini (12kHz). Non the less it would be nice if we can set the XTRX reference clock working mode. I believe there are 3 settings: Internal, External and External+PPS, this last one is GPSDO function. When GPS is not available, tuning the clock DAC would be a useful function as well (on LimeSDR Mini this can be changed via the LimeGui tool). Printing the actual refclock mode on the console during startup would be very useful as well.
good suggestion, i have to figure out how to implement.

dchard commented 2 years ago

Hi @arun1969

Lets start with the good news: the device is now closed properly, there is no spurious emissions after the srsenb app is closed. I will need to take a look at second tx_port to see if the spurious emission is gone from that as well, but this looks good so far.

The console log is also more informative, thanks for that as well.

Issues remaining:

Gain control still does not work: I tried with tx_gain = 30, tx_gain = 20 and tx_gain = 10, no change of output power, and the log also indicates the same thing in all cases:

RF device 'Xtrx' successfully opened
11:50:46.068406 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
11:50:46.068438 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
11:50:46.068476 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 20.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

The RX gain however is set apparently.

Point is: the tx gain setting is still not working.

The un-equalized signal quality is still pretty bad. I am usually trying 5MHz and 10MHz bandwidth on band 3 (1870MHz center freq.), both of them shows the same degradation. I wonder if this is not related to the very low signal power coming from the XTRX? My Agilent Vector analyzer is pretty sensitive and has a high dynamic range, but maybe the modulation performance of the XTRX is not optimal at 0dB gains... The occupied power is -34dBm (0.0005mW) on 10MHz LTE, that is very weak:

The signal quality issue is definitely not caused by the frequency error, I have seen much better outputs with a lot higher freq. error on a LimeSDR-Mini.

Full logs:

I wanted to share some full logs with you:

LTE FDD 5MHz@1870MHz: https://pastebin.com/HzQ6KBrP

LTE FDD 10MHZ@1870MHz: https://pastebin.com/0rUMVbGL

arun1969 commented 2 years ago

Hi @arun1969

Lets start with the good news: the device is now closed properly, there is no spurious emissions after the srsenb app is closed. I will need to take a look at second tx_port to see if the spurious emission is gone from that as well, but this looks good so far.

The console log is also more informative, thanks for that as well.

Issues remaining:
1. Gain control still does not work: I tried with tx_gain = 30, tx_gain = 20 and tx_gain = 10, no change of output power, and the log also indicates the same thing in all cases:
tx_gain = 30db xtrx will set 30 - tx_gain = 0db tx_gain = 20db xtrx will set 30 - tx_gain = -10db tx_gain = 10db xtrx will set 30 - tx_gain = -20db with modified calculation
RF device 'Xtrx' successfully opened
11:50:46.068406 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
11:50:46.068438 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
11:50:46.068476 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 20.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000
The RX gain however is set apparently.

Point is: the tx gain setting is still not working. rf_xtrx_set_tx_gain calculation changed because of xtrx_set_gain require only -ve gain i.e Loss.
2. The un-equalized signal quality is still pretty bad. I am usually trying 5MHz and 10MHz bandwidth on band 3 (1870MHz center freq.), both of them shows the same degradation. I wonder if this is not related to the very low signal power coming from the XTRX? My Agilent Vector analyzer is pretty sensitive and has a high dynamic range, but maybe the modulation performance of the XTRX is not optimal at 0dB gains... The occupied power is -34dBm (0.0005mW) on 10MHz LTE, that is very weak:
The signal quality issue is definitely not caused by the frequency error, I have seen much better outputs with a lot higher freq. error on a LimeSDR-Mini.
4. Full logs:
I wanted to share some full logs with you:

LTE FDD 5MHz@1870MHz: https://pastebin.com/HzQ6KBrP

LTE FDD 10MHZ@1870MHz: https://pastebin.com/0rUMVbGL

dchard commented 2 years ago

@arun1969

Pulled your latest mods, but still: no matter what I set as tx_gain, the output power is still the same.

with --rf.tx_gain 0

RF device 'Xtrx' successfully opened
12:45:09.215479 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:45:09.215562 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 30.000000 converted to (30.0-gain) = 0.000000
12:45:09.215623 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 0.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

With --rf.tx_gain 10

RF device 'Xtrx' successfully opened
12:45:47.305694 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:45:47.305759 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 10.000000 converted to (30.0-gain) = 20.000000
12:45:47.305817 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 20.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

With --rf.tx_gain 30

RF device 'Xtrx' successfully opened
12:46:23.647698 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:46:23.647763 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 30.000000 converted to (30.0-gain) = 0.000000
12:46:23.647826 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 0.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

In all the above cases, the actual (measured) output power was the same (-34dBm total output power).

MOD:

Looking at your rf_xtrx_imp.c file, this part might be wrong:

    /* Set info structure */
    h->info.min_tx_gain = 0.0;
    h->info.max_tx_gain = 30.0;
    h->info.min_rx_gain = -52.0;
    h->info.max_rx_gain = 0.0;

The devices however reports the following capabilities: TX chain:

  Full gain range: [0, 52] dB
    PAD gain range: [-52, 0] dB

RX chain:

 Full gain range: [-12, 61] dB
    LNA gain range: [0, 30] dB
    TIA gain range: [0, 12] dB
    PGA gain range: [-12, 19] dB

arun1969 commented 2 years ago

@arun1969

Pulled your latest mods, but still: no matter what I set as tx_gain, the output power is still the same.

with --rf.tx_gain 0

RF device 'Xtrx' successfully opened
12:45:09.215479 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:45:09.215562 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 30.000000 converted to (30.0-gain) = 0.000000
12:45:09.215623 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 0.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

With --rf.tx_gain 10

RF device 'Xtrx' successfully opened
12:45:47.305694 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:45:47.305759 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 10.000000 converted to (30.0-gain) = 20.000000
12:45:47.305817 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 20.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

With --rf.tx_gain 30

RF device 'Xtrx' successfully opened
12:46:23.647698 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 30.0 to 0 on 3 channel
12:46:23.647763 INFO:   [LSM7] PCI:/dev/xtrx0: RFE: set_lna(0 -> 0) => 15
[XTRX RF INFO] xtrx_set_gain: rx gain 30.000000
[XTRX RF INFO] tx gain 30.000000 converted to (30.0-gain) = 0.000000
12:46:23.647826 INFO:   [LMSF] PCI:/dev/xtrx0: Set gain 0.0 to 3 on 3 channel
[XTRX RF INFO] xtrx_set_gain: tx gain 0.000000

In all the above cases, the actual (measured) output power was the same (-34dBm total output power).

MOD:

Looking at your rf_xtrx_imp.c file, this part might be wrong:

  /* Set info structure */
  h->info.min_tx_gain = 0.0;
  h->info.max_tx_gain = 30.0;
  h->info.min_rx_gain = -52.0;
  h->info.max_rx_gain = 0.0;

The devices however reports the following capabilities: TX chain:

  Full gain range: [0, 52] dB
    PAD gain range: [-52, 0] dB

RX chain:

 Full gain range: [-12, 61] dB
    LNA gain range: [0, 30] dB
    TIA gain range: [0, 12] dB
    PGA gain range: [-12, 19] dB

Sorry there was typo mistake while commit on github,which corrected immediately (need to pull again).

xtrx -20db xtrx 0db

dchard commented 2 years ago

@arun1969

Still not correct, however it kinda started to work.

With --rf.tx_gain 0 I am getting -33dBm total output power. With --rf.tx_gain 10 I am getting -49dBm total output power. With --rf.tx_gain 20 I am getting -42dBm total output power. With --rf.tx_gain 30 I am getting -32dBm total output power.

However, we are still not able to get above -33dBm, which is very weak, and definitely not the maximum.

arun1969 commented 2 years ago

@arun1969

Still not correct, however it kinda started to work.

With --rf.tx_gain 0 I am getting -33dBm total output power. With --rf.tx_gain 10 I am getting -49dBm total output power. With --rf.tx_gain 20 I am getting -42dBm total output power. With --rf.tx_gain 30 I am getting -32dBm total output power.

However, we are still not able to get above -33dBm, which is very weak, and definitely not the maximum. @dchard setting tx_gain to 0 is incorrect as per srsran source code. i have checked again, i believe there is some issue with xtrx as mentioned in #42

dchard commented 2 years ago

OK, so according to the device, the TX capability looks like this:

Full gain range: [0, 52] dB
    PAD gain range: [-52, 0] dB

So the XTRX expects TX gain (XTRX_TX_PAD_GAIN) between 0 and -52dB.

I hacked in gain = 0.0 ; and I am till getting -33dBm total output power. When I hacked in gain = -52.0; then the signal level was below detection threshold.

As the maximum output power should be around 0dBm, this is clearly wrong, but maybe it is not the TX gain value that causes this issue, but something else.

dchard commented 2 years ago

@arun1969

You have to fix this part as well:

    if(gain > 30.0)
        gain = 30.0;

    XTRX_RF_INFO("tx gain %f converted to (30.0-gain) = %f\n",gain,(gain - 30.0));
    gain = gain - 30.0;

to this:

    if(gain > 52.0)
        gain = 52.0;

    XTRX_RF_INFO("tx gain %f converted to (52.0-gain) = %f\n",gain,(gain - 52.0));
    gain = gain - 52.0;

dchard commented 2 years ago

I noticed something else: the spectrum of the XTRX output is not flat, but shaped more like a triangle.

And where the DC offset should be, there is a huge spike:

MOD: interestingly enough, the 20MHz LTE signal does not have the weird flatness issue (the 5 and 10MHz signals do fail):

arun1969 commented 2 years ago

I noticed something else: the spectrum of the XTRX output is not flat, but shaped more like a triangle.

And where the DC offset should be, there is a huge spike:

MOD: interestingly enough, the 20MHz LTE signal does not have the weird flatness issue (the 5 and 10MHz signals do fail):

@dchard Please find attached simple test program to generate waveform, which can be useful to test xtrx board. this could be great help for you to test xtrx board behavior. it is just one file require xtrx and liquid dsp library.

gcc xtrx_tx_test.c -o xtrx_tx_test -lxtrx -lliquid xtrx_tx_test.zip

dchard commented 2 years ago

@arun1969 sure thing, will test later today. Srs-,ran also has a generator, called pdsch_enodeb, but it does not work with xtrx yet. If you want to take a look.

MOD: this is the one: https://github.com/arun1969/srsRAN/blob/master/lib/examples/pdsch_enodeb.c

With this we can generate complex downlink OFDM signal of LTE, even PDSCH (traffic), this would make it a lot easier to test all relevant signals in the same time. You can even choose PDSCH modulation (QPSK, 16QAM, 64QAM, maybe 256QAM is also available). Would be great if you can make this work with XTRX.

dchard commented 2 years ago

@arun1969

The xtrx_tx_test compiles and runs fine. Question is how to set up the VSA to get the modulation analysis for it. These are the settings available:

arun1969 commented 2 years ago

@arun1969 sure thing, will test later today. Srs-,ran also has a generator, called pdsch_enodeb, but it does not work with xtrx yet. If you want to take a look.

MOD: this is the one: https://github.com/arun1969/srsRAN/blob/master/lib/examples/pdsch_enodeb.c

With this we can generate complex downlink OFDM signal of LTE, even PDSCH (traffic), this would make it a lot easier to test all relevant signals in the same time. You can even choose PDSCH modulation (QPSK, 16QAM, 64QAM, maybe 256QAM is also available). Would be great if you can make this work with XTRX.

@dchard yes there is problem with xtrx driver in case there is no timestamp, i will look into by today.

arun1969 commented 2 years ago

@arun1969

The xtrx_tx_test compiles and runs fine. Question is how to set up the VSA to get the modulation analysis for it. These are the settings available:

@dchard replace calling of gen_random_mod with gen_random_qam16 code in test file, add following code in test static void gen_random_qam16(float complex* x,unsigned int num_symbols,int k) { // options unsigned int bps = 1; // number of bits/symbol

// derived values
unsigned int num_samples = k * num_symbols;
unsigned int M = 1 << bps;
// create mod/demod objects
modulation_scheme ms = LIQUID_MODEM_QAM16;

// arrays
unsigned int* sym_in = (unsigned int*)malloc(num_symbols*sizeof(unsigned int));

// create modem objects
modem mod = modem_create(ms);

// print modulator
modem_print(mod);

// generate message signal
for(int idx = 0;idx < num_symbols;idx++)
    sym_in[idx] = rand() % M;

// modulate signal
for(int idx = 0;idx < num_symbols;idx++)
    modem_modulate(mod,sym_in[idx],&x[k*idx]);

// destroy modem objects
modem_destroy(mod);
free(sym_in);

}

arun1969 commented 2 years ago

@arun1969 sure thing, will test later today. Srs-,ran also has a generator, called pdsch_enodeb, but it does not work with xtrx yet. If you want to take a look. MOD: this is the one: https://github.com/arun1969/srsRAN/blob/master/lib/examples/pdsch_enodeb.c With this we can generate complex downlink OFDM signal of LTE, even PDSCH (traffic), this would make it a lot easier to test all relevant signals in the same time. You can even choose PDSCH modulation (QPSK, 16QAM, 64QAM, maybe 256QAM is also available). Would be great if you can make this work with XTRX.

@dchard yes there is problem with xtrx driver in case there is no timestamp, i will look into by today.

@dchard xtrx Done driver now works with pdsch_enodeb please pull the code.

dchard commented 2 years ago

@arun1969 on it. This is great progress. After the last year I was skeptical that we will ever have SRS working. 👍

dchard commented 2 years ago

@arun1969 I modified the xtrx_tx_test.c for 16 QAM, and I think it works, however the demodulator settings on the VSA are still unclear. For example, what is the symbol rate of the signal? Tried with 1.92MHz, but that is not it (you can also see the state definitions, we might need to modify that as well for successful demod):

MOD: those 5 spikes in the signal however.... When I analyzed 16QAM and 64QAM single carrier (Cable TV) signals, those spikes where not there for sure :-)

dchard commented 2 years ago

@arun1969 I can confirm that the "pdsch_enodeb" test app now works. It produces the same signal degaradation as the SRS-ENB app (this is un-equalized 5MHz LTE signal with 16QAM (MCS15) PDSCH traffic):

Note the same ringing effect around RS and PDSCH signals plus the triangle shape of the spectrum. The power level is also low, as you can see and this is with maximum TX gain.

arun1969 commented 2 years ago

@arun1969 I modified the xtrx_tx_test.c for 16 QAM, and I think it works, however the demodulator settings on the VSA are still unclear. For example, what is the symbol rate of the signal? Tried with 1.92MHz, but that is not it (you can also see the state definitions, we might need to modify that as well for successful demod):

MOD: those 5 spikes in the signal however.... When I analyzed 16QAM and 64QAM single carrier (Cable TV) signals, those spikes where not there for sure :-)

@dchard it 1.92Mhz, let me see modulation code again.

arun1969 commented 2 years ago

@arun1969 I can confirm that the "pdsch_enodeb" test app now works. It produces the same signal degaradation as the SRS-ENB app (this is un-equalized 5MHz LTE signal with 16QAM (MCS15) PDSCH traffic):

Note the same ringing effect around RS and PDSCH signals plus the triangle shape of the spectrum. The power level is also low, as you can see and this is with maximum TX gain.

@dchard please suggest where we should target. even i am looking into libxtrx, specially LMS7002M registers.

arun1969 commented 2 years ago

@arun1969 I modified the xtrx_tx_test.c for 16 QAM, and I think it works, however the demodulator settings on the VSA are still unclear. For example, what is the symbol rate of the signal? Tried with 1.92MHz, but that is not it (you can also see the state definitions, we might need to modify that as well for successful demod): MOD: those 5 spikes in the signal however.... When I analyzed 16QAM and 64QAM single carrier (Cable TV) signals, those spikes where not there for sure :-)

@dchard it 1.92Mhz, let me see modulation code again.

@dchard i don't have VSA, will try to use matlab with bladerf.

dchard commented 2 years ago

@dchard please suggest where we should target. even i am looking into libxtrx, specially LMS7002M registers.

I just wanted to say the same thing. Either low level LMS stuff that is missing (maybe IQ imbalance or DC offset?), or something similar. If we can get your 16QAM test code to work, that would be a good start though.

MOD: the device reports it can do "Corrections: DC offset, IQ balance", maybe we are missing one of them or both?

Question: I have a LimeSDR-Mini which can produce validated 5 and 10MHz LTE signals with good vector quality with SRS-ENB. Can we dump the LMS registers from that somehow?

xtrx-sdr / images

Support of srsLTE #68