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.
The next step is to save data leaved in onboard memory.
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.
AFAIK there is no simple way to simulate NI PXIe-5661.
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; LOBoardTypeXIe
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
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?
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.
I realize this post is a bit old so * bump *
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!
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:
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.
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:
And now it runs real-time.
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.
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 :-).
This actually worked even better with LV 64bit and native File IO VIs. I didn't even have to modify the block size, etc.