【问题标题】:Is there a way to communicate reliably via Bluetooth?有没有办法通过蓝牙可靠地通信?
【发布时间】:2016-12-26 07:20:08
【问题描述】:

我必须在两台蓝牙设备之间交换数据,其中一台是 Android 设备。为简单起见,您可以假设其他设备将是运行 bluez 的通用 linux 设备,生成的数据类似于健身追踪器生成的数据。

该场景似乎是低功耗蓝牙的一个简单用例。我目前遇到的问题来自于通信必须是可靠的(以 TCP 可靠的方式可靠)。这意味着:

  • 没有损失
  • 没有数据损坏
  • 需要保留订单
  • 没有重复
  • 没有幻像包

虽然在链路层级别可以防止损失,但在使用 Low Energy 时似乎没有明确保留顺序(使用指示可能会实现这一点)。

没有对蓝牙做很多工作,我目前对选项的数量感到不知所措,同时似乎没有一个选项能很好地满足要求。

是否有在两个蓝牙设备之间建立可靠通信的“最佳实践”?低功耗蓝牙解决方案更可取,但不是强制性的。

【问题讨论】:

    标签: android bluetooth bluetooth-lowenergy android-bluetooth bluez


    【解决方案1】:

    BLE 使用 24 位 CRC。对于使用 BLE 传输的数据量,CRC 非常可靠并且损坏的可能性非常低(请注意,TCP CRC 是 16 位,以太网 CRC 是 32 位,请参阅http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html)。

    有线网络中的排序问题是通过不同路由将数据包路由到同一目的地的结果(请参阅If TCP is connection oriented why do packets follow different paths?)。这部分是由于使用了滑动窗口确认协议,该协议允许在确认之前传输许多数据包。在 BLE 中没有路由,确认方案是停止和等待 ARQ 方案的变体(2 位惰性确认),这意味着不可能在没有确认的情况下发送新数据包。这两个因素使得无序传输的可能性极小。

    【讨论】:

      【解决方案2】:

      一旦您的Bluetooth 连接设置为可靠。因此,您不必担心数据丢失或损坏。

      所以你担心的事情都可以在你身边轻松处理。在为您的BluetoothAdapter 设置BroadcastReceiver 时,您将获得正确的连接和断开回调。

      如果发生任何断开连接,您可能需要重新启动连接过程,一旦正确建立,您可以重新发送数据。

      我还不知道你的目的,但我需要在这里提到的一件事是,如果你长时间保持连接,我不推荐Bluetooth 通信。如果没有连续传输,某些设备会在一段时间后自动断开连接。

      【讨论】:

      • 我认为丢失或损坏不会是 BLE 的问题。我列出的其他要求呢?规范中没有任何内容可以确保保留数据包的顺序是吗?另外,如果我想防止重复和幻包,我必须自己实现这些要求?
      • order of packets will be preserved - 我也没有找到任何规格,但我也没有发现订购有任何问题。 prevent duplicates and phantom packets - 在通常情况下,没有数据丢失或损坏的可能性,您可能不必实施重复数据包策略。
      • 好的。这几乎是我在自己的研究中发现的。不完全是我所希望的,但我仍然接受这个答案,因为它是最有帮助的。
      • 祝您的研究顺利,请让大家知道您目前的发现。这对我来说将是一个很好的学习。 :)
      【解决方案3】:

      Android 的 BLE 堆栈与链路层规范一样好。因此,您可以在一个方向使用“无响应写入”,而在另一个方向使用通知。只需确保您的外围设备端不会丢弃传入的写入。

      【讨论】:

        【解决方案4】:

        Android 支持蓝牙,但它只允许从流中发送或接收数据。谷歌有一个非常好的示例项目:https://github.com/googlesamples/android-BluetoothChat。此示例的唯一缺点是它使用 Handler 来通知蓝牙事件。我对其进行了一些更改,因此它使用另一个线程并从中调用您设置的接口方法,看看项目:https://github.com/AlexShutov/LEDLights。这是普通的蓝牙,不是BLE,希望对你有帮助

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2021-09-06
          • 1970-01-01
          • 2016-07-29
          相关资源
          最近更新 更多