> Try interpolating on the host to 200 Msps and see how things go.
I’m not sure what you are suggesting. If I take the “bad” recorded file and I
interpolate from 25 to 200 Msps, it’s not going to make chopped tail the
appropriate width.
I also can’t just run the USRP at 200 Msps, because I’m us
> What is the sample rate of your transmitted samples? If it isn't 200 Msps \
> for the X310, then you are using the DUC.
I use a couple different sample rates. The plots I showed earlier were taken at
25 MSPs.
> Not adding 0's to the end of a burst which you intend to be interpolated is \
> p
> Are you using any interpolation or is it going directly to the TX DAC?
I’m using a base UHD FPGA image at the moment. I tune the frequency directly
using the analog LO. The DSP component of the tune request is set to 0. Is
there some other setting that may have triggered the DUC?
_
I accidentally attached the “fixed” plot twice. Attached is the trimmed sample
plot.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I noticed that part of the manual but ignored it because it sounds like it only
applies to the n3 and x4 family of USRPs, and I’m using an x310. Is that not
the case?
Regardless I’ll work on installing the patch and try again.
___
USRP-users mailing li
:
``
`BUILDER: Building IP axi_hb31`
``
`BUILDER: Staging IP in build directory...`
`BUILDER: Reserving IP location:
/afs/mitll/usr/ri28856/public/clean_uhd/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31`
`BUILDER: Retargeting IP to
: Reserving IP location:
/afs/mitll/usr/ri28856/public/uhd/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31
BUILDER: Retargeting IP to part kintex7/xc7k410t/ffg900/-2...
BUILDER: Building IP...
\[00:00:00\] Executing command: vivado -mode batch -source
/afs/mitll/usr/ri28856/public/uhd/fpga
On average it happens somewhere between 10,000 and 100,000 calls to set_freq().
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Hello,
I have a C++ application running on RHEL 9, UHD 4.2, using USRP x310s. Recently
I encountered the following exception:
`terminate called after throwing an instance of 'uhd::op_timeout'`
` what(): RfnocError: OpTimeout: Control operation timed out waiting for ACK`
I know the exception
Thank your for the reply, Rob, this appears to be exactly what I was looking
for. I have spent a little while attempting to replicate the factory function
at the bottom of multi_usrp.cpp that uses what looks like the make_rfnoc_device
from multi_usrp_rfnoc.cpp. I can’t seem to figure out what I
> Having the exact exception details would be very helpful to share--just \
> like in any other discipline involving computers. This can help the
> community help you.
I forgot to copy down the exception info last time I encountered it.
Unfortunately (or fortunately depending on your perspectiv
Is there a method for accessing a ddc_block_control object from a multi_usrp
object? I have been skimming the various RFNoC examples, and it seems the
preferred method of accessing RFNoC objects is via the graph API. The problem
is I can’t create an RFNoC graph for an existing multi_usrp object
I found the following line in uhd_usrp_probe that looks like it does what I’m
looking for:
`if (tree->exists(path / "fw_version")) {`
` ss << "FW Version: " << tree->access(path / "fw_version").get()`
` << std::endl;`
` }`
The next question is where does the firmware version get set? I did so
I use a modified FPGA image on a few x310s. Is there a convenient mechanism for
writing some kind of versioning to a register on the FPGA?
The specific problem I’m trying to solve is I have a lot of USRPs, and I would
like my application to report when one of the radios it connects to is still o
I’m using a UBX-160 daughtercard. I’m also not tuning the RF frequency, only
the dsp frequency. I’ve managed to get Linux to keep up well enough it seems
through thread pinning.
I have one remaining question. Is there a method for issuing set_command_time()
to an individual daughterboard (say o
This is a USRP x310, and I’m issuing a command every \~150 us. I increased the
size of the timed command FIFO in the FPGA to 64.
Over long periods of time, I have hiccups like shown above on the order of
every 20 ms or so. I think what’s happening is I’m not quite keeping the USRP
queue full wh
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 of
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 t
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 = min_fr
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
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 usrp-users-
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 rapidly (hopping every \~200 us). I know the hopp
Marcus has perfectly summarized the issue. I think at this point my best bet is
to handle it at baseband in software.
I’ve been digging through AVX intrinsics, hopefully I can write something that
will meet my throughput requirements.
___
USRP-users ma
I’m using a UBX-160 daughterboard. My application uses less than 50 MHz of
bandwidth at baseband.
In past experimentation I’ve done, changing the RF gain takes on the order of 1
ms, and I need to adjust for different beam angles an order of magnitude faster
than that.
_
Is there a convenient in the UHD API to apply a digital scaling factor before
transmitting a burst?
I have a C++ application and X310 attached to a beamforming antenna, and I want
to account for the scan loss. I know there are a number of ways to achieve
this, such as handling it in my own soft
> I don’t think that recv_async_msg() blocks. So an infinite loop will chews up
> CPU.
I had a separate thread that only called recv_async_msg(). I have unused cores
on my machine, my reasoning was that I’d rather have a CPU busy looping than
risk Ls on my transmit because the hot loop Tx threa
Hi Marcus,
I’ve attempted to use uhd::tx_streamer::recv_async_msg() before, but it slowed
down my application and caused frequent lates on the tx_streamer. I’m unclear
on the intended usage. I tried creating a separate thread that polls in an
infinite while loop looking for async messages. Am I
28 matches
Mail list logo
