Behavior change with MIMO cable operation?

[cochenob]

I have a bunch of previously-written applications using two USRPs connected via MIMO cable.  In the code, I set the Start Trigger Time to something...configure the radios....call the Set Time vi (with the 'apply timestamp' parameter left defaulted to "now")...Initiate acquisition...and begin fetches.  Has always worked without a problem.

Recently though I'm randomly getting the "Incoming data packets could not be time-aligned" error, suggesting that I'm losing synchronization.  There does not seem to be much rhyme or reason as to when this happens (sometimes it happens immediately, other times after many fetches). 

I was looking at the MIMO help (http://zone.ni.com/reference/en-XX/help/373380F-01/usrphelp/mimo_sync/) and under number 5, it says, "If the device uses a PPS signal from the MIMO connector, do not call the niUSRP Set Time VI. The onboard device timer automatically synchronizes to the master device and drives the timestamp over the MIMO connector."

Is this new?  I don't recall seeing this instruction before.  Did something change with driver versions along the way and I'm just seeing it now?

---

Brandon

[Case_in_Point]

Hey Brandon,

At the very least, that doesn't seem to be a new caveat. I found that in the USRP help as far back as 2012: http://zone.ni.com/reference/en-XX/help/373380C-01/usrphelp/mimo_sync/. Wasn't able to find an older Help than that one that had the MIMO synch section, but not super important.

There may be several other things going on with your system. What USRPs are you using, and how many/what is your overall MIMO configuration? Are you getting the error exclusively pointing to your slave USRPs, or will a master throw it sometimes? I did find some potentially relevant reports on USRPs with the GPS oscillator. The 293x series defaults to using the GPS oscillator as it's timing source, and if you get a bad GPS lock that can cause the error you're seeing when the GPS oscillator isn't capable of driving the right timing signals. Is that potentially happening here? Are you explicitly setting the timing source for your USRPs to MIMO, or Ref In, or not setting it at all? Finally, how are you using the Set Time VI/when are you setting the time (now vs. next edge)?

Cason

NI Applications Engr.

[cochenob]

Hi Cason-

I didn't think there would be.  In fact, if I don't call the VI (as the bullet point seems to suggest), I get the expected "The LO didn't lock in time" error, which is indicative of the device timer not being set.  Those bullet points under item #5 seem to be a bit confusing then.

In any case...I'm using two N210's (292x's I guess?) with a WBX.  I explicitly configure the Ref and PPS on one for "internal" (the master?), and the Ref and PPS on the other for "Mimo" (the slave).  I'm not certain at the moment which one I have the Ethernet cable plugged into, but I didn't think it mattered.  Does it?  Afterwards, when setting the system clock to 0, I set the "when" to Now (when I use external Ref and PPS from an octoclock, this changes to "next edge").

It is unclear whether one radio or the other throws the error (I didn't realize there was a way to determine that!).  The majority of the time, acquisition occurs without a problem.  Randomly however, fetches get hung up, and I get the "Incoming packets could not be time aligned" error.

It's unclear if the hang up is coming from the USRPs having some kind of timing issue, or from some other place in my application.  That said...if it was my application that was slowing things down somewhere, I'd expect the "you didn't fetch fast enough and you're out of memory" error, rather than the "I've lost synchronization" error that I'm seeing.

I may try to continuously run one of the example programs to see if I can get the error with one of the shipped routines.  That would then point to the radios (though still unsure what would cause this).

Thanks for the discussion.

---

Brandon 

[Case_in_Point]

Brandon,

Your elaboration helps a lot. I'm honestly also confused by that note in the Help now. I looked at the Rx MIMO LabVIEW example (Rx Multiple Synchronized Inputs (MIMO Expansion).vi) and that example also calls Set Time on both the master and slave. It uses internal references for the master and MIMO for the slave, just as you're doing. But then, I compared to one of our whitepaper MIMO examples (http://www.ni.com/white-paper/14311/en/), and in that code they only Set Time for the masters that are getting their time from the external source. All of the slaves, which get time from the MIMO, don't ever get their time set. So I'm honestly not positive which is the ideal method.

You've got the Master and Slave exactly right, but on the Ethernet cable question I'm pretty sure you should have the Ethernet cabled to the master. You don't need to connect to both USRPs, since the MIMO lets you communicate to the downstream unit, but I do think you should connect to the master directly, although I'm honestly not sure what would be the impact if you connected to the slave.

I also don't think you'll be able to tell which USRP is giving you an error from the message. If you were calling some functions only on one unit and then that function errored, then you'd know, but it sounds like all your commands are applying to both USRPs so you won't know which is which. It would be worthwhile to swap which one is master and slave, though, to see if that changes behavior. I also think it'd be a good idea to try the example programs and see if they ever give you an error.

Cason

NI Applications Engr.