Hi USRP Users
I tried to synchronize 2 N310s throught the external PPS and
reference clock, and tested by the application below.
*/tx_waveforms.exe --args
"addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6"
--rate 30.72e6 --freq 3.5e9 --wave-type SINE --wave-freq 10e6
--gain 20 --channels "0,4"--ref "external" --pps "external"/*
The program runs without errors, but no signal outputs from the
corresponding channels. ( No sine waveform on the scope, and the
LED light are dark.)
I've checked if the external PPS is available by the application
"test_pps_input.exe".
And if I only use 1 N310, it works normally.
But failed in the 2 N310s synchronized case.
The OS is Win10, and I use the UHD 3.13.1.
My questions are:
1. Is the commands or the hardware/environment setting causing
the failure on synchronizing the 2 N310s?
2. I found the eeprom_version and the rev information are
different, does this difference affect?
And two further questions:
3. When does the N310 re-initialize the daughter board? In the
log (please see the attached file), it executes re-initializing
routine 3 times.
4. What's the difference between specifying
"clock_source=external, time_source=external" in the device
argument and use the UHD API set_time_source("external"),and
set_clock_source("external") if I'd like to synchronize multiple
N310s.
Are they both necessary?
| /
| | Mboard: ni-n3xx-3151CB0
| | eeprom_version: 1
| | mpm_version: 3.13.1.0-gbbce3e45
| | pid: 16962
| | product: n310
| | rev: 5
| | rpc_connection: remote
| | serial: 3151CB0
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | FPGA git hash: d0360f7.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: temp, gps_locked, gps_time, gps_sky, gps_tpv,
ref_locked, fan
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3175D90
| | eeprom_version: 2
| | mpm_version: 3.13.1.0-gbbce3e45
| | pid: 16962
| | product: n310
| | rev: 6
| | rpc_connection: remote
| | serial: 3175D90
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | FPGA git hash: d0360f7.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_locked, fan, ref_locked, gps_tpv, gps_sky,
gps_time, temp
Any feedback or help are appreciated!
All the best!
Jorge
Florian Kaltenberger via USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> 於 2018年12月20日 週四 下午
4:48寫道：
Hi Michael,
halleluja! that was it! Thanks for spotting this.
Florian.
On 20/12/2018 02:34, Michael West wrote:
Hi Florian,
The device arguments are "clock_source" and "time_source".
I noticed in your command you had them as "clock_src" and
"time_src". That may be the source of the problem.
Regards,
Michael
On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via
USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
Dear Nate,
no it says something like this is not supported with the
N310 and I should pass it using the args options. Sorry,
I don't have access to the N310 right now, so I can't
give you the exact message, but I have tried that.
Florian.
On 10/12/2018 19:00, Nate Temple wrote:
Hi Florian,
If you pass the arg "--ref external" to tx_waveforms,
does it resolve this frequency offset?
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62
Regards,
Nate Temple
On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger
via USRP-users <usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
Hi Marcus,
I have measured this with a spectrum analyzer
simply by setting markers to the peak of the
sinusoid (one marker per measured USRP) and then
taking the delta.
Could it be that the USRP is ignoring the external
reference when used alone? Remember, I am doing the
test with one USRP at a time, as the test using
multiple USRP simultaneously does not work.
Florian.
On 06/12/2018 00:29, Marcus Müller wrote:
oh! That means 341 ppb frequency error, which *really*
shouldn't be
happening.
I'd like to get some statistics of that error, how are you
measuring
it?
Best regards,
Marcus
On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
Sorry typo. I did use a frequency of 3.51GHz.
On 5 Dec 2018, at 12:54, Marcus Müller<marcus.muel...@ettus.com>
<mailto:marcus.muel...@ettus.com>
wrote:
Hi Florian,
trying to get my head to understand the order of problems here:
Could you try to use a higher frequency (say, --freq 2e9
instead of
3.5e6)?
I'd thing 3.51 MHz is out of range for the N310, anyway?
Best regards,
Marcus
On Wed, 2018-12-05 at 11:49 +0100, Florian Kaltenberger via
USRP-
users
wrote:
So I can confirm that there is a frequency offset between the
two
USRP N310s when using only an octoclock (10MHz + PPS) to
synchronize.
I have measured with the tx_waveforms program
./tx_waveforms --args
"addr=192.168.x.2,time_src=external,clock_src=external,master_clo
ck_r
ate=122.88e6" --rate 122.88e6 --freq 3.51e6 --wave-type SINE --
wave-
freq 10e6 --gain 100
on the first USRP N310 (x=10) and then on the other (x=20).
There
is
an offset of 1200Hz between the peaks of the sinusoids between
the
two measurements.
Using an external LO didn't change anything either. Unless I
need
to
provide any other arguments in that case?
I also tried to do a test where I use both USRPs simultaneously
./tx_waveforms --args
"addr0=192.168.10.2,addr1=192.168.20.2,time_src=external,clock_sr
c=ex
ternal,master_clock_rate=122.88e6" --rate 122.88e6 --freq 3.51e6
--
wave-type SINE --wave-freq 10e6 --gain 100--channels "0,4"
but unfortunately that does not work at all at my testbench
(program
hangs and no signal transmitted).
My UHD version is 3.13.0.2 (UHD_3.13.0.HEAD-0-g0ddc19e5)
Any help appreciated.
Thanks!
Florian.
On 04/12/2018 21:29, Florian Kaltenberger via USRP-users wrote:
Hi Marcus and Robin,
thanks for your answers, this is helpful information. I should
add,
that I actually tried the synchronization with an octoclock
(10MHz
+ PPS), but it did not give me the expected results, i.e., I
saw
some residual frequency offsets. But maybe I screwed up at some
point. Let me do some more measurements and get back to you on
this.
Florian.
On 04/12/2018 18:57, Marcus D. Leech via USRP-users wrote:
On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users
wrote:
Hi there,
I just discovered that in addition to the external 10MHz
reference in, the USRP N310 also has external local
oscilator
inputs, one for each daughterboard and each TX/RX. So does
that
mean that in order to synchronize multiple N310 in
frequency,
phase, and time, it is no longer sufficient to use an
octoclock
to provide a 10MHz reference and PPS? If so, at what
frequency
do you have to drive the external LOs and at what power?
Florian.
In addition to what Robin posted, I'll observe that the
external
LO port is an *additional feature* of this device.
You should still be able to use the external 10MHz and 1PPS
ports
the same way you would with a B210 or E310, since the AD9371
front-end chip is similar to the AD9361 chip used in the
B210
and E310.
The thing about synchronizing multiple independent PLL
synthesizers, though, compared to a strictly-shared-LO, is
that
the former will
experience both phase ambiguities, and have a higher mutual
phase-noise than the latter, which is why you might decide to
choose
the latter.
_______________________________________________
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
--
Follow us on Google+, LinkedIn, or Twitter!
_______________________________________________
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
--
Follow us on Google+, LinkedIn, or Twitter!
_______________________________________________
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
--
Follow us on Google+
<https://plus.google.com/+OpenairinterfaceOrg>,
LinkedIn
<https://www.linkedin.com/company/openairinterface>, or
Twitter <https://twitter.com/osalliance5g>!
_______________________________________________
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
--
Follow us on Google+
<https://plus.google.com/+OpenairinterfaceOrg>, LinkedIn
<https://www.linkedin.com/company/openairinterface>, or
Twitter <https://twitter.com/osalliance5g>!
_______________________________________________
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
--
Follow us on Google+
<https://plus.google.com/+OpenairinterfaceOrg>, LinkedIn
<https://www.linkedin.com/company/openairinterface>, or
Twitter <https://twitter.com/osalliance5g>!
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/
<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
