Post Go back to editing

ORX_CTRLs in 5GNR TDD

Category: Datasheet/Specs
Product Number: ADRV9029

Hi.

We are using ADRV9029 in 5GNR application, TDD mode. We are using also internal DPD processor. We have a question about ORX_CTRL pins control, we did not found clear information about it.

Based on our testing we understand that, when internal DPD core is used, digital ORX_CTRLs should be kept 0 (in pin mode control) or kept 0 with adi_adrv9025_RxTxEnableSet in SPI mode.

We believe that, in both SPI and pin modes, ORX_CTRLs are used to push ORX channel sampled data to JESD interface. They actually dont control ORX sampling for internal DPD core.

Considering this approach, how does the internal DPD core select the proper time windows for ORX sampling? Automatically?

Thanks!

  • Based on our testing we understand that, when internal DPD core is used, digital ORX_CTRLs should be kept 0 (in pin mode control) or kept 0 with adi_adrv9025_RxTxEnableSet in SPI mode.

    Yes, your understanding is correct.

    We believe that, in both SPI and pin modes, ORX_CTRLs are used to push ORX channel sampled data to JESD interface. They actually dont control ORX sampling for internal DPD core.

    Yes, your understanding is correct.

    Please see below, when one side of the ORX data is being sent to FPGA over JESD, the other side of the ORX data will be used for internal DPD calibration.

    So, when ORC_CTRL_A is high, CTRL_B and CTRL_C are low, ORX1 data goes to JESD and during this time, depending on the ARM scheduling , either TX3 or TX4 DPD or LOL can be running.

    Please see UG for more details.

  • Thank you Ramarao but the time diagram shows still an external DPD implementation approach.

    To clarify for our use case, using internal DPD/CFR WITHOUT JESD ORX push (just RX/TX samples move on JESD).

    In this case I understand that, regardless ORX control mode (pin or SPI), we should always keep ORX_CTRL=0 and DPD core will automatically take care of used channels (sampling for DPD kernel usage and needed calibrations). So, for example, in 4x4 mode, the internal DPD core will automatically schedule ORX1/ORX2/ORX3/ORX4 sampling, no? A question is, in this operation mode (internal DPD/CFR WITHOUT JESD) do we have a mean to select time window and channel where internal DPD will use for coefficient update algo? Or, we can use ORX_CTRL not as activators (as for JESD) but as inhibitors (this is not the same as enabling anyway, for example selecting ORX1 for JESD makes ORX2/ORX3/ORX4 usable by internal DPD core for coefficient update algo or calibrations).

    Please let me know how is internal DPD/CFR WITHOUT JESD designed at ADI in time domain.

    Thanks!

  • I understand that you are using internal DPD. Even if you use internal DPD, there may be a need to monitor the ORX data through JESD on FPGA while the DPD is working on another ORX side. In that case, user need to enable CTRL_A- if not you can keep this pin LOW always.

    Coming to the other ORX control pins, you can change these PINs timing which are usually driven by FPGA. The user has the control to change these PIN timings. For eg, every 250ms, you can keep changing these control PIN timings which means each TX is available on that particular ORX for 250ms of time.

    Not sure if this help, let me know if you have any follow up questions.

  • Hi Ramarao. New data from my experiments.

    History:

    My question was coming from a problem that we see in TDD mode. In TX only mode, we get DirectEvm down to 1.8% maximum. When we switch to TDD mode, we get 18%. We have investigated in the last two weeks and we found that problem is related to:

    a) in hardware, we multiplex ORX path with RX with RF switch; when we select RX, we dont terminate ORX port so its just the RF switch isolation

    b) we discovered that ORX is "listened to" at all times, regardless the TX_EN control which is actually enabling/disabling internal DPD

    Considering these, the problem that we have is that we get RX flowing into ORX and affects ORX measurements hence DPD DirectEvm. We have tried to "disable" ORX sampling by enabling the JESD ORX path with ORX_CTRL. This does not work ok, because in all pin modes, this is supposed to select not to deselect. So we can deselect one channel at a time, we need to deselect ALL during RX slot.

    Question:

    How can we do this? Using ORX_CTRL (we have all of them) to deselect during TDD RX slot all ORX samplings?

    I forgot to specify that our system is 4x4 with 4 ORX feedbacks, except that they are not always connected to PA. Between PA and ADRV we have only one RF receive line per channel (so 4x). This RF receive line is RF switched at ADRV between RX input (on TDD RX slot) and ORX input (on TDD TX slot). As mentioned, during RX slot, ADRV ORX input stays connected to RF switch but is not terminated. 

    Ive tried to sketch how I can use the dual mode 4 pin in my usecase. Please confirm, Per this table, _A and _C are used for enable/disable and _B/_D for selection. Will this inhibit DPD tracking calibration during RX slot?

    In API code, there is something strange in regards to ORX controls which are called differently (probably the digital IP names?).

    *  The table below outlines the various ORx enable modes and corresponding ORx select mechanisms.
    *
    *                  ORx PIN Mode     |    ORx Select Mechanism
    *      -----------------------------|------------------------------------------------------------------------------------
    *                        SPI Mode   | ORx enable and channel select is accomplished through SPI registers
    *         Single Channel 3 Pin Mode | ORX_ENABLE[0] is enable/disable ctrl. ORx select is accomplished by ORX_ENABLE[2:1]
    *         Single Channel 2 Pin Mode | ORX_ENABLE[0] is enable/disable ctrl. ORx select is accomplished by SPI registers.
    *                                   | ORx select is multiplexed between 2 possible ORx channels depending on the level of ORx_ENABLE[1] pin
    *         Single Channel 1 Pin Mode | ORX_ENABLE[0] is enable/disable ctrl. ORx select is accomplished by SPI registers.
    *         Dual Channel 4 Pin Mode   | ORX_ENABLE[1:0] pins are enable/disable ctrl. ORx select is accomplished by ORX_ENABLE[3:2]
    *         Dual Channel 2 Pin Mode   | ORX_ENABLE[1:0] pins are enable/disable ctrl. ORx select is accomplished by SPI registers

    This confuses me. Is the ORX_CTRL_A = ORX_ENABLE0, ORX_CTRL_B = ORX_ENABLE3, ORX_CTRL_C = ORX_ENABLE1 and ORX_CTRL_D = ORX_ENABLE4? Or in fact ORX_CTRL_[D:A] = ORX_ENABLE[1:0].

    Thanks.

  • Considering these, the problem that we have is that we get RX flowing into ORX and affects ORX measurements hence DPD DirectEvm. We have tried to "disable" ORX sampling by enabling the JESD ORX path with ORX_CTRL. This does not work ok, because in all pin modes, this is supposed to select not to deselect. So we can deselect one channel at a time, we need to deselect ALL during RX slot.

    Is this TDD system? Why would the RX be ON when TX is ON/ ORX is ON or Why the ORX is ON when RX is ON?

    How can we do this? Using ORX_CTRL (we have all of them) to deselect during TDD RX slot all ORX samplings?

    During RX slot, the TX data wont be there and ORX is not expected to get any data as the TX data is fed back to ORX.

    I think your understanding is fine and DPD should not be limited in this case.