2

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

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

一种TCP Sink是发送复杂数据，另一种是发送浮点数据。

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

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

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

我将描述 GNU Radio 中的 pre-D 路径，因为它更短，但我在 post-D 路径上看到了同样的问题，其中添加了 aWBFM Receive和 a Rational Resampler，然后是一个Throttle块，然后是一个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 会显示错误），但我无法在流的另一端正确解码数据。

4

2 回答 2

1

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

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

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

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

我很惊讶之前的答案已经这么长了，没有关于网络字节顺序与本机字节顺序的课程。

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

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

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

from sys import byteorder
byteorder

结果将是“小”或“大”

于 2021-04-23T13:15:53.230 回答
0

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

于 2017-03-17T12:26:45.803 回答