Dear All,
I would like to share the following results in case someone is interested.
It is related to USB latency, linux latency and whatever. It is an attempt
to “emulate” a TDMA system.
I have connected a square-wave to one of the pins of the J101 connector of
two USRPs each equipped with an RFX1800. The two USRPs are polling the pins
for a change of polarity. When this happens one of them starts to transmit a
frame (a frame consists of 40 USRP buffers) from the USRP and the other is
receiving the data. In fact, the direction is changed in every burst. The
length of the useful part of the burst and is 4.4ms and the square-wave has
a period of 6*2=12ms (i.e. each polarity lasts for 6ms).
The figure http://www.ee.kth.se/~perz/usrp/fig1.eps http://www.ee.kth.se/~perz/usrp/fig1.eps shows a histogram of the
position of the useful burst in the received frame. The variation is about
0.5ms.
Does anyone know the cause of the variation ? Or any means of reducing it ?
BR/
Per
One source of variation is the USB Request Block size (fusb_block_size),
along
with the sample rate. For example, a 2048 byte block size at 8 Msps
holds 64 us
worth of signal. The edge of your pulse could be the first sample in the
block,
or the last. If you are i/o bound and processing blocks as soon as
they are ready,
if it is the first sample it will be delayed 64 us while you wait for
the rest of
the block to fill. By default, GNU Radio is going to pull in ~16k
worth of samples
so you would expect variation of about 512 us.
It is worth noting that changing the fusb block sizes won’t really fix
this problem.
At least for the single thread case, and assuming I understand it
correctly, the
default buffer size between blocks is 16k. usrp_source will block
until it can satisfy
the request of the downstream block, which generally will be asking
for a full buffer worth
of samples. If you can use very low sample rates, you can support
smaller requests/block
sizes and the jitter will be reduced accordingly.
michael