RF Applications

cancel
Showing results for 
Search instead for 
Did you mean: 

RF Record and Playback Reference Application

Hi

Let me add a suggestion

 

Assume the following case

You need to record a signal at high BW (say 20 MHz) for as long as possible. but you have only simple HDD (no RAID) with maximum 20 or 40 MB/s. It is not enough for reliable streaming but you can hope to fill big onboard memory and RAM. (The same case if using 50 MHz BW and 200 MB/s RAID)

 

In this case during acquisition the signal gets to onboard memory, then quickly fetched to Queue (which is in RAM), and slowly stored to disk.

 

As far as we fill the queue quickly but dequeue slowly, at some moment Queue is full and can't fetch data from onboard memory.

Onboard memory starts to fill.

Then onboard memory is also full. Overflow error generated. Producer loop stops.

 

At this moment we have some important data in both queue and onboard memory. And we need to slowly store the data to disk.

 

 

But in the current version after Acquisition loop (Producer) stops, we release queue. There is additional loop waiting for queue to become empty before release it. It should save the data in queue.  But it stops in this case due to error ported to this additional loop.

 

To fix it we should simply delete the RFSA overflow error before this additional loop. This saves data in queue. The more queue size is (up to RAM size) the more data is saved.

delete error -1074118655.png

 

The next step is to save data leaved in onboard memory.

 

 

 

 

0 Kudos
Message 31 of 40
(7,242 Views)

Hi

 

Is it possible to use simulation for the PXI 5661 and then use this program to record the signal? because currently I don't have the device and need to try something before purchasing it.

Thank you very much.

 

Best regards

Dhimas

0 Kudos
Message 32 of 40
(7,190 Views)

Hi

AFAIK there is no simple way to simulate NI PXIe-5661.

http://zone.ni.com/reference/en-XX/help/372058L-01/maxrfsa/mi_rf_simulating/

You can simulate say NI PXIe-5663E by replacing niRFSA Initialize.vi with niRFSA Initialize with options.vi and using the following option string:

 

Simulate=1, DriverSetup=Model:5601; Digitizer:5622; LO:5652; LOBoardTypeSmiley TongueXIe

 

You can also simulate the device in MAX without need to modify the code.

 

Simulation is only simulation though and it can behave different

 

You can also share your doubts with your local representative or support

Alex

0 Kudos
Message 33 of 40
(7,187 Views)

Hi

 

Thank you for the solution. The simulation works well.

I have several questions about the program. I am not sure what is the meaning of absolute and relative timestamp in the header file. Can we get the time of recording from these two information? I found that the span/bandwidth can not go lower than 2 MHz. Is it the limitation of the hardware or we can change it in the program?

 

Thank you

 

Dhimas

0 Kudos
Message 34 of 40
(7,176 Views)

Hi

 

I am recording GPS signal using NI PXI-5652 and NI PXIe-5601 and after processing I found that there are some deeps in the tracking result. After some investigation it is found that sometimes the recorded signal is weaker for short while as shown in the figure bellow between time=5 and time=6 . Did anyone happen to meet this problem and find out the cause and solution? Thank you.

37.jpg

Best regards

Dhimas

0 Kudos
Message 35 of 40
(7,115 Views)

Hello All,

 

I realize this post is a bit old so * bump * Smiley Happy

 

I am having some issues running the pxie-5672 Simple Playback.vi found in the "Record and Playback Reference Application v02 (lv85).zip" package that was posted here. I am trying to stream a previously recorded binary file with it's respective XML file.

 

I am getting some sort of LabVIEW memory fault from a "Win32 Read I16.vi" I realized it uses some sort of Call Library Function Node to rundll32.dll which I guess is compiled in 32-bit? I am using LabVIEW 64-bit actually...Could this be the error here?

 

Is this VI package for LV 32-bit?

 

Thanks in advance for your help if anybody had a similar issue!

 

Erick

0 Kudos
Message 36 of 40
(1,955 Views)

Silly! That was the actual problem. This Reference Application SHOULD run on LV 32-bit version or it will not work, because of the Win32 libraries that it uses. Just in case this might help someone.

 

In other topics, I am still not able to stream the previously recorded file in a real-time manner. The file itself is around 40 GB in size, and was recorded with IQ Rate of 25 Ms/s. Again, this file has its own generated XML file.

 

On the playback side, I'm using a Dell Inspiron Desktop PC with 12 GB RAM, Intel Core i5 dual-core, Windows 10. I am using the NI PXIe-8370 Remote Control Module as interface with PC and the NI PXIe-5673 RFSG. Don't know what could be the bottleneck? Just throwing all the info in here.

 

This is what I am getting:

 

Capture.JPGError shownCapture2.JPGMy configuration

I tried increasing the Max Queue option up to around 50-60 as it seems the only tunable option, but sometimes threw a "LabVIEW memory is full" error and still no real-time achieved.

 

Any suggestions?

 

Thanks!

0 Kudos
Message 37 of 40
(1,950 Views)

Again I found my own solution, but might be useful for others.

 

I simply changed the VI properties of the "pxie-5672 Simple Playback.vi" in execution:

-No debugging

-Priority: time-critical

-Instrument I/O

 

And now it runs real-time. Smiley Wink

 

0 Kudos
Message 38 of 40
(1,943 Views)

Hi erick,

 

Glad you were able to work through and find a solution. Just a few suggestions though. Before putting the priority of the VI so high you might want to play around with the Block Size (aka # of Samples Per RFSG Write) and find an optimal value for that. The formula used to calculate block size doesn't always guarantee optimal streaming rate. 

 2018-07-06_0842.png

 

 

Some other optimizations for streaming can be found here: http://www.ni.com/product-documentation/5897/en/. 

 

Also, you can get around your 64/32 bit issues by using the LV File IO VI calls instead of the Win32 vi's. Performance will likely be better as well.

 

Hope this helps :-).



Tim Sileo
RF Field Account Specialist
National Instruments



You don’t stop running because you get old. You get old because you stop running. -Jack Kirk, From "Born to Run" by Christopher McDougall.
Message 39 of 40
(1,934 Views)
Highlighted

Thanks Tim!

 

This actually worked even better with LV 64bit and native File IO VIs. I didn't even have to modify the block size, etc.

 

 

0 Kudos
Message 40 of 40
(1,930 Views)