On 09/08/2017 10:54 PM, Steven Knudsen wrote:
Hi Marcus,
I did rebuild LiquidDSP, though it has no dependencies on the UHD. No
change in behaviour.
Rather than speculate further with you (and waste your time), I
pressed ahead with various avenues of investigation and appear to have
had some success.
What seems to be the problem is that when you schedule multiple
consecutive receptions using a stream command, you must leave some
minimum time between the end of one reception and the start of the next.
Mine is a TDMA radio design with (for this experiment) 4 consecutive
slots followed by an extended guard time. Each radio in the system is
assigned one slot for transmission, and can use 3 slots for reception.
What I do now is the following
Every 10 ms;
1) in one thread schedule 3 receptions 10 ms into the future, each
separated by 1 ms and that will acquire samples over N microseconds
(us) where N <= 1000 us. That is, do a batch scheduling for the
reception of 3 slots
2) A second thread runs forever and invokes recv with a timeout = 100 ms
As you know, the recv will block until it times out or a scheduled
reception starts.
If N < 650 us, it all works as expected. However, if N > 650 us, I
start to miss slots, and if N is too large a seg fault occurs (as per
below, in __convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD).
My tentative conclusion is that there is some minimum time needed
between scheduled receive commands even if they have been scheduled as
a batch (all at once) in the “distant” past.
What do you think? Is there a minimum time in the FW required to set
up for a scheduled reception?
thanks!!!!
steven
I know that tuning on the B2xx series is quite time consuming, and there
will necessarily be *some* setup time for scheduled receives. But I
can't definitively
comment on the magnitude of such setup times.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
