USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

100 msec Loop Delay Between NI-USRP Streaming Tx Signals

I am using LabVIEW's NI-USRP Simple Streaming examples for interfacing with the FPGA on the USRP .  I have been noticing that the Tx signal from these examples is being generated in pulses that are spaced 100miliseconds apart.  This is strange because the Tx Continuous Async Host VIs are able to generate a nice continuous signal with no interruptions.

 

I have checked the code on the host and it seems like the start trigger is only being set on the first loop interration.  I do not think that the start trigger is being reset at each loop count(at least on the host VI's). 

 

Has this issue ever been noticed?  Is this a delay caused by writing from the host to the FPGA? I am wondering if this delay between writing to the Tx is caused by the FPGA code or something that can easily be resolved on the Host VI's. It seems strange that the Tx Continuous Async Host VI is able to generate a nice signal, whereas the streaming example that uses the FPGA for better performance has a choppy output.

 

0 Kudos
Message 1 of 10
(5,376 Views)

Hi,

 

I believe that you need to use a reference trigger. Can you ensure that you are utilizing a reference trigger? Thanks!

Kevin S
Applications Engineer
National Instruments
0 Kudos
Message 2 of 10
(5,341 Views)

@kevins33 wrote:

Hi,

 

I believe that you need to use a reference trigger. Can you ensure that you are utilizing a reference trigger? Thanks!


The USRP Simple Streaming sample project doesn't use reference triggers, only start triggers.

 

GenericAccount,

I'm assuming you're using the USRP Simple Streaming sample project. If not, please let me know. Can you confirm that you have Generation Mode set to Continuous? Refer to the image below with the red circle.

 

Simple Tx Streaming Host

 

 

0 Kudos
Message 3 of 10
(5,336 Views)

Thanks for responding to my call for help, guys.  I am using the USRP Simple Streaming sample project that uses time-based synchronization(I wanted to use the PPS trigger, but having issues with that at the momment). 

 

At first I was running my code with just two USRP-2943R devices.  I had noticed that the multi-device Tx VI from the Streaming works by sending in an array containing a session for each Rio to the Tx write sub-VI.  This seemed like it could be a bottleneck.  So, what I did was to first take out each session from the array and call a separate Tx write operation for each operation in my main loop for a parallel process.  This seemed to work out and even extended to three USRP devices with good results(At first).  Below is a screenshot of the setup that I am talking about.TxVIDiagram.JPG

However, for three devices this only works for a sampling rate of 10MHz.  I had increased the rate up to 50MHz and the problem had reappeared. Initially there is some signal leakage before the signal is transmitted

Leakage(2USRP).JPG

 

followed by the actual Tx generated message.

 

BadMsgAfter(3USRP).JPG

 

Shown below is a close up of the signal that I am measuring from the transmitting RIOs.  Note it appears as a pulsed sinusoid.

 

3USRPat20MHzTxSamplingRate.jpg

 

So, in summary I am using continuous generation but it seems like there may be a bottleneck that is causing my message to be sent in pulses as the sampling rate or number of devices increases.  The goal of this project is to work near 100MHz sampling rate. This makes it quite an issue here.

 

Would it seem like this is being caused by the time triggering method, or a delay caused by writing to the FPGAs from the host?  I am trying to narrow down any tweaking some host VI code, or if I will have to resort to creating my Tx signal on the FPGA(which I am not sure whether this is practicable or recommended).

 

 

0 Kudos
Message 4 of 10
(5,319 Views)

Can you confirm:

  1. Front Panel Generation Mode is set to Continuous? (See circled area below)
  2. Front Panel Start Trigger is set to Future Time Event? (See boxed area below)

multi device time panel

 

If the Generation Mode is set to Finite, then the 'retrigger delay' on the diagram controlls when triggering happens. By default, that value is 100 ms. Since you're see 100 ms pulses, I'm guessing you're using Finite generation. See the boxed area below.

multi device time diagram

 

It's also possibe that your modifications have resulted in incorrect application of settings. I DO NOT recommend your approach of splitting the 'Initiate and Generate' VI. The 'Initiate and Generate (Multi)' VI is tested for this specific use-case; I do not guarantee that splitting the sessions and duplicating the VIs will work (I'd actually expect it not to work).

 

How are your devices wired? For Time-based synchronization, it should look like this:

time sync cabling

Make sure the OctoClock is set to Internal! Can you confirm your wiring is identical to this?

 

 

Lastly, you mention a goal of sampling at 100 MHz. The Tx processing on the FPGA will always transmit at the full device bandwidth (120 MHz of BW when using the 200 MS/s bitfiles). The sample rate will only affect the bandwidth of the signal you generate on the host, not what the FPGA transmits. 

 

As I said in your other thread, synchronization is hard. This likely does not answer all your questions, but hopefully it helps. Let me know!

0 Kudos
Message 5 of 10
(5,311 Views)

Below is a screenshot of my front panel setup.  My signal generation was set to Continuous and my Start Trigger to Future Time Event.

 

MultiTxSetup.JPG

 

I think that I may have left out some information.  Initially, I was running my code without any modifications made to the Multi-Device Tx Streaming Time (Host) VI.  It was then when I had experiencing issues with my generated Tx message while running two USRPs at 10MHz.

 

I then made the modifications of extracting each session from the session array and forwarding these individual sessions to their own Initiate and Generate Time(Single) VI.  The idea was for better efficiency through a parallel process.  After doing this, the issue went away.  I then had tested it with three USRPs at 10MHz and it worked.  However, the issue returned when I had increased the sampling here.  I have recorded a video of what I am experiencing and you can view it Here .

 

My Octoclock-G is set to Internal is wired as shown below.

OctoclockG circuit.png

Ideally, I would love to have signal based triggering using the PPS ports.  But, as you can see from my other thread there are still some bugs to work out.

 

 

"Lastly, you mention a goal of sampling at 100 MHz. The Tx processing on the FPGA will always transmit at the full device bandwidth (120 MHz of BW when using the 200 MS/s bitfiles). The sample rate will only affect the bandwidth of the signal you generate on the host, not what the FPGA transmits. "

Yes, you are right on that and thanks for reminding me about it!  So, does this mean that the Rx will also be sampled at 120MHz?  I cannot recall whether the actual Rx sampling rate will be overridden by the Rx sampling rate selected by the user at the front panel, or if the sampling rate at the front panel is just for the host-based signal processig to plot the spectrum and IQ data for the user to view.

 

Our goal is to have four USRP-2943R devices connected for synced full-duplex operation for a direction of arrival/phased array simulation.  If our results are satisfactory we plan on using one rio to transmit a message and a refernce signal, with seven other USRPs strictly used for a synced multi-channel Rx system.  The utlimate goal is to use the USRPs in a direction of arrival project, and hopefully many other ambitious projects if this one gets off the ground.

 

 

0 Kudos
Message 6 of 10
(5,294 Views)

@GenericAccount wrote:

Initially, I was running my code without any modifications made to the Multi-Device Tx Streaming Time (Host) VI.  It was then when I had experiencing issues with my generated Tx message while running two USRPs at 10MHz.

 

I then made the modifications of extracting each session from the session array and forwarding these individual sessions to their own Initiate and Generate Time(Single) VI.  The idea was for better efficiency through a parallel process.


Ah, interesting. What were the issues you experienced? The Initiate and Generate VI does very little processing--mostly data transfer to the USRP--so this explicit parallelism may not buy much, unfortunately. You may also experiment with configuring the For loops inside the Generate VI to be Parallel For loops too.

 


After doing this, the issue went away.  I then had tested it with three USRPs at 10MHz and it worked.  However, the issue returned when I had increased the sampling here.

If the issue is sampling-rate dependent, you should get a FIFO underflow error. If not, it may be a different issue.

 


So, does this mean that the Rx will also be sampled at 120MHz?  I cannot recall whether the actual Rx sampling rate will be overridden by the Rx sampling rate selected by the user at the front panel, or if the sampling rate at the front panel is just for the host-based signal processig to plot the spectrum and IQ data for the user to view.


The ADCs and DACs on the USRP are fixed to operate at the Data Clock rate. For the 120 MHz BW USRPs, the Data Clock is 200 MHz. So the ADCs and DACs will always run at 200 MHz (or a higher multiple of 200 MHz). The Sample Rate control on the host configures the decimation/interpolation that the FPGA's DSP does. Let me know if that's not clear.

 


Our goal is to have four USRP-2943R devices connected for synced full-duplex operation for a direction of arrival/phased array simulation.  If our results are satisfactory we plan on using one rio to transmit a message and a refernce signal, with seven other USRPs strictly used for a synced multi-channel Rx system.  The utlimate goal is to use the USRPs in a direction of arrival project, and hopefully many other ambitious projects if this one gets off the ground.


Very cool project! I do believe this is possible to do. If latency is important when transmitting the message+reference to the other USRPs, and if the logic for figuring out *when* to send the message+reference only exists on the one USRP, then signal-based synchronization is likely a better fit. If the host can tell the one USRP to send its message+reference, then time-based synchronization may be easier to setup.

0 Kudos
Message 7 of 10
(5,279 Views)

Hey General Account,  


One thing you may also wish to check out is this community example about angle of arrival detection using USRPs:

< https://decibel.ni.com/content/docs/DOC-25716 >

 

Hopefully you can use it as a helpful resource!

 

-ChristophersonJ

 

0 Kudos
Message 8 of 10
(5,274 Views)

"Ah, interesting. What were the issues you experienced? The Initiate and Generate VI does very little processing--mostly data transfer to the USRP--so this explicit parallelism may not buy much, unfortunately. You may also experiment with configuring the For loops inside the Generate VI to be Parallel For loops too."

 

The issues that I was experiencing can be viewed from the video that I had posted in my previous message.  You can watch the video here. I can try your idea of modifying the Generate VI and see how that goes.

 

"If the issue is sampling-rate dependent, you should get a FIFO underflow error. If not, it may be a different issue...The ADCs and DACs on the USRP are fixed to operate at the Data Clock rate. For the 120 MHz BW USRPs, the Data Clock is 200 MHz. So the ADCs and DACs will always run at 200 MHz (or a higher multiple of 200 MHz). The Sample Rate control on the host configures the decimation/interpolation that the FPGA's DSP does. Let me know if that's not clear."

 

I decided to trace out how exactly the user-selected sampling rate is utilized after it leaves the front panel to the FPGA.  If I understand correctly, the Host Rx sampling rate is written to rx.output sample rate on the FPGA and bundled into DDC Parameters. The Host Tx sampling rate is written to tx.input sample rate on the FPGA and bundled into DUC Parameters. The DDC Parameters and DUC Parameters are then bundled into rx.parameters and tx.parameters within the main Rx/Tx Parameters FPGA loop.

 

For Rx sampling on the FPGA:

1.Streaming Transceiver Engine loop sends rx.parameters to Rx Core VI

2.Rx Core VI strips out DDC Parameters from rx.parameters and sends it to DDC(Multichannel) VI.

3.DDC(Multichannel) VI sends DDC Parameters to DDC(Single Channel) VI

4.DDC(Single Channel) VI extracts output sample rate from DDC Parameters and sends it to a decimeter VI.  This decimation resamples the data for stepping down from the 200MHz sampling rate to a lower sampling.  This lower sampling rate is used for post-processing of the Rx data on the Host VI(ex:Power Spectrum plot).

 

For Tx sampling on the FPGA:

1.Streaming Transceiver Engine loop sends tx.parameters to Tx Core VI

2.Tx Core VI strips out DUC Parameters from tx.parameters and sends it to DUC(Multichannel) VI.

3.DUC(Multichannel) VI sends DUC Parameters to DDC(Single Channel) VI

4.DUC(Single Channel) VI extracts input sample rate from DUC Parameters and sends it to an interpolator VI.  This interpolation resamples the data by stepping up from the lower sampling rate used on the Host VI to the 200MHz usd on the FPGA.

 

If I made an error in tracing the steps, let me know.  The actual decimation and interpolation VIs are password protected by VI, so I really cannot get into their guts. But, by looking at this I understand better by what you mean by how the sampling rate on the Host for the Tx data can be much lower for signals in the kHz range.  It is going to be upsampled anyway.

 

The mystery that remains is why does increasing the Host sampling rate cause the sinunsoidal message to be pulsed(please refer to the video link that I had posted). Ideally, changing the sampling rate on the Host shouldn't be much of an issue. By looking at the FPGA code, wouldn't it have something to do with how the interpolation works with the Host sampling rate?  Perhaps it could the interpolation factor?  I am wondering if there is an upper limit of the Host sampling rate before interpolation causes signal distortion.

 

"Very cool project! I do believe this is possible to do. If latency is important when transmitting the message+reference to the other USRPs, and if the logic for figuring out *when* to send the message+reference only exists on the one USRP, then signal-based synchronization is likely a better fit. If the host can tell the one USRP to send its message+reference, then time-based synchronization may be easier to setup."

I just want to be sure that I understand this setup that you are referring to.  By "logic" do you mean FPGA implementation or just a simple Host VI implementation?  The setup is using this one USRP for sending out a Tx message through an antenna on one channel, and the Tx reference signal through the other channel. 

 

The goal is to distribute this Tx reference to the receiving USRPs and compare the phase difference between the Rx signal and the Tx reference signal with a desired accuracy within the picosecond range.  This is to perform some sort of calibration between the Rx channels.

 

For this setup, would Time-Based syncrhonization be the better suitable?  One thing that I was thinking is that if we went with the Signal-Basd synchronization, then wouldn't the Tx reference signal be unnecessary?

 

 

 

0 Kudos
Message 9 of 10
(5,252 Views)

@ChristophersonJ wrote:

Hey General Account,  


One thing you may also wish to check out is this community example about angle of arrival detection using USRPs:

< https://decibel.ni.com/content/docs/DOC-25716 >

 

Hopefully you can use it as a helpful resource!

 

-ChristophersonJ

 


We actually had reviewed that project, but it still is a good post.  The details in it served as a good reference for our project.

0 Kudos
Message 10 of 10
(5,251 Views)