LabVIEW Errors Loading Bitfile for PPS Triggering Using Octoclock-G

[GenericAccount]

I am currently using mutliple USRP RIOs in a synchronized setup using an Octoclock-G.  I am currently working with the built-in PXIe USRP RIO 120 MHz BW Multi-Device Streaming template in LabVIEW Communications Suite. I am able to load the niusrpRio_Xcv bitfile for Time syncrhonization and run the Multi-Device Tx and Rx Streaming Time (Host).gvi with no issues.

However, if I am correct the Octoclock-G setup would require the PPS signal synchronization instead of the Time syncrhonization for proper syncing of multiple RIOS.  The issue that I am having is that loading the niUsrpRio_Xcvr_SyncPps bitfile for PPS signal syncing gives me a run time error.   I had attached a picture of the error with this message. I had checked my hardware setup and everything seems to be connected to the Octoclock-G properly.  My Primary Ref switch on my Octoclock-G is set to Internal.  I am trying to figure what would be causing this issue since I am using a project template built by NI and packaged with LabVIEW Comm. Suite.

[brooksprumo]

 All the of Multi-Device VIs that ship with LabVIEW Communications will synchronize multiple USRP RIOs to the nearest data clock cycle. The difference between the Time and the Sync versions are whether you're doing time-based or signal-based synchronization.

The different versions have different cabling requirements, and they have different pros and cons. Ultimately they produce the same level of synchronization. This quote is incorrect:

---

GenericAccount wrote:

However, if I am correct the Octoclock-G setup would require the PPS signal synchronization instead of the Time syncrhonization for proper syncing of multiple RIOS.

---

You must use the Time bitfile with the time-based synchronization. You must use the SyncPps bitfile when using signal-based synchronization via the (PPS) TRIG IN/OUT lines. You must use the SyncAux bitfile when using signal-based synchronization via the AUX IO lines.

If time-based synchronization solves your use case, I'd stick with that. If you need signal-based, you'll need to likely re-cable some things.

Let me know what other questions you have; I doubt this is enough to fully answer everything, but hopefully it's a start!

Thanks!

[GenericAccount]

Thanks for the information.  I have done some research regarding setting up the Octoclock-G for Time-Based configuration.  Attached is a picture("Octoclock-G_Time_Config.png") from an NI document showing a Time-Based wiring diagram.  My setup is currently wired with this configuration and I am able to load the niUsrpRio_Xcvr.lvbitx FPGA configuration using the built-in 120MHz BW Multi-Device Streaming example from LabVIEW Communications Suite with no run-time errors.  Also, all the cables connecting the Octoclock-G to the USRPs are the same length/type. So, this part seems to be working.

Unfortunately, we seem to have offsets of the phases of the signals that we are measuring during our Rx processes.  Our setup consists of three USRP's: RIO0, RIO1, and RIO2.  We are using RIO0 CH0 as a reference for relative phase measurement of the signals at the other channels.  What we are experiencing is phase differences between these channels.  To complicate matters further, the amount of phase difference changes each time we run our LabVIEW project.  So, there is no deterministic phase difference that we can simply compensate for in our code and have random phase differences.

Is this random phase difference a normal behavior when working with the Octoclock -G?  One thing that I was wondering is if I do not receive any run-time errors when running my program, then does this imply that the syncrhonization routines are working?

[Cooking_Up_Code]

Hi GenericAccount,

Even though you have cabled everything correctly, you need to make sure that you are still referencing the external clock in software. You can do this by configuring the Clocking and Synchronization » Reference Frequency Source as RefIn for an niUSRP property node. Adding this into each of your tasks for each RIO device will ensure that they are all using the Octoclock's source.

[GenericAccount]

Thanks for the tip, Paul.  The built-in PXIe USRP RIO 120 MHz BW Multi-Device Streaming template does have a Reference Frequency Source selection on the main VI panel.  I had decided to trace where this Reference Frequency Source variable is actually used and had found that the program flow is as follows:

1.User selects value for Reference Frequency Source from main VI panel

2. Reference Frequency Source is sent to function Open and Configure Devices

3. Open and Configure Devices calls Open Device using Reference Frequency Source as an argument

4.Open Device calls Open2 using Reference Frequency Source as an argument

5.Open2 calls Intialize Clocking using Reference Frequency Source as an argument

6.Intialize Clocking calls Configure Clocks using Reference Frequency Source as an argument

7.Configure Clocks calls Configure Clock Select using Reference Frequency Source as an argument

A Reference  Frequencty Source IF statement is executed within function Configure Clock Select. The corresponding value contained within Reference Frequency Source variable is checked and a corresponding reference clock  value is sent to memeber "data" of a cluster that is written to a register on the FPGA to program  the clock select.  I would say that this routine is how the reference frequency source is selected and written to the RIO device(we are using USRP-2943R models).  Wouldn't this be a proper programming of the reference frequency source for the device?

[brooksprumo]

---

@GenericAccount wrote:

if I do not receive any run-time errors when running my program, then does this imply that the syncrhonization routines are working?

---

Effectively yes. For time-based synchronization, there is a non-zero (but small) chance that two USRPs may not be synchronized. If the cables used to wire the USRPs are different lengths, it's possible that one USRP's PPS will identify a different edge of common reference clock. With length-matched cables, you should be good.

---

@GenericAccount wrote:

Unfortunately, we seem to have offsets of the phases of the signals that we are measuring during our Rx processes.  Our setup consists of three USRP's: RIO0, RIO1, and RIO2.  We are using RIO0 CH0 as a reference for relative phase measurement of the signals at the other channels.  What we are experiencing is phase differences between these channels.  To complicate matters further, the amount of phase difference changes each time we run our LabVIEW project.  So, there is no deterministic phase difference that we can simply compensate for in our code and have random phase differences.

---

Time-based synchronization only accounts for baseband synchronization. The LOs will have a different phase whenever they are retuned. That phase offset will be fixed, but you are right, there will be a random phase between USRPs whenever you retune your LOs.