Hello,
I am prototyping on the 9375 EVM. I am trying to retrieve the orxRms value using the MYKONOS_getClgcStatus() function. I call this function periodically in a background task.
My TX1 port is connected to the ORX1 port using a -20 dB coupler. I also have my TX2 connected to the ORX2 port using another coupler.
The function works as I expect when I am configured for RX1/TX1 and call the function passing in TX1 as the channel.
However, when configured for RX2/TX2 operation, the orxRms value is low and I am getting Error = 19. I have confirmed my TX signal is present on the TX2 output and on the coupler output.
If I move the TX2 coupler output from ORX2 to ORX1 the orxRms value then behaves normally.
So, it would seem, that despite the configuration to monitor ORX2, ORX1 is still being used.
I stepped the code in MYKONOS_getClgcStatus() and I can see that txChannel is indeed TX2 and the third byte of extData is getting set to 1. It almost seems as is the ARM is ignoring this and using ORX1 instead.
Perhaps I need an ARM code update?
Thanks,
Chris Peters
Lead DSP Design Engineer
L3Harris Corporation
So, I solved the issue but I'll include the details for the benefit of others...
I am not using txChannels = TX1_TX2.
More background. We are not using TX1_TX2 and RX1_RX2 like in a MIMO setup, but…
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);
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
with
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.