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
>>>>>>> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment