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).
Does anyone know the cause of the variation ? Or any means of reducing it ?
One source of variation is the USB Request Block size (fusb_block_size),
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
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
At least for the single thread case, and assuming I understand it
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
sizes and the jitter will be reduced accordingly.