允许最大吞吐量的网络数据包

网络工程 协议论 包分析 数据包丢失 数据 收发器
2022-02-10 04:06:23

我在两个微控制器之间创建了一个基本的无线系统。每个都使用片上 UART 和 HM-TRP 无线电模块相互通信。最终我会有一个主从设置,其中许多系统是从属系统,一个是主系统,但我总共不会超过 40 个单元。

我的点子

我的数据包格式基本上是 16 字节长,和 UDP 数据包类似,但在以下方面有所不同:

1st byte is an 8-bit address of the local machine.
2nd byte is an 8-bit address of the remote machine.
3rd byte through 15th byte is data
16th byte is 8-bit CRC checksum of all previous bytes.

使用此设置,如果任何硬件无法及时接收任何字节的数据,则可能会出现很大的延迟。我会用数据来解释。

假设主机 (ID #34) 以正确的格式多次向从机 (ID #12) 发送完整数据,并假设 FE 是正确的校验和。例子:

12 34 01 02 03 04 05 06 07 08 09 10 11 12 13 FE

现在,如果从机打开并且在整个数据包之前没有收到任何内容并且连接非常好,那就没有问题了。但是假设接收器由于网络(无线)错误而没有收到前两个字节。然后它收到:

01 02 03 04 05 06 07 08 09 10 11 12 13 FE 12 34

由于我的数据包格式将前 2 个字节视为机器地址,将后面的 13 个字节视为数据,因此接收器将丢弃上述数据,因为它选择了 34 作为校验和,而不是预期的 FE 值。

我的新想法

因为我正在使用的机器少于 128 台,所以我想从每个数据字节中剥离一个位并将数据拟合到剩余的 7 位中,然后使用剩余的位作为标志来指示数据的开始。这是一个二进制示例:

0mmmmmmm 1rrrrrrr 1ddddddd 1ddddddd 1ddddddd ..... 1ddddddd 1ccccccc

其中 m 是二进制的本地地址,r 是远程地址,d 是数据,c 是校验和。

我看到这种方法的优点是接收器知道在接收到 0 作为最高有效位之前不会开始任何事情。

问题是,这些格式中的哪一种最适合通过这种链路进行有保证的无线传输,为什么?如果我描述的格式不是最好的,那么哪种格式更好?

请记住,我正在使用 8 位微控制器(特别是芯片 AT89C2051),所以我的资源非常有限。

2个回答

正如 Martin 在评论中提到的,考虑使用 SLIP 来解决您的框架问题。 https://www.rfc-editor.org/rfc/rfc1055

这很简单,并且可以阻止您重新发明轮子。空闲时发送的优化END也可以解决许多问题。尽管它是“非标准”的,但它的实施非常广泛,例如在 Cisco 设备上,因此如果您选择在以后选择将您的项目与标准网络集成,那么您也有办法将其与标准网络集成。

基本上,您将无线通道用作 8 位并行通道,使用微控制器中固有的某种编码。您看到的问题是您无法检测到框架的开始或对齐位置。

有效的方法是在物理层上解决这个问题(您主要描述的是链路层)。显然,已经有一个无线符号指示字节开始(在硬件编解码器或您正在使用的库中),因此您不必担心字节对齐。如果物理层可以额外提供帧开始指示/符号,那将是一个有效的解决方案。

如果您坚持使用没有额外符号的固有字节大小的通道,则需要使用它来编码帧的开始。基本上,您需要使用不显示为用户数据的序列。这可以是特殊的位组合(如您所建议的)或字节序列。您需要分析您期望(并允许)作为用户数据的数据,以找到不会产生太多开销的序列。如果您一直在传输 7 位数据,则​​ HSB 标志是一个不错的选择。如果您需要 8 位宽度,它将产生 12.5% 的开销,这并不小。

您最好使用用户数据中不存在或非常罕见的特殊字节作为开始帧。然后,用户数据中的相同字节必须以一种在完整帧的情况下提供轻松解码并在部分帧的情况下被检测到的方式进行转义。

根据您的性能要求,您可能需要增加帧大小和 CRC 大小以使其可行。对于较大的帧大小,您可以使用带有用户数据长度指示的适当标头,从而解决转义问题。

使用已提议的 SLIP 将需要对 SLIP 进行一些扩展,该扩展不能很好地处理部分帧和丢失字节。