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 measurements today, here are the results.
I'm transmitting a signal at 1.57542GHz, and a second signal at 1.2276GHz.
Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz)
Sample Rate on X300: 25.0Msps (MCR of 200Mhz)
Using External Clock and External PPS from Octoclock
1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns
time offset (See image here: link
<https://drive.google.com/file/d/1FBC3CHOhGO4xLdJU3LhjB0pTjexNpJik/view?usp=sharing>)
2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time
offset (See image here: link
<https://drive.google.com/file/d/1mV2XrUVz1PC4boi0BzUmxFcWo2b8zj3Y/view?usp=sharing>)
3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us
time offset.
Important: the "timed commands" seem to be broken in UHD 3.13.1.0,
either for X300 or N310.
When we change the time_spec of the first "send" call, the time at
which the samples are transmitted does not change. For example, I
tried to set tie_spec to 10s, but the Tx starts right away. This was
working correctly with UHD 3.10.3.0
Let me know if you have ideas I could try.
Best regards,
Serge
Serge:
The fact that this affects both X310 and N310 is a bit disturbing--the
device-side codebase is quite different on the two boxes. I'm engaging
Ettus R&D internally to see if this can be reproduced.
On Thu, 8 Nov 2018 at 14:44, Mark Wagner <m2wag...@eng.ucsd.edu
<mailto:m2wag...@eng.ucsd.edu>> wrote:
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 <m2wag...@eng.ucsd.edu
<mailto:m2wag...@eng.ucsd.edu>> wrote:
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
response between each transmitter and receiver pair (16 in
total) and recording the magnitude and phase of the arrival
spikes between each pair.
We took several seconds of data and processed it in length
4096 chunks (around 1500 chunks in total) and looked at the
phase difference between transmitter pairs as time progressed.
Since transmitters 1 and 2 are sharing an LO and our setup was
not moved during the sounding we expected to see a constant
phase difference between transmitters 1 and 2 and a single
receiver (same with tx 3 and 4), but we saw some drift. Worse
yet, not all LO sharing pairs drifted in the same way, some
didn't drift much at all while some drifted in linear or
non-linear patterns.
If you're all fine with me breaking the rules I can attach
some png images of what we recorded so you can see what it
looks like. Later this week we'll repeat the experiment but
leave the machines running longer to see if the drift
diminishes as the machines run longer.
Cheers,
-Mark
On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
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 phase offset between
channels 0 and 2 every time you reconfigure the device. In
the latter case, it sounds like a start trigger mismatch
like Marcus mentioned.
Can you share more details as to how you're measuring the
phase offset?
Thanks,
-Daniel
On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
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
<patchvonbr...@gmail.com
<mailto:patchvonbr...@gmail.com>> wrote:
On 11/07/2018 09:31 PM, Serge Malo wrote:
Yes:
We only use one streamer for all RF outputs, and
send time_spec with each call to the streamer's
send method.
We reset the internal time with
set_time_unkown_pps(0), and program the first
samples to be streamed at a time of 0.800s.
It is basically the same code we used on the
X300/X310.
Thanks,
Serge
Well, that is quite strange--the magnitude of the
time offsets is larger than I would expect.
Perhaps someone from the N310 team can comment?
Serge, are you using the latest UHD and system
image versions for the N310?
On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via
USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
On 11/07/2018 08:53 PM, Serge Malo via
USRP-users wrote:
Hi all,
We are trying to send 4 synchronous signals
from the 4 Tx ports of the N310.
We are using UHD 3.13.1.0 RC1 under Ubuntu.
Central Freq = 1575.42 GHz and 1227.6 MHz
Master Clock rate = 153.6 MHz
We would expect to have less than 3ns offset
between all TX ports of the N310, like we do
with the X300/X310. However, we have
measured 4700ns between TX RF ports 0 and
port 2.
We have tried the next things with no more
success:
- Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
- Init with the device options
"init_cals=ALL" and "force_reinit=1"
- Use the internal GPSDO
- Use clock_source=external and
time_source=external (from an Octoclock).
Can you tell us:
-What time offset between TX RF ports we
should expect to achieve?
-Is there anything else we can try to reduce
this offset to less than 3ns?
Best regards,
Serge
How are you setting up your TX streamer? Is
it time-tagged to start at a particular
device time?
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Daniel Jepson
Digital Hardware Engineer
National Instruments
O: +1.512.683.6163
daniel.jep...@ni.com <mailto:daniel.jep...@ni.com>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Mark Wagner
University of California San Diego
Electrical and Computer Engineering
--
Mark Wagner
University of California San Diego
Electrical and Computer Engineering
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
