[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Errors of missing modulators in gnuradio-companio

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Errors of missing modulators in gnuradio-companion
Date: Wed, 26 Oct 2011 13:45:26 -0400

On Wed, Oct 26, 2011 at 11:10 AM, Paul M. Bendixen <address@hidden> wrote:
Compiling done.

So a grep for blocks that are only in digital in the grc files showed that mpsk_sync_cc and cvsd_decode and encode are still missing.

Oh, and a minor glitch: it seems that putting the blocks in gr-digital instead of gr-digital/grc made it disappear from grc's view (at least with the new build it's nowhere to be found).
During startup, the following warnings pop up:
Warning: Block key "digital_gmskmod_bc" not found when loading category tree.
Warning: Block key "digital_cpmmod_bc" not found when loading category tree.
Warning: Block key "digital_gmsk_mod" not found when loading category tree.
Warning: Block key "digital_gmsk_demod" not found when loading category tree.

cpmmod_bc however is in the right place, so I can't comment on that.


Yes, they are supposed to be in gr-digital/grc. That was just unbelievably stupid of me. This is why you should never commit before breakfast! I also didn't properly put these new ones into the Makefiles. 

This has been fixed. I was in a rush to get out the door this morning and wasn't thinking clearly. Was such a simple thing to do, too....


2011/10/26 Paul M. Bendixen <address@hidden>

Thanks, building now

Just one thing, shouldn't the xml files go into /gr-digital/grc/ like the other blocks instead of /gr-digital all by them selves?

Will get back to you on how it went.


2011/10/26 Tom Rondeau <address@hidden>
The master branch has been updated with the fixes to the GRC blocks.

Thanks again for the reports!


On Wed, Oct 26, 2011 at 7:55 AM, Tom Rondeau <address@hidden> wrote:
On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen <address@hidden> wrote:
Did a little more digging
cd [gitdir]/grc/
find . -name "*" | xargs grep digital

Returns nothing, on the other hand grepping blks2.gmsk_mod returns:
./Makefile.am: blks2_gmsk_mod.xml \
./block_tree.xml: <block>blks2_gmsk_mod</block>
./blks2_gmsk_mod.xml: <key>blks2_gmsk_mod</key>
./blks2_gmsk_mod.xml: <make>blks2.gmsk_mod(

Fixing these now. About to push the patch.

In other words: the XML structure of the grc that has to do with anything moved to digital must be updated, before 3.5 can be compared to a stable environment.

XML has never been my strong suit, so I won't start looking into it.
Furthermore some of the blocks have changed input parameters (e.g. gmsk_demod).

Perhaps merging next into master was a little premature?

Best regards

I don't think so at all. The problem is there are no automated test for this kind of stuff, and there's a lot of code that's of concern here. The only way we could get these kinds of error reports was to get the real users of GNU Radio to test them. These problems have been around in the old 'next' branch for a while, but without being used, there was no way for us to get these kinds of bug reports that is allowing us to fix them.

In other words, I really appreciate you checking these things out and reporting the errors. This is also why we have stable releases. For people who have environments where stability is a concern, they should stick with the releases. 

I went through and checked the GRC blocks against everything I moved into gr-digital, so hopefully there is nothing left that I missed. I wonder if we can make a piece of automatic test code that would try to load each of the GRC XML blocks and report an error if it can't be loaded properly?

Thanks! Let me know if you find anything else.


• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//

• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]