Making a transparent block for throughput measurement

GNU Radio
1

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)
2

On Tue, Dec 11, 2012 at 07:00:42PM -0500, Tommy T. 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
[email protected]
Discuss-gnuradio Info Page

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

Dipl.-Ing. Martin B.
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

3

On Wed, Dec 12, 2012 at 2:54 AM, Martin B. (CEL)
[email protected]wrote:

MB

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

Sorry, what?

Tom

4

On 12/12/2012 01:54 AM, Martin B. (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

5

Dataflow through Python is unpleasantly sluggish.

On 12 Dec 2012
10:53, Tommy T. II wrote:

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

6

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

7

On Wed, Dec 12, 2012 at 10:55 AM, [email protected] 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

8

On 12 Dec 2012 10:59, Tom R. wrote:

On Wed, Dec 12, 2012 at
10:55 AM, <[email protected] [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: