[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: |
Fri, 26 Feb 2016 13:15:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
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
- [Discuss-gnuradio] WBX Dual Receiver, Justyn, 2016/02/23
- Re: [Discuss-gnuradio] WBX Dual Receiver, Marcus D. Leech, 2016/02/23
- Message not available
- Re: [Discuss-gnuradio] WBX Dual Receiver, Marcus D. Leech, 2016/02/23
- Re: [Discuss-gnuradio] WBX Dual Receiver, Justyn, 2016/02/24
- Re: [Discuss-gnuradio] WBX Dual Receiver, Marcus D. Leech, 2016/02/24
- Re: [Discuss-gnuradio] WBX Dual Receiver, Justyn Bell, 2016/02/24
- Re: [Discuss-gnuradio] WBX Dual Receiver, Marcus Müller, 2016/02/24
- Re: [Discuss-gnuradio] WBX Dual Receiver, Justyn, 2016/02/24
- Re: [Discuss-gnuradio] WBX Dual Receiver,
Marcus Müller <=