Push the high IQ sampling rate for multiple synchronised USRP 2943R with Network Ports configuration

[True_Boombo]

Dear All, I am current working with 4 USRP 2943R as 8-channels receiver.  

What I am trying to achieve with this system are:

1. 8 totally synchronized channel

2. As high as possible IQ sampling rate

My Hardware and configuration:

1. 4 USRP 2943Rs

2. I have OctClock as 10 MHz ref clock and PPS (10MHz from 6674t, PPS from first USRP, via 6674t)

3. CPU is: Intel Xeon E5 2630 2.3GHz, I have 2 CPUs in this PC, each CPU has 6 cores and 12 threads

5. 32GB RAM

4. Network card: I installed 2 Intel 82574L network cards, each card has 2 82574L chipsets and 2 ports, thus, I can connect 4 USRP 2943Rs.

My Driver, system, Labview version:

1. USRP 15.0
2. Win 7 64bits
3. Labview 2015 64bits

My test: 

1. niUSRP EX Rx Multiple Synchronized Inputs (PPS Trig): I extend this example to 4 USRPs with 8 channel configured. In order to unnecessary processing delay, I removed all the display code in the example, just display the timestamp to know the VI is running or not. With this configuration I can run the VI in 5M IQ sampling rate. 
2. I also test another configuration from NI 8X8 MIMO white paper (http://www.ni.com/white-paper/14311/en/😞 for this example, I can run the VI also in 5M IQ rate. (I like PPS trigger configuration though)
3. I found there two example VIs called "niUSRP EX Spectral Monitoring (History)", "niUSRP EX Spectral Monitoring (Interactive)". These two VIs are very interesting, as I found that they put the "niUSRP Initiate.vi" in side of the data fetch while loop. So, I make some extension based on "niUSRP EX Spectral Monitoring (History)", I built 4 independent configuration and data fetch chains in one VI and I can run all 4 devices (8 channels) in even 60MHz IQ rate in real time. But the problem is that I cannot make the 8 channel synchronized under this configuration.    

Some further test:

I tried to mix the "niUSRP EX Rx Multiple Synchronized Inputs (PPS Trig)" configuration and "niUSRP EX Spectral Monitoring (History)" together by put the "niUSRP Initiate.vi" inside of the data fetch loop in "niUSRP EX Rx Multiple Synchronized Inputs (PPS Trig)" example, I found that Labview will always report following error. 

Now, the situation is for high IQ rate and synchronization seems like I can only take one of the fruits, but I need both of the features work in my system. 

If someone have experience on configuring such a system, it will be great to share experience and knowledge here. 

BTW, I already tried some method mentioned in related discussion as described in following link:

http://forums.ni.com/t5/USRP-Software-Radio/Increase-the-IQ-Rate-of-USRP-NI-USRP-1-1-Driver/td-p/225...

Actually, some methods help in some extent, but not essentially resolve the problem. 

Thanks a lot!

Bo

[muffin.vi]

Hi True_Boombo,

I'm not entirely sure what is going on here, but there appears to be a few things that could be wrong.

1. You need all four USRP RIOs to reference external 10 MHz (Reference Frequency Source) and PPS (Timebase Clock Source) signals. These are the signals from the OctoClock. As long as this is done for every USRP RIO, they will be phase coherent. It should look close to this:

If the reference frequency and timebase clock source are set to "Internal" they will not look at the external clock input. This is probably why you are seeing issues with synchronization. If you are planning on using the PPS signal from one USRP RIO, you will also need to export that PPS signal to the 6674T. 

The reason why the "niUSRP EX Spectral Monitoring (Interactive)" example is able to include the "niUSRP Initiate" vi inside the loop is because the USRP session is closed before the initiate VI is run. The reason you are seeing that error is because you are trying to open a USRP session that is already open. The Spectral Monitoring example gets around that by closing the sesion after the user hits "stops" or "Reconfigure" 

[True_Boombo]

Hi Muffin,

Thanks for your reply. 

My clock configuration is like this: (I think it should be right)

Also, I think is better to discuss by using "niUSRP EX Spectral Monitoring (History)". For this example code, you can see that the session is not stopped (as I showed in the red rectangular).

 

The abort is outside of the while loop.

Cheers,

Bo

[True_Boombo]

Actually, the example "niUSRP EX Spectral Monitoring (Interactive)" did the same (see the initiate and abort in red rectangular), initiate is in side of data fetch loop and abort is out side

[muffin.vi]

Ah, okay. I see what you mean now.

Can you send a picture of what your code looks like? Are there two initiate VIs in a row? I believe the reason those examples have a niUSRP initiate VI in the loop is because the data has already been fetched once. 

[True_Boombo]

Hi Muffin,

I actually attached the VI codes here. There are 3 VIs. The first one is the "niUSRP EX Spectral Monitoring (history)" as reference. I made some modification on this example, like carrier frequency, and IQ rate. For this code I can run it up to 60MHz IQ sampling rate.

Then, I attached "niUSRP EX Synchronize Clocks Multi-Device (PPS)" and "niUSRP EX Rx Multiple Synchronized Inputs (PPS Trig)" (this one is just required in order to run "niUSRP EX Synchronize Clocks Multi-Device (PPS)")

I also made some modification on ""niUSRP EX Synchronize Clocks Multi-Device (PPS)"", but the overall structure is still there. The main modification is that I added "niUSRP iniaite.vi" is side of the while data fetch loop. The reason for me to do this is trying to mimic the "niUSRP EX Spectral Monitoring (history)" for high IQ sampling rate.

Actually, the attached  "niUSRP EX Synchronize Clocks Multi-Device (PPS)" will not work as it will report the error I posted in very beginning.

I hope my explanation make sense. I will be online to explain is you have any question about the code. 

Cheers,

Bo

[muffin.vi]

Hi True_Boombo,

I have a couple of clarification questions:

1. In the first example: "niUSRP EX Spectral Monitoring (HIstory) _ modified" what is wrong with this example? Is synchronization the problem, or are you getting the error here?

2. In the second example:  "niUSRP EX Synchronize Clocks Multi-Device (PPS)_Modified" what did you change about this example? I don't see any "niUSRP initiate" VI in this one.

3. In the third example: "niUSRP EX Rx Multiple Synchronized Inputs (PPS Trig)" why did you add an extra data fetch? (circled in red below) and what happens if you add a "niUSRP initiate" where I circled in blue?

[True_Boombo]

HI Muffin,

The first example I attached is alright. I use this one as reference. The problem for this example it only configured one device. What I need in the end should be 4 synchronized devices. 

The 2nd the 3rd Vis. I made some mistake on names. I did not make any change on "niUSRP EX Synchronize Clocks Multi-Device (PPS)_Modified" 

For the 3rd VI, Please refer to the new attachment. The reason I add an extra fetch out side the loop is try to totally mimic what has been done in "niUSRP EX spectrum Monnitoring (history)". They called it "Acquire initial frame to prime pipeline".

Cheers, 

Bo

[True_Boombo]

Response to what happens if you add a "niUSRP initiate" where I circled in blue?

It will report an error:

[muffin.vi]

True_Boombo,

What happens if you remove the fetch circled in red? I'm not entirely sure why you are getting that error but the driver is being confused by the additional fetches/initiates. There is not a specific need to have the extra fetch.

Otherwise, I think we're getting in the weeds here. If the goal is to have four USRP RIOs synchronized, it will look more like the usrp_rx_continuous-8_channel.vi VI used in the 8x8 MIMO white paper. Except, instead of using the MIMO cable, every Ref frequency and Timebase clock will be set to "RefIn" and "PPSIn" respectively. 

The real tricky part here is to export the PPS from one USRP, feed it through the Octoclock, and then use the resulting PPS signal as the input. There is not an example for doing that, but once that code is implemented, the 8x8 MIMO example should be very close to what you are looking for.