Jeff:
Thanks for the tip on division. I can't find any division-related flaws.
The consistent thing about the errors from the companion is that the source vector length is always reported as the number of bytes in the hier block using the default parameter block_size inside the heir block, not the value of block_size that is actually specified in the csp_fsm_live_data.grc flowgraph. As I change block_size in that flowgraph, the reported vector size of the QT Vector Sink blocks changes accordingly (and correctly) in the error messages, but the reported vector size for my hier blocks is always equal to the size for the value of the block_size parameter inside the hier flowgraph.
It's as if the companion can't tell that the hier block is getting the parameters set in the main flowgraph. However, as you can see in the images below, the companion displays the block_size parameter correctly for each component of the flowgraph.
C
On 8/11/20 5:30 PM, Jeff Long wrote:
131072 is the number of bytes for 32768 float samples.
When numbers change going from 3.7 to 3.8, check Python division. The change in division operators (/ vs //) between Python2 and Python3 may change the result of Python expressions used in parameters.
On Tue, Aug 11, 2020 at 8:02 PM Chad Spooner <cmspooner@nwra.com> wrote:
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-- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspooner@nwra.com 831 582 4904 cyclostationary.blog
