On 11/08/2018 03:13 PM, Serge Malo via USRP-users wrote:
Hi all,
Thanks for the extra comments Mark.
Just to be clear: I'm not talking about phase offset between RF
Outputs, but only time offset.
(Once time offset is fixed, we will try to have phase-coherent RF
outputs).
I have made other m
Hi all,
Thanks for the extra comments Mark.
Just to be clear: I'm not talking about phase offset between RF Outputs,
but only time offset.
(Once time offset is fixed, we will try to have phase-coherent RF outputs).
I have made other measurements today, here are the results.
I'm transmitting a si
Here's a google drive link with images of the phase drift between rx4 and
tx 1&2, and tx 3&4
https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH
On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner wrote:
> Hi guys,
>
> Maybe I could jump in and share some related results. My group has be
Hi guys,
Maybe I could jump in and share some related results. My group has been
developing a MIMO system with N310 units. We did a test sounding recently
where we sent 4, length 4096, orthogonal multitone signals from the
transmitters to the receivers and processed the data by finding the channel
Hello,
We would like to repeatably stream a fixed number of data points (i.e. 4096
points) at a sample rate of 40 MS/s. The file format is in complex binary.
I suspect there are several ways that this can be optimized.
If we have a flow graph:
FileSource -> UHDRadio
or with RFNoc
FileSource -
Hi Serge,
Are you measuring the phase offset between the TX0 and TX2 signals in a
steady-state case, or the time difference in the start of those signals?
In the former case, your results could be impacted by the lack of internal
LO sharing between daughterboards. I would fully expect an unknown
Your time offset is in line with the time offset we are seeing in our
N310's. I think this is because TX 0, 1 is on one RF chain (with its own
local oscillator) while TX 2, 3 is on its own RF chain with a separate LO.
As far as time delay or how long it takes for the RF components to warm up
TX 0,
Thanks very much Ian, this makes very true sense now you explained well in
short summary.
Now if we change the same algo to find the Cartesian to polar
conversion.The theory says,
check the Yi for the trig equation selection as we do previously with Zi in
rotation mode,
but what would be the equati
Hello Piotr
I can't answer your question, but I'm wondering if you plan to make this
project open source? I would find a tool like this very valuable.
On Thu, Nov 8, 2018 at 10:48 AM Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello everyone,
>
> I'm considering to create
Wade,
Great, thanks! At least in about 30 minutes of preliminary testing, that does
seem to have solved the issue.
I am successfully able to replay a 750 MB file (~1.5 seconds of data at 125
MS/s) on the N310. Now on to tuning!
-Dan
From: Wade Fife
Sent: Wednesday, November 7, 2018 7:00 PM
T
Hi Marcus,
Thank you for the detailed explanation. I think this is very helpful.
The reason I need a specific version of UHD is to work with a remote N310.
It seems that to work with a N310, the versions of Ubuntu (sdimg), FPGA
image, and UHD on the host computer must all match.
However, since my
Thanks for looking at this EJ.
The outputs does go straight to the axi_wrapper, so that was good news. Out of
curiosity, besides cleanliness, what does the axi_flop buy that issuing a one
clock register event doesn't?
Yeah, I didn't like that multiply when I put it in, but like I said, it go
Hey Jason,
Do you need to be able to run the block at 200 MSPS? If not, I would
suggest changing all instances of ce_clk to bus_clk in your block. bus_clk
runs at ~187.5 MHz versus ~214 MHz for ce_clk, so it could give you the
extra margin you need to make timing.
You can also make the change by
First, it's really not failing by much -- you got under 7 ns, so it's
*almost* there.
Two suggestions:
1. If the input/output of the block does not go directly into axi_wrapper,
try adding an axi_flop at the end to insert a one-cycle delay. This could
break up a critical path if you have a few "0
Gents, thanks for the input. I actually found the section I needed in the
timing report just before you guys wrote (I hate trying to sift through those).
It is indeed my block that is causing issues. I was getting ready to try to
break out my testbench and start playing with it by adding some
Hi Jason,
That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if
I remember correctly (and if it didn't change), and the max radio_clk is
something like 64ish MHz.
Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic
in the x310 nominally needs to settl
Hi Jason,
The longer run times might be explained by the tool struggling to meet
timing. I can't say off the top of my head what's wrong without looking at
the timing report. Do you have an updated post_route_timing_summary.rpt
file yet? Buried in there it should say exactly what's not meeting tim
OK, this has befuddled me for 3 days and I can't seem to get past it. I have a
prefix that seems to work fine.
Here are my working steps for building a bitfile on an E310:
cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
source ../../top/e300/setupenv.sh
./uhd_image_builder.py kee
Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
I can try to use lower tx start times to see if the time offset changes
with that.
Thanks,
Serge
On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech
wrote:
> On 11/07/2018 09:31 PM, Serge Malo wrote:
>
> Yes:
> We only use one stre
Hello everyone,
I'm considering to create virtual SDR device based on UHD (as libuhd
module) and virtual radio channel (probably a GNU Radio based program).
The main aim is to enable (at least partial) testing of programs using
without need to run actual hardware (i.e. to run base transceiver
stat
20 matches
Mail list logo
