Forum: GNU Radio Making a transparent block for throughput measurement

I'm trying to measure the throughput of my flow graph. In order to 
accomplish this, I'm creating a transparent float block and then 
measuring the btyes/second that is going through the block. 
Unfortunately, my block is not acting transparently. I'm getting strange 
distortion when doing AM demodulation.

Below is my grextras code:
  Is there something that I am missing?

----------
class emptyBlock(gr.block):
    def __init__(self, args):
        gr.block.__init__(self, name="empty", in_sig=[float32], 
out_sig=[float32])

    def work(self, input_items, output_items):
        in0 = input_items[0]
        out = output_items[0]
        out[:]=in0
        self.consume(0, len(in0))
        return len(out)

On Tue, Dec 11, 2012 at 07:00:42PM -0500, Tommy Tracy II wrote:
> I'm trying to measure the throughput of my flow graph. In order to accomplish 
this, I'm creating a transparent float block and then measuring the btyes/second 
that is going through the block. Unfortunately, my block is not acting 
transparently. I'm getting strange distortion when doing AM demodulation.

Try without self.consume(); grextras using auto_consuming in sync
blocks, although I don't know what happens if you do call it (my
hypothesis is that if I'm right, your audio should sound choppy).

MB

PS: Or is this the omninous Bugsquatch people have been talking about?


>         in0 = input_items[0]
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Wed, Dec 12, 2012 at 2:54 AM, Martin Braun (CEL) 
<martin.braun@kit.edu>wrote:

>
> MB
>
> PS: Or is this the omninous Bugsquatch people have been talking about?


Sorry, what?

Tom

On 12/12/2012 01:54 AM, Martin Braun (CEL) wrote:
>
> MB
>
> PS: Or is this the omninous Bugsquatch people have been talking
> about?
>

In this case, i think its just the autoconsume in action. Not
Bugsquatch this time...

-josh

Thank you. It worked! Unfortunately, it slowed down my flowgraph from ~6 
seconds to 145 seconds.

The only difference between the two programs is in the connections:
----------
  self.connect((self.gr_wavfile_source_0, 0), (emptyBlock0,0))
        self.connect((emptyBlock0,0), (self.band_pass_filter_0, 0))
----------
which was originally:
----------
  self.connect((self.gr_wavfile_source_0,0), 
(self.band_pass_filter_0,0))
----------
Below is the emptyBlock code:
----------
class emptyBlock(gr.block):
    def __init__(self, args):
        gr.block.__init__(self, name="empty", in_sig=[float32], 
out_sig=[float32])

    def work(self, input_items, output_items):
        output_items[0][:]=input_items[0]
        return len(output_items[0])
----------

Thanks again!
Tom Tracy II
      UVA

Dataflow through Python is unpleasantly sluggish.

On 12 Dec 2012
10:53, Tommy Tracy II wrote:

> Thank you. It worked! Unfortunately, it
slowed down my flowgraph from ~6 seconds to 145 seconds.

On Wed, Dec 12, 2012 at 10:55 AM, <mleech@ripnet.com> wrote:

> **
>
> Dataflow through Python is unpleasantly sluggish.
>

Yes. Writing blocks in Python is not at all recommended except in the
development stage. Once you know how your block works
mathematically/algorithmically/logically, move it over to a C++ block.

Tom

On 12 Dec 2012 10:59, Tom Rondeau wrote:

> On Wed, Dec 12, 2012 at
10:55 AM, <mleech@ripnet.com [1]> wrote:
>
>> Dataflow through Python
is unpleasantly sluggish.
>
> Yes. Writing blocks in Python is not at
all recommended except in the development stage. Once you know how your
block works mathematically/algorithmically/logically, move it over to a
C++ block.
>
> Tom

Processing on low-sample-rate stuff is also fine.
I do that in my meteor-detector, since I'm only processing about 200sps,
although not using the gr-extras mechanism.



Links: