|
| From: | Justyn |
| Subject: | Re: [Discuss-gnuradio] WBX Dual Receiver |
| Date: | Wed, 24 Feb 2016 12:18:46 -0800 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
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. -- JustynThere 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 address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
| [Prev in Thread] | Current Thread | [Next in Thread] |