Save Output from "niUSRP Fetch RX Data (poly).vi"

[krmills]

Hello all,

I'm trying to save data received by my USRP 2955 device for offline processing. The trouble is that the blocks I added to handle the file i/o portion cause overflow errors for the fetch rx data block. 

If we were to look at the example niUSRP EX Rx Multiple Inputs (Single Device, Multi Channel).vi, I want to save the output of the fetch rx data block, which is essentially shown in the "IQ Graph."

Attached is my adjustments to niUSRP EX Rx Multiple Inputs (Single Device, Multi Channel).vi with some blocks in the while loop to handle file i/o. Take note that the default values on the front panel have been changed to match my application.

Thank you for you assistance!

[pauldavey]

I am not experienced with niUSRP but if I assume your sampling rate is about 10MS/s and you are only fetching 16kS per read then your loop time needs to be no more than ~1.5ms, which is pretty tight (plus you attempt a Power Spectrum every 8th iteration!). I would suggest fetching more samples per read at least (maybe 10x). I would also test what sort of frequency of Power Spectrum execution you can manage (so start by disabling it).

[krmills]

Thank you pauldavey, but the overflow error isn't really what I'm trying to address. It only occurs when I have the Array Spreadsheet to String and Write to Text File blocks in the while loop. The VI I attached is just some minor adaptations I made to an existing example VI in an attempt to save the Rx data.

The problem I want to address here is how to save the "data" output from the niUSRP Fetch Rx Data (poly).vi, preferably in a text file.

[pauldavey]

Well you need to address the overflow error if you want to get data. You either need to read more at a time to lower the required loop rate or alternatively (and worth doing anyway) use a master/slave architecture (queues or similar) to pass your data off to a second loop that does the writing to text file (which can then be handled by a separate execution thread). Writing to disk is best done in bigger chunks at a lower rate rather than many little pieces at a high rate (within certain bounds). Running the Power Spectrum less often is also worth doing (at the moment you are attempting about 80/s which is overkill). Reading more data per read will achieve this indirectly.

[krmills]

Thanks for the help pauldavey.

I took out the graphs as they were not really necessary. I decided to go with a queue structure to take data from the Fetch Rx data block in one loop and feed it to Write to Text File in another. The updated VI is attached.

There are some new errors now. The first time in run the VI (since restarting the PC) I get:

Memory is full
The top-level VI "GNSS_Rx-V1.vi" was stopped at Build Array on the block diagram of "GNSS_Rx-V1.vi".
Refer to the VI Memory Usage topic in the LabVIEW Help for suggestions on monitoring and improving VI memory usage.

This error occurs after about 16s, during which Fetch Rx Data is saved.

On any successive runs I get niUSRP Open Rx Session.vi<ERR>bad allocation.

This error, of course, occurs before the Fetch Rx Data block.

[pauldavey]

Unfortunately I can't test your VI since I do not have the niUSRP driver installed, but one observation is that the file writing consumer loop might get terminated prematurely since you are checking if there are 0 or less items in the queue.  I would suggest removing that termination condition and just leave it with terminating on a queue error, and instead close the queue upon exit of the producer loop (not the consumer loop).  What loop count was the error occurring on?  If my guess is right, the problem is the queue is filling up you RAM with huge amounts of data so there is none left to build the array (since the consumer loop has stopped).

[krmills]

When the error occurs there are 14845 iterations in the USRP Fetch Rx Data (producer) loop, and 1235 iterations in the Write to Text File (consumer) loop. At the time of termination, LabVIEW is only consuming 4GB of RAM out of a 32GB total in my work PC.

Then to close the queue, I put a Release Queue block outside the producer loop connected via a tunnel to the Get Queue Status block, or how else should it be done?

[pauldavey]

Are you using LabVIEW 64bit? Otherwise 4GB will be your max, but I would think you should be able to stay away from that limit once the code is right. 

---

@krmills

Then to close the queue, I put a Release Queue block outside the producer loop connected via a tunnel to the Get Queue Status block, or how else should it be done?

---

 

Yes that is right. That way the consumer loop will terminate when the queue is released (the Dequeue Queue Element will generate an error) and not before. The other thing you can do is wrap your consumer code (inside the loop) with an error case structure (using the Dequeue Queue Element block's error out).