On 02/21/2019 10:18 AM, Jorge Chen via USRP-users wrote:
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.)
You have not included a subdev specification, so it's not going to be
able to intuit what you mean.
https://kb.ettus.com/N300/N310_Getting_Started_Guides#Subdevice_Specification_Mapping
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/usrp-users_lists.ettus.com
--
___________________________
| |
| 陳建旻 (^_^) |
| 0912-926-397 |
| superme...@gmail.com <http://gmail.com/> |
|__________________________|
_______________________________________________
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
