[USRP-users] roundtrip delay with x310 and RIO express card interface

Lecoq Yann Yann.Lecoq at obspm.fr
Fri Oct 23 06:19:55 EDT 2015


I am trying to see if I can use a X310 for a (reasonnably fast) servo loop involving the RX and TX of a UBX160 daughter board. To this aim, I need to sync the RX and TX and reduce the round trip delay for a signal going from RX to TX via the host computer as much as possible.

The test bench for this is a simple gnuradio flowgraph, connected as such:

usrp source (from RFA/RX)-> delay block -> usrp sink (to RFA/TX)

In the python file, after declaring the usrp source and sink, I synch them with: 

        now = self.uhd_usrp_source_0.get_time_now().get_real_secs()
        start = uhd.time_spec(now + 1.3)

I feed the RFA/Rx with an external RF synthesizer near 80MHz. The gnuradio sample rate is 20MSPS. The sinewave produced by this synthesizer is therefore coppied to the Tx channel, with a fix and predictable delay that is set by the delayblock value. I can check the delay that is effectivel realized with an oscilloscope monitoring both the signal from the RF synthesizer and the signal emmited by the TX. This perfectly agrees with what is expected from the flowgraph delay block.

By reducing the delay time, I can get down to 2ms no problem. If I try to go to 1ms or less, I start loosing samples which, to me, means that the minimum roundtrip delay is somewhere between 1 and 2ms.

I am using a X310 with RIO interface on a Express card laptop, and the website claims a roundtrip latency for this interface "as low as 10µs". I understand that this is probably obtained in a very specific situation not necessarly identical to what I have in mind, but I am still puzzled by the 200x difference between what I obtain as a roundtrip delay and what is specified.

Am I doing something wrong ? Is there any way or clever trick to reduce the round trip delay for a X310 RX to X310 TX in gnuradio ? I understand that RFNoC may be a possible answer, but if I could get down to a few 100µs roundtrip delay without ressorting to RFNoC it would be good enough for my application. Note that I have tried doing the exact same thing in both Python and C++ Gnuradio, which doesn't do any better.

Thanks for any help or hint on this issue.

-Yann Le Coq  

More information about the USRP-users mailing list