Re: [Discuss-gnuradio] 4x4 MIMO with USRP

[Martin]

Ketan Mandke wrote:
> Martin,
>
> Thanks for your response. It is disappointing to hear that the MIMO
> support for 4 antennas will not be available for some time.
>
> Could you provide some more details into why this problem of aligning
> the transmit samples will be easier in the new m-block framework? Will
> these new packet oriented m-blocks utilize a different interface to
> the USRP which will make this alignment-task easier?
Sorry for the late response. I get so much mail, that I miss a mail once 
in a while.
With the m-block interface you can specify in a packet when the samples 
should be sent.
As long as the time reference in the USRPs are synced this means that 
all samples will be synchronised.
In the old framework there is no sense of absolute or relative time.
This means you have to build from scratch a system which can hold-off 
samples untill the time comes for them to be sent out.

In essence this IS what the m-blocks will do. So why invent the wheel twice?

Greetings,
Martin


> On 8/29/07, Martin Dvh <address@hidden> wrote:
> > Ketan Mandke wrote:
> > > Martin,
> > >
> > > I've been searching through the mailing list for more information
> > > about synchronizing two USRP boards to create the transmitter for a
> > > 4x4 MIMO node. From what I've found, it seems that this is not
> > > currently implemented (see links below for relevant threads). What is
> > > the current status of this effort,
> > Yes you do need special measures to make sure the samples are aligned.
> > I am the author of the usrp_multi code (and the modified usrp firmware)
> > I was working on the transmit site but with the current framework this got 
> > quite complicated.
> >
> > The m-blocks framework which is currently in development will make it much 
> > easier to synchronize multiple receive or multiple transmit streams
> > on seperate USRPs.
> > So this work has been on hold waiting for the m-blocks become available and 
> > usuable in the main tree.
> > > and when (if at all) do you think
> > > that this functionality might be implemented?
> > Since the m-blocks are maturing now, in theory the work on this could be 
> > started soon.
> > The problem is that I am very busy doing contract work on another part of 
> > GnuRadio.
> > So at the moment I don't have time for this.
> > After this project it also depends on the amount of work I have, how much time 
> > will be left for implementing 4x4MIMO.
> > So at the soonest in the next few months.
> > At the latest, in a year or two.
> >
> > It also depends on how many others will be working on this code. Until now I 
> > have been the only one implementing the low-level MIMO stuff.
> >
> > If you have a budget for it. Matt, Eric and I could probably team up and 
> > implement it more quickly.
> > If you don't have a budget you could try to help out by doing the dirty work 
> > yourself.
> > We can help you on your way in this.
> >
> > > links:
> > > http://www.nabble.com/Question-about-4-x-4-MIMO-transmitting-and-receiving-tf3605863.html#a10074272
> > > http://www.nabble.com/Re%3A-USRP-Tx-Question-tf1452214.html#a3924517
> >
> > One other thing is the phase relationship between the different USRPs.
> > At the moment we use the upconverters (DUCs) of the ADC/DAC chips.
> > Unfortunately the starting phase of these can not be set.
> > Only after power-up these are in a known state.
> > After you have used the usrp these are in an unknown state.
> > This means that every time you start a gnuradio script the phase relationship 
> > between the multiple USRPs will have a fixed unknown phase difference.
> >
> > Depending on your application this can be a problem.
> >
> > The only solution is not to use the DUCs in the DAC but do the upconversion in 
> > the FPGA.
> > This can be developed but you would probably also have to disable some other 
> > functionality because the FPGA is already very full.
> > (disable the RX halfbandfilters, or reduce the number of RX channels)
> >
> > I hope this clears it up for you.
> >
> > Greetings,
> > Martin DvH
> >
> >
> >
> >
> > Olifantasia
> > Software Defined Radio, GnuRadio, USRP development