延迟与速率

低延迟 (10 Hz) 类型的 IoT 应用程序

这是一个概念错误。 延迟和速率在很大程度上是独立的。您可以拥有一个每秒记录数千个读数的系统，将它们存储在 SD 卡上，并且每月一次有人访问远程站点，提取卡并将其邮寄给您 - 该系统将具有很高的速率，但也非常延迟。或者，您可以拥有一个系统，该系统在读取读数后的几微秒内报告读数，但每小时仅读取一个读数。

因此，您需要做的第一件事是澄清您的要求 - 您是否需要获取大量数据，或者是否需要在数据仍然非常最新时获取它，或者两者兼而有之？

10 Hz 更新速率对于大多数数字传输方案来说是相对可行的，除了那些对每段时间的传输数量有监管限制的方案，或者那些具有如此低数据速率的方案（或者因为它们是窄带链路）效率，或者因为它们很粗糙），以至于它们无法足够快地移动您想要发送的数据量。

延迟与可靠性和复杂性

由于小区域的实际传播时间需要特殊电路来测量，对于本地无线电系统，移动消息所花费的时间基本上就是对其进行编码的时间长度 - 除非系统设计方面增加更多。需要对消息进行大量“考虑”的系统可能会增加延迟，尽管使用体面的软件可能会很轻微。需要每个消息多次来回“讨论”循环的方法必然会增加循环次数和链路或协议的任何周转时间。

但最可能的延迟来源是可靠性层——如果消息丢失或到达时损坏，系统应该怎么做？如果它再次尝试，那几乎总是意味着增加延迟，而如果它只是丢弃消息并继续前进，则可能意味着间隙。

对于您的应用程序，可能工作得很好的是一种不可靠的方案，但其中每个数据包不仅包括当前测量值，还包括几个先前测量值的重复（或对于计数应用程序，运行总数）。并且那些不一定需要是最近的测量值 - 根据干扰模式，最好的方案很容易最终成为当前、前一个、下一个前一个、第 5 个前一个、第 13 个前一个或其他任何东西，以便确实通过的数据包往往有很高的机会也包括没有通过的数据。

实用系统

如果组件之间有合理的视线或泄漏路径，许多现成的 2.4 GHz 系统可能会在您的示例中正常工作。

• nRF24L01 - 2.4 GHz 型数字无线电可以轻松处理数据速率，并且很容易用于制作相当低延迟的信道跳跃系统 - 例如，这些和它们的竞争对手用于交互飞行许多廉价的消费无人机。

• BTLE 具有状态复杂的模式，这可能会出现问题，但是广告模式足够简单，并且可以以您正在寻求的那种重复率运行。围绕嵌入式板构建的定制接收器应该能够跟上并为您提供每个数据包的完整详细信息。还有一些与智能手机的交叉兼容性，但是在这种情况下，主机操作系统可能只给你一小部分流量，并且可能不会在数据包内容发生变化时始终通知你。

• 当然还有很多其他的选择