# Issues with syncing two USRPs!

**URL:** <https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327>\
**Category:** GNU Radio\
**Created:** [June 10, 2014, 10:10pm UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327 "2014-06-10T22:10:18Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [June 10, 2014, 10:10pm UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/1 "2014-06-10T22:10:18Z")

</div>

Hi,

I am a new user of USRP/GNU Radio. I am experimenting with a system  
comprised of one transmitter and multiple receivers. For now, I have two  
USRP N200. On the first USRP, I got one LFTX and one LFRX daughter  
boards.  
On the other, I got one LFRX daughter board.

In my application, it is important that the transmit and receive  
channels  
are synchronized (i.e., both device time and channel phase). For this,  
I  
am using my own GPS and PPS signals.

For the sake of testing, I am feeding the output of LFTX to all the  
inputs  
in LFRX (i.e., four receive channels). The output/input type is  
Complexfloat32. In GRC, when I use a separate USRP source block for  
each  
motherboard (i.e., without synchronization), the system is working and I  
can receive four unsynchronised replicas of my transmitted signal.

However, when I a use a single USRP source with two-motherboard and  
four-channel options, I get the following error message:

linux; GNU C++ version 4.8.2; Boost\_105400; UHD\_003.007.001-68-gc4b1f810

– Opening a USRP2/N-Series device…  
– Current recv frame size: 1472 bytes  
– Current send frame size: 1472 bytes  
– Opening a USRP2/N-Series device…  
– Current recv frame size: 1472 bytes  
– Current send frame size: 1472 bytes  
– 1) catch time transition at pps edge  
– 2) set times next pps (synchronously)  
Using Volk machine: sse4\_a\_64\_orc  
_thread[thread-per-block[4]: \<block gr uhd usrp source (1)\>]:  
RuntimeError:  
fifo ctrl timed out looking for acks_

> > > Done

My sample rate is 100e6/128 Hz. In the USRP source I set synch to:  
UnknownPPS, Mb0/1 clock source and Mb0/1 time source to EXTERNAL. Mb0/1  
subdev spec: A:A A:B. I tried to change the WireFormat from AUTOMATIC to  
ComplexInt16 without any difference.

I checked ./test\_pps\_input and I got a ‘success’. I think the issue has  
to  
do with the settings for syncing. Any ideas on what causes this  
problem?

BTW, I am also aware of this link (  
[http://files.ettus.com/uhd\_docs/manual/html/sync.html](http://files.ettus.com/uhd_docs/manual/html/sync.html)), but I am not  
sure  
where the commands of synchronizing the device time and channel phase  
should be applied?

Thank you.

Best regards,  
Khalid

---

<div class="post-metadata">

**Author:** ![khalid.el-darymli](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/6a8cbe/32.png) [@khalid.el-darymli](https://www.ruby-forum.com/u/khalid.el-darymli)\
**Post date:** [June 11, 2014, 3:21pm UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/2 "2014-06-11T15:21:56Z")

</div>

On 10.06.2014 22:09, khalid.el-darymli wrote:

> I am a new user of USRP/GNU Radio. I am experimenting with a system  
> comprised of one transmitter and multiple receivers. For now, I have two  
> USRP N200. On the first USRP, I got one LFTX and one LFRX daughter  
> boards. On the other, I got one LFRX daughter board.
> 
> In my application, it is important that the transmit and receive  
> channels are synchronized (i.e., both device time and channel phase).  
> For this, I am using my own GPS and PPS signals.

What’s the source of these signals? Have you made sure they are  
generating the right thing (i.e. 10 MHz ref)?

Out of curiousity, do you have a MIMO cable and are willing to test  
that?

> For the sake of testing, I am feeding the output of LFTX to all the  
> inputs in LFRX (i.e., four receive channels). The output/input type is  
> Complexfloat32. In GRC, when I use a separate USRP source block for  
> each motherboard (i.e., without synchronization), the system is working  
> and I can receive four unsynchronised replicas of my transmitted signal.

You’re saying you get 2 channels per LFRX, correct? Also, are you  
attenuating the signal?

> – Current recv frame size: 1472 bytes  
> subdev spec: A:A A:B. I tried to change the WireFormat from AUTOMATIC to  
> ComplexInt16 without any difference.

Just to confirm: You’re setting _both_ clock and time sources to  
external?

M

---

<div class="post-metadata">

**Author:** ![khalid.el-darymli](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/6a8cbe/32.png) [@khalid.el-darymli](https://www.ruby-forum.com/u/khalid.el-darymli)\
**Post date:** [June 14, 2014, 11:49pm UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/3 "2014-06-14T23:49:19Z")

</div>

Hi Martin,

This is a follow up on my earlier email. I am still having issues with  
getting two N200’s to work together.

First, please find a short answer to your questions.

> > Out of curiousity, do you have a MIMO cable and are willing to test that?  
> > No, I do not have a MIMO cable.

> > You’re saying you get 2 channels per LFRX, correct? Also, are you  
> > attenuating the signal?  
> > Yes, I tried both 2 (i.e., A:A, A:B) and 1 (i.e, A:AB). The signal is  
> > attenuated by a factor of four 'cuz I’m using two T’s each with two  
> > outputs.

> > Just to confirm: You’re setting _both_ clock and time sources to  
> > external?  
> > Yes.

I initially thought the issue has to do with syncing, but it seems that  
it  
is not due to syncing per se (?!)

A quick recap. One N200 acts as a single-channel Tx (i.e., A:AB) and a  
two-channel Rx (i.e., A:A and A:B). The other N200 only acts as a  
two-channel Rx (i.e., A:A and A:B).

I am using two T’s to split my Tx signal into four signals and I am  
feeding those to the Rx’s.  
[i.e., my Rx signal is attenuated by a factor of 4].

In GRC, I always use an USRP sink that is properly configured for the Tx  
AB  
channel.

At the Rx side, for the sake of testing, I tried multiple configurations  
as  
follows.

First, I only considered one N200 (i.e., a single motherboard) at a  
time,  
and I used a source as above. When I do so, _either I apply external  
sync  
and clock or not_, I am able to perfectly receive my signal. This test  
was  
successful when I fed-in the source with either the two Rx channels from  
the first or the second N200, separately.

Second, I used one single source with two motherboards and four Rx  
channels. I tested this\* with and without sync/clocking signals\*. In  
both  
cases, I get this error message:

> Using Volk machine: sse4\_a\_64\_orc  
> _thread[thread-per-block[4]: \<block gr uhd usrp source (1)\>]:  
> RuntimeError: fifo ctrl timed out looking for acks_

Please note that, despite this message, the GRC program looks as if it  
is  
running, and the GUI shows me the output from the scope (i.e., scope is  
just placed before the USRP Tx sink). However, the output from the  
scopes  
after the Rx USRP is null for the four channels.  
[For Rx’s with a single source, I also tried a single-channel from the  
two  
motherboards (i.e., A:AB) without any success].

Checking the system monitor on my computer confirms that one USRP is  
transmitting all the time while no receive/incoming traffic whatsoever.

Besides this, I tried various diagnostics. I thought that the issue may  
has  
to do with the Ethernet controller/card on my computer, and that it may  
be  
dropping/delaying some packets. Hence, I ‘unmanaged’ the Ethernet  
connections, and I applied static configuration. I also tried to disable  
some options in the network driver such as autoneg, adaptive, coalesce,  
etc., without any success.

Please find below some diagnoses that may give some clues on the FIFO  
ACK  
error,

T-UD2H:~$ sudo ethtool --show-coalesce eth4  
Coalesce parameters for eth4:  
Adaptive RX: off TX: off  
stats-block-usecs: 0  
sample-interval: 0  
pkt-rate-low: 0  
pkt-rate-high: 0

rx-usecs: 20  
rx-frames: 5  
rx-usecs-irq: 0  
rx-frames-irq: 5

tx-usecs: 72  
tx-frames: 53  
tx-usecs-irq: 0  
tx-frames-irq: 5

rx-usecs-low: 0  
rx-frame-low: 0  
tx-usecs-low: 0  
tx-frame-low: 0

rx-usecs-high: 0  
rx-frame-high: 0  
tx-usecs-high: 0  
tx-frame-high: 0

T-UD2H:/etc/network$ sudo ethtool --show-coalesce eth3  
Coalesce parameters for eth3:  
Adaptive RX: off TX: off  
stats-block-usecs: 0  
sample-interval: 0  
pkt-rate-low: 0  
pkt-rate-high: 0

rx-usecs: 20  
rx-frames: 5  
rx-usecs-irq: 0  
rx-frames-irq: 5

tx-usecs: 72  
tx-frames: 53  
tx-usecs-irq: 0  
tx-frames-irq: 5

rx-usecs-low: 0  
rx-frame-low: 0  
tx-usecs-low: 0  
tx-frame-low: 0

rx-usecs-high: 0  
rx-frame-high: 0  
tx-usecs-high: 0  
tx-frame-high: 0

T-UD2H:/etc/network$ ifconfig -a eth4  
eth4 Link encap:Ethernet HWaddr REMOVED  
inet addr:192.168.10.1 Bcast:192.168.10.255  
Mask:255.255.255.0  
inet6 addr: REMOVED\_by\_KE Scope:Link  
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1  
RX packets:118227 errors:0 dropped:0 overruns:0 frame:0  
TX packets:733915 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:8366882 (8.3 MB) TX bytes:930252111 (930.2 MB)  
Interrupt:19

GA-MA785GMT-UD2H:/etc/network$ ifconfig -a eth3  
eth3 Link encap:Ethernet HWaddr REMOVED  
inet addr:192.168.20.1 Bcast:192.168.20.255  
Mask:255.255.255.0  
inet6 addr: REMOVED\_by\_KE Scope:Link  
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1  
RX packets:40807 errors:0 dropped:0 overruns:0 frame:0  
TX packets:11811 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:3100954 (3.1 MB) TX bytes:1076135 (1.0 MB)  
Interrupt:18

We also sucessfuly upgraded the firmware for both the USRPs. We noticed  
that (i.e., also shown form the stickers on the back of each device) one  
N200 is rev 2.0 and the other is rev 4.0. Could that be the cause of the  
problem?

I will appreciate any help on fixing this issue.

Thank you in advance.

Khalid

On Wed, Jun 11, 2014 at 1:30 PM, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> On 10.06.2014 22:09, khalid.el-darymli wrote:  
> generating the right thing (i.e. 10 MHz ref)?  
> attenuating the signal?
> 
> > – Opening a USRP2/N-Series device…  
> > UnknownPPS, Mb0/1 clock source and Mb0/1 time source to EXTERNAL. Mb0/1  
> > problem?  
> > Khalid

–  
View this message in context:  
[http://gnuradio.4.n7.nabble.com/Issues-with-syncing-two-USRPs-tp48883p48921.html](http://gnuradio.4.n7.nabble.com/Issues-with-syncing-two-USRPs-tp48883p48921.html)  
Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![khalid.el-darymli](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/6a8cbe/32.png) [@khalid.el-darymli](https://www.ruby-forum.com/u/khalid.el-darymli)\
**Post date:** [June 15, 2014, 4:19am UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/4 "2014-06-15T04:19:51Z")

</div>

Hi Marcus,

Thanks for your reply.

> Do you know what kind of Ethernet controller is on your ports? Are  
> they 82579LM by any chance?

My Ethernet controller is Broadcom NetXtreme 57XX

> **[Support Documents and Downloads](https://www.broadcom.com/support/download-search?pf=Ethernet+Controllers&pg=Ethernet+Connectivity%2C+Switching%2C+and+PHYs)**
>
> Search technical documentation and downloads including firmware and drivers.

[http://www.broadcom.com/support/ethernet\_nic/downloaddrivers.php](http://www.broadcom.com/support/ethernet_nic/downloaddrivers.php)

> You _have_ to make certain that Network Manager isn’t trying to  
> automatically assigned addresses on those cards, since it will try, and  
> then take them out of service if it doesn’t get a DHCP address  
> assignment.

Yes, I ‘unmanaged’ the two Ethernet connections pertaining to the two  
N200’s. I can confirm that by going to the ‘network manager’ in Ubuntu  
where  
it shows that they are ‘unmanaged’. Then, in the ‘interfaces’ file I  
define  
the following:

auto eth3  
iface eth3 inet static  
address 192.168.10.1  
netmask 255.255.255.0  
pre-up ethtool -s eth3 speed 1000 duplex full autoneg off

auto eth4  
iface eth4 inet static  
address 192.168.20.1  
netmask 255.255.255.0  
pre-up ethtool -s eth3 speed 1000 duplex full autoneg off

I tried it both with and without the ‘pre-up’ line shown above without  
any  
success.

If it is a networking issue, is there any thing else you recommend?

Can it be an issue of compatibility since one device is N200 Rev 2.0 and  
the  
other is N200 Rev 4.0?

BTW, I tried to use an external signal generator (not the LFTX installed  
onboard one of the two N200’s) to feed both the LFRX receivers, and I  
used  
one USRP Source in GRC. The four channels worked just fine.

The problem is there when only using the LFTX (i.e., installed on one of  
the  
N200’s) simultaneously with the _four_ receive channels.

Thanks,  
Khalid

–  
View this message in context:  
[http://gnuradio.4.n7.nabble.com/Issues-with-syncing-two-USRPs-tp48883p48926.html](http://gnuradio.4.n7.nabble.com/Issues-with-syncing-two-USRPs-tp48883p48926.html)  
Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![khalid.el-darymli](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/6a8cbe/32.png) [@khalid.el-darymli](https://www.ruby-forum.com/u/khalid.el-darymli)\
**Post date:** [June 16, 2014, 2:09am UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/5 "2014-06-16T02:09:26Z")

</div>

Hi Marcus,

Thanks for your reply.

> Do you know what kind of Ethernet controller is on your ports? Are  
> they 82579LM by any chance?

My Ethernet controller is Broadcom NetXtreme 57XX

> **[Support Documents and Downloads](https://www.broadcom.com/support/download-search?pf=Ethernet+Controllers&pg=Ethernet+Connectivity%2C+Switching%2C+and+PHYs)**
>
> Search technical documentation and downloads including firmware and drivers.

> You _have_ to make certain that Network Manager isn’t trying to  
> automatically assigned addresses on those cards, since it will try, and  
> then take them out of service if it doesn’t get a DHCP address  
> assignment.

Yes, I ‘unmanaged’ the two Ethernet connections pertaining to the two  
N200’s. I can confirm that by going to the ‘network manager’ in Ubuntu  
where it shows that they are ‘unmanaged’. Then, in the ‘interfaces’ file  
I  
define the following:

auto eth3  
iface eth3 inet static  
address 192.168.10.1  
netmask 255.255.255.0  
pre-up ethtool -s eth3 speed 1000 duplex full autoneg off

auto eth4  
iface eth4 inet static  
address 192.168.20.1  
netmask 255.255.255.0  
pre-up ethtool -s eth3 speed 1000 duplex full autoneg off

I tried it both with and without the ‘pre-up’ line shown above without  
any  
success.

If it is a networking issue, is there any thing else you recommend?

Can it be an issue of compatibility since one device is N200 Rev 2.0 and  
the other is N200 Rev 4.0?

BTW, I tried to use an external signal generator (not the LFTX installed  
onboard one of the two N200’s) to feed both the LFRX receivers, and I  
used  
one USRP Source in GRC. The four channels worked just fine.

The problem is there when only using the LFTX (i.e., installed on one of  
the N200’s) simultaneously with the _four_ receive channels.

Thanks,  
Khalid

---

<div class="post-metadata">

**Author:** ![khalid.el-darymli](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/6a8cbe/32.png) [@khalid.el-darymli](https://www.ruby-forum.com/u/khalid.el-darymli)\
**Post date:** [June 15, 2014, 12:04am UTC](https://www.ruby-forum.com/t/issues-with-syncing-two-usrps/230327/6 "2014-06-15T00:04:09Z")

</div>

On 06/14/2014 05:48 PM, eldarymli wrote:

> Hi Martin,
> 
> This is a follow up on my earlier email. I am still having issues with  
> getting two N200’s to work together.
> 
> First, please find a short answer to your questions.  
> Do you know what kind of Ethernet controller is on your ports? Are  
> they 82579LM by any chance?

You _have_ to make certain that Network Manager isn’t trying to  
automatically assigned addresses on those cards, since it will try, and  
then take them out of service if it doesn’t get a DHCP address  
assignment.
