Error Compiling Multimon

I am running gnuradio 3.7.0 and been using grc with good results. When I
try to make Multimon (recent trunk) I get the following errors:

trunk # make
/usr/local/bin/grcc -d . multimode.grc

Error: Block key “gr_complex_to_real” not found in Platform -
grc(GNU Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

Error: Block key “gr_keep_one_in_n” not found in Platform - grc(GNU
Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

Error: Block key “gr_feedforward_agc_cc” not found in Platform -
grc(GNU Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

Error: Block key “gr_keep_one_in_n” not found in Platform - grc(GNU
Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

Error: Block key “gr_keep_one_in_n” not found in Platform - grc(GNU
Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

Error: Block key “gr_fft_filter_xxx” not found in Platform -
grc(GNU Radio Companion)
Traceback (most recent call last):
File “/usr/local/bin/grcc”, line 25, in
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

[continuation of errors snipped]

Any ideas as to how to address?

On 09/11/2013 08:51 PM, John wrote:

ImportError: No module named grc.python.Platform
from grc.python.Platform import Platform
File “/usr/local/bin/grcc”, line 25, in

Any ideas as to how to address?


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Multimode hasn’t been converted to 3.7 yet.


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

On 09/11/13 20:02, Marcus D. Leech wrote:

Multimode hasn’t been converted to 3.7 yet.

Thanks!

I have heard good things about how it handles nbfm and wanted to compare
it to what I have hacked together. I have been reviewing examples of
nbfm demodulation and would appreciate any pointers to “ideal” approach
in this area.

John

On 09/11/13 20:14, Marcus D. Leech wrote:

You can pull the .grc into gnuradio-companion, although that might not
work out that well, since the block-names changed across 3.7.

When I do this a large percentage of blocks/connectors do mot render.

In a separate thread I can present what I have so far to get some input.

On 09/11/2013 09:12 PM, John wrote:

John


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
You can pull the .grc into gnuradio-companion, although that might not
work out that well, since the block-names changed across 3.7.


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On 09/13/13 22:21, John wrote:

I cannot see where “mh” should be brought into the flow graph. There
may be other errors bu this one appears pretty common on initial look.

This issue can be ignored. I was so focused on editing the file I
ignored the part where I needed to set PYTHONPATH. After I followed the
instructions in make install it worked.

John

On 09/12/13 08:41, Tom R. wrote:

[snip]

There are a few ways you can go about fixing it. The easiest would be
to have a version of 3.6.5.1 installed on your system. When you open
up your .grc file, look for any block with “(old)” in the name. Those
are blocks that will disappear in 3.7. You can just find the new
version of that block (same name without the “(old)”) and replace it.
When you then open the newly saved grc file in 3.7, those blocks will
still be there.

[snip]

I have gone down this path and see the references to those with “(old)”
in the name. However, I also see some errors that need to be addressed
(search has not yielded anything yet). A typical one manifests itself
in something as simple as definition of samp_rate variable:

Param - Value(value):
Value “int(mh.get_good_rate(devinfo,srate))” cannot be evaluated:
name ‘mh’ is not defined

I cannot see where “mh” should be brought into the flow graph. There may
be other errors bu this one appears pretty common on initial look.

Thanks,

John

On Wed, Sep 11, 2013 at 9:21 PM, John [email protected] wrote:

On 09/11/13 20:14, Marcus D. Leech wrote:

You can pull the .grc into gnuradio-companion, although that might not
work out that well, since the block-names changed across 3.7.

When I do this a large percentage of blocks/connectors do mot render.

Yes, as Marcus said, a lot of names have changed in 3.7 so the same
blocks aren’t recognized from your .grc file.

There are a few ways you can go about fixing it. The easiest would be
to have a version of 3.6.5.1 installed on your system. When you open
up your .grc file, look for any block with “(old)” in the name. Those
are blocks that will disappear in 3.7. You can just find the new
version of that block (same name without the “(old)”) and replace it.
When you then open the newly saved grc file in 3.7, those blocks will
still be there.

You can also just edit the .grc. XML file yourself. Most of the
changes are from “gr.someblock” to “block.someblock” (or
“filter.someblock” or “analog.someblock”), but this way requires
either a lot of intimate knowledge about the new locations of blocks
or looking at each block and locating what the new block name and its
new location are.

In a separate thread I can present what I have so far to get some input.


Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

On Sat, Sep 14, 2013 at 8:15 AM, John [email protected] wrote:

name 'mh' is not defined

John

That’s great, John! Thanks for following up.


Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

On 09/12/13 09:16, Marcus L. wrote:

And Ill comment that if you *do* undertake that work, successfully, Id be happy to fold the results into the SVN code for multimode.

I am moving down the path but do not yet have something that is working.

What I have done:

  • Reverted back to 3.6.5.1 and loaded flow graph.
  • Took screen shots of overall flow graph including details of blocks I
    knew were a problem.
  • Changed blocks with (old) in name to new block.
  • Loaded low graph into 3.7.0
  • Had to set default for sc_list_str to 300 as there was error when
    default was block
  • Took a long break from working on this and came back to it probably
    forgetting important things.
  • The following blocks did not load into 3.7.0: osmocom source block
    and FM deemphasis. I had to add these back.
  • In 3.7 disabled the import firdes block as it threw and error and help
    file indicates it may not be needed.

I have a temp repository on github for my changes:

 https://github.com/john-/multimode-tmp

I will keep working through the errors I receive when executing the flow
graph.

John

Also note that I could not get Multimon to work in 3.6.5.1 prior to
making changes in 3.7 (although it didn’t work differently). On the
premise that was issue with my install of that version I did not work
through resolving those issues.

On 10/05/2013 12:57 PM, John wrote:

I knew were a problem.

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

You should work with [email protected]valid who has also made an attempt
to get it working under 3.7.

His attempt comes up, but “stalls” after a few seconds, and then just
gets continuous “O”. Curiously enough, Andrew’s port of simple_fm_rcv
to 3.7 went swimmingly well. Not sure what’s going on.

Indeed that “import firdes” in the “helper” .py hasn’t been necessary
for a long time, and was just a bit of detritus.

The osmocom sources changed across 3.6->3.7 boundary, so you have to
re-instantiate in 3.7, and hopefully replicate what was in 3.6


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

On 10/05/2013 02:14 PM, John wrote:

This is how it behaved for me under 3.6.5.1.
Hmmm, that’s interesting.

I haven’t run multimode for a few weeks, and I’m not certain that I
tested it after I personally upgraded to 3.6.5.1.

Darn.

The osmocom sources changed across 3.6->3.7 boundary, so you have to
re-instantiate in 3.7, and hopefully replicate what was in 3.6


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

On 10/05/13 12:22, Marcus D. Leech wrote:

You should work with [email protected] who has also made an attempt
to get it working under 3.7.

I will do that.

His attempt comes up, but “stalls” after a few seconds, and then just
gets continuous “O”.

This is how it behaved for me under 3.6.5.1.

Curiously enough, Andrew’s port of simple_fm_rcv

to 3.7 went swimmingly well. Not sure what’s going on.

Indeed that “import firdes” in the “helper” .py hasn’t been necessary
for a long time, and was just a bit of detritus.

Thanks for confirmation.

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