When tuning, the WBX/SBX/UBX LO synthesizers always reconstruct the same phase for a given frequency. With the WBX, that only works with the discussed +- ambiguity.
So, this only happens when you re-tune. Estimate whether you're off by 180° after every tune. Calibrate the remaining inter-channel phase offset once per daughterboard and frequency. Best regards, Marcus On 24.02.2016 21:18, Justyn wrote: > You're right: this isn't a show stopper, and in the context of this > not running in real time for my purposes anyway, I don't think it's a > big deal. > > In the interest of completeness, when is this ambiguity introduced? On > power up, or on some/any UHD call? Basically, when should I be aware > and correct this phase ambiguity from test to test, run to run? > > -- > Justyn > > On 02/24/2016 10:39 AM, Marcus Müller wrote: >> on the N210: SBX. >> UBX on the N210 does have that ambiguity (it doesn't on X3x0). >> >> re MIMO: well, ambiguities aren't nice, but as a matter of fact, any >> communication receiver needs to have a timing / phase recovery, be it a >> MIMO receiver or not; typically, you'd try both options (remember, 180° >> is just a multiplication with -1) and see what gives a better result. So >> that's a quirk that's relatively easy to work around. >> >> Best regards, >> Marcus >> >> On 02/24/2016 07:20 PM, Justyn Bell wrote: >>> As little comms knowledge as I have, I have even less about MIMO. >>> However, I'm having a hard time understanding how the WBX boards would >>> even be considered for any MIMO application when there could be a >>> random 180 degree phase offset. Is there another daughtercard in >>> which this little quirk is NOT present? >>> >>> I'll try to find some examples of the timed commands and we'll see >>> where we can get on this. >>> >>> Thanks for all your help, I've learned more about the WBX and >>> synchronization in these two days that I have in months. >>> >>> -- >>> Justyn >>> >>> On 2/24/2016 5:56 AM, Marcus D. Leech wrote: >>>> On 02/24/2016 12:24 AM, Justyn wrote: >>>>> Forgive me because I'm a software engineer with little theoretical >>>>> comms experience, but I'm having a difficult time understanding what >>>>> a 180 phase shift at RF would mean for my baseband signal. If >>>>> anything. >>>> A phase shift at RF comes out as a phase-shift at baseband. It had >>>> better, otherwise, things like PSK modulation wouldn't work. >>>> >>>>>> Now the issue is that with GRC, there's no way to use >>>>>> timed-commands directly, so you end up either coding in naked >>>>>> python/C++ yourself, >>>>>> or modifying the code generated by GRC to wrap the tuning >>>>>> functions in UHD timed commands. >>>>> Timed commands are the mechanism for time synchronization I was >>>>> looking for, I think. I have a sample C++ application that I've >>>>> written a while ago to directly interface with the UHD. Although if >>>>> there's a more complete example, I would like to see that. >>>>> >>>>> If I get a MIMO cable, can I avoid these timed events, and possibly >>>>> use GRC? The application I'm working on serves a primary purpose, >>>>> but is also meant as a learning experience for a group of students >>>>> so keeping it within GRC would be ideal for future development. >>>> The MIMO cable is just a way to share clocks, rather than using an >>>> external reference. Your application still has the responsibility to >>>> set things up for synchronization, and used timed commands to try >>>> to force phase-offset reset. >>>> >>>> Basically, on cards that support it (WBX, SBX, UBX) the final piece >>>> of tuning involves asserting a hardware signal that says "reset thy >>>> phase". >>>> The only way that can be made "useful" is if all tuning commands in >>>> a "coherent cluster" (my term) tune their tuners at precisely the same >>>> time. Which is where timed commands come in. Provided that all >>>> participants in our "coherent cluster" of USRPs agree very closely >>>> on the time-of-day, timed-commands allows this "let's all tune at >>>> exactly the same time" thing to occur. But in order for them to all >>>> agree on what time it is, they must share a 10Mhz reference clock, >>>> and a 1PPS signal derived from that clock to provide a common >>>> synchronization point for operations like "set_time_next_pps()". >>>> >>>> Time and phase synchronization is one of the trickier aspects of USRP >>>> usage. GRC makes some of this easier by providing "point and click" >>>> setup of time-synch options. But there's currently no >>>> corresponding way to enable the use of timed-commands in a UHD USRP >>>> block >>>> consisting of more than one USRP. >>>> >>>> >>>>> -- >>>>> Justyn >>>>> >>>>> On 02/23/2016 08:46 PM, Marcus D. Leech wrote: >>>>>> On 02/23/2016 11:34 PM, Justyn wrote: >>>>>>> Makes sense. >>>>>>> >>>>>>> If I can ask a follow up here: >>>>>>> >>>>>>> 1) If I instead use 2 USRPs connected via an external reference >>>>>>> clock and an Ethernet switch for receiving data, will they be >>>>>>> phase-aligned? If I understand what's going on in the context of >>>>>>> the ref clock, I think this is a yes. >>>>>> Assuming that you have an external reference, and 1PPS to >>>>>> time-synchronize them, and you use timed-commands to properly assert >>>>>> the phase-resynch logic in the synthesizers, then yes, with the >>>>>> proviso that WBX in particular uses a 2XLO mixer, which has a >>>>>> 180 deg phase ambiguity--since there's no way to predict or >>>>>> control the start state of the flip-flop inside the mixer that's >>>>>> used as >>>>>> a phase-splitter. So they'll either be aligned, or 180deg >>>>>> out-of-phase. >>>>>> >>>>>>> However, >>>>>>> >>>>>>> 2) On the TX end, if I use two USRPs connected to an Ethernet >>>>>>> switch, and synchronized by an external clock connected to the ref >>>>>>> clock port, is there any way I can guarantee that the first >>>>>>> samples of each are sent out at the same "time" (I don't know what >>>>>>> the appropriate term would be here, time, clock cycle, ref clock >>>>>>> tick, etc)? I suspect that unless there's a mechanism that does >>>>>>> this, this is a no. >>>>>> If you have both USRPs in a common multi_usrp object, then their >>>>>> outputs will be time-aligned. The same comments above about >>>>>> using timed-commands for tuning, and the 180deg phase-ambiguity >>>>>> continue to apply here. >>>>>> >>>>>> Now the issue is that with GRC, there's no way to use >>>>>> timed-commands directly, so you end up either coding in naked >>>>>> python/C++ yourself, >>>>>> or modifying the code generated by GRC to wrap the tuning >>>>>> functions in UHD timed commands. >>>>>> >>>>>> >>>>>>> -- >>>>>>> Justyn >>>>>>> >>>>>>> On 02/23/2016 08:26 PM, Marcus D. Leech wrote: >>>>>>>> On 02/23/2016 11:22 PM, Justyn wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm experimenting with the MIMO capabilities of the N210s with >>>>>>>>> WBX daughter cards and seeing how far I can get before I need >>>>>>>>> the MIMO breakout cable or GPSDO. >>>>>>>>> >>>>>>>>> One of the first things I'd like to see is if both receivers on >>>>>>>>> the WBX daughter card can run at the same time (TX/RX and RX2). >>>>>>>>> >>>>>>>>> Unfortunately, if I add two USRP source blocks with the same IP >>>>>>>>> to my flow graph and try it out, I get D's on the output. >>>>>>>>> >>>>>>>>> According to >>>>>>>>> http://files.ettus.com/manual/page_general.html#general_ounotes, >>>>>>>>> it seems that I'm getting "discontinuous packets" and are >>>>>>>>> subsequently dropping data (which I can confirm). I assume it's >>>>>>>>> because I'm receiving data packets with the same source address, >>>>>>>>> and probably duplicated sequence numbers which GNU Radio thinks >>>>>>>>> are discontinuous. >>>>>>>>> >>>>>>>>> Is there a way around this? Is this a bug? It seems if I have >>>>>>>>> the bandwidth and physical hardware, I should be able to >>>>>>>>> leverage those capabilities, no? >>>>>>>>> >>>>>>>>> This USRP and my workstation are connected through a switch, but >>>>>>>>> if I add a separate identical N210 with WBX to the switch, I get >>>>>>>>> both sets of data, so it's not a bandwidth issue. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Justyn >>>>>>>> There is only a single receive chain on a WBX card--there are, >>>>>>>> granted, two ANTENNA PORTS that may be selected that the receive >>>>>>>> chain >>>>>>>> attaches to, but there really is only one receive chain on a >>>>>>>> WBX card. >>>>>>>> >>>>>>>> The fact that you have two distinct UHD/USRP objects trying to >>>>>>>> communicate with the same physical USRP is going to create a fair >>>>>>>> amount >>>>>>>> of confusion in the lower layers which will result in >>>>>>>> unpredictable behaviour. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnuradio mailing list >>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
