Synchronizing Tx and Rx Processes

[GenericAccount]

Hello.  I am interfacing LabVIEW with a USRP NI2901 for a Doppler radar project.  These type of projects require that both the Rx and Tx channels be tied(synced) to the same local oscillator for proper time delay measurements.  However, I have learned that the Rx and Tx channels are not synced to the same local oscillator, and that time triggering should be implemented.  My program has been modified for time triggers and is attached with this post.  My start triggers are set to a 5.00 second delay.

My question is whether or not this implementation is the best way to sync Rx and Tx.  Am I doing this right, or is there a better way to ensure proper syncing between Rx and Tx?

[a_clucker]

Hi GenericAccount,

There are other sync methods available for the USRP 293x and 294x lines, but they aren't available on the 290x models. The niUSRP Configure Time Start Trigger function is the best sync function to use with the 2901. This function will make use of the device's onboard clock, which is much more accurate than the timing resolution/jitter available on the PC.

[GenericAccount]

Thanks for the advice.  I had incorporated the trigger into my VI(See attached).  It seems to do the job.  However, I still have buffer overflow/underflow and queing issues.  But, this is getting worked on in another thread.

[a_clucker]

Sounds good. Glad the trigger is working!

[GenericAccount]

I do have an issue.  Attached is a revised VI using the time triggers.  Sometimes it works, sometimes it gets the buffer underflow.  Also, I receive a Tx error message "Packet had timestamp that was late (or too early)." and Rx error message "A stream command was issued in the past".  Screen shots of these errors are attached with this post.  I thought that initiliazing the timer to zero and then setting a start trigger would resolved these types of errors.  Attached is my VI.  What am I doing wrong here?  I am following reccommendations as close as I can.

I also have a question regarding timestamps.  Lets say my program execution had reached the Tx/Rx processes.  But, the USRP timer did not yet hit the start trigger time.  Do my Tx/Rx operations sit idle until the USRP timer reaches the trigger time?  Or does LabVIEW just plows over them and gives me an error as if the Tx/Rx operations weren't ready and LabVIEW does not wait for them?  The reason that I am curious is that from my VI I am taking a timestamp of the Tx process as soon as program execution reaches it.  Yet, this timestamp is at a time which is earlier than my start trigger time.  This is a sort of way for me to get a timestamp of start of transmission. 

[a_clucker]

Generic,

I was able to dig up a few things on those errors that might be helpful. I think the most important one is one is listed as a NI-USRP Known Issue: http://www.ni.com/product-documentation/52445/en/#466351_by_Severity

Here are two threads that experienced the “Stream command issued in the past”:
http://forums.ni.com/t5/LabVIEW/NIUSRP-error-in-receiving-data-with-synchronized-5-USRP2-boards/td-p...
http://forums.ni.com/t5/USRP-Software-Radio/Error-1074118649-occurred-at-niUSRP-Fetch-Rx-Data-2D-CDB...

And here are two regarding “Timestamp that was late (or too early)”:
http://forums.ni.com/t5/USRP-Software-Radio/Packet-had-timestamp-that-was-late-or-too-early/td-p/236...
http://forums.ni.com/t5/USRP-Software-Radio/Trouble-with-multiple-time-sensitive-starts-of-2x2-MIMO-...

As for the second question, the TX/RX processes should be sitting idle after you call their respective niUSRP Initiate commands. I would recommend to take a timestamp immediately after Write TX data returns, as this will be closer to the actual write time.

Also, do you think you can link to the other forum post you have open regarding overflow/underflow?

Regards,

[GenericAccount]

Hey, Andrew. Thanks for the info.  I have been working had on this and attached is the latest, most stable Vi.  I had employed sequential structures and placed the Start Trigger initialization before the Set Timer.  I had also tweaked the Start Trigger with various values until the errors had gone away.  So, I would say that I think that settles the timing issue.  I have not yet implemented a Tx time stamp right after the Write Process.

As for my buffer issue, here is a link to the forum topic: https://forums.ni.com/t5/LabVIEW-Communications-System/Labview-Communications-Suite-Buffer-Overflow-...

I have stumbled upon something interesting by sheer dumb luck that had greatly helped my buffer issue.  It will be posted in the forum link above so as to keep the topics organized.  Thanks!

[a_clucker]

Hi Generic,

I went over to the other thread, and it sounds like you're on the road to success! Thanks for the update on both issues.

[GenericAccount]

Thanks.  I don't want to say that it is complete a success, but it is progress!  There is still more testing to be performed to see if what I have is satisfactory.  I am wondering though.  It is really hard to find similar projects to our Doppler radar project.  Has this ever be done before on the NI-2901 with LabVIEW?  Or am I pretty much blazing trails with this project? I could also be searching in the wrong places for similar projects.

[a_clucker]

Generic,

Working with Doppler radar almost certainly has been done with LabVIEW. I poked around a bit for existing Community Examples, but haven't found any. I did find a useful White Paper. This is a little more geared toward theory, but should hopefully provide you with more context.

As I mentioned above, I expect someone has done this with a USRP, but I haven't seen that anyone's posted their code. If you do end up making this, it would be a great resource for others who come after you 🙂

Kind Regards,