USRP Software Radio
PPS Trigger Syncing Issue
I have been working with some of the USRP Streaming examples from LabVIEW. My setup consists of USRP-2943R devices with an Octoclock-G. My issue is that I am able to get my PPS triggering circuit to work when interfacing with the USRPs through the driver and running completely from the host. However, I cannot get my PPS triggering circuit to work with the FPGA implementation of the streaming examples. This is for either half-duplex Rx or Tx, or for the full-duplex Rx and Tx.
I am familiar with the trigger settings on the front panel(future time event, immediate, etc.) and have tried all sorts of configurations. I have also made sure that I have selected PPS instead of AUX on the front panel. I just have the following error
My Octoclock-G circuit is wired in a star configuration with the PPS and REF out of the Octoclock-G to the PPS and REF in of the RIOs. This is strange because my synchronization setup works fine when programming with the basic host VIs, but yields errors with the streaming examples.
GenericAccount,
Take a look at my reply to a previous question about synchronization to make sure your USRPs are wired up properly for signal-based synchronization. Here's another reply about synchronization that discusses configuring the 6674T too. Those threads also contain additional useful posts, so I'd recommend reading through them in their entirety.
I found one of your previous threads that I replied to; was there any resolution to that issue?
For signal-based synchronization via the PPS TRIG lines, here's how you need to wire up your USRPs. Notice the Octoclock and the 6674T. Also notice that the master USRP TRIG OUT is going to the OctoClock (through the 6674T). Can you confirm you have your devices wired up properly? Make sure your OctoClock is set to External and the External LED is lit too. If not, your OctoClock will not distribute an input trigger.
Synchronization on the USRPs is difficult. I'm guessing I haven't answered all of your questions in this one post, but hopefully it's a start! Let me know how things go!
I actually had already studied the threads that you had posted. But, I do not think that it resolves my particular issue. The issue in my previous thread that you had mentioned was actually taken up by a service request with some Application Engineers at NI. While consulting with them it was found that we would not need the PXIe-6674T module as our Octoclock-G unit should be able to provide the triggering that is necessary without the buffering that would be required if a RIO was used as the trigger source. This can be referenced from the Octoclock-G datasheet. So, my timing circuit at this momment is as shown as below. It should be noted that the Primary Reference switch on the Octoclock-G is set to Internal.
Unfortunately, we still had issues during my service request. The Application Engineers had just recommended moving away from LabVIEW Communications Suite to regular LabVIEW and the issues we had were never really solved.
What is really killing me is that I can successfully apply the PPS triggering while interfacing through the USRP driver on the host VI, for example
and my program runs without any run-time sync errors.
Thanks for clarifying the operation. Just to put this into the perspective of a user who is just starting out with the equipment it can be confusing because below is a snippet from the Octoclock-G datasheet:
To the unitiated this gives the impression that the wiring simply consists of connecting the TRIG OUT from the Octoclock-G to the TRIG IN of the USRPs without the need of wiring the TRIG OUT from a Master USRP to a TRIG IN port of the Octoclock-G through a 6674T(or similar buffer). This can create a lot of confusion for any newbie to synchronizing USRPs.
However, from what I am understanding is that regardless of whether the unit is an Octoclock or Octoclock-G, signal-based synchronization requires the following wiring:
where I believe from this previous synchronization post one can simply replace the PXIe-6674T with a Schmitt Trigger so long as the circuit output voltage is at around the 5 Volt PPS spec. We do not have the PXIe-6674T module. So, the buffering circuit may have to be our solution.
@GenericAccount wrote:
Thanks for clarifying the operation. Just to put this into the perspective of a user who is just starting out with the equipment it can be confusing because below is a snippet from the Octoclock-G datasheet:
To the unitiated this gives the impression that the wiring simply consists of connecting the TRIG OUT from the Octoclock-G to the TRIG IN of the USRPs without the need of wiring the TRIG OUT from a Master USRP to a TRIG IN port of the Octoclock-G through a 6674T(or similar buffer). This can create a lot of confusion for any newbie to synchronizing USRPs.
Yes, I understand the confusion. Synchronization is hard because there are multiple definitions, and there are multiple schemes of synchronizing. This is further complicated by what is and is not available depending on (1) your HW and/or (2) your SW. That quote above is for time-based synchronization, not signal-based synchronization. In time-based synchronization you *do not* need to wire the PPS TRIG OUT from one USRP to the PPS TRIG IN of the OctoClock.
However, from what I am understanding is that regardless of whether the unit is an Octoclock or Octoclock-G, signal-based synchronization requires the following wiring:
Correct. For signal-based synchronization you do not need an OctoClock-G. However, if you do not use the OctoClock-G, you will need to provide the OctoClock-G with a 10 MHz reference clock, since it will not have an onboard oscillator itself. This 10 MHz reference clock *cannot* come from one of the USRPs being synchronized.
I believe from this previous synchronization post one can simply replace the PXIe-6674T with a Schmitt Trigger so long as the circuit output voltage is at around the 5 Volt PPS spec. We do not have the PXIe-6674T module. So, the buffering circuit may have to be our solution.
Yes, this should work although I haven't tested it myself.
