[USRP-users] synchronizing multiple USRP N310

Marcus D. Leech patchvonbraun at gmail.com
Thu Feb 21 13:11:21 EST 2019


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 at lists.ettus.com 
> <mailto:usrp-users at 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 at lists.ettus.com
>>     <mailto:usrp-users at 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 at lists.ettus.com
>>>         <mailto:usrp-users at 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.mueller at ettus.com>  <mailto:marcus.mueller at 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 at lists.ettus.com  <mailto:USRP-users at 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 at lists.ettus.com  <mailto:USRP-users at 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 at lists.ettus.com  <mailto:USRP-users at 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 at lists.ettus.com
>>>             <mailto:USRP-users at 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 at lists.ettus.com <mailto:USRP-users at 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 at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> -- 
>
> ___________________________
> | |
> | 陳建旻  (^_^) |
> | 0912-926-397 |
> | superme991 at gmail.com <http://gmail.com/> |
> |__________________________|
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190221/09016d0b/attachment.html>


More information about the USRP-users mailing list