Post Go back to editing

MYKONOS_getObsRxDecPower returns 0

As discussed in a previous thread, I am using the function MYKONOS_getObsRxDecPower to monitor our transmit power for use in an AGC mode.

Now that we have started to integrate on our custom board, I've come across a case where the MYKONOS_getObsRxDecPower function is returning 0.  Same code, same config, running on the 9375 EVM works as expected. 

The header for MYKONOS_getObsRxDecPower says 

"If the receiver is disabled during the power measurement, this function returns a 0 value for rx2DecPower_mdBFS"

However, I have all the pin control mode settings set to 0 in the mykonosArmGpioConfig_t structure, so I don't see how that could be the case when comparing EVM operation to custom board operation.  

To troubleshoot, I've disabled Dpd, Clgc, Vswr.  Rx and Orx Gain control is set to MGC.  

I do occasionally get good results, a log is shown below.

I was thus wondering, what might all cases be where MYKONOS_getObsRxDecPower will return a 0?

The readings below are taken at approximately every 500 msec intervals.  The input signal is very low, so the 44750 is a realistic value, whereas 0 is not.

obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 44750
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0
obsRxDecPower_mdBFS 0

The code for the above log is below and runs in a low priority task.  sleeps are in msec.

while(1)
{
    if (txEnabled)
    {
        MYKONOS_setObsRxPathSource(&mykDevice, OBS_RX1_TXLO);

        sleep(10);

        uint16_t obsRxDecPower_mdBFS = 0;
        MYKONOS_getObsRxDecPower(&mykDevice, &obsRxDecPower_mdBFS);

        sleep(10);

        MYKONOS_setObsRxPathSource(&mykDevice, OBS_INTERNALCALS);

        TRACE1(DspTrace::TX_AGC_LOG,"obsRxDecPower_mdBFS %d", obsRxDecPower_mdBFS);

    }

    sleep(500);
}

  • What is the input signal level that you are feeding to the input port? If the signal level is high and it is saturating the path, then the ORX dec power can readback a value of zero. Can you change to AGC mode and then check?

  • My apologies, I should have mentioned that.  Since the 0 represents FSP, I thus set the Tx Atten to maximum, so the level being fedback is very low.  Our tx output is connected to a directional coupler that has its tap port connected to the ORX input.  The 44750 value that comes out occasionally is the correct expected value.  I think I mentioned that this seems to work just fine on the EVM based system, but not on our custom board, so I am suspecting it is a physical interface type issue, though I can't see what would cause this.  

  • Are you configuring the chip in TDD mode or FDD mode? Are you using pin mode or SPI mode to switch between RX and TX states? Can you check the ORX power readback  in FDD mode?

  • I've made some progress, but by guessing at a few things...  But to answer your questions, we are in FDD mode and SPI control only.  So, the ORX power readback is being read in FDD mode.

    I discovered that the value 44750 is the minimum value which can be returned by the getObsRxDecPower function.  I noticed that when comparing our EVM setup to our Final Form Factor setup.  The two setups have very different RF chains.  I believe the EVM setup will present a higher signal to the ORx port.  So, in our FFF setup I have to increase the signal level to get above the 44750 minimum.  However, this still does not explain why I get 0's.  As I stated previously, my signal is low not high, so I am confident I am not saturating the ORx thus the 0 value is not real.

    Staring at the config parameters, I got to wondering how the parameter pmdMeasDuration might be affecting this.  I know there is scheduling of various measurements in the ARM.  0 might be an indication that the measurement was not taken, similar to how getClcgStatus can return an error.  Since I am not using ORxAGC mode, I have it set to MGC, I suspected there was no reason to set the pmdMeasDuration value, so I changed it to 0.  This seems to have helped dramatically.  I do rarely see a value of 0 but I think I can safely ignore that since we will never overload the ORx input, but I am getting more reliable values now.

    It would still make me feel alot better if someone could look at the ARM code and tell me under what circumstances getObsRxDecPower would return a 0 instead of a real power reading.

     

  • ORX path doesnot support AGC mode. 

    Can you check with CW signal as input tone (keep the power measurement to the default value)and then check if you are still getting zero readback at the ORX output power?

    The measurement duration of the power measurement blocks (denoted by pmdMeasDuration) sets the number of samples that the power measurement blocks use to evaluate the received signal power level. Power measurement duration value will affect the accuracy of the power measurement but will not affect the power value to change between 0 and the lowest value.

  • We may have found the root cause of the issue.  Over time we had changed the clocking scheme for this waveform and along the way the config structure orxAdcCustom was not correctly updated.  It was from an older config with a slower clock rate.  Apparently that can result in the MYKONOS_getObsRxDecPower() call returning a 0 and being temperature sensitive.