在“+++”时无法从 XBee 获得 OK 响应答案

【问题标题】：Can't get OK response from XBee upon "+++"在“+++”时无法从 XBee 获得 OK 响应
【发布时间】：2016-10-11 03:08:24
【问题描述】：

自过去三天以来，我一直在尝试设置两个 XBees 进行通信。 X-CTU 似乎是这样做的完美选择，但是，在串行端口上发现 XBees 时，它是一个真正的威胁。

我只靠运气检测到了一个 XBee，而另一个从未出现过。我什至更换了我的两个 XBees。我正在尝试找出替代方案，即使用串行控制台执行操作。在发出 +++ 时，我无法从设备收到 OK 响应。

由于我之前没有使用 PC 与 ESP8266 设备进行通信的良好体验，我试图通过使用 Arduino 的第二个串行端口发送此类配置消息并通过打印读取响应来找出解决方法在默认串行控制台上输出。

配置消息似乎也可能因设备模式而异。如果处于 API 模式，则必须以特定格式生成帧（为此我使用 X-CTU 帧生成器）。

为什么我在发出+++ 时无法收到 XBee 的响应？

这些设备是 Series 1 XBees，确切的部件号是 XB24-AWI-001。非常感谢任何帮助。

【问题讨论】：

你是否尊重+++前后的守卫时间？ IIRC是整整一秒；多一点伤不起。当然，它必须具有正确的波特率。您可以以不同的波特率执行序列。我构建了一个系统，可以通过测试两种波特率来处理 9600 的全新 Xbees 或 115200 的配置模块。（然后，全新的模块将在系统中进行配置，然后切换到 API 模式。）
" 我试图通过使用 Arduino 的第二个串行端口找出解决方法" -- 哪个 Arduino？您使用的是 5v 还是 3.3v 设备？

【解决方案1】：

您是否考虑过 XBee 处于 API 模式？也许您应该考虑在 AT 模式下重新刷新设备以开始使用它。

要测试它是否处于 API 模式，您可以参考指南，第 9 章了解 API 模式结构：

API模式下的数据报基本上都是以~开头的，它的构建方式如下：

[0x7E|length(2B)|Command(1B)|Payload(length-1B)|Checksum(1B)]

由于0x7E 在 ASCII 表中是 ~，您应该尝试在串行终端会话中键入一个伪造的数据报，例如：

~ <C-d> AAAA

注意：<C-d> 字符在 unix 下表示 Control-d，也就是 EOF 字符。

显然这样的消息不太可能起作用，您将收到要求您再次发送该数据报的回复。那是因为EOF字符是ASCII码4，这意味着数据报的长度是4字节。那么你发送四个虚假字节，校验和将是A，这很可能是正确的，并且接收者将假设传输已损坏。因此将再次询问数据报，这意味着您将收到一个数据报来执行该查询。

虽然我只能建议你考虑只在 API 模式下运行它（更可靠和更好的 API，但你不能玩弄它并通过用逻辑分析仪点击线路来了解发生了什么......尽管给出了足够的到时候，你会开始像阅读英文一样阅读 API 数据报 ☺)。

我写了一个页面，其中包含一些资源来检查如何重新刷新 XBees：

还有来自另一个完全不相关的项目的其他建议：

我还编写了一个库（针对 beaglebones，但您可以对其进行调整以供您使用）使用 XBees 处理 API 模式 2：

但我敢打赌，通过谷歌搜索，您可以找到比那些更广泛使用的库，甚至一些旨在在 Arduinos 上运行的库（注意：该库最初是为 Arduinos 编写的，然后适用于为 Beaglebone 运行，所以逆向操作应该不难）。

【讨论】：

如果它处于API模式，不会发出+++将它带到AT命令（透明）模式吗？
检查文档以确保安全，但我不这么认为。您需要使用 X-CTU（或替代方法）重新刷新 XBee 以更改模式。
我想我将不得不使用 XBee 刷新指南页面上列出的 xb-comm，因为 X-CTU 会导致问题。最后一个问题，对于系列 1 模块，应该遵循此列表中的哪个固件？ ftp1.digi.com/support/firmware/update
我想我设法让 X-CTU 在 Wine（在 linux 上）运行。遗憾的是，这仍然是了解固件名称和型号之间“分辨率”的最佳位置。
我明白了。我会尝试再次识别设备。感谢您的帮助！