discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Martin Dvh
Subject: Re: [Discuss-gnuradio] Re: Multiple USRP's debugging
Date: Fri, 08 Aug 2008 17:43:10 +0200
User-agent: Icedove 1.5.0.14pre (X11/20071018)

Douglas Geiger wrote:
> On Mon, Jul 21, 2008 at 9:46 AM, Douglas Geiger
> <address@hidden <mailto: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.
> 
>     <mailto:address@hidden>
> 
> 
> 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?
Most common source for this problem is a buffer overrun (a whole USB packet was 
missed)
You can try to minimize this by increasing the process priority of both the TX 
and the RX script.
lowering the datarate also should help.

> Are there any recommendations on how often the master/slave sync should
> get sent?
For low datarates a single sync should work for a long time.

To be sure, you could do it once a minute or something like that.

>  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?
If I recall well, this should work indeed.
> 
> 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.
With the new inband signaling timestamps you should not need the counter 
anymore which is used in the current multi_usrp code.
You should only need to sync the starttime (used for the timestamps)  once 
using the J24 cable.
Then the align block should be rewritten to align on timestamps in stead of 
samplenumbers.

With the new inband signaling it should also be feasabale to build a multi-usrp 
setup for sending signals (TX).
(I stopped working on this when work was started on the inband signaling)


Greetings,

Martin
>  Doug
> 
> -- 
> Doug Geiger
> address@hidden <mailto:address@hidden>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

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