treams.
>
> Currently struggling with the flu. It has addled my brain...
>
>
> On Thu, Dec 27, 2018 at 10:56 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 12/27/2018 10:57 AM, Daniel May via USRP-users wrote:
>> > We ha
ers@lists.ettus.com> wrote:
> On 12/27/2018 10:57 AM, Daniel May via USRP-users wrote:
> > We have an X310 with two UBX-160 daughter cards. Is it possible to set
> > different sample rates for each Tx channel? Seems that setting the
> > sample rate for one channel sets all
We have an X310 with two UBX-160 daughter cards. Is it possible to set
different sample rates for each Tx channel? Seems that setting the sample
rate for one channel sets all channels. We're controlling things via a
multi_usrp object. The set_tx_rate function has a channel argument, but it
Andreas,
Just a guess: Are both of your X310's using a common 10 MHz reference? If
not, this is likely just the difference between the LO's on the two
devices. Even tuned to the same center frequency, there will be a slight
difference in the LO's. If you feed both X310's a common 10 MHz
Important info up front:
Hardware: USRP B210
Driver: Version: [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red
Hat 4.8.5-16); Boost_106700; UHD_3.11.1
I have an application that receives and transmits at the same time. The
application receives a stream of data, does some simple processing,
t;
usrp-users@lists.ettus.com> wrote:
> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote:
>
> Is there a way to query the amount of data in the FIFO so that I can wait
> until it clears?
>
> I don't believe so.
>
> You could simply wait an amount of time, based o
, but for slow sample rates, it empties
>>> slowly. Perhaps you could supply the arg "skip_dram=1" so that the
>>> streaming goes directly to the DUC rather than through the FIFO. This will
>>> probably work fine for slow sample rates (i.e., perhaps a FIFO is not
&g
ld supply the arg "skip_dram=1" so that the streaming goes
> directly to the DUC rather than through the FIFO. This will probably work
> fine for slow sample rates (i.e., perhaps a FIFO is not needed for such
> rates).
> Rob
>
> On Mon, Oct 29, 2018 at 4:17 PM Dan
All,
Can anyone else reproduce this issue and/or suggest a solution?
This is happening over the Ethernet interface as well. Application exits,
Tx light stays on, relaunching application causes X310 to enter an
unrecoverable state and requires power cycling. It looks like an issue with
Hello,
For our projects, we write C++ code that interfaces directly to UHD and
executes on the E310. We are very comfortable with the UHD API, and have
used it extensively. We are interested in getting familiar with RFNoC and
using it to expand some of our capabilities. We have successfully
10 matches
Mail list logo
