discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: Multiple USRP's debugging


From: Douglas Geiger
Subject: [Discuss-gnuradio] Re: Multiple USRP's debugging
Date: Tue, 22 Jul 2008 16:00:28 -0400

On Mon, Jul 21, 2008 at 9:46 AM, Douglas Geiger <address@hidden> wrote:
I am having trouble getting two USRP's synchronized using the multiple USRP setup described at http://www.gnuradio.org/trac/wiki/MultiUsrp and http://www.gnuradio.org/trac/wiki/USRPClockingNotes. I am able to open/get data from both USRP's independently, and have even crafted a program to setup simultaneous flowgraphs collecting data from both and feeding them into BBN's 80211b demodulator.  However, I would like to be able to synchronize the clock on both USRP's (I'm interested in looking at TDOA between packets). I have not had any luck getting the multi_usrp_oscope.py program displaying any data - and my attempts at using usrp_multi.multi_source_align as a source in e.g. the usrp_fft program have not been successful.  Are there any suggestions on where I should be looking to debug this?  I am using the multi_2rxhb_2tx.rbf fpga code, and using gnuradio-3.1.2 on a laptop running ubuntu hardy heron.


I found my problem - I was not properly connecting the j24 jumper (io15,gnd) between the master and slave, so the sync signal was not getting received properly.  I still get errors occasionally:
Error: counter not continuous.
 ucounter_begin[1]=200768 +1 != ucounter_begin[2]200828

I assume this is because the master and slave have falling out of sync? Are there any recommendations on how often the master/slave sync should get sent?  Also - if I were to add a third USRP, I assume I'd just have to chain the j24 jumper from either the master or slave - and change the enable_master_and_slave() function in usrp_multi.py to enable both slaves?

My next goal is to forward-port the multi_usrp code to the development trunk (e.g. using hier_block2, etc.), as my eventual goal is to include the in-band signaling code to get accurate time-stamps from the RF front-end.  I assume the current in-band .rbf files are not being built to support the multi-usrp code, correct?  I am starting to familiarize myself with the Quartus software and the organization of the usrp verilog code.
 Doug

--
Doug Geiger
address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]