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
