I have an application where I don’t necessarily care what the latency
is, but I need it to be predictable and/or constant. Is there a way to
achieve this with the USRP hardware?
Thanks!
Geib, Jeffrey (Civilian) wrote:
I have an application where I don’t necessarily care what the latency
is, but I need it to be predictable and/or constant. Is there a way to
achieve this with the USRP hardware?
USRP supplies data via USB. I believe the delay of USB data through the
operating system and into your application is not predictable or
constant.
Chris
On Tue, Aug 19, 2008 at 7:27 AM, Geib, Jeffrey (Civilian)
[email protected] wrote:
I have an application where I don’t necessarily care what the latency
is, but I need it to be predictable and/or constant. Is there a way to
achieve this with the USRP hardware?
Latency between what two points?
The USB bus/OS will be unpredictable, but there is opportunity to do
processing on the FPGA itself that can be made deterministic, or you
can interleave an external synchronization pulse from a GPIO pin into
the data stream and use it somehow. It really depends on what your
application needs.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/
This is correct. Your samples go through buffers, and therefore it is
hard to predict the latency each and every sample will have to get
from software to the USRP. I did a study on this a while back. If you
are interested, you can find the paper here:
http://nesl.ee.ucla.edu/document/show/242
What you can do though is calculate the minimum and the maximum
latency that the samples will have. Also, I am not sure how far the
mblock and GNU Radio is in regards to timestamping outgoing samples (I
didn’t follow the GNU Radio development lately) is, but if you can
tell the USRP when to send out which sample, then you could easily
predict the latency itself.
Cheers,
Thomas
On Tue, Aug 19, 2008 at 8:14 AM, Chris S.
[email protected] wrote:
Chris
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
“Don’t complain; Just work harder” - Randy Pausch
Thomas S., Ph.D. Candidate
Networked & Embedded Systems Laboratory (NESL)
University of California, Los A. (UCLA)
http://gresci.blogspot.com/ - Science articles on green technology
On Tue, Aug 19, 2008 at 11:21 AM, Thomas S. [email protected]
wrote:
tell the USRP when to send out which sample, then you could easily
predict the latency itself.
I believe the TX direction for the m-block/inband signaling in the
FPGA works well, but the RX has issues with providing the actual
timestamp of the received sample block (which will be fixed soon).
Brian
On Tue, Aug 19, 2008 at 10:27:15AM -0400, Geib, Jeffrey (Civilian)
wrote:
I have an application where I don’t necessarily care what the latency
is, but I need it to be predictable and/or constant. Is there a way to
achieve this with the USRP hardware?Thanks!
Latency measured relative to what?
Rx only, Tx only or Tx/Rx?
Eric
On Tue, Aug 19, 2008 at 10:27:15AM -0400, Geib, Jeffrey (Civilian)
wrote:
I have an application where I don’t necessarily care what the latency
is, but I need it to be predictable and/or constant. Is there a way
to
achieve this with the USRP hardware?Thanks!
Latency measured relative to what?
Rx only, Tx only or Tx/Rx?
Eric
I am looking for fixed latency from Rx to Tx. I want to take a
continuous stream of input data, process it, and transmit it back out.
The processing needs to know what the precise latency is between the
samples at the DAC and ADC.
From the previous replies and Thomas S.'s analysis, it appears that
this isn’t feasible with the current interface. It appears this could
be done with the mblock and inband signaling additions, where then I
could schedule each packet to be output at a known timestamp.
Jeff
On Tue, Aug 19, 2008 at 02:01:40PM -0400, Geib, Jeffrey (Civilian)
wrote:
Rx only, Tx only or Tx/Rx?
be done with the mblock and inband signaling additions, where then I
could schedule each packet to be output at a known timestamp.
Yes. As soon as George and company get the timestamp issue sorted
out, this should work fine.
Eric