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
