tcp - GnuRadio tcp_sink 数据值乱码

Question

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

我有一个 TCP 客户端连接到两个 TCP Sink block 的输出，但数据编码与我预期的不同。

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

我通过将每个 4 字节 block 读取为 float32 值来在客户端解码数据。服务器和客户端都是小端系统，但我也尝试了字节交换(使用GNU Radio Endian Swap block ，也在客户端手动)，数据仍然不对。实际上情况更糟，确认没有字节顺序不匹配。

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

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

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

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 会显示错误)，但我找不到在流的另一端正确解码数据的方法.

Answer 1

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

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

已经提到协议(protocol)的网络顺序是大端，这实际上并没有说明网络有效负载本身的字节顺序。

另请注意:Sun Microsystems 制造了 big-endian native 字节顺序计算机(许多 Internet 协议(protocol)开发都基于此完成)。

令我惊讶的是，之前的答案竟然这么长，却没有关于网络 字节顺序与 native 字节顺序的类(class)。

GNURadio 似乎假定来自 UDP 源 block 的 native 字节顺序。

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

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

from sys import byteorder
byteorder

结果将是“小”或“大”