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.
> 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.
--
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
No comments:
Post a Comment