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

Reply via email to