Huh, I really don't know what's happening there :/ I sadly don't have
the USRP to test this live with me right now, but there's absolutely no
timed commands involved¹
So, trying to weed out bugs:
* I've replaced the USRP sink with a "Probe Rate" block, connected to a
"Message Debug"'s print port. I saw samples fly by with more than 7
MS/s, so there really shouldn't be a bottleneck here – can you try to do
the same and see whether your system can get similar rates? 7MS/s is
still far too little for my taste, but that is FM-Modulation-limited²
* Can you delete your subdev spec? in a 2-channel case, that should be
the implicit one, anyways.
Best regards,
Marcus
¹ "timed commands" are a USRP feature that allows certain things to
happen at well-defined times. You get an L when a timed command reaches
the USRP after the specified time has already passed. In your flow
graph, all that could happen is that a sample packet reaches the USRP
after it should – but that's unlikely, you'd get a "U" instead.
² at least on my machine, most of the time is spent in the FM modulator.
Which is kind of annoying, because looking into that, what costs most
time is the "keeping the phase within 0;2pi" floating point modulo
operation. I might get the urge to fix that.
On 08/01/2017 08:31 PM, Rui ZOU wrote:
Hi Marcus,
I have fixed the two parallel SISO by removing packeting encoding,
using QT GUI instead of WX. But the 'L' indicator still comes on, even
sooner than previous version. The GRC and generated python files are
attached.
Rui
On Tue, Aug 1, 2017 at 12:04 PM, Marcus Müller <muel...@kit.edu
<mailto:muel...@kit.edu>> wrote:
Ah, cool, but then I wouldn't start by packetizing data.
Simply send your file GMSK-Modulated; drop the packet encoding;
think about it: the MIMO coding (usually) happens *after* the data
has been formed to logical data units.
A few notes on your flowgraphs: Don't use the WX GUI elements in
new flowgraphs. We have deprecated them, since no-one can maintain
them, and the Qt GUI sinks have shown to be both more stable and
efficient. As far as I can foresee your application's needs, Qt
has replacements for all the WX visualizations you'd need.
For the receiver, I'd guess you'd first simply start by just
recording from to channels, and then experimenting with things
like cross-correlation, and estimating the channel matrix based on
your known transmit signal. I wouldn't be surprised if the channel
is rather boring in your setup – I blindly assume you're doing
this indoors, and that limits the path difference and the amount
of change (and hence, the delay spread and the doppler spread)
your signals are subject to, especially since your bandwidth is so
low. Of course, having a flat channel is nice :) but it also means
that it might be quite hard to get any actual MIMO gain, because
the two RX antennas might be very correlated. If in doubt,
increase bandwidth. Be agressive with roll-off / Bandwidth factors
of your GMSK.
Cheers,
Marcus
On 08/01/2017 05:51 PM, Rui ZOU wrote:
Hi Marcus,
My goal is to first build a 2-by-2 space multiplexing MIMO using
two X310s and GNU Radio. As I'm new to all this stuff, I'm
starting from building 2 parallel SISOs. If there are some good
kick-start materials or any resources, they will be very
valuable. Thanks.
Rui
On Tue, Aug 1, 2017 at 11:37 AM, Marcus Müller <muel...@kit.edu
<mailto:muel...@kit.edu>> wrote:
Hi Rui,
sorry, I might simply have missed those, and didn't find your
first email when I saw your recent one! I apologize.
So, hm, interestingly, we have a severe bug in the
packet_encoder block (its design is pretty bad, and that
triggers an unexpected behaviour underneath). That might mean
the packet_encoder is just consuming items as fast as it can,
without actually producing packets. In other words,
packet_encoder is broken; you can't use it right now.
The more appropriate way of dealing with data might be in the
example flowgraphs that you'd find under
/usr/[local/]share/doc/gnuradio/examples/digital/packet_loopback_hier.grc
; it's a lot more complicated, though, and you'd have to
write a message / PDU source that gives you the data you want
to transmit, rather than the Random PDU block!
I don't really know if that is the way to go. What is it,
that you want to build? Maybe the mailing list can advise?
Best regards,
Marcus
On 08/01/2017 05:26 PM, Rui ZOU wrote:
Here are the two flowgraphs I have used. I have tried to
attach the two files in my first email. Probably failed in
doing that. If still not seen, please let me know so I will
try again. Thanks for your help.
Running the first flow graph will cause GRC stop responding
instantly, while the second one can run for a little while
and produce lots of 'L' before going not responsive.
Rui
On Tue, Aug 1, 2017 at 11:09 AM, Marcus Müller
<muel...@kit.edu <mailto:muel...@kit.edu>> wrote:
Hi Rui,
don't know, to me, it looks like replying didn't work
out great, since my mail client showed your mail in a
new thread. Really, replying to a mailing list mail
should be nothing more than hitting the "reply" or
"reply all" button.
Anyway, even the slowest PC/laptop/Raspberry Pi/… I
could think of would be able to deal with these rates,
so there's very, very likely something wrong with the
GNU Radio flowgraph you're using. Maybe you'd want to
share that!
Best regards,
Marcus
On 08/01/2017 04:59 PM, Rui ZOU wrote:
Hi Marcus,
Sorry for leaving the title empty, that's the first
time to post to a mailing list. This is also the first
time to reply, no sure if I replied correctly.
I use 390.625k as the sampling rate because this is the
lowest I can get using the Ettus X310 without giving me
a warning saying that the sampling rate cannot be
provided by the hardware. The application is just
transmitting a file using GMSK modulation on the two
daughter boards of X310.
Rui
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
