Synchronization of DMA TX and RX channels in adrv9002

Hi Adam, 

I am looking into this for you now. 

Regards

Hi Ruairi

I can see that the problem is not easy.

Regards

Hi Adam, 

Are you using one of our evaluation boards or are you implementing this on your own platform currently?

Regards

I'm using ADRV9002NP/W1/PCBZ (C0) + ZC706 and modified software generated in TES 0.18.1.

Hi Adam, 

I'v had a chance to try this out in the lab. So I have seen the shifting you describe above when I don't have synchronous transfer enabled on the Tx and Rx side. 

In the Transmit and Receive tabs there is a Synchronous Transfer checkbox in the top left. If you enable this on both before programming you should see the data in sync. This is only available to select when MCS is enabled from the Advanced features Tab.

There is a new version 20 of SDK and TES available as of yesterday on the product page. That will be worth updating to for the best support. 

Let me know how this works.   

Regards

Hello

We did not understand each other.
Synchronous Transfer allows synchronization between R1 and R2, T1 and T2. The adi_fpga9001_DataChain_PerformSynchronousTransfer() function sets both channels to ADI_FPGA9001_DMA_TRIGGER_SYNC mode and generates an internal MCS pulse. When writing my code, I followed this mechanism.
I need a synchronization between TX and RX. In my case, TX DMA does not work in continuous mode, but it is triggered by one MCS pulse together with RX DMA, i.e. I configure all DMA channels in ADI_FPGA9001_DMA_TRIGGER_SYNC mode and generate a pulse. This works except that the signal between TX and RX shifts randomly.
Below, I have presented 90 registrations (real part of the RX1 signal,1 MHz sampled at 10 MHz) on one graph. As you can see, we only have two cases shifted by two samples. Repetitive, i.e. not random behavior.

This cannot be seen in TES because it is not possible to trigger TX and RX channels at the same time, and the transmitter without continuous mode starts only once.
I suspect that no one made sure that the TX and RX could be run synchronously, because there was no such need. I want to use this system in a radar where synchronous operation of transmitters and receivers is necessary. Currently it uses a second receiver for offset correction, but then I lose one receive channel.

I downloaded and ran TES version 20. I generated the C code, compiled and ran the program on the ZC706. The program crashed on the first call to adi_fpga9001_DataChain_Data_Set_16IQInterleaved () - segmentation fault. I think this version is still too fresh.
I went back to version 18.

Regards

Hi Adam, 

I understand you now, I'll speak to our developers and see what can be done to try test this. 

Regards

Hi Adam, 

Just an update on our discussions. Currently we are looking into the advanced features to see if we can trigger Tx and Rx concurrently. 

An alternative method could be to tri-state enable signals on the FPGA and use an DGPIO output to trigger both of them at the same time. 

Regards

Hi Adam,

    Could you clarify if your system is a FDD or TDD system? In a TDD system, Tx_enable and Rx_enable signals along with the TDD enablement delays are controlled by user and they are used to control the timing to enable/disable Tx and Rx channels. Tx and Rx channels are time multiplexing with each other which could not be enabled at the same time. So I guess it is a FDD system, right? In addition to that, the picture you posted is not very clear to me. Is it only for Rx1 real part? Why 2 patterns? How you use it to verify that Rx and Tx are not in sync? Please provide details how you did the experiment to prove that Tx and Rx are not in sync.

Thanks,

Michelle

Hi, Michelle

Yes, I work in FDD mode.
Of course I did MCS sync first.
Then I enabled the TX and RX channels (RF mode).
And I ran the DMA channels 90 times. I did the configuration and launch of the DMA channels using a fragment of the code below:

static adi_fpga9001_DmaCfg_t dmaCfg_TX = {
.length = 0,
.continuous = false,
.timeout_ms = 0,
.trigger = ADI_FPGA9001_DMA_TRIGGER_SYNC,
.captureType = ADI_FPGA9001_CAPTURE_TYPE_DISABLE,
.dmaEnableSync = false};

error_code = adi_fpga9001_DataChain_Dma_Configure(fpga9001Device_0, ADI_TX, ADI_CHANNEL_1, &dmaCfg_TX);
AUTOGENERATOR_ERROR_HANDLER(error_code);
error_code = adi_fpga9001_DataChain_Dma_Configure(fpga9001Device_0, ADI_TX, ADI_CHANNEL_2, &dmaCfg_TX);
AUTOGENERATOR_ERROR_HANDLER(error_code);

static adi_fpga9001_DmaCfg_t dmaCfg_RX = {
.length = 4864,
.continuous = false,
.timeout_ms = 2000,
.trigger = ADI_FPGA9001_DMA_TRIGGER_SYNC,
.captureType = ADI_FPGA9001_CAPTURE_TYPE_RX_DATA,
.dmaEnableSync = false};

error_code = adi_fpga9001_DataChain_PerformSynchronousTransfer(fpga9001Device_0, ADI_RX, &dmaCfg_RX);
AUTOGENERATOR_ERROR_HANDLER(error_code);

The adi_fpga9001_DataChain_PerformSynchronousTransfer function is convenient because it configures the DMA, generates the MCS pulse (activating all DMA channels) and waits for the data to be downloaded.

In the graph presented above, the registration results 90 are superimposed (the real part of the signal at RX1 input, but looks identical to RX2). Channel TX1 is connected to RX1 and TX2 is connected to RX2.
The graph looks as if it were two signals because the signal in all registrations takes one of the two waveforms, between which there is always a shift of the 2 samples. Interestingly, when I changed the sampling rate, this offset was still 2 samples.
I was hoping that I was making a simple mistake and someone would point it out to me, but so far it looks like it might be a property of this API project.

Regards, Adam