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.
phase differences. Why?
The purpose is to apply and record a calibrating signal which is
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.
Consider a different approach. I’m assuming that you are using a
“select” here so that you can watch
for correct phasing on the 'scope display before you start recording.
Perhaps instead, record
all the time, and insert zeros into the data stream while you’re in
the “mucking about” state, and
when you’re happy, you record the actual data. Just insert a
multiplier into the stream in front
of the file-sinks, and have the multiplier be either ‘1’ or ‘0’
depending on what state you’re in.
There are probably thinks with stream tags you could do as well, but I’m
not that familiar with them.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
providing a calibrating signal to ascertain the fixed channel-channel
channel-channel and hence the system cannot be calibrated.
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.
Thanks Marcus. So, it is the “select” block that is causing UHD device
to reset every time.
The reason I am using “Select” block is to avoid large file sizes, as
the interested signals can occur any time for short periods of time. So,
I have to run the program all the time, record a calibrating signal and
then wait for experiment data to occur and record this to file sinks.
Continuous recording can fill the hard disk very quickly; 1MS/s for
eight channels, something like 32MB/s or 2GB/min.
Any ideas on how can I record IQ data for discrete non-continuous
intervals of time without causing the system to re-tune.
Thanks,
Khalid.
Marcus D. Leech wrote in post #1030432:
On 06/11/11 06:11 AM, Khalid J. wrote:
phase differences. Why?
The purpose is to apply and record a calibrating signal which is
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.
Consider a different approach. I’m assuming that you are using a
“select” here so that you can watch
for correct phasing on the 'scope display before you start recording.
Perhaps instead, record
all the time, and insert zeros into the data stream while you’re in
the “mucking about” state, and
when you’re happy, you record the actual data. Just insert a
multiplier into the stream in front
of the file-sinks, and have the multiplier be either ‘1’ or ‘0’
depending on what state you’re in.
There are probably thinks with stream tags you could do as well, but I’m
not that familiar with them.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
Thanks Marcus. So, it is the “select” block that is causing UHD device
to reset every time.
The reason I am using “Select” block is to avoid large file sizes, as
the interested signals can occur any time for short periods of time. So,
I have to run the program all the time, record a calibrating signal and
then wait for experiment data to occur and record this to file sinks.
Continuous recording can fill the hard disk very quickly; 1MS/s for
eight channels, something like 32MB/s or 2GB/min.
Any ideas on how can I record IQ data for discrete non-continuous
intervals of time without causing the system to re-tune.
Thanks,
Khalid.
Marcus D. Leech wrote in post #1030432:> On 06/11/11 06:11 AM, Khalid
Jamil wrote:>> phase differences. Why?>> The purpose is to apply and
record a calibrating signal which is>>>>>>>>> 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.>> Consider a different approach. I’m
assuming that you are using a> “select” here so that you can watch>
for correct phasing on the 'scope display before you start recording.>
Perhaps instead, record> all the time, and insert zeros into the
data stream while you’re in> the “mucking about” state, and> when
you’re happy, you record the actual data. Just insert a> multiplier
into the stream in front> of the file-sinks, and have the multiplier
be either ‘1’ or ‘0’> depending on what state you’re in.>> There are
probably thinks with stream tags you could do as well, but I’m> not
that familiar with them.>>> → Principal Investigator> Shirleys Bay
Radio Astronomy Consortium> http://www.sbrac.org
Any ideas on how can I record IQ data for discrete non-continuous
intervals of time without causing the system to re-tune.
Thanks,
Khalid.
Actually, this is entirely independant of UHD and the devices it
connects to. The selector() must necessarily disconnect then reconnect,
and
this must necessarily create a phase hit. Near as I can tell, the
selector object (which is a synthetic object defined in GRC, but not, as
far
as I can tell, available anywhere else in Gnu Radio) will case a
phase-hit regardless of what the source is.
If this were my problem to solve, I might use the “record” button to
drive an adder which when you’re not recording, adds some large
out-of-range value to the output data, otherwise the data is in
{-1.0,1.0}. Then I’d dump my data over a FIFO, and use a C/C++ program
to do “data slicing” on the resulting data, then use the data
magnitude to decide if it’s “real” or not. That is but one approach.
You could dump your “record” variable to an external file, and have your
recording program look for the value of that variable, and start
recording when it sees the variable set to True (or 1, or oranges, or
kobe-beef, or battleships, or whatever).
Another way is to simply have your file-sink write to “/dev/null” until
it’s time to write real data. The filename can be changed dynamically
and it “just works”.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Any ideas on how can I record IQ data for discrete non-continuous
intervals of time without causing the system to re-tune.
I am surprised that no one has mentioned it. But have you tried stopping
the flow graph between reconfiguring the selection mux? You can even
control this in GRC using the run parameter in the options block.
-josh
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.