Not sure if the debug setup is the expected
since it's the first time I use the 'Probe
Rate' and 'Message Debug' blocks whose
functions are not very clear to me now just
after reading the contents under the
document tag. If there are other ways to
learn about new blocks, please advise.
The rates I get when the USRP Sink disabled
is around 0.78MS/s I guess from the debug
output, shown below.
******* MESSAGE DEBUG PRINT ********
(((rate_now . 782916) (rate_avg . 784937)))
************************************
After enabling the USRP Sink, I got lots of
'L's and 2.4MS/s, shown below.
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL*******
MESSAGE DEBUG PRINT ********
(((rate_now . 2.36319e+06) (rate_avg .
2.36319e+06)))
************************************
GRC and python files are attached.
Rui
On Wed, Aug 2, 2017 at 3:57 AM, Marcus
Müller <muel...@kit.edu
<mailto:muel...@kit.edu>> wrote:
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>
