This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

XEVMK2LX: Using the MCSDK with DFE + IQN2 to output 2 square waves of differing, independent frequencies handled with two AxC's, second AxC's RX data capture frequency is dependent on firsts

Part Number: XEVMK2LX
Other Parts Discussed in Thread: RFSDK

Hello all, 

We're encountering a very specific issue with the networking processor. Let me describe the background: Our project needs us to send out two square wave forms at very high customized frequency independent of each other, switching between one and the other on an order of tens of microseconds. To accomplish this we've spent some time customizing the IQN and DFE in the MCSDK in a bare metal environment, starting with a DFE demo that loaded in 2 AxC containers for LTE transmission and working from there. The ultimate goal was to basically be able to turn on one antennae channel to output and receive data at one frequency, then turn that off and turn the other channel on and receive/output data at another. We're most of the way there -- we figured out how to configure the DFE to use the correct filtrations (we mostly bypassed them), configured the IQN AT's to fire at the correct timing intervals to load in TX data, and have similarly configured the uAT timers internally. 

The issue we are having is as follows: Antennae container 1's TX and RX operations all work perfectly. Container 2's TX operation works perfectly. However, for whatever reason the data that gets returned by the second antennae container gets continuously offset by a value that is proportional to container 1's frequency. After much digging we have discovered that this discrepency is specifically related to the uAT terminal count register. When the terminal counts for channels (and containers by proxy we assume) 1 and 2 are the same, then channel 2 has no problem receiving data. But when the terminal counts are seperate, the data returning from channel 2 gets that offset! We are confident this is not an issue with anything above the IQN such as the pktdma itself as the descriptors for the received packets are all of the correct length, its just the data itself that bubbles out of the IQN / DFE that gets offset incorrectly. 

Is there some setting that couples together the two channel's PRI values like this, as far as receiving antennae data goes? We've tried simply modifying the uAT terminal count at runtime to adjust channel 1's TC to whatever frequency we want it to be, which works fine when we're only staying at one channel but causes its own timing errors when we try to switch back and forth between the two channels.

The MCSDK version is 3.0.3.15. The RFSDK demo that we used and modified was the 1x1 - 2xLTE60-HC-JESD121121x-DEMO1