Rob Kossler wrote: > Would it make sense to separate into 2 threads where one thread sends the > tuning commands and the other sends the Tx samples? > Rob
Yes, and that’s what I do on the real system. The code snippet I posted was a test harness to see if my FPGA changes increased the queue size of the DDS/DUC. The documentation suggests by default the DDS/DUC only support 5 timed commands in flight at a time. I verified this by scheduling 6 commands well into the future, and observing that I get late errors, but run error free when only issue 5 commands. I would have expected my FPGA modification to change the observed behavior to 10 commands run fine, 11 cause errors. The reason I need a deeper DDS/DUC timed command buffer is because I want to retune every \~200 us. There does not appear to be a mechanism for UHD automatically buffering timed commands beyond the 5 that fit into the FPGA on the host, meaning my software must keep track of the number of commands in flight. Given network latency and scheduling uncertainty (I’m not running on an RTOS), I have not been able to issue commands that fast. If I could increase the buffer size, I could instead issue batches of commands.
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
