Multi usrp, 1 odd channel, HW problem?

GNU Radio
1

Hi all-

I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
performed the clock synching described here:
http://gnuradio.org/redmine/wiki/1/MultiUsrp

I’m doing 4-channel receive, using a power splitter to send the same CW
signal into all 4 d’cards, and tuning them all identically.

3 of the 4 channels are nicely phase-locked. The 4th seems a
little…off.

ClockMasterUSRP (Serial #5821): Side A: “red” channel
ClockMasterUSRP (Serial #5821): Side B: “green” channel
ClockSlaveUSRP (Serial #2087): Side A: “blue” channel
ClockSlaveUSRP (Serial #2087): Side B: “black” channel <— problem
with this guy

Please see these 3 images to see the problem:
http://picasaweb.google.com/steven.p.clark/MultiUsrpGlitches?feat=directlink

You can see the problem in both the frequency domain, and in the time
domain.

I tried swapping daughtercards around, and the problem is not tied to
any
one daughtercard, but rather to slave USRP side B.

Any idea what could be causing this? Shouldn’t the same clock be going
to
both sides of the USRP? (why does blue look fine, but black does not?)

-Steven

2

Probe R201 on all 4 WBX boards with an oscilloscope while running. One
side of the resistor is ground and the other side is the reference
clock. They should all be around the same amplitude, and have the exact
same frequency and phase.

Matt

3

On Thu, Oct 14, 2010 at 12:47 PM, Matt E. [email protected] wrote:

You can see the problem in both the frequency domain, and in the time

Matt-

Sorry for the delay in getting back to you. I took a look at R201 on all
dboards as you suggested. All 4 looked fairly similar – a clean-looking
64MHz sine wave. Amplitudes were close, in the 700-800mV p-p range.
Comparing between 2 dboards on the same USRP, the phases matched pretty
well
(within a few degrees I would say). Comparing from one USRP to the
other,
there was a definite phase offset (~90degrees). Since the SMA cable
bringing
the clock from master to slave is a few feet long, this seems
reasonable.

What’s the next step?

-Steven

4

On Wed, Oct 20, 2010 at 7:41 PM, Steven C.
[email protected]wrote:

Comparing between 2 dboards on the same USRP, the phases matched pretty well
(within a few degrees I would say). Comparing from one USRP to the other,
there was a definite phase offset (~90degrees). Since the SMA cable bringing
the clock from master to slave is a few feet long, this seems reasonable.

What’s the next step?

-Steven

New info.

All 4 channels look fine when capturing individually on them.
Furthermore, frequency-wise, all the individual captures look different
from their corresponding simultaneous captures. For example, with
individual captures my CW input might show up as energy in FFT bin #514
of
1024
for all 4 chans, whereas with a combined capture, the energy shows up in
bin #535 for Chans 1-3, and in bin #536 for Chan 4. This is consistent
with all 4 channels dropping occasional samples when used jointly, but
with chan 4 dropping them slightly more frequently than the others. So I
would say the problem is not as simple as “one channel has HW problems”,
but rather there is something system-level going on. Sample rate was
250kHz, which should be plenty doable…

Does anybody have any thoughts as to what might be going on?

-Steven

5

On Thu, Oct 14, 2010 at 12:13 PM, Steven C.
[email protected]wrote:

domain.

I tried swapping daughtercards around, and the problem is not tied to any
one daughtercard, but rather to slave USRP side B.

Any idea what could be causing this? Shouldn’t the same clock be going to
both sides of the USRP? (why does blue look fine, but black does not?)

-Steven

Solved…see if you can spot the problem:

self.usrp_master.tune(0, self.wbx0_subdev, freq)
self.usrp_master.tune(1, self.wbx1_subdev, freq)
self.usrp_slave.tune(0, self.wbx2_subdev, freq)
self.usrp_slave.tune(0, self.wbx3_subdev, freq)

/facepalm

(The final line’s 0 should be a 1. the daughtercards were getting tuned
properly, but the 4th DDC was not). Everything looks fine now. Sorry for
suspecting the hardware, Matt!

-Steven