LO locking around 100 MHz with v1.3

[cochenob]

Here's a fun one...

See if anyone else can create this using two N210's (NI 2920's) with a MIMO cable and version 1.3 of the driver. 

- Open up "niUSRP EX Rx Multiple Synchronized Inputs (MIMO Expansion).vi" example program.

- Enter the IP addresses of two USRPs connected via MIMO cable.

- Change the carrier to 100MHz

- Change the start trigger time to 1 second

- Go into the block diagram and at the "Set Time.vi"...delete the wire of the Ring constant...or set to "Now".

Ok.  Now....run this program over and over (a few options on how to do that: 1) press the Run arrow let the radio configure, start fetching, then Stop...and repeat that over and over.  2) Have LV do it for you by pressing the "Run continuously" button, and just press the Front Panel stop button to stop the Fetch loop and continuously keep reconfiguring the radio...or 3) Just go into the block diagram and remove the while loop around the fetch).  However you do it...you should find that you can spin up the radio over and over with no problem.   

Ok then.  Now change the carrier to 101 MHz  (or really any frequency around there....101MHz, 105.373 MHz, etc).  Try running the program over and over again.  It's random, but you'll start getting the "The Local Oscillator did not lock within the alloted time" error message. 

1. Yes...I have the most recent version of the FPGA and FW flashed on the radios.  (This seemed to be the only suggestion here when searching for the error message on the forum).  Though...interestingly enough...I don't see this issue on a machine running v1.1 of the driver.  I've also test on multiple laptops and multiple USRPs.

2.  I observed similar behavior with non-MIMO'd applications as well (for example...try the same thing with the "One Shot" example that only uses one Rx radio).

3.  The error seems contained in the 100-110MHz range, approximately.  I haven't be able to "break" things at any other frequency.  And of course....at 100MHz exactly...things are fine.

I suspect this has something to do with the behavior of the PLL in this band...but I don't know enough about the chip to infer much more beyond that.  Has the "tolerance" for how long the driver waits for and "acceptable condition" changed in v1.3?  (I don' t see this error in v.1.1).

Any ideas on what's going on here?

---

Brandon

[PeanutButterOven]

I will look into this behavior, and see if it is reproducible.

[cochenob]

Any luck here?

[ErikL]

The ADC sample clock in the USRP runs at 100 MHz.  Often there is a large spur caused by that clock.  I recommend not working at 100 MHz on the 2920.

There are DSP filtering techniques that can be used to minimize the impact if absolutely necessary.