problem in performing multiple synced acquisition with NI USRP

[gmrusso]

Hi,
I have two USRP N210 receivers with WBX board, an octoclock for synchronization and an Analog Devices board to send an RF calibration signal. The data communication between PC and USRP is performed through a Netgear Gigabit ethernet switch.
I want to make three series of measures on the two synchronized channels (ten acquisitions each), with an external signal at a given frequency and the other two at that frequency + or - 1 MHz.
The "single channel VI" allows me to change the frequency of the calibration signal coming from theAnalog Devices board between different input prompt, and the receiver keeps track of the frequency variation (in this case the "initiate VI" is inside the for loop).
The multiple channels VI ("Multiple sync while") does not allow me to place the "initiate VI" inside the loop (if i do this i get niUSRP initiate.vi<ERR> This attribute cannot be modified while the driver is in the Running state) and when I change the frequency of the calibration signal between two prompts the receivers do not read the frequency change, but instead they keep reading the previous one.

What do you propose? Maybe it's a queue problem?

Thanks.

[vvkakade]

Can you attach the code that you are trying to make work.Thanks.

[cochenob]

I like to look at the "Initiate" vi as the thing that finalizes configuration and kicks off data streaming.  If the 3 measurements you're making are consecutive/continuous in time...then you only need to call Initiate once (outside the loop) after you've set up all the timing...then call Fetch within your loop 3 times.  This will give you 3 "chunks" of data which are all contiguous in time.

If you want to take your 3 chunks of data at random times (say, when a user clicks a button)...then you'll have to configure everything like the "single shot" examples.  In this case, you'll have to configure the timing, Initiate, and Fetch, and then Stop, each time you want a chunk of data.

Basically, for synchronous measurements, the driver gets confused if you call Initiate more than once after you've set up the initial timing and triggering parameters.  Think of it this way...you initially set the system clock to 0, and then tell the USRP to start streaming at 1 second (in system time).  You initiate, the clock starts,  data starts streaming at the configured time, you fetch some samples, do some stuff, etc..  Now you go back and call Initiiate again.  The driver says to itself, "Ok I will start streaming at system time of 1 second"....but...the system clock is already way beyond that already.  Error!  So...you either have to go back and reset the system clock back to zero and the trigger to 1 second....OR....just Initiate once and call the Fetch VI multiple times in the loop to get contiguous chunks.

---

Brandon

[cochenob]

I guess I should add a few other details here...

Reconfiguring a property like retuning the center frequency requires a "reconfiguration", which is essentially what the Initiate VI does (at least that's the way I like to look at it).  The reason you see it work with only one channel (radio/device) is that since you're not making a sync'd measurement across different devices, you can reconfigure (i.e. - Initiate) as many times as you want since system time doesn't matter.

Once you try to do this with multiple sync'd channels...then you get to the situation I described above.  You set up all the initial timing parameters for synchronization...but are then asking the system to reconfigure over and over without resetting the system clock.  I'm guessing that the "re-tune" process isn't deterministic, which is why the driver can't both reconfigure the radio AND assure time sync.  You've got to go back and start from the beginning, so to speak.

From what I can tell...things like center frequency and IQ rate are properties that require the radio to "shut down" so that it can re-tune.  You'll need to re-call all the timing and sync blocks each time if you want to do multiple acquisitions with different configurations of these parameters.

However...I've been able to do things like switch antennas ports and change the gain WITHOUT having to "re-tune" and reconfigure.  I suppose this makes sense, as they're both "timing agnostic".  In other words...these properties don't require changes to the LO or the rate of samples coming from the FPGA, both which need to be controlled to assure time synchronization.

---

Brandon

[cochenob]

Sorry...one more thing!

It sounds like you're trying to calibrate the phase offset between two radios with a calibration tone.  Presumably, you've got some signal of interest that you want to measure coherently (hence the sync'd acquisition of multiple channels/devices), and you want to "flip over" to the calibration signal at different frequency to callibrate out the phase difference between the radios.  Is this right?

If so...this approach won't work because each time you retune the center frequencies, the phase difference between devices will be different.  So you're calibration will be worthless when you "swap back" to the other center frequency. 

There are some cute tricks to get around this, if this is indeed what you're trying to do.

[gmrusso]

Hi cochenob,

first of all, thanks for your precious tips!

By the way, we solved our problems by using a queue structure from the Data Fetch VI loop to the data processing loop and adding a flush queue data after every input prompt.