I'm not very familiar with how those tune commands get translated into
register transactions, but one thought I had is that it may also be issuing
timed commands to the radio. If so, you also might need to make the radio's
control FIFO deeper by updating the "512" number to the depth you need. It
should be a power of 2, so I would try 1024 or 2048, etc. It needs to be
updated in two places to the same value:

https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/noc_shell_radio.v#L148

https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/noc_shell_radio.v#L195

Wade

On Tue, Jun 7, 2022 at 9:11 AM <ri28...@mit.edu> wrote:

> 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
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to