Re: [Discuss-gnuradio] WBX Dual Receiver

[Marcus Müller]

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