Migrating flowgraphs from GR 3.7 to 3.8: Two problems

[Chad Spooner]

All:

Thanks to Derek Kozel and Cinaed Simson for helping me to compile gnuradio 3.8.1.0 under Ubuntu 18.04.5.

I've been trying to migrate my flowgraphs from 3.7 to 3.8 with much success, but I have two stubborn problems I can't solve.

1. For the attached flowgraph csp_fsm_live_data.grc, I've created multiple hier blocks and strung them together to produce a block-oriented signal processor. All the heir blocks get the parameter 'block_size' and I also use 'block_size' as the vector length in some vector blocks of GRC. All of this worked fine in GR 3.7. I could change the block_size parameter in csp_fsm_live_data.grc and the processing would reflect the change correctly.

In 3.8, the flowgraph will operate correctly only if the block_size parameter in csp_fsm_live_data.grc matches the default block_size parameter in the various heirblocks. When I change block_size, I end up with an error involving the final connection of some of the heir blocks to QT Vector Sink Blocks. When all is well (block_size matches default in all heir blocks), the relevant portion of the flowgraph looks like this:

and when I change it from the default of 65536 to 32768, it looks like this:

The only errors reported by the companion are related to the red connection arrows:

I can't figure out where the '262144' and '131072' numbers are coming from. They are multiples of two times the block_size of 32768 of course, but I can't see how they are used or are relevant.

2. Another flowgraph, bank_of_dsss_gens_sleuth.grc (also attached), generates various DSSS-like signals and switches between them using the Stream Mux block. The output of the GR 3.8 version appears to be correct, but the flowgraph does not run for very long before overwhelming the companion and forcing me to kill it. I get the warning that gnuradio-companion has become unresponsive (wait or force stop). Looking at top while I run it, it does not use more than about 2.5 of my 8 cores. This flowgraph also ran very well (indefinitely) in GR 3.7 on the same hardware (computer) running the same OS. I get the feeling there has been some kind of relevant change to the use of multiple threads, but I can't figure out how to convince the companion to use as much CPU as it needs to (as it did before).

    C
-- 
Chad M. Spooner, PhD
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
cmspooner@nwra.com
831 582 4904
cyclostationary.blog

csp_fsm_live_data.grc
Description: Text document

bank_of_dsss_gens_sleuth.grc
Description: Text document

smime.p7s
Description: S/MIME Cryptographic Signature