Stop.vi and the Buffer

[cochenob]

Would calling the Stop.vi and then re-initiating be a round-about way to 'flush' the PC buffer?

I want to initiate an acquisition...fetch some data...then go and change some parameters (center frequency, etc.) and re-initiate.  I'd like to make sure though on my subsequent initiations and fetches that the data I fetch isn't still pointing to "old" data in the buffer.

It seemed from previous posts that there wasn't a specific function to flush the buffer...but I'm curious if there's something I can do that effectively does the same thing.

Said more simply...what processes in the driver cause the buffer pointer to "reset"?

---

Brandon

[cochenob]

Follow up question...would reseting the system timer accomplish the same goal?  i.e. does resetting the system time reset the pointer back to "time zero", effectively ignoring any samples still in the pc buffer in the moment right before I reset the clock?

[Door-C]

You could do that but you will need to read all the data that is in the buffer to be for sure. Use the output of a USRP Property Node (Number of Samples) and then do one more Fetch but don't connect any indicators. That should read off any remaining samples that are on the buffer. Then you can Abort your task so that you can reconfigure it. There is a small code snippet below to illustrate what I am talking about. Your second method mentioned would not clear the buffer and I would recommend using the method in the code snippet instead.

[cochenob]

Thanks Noah-

Question though....isn't "Number of Samples" just the fetch size determined by the user?  This number could still be smaller than the actual number of samples in the buffer.  Even if I assume that my fetch rate is much faster than the rate at which packets come into the buffer, is it possible that a new packet could be delivered between my last fetch and the execution of the Stop.vi?

---

Brandon

[Door-C]

There could be a small chance that you could see that happen. You could remove the Number of Samples property node and connect a -1 constant to the Fetch.vi. That should read any remaining samples on the buffer as well.

[cochenob]

Hi Noah-

I tried the -1 thing previously.  It didn't work  (see this related post).  This was with v1.2 of the driver, so maybe things have changed in v1.3?  Either way...this would be a great feature to put on the roadmap for future revisions, especially for MIMO applications where it may be beneficial to "clear the slate" without having to re-tune/re-calibrate everything.

---

Brandon