[USRP-users] synchronizing multiple USRP N310

Jorge Chen superme991 at gmail.com
Fri Feb 22 09:23:35 EST 2019


Hi Marcus

Sorry for the confusion, the problem is no signal at all, and the
application just hang without any message.

Thanks
Jorge


Marcus D. Leech <patchvonbraun at gmail.com>於 2019年2月22日 週五,下午10:09寫道:

> On 02/22/2019 08:15 AM, Jorge Chen wrote:
>
> Hi Marcus
>
> Thanks for your reply.
>
> Since I thought it works in the case using channel 0,4 with default subdev
> spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
> However, I add the subdev spec setting and test again, but still failed to
> transmit synchronized signal from 2 N310s.
> Any other advices?
>
> Yesterday, you said you failed to transmit *ANY* signal.  Please clarify
> as to whether you mean you're transmitting, but the result is
>   unsynchronized, or whether there's no signal at all.
>
>
>
>
>
>
> To take a note, Q3 yesterday,3. When does the N310 re-initialize the
> daughter board?
> -> I found that the time is after set_clock_source(ref) and
> set_time_source(pps) commands.
>
> All the best!
> Jorge
>
>
> Marcus D. Leech via USRP-users <usrp-users at lists.ettus.com> 於 2019年2月22日
> 週五,上午3:27寫道:
>
>> 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> 於
>> 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> 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> 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> <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 listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>> --
>>>>> Follow us on Google+, LinkedIn, or Twitter!
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>> --
>>>>> Follow us on Google+, LinkedIn, or Twitter!
>>>>> _______________________________________________
>>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://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
>>>>> 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
>>>> 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
>>> http://lists.ettus.com/mailman/listinfo/
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> --
>
> ___________________________
> |                                                    |
> |    陳建旻                    (^_^)     |
> |    0912-926-397                     |
> |    superme991 at gmail.com      |
> |__________________________|
>
>
> --

___________________________
|                                                    |
|    陳建旻                    (^_^)     |
|    0912-926-397                     |
|    superme991 at gmail.com      |
|__________________________|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190222/573edabf/attachment.html>


More information about the USRP-users mailing list