Changed to null source, the rate is still around twice the sample rate
(390.625k) for throttle block.

******* MESSAGE DEBUG PRINT ********
(((rate_now . 781360) (rate_avg . 786529)))
************************************

When the throttle block is bypassed, the rate jumps up to around 11.3MS/s.

******* MESSAGE DEBUG PRINT ********
(((rate_now . 1.16071e+07) (rate_avg . 1.12848e+07)))
************************************

The rate is similar to using file source, 0.78MS/s with throttle and
11.3MS/s when throttle bypassed.

Rui

On Wed, Aug 2, 2017 at 10:37 AM, Marcus Müller <muel...@kit.edu> wrote:

> Ok, there's something fishy here. That rate (without the USRP Sink) is
> ridiculously low. Can you replace the file_source with a null_source? That
> way, we can rule out storage as the bottleneck.
>
> The probe_rate does nothing but just count how many items fly by, and then
> send a message at its output port every update period. The message_debug
> just prints messages.
>
> If it's not storage: are you perhaps running in a powersaver mode? Even
> so, the rate would be too low. I really don't know what's going wrong here.
> Run your flow graph, run "top" in a terminal, check that the python process
> and its spawned child threads really consume most of the CPU. If that's not
> the case, you've got something else eating away on your CPU.
>
> Best regards,
>
> Marcus
>
> On 08/02/2017 04:22 PM, Rui ZOU wrote:
>
> 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.
>
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL*******
> 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> 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> 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> 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/gnuradi
>>>> o/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> 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 
>>>>> listDiscuss-gnuradio@gnu.orghttps://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