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
