Costas parameter in DPSK2 grc block not in .py?

When I try to use the DPSK2 demod block in grc, I get the below error.
The
issue seems to be that the grc block has different arguments than
dqpsk2_demod() in dqpsk2.py (see below). Am I missing something here? I
am
using the gnuradio version 3.3.0.

Thanks,
Ben

===========
(GRC ERROR)
Traceback (most recent call last):
File
“/gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py”,
line
211, in
tb = usrp_rx_dpsk()
File
“/gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py”,
line
125, in init
sync_out=True,
TypeError: init() got an unexpected keyword argument ‘costas_alpha’

=============
(BLK2_DXPSK2_DEMOD.XML)

DPSK2 Demod
blks2_dxpsk2_demod
from gnuradio import blks2
blks2.$(type)2_demod(
samples_per_symbol=$samples_per_symbol,
excess_bw=$excess_bw,
costas_alpha=$costas_alpha,
timing_alpha=$timing_alpha,
timing_max_dev=$timing_max_dev,
gray_code=$gray_code,
verbose=$verbose,
log=$log,
sync_out=$sync_out,

=============
(DQPSK2.PY)
class dqpsk2_demod(gr.hier_block2):
def init(self,
samples_per_symbol=_def_samples_per_symbol,
excess_bw=_def_excess_bw,
freq_alpha=_def_freq_alpha,
phase_alpha=_def_phase_alpha,
timing_alpha=_def_timing_alpha,
timing_max_dev=_def_timing_max_dev,
gray_code=_def_gray_code,
verbose=_def_verbose,
log=_def_log,
sync_out=False):

diff attached

It looks like the guts of the dqpsk2 demod changed but the grc file was
not updated. I vote for keeping the grc files with the python/c++
source.

-Josh

On Mon, Oct 18, 2010 at 5:53 PM, Josh B. [email protected] wrote:

diff attached

It looks like the guts of the dqpsk2 demod changed but the grc file was not
updated. I vote for keeping the grc files with the python/c++ source.

-Josh

There’s an argument to be made for this. It’ll go into the thinking
about the refactoring of the code.

There is also the concept of using SWIG’s XML output for the GRC
files. I’ve only played around a bit with them, but it’s something to
look into if you haven’t already. It looks like it captures most of
the information about the blocks that is exposed in the GRC xml files.
It’s fairly expressive output, so we’d have to see if it actually
covers everything necessary for GRC to use with updated parsing.

Have you already looked at, and dismissed, this, Josh?

Tom

There’s an argument to be made for this. It’ll go into the thinking
about the refactoring of the code.

blks2impl must be burned

I think the structure in the gr-noaa directory is a good example of how
to organize a set of related blocks and applications.

There is also the concept of using SWIG’s XML output for the GRC
files. I’ve only played around a bit with them, but it’s something to
look into if you haven’t already. It looks like it captures most of
the information about the blocks that is exposed in the GRC xml files.
It’s fairly expressive output, so we’d have to see if it actually
covers everything necessary for GRC to use with updated parsing.

Have you already looked at, and dismissed, this, Josh?

I have not looked at nor have I dismissed the possibility. There are
certain visually appealing things you can do like hiding parameters that
dont matter when another parameter is set, or grouping two similar
blocks that have different outputs. I believe that there is no general
abstraction on how to do this and that generated xml files will be
somewhat lacking. That said, maybe generating the xml files might be
useful for enough of the blocks that its worth figuring out. Maybe we
can have a middle ground and find a way to generate the xml and leave a
place to get extra block specific information into the generator.

Basically, I will take a look at the SWIG XML when I get the chance.

-Josh

On 10/19/2010 05:45 PM, Josh B. wrote:

There is also the concept of using SWIG’s XML output for the GRC
certain visually appealing things you can do like hiding parameters

-Josh

I think having the XML generated automatically (mostly) from the
underlying SWIG/C++ is a very nifty idea. But I think I agree with Josh
that
some of the semantics are going to need to be “grafted in”
post-facto. Unless we can come up with some clever way of deriving
those
semantics from the underlying C++ code.

But moving towards a single, “de facto” location for all of this, and
having the rest be derived by an automated build-time process would be
sweet.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs