GnuRadio tcp_sink 数据值乱码答案

【问题标题】：GnuRadio tcp_sink data values are garbledGnuRadio tcp_sink 数据值乱码
【发布时间】：2023-03-25 07:06:02
【问题描述】：

我正在为同事开发的 GNU Radio 应用程序开发 Web 前端。

我有一个 TCP 客户端连接到两个 TCP Sink 块的输出，并且数据编码与我预期的不一样。

一个TCP Sink 发送复数数据，另一个发送浮点数据。

我在客户端通过将每个 4 字节块读取为 float32 值来解码数据。服务器和客户端都是 little-endian 系统，但我也尝试了字节交换（使用 GNU Radio Endian Swap 块并在客户端手动），但数据仍然不正确。其实更糟糕的是，确认没有字节顺序不匹配。

当我在 GNU Radio Companion 中使用适当的 GUI 元素执行流程图时，图表看起来是正确的。数据值按预期显示在 0 到 10 之间。

但是，在客户端解码的值通常在 0.00xxxxx 左右，并且该图看起来像噪音，而不是在 GNU Radio 中显示的简单音调。如果我通过乘以 1000 手动缩放数据，它看起来仍然像噪音。

我将描述 GNU Radio 中的 pre-D 路径，因为它更短，但我在 post-D 路径上看到了同样的问题，其中添加了 WBFM Receive 和 Rational Resampler，然后是 @987654327 @ 块，然后是 TCP Sink 块发送浮点数据。

File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).

这似乎是指定流参数的正确方法（如果我做出与流项目不匹配的更改，确实 Companion 会显示错误），但我无法在流的另一端正确解码数据.

【问题讨论】：

你为什么使用throttle 块，为什么还要使用两个？ Throttle 对您的信号完全没有。它只会减慢处理速度。您永远不应该将它们中的两个放在同一个示例路径中。
所以：首先是坏消息：GNU Radio 正在为 3.8 版本做准备，并且 TCP 接收器已被弃用并将被删除。所以你最好完全避免这些，特别是因为它们在很多方面都非常可怕（如果你邮寄讨论-gnuradio 邮件列表，我可以解释）。
但是：我不认为这是这里的问题。您的抽取因子是多少？
我通常建议切换到 GNU Radio 中更强大的 ZeroMQ 网络接收器，并在您的客户端中使用 ZeroMQ；它负责整个打包的事情，我认为这可能是这里的问题。
不，ZMQ 做 ZMQ，但老实说，PUB/SUB 或 REP/REQ（如果您的客户想要扮演“请求”数据的角色）并不过分——ZMQ 相当苗条，并且基本上只处理从 a 获取的数据，因此您不必弄乱 recv()/send() 处理。是的，整个接受的事情是这段代码的混乱之一（也是，它是 GRC 代码库的一部分，等等）

标签： tcp gnuradio gnuradio-companion

【解决方案1】：

“历史悠久的 RFC 1700（也称为 Internet 标准 STD 2）已将 Internet 协议套件中的协议的网络顺序定义为 big-endian ，因此使用术语“network byte order”来表示 big-endian字节顺序。”

见https://en.wikipedia.org/wiki/Endianness

提到了 protocols 的网络顺序是 big-endian，这实际上并没有说明网络负载本身的字节顺序。

另请注意：Sun Microsystems 制造了 big-endian 本机字节顺序计算机（在此基础上进行了大量 Internet 协议开发）。

我很惊讶之前的答案已经这么长时间没有关于 network 字节顺序与 native 字节顺序的课程。

GNURadio 似乎假定来自 UDP 源块的本机字节顺序。

检查 Help->Types of GNURadio Companion 中的数据类型颜色代码，橙色的“float”连接是 float32。

要验证计算机的本机字节顺序，在 Python 中，请执行以下操作：

from sys import byteorder
byteorder

结果将是“小”或“大”

【讨论】：

【解决方案2】：

无论您发送什么类型的浮点数，当字节进入网络时，它们都可能以小端序排列。我在 udp 连接上遇到了类似的问题，我通过在客户端将浮点数解析为小端来解决它。

【讨论】：