[Discuss-gnuradio] MIMO Trigger (was Re: USRP2 questions)

[Robey, Frank]

> Date: Fri, 14 Nov 2008 11:42:43 -0800
> From: Matt Ettus <address@hidden>
> Subject: Re: [Discuss-gnuradio] Re: USRP2 questions
>
> Matt Ettus wrote:
> I think the confusion here comes from the fact that there are multiple
> ways to get MIMO set up.
>
> There are 3 things necessary to get MIMO working.
> 1 - All systems need to be phase-locked to a common clock (10 MHz in
> this case)
> 2 - All systems need to have a common time reference (often a 1 PPS
> signal) so that they know which sample in one system corresponds to
> which sample in the other
> 3 - All the data needs to come from / go to the same place

 (etc.)


Matt,

I would like to suggest that what you have described is necessary but not 
sufficient for some (most?) MIMO or multi-channel applications and would like 
to describe the other pieces needed for a more complete solution.

For many applications differential phase shift and time delay between channels 
that is not observable without known external signals for calibration and that 
changes every time you reset or power cycle is unacceptable.  To ensure the 
phase shift and time delay are stable and repeatable the following additional 
steps are necessary.  These steps are ordered in increasing channel-to-channel 
precision.

A. Output buffers either need to be flushed to start filling when the trigger 
occurs, or the next sample after the trigger needs to be marked in some fashion 
so that it is identified in the data stream(s).

B. The state of the decimation counters for each USRP2 needs to be either reset 
or read when triggered.  An alternative is to count the number of 100MHz clocks 
before the next internal sample is output to the ethernet buffer.  Not 
compensating for this could lead to a large time delay variation betweeen 
channels depending on the decimation factor.  This is translated to a phase 
shift at the center frequency.  For example, we like to run narrow-band outputs 
with a sample rate of 50kHz.  This is a decimation of 2,000 relative to the 
100MHz clock.  With a 30MHz center frequency input each sample is 30/100, or 
3/10 of a cycle so a decimation difference of 2,000 clocks (20 microseconds) is 
as much as 600 cycles of the RF signals.

C. The phase of the internal numerical oscillator needs to be synchronized 
between USRP2 systems.  This would normally be through a common, synchronized 
reset, but could also be done by reading the phase register for the numerical 
oscillators when the trigger/1pps occurs.   This could lead to as much as a 360 
degree phase variation if not compensated.

D. The 1PPS/trigger input needs to be resynchronized internal to the USRP2 so 
that it is stable with respect to 100MHz clock edges. This implies meeting 
setup and hold times for the 100MHz clock edges.  Since the 100MHz clock edges 
are not observable (or are they?) external to the USRP2 the 1pps needs to be 
synchronized to the 10MHz reference clock and then internal to the USRP2 
resynchronized to the 100MHz such that it is stable with respect to the 10MHz.  
It needs to meet 100MHz setup and hold times internal to the FPGA.  This could 
lead to a channel-to-channel phase variation of 3/10 of a cycle at 30MHz, 
sufficient that beams created from the multiple channels are not formed 
properly with potentially significant loss in gain and high sidelobes.

A through C could be straightforward through a master synchronized reset or by 
including metadata with the data block.
D is not straightforward since it requires an analysis of the timing internal 
to the USRP2.  The ability to implement either item D or the master 
synchronized reset will not be clear until the schematic is published.  With a 
10MHz external clock input I expect the best we will be able to do for 
channel-to-channel coherence is to align triggers to the 10MHz clock edge for 
resolution of 100nsec.

Without these synchronizations the apparent phase or time delay will wander 
even for a single channel of normally synchronous data from one trigger to 
another.

When you are able to make the schematic available I would be happy to help 
develop the multi-channel synchronization approach.  My preference is your 
scenario 3 since it is the most scaleable.

Thanks,

Frank

robey@ll.mit.edu.vcf
Description: robey@ll.mit.edu.vcf