Hi Steve,
yes, nonlinearities in amplifiers would be my interpretation, too. But
I'd suspect that these might be (also) happening on the RX side – what's
your gain there? What's the attenuation?
My further approach would be:
1. Get the CBX performance data from [1]
2. From that, read/estimate ma
Dear Seah,
please avoid sending the same mail 4 times; that certainly doesn't
increase the usability of the mailing list.
So, what's your own PC's IP address? is it in the same subnet?
I don't understand what you mean with
> will communicate within omnidirectional
Could you elaborate?
Best re
Hi all,
When we set the gain (or other parameter) to 20dB, we need to convert this
gain value into binary by UHD, and then pass it to FPGA. Is there any way
to know the transformation between this value and binary?in other words，
how does the corresponding binary transform? Do you have tables or fo
OK, thanks Martin. I guess I am still confused though (no surprise
there). You say that they're "generally useful." In what way? If I
have a flow graph that has 3 RFNoC blocks, what is the benefit of adding
a FIFO or two to it?
Thanks!
On 09/28/2017 03:10 PM, Martin Braun via USRP-users
I recently moved to working with an X310, after previously working with an
N210. When working with the N210 I was able to run my code which scans
multiple frequencies, and only use 5000 msec as my dwell time on each
frequency. With the N210, 5000 msec was enough time to task the N210 and
coll
Hi,
Apparently the RFNoC infrastructure only supports blocks that have input to
output rate changes of integer amounts?
Is there any way to have a data output that flows through to subsequent
blocks at unknown downsampled rates?
Thanks.
___
USRP-users m
Hello,
Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter
some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 sec
of time. A bit surprised to see this in 64-bit environment... The assertion is
in module rx_vita_core_3000.cpp:
UHD_ASSERT_THROW(s
Yes. You can change the rate however you like. Not sure where you'd get the
suggestion of an intrinsic integer limitation. If you're using axi_wrapper
in simple mode you'll just be responsible for handling the AXI stream and
setting the tlast signal to delimit packets at reasonable lengths. If
you'
Jon,
This isn't specific enough to offer a reasonable answer, and might not even
be a reasonable question. The binary representations for different control
parameters are different for each parameter and are what the drivers
(daughterboard, motherboard, transport) are intended to handle for you.
Hi Nick,
OK, all clear now, thanks for the clarification.
Cheers, Mark.
On 29 September 2017 at 16:04, Nick Foster wrote:
> Yes. You can change the rate however you like. Not sure where you'd get
> the suggestion of an intrinsic integer limitation. If you're using
> axi_wrapper in simple mode
OK, I have a weird problem. I have a block I wrote a couple of months
ago that doesn't seem to be working anymore. I don't think I've updated
anything within uhd-fpga except for some patches that Jonathon sent me
so that I could add the logic in that keeps blocks from blasting data
before the
Hi James,
I did what you suggested and it works! Thanks a ton!
—
Regards
Shoor
From: "Humphries, James R." mailto:humphrie...@ornl.gov>>
Date: Tuesday, September 26, 2017 at 11:36 AM
To: Shoorveer Singh
mailto:shoorveer.si...@privoro.com>>, Ezequiel
Alfíe mailto:eal...@gmail.com>>,
"usrp-use
12 matches
Mail list logo
