Re: [USRP-users] N320: XQ image issue using sfp0 as time_source

[Daniel Jepson via USRP-users]

Hi David,

Indeed, this sounds like a bug, and I believe you have the correct solution
identified. We will begin validating the fix on our side, but you can try
adding `XQ` to the list here: sfp_time_source_images = ('WX',) and then
recompiling. You should be able to just modify the installed file directly
on your N320 and then reboot to restart MPM.

Just keep in mind I haven't tested this yet, but it seems like it's the
right way to go!

-Daniel


On Tue, Dec 10, 2019 at 9:41 AM Truan David via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi!
>
> We are using multiples N320 (UHD 3.14) and we want to synchronize our
> setup using the White Rabbit protocol and using the N320 as the WR Slave
> and the Master being an OPNT Switch.
>
> We have to be able to stream the IQ over the QSFP+ port (seen as sfp0) and
> use the SFP0 as the WR input so we have the XQ image loaded.
>
> However, when setting sfp0 as the time_source, I get an error saying I
> need the WX image. I checked the "MPM/periph_manager/n3xx" python code and
> saw it only checks for the WX (line 692 of the 3.14 UHD on github). Is this
> normal?
>
> If not, can I patch it by adding the XQ string to the
> "sfp_time_source_images", pack it and only replace the MPM package or
> should I totally rebuild UHD and flash my SD?
>
>
> Thank you in advance for your answer!
>
>
> David Truan
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Daniel Jepson via USRP-users]

Cherif,

Great news! Congrats on the fix!

Cheers,
Daniel

On Mon, Oct 7, 2019 at 9:48 AM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Daniel,
>
>
> The problem was finally solved. It was from both my software and my
> hardware development.
>
> -> in fact in the software I used the set_time_next_pps() call from the
> device3 object to synchronize the vitatime counter with the PPS signal, but
> later on I would also create a rfnoc_streamer object to be able to use
> the rf frontend. This would somewhat modify the vitatime value and
> desynchronize my local counter with the  vitatime counter causing random
> offset between the two counters.
>
> -> The second problem was linked to the cvita_hdr_encoder  which was not
> properly set, Leading the frontend to transmit asap, I guess.
>
>
> So from both these issues I could be from time to time off by one sample/5
> ns at the transmitter.
>
> Now that's old story !
>
>
> Many thanks
>
>
> Cherif
>
>
>
>
> __
>
> Fabian, I had a hunch it was just the 3.3V part--thanks for clarifying!
>
> Cherif, the DAC interface timing (and for that matter, the ADC timing)
> should be fairly tight. What you're seeing is expected and matches the
> numbers we designed it to. The FPGA constraints are intentionally tight to
> provide some extra margin at the DAC. Since this is all in the same X310,
> you could start by isolating the various components of the design using the
> front-panel GPIO connector. Run a trigger from each of your custom blocks
> to the GPIO and see if they line up on a scope. If they don't, then you
> might have a baseband timing issue (with how timed commands are interacting
> with your blocks). If they line up, then it points to a timing failure in
> the DAC.
>
> -Daniel
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Daniel Jepson via USRP-users]

Fabian, I had a hunch it was just the 3.3V part--thanks for clarifying!

Cherif, the DAC interface timing (and for that matter, the ADC timing)
should be fairly tight. What you're seeing is expected and matches the
numbers we designed it to. The FPGA constraints are intentionally tight to
provide some extra margin at the DAC. Since this is all in the same X310,
you could start by isolating the various components of the design using the
front-panel GPIO connector. Run a trigger from each of your custom blocks
to the GPIO and see if they line up on a scope. If they don't, then you
might have a baseband timing issue (with how timed commands are interacting
with your blocks). If they line up, then it points to a timing failure in
the DAC.

-Daniel



On Fri, Sep 27, 2019 at 12:33 PM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:

> fabian,
>
>
> I have tested your solution, but the get_time_last_pps always gives me
> the expect value.
>
>
>
> Daniel, On a different point, the issue might be related to timing, here
> are some examples of  timing related to the DACs. The compilation is
> successful but the margin is very low, in the 10 ps order.
>
>
>
>
> Startpoint Endpoint   Slack(ns)
>
>
> 
> gen_db1/gen_pins[2].oddr/C DB1_DAC_D2_N   0.016
>
> gen_db1/gen_pins[2].oddr/C DB1_DAC_D2_P   0.016
>
> gen_db1/gen_pins[7].oddr/C DB1_DAC_D7_N   0.021
>
> gen_db1/gen_pins[7].oddr/C DB1_DAC_D7_P   0.021
>
> gen_db1/gen_pins[3].oddr/C DB1_DAC_D3_N   0.024
>
> gen_db1/gen_pins[3].oddr/C DB1_DAC_D3_P   0.024
>
>
>
> gen_db0/gen_pins[2].oddr/C DB0_DAC_D2_N   0.066
>
> gen_db0/gen_pins[2].oddr/C DB0_DAC_D2_P   0.066
>
> gen_db0/gen_pins[0].oddr/C DB0_DAC_D0_N   0.071
>
> gen_db0/gen_pins[0].oddr/C DB0_DAC_D0_P   0.071
>
> gen_db0/oddr_frame/C   DB0_DAC_FRAME_N0.075
>
> gen_db0/oddr_frame/C   DB0_DAC_FRAME_P0.075
>
> gen_db0/gen_pins[3].oddr/C DB0_DAC_D3_N   0.080
>
> gen_db0/gen_pins[3].oddr/C DB0_DAC_D3_P   0.080
>
> gen_db0/gen_pins[1].oddr/C DB0_DAC_D1_N   0.085
>
> gen_db0/gen_pins[1].oddr/C DB0_DAC_D1_P   0.085
>
>
>
> Best Regards
>
> Cherif
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Daniel Jepson via USRP-users]

Fabian,

I noticed on the SN74LS125A datasheet the minimum input voltage is 4.75V.
Is this the correct part that you're using?

-Daniel

On Fri, Sep 27, 2019 at 9:27 AM Daniel Jepson 
wrote:

> Thanks Fabian. As long as the input PPS is driven by the same RefClk that
> is provided to the X310, this system should be ok. You might also consider
> driving the PPS on the falling edge of the RefClk to ensure timing is met
> at the X310. There are some timing constraints here that might affect
> performance, but I wouldn't expect to see a 10 ns shift.
>
> -Daniel
>
> On Thu, Sep 26, 2019 at 3:18 PM Fabian Schwartau via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> It is a self build device using a 74LS125D as buffer. The level is 3.3V
>> digital.
>> As there were no specifications around for the required input levels at
>> the time we needed the device, we just measured the levels coming from
>> the 1PPS output and replicated them.
>>
>> Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:
>> > Hi Fabian, Cherif,
>> >
>> > What is the external PPS device you are using?
>> >
>> > -Daniel
>> >
>> > On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users
>> > mailto:usrp-users@lists.ettus.com>> wrote:
>> >
>> > Hi,
>> > I have very similar problem with X310. I am running a C++
>> application,
>> > so I have a bit more flexibility I guess. After I do the
>> > set_time_unknown_pps to sync to the 1PPS signal, I run the function
>> > get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns
>> > for
>> > an old firmware due to a bug, which was fixed a few weeks ago). If
>> that
>> > is the case I just do the sync again until the offset is zero.
>> > I don't know if it is an firmawre problem or if it is because the
>> > signal
>> > integrety of the 1PPS signal is not good enough.
>> > Maybe that is also a solution for you.
>> > Best regards,
>> > Fabian
>> >
>> > Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:
>> >  > Hello,
>> >  > I am working with the X310 USRP. I have two identical custom
>> blocks
>> >  > feeding the RF frontends.
>> >  >
>> >  > flowchart
>> >  > -
>> >  > HW Block1 -> RF0-TX1 |---<
>> >  > HW Block2 -> RF1-TX1 |---<
>> >  >
>> >  > The system is synchronized to an external PPS reference. The
>> > sampling
>> >  > rate is 200 MSps and the signal bandwidth is 160 MHz for both
>> > channels.
>> >  > The two HW blocks start  transmitting at the exactly same time.
>> Time
>> >  > resolution is 5ns.
>> >  > In most cases the two outgoing RF signals present a 1ns time
>> offset.
>> >  > Which can be understood as a phase offset.
>> >  >
>> >  > But From time to time there is a 6ns delay between the channels.
>> I
>> >  > assume this 6ns comprises the 1ns delay due to phase offset + 5
>> > ns delay
>> >  > due to misalignment of outgoing samples.
>> >  >
>> >  > What could be the origin of this one sample misalignement? Is it
>> > a way
>> >  > to fix it? Or working close to the limits of the device should
>> such
>> >  > behavior be expected?
>> >  >
>> >  > Thanks in advance
>> >  >
>> >  > Best Regards
>> >  > Cherif
>> >  >
>> >  >
>> >  > ___
>> >  > 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
>> >  >
>> >
>> > --
>> > --
>> > M.-Sc. Fabian Schwartau
>> > Technische Universität Braunschweig
>> > Institut für Hochfrequenztechnik
>> > Schleinitzstr. 22
>> > 38106 Braunschweig
>> > Germany
>> >
>> > Tel.:   +49-(0)531-391-2017
>> > Fax:+49-(0)531-391-2045
>> > Email: fabian.schwar...@ihf.tu-bs.de
>> > <mailto:fabia

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Daniel Jepson via USRP-users]

Thanks Fabian. As long as the input PPS is driven by the same RefClk that
is provided to the X310, this system should be ok. You might also consider
driving the PPS on the falling edge of the RefClk to ensure timing is met
at the X310. There are some timing constraints here that might affect
performance, but I wouldn't expect to see a 10 ns shift.

-Daniel

On Thu, Sep 26, 2019 at 3:18 PM Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> It is a self build device using a 74LS125D as buffer. The level is 3.3V
> digital.
> As there were no specifications around for the required input levels at
> the time we needed the device, we just measured the levels coming from
> the 1PPS output and replicated them.
>
> Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:
> > Hi Fabian, Cherif,
> >
> > What is the external PPS device you are using?
> >
> > -Daniel
> >
> > On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users
> > mailto:usrp-users@lists.ettus.com>> wrote:
> >
> > Hi,
> > I have very similar problem with X310. I am running a C++
> application,
> > so I have a bit more flexibility I guess. After I do the
> > set_time_unknown_pps to sync to the 1PPS signal, I run the function
> > get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns
> > for
> > an old firmware due to a bug, which was fixed a few weeks ago). If
> that
> > is the case I just do the sync again until the offset is zero.
> > I don't know if it is an firmawre problem or if it is because the
> > signal
> > integrety of the 1PPS signal is not good enough.
> > Maybe that is also a solution for you.
> > Best regards,
> > Fabian
> >
> > Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:
> >  > Hello,
> >  > I am working with the X310 USRP. I have two identical custom
> blocks
> >  > feeding the RF frontends.
> >  >
> >  > flowchart
> >  > -
> >  > HW Block1 -> RF0-TX1 |---<
> >  > HW Block2 -> RF1-TX1 |---<
> >  >
> >  > The system is synchronized to an external PPS reference. The
> > sampling
> >  > rate is 200 MSps and the signal bandwidth is 160 MHz for both
> > channels.
> >  > The two HW blocks start  transmitting at the exactly same time.
> Time
> >  > resolution is 5ns.
> >  > In most cases the two outgoing RF signals present a 1ns time
> offset.
> >  > Which can be understood as a phase offset.
> >  >
> >  > But From time to time there is a 6ns delay between the channels. I
> >  > assume this 6ns comprises the 1ns delay due to phase offset + 5
> > ns delay
> >  > due to misalignment of outgoing samples.
> >  >
> >  > What could be the origin of this one sample misalignement? Is it
> > a way
> >  > to fix it? Or working close to the limits of the device should
> such
> >  > behavior be expected?
> >  >
> >  > Thanks in advance
> >  >
> >  > Best Regards
> >  > Cherif
> >  >
> >  >
> >  > ___
> >  > 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
> >  >
> >
> > --
> > --
> > M.-Sc. Fabian Schwartau
> > Technische Universität Braunschweig
> > Institut für Hochfrequenztechnik
> > Schleinitzstr. 22
> > 38106 Braunschweig
> > Germany
> >
> > Tel.:   +49-(0)531-391-2017
> > Fax:+49-(0)531-391-2045
> > Email: fabian.schwar...@ihf.tu-bs.de
> > <mailto:fabian.schwar...@ihf.tu-bs.de>
> > WWW: http://www.tu-braunschweig.de/ihf
> > --
> >
> > ___
> > 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
> >
> >
> >
> > --
> >
> > Daniel Jepson
> >
> > Digital Hardware Engineer
> >
> > National Instruments
> >
> > O: +1.512.683.61

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Daniel Jepson via USRP-users]

Hi Fabian, Cherif,

What is the external PPS device you are using?

-Daniel

On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I have very similar problem with X310. I am running a C++ application,
> so I have a bit more flexibility I guess. After I do the
> set_time_unknown_pps to sync to the 1PPS signal, I run the function
> get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns for
> an old firmware due to a bug, which was fixed a few weeks ago). If that
> is the case I just do the sync again until the offset is zero.
> I don't know if it is an firmawre problem or if it is because the signal
> integrety of the 1PPS signal is not good enough.
> Maybe that is also a solution for you.
> Best regards,
> Fabian
>
> Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:
> > Hello,
> > I am working with the X310 USRP. I have two identical custom blocks
> > feeding the RF frontends.
> >
> > flowchart
> > -
> > HW Block1 -> RF0-TX1 |---<
> > HW Block2 -> RF1-TX1 |---<
> >
> > The system is synchronized to an external PPS reference. The sampling
> > rate is 200 MSps and the signal bandwidth is 160 MHz for both channels.
> > The two HW blocks start  transmitting at the exactly same time. Time
> > resolution is 5ns.
> > In most cases the two outgoing RF signals present a 1ns time offset.
> > Which can be understood as a phase offset.
> >
> > But From time to time there is a 6ns delay between the channels. I
> > assume this 6ns comprises the 1ns delay due to phase offset + 5 ns delay
> > due to misalignment of outgoing samples.
> >
> > What could be the origin of this one sample misalignement? Is it a way
> > to fix it? Or working close to the limits of the device should such
> > behavior be expected?
> >
> > Thanks in advance
> >
> > Best Regards
> > Cherif
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> --
> --
> M.-Sc. Fabian Schwartau
> Technische Universität Braunschweig
> Institut für Hochfrequenztechnik
> Schleinitzstr. 22
> 38106 Braunschweig
> Germany
>
> Tel.:   +49-(0)531-391-2017
> Fax:+49-(0)531-391-2045
> Email:  fabian.schwar...@ihf.tu-bs.de
> WWW:http://www.tu-braunschweig.de/ihf
> --
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: Re: Digital TV Clock recovery using N310 and GNUradio

[Daniel Jepson via USRP-users]

Sounds good. I'll allow others to comment on the GNURadio side of things.
Let me know if you have any specific HW concerns and I can chime in.

-Daniel

On Mon, Jul 22, 2019 at 5:17 PM m2wagner via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> Hey Daniel,
>
> Right now I'm setting an externally generated clock to a nearby frequency
> and recording the data to file for later processing. I'd like the LOs to be
> disciplined to the recovered clock (I have a clock splitter already). I
> suppose I'm most curious to see what GNUradio blocks people have had
> success with in similar applications
>
> -Mark
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>  Original message 
> From: Daniel Jepson 
> Date: 7/22/19 3:00 PM (GMT-08:00)
> To: Mark Wagner 
> Cc: Usrp Users 
> Subject: Re: [USRP-users] Digital TV Clock recovery using N310 and
> GNUradio
>
> Hi Mark,
>
> A few questions: Is your clock recovery algorithm running in the FPGA? Do
> you require the sample clock/LOs to be disciplined to this recovered clock?
>
> While the N310 does not have a dedicated clock output port, if the
> recovered clock is internal to the FPGA you can transmit a copy of it out
> the front panel GPIO port and (with a bit of creativity) possibly cable it
> into another N310. Just watch your voltage level compatibility.
>
> -Daniel
>
> On Mon, Jul 22, 2019 at 4:38 PM Mark Wagner via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey all,
>>
>> I'd like to recover the clock tone of a digital TV signal on one USRP
>> N310 and use it as the clock input to another N310. Does anyone have
>> experience doing something like this? I could use some pointers.
>>
>> -Mark
>>
>> --
>> Mark Wagner
>> University of California San Diego
>> Electrical and Computer Engineering
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163
>
> daniel.jep...@ni.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Digital TV Clock recovery using N310 and GNUradio

[Daniel Jepson via USRP-users]

Hi Mark,

A few questions: Is your clock recovery algorithm running in the FPGA? Do
you require the sample clock/LOs to be disciplined to this recovered clock?

While the N310 does not have a dedicated clock output port, if the
recovered clock is internal to the FPGA you can transmit a copy of it out
the front panel GPIO port and (with a bit of creativity) possibly cable it
into another N310. Just watch your voltage level compatibility.

-Daniel

On Mon, Jul 22, 2019 at 4:38 PM Mark Wagner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey all,
>
> I'd like to recover the clock tone of a digital TV signal on one USRP N310
> and use it as the clock input to another N310. Does anyone have experience
> doing something like this? I could use some pointers.
>
> -Mark
>
> --
> Mark Wagner
> University of California San Diego
> Electrical and Computer Engineering
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] REF IN clock

[Daniel Jepson via USRP-users]

Hi Diogo,

While there are hooks in UHD to support custom reference clock rates, the
majority of the synchronization (PPS and sample clock alignment) routines
rely heavily on known rates (10, 20, 25M). It would be non-trivial to
update everything to use 100M as reference. Let me know if this is a path
you want to pursue and I could point you in the direction of the major
refactoring areas.

-Daniel

On Wed, Apr 24, 2019 at 5:04 AM Diogo Botelho Ribeiro Marinho via
USRP-users  wrote:

> Hello,
>
> Looking into schematic of N310 motherboard , I notice it accepts 10MHz
> ,20MHz and 25MHz external clock. I need to synchronize the USRP N310 with
> external  PLL. Can i use 100 MHz clock as reference?
>
> Thanks in advanced
> Diogo Marinho
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] External reference issue of synchronizing two USRP N210s

[Daniel Jepson via USRP-users]

Hi Kwansik,

The Octoclock datasheet specification is only valid when driving into a 50
ohm load, and it should be just under 1.4Vpp.

Cheers,
-Daniel

On Thu, Jan 10, 2019 at 7:22 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 01/10/2019 08:07 PM, Kwansik Park via USRP-users wrote:
> > Dear all,
> >
> > I have been performing experiments of collecting GPS signals and
> > checking operations of GPS software defined receiver (SDR), using two
> > USRP N210s.
> >
> > I used "UHD: USRP Source" block in gnuradio-companion, and both clock
> > and time sources of the two N210s are set to be 'external'. The two
> > N210s are synchronized by 'octoclock-g' which  distributes 10 MHz
> > clock and 1 PPS signals.
> >
> > Until a few days ago, the experiments were successful and I check that
> > the SDR was able to acquire and track the received GPS signals.
> >
> > However, from this week, after collecting data using those two N210s,
> > the SDR cannnot even acquire any GPS signals. Any parameters of the
> > SDR and blocks in gnuradio-companion were not changed. When I set the
> > clock sources of the N210s to be 'internal' or 'default', the SDR
> > worked well.
> >
> > I found that the LED of the octoclock-g, which indicates status of
> > GPS-lock by the internal GPSDO, is turned off even though a GPS
> > antenna is connected to the octoclock-g.
> >
> > I checked the antenna and the cable using other commercial u-blox
> > receiver and there was no problem, but, the LED is still left turned off.
> >
> > In data sheet of the octoclock-g, it says that the 10 MHZ clock and
> > and 1 PPS signals can be still provided with lower accuracy, although
> > the GPSDO is not locked to the GPS signals.
> >
> > Meanwhile, I measured the 10 MHz clock and 1 PPS output using
> > oscilloscope. In data sheet of the octoclock-g, it says that Vpp
> > (Peak-to-peak voltage) of the 10 MHz clock is about 1.4V and I found
> > that the measured Vpp is about 3.5V which is higher than the Vpp
> > specified in the data sheet.
> >
> > Is there anyone who can explain why my USRPs don't work well?
> >
> > Thank you all.
> >
> >
> One thing to check for would be presence of the DC bias on the GPS input
> connector--somewhere between 3.3V and 5V--if you're using an
>amplified GPS antenna (most of them are), then it'll need the DC bias
> on the connector to power the LNA in the antenna module.
>
> Can you possibly post an oscilloscope screen shot of the 10MHz signal
> from the Octoclock-G ?
>
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 time offset between TX RF Outputs

[Daniel Jepson via USRP-users]

Hi Serge,

Are you measuring the phase offset between the TX0 and TX2 signals in a
steady-state case, or the time difference in the start of those signals?

In the former case, your results could be impacted by the lack of internal
LO sharing between daughterboards. I would fully expect an unknown phase
offset between channels 0 and 2 every time you reconfigure the device. In
the latter case, it sounds like a start trigger mismatch like Marcus
mentioned.

Can you share more details as to how you're measuring the phase offset?

Thanks,
-Daniel



On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
>
> I can try to use lower tx start times to see if the time offset changes
> with that.
>
> Thanks,
> Serge
>
> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
> wrote:
>
>> On 11/07/2018 09:31 PM, Serge Malo wrote:
>>
>> Yes:
>> We only use one streamer for all RF outputs, and send time_spec with each
>> call to the streamer's send method.
>> We reset the internal time with set_time_unkown_pps(0), and program the
>> first samples to be streamed at a time of 0.800s.
>> It is basically the same code we used on the X300/X310.
>>
>> Thanks,
>> Serge
>>
>> Well, that is quite strange--the magnitude of the time offsets is larger
>> than I would expect.
>>
>> Perhaps someone from the N310 team can comment?
>>
>> Serge, are you using the latest UHD and system image versions for the
>> N310?
>>
>>
>>
>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>>>
>>> Hi all,
>>>
>>> We are trying to send 4 synchronous signals from the 4 Tx ports of the
>>> N310.
>>> We are using UHD 3.13.1.0 RC1 under Ubuntu.
>>> Central Freq = 1575.42 GHz and 1227.6 MHz
>>> Master Clock rate = 153.6 MHz
>>>
>>> We would expect to have less than 3ns offset between all TX ports of the
>>> N310, like we do with the X300/X310. However, we have measured 4700ns
>>> between TX RF ports 0 and port 2.
>>> We have tried the next things with no more success:
>>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
>>> - Init with the device options "init_cals=ALL" and "force_reinit=1"
>>> - Use the internal GPSDO
>>> - Use clock_source=external and time_source=external (from an Octoclock).
>>>
>>> Can you tell us:
>>> -What time offset between TX RF ports we should expect to achieve?
>>> -Is there anything else we can try to reduce this offset to less than
>>> 3ns?
>>>
>>> Best regards,
>>> Serge
>>>
>>>
>>> How are you setting up your TX streamer?   Is it time-tagged to start at
>>> a particular device time?
>>>
>>>
>>>
>>> ___
>>> 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
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] n3xx master clock rate selection

[Daniel Jepson via USRP-users]

EJ,

Great news! I've also filed a feature request for the 120MHz MCR to keep
things moving on that front. I'm glad you found an intermediate solution!

-Daniel

On Wed, Oct 24, 2018 at 5:07 PM EJ Kreinar  wrote:

> Hi Daniel and others interested,
>
> To follow up on our discussion: I ended up making a "quick and dirty"
> rfnoc block to do rational resampling (integer upsample, fractional
> downsample). It's implemented by simply repackaging the existing duc and
> ddc blocks into a new combined noc_block. I've tested the FPGA and software
> targeting the n3xx and I can now hit my target rates of 2, 3, 6, & 10 MHz.
>
> I'm planning to use this block for now, and in case anyone else is
> interested I set up a couple PRs for the changes:
> - uhd: https://github.com/EttusResearch/fpga/pull/32/commits
> - fpga: https://github.com/EttusResearch/uhd/pull/219/commits
> - gr-ettus: https://github.com/EttusResearch/gr-ettus/pull/29/commits
>
> Cheers!
> EJ
>
> On Thu, Oct 18, 2018 at 5:56 PM EJ Kreinar  wrote:
>
>> Hi Scott,
>>
>> Thanks for the pointers! I actually tried making these changes this
>> afternoon... This is what I came up with for the LMK table (it appears the
>> sysref_divider wants to be 500 for this rate based on the other
>> calculations):
>>
>> ```
>> clkout_divider = {120e6:   25, 122.88e6:   25, 125e6:   24, 153.6e6:   20}
>> pll1_n_divider = {120e6:  125, 122.88e6:  128, 125e6:  125, 153.6e6:  128}
>> sysref_divider = {120e6:  500, 122.88e6:  500, 125e6:  480, 153.6e6:  400}
>> pll2_prescaler = {120e6:5, 122.88e6:2, 125e6:5, 153.6e6:2}
>> pll2_n_divider = {120e6:   25, 122.88e6:   64, 125e6:   25, 153.6e6:   64}
>> ```
>>
>> And then the obvious changes in ad937x_device::set_master_clock_rate. As
>> expected, some plumbing was required in both magnesium.py and tdc_sync.py
>> to allow a 120MHz master clock rate.
>>
>> The next roadblock comes down to the JESD configuration, specified here:
>> https://github.com/EttusResearch/uhd/blob/master/mpm/python/usrp_mpm/dboard_manager/mg_init.py#L249
>> ... And the JESD configuration is probably where I'm going to leave it for
>> now, since this configuration now appears to involve potentially generating
>> IP and calculating more magic numbers. Hope this can help anyone else
>> looking down this path to this point.
>>
>> I'm not a fan of the "fixed" fractional resampler from xilinx. Since I'm
>> looking at going through the effort of a new noc_block spinup anyway, I
>> would much prefer something programmable. I think I'll chase down the
>> "noc_block_fractional_resampler" instead and see where that leads.
>>
>> Cheers,
>> EJ
>>
>> On Thu, Oct 18, 2018 at 3:41 PM Daniel Jepson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> EJ,
>>>
>>> We are continuing to investigate the rate selection and possibility of
>>> adding 120 MHz as an MCR option. Our initial choices were (in large part)
>>> driven by the available options and example code provided through their
>>> evaluation software. It appears there is leeway in choosing MCRs, although
>>> anything lower than 122.88 MHz will begin sacrificing BW. The JESD204b core
>>> throughput requirements must typically match exactly the data rates inside
>>> the AD9371, so it is simply a matter of configuring both the AD9371 and the
>>> FPGA with the correct parameters (nothing seems too impossible, just work
>>> to be done). Note there is a difference between the DEVCLK (reference
>>> clock) input to the AD9371 and the actual sampling rate inside the device.
>>> To facilitate synchronization, we match the reference clock rate to the
>>> actual sampling rate.
>>>
>>> To get you going in the mean time, Xilinx provides a free, fixed
>>> fractional resampler through the FIR Compiler that might be helpful and is
>>> fairly lightweight. It's AXI-Stream, so building it into the signal path
>>> shouldn't be too difficult.
>>>
>>> I'll report back when we have more information on the 120 MHz feature
>>> request.
>>>
>>> -Daniel
>>>
>>> On Wed, Oct 17, 2018 at 7:46 PM EJ Kreinar  wrote:
>>>
>>>> So, I'm trying to understand the fundamental clock rate selection
>>>> limitations for the 9371... From what I understand, this is plausibly due
>>>> to some limitations of the JESD interface (?).
>>>>
>>>> This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
>>>>

Re: [USRP-users] n3xx master clock rate selection

[Daniel Jepson via USRP-users]

EJ,

We are continuing to investigate the rate selection and possibility of
adding 120 MHz as an MCR option. Our initial choices were (in large part)
driven by the available options and example code provided through their
evaluation software. It appears there is leeway in choosing MCRs, although
anything lower than 122.88 MHz will begin sacrificing BW. The JESD204b core
throughput requirements must typically match exactly the data rates inside
the AD9371, so it is simply a matter of configuring both the AD9371 and the
FPGA with the correct parameters (nothing seems too impossible, just work
to be done). Note there is a difference between the DEVCLK (reference
clock) input to the AD9371 and the actual sampling rate inside the device.
To facilitate synchronization, we match the reference clock rate to the
actual sampling rate.

To get you going in the mean time, Xilinx provides a free, fixed fractional
resampler through the FIR Compiler that might be helpful and is fairly
lightweight. It's AXI-Stream, so building it into the signal path shouldn't
be too difficult.

I'll report back when we have more information on the 120 MHz feature
request.

-Daniel

On Wed, Oct 17, 2018 at 7:46 PM EJ Kreinar  wrote:

> So, I'm trying to understand the fundamental clock rate selection
> limitations for the 9371... From what I understand, this is plausibly due
> to some limitations of the JESD interface (?).
>
> This wiki answer suggests possible rates of 122.88M, 153.6M, 184.32M,
> 245.76M, or 307.2M:
> https://ez.analog.com/wide-band-rf-transceivers/design-support-ad9371/f/q-a/100289/ad9371-sync-clock-frequencies
>
> Then the 9371 datasheet also shows example rates of 122.88, 153.6, 245.76,
> and 307.2 MHz: https://www.analog.com/en/products/ad9371.html
>
> So how is it that there's a master clock rate at 125MHz??
>
> EJ
>
> On Wed, Oct 17, 2018, 5:49 PM EJ Kreinar  wrote:
>
>> Hi Daniel,
>>
>> Sad to hear that! By the way, I forgot to mention another important rate
>> I need, 3 MHz, that also has an integer relationship to 120 MHz... Perhaps
>> I'd like to make a formal feature request for 120 MHz master clock?? It
>> strikes me as odd that so many of the "whole number" MHz sample rates are
>> neglected on the n3xx series by default-- it's often the case that I'll
>> want to interact with other hardware with baud rates at, say, 2 MHz or 10
>> MHz or something, but I just don't have the fpga-based fractional
>> conversions onhand right now...
>>
>> I'm certainly not afraid of nontrivial changes, so if the AD9371 supports
>> a clock rate that can give me these derived sample rates, I really see this
>> as the best solution since other platforms can already achieve these rates
>> without extra user-space processing requirements.
>>
>> However, if needed, potentially a "quick and dirty" approach might be to
>> make an rfnoc fractional resampler that combines a DUC and DDC into one
>> "ce", with a block controller to calculate the magical conversions... It's
>> not an optimal solution but it might do the trick here. Anyone else
>> interested in such an fpga-based fractional resampler?
>>
>> EJ
>>
>> On Wed, Oct 17, 2018, 1:52 PM Daniel Jepson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi EJ,
>>>
>>> The fundamental limitation comes from the AD9371. Although the datasheet
>>> specifies a wide reference clock input range, there are only certain
>>> supported rates within the public side of their API (at least that I'm
>>> aware of). These include the rates you mentioned from the KB.
>>>
>>> Assuming the AD9371 allows it, adding a new MCR is not trivial and would
>>> require a good deal of work across hardware, FPGA code, and MPM. The
>>> fractional resampler sounds like a much better path forward, albeit
>>> difficult right now.
>>>
>>> Hopefully that explains some of the background on the chosen MCRs. Sorry
>>> it wasn't exactly what you were hoping for!
>>>
>>> -Daniel
>>>
>>> On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm working on an FPGA application on the n310/n300, and I'm bumping
>>>> into a limitation of the master_clock_rate selection I'd like to be
>>>> able to use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none
>>>> of these values are integer multiples of the supported rates (122.88e6,
>>>> 125e6, 153.6e6 -- from here:
>>>> https://kb.ettus.com/N300/N310_Gett

Re: [USRP-users] X310 synchronization over White Rabbit

[Daniel Jepson via USRP-users]

Hi Jean-Michel,

As you hinted, it might be best to re-post this to the White Rabbit list:
https://lists.ohwr.org/sympa/info/white-rabbit-dev

>From my limited experience with White Rabbit and the N310 product, I don't
see any obvious issues, other than possibly within the switch.

-Daniel

On Wed, Oct 17, 2018 at 1:17 PM jean-michel friedt via USRP-users <
usrp-users@lists.ettus.com> wrote:

> [copy to the White Rabbit Developers mailing list]
>
> I am considering distributed radiofrequency signal acquisition and
> generation using
> two Ettus Research X310 SDR platforms, fed with the 1 PPS and 10 MHz
> outputs from our
> White Rabbit (WR) network. In addition to these signals, the control
> software (libuhd) running
> on the computer collecting data from all SDR platforms needs to timestamp
> packets in order
> to synchronize acquisitions. If I run a 1GbE network through a switch, all
> works fine, I can
> collect synchronous data from the local and remote site. In real life I'd
> like to use the
> WR network to transfer the data: I know my network configuration is good
> since I can ping
> the USRPs. I have increased MTUs on the host Ethernet interfaces and the
> WRS (running
> firmware 5.0.1) to 9000 as advised by libuhd.
> In all cases the synchronization of the USRPs fail with error messages
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
> while the same configuration works when replacing the WR network with a
> 1GbE switch. Is there
> some sort of excess latency introduced by the networking layer of WR that
> might be the cause
> of the timeout ? Is there any configuration I can tune to try to solve the
> issue ? Or lower some
> of the timeout limit on libuhd ?
>
> Thanks, Jean-Michel
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] n3xx master clock rate selection

[Daniel Jepson via USRP-users]

Hi EJ,

The fundamental limitation comes from the AD9371. Although the datasheet
specifies a wide reference clock input range, there are only certain
supported rates within the public side of their API (at least that I'm
aware of). These include the rates you mentioned from the KB.

Assuming the AD9371 allows it, adding a new MCR is not trivial and would
require a good deal of work across hardware, FPGA code, and MPM. The
fractional resampler sounds like a much better path forward, albeit
difficult right now.

Hopefully that explains some of the background on the chosen MCRs. Sorry it
wasn't exactly what you were hoping for!

-Daniel

On Wed, Oct 17, 2018 at 10:50 AM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm working on an FPGA application on the n310/n300, and I'm bumping into
> a limitation of the master_clock_rate selection I'd like to be able to
> use sample rates in the FPGA of 2 MHz, 4 MHz, and 10 MHz, but none of these
> values are integer multiples of the supported rates (122.88e6, 125e6,
> 153.6e6 -- from here:
> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Supported_Sample_Rates).
> This causes a problem in the FPGA since I would need a fractional
> resampler, which I dont currently have, unfortunately.
>
> What's the fundamental limitation of these master clock rates? I would
> have assumed that the AD9371-based architecture would have resulted in a
> wider variety of plausible clock rates, similar to the AD9361 on the E310.
> I havent found these limits yet in the software or FPGA, so any pointers
> where to look would be appreciated.
>
> As a follow up question, how feasible would it be to add a master clock
> rate of 120 MHz?? Any ideas where to make these changes? This would answer
> the mail for my sample rates of interest right now.
>
> Thanks!
> EJ
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 and gpsdo strange behavior

[Daniel Jepson via USRP-users]

All,

A patch for this bug is now included in UHD-3.13. The root cause was a
clock switching routine failing to re-initialize the daughterboard PLLs.

https://github.com/EttusResearch/uhd/tree/UHD-3.13

The specific fix is in 5286f1c.

Cheers,
-Daniel

On Tue, Aug 7, 2018 at 9:36 AM, Rob Kossler  wrote:

> I am not specifying MCR so it should be 125e6, I believe.
>
> On Tue, Aug 7, 2018 at 10:29 AM Daniel Jepson 
> wrote:
>
>> Rob,
>>
>> That is indeed strange behavior. The GPSDO for the N310 has changed from
>> previous products to produce a 20MHz reference instead of 10MHz. Either
>> way, the PPS should arrive every 20e6 ticks of the reference clock from the
>> GPSDO, whether it is locked or not. It appears that the PPS is around 8us
>> (160 ticks at 20MHz and 1000 at 125MHz) short of a full second, if I'm
>> deducing things correctly from your data.
>>
>> What master clock rate are you specifying?
>>
>> -Daniel
>>
>> On Thu, Aug 2, 2018 at 9:48 PM, Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I am learning to use the gpsdo capability of the N310 and I stumbled
>>> upon something strange. I have a capability in my software for displaying a
>>> message every time the "last PPS" value changes. Note that during startup,
>>> I set the clock to zero on a PPS trigger.
>>>
>>> If I set "time_source=internal,clock_source=internal", I get the
>>> following expected behavior
>>> Mboard 0 last PPS time: 3
>>> Mboard 0 last PPS time: 4
>>> Mboard 0 last PPS time: 5
>>> Mboard 0 last PPS time: 6
>>> Mboard 0 last PPS time: 7
>>> Mboard 0 last PPS time: 8
>>> Mboard 0 last PPS time: 9
>>> Mboard 0 last PPS time: 10
>>> Mboard 0 last PPS time: 11
>>> Mboard 0 last PPS time: 12
>>> Mboard 0 last PPS time: 13
>>>
>>> But if I set "time_source=gpsdo,clock_source=gpsdo", I get the
>>> following unexpected behavior
>>> Mboard 0 last PPS time: 2.9998
>>> Mboard 0 last PPS time: 3.9998
>>> Mboard 0 last PPS time: 4.9998
>>> Mboard 0 last PPS time: 5.9997
>>> Mboard 0 last PPS time: 6.9997
>>> Mboard 0 last PPS time: 7.9996
>>> Mboard 0 last PPS time: 8.9996
>>> Mboard 0 last PPS time: 9.9995
>>> Mboard 0 last PPS time: 10.9995
>>> Mboard 0 last PPS time: 11.9994
>>> Mboard 0 last PPS time: 12.9994
>>>
>>> Note that the time is slowly "walking". It seems that the PPS and 10MHz
>>> (driving the clock ticking) aren't synced.  Any suggestions?
>>>
>>> BTW, I verified that the sensor "gps_locked" was true before running
>>> this code.  I included the source code below for this functionality.
>>>
>>> stop_signal_called = false;
>>> std::vector dbl_vec(usrp->get_num_mboards());
>>> std::cout << "Press Ctrl + C to stop looping..." <<
>>> std::endl;
>>> while (not stop_signal_called) {
>>> for (size_t iboard = 0; iboard <
>>> usrp->get_num_mboards(); iboard++) {
>>> std::cout << boost::format("Mboard %d last PPS time:
>>> %g") % iboard % usrp->get_time_last_pps(iboard).get_real_secs() <<
>>> std::endl;
>>> dbl_vec[iboard] = usrp->get_time_last_pps(
>>> iboard).get_real_secs();
>>> }
>>> while (not stop_signal_called and
>>> usrp->get_time_last_pps(0).get_real_secs() == dbl_vec[0])
>>> boost::this_thread::sleep(boost::posix_time::
>>> milliseconds(1));
>>> }
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>>
>> Daniel Jepson
>>
>> Digital Hardware Engineer
>>
>> National Instruments
>>
>>
>>
>> O: +1.512.683.6163
>>
>> daniel.jep...@ni.com
>>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 and gpsdo strange behavior

[Daniel Jepson via USRP-users]

Rob,

That is indeed strange behavior. The GPSDO for the N310 has changed from
previous products to produce a 20MHz reference instead of 10MHz. Either
way, the PPS should arrive every 20e6 ticks of the reference clock from the
GPSDO, whether it is locked or not. It appears that the PPS is around 8us
(160 ticks at 20MHz and 1000 at 125MHz) short of a full second, if I'm
deducing things correctly from your data.

What master clock rate are you specifying?

-Daniel

On Thu, Aug 2, 2018 at 9:48 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am learning to use the gpsdo capability of the N310 and I stumbled upon
> something strange. I have a capability in my software for displaying a
> message every time the "last PPS" value changes. Note that during startup,
> I set the clock to zero on a PPS trigger.
>
> If I set "time_source=internal,clock_source=internal", I get the
> following expected behavior
> Mboard 0 last PPS time: 3
> Mboard 0 last PPS time: 4
> Mboard 0 last PPS time: 5
> Mboard 0 last PPS time: 6
> Mboard 0 last PPS time: 7
> Mboard 0 last PPS time: 8
> Mboard 0 last PPS time: 9
> Mboard 0 last PPS time: 10
> Mboard 0 last PPS time: 11
> Mboard 0 last PPS time: 12
> Mboard 0 last PPS time: 13
>
> But if I set "time_source=gpsdo,clock_source=gpsdo", I get the following
> unexpected behavior
> Mboard 0 last PPS time: 2.9998
> Mboard 0 last PPS time: 3.9998
> Mboard 0 last PPS time: 4.9998
> Mboard 0 last PPS time: 5.9997
> Mboard 0 last PPS time: 6.9997
> Mboard 0 last PPS time: 7.9996
> Mboard 0 last PPS time: 8.9996
> Mboard 0 last PPS time: 9.9995
> Mboard 0 last PPS time: 10.9995
> Mboard 0 last PPS time: 11.9994
> Mboard 0 last PPS time: 12.9994
>
> Note that the time is slowly "walking". It seems that the PPS and 10MHz
> (driving the clock ticking) aren't synced.  Any suggestions?
>
> BTW, I verified that the sensor "gps_locked" was true before running this
> code.  I included the source code below for this functionality.
>
> stop_signal_called = false;
> std::vector dbl_vec(usrp->get_num_mboards());
> std::cout << "Press Ctrl + C to stop looping..." << std::endl;
> while (not stop_signal_called) {
> for (size_t iboard = 0; iboard < usrp->get_num_mboards();
> iboard++) {
> std::cout << boost::format("Mboard %d last PPS time:
> %g") % iboard % usrp->get_time_last_pps(iboard).get_real_secs() <<
> std::endl;
> dbl_vec[iboard] = usrp->get_time_last_pps(
> iboard).get_real_secs();
> }
> while (not stop_signal_called and
> usrp->get_time_last_pps(0).get_real_secs() == dbl_vec[0])
> boost::this_thread::sleep(boost::posix_time::
> milliseconds(1));
> }
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 and gpsdo strange behavior

[Daniel Jepson via USRP-users]

Hi Rob,

Thanks for the heads up on the documentation bug. While digging through it
I also noticed a bug in the White Rabbit arguments. WR disciplines the
internal oscillator, so that must be explicitly selected. Below is the
correct clock/time combination to enable WR:

auto usrp =
uhd::usrp::multi_usrp::make("type=n3xx,clock_source=internal,time_source=sfp0");

-Daniel

On Thu, Aug 2, 2018 at 10:32 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> One more small thing The device arguments "time_source" and
> "clock_source" are not listed in the device arguments table in the UHD
> manual (http://files.ettus.com/manual/page_usrp_n3xx.html#
> n3xx_usage_device_args).  They are, however, shown as examples in the
> clock/time synchronization section (http://files.ettus.com/
> manual/page_usrp_n3xx.html#n3xx_synchronization). Updating the table
> would be helpful.
>
> Rob
>
> On Thu, Aug 2, 2018 at 10:48 PM Rob Kossler  wrote:
>
>> I am learning to use the gpsdo capability of the N310 and I stumbled upon
>> something strange. I have a capability in my software for displaying a
>> message every time the "last PPS" value changes. Note that during startup,
>> I set the clock to zero on a PPS trigger.
>>
>> If I set "time_source=internal,clock_source=internal", I get the
>> following expected behavior
>> Mboard 0 last PPS time: 3
>> Mboard 0 last PPS time: 4
>> Mboard 0 last PPS time: 5
>> Mboard 0 last PPS time: 6
>> Mboard 0 last PPS time: 7
>> Mboard 0 last PPS time: 8
>> Mboard 0 last PPS time: 9
>> Mboard 0 last PPS time: 10
>> Mboard 0 last PPS time: 11
>> Mboard 0 last PPS time: 12
>> Mboard 0 last PPS time: 13
>>
>> But if I set "time_source=gpsdo,clock_source=gpsdo", I get the following
>> unexpected behavior
>> Mboard 0 last PPS time: 2.9998
>> Mboard 0 last PPS time: 3.9998
>> Mboard 0 last PPS time: 4.9998
>> Mboard 0 last PPS time: 5.9997
>> Mboard 0 last PPS time: 6.9997
>> Mboard 0 last PPS time: 7.9996
>> Mboard 0 last PPS time: 8.9996
>> Mboard 0 last PPS time: 9.9995
>> Mboard 0 last PPS time: 10.9995
>> Mboard 0 last PPS time: 11.9994
>> Mboard 0 last PPS time: 12.9994
>>
>> Note that the time is slowly "walking". It seems that the PPS and 10MHz
>> (driving the clock ticking) aren't synced.  Any suggestions?
>>
>> BTW, I verified that the sensor "gps_locked" was true before running this
>> code.  I included the source code below for this functionality.
>>
>> stop_signal_called = false;
>> std::vector dbl_vec(usrp->get_num_mboards());
>> std::cout << "Press Ctrl + C to stop looping..." << std::endl;
>> while (not stop_signal_called) {
>> for (size_t iboard = 0; iboard < usrp->get_num_mboards();
>> iboard++) {
>> std::cout << boost::format("Mboard %d last PPS time:
>> %g") % iboard % usrp->get_time_last_pps(iboard).get_real_secs() <<
>> std::endl;
>> dbl_vec[iboard] = usrp->get_time_last_pps(
>> iboard).get_real_secs();
>> }
>> while (not stop_signal_called and
>> usrp->get_time_last_pps(0).get_real_secs() == dbl_vec[0])
>> boost::this_thread::sleep(boost::posix_time::
>> milliseconds(1));
>> }
>>
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] two X310 synchronization

[Daniel Jepson via USRP-users]

Dmitry,

The PPS and 10MHz should (at the very least) be generated using the same
base clock so they don't drift with respect to one another. Since you are
using multiple X310 devices, it is also important that the PPS arrives at
each device on the exact same cycle of the 10MHz clock--otherwise you may
see your timekeepers in each X310 offset with respect to one another. There
are no setup or hold specs for the X310 for PPS relative to 10MHz, but if
you use equal length cables for both signals you should achieve a decent
level of consistency.

-Daniel

On Mon, Jun 18, 2018 at 10:17 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/18/2018 10:57 AM, Дмитрий Михайличенко via USRP-users wrote:
>
> Is it important to have PPS signal aligned with reference 10 MHz signal.
> In my case they come from different sources.
>
> thanks,
> Dmitry?
>
> That shouldn't matter
>
>
>
>
> пн, 18 июн. 2018 г. в 17:37, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> On 06/18/2018 10:28 AM, Дмитрий Михайличенко via USRP-users wrote:
>>
>> The frequency is around 600 MHz. I also tried higher frequencies. The
>> offset is visible on picture attached.
>>
>> thanks,
>> Dmitry
>>
>> If you look here:
>>
>> https://kb.ettus.com/UBX
>>
>> You can see that for frequencies below 1GHz, you have to use a 20MHz
>> daughterboard clock for UBX to achieve synchronization.
>>   I don't know if SBX will work correctly with a 20MHz daughterboard
>> clock, so you can't have "mixed" UBX + SBX on the same
>>   X310.
>>
>> Also, integer-N tuning can help maintain better phase synchronization
>> characteristics:
>>
>> https://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>>
>>
>> пн, 18 июн. 2018 г. в 14:50, Дмитрий Михайличенко :
>>
>>> Hi,
>>>
>>> I have a couple of X310 each of them has UBX+SBX cards. The devices are
>>> synchronized by external 10MHz + PPS signal. But in my test I see random
>>> phase delay between all channels that varies between test runs. The test
>>> creates multi usrp device, sets up time and tunes to the same frequency
>>> using timed command, then it captures some buffers. The same external
>>> signal is supplied to all antenna ports. Is it expected to have random
>>> delay between channels? Is there any way to have constant phase delay from
>>> run to run?
>>>
>>> thanks,
>>> Dmitry
>>>
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://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
>>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 sample rate

[Daniel Jepson via USRP-users]

Correct, the master clock rate must be one of those three values. Others
will have to weigh in on the specifics of set/get rx/tx rate.

On Fri, Mar 2, 2018 at 8:43 AM, Андрей 1  wrote:

> When I set the 200 MHz function to set_rx_rate and then I request
> get_rx_rate, then I get 100 MHz.
> What values can I set for master clock rate? Only those three values?
>
>
> 02.03.2018, 16:30, Daniel Jepson 
> Hi,
>
> The X300/X310 supports three Sampling Rates: 120MHz, 184.32MHz, and
> 200MHz. Your rate was most likely coerced to the most common rate of 200M.
> The FPGA then performs decimation and interpolation such that the host
> doesn't have to stream all that bandwidth (nor can it in most cases). The
> streaming rate called out in your screen shots is 10.0Msps.
>
> Does that answer your question?
>
> -Daniel
>
> On Fri, Mar 2, 2018 at 7:57 AM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello
>
> When I open  device with uhd_usrp_make in the terminal I see a message
> "invalid sample rate 100 MHz actual rate is 200 MHz".The same message I see
> when running application from uhd samples folder.
> If I set sample rate 200 MHz and then read them from device I got 100 MHz.
>
> What does this mean and what is the maximum clock of the X300 in single
> and multichannel mode?
>
> See png for detail.
>
> Thank you
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163 <(512)%20683-6163>
>
> daniel.jep...@ni.com
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 sample rate

[Daniel Jepson via USRP-users]

Hi,

The X300/X310 supports three Sampling Rates: 120MHz, 184.32MHz, and 200MHz.
Your rate was most likely coerced to the most common rate of 200M. The FPGA
then performs decimation and interpolation such that the host doesn't have
to stream all that bandwidth (nor can it in most cases). The streaming rate
called out in your screen shots is 10.0Msps.

Does that answer your question?

-Daniel

On Fri, Mar 2, 2018 at 7:57 AM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
> When I open  device with uhd_usrp_make in the terminal I see a message
> "invalid sample rate 100 MHz actual rate is 200 MHz".The same message I see
> when running application from uhd samples folder.
> If I set sample rate 200 MHz and then read them from device I got 100 MHz.
>
> What does this mean and what is the maximum clock of the X300 in single
> and multichannel mode?
>
> See png for detail.
>
> Thank you
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com