NI-2920 buffer size

[cochenob]

"I heavily believe that the role of memory management plays a very small part next to what happens with those samples in your program..."

I couldn't agree more!  Which is why I'm trying to make sure I know as much as possible about what the driver is doing so that I make smart choices on the processing end.

My sample rates are relatively low I suppose...1MS/s or less.  I do some magnitude and frequency calculations after that, with the end result being a form of FSK demodulation.  Because my transmitter and receiver are not on the same platform, the receiver processing must then 'search' for the 'real' beginning of the data stream.  Currently...I have two 'processes' set up.  One that fetches data out of memory and puts it into an array (a 'buffer' so to speak)...and another that then does the calculations and searches the buffer (doing a point-by-point correlation) looking for the beginning of the data stream (a pn-code).

Currently...the driver fetches are putting IQ data into the array much faster than I can calculate magnitude, frequency, and do the point by point search.  LabView slows down as my array variable is getting stuffed with memory faster than I can take it out and operate on it. 

It may be more efficient to just let LabView manage all the data in memory, rather than copying packets into an array variable.  With this option, I'd operate on each fetch packet one at a time, rather than having two processes that were both operating on the same array.  However...this option would let data build up in memory as managed by the USRP driver rather than in a variable created by LabView.  It's unclear if this is any better of an option...and really...it's why I'm trying to get some more insight as to what the driver is doing. 

So...even though I had hoped to get a better feel for what I would need to do to "keep up" with the USRP data stream, it seems like we're just going to have to give it a go and see what happens! 

Thanks for the conversation.  Do let me know if you have any other insight that might be helpful.

---

Brandon   

[cochenob]

I just wanted to ask a follow-up question here.....the documentation suggests that fetches be some multiple of 360 (or thereabouts) because these are the number of samples that fit into an Ethernet frame. 

My question....if you're really fetching from PC memory and not the radio itself...what difference does it make what your fetch sizes are?  I'm presuming the radio isn't sizing it's packets based on what you say the fetch size is.  Once it has a full packet of data...it ships it off to the PC, regardless of how big of a 'chunk' you then fetch out of memory.  Do I have this right?

If so...why bother fetching a multiple of an Ethernet frame?  Does it help with memory allocation somehow?  i.e. - you're memory writes and reads are all similarly sized chunks?

[Anthony_F]

Brandon,

I talked with our developer late last week and you have a good point. 

Once it has a full packet of data...it ships it off to the PC, 

That is correct operation of the FPGA.  Our driver is based on the universal hardware driver (UHD) by Ettus.  In UHD,  it will hold the samples in computer memory until it has enough to be delivered to the calling program.  We will take a better look into the suggestions provided by our documentation.