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> 於
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> 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> 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> 
>>> <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 
>>> listUSRP-users@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@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@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@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
>> 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
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

___________________________
|                                                    |
|    陳建旻                    (^_^)     |
|    0912-926-397                     |
|    superme...@gmail.com      |
|__________________________|
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 900e6 --wave-type SINE --wave-freq 10e6 --gain 20 
--subdev "A:0" --channels "0,1" --pps "external" --ref "external"
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"

Creating the usrp device with: 
addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; 
UHD_3.13.1.0-release
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.30.3,type0=n3xx,product0=n310,serial0=3151CB0,claimed0=False,mgmt_addr1=192.168.40.3,type1=n3xx,product1=n310,serial1=3175D90,claimed1=False,addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6
[INFO] [MPM.main] Launching USRP/MPM, version: 3.13.1.0-gbbce3e45
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3151CB0
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.main] Launching USRP/MPM, version: 3.13.1.0-gbbce3e45
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3175D90
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.PeriphManager] init() called with device args 
`master_clock_rate=122.88e6,time_source=external,clock_source=external,mgmt_addr=192.168.30.3,product=n310'.
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.PeriphManager] init() called with device args 
`product=n310,time_source=external,mgmt_addr=192.168.40.3,clock_source=external,master_clock_rate=122.88e6'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1348 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1353 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1344 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1359 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1357 MB/s)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1337 MB/s)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1350 MB/s)
[INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)
[INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
Using Device: Multi USRP:
  Device: N300-Series Device
  Mboard 0: ni-n3xx-3151CB0
  Mboard 1: ni-n3xx-3175D90
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 1
    RX DSP: 1
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 2
    RX DSP: 0
    RX Dboard: B
    RX Subdev: Magnesium
  RX Channel: 3
    RX DSP: 1
    RX Dboard: B
    RX Subdev: Magnesium
  RX Channel: 4
    RX DSP: 0
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 5
    RX DSP: 1
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 6
    RX DSP: 0
    RX Dboard: B
    RX Subdev: Magnesium
  RX Channel: 7
    RX DSP: 1
    RX Dboard: B
    RX Subdev: Magnesium
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 1
    TX DSP: 1
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 2
    TX DSP: 0
    TX Dboard: B
    TX Subdev: Magnesium
  TX Channel: 3
    TX DSP: 1
    TX Dboard: B
    TX Subdev: Magnesium
  TX Channel: 4
    TX DSP: 0
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 5
    TX DSP: 1
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 6
    TX DSP: 0
    TX Dboard: B
    TX Subdev: Magnesium
  TX Channel: 7
    TX DSP: 1
    TX Dboard: B
    TX Subdev: Magnesium
Setting TX Rate: 30.720000 Msps...
Actual TX Rate: 30.720000 Msps...
Setting TX Freq: 3500.000000 MHz...
Actual TX Freq: 3500.000000 MHz...
Setting TX Gain: 20.000000 dB...
Actual TX Gain: 20.000000 dB...
Setting TX Freq: 3500.000000 MHz...
Actual TX Freq: 3500.000000 MHz...
Setting TX Gain: 20.000000 dB...
Actual TX Gain: 20.000000 dB...
Setting device timestamp to 0...
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some 
time.
[INFO] [MPM.Magnesium-1] Re-initializing daughter board. This may take some 
time.
[INFO] [MULTI_USRP]     1) catch time transition at pps edge
[INFO] [MULTI_USRP]     2) set times next pps (synchronously)
Checking TX: all_los: locked ...
Press Ctrl + C to stop streaming...
^C
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to