usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] E310 8x8/16x16 MIMO possible?
Hi jonathan,
25MS/s will not be possible in software; the ARM on the E310 isn't meant
for these loads.
If you want to have such a big MIMO system without heavy modifcation,
you should look at other USRPs. You're right, you'd be abusing an
embedded device as something else, and Ettus never designed it to work
well as a streaming peripheral.
However, if you're used to doing FPGA work on USRPs, this might be
different. E310 supports RFNoC, so buffering things from within the FPGA
to RAM might be viable; I have no experience at that, though. It will
also break the central USRP credo that you should get "live" data,
rather than "prerecorded samples" into your processing chain, but that
might be no problem for you.
<<snip>>
This is a nice write up/explanation Marcus. I've thought about similar
things in the past, so this was a good read-through of the stuff that
needs to happen to make it work out. I assume that with the proper
daughter-card, there is no reason something like the X310 couldn't work,
right (I know that that is much more costly than the OP was hoping for)?
Good luck with your research Jonathon, sounds interesting and I am
intrigued to see where it goes!
~Jason
Hi Jason,
On 20.08.2015 13:55, Jason Matusiak via USRP-users wrote:
I assume that with the proper
daughter-card, there is no reason something like the X310 couldn't work,
right (I know that that is much more costly than the OP was hoping for)?
in fact, the X3x0, with its two inherently time- and frequency aligned
daughterboard slots, was made with MIMO in mind, so yes, that's
possible. Unlike the B210, where that is complicated due to USB/control
issues, multiple X3x0 devices can be used in a single uhd::multi_usrp
object, making alignment even easier, and allowing you to recv() in
arbitrarily many channels at once.
Also, as Jonathan illustrated by using the maximum sample rate possible
over Gigabit ethernet, MIMO mostly plays a role in high-bandwidth
channels [1], so going for high rates makes a lot of sense. B210 is a
good compromise between cost and rate here, but again, the limit is the
USB hardware in your host computer.
Best regards,
Marcus
[1] for MIMO to be an improvement, i.e. for diversity gain, you'll need
the chance that your observations be independent of each other -- if you
observe your channel with a small sampling rate, you would not notice
e.g. multipath components that are $\le \frac1{f_\text{sample}}$ of each
other.
Thanks Marcus for the great write-up!
Luckily phase alignment isn't necessary. I'm using a modified 802.11ac
protocol to do spacial-multiplexing MIMO (independent data on each
channel). This means that a known sequence is sent in the header to recover
phase across all channels.
Good note about the relation between diversity gain and MIMO performance
for others. So far in an office environment I'm seeing good 4x4 diversity
gain (outdoors line-of-sight gives terrible performance because of lack of
multipath diversity) and from simulations I expect acceptable 8x8. Not sure
about 16x16 because there aren't many published results to compare against
and that's a large jump to extrapolate my multipath simulations.
Yes, the X3x0 line work great for MIMO. Ettus was nice enough to loan me
two of them a year ago. They are awesome radios but are outside my budget
for the time being.
I hadn't even considered the B210. Great suggestion!
B210 thoughts:
- The Spartan-6 FPGA looks like it has enough block ram to buffer the
received signal even if I completely choke the PC/USB3 with a large MIMO.
Not sure if increasing the buffer size would require an FPGA mod, but
should be "easy". - Good to know that the PPS doesn't need to be per-second.
- Lack of RF filter-bank is unfortunate, but the reduced cost needs to come
from somewhere. - For this sort of MIMO I don't expect the ~3dB difference in noise-figure
to matter because I'm basically jamming myself with the overlapped signals.
Should I expect any problems with the uhd::multi_usrp timed-commands on the
B210? Double checking because of some of the replied comments.
Documentation states that timed-commands work so I'm assuming they were
just warning that USB3 will lag with high MIMO data rates. With my
non-realtime application I presume I can just make the burst small enough
to fit in the FPGA buffer and then set the timed-command far enough in the
future to negate any lag issues.
[ jonathan hedstrom ]
On Thu, Aug 20, 2015 at 7:05 AM, Marcus Müller usrp-users@lists.ettus.com
wrote:
Hi Jason,
On 20.08.2015 13:55, Jason Matusiak via USRP-users wrote:
I assume that with the proper
daughter-card, there is no reason something like the X310 couldn't work,
right (I know that that is much more costly than the OP was hoping for)?
in fact, the X3x0, with its two inherently time- and frequency aligned
daughterboard slots, was made with MIMO in mind, so yes, that's possible.
Unlike the B210, where that is complicated due to USB/control issues,
multiple X3x0 devices can be used in a single uhd::multi_usrp object,
making alignment even easier, and allowing you to recv() in arbitrarily
many channels at once.
Also, as Jonathan illustrated by using the maximum sample rate possible
over Gigabit ethernet, MIMO mostly plays a role in high-bandwidth channels
[1], so going for high rates makes a lot of sense. B210 is a good
compromise between cost and rate here, but again, the limit is the USB
hardware in your host computer.
Best regards,
Marcus
[1] for MIMO to be an improvement, i.e. for diversity gain, you'll need
the chance that your observations be independent of each other -- if you
observe your channel with a small sampling rate, you would not notice e.g.
multipath components that are [image: $\le \frac1{f_\text{sample}}$] of
each other.
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hi jonathan,
On 24.08.2015 20:16, Jonathan Hedstrom wrote:
Thanks Marcus for the great write-up!
thanks for the nice words :)
Luckily phase alignment isn't necessary. I'm using a modified 802.11ac
protocol to do spacial-multiplexing MIMO (independent data on each
channel). This means that a known sequence is sent in the header to
recover phase across all channels.
Ah, that of course eliminates the need of alignment.
Good note about the relation between diversity gain and MIMO
performance for others. So far in an office environment I'm seeing
good 4x4 diversity gain (outdoors line-of-sight gives terrible
performance because of lack of multipath diversity) and from
simulations I expect acceptable 8x8. Not sure about 16x16 because
there aren't many published results to compare against and that's a
large jump to extrapolate my multipath simulations.
I'm trying to understand the scenario here: If I get this correctly, you
try to detect the preamble of each TX stream at each RX stream, then use
that to phase-align them, and add them up in a maximum-ration-combining
mode?
That would sound like it should give you something like
$C_\text{total} = B \log_2\left(1+\text{SNR}_\text{total}\right) = B
\log_2\left(1+f\left(\text{SINR}1,\dots,\text{SINR}{16}\right)\right)$,
bearing the question how $\text{SINR}_i$ behaves for growing i? Assuming
we sort the receive streams by their preamble SINR, can you achive at
least Selection Combining's $\text{SINR}_i = \frac1i}$?
Yes, the X3x0 line work great for MIMO. Ettus was nice enough to loan
me two of them a year ago. They are awesome radios but are outside my
budget for the time being.
I hadn't even considered the B210. Great suggestion!
B210 thoughts:
- The Spartan-6 FPGA looks like it has enough block ram to buffer the
received signal even if I completely choke the PC/USB3 with a large
MIMO. Not sure if increasing the buffer size would require an FPGA
mod, but should be "easy".
FPGA mod; I can't really tell you how easy this will be.
- Good to know that the PPS doesn't need to be per-second.
Yes; I stumbled upon this when a physicist asked me how to trigger
"recording" on an external pulse. You just issue a stream command in the
far future at time t, and then define that t should be loaded into the
timekeeping register on a PPS edge. I'm not quite sure this would ever
become an "official" way of doing things, but it's a hack for these
devices where that works.
- Lack of RF filter-bank is unfortunate, but the reduced cost needs to
come from somewhere.
Really really depends on your environment; for research, that's more
often than not OK. If it's not, external filtering might be inflexible,
but cheap.
- For this sort of MIMO I don't expect the ~3dB difference in
noise-figure to matter because I'm basically jamming myself with the
overlapped signals.
Should I expect any problems with the uhd::multi_usrp timed-commands
on the B210? Double checking because of some of the replied comments.
Documentation states that timed-commands work so I'm assuming they
were just warning that USB3 will lag with high MIMO data rates. With
my non-realtime application I presume I can just make the burst small
enough to fit in the FPGA buffer and then set the timed-command far
enough in the future to negate any lag issues.
Yes. First of all, UHD doesn't support bundling multiple B2x0 devices
under one multi_usrp object at the moment. This means you will have to
maintain one multi_usrp per B210, and one rx_streamer/tx_streamer, too.
Also, timed commands only exist in the FPGA, so you can do anything
that's purely digital (ie. starting/stopping sampling, retuning the
DSP), but things that have to be communicated to the AD9361 (gain
setting, retuning the LO) will just happen "instantly".
Best regards,
Marcus
[ jonathan hedstrom ]
On Thu, Aug 20, 2015 at 7:05 AM, Marcus Müller
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
Hi Jason,
On 20.08.2015 13:55, Jason Matusiak via USRP-users wrote:
I assume that with the proper
daughter-card, there is no reason something like the X310 couldn't work,
right (I know that that is much more costly than the OP was hoping for)?
in fact, the X3x0, with its two inherently time- and frequency
aligned daughterboard slots, was made with MIMO in mind, so yes,
that's possible. Unlike the B210, where that is complicated due to
USB/control issues, multiple X3x0 devices can be used in a single
uhd::multi_usrp object, making alignment even easier, and allowing
you to recv() in arbitrarily many channels at once.
Also, as Jonathan illustrated by using the maximum sample rate
possible over Gigabit ethernet, MIMO mostly plays a role in
high-bandwidth channels [1], so going for high rates makes a lot
of sense. B210 is a good compromise between cost and rate here,
but again, the limit is the USB hardware in your host computer.
Best regards,
Marcus
[1] for MIMO to be an improvement, i.e. for diversity gain, you'll
need the chance that your observations be independent of each
other -- if you observe your channel with a small sampling rate,
you would not notice e.g. multipath components that are $\le
\frac1{f_\text{sample}}$ of each other.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Interesting that there is no multi-B2x0 device mutli_uspr support yet. No
problem, I can manage them independently. It might not be as clean, but
will suffice.
Small miscommunication because of my vague description and incorrect use of
the word diversity-gain. I'm doing spacial-multiplexing MIMO which sends
completely different data on each antenna. The math involved is y=H*s where
y=complex_received_data_vector, s=complex_transmitted_data_vector,
H=complex_matrix_representing_how_signals_mix_in_the_air. Although all of
the data is mixed together, if you can correctly identify H by using a
known sequence in the header then you can simply apply the inverse of H to
recover the data. The unknown phase offset between ADCs is automatically
sucked into the estimation of H. My university research and startup is
trying to do better than an inverse solution without the complexity of
maximum-likelihood. Since this is just research and proof-of-concept,
real-time operation isn't necessary.
FYI for anyone else reading the thread. I already tried changing the FPGA
code to increase buffer size (untested on hardware but compiles easily).
Having done this already for the USRP2's it turned out to be similar and
easy. The current FPGA code in UHD3.8.5 uses 15% of slice registers, 39% of
slice LUTs, 84% of DSP48s, and 69% of block RAM. The low slice utilization
means timing should be easy to meet with well made code. Also, there is
plenty of block RAM available for increased buffering (maximum of ~20ksps
increase possible). Until I have hardware I can't be sure but changing a
combination of DATA_RX_FIFO_SIZE, DATA_TX_FIFO_SIZE, EXTRA_BUFF_SIZE inside
fpga/usrp3/top/b200.v and b200_core.v should provide the changes to
optimize for large MIMO bursts. Be aware that the meaning of TX and RX
might be reversed. For USRP2 the FPGA code in the top level is all in
reference to ethernet direction which is the opposite of transceiver
direction. Not sure about B2x0 yet.
Thanks a lot Marcus!
[ jonathan hedstrom ]
On Mon, Aug 24, 2015 at 1:40 PM, Marcus Müller marcus.mueller@ettus.com
wrote:
Hi jonathan,
On 24.08.2015 20:16, Jonathan Hedstrom wrote:
Thanks Marcus for the great write-up!
thanks for the nice words :)
Luckily phase alignment isn't necessary. I'm using a modified 802.11ac
protocol to do spacial-multiplexing MIMO (independent data on each
channel). This means that a known sequence is sent in the header to recover
phase across all channels.
Ah, that of course eliminates the need of alignment.
Good note about the relation between diversity gain and MIMO performance
for others. So far in an office environment I'm seeing good 4x4 diversity
gain (outdoors line-of-sight gives terrible performance because of lack of
multipath diversity) and from simulations I expect acceptable 8x8. Not sure
about 16x16 because there aren't many published results to compare against
and that's a large jump to extrapolate my multipath simulations.
I'm trying to understand the scenario here: If I get this correctly, you
try to detect the preamble of each TX stream at each RX stream, then use
that to phase-align them, and add them up in a maximum-ration-combining
mode?
That would sound like it should give you something like
[image: $C_\text{total} = B \log_2\left(1+\text{SNR}_\text{total}\right) =
B \log_2\left(1+f\left(\text{SINR}1,\dots,\text{SINR}{16}\right)\right)$]
,
bearing the question how [image: $\text{SINR}_i$] behaves for growing i?
Assuming we sort the receive streams by their preamble SINR, can you achive
at least Selection Combining's [image: $\text{SINR}_i = \frac1i}$]?
Yes, the X3x0 line work great for MIMO. Ettus was nice enough to loan me
two of them a year ago. They are awesome radios but are outside my budget
for the time being.
I hadn't even considered the B210. Great suggestion!
B210 thoughts:
- The Spartan-6 FPGA looks like it has enough block ram to buffer the
received signal even if I completely choke the PC/USB3 with a large MIMO.
Not sure if increasing the buffer size would require an FPGA mod, but
should be "easy".
FPGA mod; I can't really tell you how easy this will be.
- Good to know that the PPS doesn't need to be per-second.
Yes; I stumbled upon this when a physicist asked me how to trigger
"recording" on an external pulse. You just issue a stream command in the
far future at time t, and then define that t should be loaded into the
timekeeping register on a PPS edge. I'm not quite sure this would ever
become an "official" way of doing things, but it's a hack for these devices
where that works.
- Lack of RF filter-bank is unfortunate, but the reduced cost needs to
come from somewhere.
Really really depends on your environment; for research, that's more often
than not OK. If it's not, external filtering might be inflexible, but cheap.
- For this sort of MIMO I don't expect the ~3dB difference in noise-figure
to matter because I'm basically jamming myself with the overlapped signals.
Should I expect any problems with the uhd::multi_usrp timed-commands on
the B210? Double checking because of some of the replied comments.
Documentation states that timed-commands work so I'm assuming they were
just warning that USB3 will lag with high MIMO data rates. With my
non-realtime application I presume I can just make the burst small enough
to fit in the FPGA buffer and then set the timed-command far enough in the
future to negate any lag issues.
Yes. First of all, UHD doesn't support bundling multiple B2x0 devices
under one multi_usrp object at the moment. This means you will have to
maintain one multi_usrp per B210, and one rx_streamer/tx_streamer, too.
Also, timed commands only exist in the FPGA, so you can do anything that's
purely digital (ie. starting/stopping sampling, retuning the DSP), but
things that have to be communicated to the AD9361 (gain setting, retuning
the LO) will just happen "instantly".
Best regards,
Marcus
[ jonathan hedstrom ]
On Thu, Aug 20, 2015 at 7:05 AM, Marcus Müller <usrp-users@lists.ettus.com
wrote:
Hi Jason,
On 20.08.2015 13:55, Jason Matusiak via USRP-users wrote:
I assume that with the proper
daughter-card, there is no reason something like the X310 couldn't work,
right (I know that that is much more costly than the OP was hoping for)?
in fact, the X3x0, with its two inherently time- and frequency aligned
daughterboard slots, was made with MIMO in mind, so yes, that's possible.
Unlike the B210, where that is complicated due to USB/control issues,
multiple X3x0 devices can be used in a single uhd::multi_usrp object,
making alignment even easier, and allowing you to recv() in arbitrarily
many channels at once.
Also, as Jonathan illustrated by using the maximum sample rate possible
over Gigabit ethernet, MIMO mostly plays a role in high-bandwidth channels
[1], so going for high rates makes a lot of sense. B210 is a good
compromise between cost and rate here, but again, the limit is the USB
hardware in your host computer.
Best regards,
Marcus
[1] for MIMO to be an improvement, i.e. for diversity gain, you'll need
the chance that your observations be independent of each other -- if you
observe your channel with a small sampling rate, you would not notice e.g.
multipath components that are [image: $\le \frac1{f_\text{sample}}$] of
each other.
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
