MYKONOS_getClgcStatus orxRms returns wrong channel

I thought  should add that I am using the default ArmGpioConfig which sets orxPinMode = 0, which should make the ORX input under control of the ARM.

static mykonosArmGpioConfig_t armGpio =

{

0, // useRx2EnablePin; /*!< 0= RX1_ENABLE controls RX1 and RX2, 1 = separate RX1_ENABLE/RX2_ENABLE pins */

0, // useTx2EnablePin; /*!< 0= TX1_ENABLE controls TX1 and TX2, 1 = separate TX1_ENABLE/TX2_ENABLE pins */

0, // txRxPinMode; /*!< 0= ARM command mode, 1 = Pin mode to power up Tx/Rx chains */

0, // orxPinMode; /*!< 0= ARM command mode, 1 = Pin mode to power up ObsRx receiver*/

I thought maybe I solved my problem by adding a call to MYKONOS_setObsRxPathSource() before the call to getClgcStatus(), but that did not seem to help.

Are you able to see data on ORX in GUI ? In DPD GUI change path to Tx 2 in Tx channel drop down.

Make sure Tx1 and Tx2 and Orx 1 and Orx2 are enabled. 

Tx calibrations will only run if radioOn and the obsRx path is set to OBS_INTERNAL_CALS. (MYKONOS_setObsRxPathSource) 

My apologies, I should have provided more information. 

I am not using the DPD GUI, we are controlling this via custom code on a DSP processor.  ORX2 does not seem to work even if I start using TX2/RX2/ORX2 from a reset condition.  The ORX input still seems to be ORX1.

When I start on RX1/TX1/ORX1 behavior is as desired.  When we switch from 1 to 2 I do a full initialization and re-calibration just like I would when doing a full reset power up start.  This seemed necessary as the rxChannels and txChannels parameters are used in many API functions and there is no direct API call to switch inputs/outputs.

To your point about OBS_INTERNAL_CALS, I noticed that in the UG last night.  In fact, it makes me wonder how ORX1 even works at all.  At the end of configuration and calibration, I do the follow two commands...

 MYKONOS_setObsRxPathSource(&mykDevice, OBS_RXOFF);

 MYKONOS_setObsRxPathSource(&mykDevice, OBS_INTERNALCALS);

Then, I have a background task that runs every 500msec which calls

MYKONOS_getClgcStatus()

Again, this resulted in ORX1 working as desired for TX1 but ORX1 also working for TX2.

What I tried last night, which also didn't seem to work was the following...

     if ((mykonosTxChannels_t)(*lastTxChan) == TX1)

     {

          MYKONOS_setObsRxPathSource(&mykDevice, OBS_RX1_TXLO);

     }

     else

     {

         MYKONOS_setObsRxPathSource(&mykDevice, OBS_RX2_TXLO);

     }

     MYKONOS_getClgcStatus(&mykDevice, (mykonosTxChannels_t)(*lastTxChan), &clgcStatus); 

     MYKONOS_setObsRxPathSource(&mykDevice, OBS_INTERNALCALS);

We are planning on using DPD and ORX for TX Power Control. I am starting to think this might be a problem.

I can slow the rate of the getClgcStatus command to 1 per second if that would allow DPD to also run.  Will something like that work or is it one or the other kind of deal?

I did more experiments.  I had a theory that DPD and setting to OBS_INTERNALCALS was interfering with using orxRms from ORX1 and ORX2.  So, removed the code that enabled DPD and replaced the call to

MYKONOS_setObsRxPathSource(&mykDevice, OBS_INTERNALCALS);

with

if ((mykonosTxChannels_t)(*lastTxChan) == TX1)

{

    MYKONOS_setObsRxPathSource(&mykDevice, OBS_RX1_TXLO);

}

else

{

    MYKONOS_setObsRxPathSource(&mykDevice, OBS_RX2_TXLO);

}

This just totally broke it.  ORX1 and ORX2 no longer work.  The call to getClgcStatus() returns error code 0 but also returns only  a track count of 1 and 0's for the data elements.  So, the Clgc is not running.

I then returned the code to no DPD, but setting OBS_INTERNALCALS, and things went back to ORX1 working and ORX2 not working.