【问题标题】:GRC Throttle Block inclusion causes errorGRC Throttle Block 包含导致错误
【发布时间】:2022-01-23 08:17:30
【问题描述】:

此 GRC 应用程序中的顶部嵌入式 Python 块是 stock 块。底部是 LPF,代码如下。

如果没有油门块,应用程序可以正常工作。使用油门块会生成错误gr::log :ERROR: thread_body_wrapper - ERROR thread[thread-per-block[2]: <block Embedded Python Block 2(3)>]: ValueError: could not broadcast input array from shape (17,) into shape (16,)。当油门块在库存块的路径中时,不会出现这样的问题。

我正在学习 GRC,想了解为什么引入油门会导致问题。

import numpy as np
from gnuradio import gr


class blk(gr.sync_block):  # other base classes are basic_block, decim_block, interp_block
    """Embedded Python Block example - a simple multiply const"""

    h = np.array([0.0397989, -0.0488053, -0.0345932, 0.0659844, 0.0315417, -0.1074744, 
    -0.0299212, 0.3187633, 0.5294118, 0.3187633, -0.0299212, -0.1074744, 0.0315417, 
    0.0659844, -0.0345932, -0.0488053, 0.0397989], dtype=np.float32)

    a = True;

    def __init__(self, example_param=2.0):  # only default arguments here
        """arguments to this function show up as parameters in GRC"""
        gr.sync_block.__init__(
            self,
            name='Embedded Python Block 2',   # will show up in GRC
            in_sig=[np.float32],
            out_sig=[np.float32]
        )
        # if an attribute with the same name as a parameter is found,
        # a callback is registered (properties work, too).
        self.example_param = example_param

    def work(self, input_items, output_items):
        """Convolution of input with LPF coefficients"""
        output_items[0][:] = np.convolve(input_items[0], self.h, 'same')

        return len(output_items[0])

【问题讨论】:

    标签: python gnuradio gnuradio-companion


    【解决方案1】:

    首先,这是行不通的——卷积有内存,而你的卷积器不会保存它。这使得来自blk 的数字取决于传递输入信号的“块”类型。这是不行的,因为 GNU Radio 可以(并且将会)在任何时候使用不同的长度。 无论您的(无限或有限)输入流如何为对work 的单独调用进行分区,您的算法都必须以始终产生相同结果的方式编写。

    基本上就是这样——这里的问题似乎是您的np.convolve 调用的结果与output_itmes[0] 的长度不同。阅读documentation of numpy.convolve;它具体说明了发生这种情况的原因和时间:

    模式“相同”返回长度为 max(M, N) 的输出。边界效应仍然可见。

    因此,如果您获得的样本块比 h 短,那么您将尝试将 len(h) 项目保存在 len(output_items[0]) 大小的数组中,这太短了。

    这种情况总是会发生——如前所述,GNU Radio 需要将信号“切割”成碎片并将它们交给您的work,而这些块的长度是不固定的。你的油门只会让它更有可能发生。

    所以,你首先需要从概念上解决这在数学上不正确的事实(长信号的卷积与短子段的截断卷积序列不同,简单那样)。最有可能的答案是只使用 GNU Radio 附带的过滤器块之一。

    【讨论】:

    • (1 of 3) 我是 GNU Radio 的新手,感谢您的帮助。我正在尝试在 GNU Radio 中实现 DSP,以了解更多关于 DSP 的信息,而不是使用提供的过滤器块。我不清楚 GNU Radio 文档是如何从信号源到 Throttle 或我的嵌入式 Python 块进行分块的。我已经查看并找不到关于这些块如何来自源的描述。我确实理解卷积涉及记忆。我最初的代码块中有代码,即len(input_items[0]),它产生了一致的8,192
    • (2 of 3) 根据您的回复,我意识到我不明白数据“块”向量的格式。我不清楚 GNU Radio 文档是如何从信号源到 Throttle 或我的嵌入式 Python 块进行分块的。我已经查看并找不到关于这些块如何来自源的描述。我看到的文档讨论了如何使用 GRC 的标准工具,而不是如何创建工具。
    • (3 of 3) 嵌入式 Python 块和编写 C++ 块的信息清楚地表明用户工具是可能的。例如,我正在寻找有关块之间的虚线连接器的文档,但找不到解释。你能告诉我在哪里可以找到 GNU Radio 文档 1) GNU Radio 如何从源发送数据,并通常格式化数据; 2) 来自信号源的数据如何被“分块”或切割成碎片?感谢您的帮助和时间。
    • 再一次,无法保证它是一致的 8192。正如您所看到的,它不是。你只是不能影响它。分块是为了通过最大化并发来最大化系统吞吐量(至少在理论上)。 您的块无法改变这一点! 没有进行特殊的“格式化”:您只需从无限的样本流中获得一个接一个的有限长度向量。
    • 您的 (3 of 3) 是完全独立的问题!请在此处将它们作为新问题提出,而不是在 cmets 中回答。谢谢!
    猜你喜欢
    • 2015-12-22
    • 2012-04-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多