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

2019-09-27 Thread Cherif Diouf via USRP-users 
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

Re: [USRP-users] E320 unable to lock to external reference

2019-09-27 Thread Jason Matusiak via USRP-users 
Nate,

Thanks, this did the trick.  Edited 
/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/e320_periphs.py on the 
E320 with the changes and now it locks perfectly (tested only in network mode). 
 Thanks for finding this and pushing it out!


From: Nate Temple 
Sent: Friday, September 20, 2019 11:35 AM
To: Jason Matusiak 
Cc: Michael West ; USRP-users@lists.ettus.com 

Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

Here is the commit that fixes the e320 ext ref issue.

https://github.com/EttusResearch/uhd/commit/6a11a141b8d32d1919e8f9fe95d5c65e95ddd03b

We are aiming to have 3.14.1.1 tagged and released next week which will include 
this commit.

Regards,
Nate Temple


On Tue, Aug 6, 2019, 11:51 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Thanks for the update Michael, I'll pass it along.  Fingers crossed.


From: Michael West mailto:michael.w...@ettus.com>>
Sent: Monday, August 5, 2019 4:49 PM
To: Nate Temple mailto:nate.tem...@ettus.com>>
Cc: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>; Ettus 
Mail List mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

We have someone looking into this now.  In the meantime, try adding the device 
arguments "clock_source=external,time_source=external".

Regards,
Michael

On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi Jason,

I'm fairly confident that this is just a software issue.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do you 
have a gut as to whether or not it is a hardware or software issue?



From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

I've been able to recreate this and have filed an issue on our internal bug 
tracker and escalated as a high priority issue. I'm not able to provide any ETA 
on when we will have a fix for it, but hope it will be soon.

I will follow up as soon as I have more information.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:
Do you need anything from my side of things?


From: Nate Temple mailto:nate.tem...@ettus.com>>
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak 
mailto:ja...@gardettoengineering.com>>
Cc: Ettus Mail List 
mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] E320 unable to lock to external reference

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this issue. 
I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
OK, we've been fighting this for a while and we think we narrowed it down to 
being a problem with the E320 (NOTE: we are running the E320 in network mode, 
not embedded)

Some background:
1) external reference input is from an octo clock (so it the 1pps input) on 
many different ports
a) also tried to use a  Symmetricom box for external reference and had 
the same problems

3) the same code we are testing with works when using an x310 instead of an 
e320, with inputs from the same octoclock

4) the code basically does this:
a) sets the reference source to external
b) checks to see if the reference is locked (and it keeps doing this 
until we get a "locked" response, using the uhd commands to do this)

5) for the e320, the locked status never returns (when running the x310 with 
this code, it sometimes responds with unlocked, but after a few checks it comes 
back ok)

6) I tried some of the Ettus (UHD) test code
a) running the "sync_to_gps" program did work - the reference was able 
to lock to the internal (gps) reference
b) "test_clock_synch"  returns similiar errors to what we get with our 
program (see below):
Checking USRP devices for lock.
 * 318B08B: false
WARNING: One or more devices not locked.
Querying Clock for time and setting USRP times...
[WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked. MB_CLOCK_CTRL 
reg: 0x0002
Running 10 comparisons at random intervals.
Comparison #1
 * Clock time: 1563463644
 * 318B08B

[USRP-users] USRP X310 problem

2019-09-27 Thread Aaron Montilla via USRP-users 
Hi,
I am trying to set the connection between my PC and my USRP X310.
I ran the command uhd_find_devices, and successfully it found the USRP.
Then I use the uhd_usrp_probe command and I had the next error:
aaron@leonard:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.git-71-g18bc320d
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell: Expecting
6, got 5.
Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
supports revision 6. Please either upgrade the FPGA image (recommended) or
downgrade UHD.

I thought that upgrade the USRP was the best option, but when I try, I have
another error saying that the size of the image is too large ( only for 1
byte). I also read that I had to use the .bin file but I didn't have any.
So, could you please tell me what I could do?

Thank you very much in advance.
Kind regards,
Aaron
___
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

2019-09-27 Thread Fabian Schwartau via USRP-users 
No, it was a 3.3V CMOS variant of that IC. I cannot figure it out as I 
would have to take the hardware apart.


Am 27.09.2019 um 09:30 schrieb 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
mailto: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

>
 >      >
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

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

2019-09-27 Thread 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 
>> >  >
>> 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
>> >
>>
>> --
>> --
>> M.-Sc. Fabian Schwartau
>> Technische Universität Braunschweig
>> Institut für Hochfrequenztechnik
>>

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

2019-09-27 Thread 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 
> >  >
> 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
> >
>
> --
> --
> 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