Loss of synchronization while creating new file

Loss of synchronization while creating new file

This post was updated on .

Hi Everyone,

I am having some issues with figuring out the cause of a loss of
synchronization using the USRP N210. I will be using the USRP as a
receiver for a radar system, but I am still in the calibration phase.
For calibration testing, I am interested in seeing the stability of the
baseband IQ data when applying a known pulsed RF signal with RF
frequency
matched to the frequency of the DDC. The data collection program
developed through GNURadio libraries is to continuously run while
creating a new file after a specified amount of time, to avoid having
one massive file. Typically each file is set to 5 minutes, but for this
issue the number has been altered several times. The baseband IQ data
from a single inter pulse period is plotted every 5 seconds. To
synchronize the pulsed RF with the USRP, we are using an external 10 MHz
clock in addition to a PPS signal.

During testing, at first everything seemed to be working as it should,
because the baseband IQ plots were the same every 5 seconds a new plot
was displayed. The problem occurred after the completion of a file,
and the start of a new file. The start of the new file caused the IQ
values to change, and these values remained until completion of the
file, where the problem will continue to the next file. I have tried
many different tests to understand this problem, but I have run out of
ideas. I was wondering, is something on the NCO is not being reset
during the closing and opening of a new file. Or, is there always going
to be some loss of synchronization during this change? For a
visualization of the problem I have attached a couple pictures of the
phase for subsequent files. If anyone has any suggestions to solve this
problem it would be greatly appreciated. Also if there is any other
information you need, please let me know.

Re: Loss of synchronization while creating new file

On 07/16/2013 04:31 PM, rmsrms1987 wrote:

>
> Hi Everyone,
>
> I am having some issues with figuring out the cause of a loss of
> synchronization using the USRP N210. I will be using the USRP as a
> receiver for a radar system, but I am still in the calibration phase.
> For calibration testing, I am interested in seeing the stability of the
> baseband IQ data when applying a known pulsed RF signal with RF
> frequency
> matched to the frequency of the DDC. The data collection program
> developed through GNURadio libraries is to continuously run while
> creating a new file after a specified amount of time, to avoid having
> one massive file. Typically each file is set to 5 minutes, but for this
> issue the number has been altered several times. The baseband IQ data
> from a single inter pulse period is plotted every 5 seconds. To
> synchronize the pulsed RF with the USRP, we are using an external 10 MHz
> clock in addition to a PPS signal.
>
> During testing, at first everything seemed to be working as it should,
> because the baseband IQ plots were the same every 5 seconds a new plot
> was displayed. The problem occurred after the completion of a file,
> and the start of a new file. The start of the new file caused the IQ
> values to change, and these values remained until completion of the
> file, where the problem will continue to the next file. I have tried
> many different tests to understand this problem, but I have run out of
> ideas. I was wondering, is something on the NCO is not being reset
> during the closing and opening of a new file. Or, is there always going
> to be some loss of synchronization during this change? For a
> visualization of the problem I have attached a couple pictures of the
> phase for subsequent files. If anyone has any suggestions to solve this
> problem it would be greatly appreciated. Also if there is any other
> information you need, please let me know.
>
> Thank you very much,
> Robert
>
> <http://gnuradio.4.n7.nabble.com/file/n42517/file1.jpg>
> <http://gnuradio.4.n7.nabble.com/file/n42517/file2.jpg>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/Loss-of-synchronization-while-creating-new-file-tp42517.html> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>

You haven't described your flow-graph, nor how you "flip to a new file".

The USRP has *zero* idea about what you're doing with the samples once
they leave the USRP. It doesn't care. So any anomalies with things like
file recording are utterly independent of the USRP (modulo any
overruns that might be caused by your flow-graph, in which case, you'll see
phase-hits).

Re: Loss of synchronization while creating new file

Hi Marcus,

Thank you for the prompt reply. I have attached the two python programs that have been written to do this type of acquisition. From Snafoo.py the only section of importance is the Rupdate. Before any file is written, the program checks the hard drive to make sure there is enough space to complete the file. If there is enough space, then the program initiates the data collection program (rx.py). The inputs to this class include the directory to save to (self.indir), FIR filter coefficients (self.fr), and the file size in seconds (self.fs). Then the method 'run' is executed, which is a function from the gr.top_block class.
After writing this, it seems like the problem can potentially be the commands that are executed between files. These command will take a brief amount of time, but enough to cause a slight phase difference between files. Do you think this may be the cause as well? If so, do you possibly have a solution?

Re: Loss of synchronization while creating new file

On 07/16/2013 06:34 PM, rmsrms1987 wrote:

> Hi Marcus,
>
> Thank you for the prompt reply. I have attached the two python programs
> that have been written to do this type of acquisition. From Snafoo.py the
> only section of importance is the Rupdate. Before any file is written, the
> program checks the hard drive to make sure there is enough space to complete
> the file. If there is enough space, then the program initiates the data
> collection program (rx.py). The inputs to this class include the directory
> to save to (self.indir), FIR filter coefficients (self.fr), and the file
> size in seconds (self.fs). Then the method 'run' is executed, which is a
> function from the gr.top_block class.
> After writing this, it seems like the problem can potentially be the
> commands that are executed between files. These command will take a brief
> amount of time, but enough to cause a slight phase difference between files.
> Do you think this may be the cause as well? If so, do you possibly have a
> solution?
>
> Thanks,
> Robert
>

You're basically doing a complete "session reset" between each
file--there's no way you can maintain phase coherence across that
"singularity".

A *MUCH* better approach is to use GRC, with a file sink, perhaps to a
FIFO, and then an external program that cuts your stream up
into individual files.