discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] WBX Dual Receiver


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] WBX Dual Receiver
Date: Wed, 24 Feb 2016 19:39:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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
>>>>>> address@hidden
>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]