date:20140731

[Discuss-gnuradio] AttributeError: 'module' object has no attribute "BLOCK NAME"

2014-07-31 Thread Simone Ciccia S210664

Hi at all,
I have some problem in running simulation of a block on gnuradio.
I have developed a simple block, .cc, .h, .i and .xml file attouched here.
All code is compile with success cmake/make/make install/ldconfig 
but when I place the block in gnuradio, running the simulation I get

Traceback (most recent call last):
  File "/home/simone/Scrivania/top_block.py", line 155, in 
tb = top_block()
  File "/home/simone/Scrivania/top_block.py", line 106, in __init__
self.agcs_newblock_0 = agcs.newblock()
AttributeError: 'module' object has no attribute 'newblock'

Who is related this error? 
Have I bad configured some file?
 

Thanks in advance,
Simone Ciccia#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Thu Jul 31 09:07:17 2014
##

from PyQt4 import Qt
from gnuradio import analog
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import agcs
import ieee802_11
import sip
import sys

class top_block(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "Top Block")
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
try:
 self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
 pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())


##
# Variables
##
self.samp_rate = samp_rate = 32000
self.AMPL = AMPL = 1

##
# Blocks
##
self._AMPL_tool_bar = Qt.QToolBar(self)
self._AMPL_tool_bar.addWidget(Qt.QLabel("AMPL"+": "))
self._AMPL_line_edit = Qt.QLineEdit(str(self.AMPL))
self._AMPL_tool_bar.addWidget(self._AMPL_line_edit)
self._AMPL_line_edit.returnPressed.connect(
	lambda: self.set_AMPL(eng_notation.str_to_num(self._AMPL_line_edit.text().toAscii(
self.top_layout.addWidget(self._AMPL_tool_bar)
self.qtgui_time_sink_x_0 = qtgui.time_sink_f(
	1024, #size
	samp_rate, #samp_rate
	"", #name
	2 #number of inputs
)
self.qtgui_time_sink_x_0.set_update_time(0.10)
self.qtgui_time_sink_x_0.set_y_axis(-1, 1)
self.qtgui_time_sink_x_0.enable_tags(-1, True)
self.qtgui_time_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, qtgui.TRIG_SLOPE_POS, 0.0, 0, 0, "")
self.qtgui_time_sink_x_0.enable_autoscale(False)

labels = ["", "", "", "", "",
  "", "", "", "", ""]
widths = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
  "magenta", "yellow", "dark red", "dark green", "blue"]
styles = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
markers = [-1, -1, -1, -1, -1,
   -1, -1, -1, -1, -1]
alphas = [1.0, 1.0, 1.0, 1.0, 1.0,
  1.0, 1.0, 1.0, 1.0, 1.0]

for i in xrange(2):
if len(labels[i]) == 0:
self.qtgui_time_sink_x_0.set_line_label(i, "Data {0}".format(i))
else:
self.qtgui_time_sink_x_0.set_line_label(i, labels[i])
self.qtgui_time_sink_x_0.set_line_width(i, widths[i])
self.qtgui_time_sink_x_0.set_line_color(i, colors[i])
self.qtgui_time_sink_x_0.set_line_style(i, styles[i])
self.qtgui_time_sink_x_0.set_line_marker(i, markers[i])
self.qtgui_time_sink_x_0.set_line_alpha(i, alphas[i])

self._qtgui_time_sink_x_0_win = sip.wrapinstance(self.qtgui_time_sink_x_0.pyqwidget(), Qt.QWidget)
self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
self.ieee802_11_moving_average_xx_0 = ieee802_11.moving_average_ff(48)
self.blocks_multiply_xx_0_0 = blocks.multiply_vff(1)
self.blocks_multiply_xx_0 = blocks.multiply_vff(1)
self.analog_sig_source_x_0 = analog.si

Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?

2014-07-31 Thread Martin Braun

Hm, interesting. You know, in this specific configuration, you don't
need a throttle. What happens if you leave it out? It shouldn't change
anything, but then, it should work in any case.

Also, you *are* letting the fg terminate itself, right?

M

On 07/31/2014 04:30 AM, Nguyễn Văn Lý wrote:
> Hi Martin,
> 
> Consider the following flow graph.
> File Source --->Throttle > Packet Encoder ---> Packet
> Decoder ->File Sink 2
>   \
>
>\---> File Sink 1
> If the File Source loads a small-size image (around 50 kB), then the
> Packet Decoder works properly and File Sink 2 can open the image.
> However if the File Source load a bigger image or video (9 MB, for
> example), then the File Sink 2 achieve only more than 1 MB, and it can
> only display a part of the image/video. This surprised me.
> 
> Then I added a File Sink right after the Packet Encoder (it's called
> File Sink 1) to see what happened after the Packet Encoder. If I let the
> Sample Rate = 32k, then the File Sink 1 receives more than 9 MB, but the
> File Sink 2 still receive more than 1 MB. If I let the Sample Rate be
> faster, 1M or 4M, then both the File Sink 1 and File Sink 2 only get
> more than 1MB.
> I wonder if something related to CPU got out of ability with high Sample
> Rate or Packet Encoder - Packet Decoder 
> 
> Best Regards,
> V-L
> 
> Van-Ly Nguyen,
> Signals and Systems of Laboratory - SSL  
> Faculty of Electronics and Telecommunications - FET 
> University of Engineering and Technology - UET  
> Vietnam National University, Hanoi - VNU  
> 
> Tel: (+84) 978 819 406
> 
> 
> 
> On Wed, Jul 30, 2014 at 9:19 PM, Martin Braun  > wrote:
> 
> On 07/30/2014 04:14 PM, Nguyễn Văn Lý wrote:
> > Thank you Tom,
> >
> > I found a note in documentation of the *Packet Encoder *block**
> where it
> > declares that the *Packet Encoder* is for use with the gnuradio
> > modulator blocks: GMSK, DPSK, QAM. I don't know why only these
> modulator
> > blocks are supported, but not some popular things like BPSK or QPSK.
> > Another thing is that my task requires the use of OFDM.
> 
> These should also work (they are basically subsets of QAM), but *you*
> have to make sure the absolute phase is correct *before* going into the
> packet decoder.
> 
> > Suppose now I have a simple flow graph as below:
> > File Source ---> Packet Encoder ---> Packet Decoder ->
> > File Sink
> > I wonder what types of file can be loaded and processed properly
> in the
> > *File Source* block (text, image, or video ...), and the same question
> > for the *File Sink* block :-)
> 
> Any file. The packet blocks really don't care about the contents.
> 
> M
> >
> > Thank you so much
> > Van-Ly
> >
> >
> > Van-Ly Nguyen,
> > Signals and Systems of Laboratory - SSL
> > Faculty of Electronics and Telecommunications - FET
> > University of Engineering and Technology - UET
> > Vietnam National University, Hanoi - VNU
> >
> > Tel: (+84) 978 819 406
> >
> >
> >
> > On Wed, Jul 30, 2014 at 8:24 PM, Tom Rondeau  
> > >> wrote:
> >
> > On Wed, Jul 30, 2014 at 4:44 AM, Nguyễn Văn Lý
> > mailto:lynguyenvan@gmail.com>
>  >> wrote:
> >
> > Hi all,
> >
> > Can anyone tell me what do *Packet Encoder* and *Packet
> Decoder*
> > blocks do? and it would be great if you can give me some
> example
> > :-)
> > Thanks in advance
> >
> > Van-Ly
> >
> >
> > These are very simple example blocks to show you how to packetize
> > data. Packet bytes go in, they get wrapped into a packet of a
> given
> > payload length with a header, access code, and preamble. The
> header
> > is just a 2x repetition of the payload length (16 bits for each
> > field). Leaving the preamble and access code blank just
> chooses the
> > defaults.
> >
> > The decoder just looks for the access code with the number of
> > available bits wrong. When it's found, it reads the header to get
> > the payload length, extracts the payload, and outputs the payload.
> >
> > Hope this helps.
> >
> > Tom
> >
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >

[Discuss-gnuradio] Slow down rate of Python source block

2014-07-31 Thread David Halls

Dear All,

I have a Python block that produces packets of size 1536 bytes. Due to various 
reasons, the latter parts of my flow graph are very slow (this is desired and 
cannot be changed). After producing 510 packets, I get the following error.

"handler caught exception: operands could not be broadcast together with shapes 
(1527) (1536)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 
55, in eval
try: self._callback()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 
160, in __gr_block_handle
) for i in self.__out_indexes],
  File "/usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py", line 198, in 
work
out_cA[0:len(cAm)] = cAm
ValueError: operands could not be broadcast together with shapes (1527) (1536)
thread[thread-per-block[1]: ]: caught unrecognized 
exception"

Debugging more carefully, I can see that:

len(cAm) =  1536 , len(out_cA) =  32768

for the first 490 packets, and then the length of 'out_cA' begins to reduce

packet_num =  490
len(cAm) =  1536 , len(out_cA) =  32247
packet_num =  491
len(cAm) =  1536 , len(out_cA) =  30711
packet_num =  492
len(cAm) =  1536 , len(out_cA) =  29175
packet_num =  493
len(cAm) =  1536 , len(out_cA) =  27639
packet_num =  494
len(cAm) =  1536 , len(out_cA) =  26103
packet_num =  495
len(cAm) =  1536 , len(out_cA) =  24567
packet_num =  496
len(cAm) =  1536 , len(out_cA) =  23031
packet_num =  497
len(cAm) =  1536 , len(out_cA) =  21495
packet_num =  498
len(cAm) =  1536 , len(out_cA) =  19959
packet_num =  499
len(cAm) =  1536 , len(out_cA) =  18423
packet_num =  500
len(cAm) =  1536 , len(out_cA) =  16887
packet_num =  501
len(cAm) =  1536 , len(out_cA) =  15351
packet_num =  502
len(cAm) =  1536 , len(out_cA) =  13815
packet_num =  503
len(cAm) =  1536 , len(out_cA) =  12279
packet_num =  504
len(cAm) =  1536 , len(out_cA) =  10743
packet_num =  505
len(cAm) =  1536 , len(out_cA) =  9207
packet_num =  506
len(cAm) =  1536 , len(out_cA) =  7671
packet_num =  507
len(cAm) =  1536 , len(out_cA) =  6135
packet_num =  508
len(cAm) =  1536 , len(out_cA) =  4599
packet_num =  509
len(cAm) =  1536 , len(out_cA) =  3063
packet_num =  510
len(cAm) =  1536 , len(out_cA) =  1527

I believe this is because the latter parts of the flow graph are blocking, 
their buffers become full, and this backs up to my source block. This is 
confirmed by connecting my source block to null sinks, which then allows the 
source block to run infinitely (well, a long while!).

Is there a way I can slow up this block? I tried using a throttle on the 
output, but this doesn't help (in fact it seems to make it worse!).

The full code of the block is attached.

Thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2014 <+YOU OR YOUR COMPANY+>.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 

import numpy
from gnuradio import gr
import os, sys, inspect
sys.path.insert(0,'/home/gnuradio/gnuradio_trlcode/gr-trl/examples/ofdm_bsld/Pfiles/LDPC_lib')
from rew import *
from LDPC_lib import *
import datetime as dt
import LDPC_dec_lib
import pmt
import time

class blsd_enc_b(gr.sync_block):
"""
docstring for block blsd_enc_b
"""
def __init__(self, kA1=4,kB1=4,k2=4,NA1=8,NB1=8,N2=8,M=8,num_packets=1):
gr.sync_block.__init__(self,
name="blsd_enc_b",
in_sig=None,
out_sig=[numpy.uint8,numpy.uint8,numpy.uint8,

Re: [Discuss-gnuradio] Slow down rate of Python source block

2014-07-31 Thread Tom Rondeau

On Thu, Jul 31, 2014 at 12:21 PM, David Halls 
wrote:

> Dear All,
>
> I have a Python block that produces packets of size 1536 bytes. Due to
> various reasons, the latter parts of my flow graph are very slow (this is
> desired and cannot be changed). After producing 510 packets, I get the
> following error.
>
> "handler caught exception: operands could not be broadcast together with
> shapes (1527) (1536)
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line
> 55, in eval
> try: self._callback()
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line
> 160, in __gr_block_handle
> ) for i in self.__out_indexes],
> File "/usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py", line 198,
> in work
> out_cA[0:len(cAm)] = cAm
> ValueError: operands could not be broadcast together with shapes (1527)
> (1536)
> thread[thread-per-block[1]: ]: caught unrecognized
> exception"
>
> Debugging more carefully, I can see that:
>
> len(cAm) = 1536 , len(out_cA) = 32768
>

Just a quick response without really studying the problem or your code. The
dynamic scheduler in GR is getting in your way, and the throttle block is
definitely not the right way to help you. You need to either tell the
scheduler what you need it to send your block or handle it internally.
There are three ways to solve these issues:

1. Use set_output_multiple in the constructor, which will only allow the
scheduler to send you chunks of data of some multiple of the number you
pass that. I've seen this slow down the scheduler in other situations, but
it sounds like you're going slow, anyways, so this shouldn't cause a
problem.

2. Make your input signature your packet_length so each item will be a
vector of that length. This would not be my preferred way, but we've played
that game before.

3. Handle it internally. Buffer up the input until you have enough to
produce what you need. You'd need to inherit from gr.basic_block here and
do more management of the data and buffers yourself.

Tom




> for the first 490 packets, and then the length of 'out_cA' begins to reduce
>
> packet_num = 490
> len(cAm) = 1536 , len(out_cA) = 32247
> packet_num = 491
> len(cAm) = 1536 , len(out_cA) = 30711
> packet_num = 492
> len(cAm) = 1536 , len(out_cA) = 29175
> packet_num = 493
> len(cAm) = 1536 , len(out_cA) = 27639
> packet_num = 494
> len(cAm) = 1536 , len(out_cA) = 26103
> packet_num = 495
> len(cAm) = 1536 , len(out_cA) = 24567
> packet_num = 496
> len(cAm) = 1536 , len(out_cA) = 23031
> packet_num = 497
> len(cAm) = 1536 , len(out_cA) = 21495
> packet_num = 498
> len(cAm) = 1536 , len(out_cA) = 19959
> packet_num = 499
> len(cAm) = 1536 , len(out_cA) = 18423
> packet_num = 500
> len(cAm) = 1536 , len(out_cA) = 16887
> packet_num = 501
> len(cAm) = 1536 , len(out_cA) = 15351
> packet_num = 502
> len(cAm) = 1536 , len(out_cA) = 13815
> packet_num = 503
> len(cAm) = 1536 , len(out_cA) = 12279
> packet_num = 504
> len(cAm) = 1536 , len(out_cA) = 10743
> packet_num = 505
> len(cAm) = 1536 , len(out_cA) = 9207
> packet_num = 506
> len(cAm) = 1536 , len(out_cA) = 7671
> packet_num = 507
> len(cAm) = 1536 , len(out_cA) = 6135
> packet_num = 508
> len(cAm) = 1536 , len(out_cA) = 4599
> packet_num = 509
> len(cAm) = 1536 , len(out_cA) = 3063
> packet_num = 510
> len(cAm) = 1536 , len(out_cA) = 1527
>
> I believe this is because the latter parts of the flow graph are blocking,
> their buffers become full, and this backs up to my source block. This is
> confirmed by connecting my source block to null sinks, which then allows
> the source block to run infinitely (well, a long while!).
>
> Is there a way I can slow up this block? I tried using a throttle on the
> output, but this doesn't help (in fact it seems to make it worse!).
>
> The full code of the block is attached.
>
> Thanks!
>
> David
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnurad

[Discuss-gnuradio] [GSoC] Co-Processors Update #8

2014-07-31 Thread Alfredo Muniz

Hello all,

Logistical:
- We still need a date for the coproc dev call. Fill this out
http://whenisgood.net/nbkn35s
- GSoC "pencils down" is August 18th or 2.5 weeks from now. Time. Flies.

Progress:
- Last week I successfully tested the turbo decoder using a DSP only
program. I figured out how I can best share the code without breaching any
license terms so I'll have that up this weekend.
- This week I was able to get shared memory working between the ARM and
DSP. Basically I create a contiguous buffer using CMEM on the ARM and get
its physical pointer. I pass the physical pointer to the DSP (no MMU) using
MessageQ and it can directly manipulate the buffer I created on the ARM.
Works well with a little test of assign value on ARM and read on DSP,
assign on DSP, read on ARM. Lot of annoyances but finally tweaked the right
knobs to get this working.
- Next step is to now pass the physical pointer containing the
log-likelihood ratios over to the DSP, and the DSP should be able to place
the hard decisions in another physical pointer address that I pass to it. I
can then test whether the resulting HDs match the expected HDs on the ARM.
Should have this working early next week.
- After that I'll be able to play around with getting data in and out of
GNU Radio so I can perform a full system integration test.

Things are moving!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] AttributeError: 'module' object has no attribute "BLOCK NAME"

Re: [Discuss-gnuradio] What do Packet Encoder and Packet Decoder do?

[Discuss-gnuradio] Slow down rate of Python source block

Re: [Discuss-gnuradio] Slow down rate of Python source block

[Discuss-gnuradio] [GSoC] Co-Processors Update #8

5 matches

Site Navigation

Mail list logo

Footer information