discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Multi-N210 synchronization issue


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Multi-N210 synchronization issue
Date: Sun, 06 Nov 2011 07:37:22 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1


On 11/06/2011 07:27 AM, Marcus D. Leech wrote:
> On 06/11/11 06:11 AM, Khalid Jamil wrote:
>> Hi,
>>
>> I am facing a strange problem in synchronizing and recording data from
>> multiple (4 or 8)  N210s. 
>>
>> The problem: 
>> After each data writing to the files on disk, it seems that each N210
>> re-tunes/ re-locks to the frequency references. It changes the fixed
>> phase offset from channel to channel. It kills the purpose of
>> providing a calibrating signal to ascertain the fixed channel-channel
>> phase differences. Why?
>>
>> Setup: 
>> Eight N210+WBX devices are synchronized with external 10MHz and 1PPS
>> signal. The data is routed from all channels through a gigabit switch
>> to computer where GRC gnuradio-companion is being used on Ubuntu. Here
>> a multi-usrp block is created, each channel tuned to the same
>> frequency (900 MHz) with same sampling rate (1 MS/s).  USRP source is
>> connected to either a scope or file sink. The type of sink is chosen
>> in runtime using a switch block in GRC. 
>>
>> The purpose is to apply and record a calibrating signal which is
>> essentially a tone at the carrier frequency to find out the fixed
>> phase offsets from channel to channel. This is used to apply the
>> correction phase errors later to the actual signals of interest.
>>
>> The problem occurs when I apply a calibrating signal and push the
>> button to switch from scope sink to file sink for a couple of seconds.
>> After I switch it back to scope, the channels have now a different
>> phase offsets than before. It seems that channels have re-tuned and
>> re-locked. So, this way, I am unable to know the phase offsets from
>> channel-channel and hence the system cannot be calibrated. 
>>
>> The attached file shows a four channel setup. I have a similar eight
>> channel one.
>>
>> Any suggestions on why it is happening (re-tuning after file write)
>> and how to calibrate the multi-channel system.
>>
>> Thanks,
>>
>> Khalid.
>>
>>
>>
>>
> My recollection of the way the "Select" block works is that it causes
> flow-graph hierarchy reconfiguration.
>   Which requires that the graph be *stopped* and *restarted* every time
> you switch.  This would cause
>   phase-hits in the recorded data, and I think it may also cause the UHD
> sources to shutdown and
>   re-instantiated.
> 


The start() method of the UHD source block should be requesting aligned
data. I believe that starting and stopping should keep everything
aligned. However, the select block only locks/unlocks. Im not sure if
this is equivalent to a stop/start event.

But you cannot trust the scope sink with aligned data. There is actually
a bug in the scope sink that even I have been bitten by. Multiple
channels can be "randomly" aligned. I believe this is due to the gr.copy
block inside the scope which is used to turn things off when not in
display. I believe that once would see this even if you replaced the UHD
source with a signal source + throttle.

-josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]