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.
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).
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
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?
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.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
