Re: [Discuss-gnuradio] Issues with syncing two USRPs! (Discuss-gnuradio Digest, Vol 139, Issue 12)

[khalid.el-darymli]

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, <address@hidden> wrote:

------------------------------
Message: 9
Date: Wed, 11 Jun 2014 15:20:32 +0200
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Issues with syncing two USRPs!
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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?

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

Just to confirm: You're setting *both* clock and time sources to external?

M

>
> 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), but I am not
> sure where the commands of synchronizing the device time and channel
> phase  should be applied?
>
>
> Thank you.
>
> Best regards,
> Khalid
>
>
>
>
>