On 09/08/2017 11:38 PM, Steven Knudsen wrote:
Let me see if I understand you correctly. Are you saying that turning
on the first reception takes significant time?
In my case, the receive loop is running before the scheduling starts;
it just times out and spins around again. So I am not sure that the
receive startup is the problem.
But if it was, then could I simply not do a “dummy” receive and then
start scheduling?
I can live with the 350 us pre-receive dead time.
However, without digging into the FPGA code, I would have thought that
a command queue would be periodically checked to see if the next
command time has arrived and then the waiting command would execute
right away. But, if there was a set number of events that needed to
execute for a reception, that might explain things. E.g., if things
were disabled after NUM_SAMPS_AND_DONE and needed to be re-enabled the
next time receive is invoked, that could and would take time.
At this point I am just speculating…
steven
PS You work long hours!
In general, starting the receive process takes a finite amount of time,
because various bits of hardware need to be turned (back) on. Tuning
is the most
notoriously slow part in the B2xx series--the chip wasn't designed
for frequency-hopping, for example. But other bits and pieces need to
be initialized.
I'm just not sure how many such bits and pieces and what the latency is.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
