Re: [Discuss-gnuradio] USRP synchronization

[ValentinG]

Hi Matt, hope you had a good trip. 

We've managed to work around the ambiguity using calibration, but we are
still interested in that other technique that you've mentioned earlier.

Also we have trouble understanding the meanings of the phase ambiguities we
are observing. We use a centre frequency of 2.45G which implies a 2-way
ambiguity, doesn't this mean that 2 boards should have a phase of 0 or 180
with respect to each other? But we don't observe this...

Kind regards,
Valentin





Matt Ettus wrote:
> 
> 
> I'll be away until the 22nd, but will give you an update on the possible 
> improved method when I get back.
> 
> Matt
> 
> 
> On 03/11/2010 12:28 PM, ValentinG wrote:
>>
>>> It depends where you are measuring.  The main 100 MHz clock should
>>> always come up with the same phase.
>>
>> Ok we've found the problem, we were measuring a 10MHz signal on the test
>> pins which is derived from 100MHz, therefore has a 10-way ambiguity,
>> hence
>> different phases after power cycling... Checked the actual clock and it's
>> fine.
>>
>>> Basically, divisions produce ambiguity, multiplications remove it.  To
>>> take an example -- assume you are using a 10 MHz reference and your
>>> final LO frequency is 2450 MHz.  The 10 MHz reference is multiplied up
>>> to 100 MHz, and will have no phase ambiguity.  The 100 MHz is sent to
>>> each daughterboard where it is divided by 16 to create the 6.25 MHz
>>> compare frequency.  This will have a 16-way ambiguity.  This is then
>>> multiplied up by 392 to get 2450.  16 is not a factor of 392, but 8 is.
>>>   So 16/8 = 2 and you get a 2-way ambiguity.
>>
>>> If, on the other hand, you choose 2456.25 MHz for your LO frequency, the
>>> multiplication factor is 393, which shares no common factors with 16,
>>> and so you have 16-way ambiguity.  By judiciously choosing your R
>>> divider and LO frequency, you can often get rid of the ambiguity.
>>
>> In the example above you use the factor of 16 at the very start, where
>> does
>> it come from? Is it the decimation rate we use or it can be arbitrary?
>>
>>> I actually just thought of another possible way to do this which might
>>> be even better, so let me think about that and I'll get back to you.
>>
>> Great!:)
>>
>> We have modified our c++ code to send all the configuration commands to
>> the
>> USRP2 boards (frequency, decimation, etc.) at the very start and pause.
>> Then
>> we perform 4 fetches of data, pausing after each one. 3 of those are then
>> used to get calibration data, which is then used to refine the results of
>> the 4th fetch. Is this a correct approach?
>>
>> We have also tried sending all the configuration commands using a
>> separate
>> c++ script and then using a different script to perform the fetches, but
>> that doesn't seem to work. Is that because every time the usrp2:make
>> command
>> is called it resets the configuration of the board?
>>
>> Regards,
>> Valentin
>>
>>
>>
>>
>>
>>
>>
>> Matt Ettus wrote:
>>>
>>> On 03/10/2010 06:39 AM, ValentinG wrote:
>>>>
>>>> Thanks a lot for the answers!
>>>>
>>>> Yes all of our boards are USRP2s.
>>>>
>>>> We do have a common PPS signal provided by the external signal
>>>> generator.
>>>> We
>>>> use code from the VRT branch and call set_time_at_next_pps for all 4
>>>> boards
>>>> to reset their times. Then we call start streaming for all 4 boards
>>>> some
>>>> seconds later. This as we understand ensures the alignment of the
>>>> samples
>>>> received.
>>>
>>> OK, then you just have the RF phase issues.
>>>
>>>>
>>>> We use RFX2400 daughterboards.
>>>>
>>>> There are a few other questions we wanted to ask:
>>>>
>>>> 1.) We observe a phase shift between MB clocks on different USRP2
>>>> MotherBoards which changes each time the USRP2 is reset. Is there a
>>>> finite
>>>> number of possibilities for that phase difference due to its PLL? How
>>>> many
>>>> are there?
>>>
>>> It depends where you are measuring.  The main 100 MHz clock should
>>> always come up with the same phase.
>>>
>>>> 2.) Does the PLL on the daughterboards uses the clock, generated on the
>>>> MBs
>>>> as a reference to lock the VCO signal used for downconversion? Or does
>>>> it
>>>> use the external 10MHz clock as the reference?
>>>
>>> It uses the clock from the motherboard, not the 10 MHz reference.
>>>
>>>> 3.) If there is a finite number for the phase differences (N) between
>>>> MB
>>>> clocks and these are used to produce the down-converter signal, which
>>>> can
>>>> also have a finite number of phase differences (M), this would imply
>>>> that
>>>> we
>>>> can have NxM different phases, correct?
>>>
>>> Basically, divisions produce ambiguity, multiplications remove it.  To
>>> take an example -- assume you are using a 10 MHz reference and your
>>> final LO frequency is 2450 MHz.  The 10 MHz reference is multiplied up
>>> to 100 MHz, and will have no phase ambiguity.  The 100 MHz is sent to
>>> each daughterboard where it is divided by 16 to create the 6.25 MHz
>>> compare frequency.  This will have a 16-way ambiguity.  This is then
>>> multiplied up by 392 to get 2450.  16 is not a factor of 392, but 8 is.
>>>    So 16/8 = 2 and you get a 2-way ambiguity.
>>>
>>> If, on the other hand, you choose 2456.25 MHz for your LO frequency, the
>>> multiplication factor is 393, which shares no common factors with 16,
>>> and so you have 16-way ambiguity.  By judiciously choosing your R
>>> divider and LO frequency, you can often get rid of the ambiguity.
>>>
>>> I actually just thought of another possible way to do this which might
>>> be even better, so let me think about that and I'll get back to you.
>>>
>>>>
>>>> 4.) Do the PLL's on the daugherboard tune every time a C++ or Python
>>>> program
>>>> is run or every time the board is powered on? i.e. for phased arrays
>>>> will
>>>> we
>>>> just need to calibrate every time the board is powered on or every time
>>>> we
>>>> take a given stream of data?
>>>
>>> Every time you send the tune command.  You should only send this when
>>> you need to change frequency, not every time you start streaming.
>>>
>>>> 5.) How can we change the number of possible phases for the
>>>> daughterboard?
>>>> 6.) Does reducing this number increase lock time?
>>>
>>> Not a lot.
>>>
>>>> 7.) How can we tune so there is no ambiguity in the phase of the boards
>>>> like
>>>> you suggested?
>>>
>>> Yes, you need to choose your factors carefully.
>>>
>>> Matt
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/USRP-synchronization-tp27838821p27990197.html
Sent from the GnuRadio mailing list archive at Nabble.com.