Hello.
Are there some people from Ettus R.?
I have an USRP 1 device. Since USRP1 has 64Ms/s for RX and 128Ms/s for
TX, after 1/64M of second one sample is acquired and two sample are sent
over the air. My question is how the time-offset is between these two
stream (in % of clock period) and how is the jitter. Thank you.
On 29/07/2011 8:42 AM, Mattia R. wrote:
Hello.
Are there some people from Ettus R.?
I have an USRP 1 device. Since USRP1 has 64Ms/s for RX and 128Ms/s
for TX, after 1/64M of second one sample is acquired and two sample
are sent over the air. My question is how the time-offset is between
these two stream (in % of clock period) and how is the jitter. Thank you.
Normally, the TX path and RX would only be connected through the host
computer software–either “roll your own+UHD” or with,
Gnu Radio. So making any kind of statements about latency and jitter
would be pretty difficult.
The TX and RX sampling and RF PLL clocks are all slaved to the 64MHz
master clock on the USRP1, if that’s helpful information.
But RX-to-TX jitter and latency information is something that is
highly, highly, highly, dependent on the host side of things.
Normally, the TX path and RX would only be connected through the host computer
software–either “roll your own+UHD” or with,
Gnu Radio.
Perphas i’m not well explained. I’m talking about samples that are
inside internal buffers of USRP. At time=t0 one sample is acquired and
two sample are sent over RF front-end. What i want to know is the
temporal disaligment (due to clock path delays, etc) between these two
tasks.
Thank you for your response.
From: Marcus D. Leech
Sent: Friday, July 29, 2011 3:57 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] Internal delays (due to clock path, …)
& jitter, between tx e rx path in USRP 1 device
On 29/07/2011 8:42 AM, Mattia R. wrote:
Hello.
Are there some people from Ettus R.?
I have an USRP 1 device. Since USRP1 has 64Ms/s for RX and 128Ms/s
for TX, after 1/64M of second one sample is acquired and two sample are
sent over the air. My question is how the time-offset is between these
two stream (in % of clock period) and how is the jitter. Thank you.
Normally, the TX path and RX would only be connected through the host
computer software–either “roll your own+UHD” or with,
Gnu Radio. So making any kind of statements about latency and jitter
would be pretty difficult.
The TX and RX sampling and RF PLL clocks are all slaved to the 64MHz
master clock on the USRP1, if that’s helpful information.
But RX-to-TX jitter and latency information is something that is
highly, highly, highly, dependent on the host side of things.
On 29/07/2011 10:35 AM, Mattia R. wrote:
Normally, the TX path and RX would only be connected through the host
computer software–either “roll your own+UHD” or with,
Gnu Radio.
Perphas i’m not well explained. I’m talking about samples that are
inside internal buffers of USRP. At time=t0 one sample is acquired and
two sample are sent over RF front-end. What i want to know is the
temporal disaligment (due to clock path delays, etc) between these two
tasks.
Thank you for your response.
The USRP1 uses an AD9862 MxFE CODEC, and the DAC and ADC sections are
phase-coherent, via the built-in DLL that takes the
master clock and produces the sample clocks for RX and TX.
But from the perspective of the FPGA and the host interface, the two
halves are totally independent, so any comments on TX vs RX
latency are utterly meaningless without taking a “systems view”. If
the TX vs RX latency is really important to you, on the scale
of single samples, then you’re going to have to do what you want on
the FPGA, which means you’re going to have to take your
own measurements, and modify the FPGA to taste. The FPGA code and
FX2 firmware are freely available for you to study and
modify at will. There are buffers in both directions–the sizes I
don’t recall off the top of my head, but perhaps Matt could
comment on that. My sense is that if you care about RX vs TX latency
on the scale of single samples, then the exact sizes of
those buffers don’t really matter, since they’re orders-of-magnitude
larger than a single sample.