GnuRadio tcp_sink数据值是乱码

Question

我正在为一个同事开发的GNU无线电应用程序开发一个web前端。

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

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

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

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

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

我将在GNU Radio中描述前D路径，因为它更短，但我在后D路径上看到了同样的问题，其中添加了一个WBFM Receive和一个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会显示错误)，但我找不到在流的另一端正确解码数据的方法。

Answer 1

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

请参阅https://en.wikipedia.org/wiki/Endianness

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

还要注意: Sun Microsystems制造了big-endian原生字节顺序计算机(在此基础上进行了大量的Internet协议开发)。

令我惊讶的是，之前的答案这么长时间没有关于网络字节顺序与本机字节顺序的课程。

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

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

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

from sys import byteorder
byteorder

结果将是“小”或“大”

Answer 2

无论你发送的是什么类型的浮点数，当字节在网络上传输时，它们可能会以低位字节顺序排序。我在udp连接上也遇到过类似的问题，我在客户端通过解析浮点数解决了这个问题。