Post Go back to editing

Very noisy signal at TX output

Hi AD support,

I'm trying to have some preliminary DPD tests with ADS9-V2EBZ + EVAL-ADRV9029-HB on TES-GUI-6.3.0.5. I'm using profile 50 Link sharing, Tx input rate 122.88MHz, and thus 1228800 samples for 10ms signal input. However, while connecting my spectrum analyzer right to the Tx output, it shows a very noisy constellation:

This is my original LTE signal:


And this is the signal shown in TES GUI, seems to be clean and no clipping:

After some initial debug efforts, the IQ offset shown in VSA is very high, which could be related to carrier feedthrough. Therefore, I suspect that I'm missing some configurations or RF chain calibrations.

My signal can be found attached: modulated_readback_Tx1.txt

My VSA setup can be found attached: LTE_DL_20MHz_DEMOD_ConstellationView3.zip



fix typos, add VSA setx
[edited by: MasonH at 2:00 AM (GMT -4) on 29 Apr 2022]
Parents
  • The EVM plot above you shown is at Tx. out of the chip or at the PA output? At what output power are you measuring the EVM? If you are measuring at the PA out, how much ACLR are you getting after DPD?

    If the ACLR is good, try to test at 3dB backoff power and check the EVM.

    Also, share us the DPD statistics for further analysis.

    Can you measure the EVM, ACLR at the TX out of the chip as well if not done already? 

    On the calibrations perspective, can you check if you have enabled LO leakage init calibration? Can you check the LO leakage performance, by sending a tone at 10MHz offset?

  • Hi Ramarao,

     I’m measuring output right at ADRV9029 Tx1 port, not involving any PA or DPD. The channel power is -10 dBm, PAPR 11.3 dB. ACPR is mediocre, at -44dBC as in the images.

    In my setup, I just use Tx1. Does it affect the calibration? As I remember, LO leakage calibration is enabled by default. I will check again to ensure.

  • Please check the PLL lock status by following the below procedure

     Monitoring PLL lock status on ADRV9026 

    Can you test with Rx to Tx loopback using the attached script?

    Provide the required signal from the signal generator on the Rx input (-30dBm) and check the Tx output on the spectrum analyser and while measuring EVM, use IQ swap.

    1423.ADRV9025_LoopRxDataToTx_Enableset.zip

    Ext. LO option is not supported.

    Can you check at lesser output power, may be at 6dB backoff power from what you are measuring right now.

    Can you enable all Init cals and Tracking cals (TX QEC and LO Leakage) and check once if not done already?

  • Can you check at lesser output power, may be at 6dB backoff power from what you are measuring right now.

    I tried 10dB additional back off, still the same result. It's clear that I don't saturate the DAC according to the tracking on Tx tab.

    Can you enable all Init cals and Tracking cals (TX QEC and LO Leakage) and check once if not done already?

    I enabled them all in everything measurements, except "External Path Delay", "Rx Gain Delay/Phase" and "Tx Attenuation Delay/Table".

    Can you test with Rx to Tx loopback using the attached script?

    It not clear to me how to run this script. Is it correct to follow this procedure: connect signal generator to Rx1, connect spectral analyzer to Tx1, enable the signal generator, run the python script in TES-Iron Python?

    Please check the PLL lock status by following the below procedure

    I read several posts and answers but it is still not clear to me how to run the C API to check the PLL. Can you please link a tutorial, or is there a version that can be run using TES-Iron Python?

    Meanwhile, I recheck the tone test from Tx output and compare it with one of my clock generator. This is the tone from clock generator, which shows 60dB difference to second peaks within 2kHz span

    This is signal from Tx port, which shows 30 dB to second peaks:

    Is it the normal value? I don't see it in the datasheet. I also add measurement at 2Mhz span.

  • The Reference clock does not seem to be clean enough, spurs are observed and so the Tx output.. The requirements for the Ref. clock are explained in the UG, Page 73.

    I believe you are providing the reference clock from an RF signal generator, if not can you try with that?

    Are you testing on the HB variant of the board, the Tx output power seem to be less? Using any external attenuator or Internal Tx attenuation of the chip?

    Page 264 of the UG explains how to run the python scripts. Go to IronPython tab in the GUI, load the script and run it.

  • Yes the clock is from a RF signal generator. I will look for the requirements.

    I’m using HB variation, with no attenuator except -10 dB attenuation while generating tonetest.

    i understand how to run Python code, but i have not understood how to run C code APi.

  • Are you using your custom board or EVB? If you are using EVB, you can directly run the script that i shared earlier following the UG.

    You need to develop C code API and try testing it.

  • Hi Ramarao,

    Today I conducted 3 tests on this problem:

    1. Tone test on Tx port. Before that, I changed my clock source to Keysight N5182B and checked it phase noise with 500Hz and 2MHz span, which show at least 80dB difference:

    However, the tone test that I have from the Tx port is worse. I checked the tone with 500Hz and 2MHz span, which shows only difference at 35dB:

    2. QPSK single carrier test on Tx port. Instead of OFDM signal, I tried a simpler single carrier test. The constellation of my generated signal is very clean:

    However, the signal from Tx port is still noisy in circular pattern:

    3. QPSK single carrier test on Rx port, loop back to Tx. While trying loopback test Rx-Tx as you suggested, the same problem still persists:

    From all those tests and observations, it seems to me that there is phase noise in my testbed. However, as I checked it is not from my clock source. Therefore, I conclude that it is from either PLL or LO. I didn't try the API using C to check PLL locks, as I don't understand how to, the UG is not very clear about it.

    What do you think I should check next? Should I start the board replacement process?

  • My understanding is that you are using EVB to do all these measurements. You can directly run these scripts in the 'ironpython' tab of the GUI. Below are the scripts to check the PLL loop bandwidth and PLL lock status of all LOs. Check if all the LO supplies are as per the specification once.

    PLL_Scripts.zip

  • Yes, it is an EVB-HB. Thanks, I will try to run those and keep you updated.

  • Hi Ramarao,

    This is what I get from the script:

    Connected
    Aux PLL locked
    LO2 PLL locked
    LO1 PLL unlocked
    CLK PLL locked

    Connected
    LO2 FREQUENCY = <adrv9010_dll.Types.adi_adrv9010_PllLoopFilterCfg_t object at 0x000000000000002B [adrv9010_dll.Types.adi_adrv9010_PllLoopFilterCfg_t]> HZ loop filter BW = 100 Phase margin = 60 Power scale = 10
    (0, <adrv9010_dll.Types.adi_adrv9010_PllLoopFilterCfg_t object at 0x000000000000002B [adrv9010_dll.Types.adi_adrv9010_PllLoopFilterCfg_t]>)

    The file "PLL_Loop_filter_Status" output seems to be buggy, so I added another print(z) command. Is 0 the correct return value?

    --------

    One thing I noticed is that both your files and the files created with "New script" is importing from adrv9010_dll, while in the UG 1727 page 265, it imports from adrv9025_dll. I tried loading from adrv9025_dll but it cannot find that one. Am I using an obsolete version? I'm using version 6.3.0.5 in specific.

    Also, I added another 2 lines:

    lo2 = link.platform.board.Adrv9010Device.RadioCtrl.PllFrequencyGet(Types.adi_adrv9010_PllName_e.ADI_ADRV9010_LO2_PLL, 0)
    print "LO2 set to :" + str(lo2[1])

    which show the frequency to be 3.5Ghz, as I set

    I tried playing around with PLL loop filter, from 50kHz to 200kHz, and it changes the generated tone a bit as in the following figure: (lowest to highest: 50kHz to 200kHz)

    I can see some improvement on the tone, however it's still not good enough for single carrier QPSK test.

    I also include my clock source signal, which shows that there is around 60dB difference between my fundamental and 1st order harmonic, which seems to be good in my opinion.

  • I guess you are using LO2, can you check with LO1 once ?

    Is this issue observed on all the channels? Can you test with a different UC?

Reply Children