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.
Any help/tips would be appreciated,
Doug
On Mon, Jul 21, 2008 at 9:46 AM, Douglas G. <
[email protected]> wrote:
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.
[email protected]
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
Douglas G. wrote:
like to be able to synchronize the clock on both USRP's (I'm
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