Ask a question about loop triggering

[Antaur]

I want to do a project, the requirement is that the transmit channel transmits a single tone pulse with a duration of 1ms every 1 second

To clarify, my USRP has a built-in GPSDO module

I studied the Demos given by the LabView USRP package, and found examples about single trigger, no example about loop trigger

There are a few questions, I would like to ask the experts to confirm

1. Is it impossible to achieve interrupt triggering based on physical signals (such as PPS) for the Labview Host mode (without customizing the FPGA)?
    Is the PPS IN interface on the USRP only for synchronizing the timebase?

2. Further, I think that the mechanism of LabView+Host+USRP timing trigger is that the internal timebase of USRP counts to a certain set value (timestamp), and then the hardware starts to capture or send samples. I don't know if my understanding is correct?

3. If my understanding of the second question is correct, then to achieve loop triggering, the specific operation process should be: In the loop structure, after sending a waveform with a limited number of samples each time, I need to repeatedly configure the "Start Trigger Time" property to set the next trigger time?

4. If my above understanding is correct, is the execution process of "niUSRP Write Tx Data.vi" blocked?
     In other words, after I call this VI, the whole process stops there until the timebase in USRP reaches the timestamp set by the "Start Trigger Time" property, then the hardware of USRP starts sending waveform samples,The "niUSRP Write Tx Data.vi" does not return until the sending is completed, and the process continues to move forward.I don't know if my understanding is correct?

[mikiofuku]

Hi
You can send a zero data.
You can send a single tone pulse data for 1ms, and send zero data for 999ms, and repeat this.
The simple solution.

[Antaur]

thanks for your suggestion.

The project I want to do is channel measurement, the receiver has the same problem. For simplicity, I only describe the transmitter.

If taking your suggestion, I'm worried about the following two issues:

1. Synchronization error accumulated across Tx and Rx

2. The data sampled by the receiver contains a lot of useless samples

So, I still want to understand the synchronization principle of USRP.

[TravelLight · Accepted solution]

You may put a niUSRP property node inside your loop with your niUSRP Write Tx Data.vi. Trigger time type is Time with value of 1, it will run based on onboard device timer, so make sure you have properly assigned GPS time to onboard timer outside and before your Tx loop.

[Antaur]

TravelLight，Thank you for your help. 

Now I can send and receive a short pulse per second. But I found a new question that is about GPS syncing different devices.

The project I am doing now is channel measurement, so the transmitter and receiver are placed in different places far away. I use GPSDO to realize synchronization.

As you suggested, I used "niUSRP Sync Clk PPS multi.vi" provided by NI to synchronize the onboard clocks in both USRPs.

After the clock is synchronized, I transmit and receive when I set fractional seconds=0, and I found that I did not receive a pulse signal. When I manually adjust the fractional seconds parameter of the receiver to not be zero, the pulse signal can be sampled. But this manually adjusted parameter is not fixed for each experiment. Is it possible to use the GPSDO module to synchronize the onboard timebase of different USRP devices?

 

In addition, when I captured the transmitted pulse, the parameters of the transmitter and receiver were kept fixed, and I found that the signal at the receiver was drifting.
Is there still a noticeable frequency offset with GPS-Disciplined Clock? 

 

[TravelLight]

(1) You may use niUSRP Set Time VI to sync onboard device timer with GPS time

(2) Resort to GPSDO, because it will improve local oscillator's accuracy, with GPSDO, the freq. offset between two USRPs will only be a few Hz.

(3) It's suggested not to trigger a Rx/Tx at the very beginning of one iteration, better to add a few hundred ms delay in each iteration