Thank you everyone for your help! I’m still not sure exactly the ratio between
the above parameters and timed command queue depth, but I empirically
determined that I now have a queue depth of 64. The other key observation was
to set rf_freq_policy to NONE, which increased the effective depth
Sorry, here's the location for 3.13. In this case it's a log2 number again,
so 8 means 256 words deep, 9 means 512 words deep, etc.
https://github.com/EttusResearch/fpga/blob/UHD-3.13/usrp3/lib/radio/noc_block_radio_core.v#L60
Wade
On Tue, Jun 7, 2022 at 10:28 AM Marcus D. Leech
wrote:
> On
On 2022-06-07 11:24, ri28...@mit.edu wrote:
Wade Fife wrote:
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
Wade Fife wrote:
> 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
If it helps at all the exact tune request I’m using is as follows:
```
uhd::tune_request_t tmp;
tmp.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
tmp.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
tmp.rf_freq = rf_freq;
tmp.target_freq =
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
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
Would it make sense to separate into 2 threads where one thread sends the
tuning commands and the other sends the Tx samples?
Rob
On Mon, Jun 6, 2022 at 5:12 PM wrote:
> I modified the three files described above, changing the CMD_FIFO_SIZE
> parameter in dds_timed.v and axi_tag_time.v, and
I modified the three files described above, changing the CMD_FIFO_SIZE
parameter in dds_timed.v and axi_tag_time.v, and FIFO_SIZE in ddc.v. In all
cases I attempted to adjust to 20, but that used too much BRAM and I instead
tried 10, which successfully built.
I loaded the bitfile onto an x310,
Thank you all for the suggestions! It will take me a couple of days to get an
FPGA build environment configured, I’ll provide an update early next week.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to
Hi all,
I was also refreshing my memory on how this works. dds_timed is used by the
DUC. For the DDC, I think the line you need is here:
https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/fpga/usrp3/lib/rfnoc/ddc.v#L115
Also, I think you need to change this line
On 2022-05-31 16:43, Brian Padalino wrote:
On Tue, May 31, 2022 at 3:42 PM wrote:
Hi,
I’m playing around with frequency hopping on a USRP x310 with a
UBX 160 daughterboard. In particular, I want to hop to a few
different frequencies that are integer multiples of my master
On Tue, May 31, 2022 at 3:42 PM wrote:
> Hi,
>
> I’m playing around with frequency hopping on a USRP x310 with a UBX 160
> daughterboard. In particular, I want to hop to a few different frequencies
> that are integer multiples of my master clock rate and well within the
> daughtercard bandwidth
13 matches
Mail list logo
