Re: [USRP-users] Reference Clock PLL failed to lock external source during daisy chain

[harfan ryanu via USRP-users]

Hi Robin and Marcus,
Thanks for your reply earlier,
I have read some thread saying we can still use daisy chain for 2 USRP, but
the phase noise will get worse as the number of the device chained increase.
I am just wondering if the function of set_clock_source_out and
set_time_source_out is for daisy chain, probably i could be wrong.
So i guess the only available option is by using external clock reference?
Thank you very much

Regards,
Harfan


On Mon, May 14, 2018, 23:15 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/14/2018 09:04 AM, ROBIN TORTORA via USRP-users wrote:
>
> Split both your 1pps and 10MHz and then run cables off the splitter to
> each X310 separately using "equal length" cables and you should be "good
> enough", dont daisy chain :)
>
> I don't think the daisy-chain support was ever implemented, at least
> partially because it's not a wonderful idea in terms of added phase-noise,
>   and added clock and 1PPS skew between the two devices.
>
>
> On May 14, 2018 at 4:28 AM harfan ryanu via USRP-users
>   wrote:
>
> Hi All,
> I am building application with two USRP X310 configuration using daisy
> chain. When i try to synchronize both USRP using this :
>
> usrp.ptr->set_clock_source_out(true,0);usrp.ptr->set_time_source_out(true,0);usrp.ptr->set_clock_source("external",1);usrp.ptr->set_time_source("external",1);
>
> My configuration is the first usrp (with addr0 configuration 192.168.140.2) 
> has an sma cable connected to the PPS Trig Out and Ref Out, while the other 
> end of the sma cable is connected to second usrp (
>
> with addr1 configuration 192.168.40.2) through PPS Trig In and Ref In.
>
> I got an error message telling RuntimeError: Reference Clock PLL failed to 
> lock to external source.
>
> I have explored some question in the past saying USRP x310 is not suitable 
> for daisy chain and still in experimental however that thread is from 2014, i 
> dont know if it is still valid.
>
> Could anyone help me to solve this problem?
>
> I am very grateful for any respond and help.
>
> Thank you very much,
>
>
> Regards,
>
> Harfan
>
> Sydney Uni
>
>
> ___
> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD and process forking

[Keith k via USRP-users]

Hello all

My intuition tells me this would be a bad idea, but before I try anything
with this, does anyone have any thoughts about how the multi-usrp object
would react in a situation where the process has been forked? I know that
the call to create a multi-usrp object will fail if called in a second
process, so I imagine it won't like being in 2 separate address spaces.

-- 
-Keith Kotyk
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N310 streaming documentation

[Louis Brown via USRP-users]

Tried that but it's not working for either on-board or SFP0, though I can ping 
both :

uhd_find_devices --args "addr=192.168.1.4,type=n3xx"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
Boost_106600; UHD_3.11.1.0-0-g34c56104
No UHD Devices Found

uhd_find_devices --args "addr=192.168.10.2,type=n3xx"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1); 
Boost_106600; UHD_3.11.1.0-0-g34c56104
No UHD Devices Found

The N310 Ethernet looks OK:

root@ni-n3xx-3145FA0:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BD 
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171 errors:0 dropped:0 overruns:0 frame:0
TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:17223 (16.8 KiB) TX bytes:7577 (7.3 KiB)
Interrupt:145 Base address:0xb000 

lo Link encap:Local Loopback 
inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:86 errors:0 dropped:0 overruns:0 frame:0
TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:6542 (6.3 KiB) TX bytes:6542 (6.3 KiB)


sfp0 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BE 


inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:8000 Metric:1
RX packets:471 errors:0 dropped:22 overruns:0 frame:0
TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:59389 (57.9 KiB) TX bytes:52721 (51.4 KiB)


sfp1 Link encap:Ethernet HWaddr 00:80:2F:18:AF:BF 
UP BROADCAST MULTICAST MTU:8000 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)



It can find itself on 127.0.0.1 

root@ni-n3xx-3145FA0:~# uhd_find_devices 
[INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; UHD_3.11.0.1-0-unknown

--
-- UHD Device 0
--
Device Address:
serial: 3145FA0
claimed: False
mgmt_addr: 127.0.0.1
product: n310
type: n3xx


But can't find itself on 192.168.10.2:

root@ni-n3xx-3145FA0:~# uhd_find_devices --args "addr=192.168.10.2,type=n3xx"
[INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; UHD_3.11.0.1-0-unknown
No UHD Devices Found

Like on the E310, do I need to start something?

Could it be UHD_3.11.0.1 on the N310 image and UHD_3.11.1.0 on my PC?

Thanks,
Lou





On 05/11/2018 06:14 PM, Brent Stapleton wrote:

The `type` should be n3xx, not n300.

--args "addr=192.168.10.2,type=n3xx"

Brent

Ah.  That's a change from N2xx and B2xx series.   Might I suggest putting
in synonyms, so that folks used to previous naming schemes won't become
  confused?



On Fri, May 11, 2018 at 3:06 PM, Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:


On 05/11/2018 05:57 PM, Louis Brown via USRP-users wrote:



Is there documentation on getting the N310 streaming interface working?
I'm able to ping the SFP0 port at 192.168.10.2 and the on-board at
192.168.1.4, but uhd_find_devices and uhd_usrp_probe find nothing:

uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 8.1.1 20180502 (Red Hat 8.1.1-1);
Boost_106600; UHD_3.11.1.0-0-g34c56104
Error: LookupError: KeyError: No devices found for ->
Device Address:
addr: 192.168.10.2

I did update the SD card image with:


http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.11.0.1-20180419/n3xx_common_sdimg_default-v3.11.0.1-20180419.zip


The ASCII art spectrum test works fine, so the hardware seems to be
working.

Thanks,
Lou

COuld you try adding "type=n300" to your --args ??


--args "addr=192.168.10.2,type=n300"



___
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

Re: [USRP-users] Reference Clock PLL failed to lock external source during daisy chain

[Marcus D. Leech via USRP-users]

On 05/14/2018 09:04 AM, ROBIN TORTORA via USRP-users wrote:


Split both your 1pps and 10MHz and then run cables off the splitter to 
each X310 separately using "equal length" cables and you should be 
"good enough", dont daisy chain :)


I don't think the daisy-chain support was ever implemented, at least 
partially because it's not a wonderful idea in terms of added phase-noise,

  and added clock and 1PPS skew between the two devices.


On May 14, 2018 at 4:28 AM harfan ryanu via USRP-users 
 wrote:


Hi All,
I am building application with two USRP X310 configuration using 
daisy chain. When i try to synchronize both USRP using this :

usrp.ptr->set_clock_source_out(true,0);
usrp.ptr->set_time_source_out(true,0);
usrp.ptr->set_clock_source("external",1);
usrp.ptr->set_time_source("external",1);
My configuration is the first usrp (with addr0 configuration 192.168.140.2) has 
an sma cable connected to the PPS Trig Out and Ref Out, while the other end of 
the sma cable is connected to second usrp (
with addr1 configuration 192.168.40.2) through PPS Trig In and Ref In.
I got an error message telling RuntimeError: Reference Clock PLL failed to lock 
to external source.
I have explored some question in the past saying USRP x310 is not suitable for 
daisy chain and still in experimental however that thread is from 2014, i dont 
know if it is still valid.
Could anyone help me to solve this problem?
I am very grateful for any respond and help.
Thank you very much,

Regards,
Harfan
Sydney Uni

___
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


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

Re: [USRP-users] [Discuss-gnuradio] USRP DDC and GNURadio Bandwidth Problem

[Derek Kozel via USRP-users]

Hello Ali,

To extend what Marcus has said, here is a link to the UHD manual page about
sample rates.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

Regards,
Derek

On Mon, May 14, 2018 at 8:54 AM, Müller, Marcus (CEL) 
wrote:

> Hi Ali,
>
> just like the console will tell you, 25 kS/s is simply impossible with
> an X310; instead, the minimum possible rate was used.
>
> You should probably just configure your X310 to get you e.g. 500 kS/s,
> and then resample in digital domain. If you're hesitant to design your
> own decimating filter, use the "rational resampler" block and configure
> it to decimate by (500/25)=20.
>
> Best regards,
> Marcus
>
> On Mon, 2018-05-14 at 10:18 +0300, Ali wrote:
> > Hi to all,
> >
> > I am using GNURadio to control an X310. I want to get IQ samples for
> only 25 kHz bandwidth.
> >
> > When I wrote 25 kHz to the bandwidth line in UHD-Source block in
> GNURadio, I still see the signals at 50 kHz or 75 kHz away from the center.
> My sampling rate is 195312 Hz. When checked in MATLAB, the signals are
> there. It looks like I cannot control the bandwidth with GNURadio.
> >
> > I suspected that there is not any DDC filter for this bandwidth. If it
> is so, what is the minimum bandwidth for USRPs? Are the bandwidths that I
> can use discrete? I am confused.
> >
> > Thanks in advance,
> > Ali
> >
> > ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP DDC and GNURadio Bandwidth Problem

[Ali via USRP-users]

Hi to all,

I am using GNURadio to control an X310. I want to get IQ samples for only
25 kHz bandwidth.

When I wrote 25 kHz to the bandwidth line in UHD-Source block in GNURadio,
I still see the signals at 50 kHz or 75 kHz away from the center. My
sampling rate is 195312 Hz. When checked in MATLAB, the signals are there.
It looks like I cannot control the bandwidth with GNURadio.

I suspected that there is not any DDC filter for this bandwidth. If it is
so, what is the minimum bandwidth for USRPs? Are the bandwidths that I can
use discrete? I am confused.

Thanks in advance,
Ali
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] auto start for e313

[liu Jong via USRP-users]

Hi all,
We have two pieces of E313,the difference of them is one of them insert sg1
imges and another insert sg3 image.
When we take DC power supply(12V) for e313,the  sg1's e313 would  auto
start,but for the sg3's e313,we must press power button,then e313 power on.
Is it normal?How could make auto start for sg3's e313?

best regards
Jon
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com