Douglas Geiger wrote:
On Mon, Jul 21, 2008 at 9:46 AM, Douglas Geiger
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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:[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?
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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
