Flushing the buffer

[cochenob]

Is there a way to do this?

I'm doing a MIMO-like measurement where I first need to find the phase difference between the two USRPs (connected via MIMO).  The reference/calibration measurement is made on Antenna 1....and the DUT measurement on Antenna 2. 

Using a property node in a loop with the Fetch VI....you can swap back and forth between Antennas without having to retune the radio (which is great, otherwise you runin the thing you're trying to calibrate in the first place).  BUT...unless you flush the buffer after you swap antennas....your next fetch may still be looking at "old" data.  Basically...you never know where in the buffer you are.

I considered doing finite acquisitions....but it seems that you have to re-initiate (and hence...re-tune the LO's) after each fetch.

I am hoping there's either a way to flush the buffer OR somehow separate the driver command that retunes the LO from that which just turns on the ADC's and sends packets back to the host.

Ideas?

---

Brandon

[cochenob]

I'm beginning to feel that the above issue is why this example (https://decibel.ni.com/content/docs/DOC-25716) used the RF coupling of the switch with the reference tone at a different frequency from the "signal" so that each measurement could be made simultaneously?

(Another reason why being able to provide your own LO makes all of this go away. 🙂  Pretty pleeeeeeease?)

---

B

[cochenob]

One final comment...

Since the buffer is in PC memory and not the USRP.....are there 'generic' VI's in LabView that could be used to flush the buffer? (Sort of like VISA commands for Serial acquisition).  There isn't a whole lot (well, any really) info on how the driver handles data transfer from the USRP into memory (maybe for good reason!), so I'm shooting in the dark here.

Really though...if one could decouple the Initiate process from the "re-tune" procedure...this would certainly do the trick.  It seems though that the act of sending packets and a configuring of the radio happen together.  I did notice a "Commit.vi"...but the documentation was thin.  How does this differ from Initiate?  Any trick to play here?

---

BC

[cade]

Hello Brandon,

Can you elaborate on which property node you are using to witht he USRP fetch command that allows you to switch between an acquire on each antenna?

Could you send a code snippet of the section of code that is giving you the problem? This will be very helpful in me assisting you.

Thanks, 

[cochenob]

Cameron-

Attached is my code.  The main VI is "MIMO calibration test".

Using Property Nodes within my "fetch" loop...I found that you can change the antenna the USRP looks at and things don't seem to retune (i.e. the phase difference between radios does not change).  You could also change the gain in this loop as well with the same effect.  Since you have no idea where you are in the buffer during any given fetch...it it not a given that just because you change antennas in one loop iteration, that you will see these changes in the fetch immeditely after.  (In this example it *might* be true since I'm not doing much after the fetch....BUT...in general...there's ambiguity here).

I'd need to....

1.  Flush the buffer after switching antennas before I fetch.

OR....

2.  De-couple the re-tune procedure with the initiation of data transfer from the radio and do two finite fetches.

[cade]

Hello,

Thanks for sending the code along.

It looks like you are fetching from both channels simultaneously on each iteration of the while loop provided you have the property nodes set to active antenna. At any rate, the USRP Fetch function should fetch relative to the last read which means that it fetchs from the buffer at the point that immediately follows the last read. 

This means that you should not read duplicate samples.

[cochenob]

Cameron-

I am not concerned about fetching duplicate samples....rather...I'm concerned about fetching "leftover" samples from the previous antenna/iteration.

For example.....say I Initiate an acquisition on Antenna 1....USRP samples begin filling the buffer.  I then read, say, 5000 samples.  Afterwards....I wait around for awhile, maybe compute a spectrum, do some other calcuations, etc etc..  All the while....the buffer is still filling up with samples from Antenna 1.  On my next iteration...I switch to Antenna 2, then do another fetch.  The issue is that this next fetch, as you say, will pick up right where I left off....meaning that I'll have to chew through the the remaining Antenna 1 samples that were delivered while I was sitting around processing my first fetch.  If you want to convince yourself of this...have the case statement inside the loop execute every iteration instead of every 8...and maybe also insert an additional delay in each iteration.  Then go and change between the two antennas.  You'll likely see there will be a bit of lag until the other antenna's data shows up.  Eventually, if you don't increase your fetch size or reduce the delay...you'll get a buffer overflow...but you'll get the point.

The only two solutions I see are to 1) Flush the buffer or 2) do two finite fetches, but figure out a way to *not* retune the radio before the second acquisition.  Right now it seems that acquisition initiation and LO re-tuning are coupled.  Would be great if the driver had these as separate 'events'.  In other words....only retune the radio for things that actually require retuning...like changing the center frequency.  Deciding to send packets back to the PC or not shouldn't be tied to retuning the radio (at least in my limited understanding...maybe there's a good reason for this?).

Appreciate the conversation!  Always helps us learn more about the USRP.

---

B 

[cade]

Hello,

The USRP Fetch function will fetch samples from both channels simultaneously. Is there a reason why you are desiring to fetch from one antenna at a time? If you make sure both channels and antennas are active and complete a multichannel fetch, you will not read any "leftover" samples.

Thanks,

[cochenob]

I was careless in my terminology....by "channels" I meant "antenna".  I think maybe the driver property node uses "channels" to represent actual radios.

I want to read *Antenna 1* from each radio, then flip the switch to read *Antenna 2* from each radio.  The problem is that after I flip the RF switch in both radios...I may not yet be at that place in the buffer...hence, a need to flush it to assure that I'm reading data from the antenna (from each radio) I think I'm looking at.

[cochenob]

Actually...going back through my earlier messages...I wasn't as careless as I thought. 

Yes...I want to read only one antenna from each radio at a time.  Actually...this is regardless of want I *want* to do...it's what I'm able to do!  There's only one receive chain on the WBX...so I have to set the switch to one antenna or the other.  To my knowledge, you can't read both antennas at the same time with the WBX.