Post Go back to editing

Transmission/Reception time delay

Hi,

I'm using ADRV9002 Evaluation Board. I would like to get transmission and reception time as short as possible. To achieve my goal I had disabled internal FIR filters. With the help of TES software and  "Rx1 Datapath to Tx1 Datapath loopback" (Advanced Features) option, connected a signal generator to Rx1 channel and measured the delay between Rx1 input and Tx1 output with a oscilloscope.  The result is attached below.

Is it possible to get any better than 4.48us? I can share with my profile file also if its needed.

Thanks,

Bart

  • Hi Bart,

    Firstly, your diagram is not quite correct. In this "Rx1 Datapath to Tx1 Datapath loopback" mode, the signal is not sent into the FPGA. The signal is looped back with ADRV9002 datapaths itself. You can see this in the user guide in the section ADRV9001 IN A FDD TYPE REPEATER APPLICATION USING INTERNAL LOOPBACKS. Please keep this in mind, in case this is not what you are trying to measure.

    There are a couple of things that you can do to increase the latency through the data paths:

    1) Disable the internal FIR filters (as you have pointed out)

    2) Use the largest bandwidth you can. There are interpolation/decimation stages in the datapaths. To optimize the datapaths for latency, you should use the largest possible bandwidth.

    Furthermore, inside TES itself, there is an "Internal Path Delay" function under the TDD Enablement Delay tab. This is updated when you program the part for your particular configuration. This may help in your measurement.

    What is your target time? Knowing this will help with providing you some suggestions.

    Best Regards,

    Conrad

  • Hi Conrad,

    Thank you for replying so promptly. I would like to keep Dataport Sample Rate at 48MHz, bandwidth greater than 15MHz and latency below 2.5us. If required I can adjust reference clock frequency (38.4 MHz) using another signal generator. Your suggestions will be greatly appreciated.

    Regards,

    Bart

  • Hi Bart, 

    From a quick look at the "Internal Path Delay" for a similar setup, it looks like we can get the latency into that range.

    Can you clarify on the latency you're interested in timing. Is it from Rx RF port to Tx RF Port using the internal loopback?

    Best Regards,

    Conrad

  • Hi Conrad,

    Our system needs to prepare reply for received signal in 3us. Our goal is to minimize time required for transmission and reception of signals so that we have more computational time for our algorithm. So we are not interested in internal loopback delay, and we are working on external loopback, however it might turnout futile since we were not able to meet our timing requirement even with internal loopback. The 2.5us delay mentioned earlier gives us 0.5us time for our algorithm and we can’t go lower than that.

    Best Regards,

    Bart

  • Hi Bart,

    In this case. You are probably best to use the "Internal Path Delay" feature to measure the datapaths. You can also measure an external loopback via an IronPython script. To do this, go to View >> Pyhon Editor and load the file External_Delay_Measurement.py

    Best Regards,

    Conrad

  • Hi Conrad,

    The best result we got using internal loopback is 1.7us but Dataport Sampling Rate was set to 60MHz. It seems to be related with Decimation Factor which was computed by the TES software to 18x. However, we can't come up with settings which provide lower Decimation Factor for 48MHz. Could you provide any formula for Decimation Factor calculation or give us settings from similiar setup you mentioned?

    Best Regards,

    Bart

  • Hi Bart,

    That sounds approximately right. There isn't anything else that we can change to improve the latency aside from what is mentioned.

    We don't have an equation for the decimation factor. It's listed in TES in the Rx/Tx Overview tabs. There's also some information in the User Guide under Digital Front End Components >> DEC.

    The best latency I can get is for Sampling Rate 62.5MHz and Bandwidth 40 MHz which comes out to be: Rx delay 1168 ns and Tx delay 437 ns. There will also be more delay across the SSI port and inside the FPGA for your algorithm. 

    The only other thing that might be worth considering is to move any filtering part of your algorithm back into the datapaths and remove it from your algorithm. This will increase the latency through the datapaths but may reduce the overall latency.

    Best Regards,

    Conrad

  • Hi Conrad,

    To summarize what we’ve done so far: Thanks to your advices we were actually able to reduce the latency of internal feedback to the point where it seems justified to start working on external feedback and in the next step of our project. However we want sample rate to be 48MHz and not 60MHz.  Below is the configuration and delay for 48MHz:

    And for 60MHz:

    From those experiments it seems that the decimation factor makes significant difference in delay as you suggested. Clearly the ADC sampling rate and decimation factor are related however we don’t have direct control over neither. We don’t even know how the device obtained that decimation factor.

    Is there any way through TES or API to set ADC sampling rate and decimation factor?

    What are the constraints for ADC sampling rates? Is it possible to set it to 864MHz?

    Best Regards,

    Bart

  • Hi Bart,

    It's good to hear that you're making some progress on this.

    The decimation factor is calculated internally and can't be changed from user control directly. There are some calculations done internally to select the best decimation stages for your sampling rate. The only clue we can give here is that usually higher sampling rates have lower decimation and lower latency. In this case 60 MHz will probably always have a lower decimation factor than 48MHz.

    There are some limited changes you can make to the ADC sampling rate. In the "Radio" tab, you can set the ADC to be High/Med/Low. This may have some small impact on the decimation rate. We don't support any other sampling rates for the ADC other than the three listed.

    Best Regards,

    Conrad