请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：CC1352P7 工具与软件：
我正在将 Beagle Play 用作 Sub-Gig 系统中的收集器。 配置为200kbit 跳频操作。
收集器二进制文件有一些光定制功能、可添加一些定制到我们的应用中的消息、同样、在 Linux 端运行的收集器也有匹配的变化。 协处理器二进制文件运行 SDK 7.10.2.23、Linux 二进制文件使用最新版本、即4.40.00.03。 对协处理器的唯一修改是增加 Tx 和 Rx 队列条目的数量。
传感器使用 DMM 以双模式配置运行、以同时运行 SubGHz 堆栈和 BLE 堆栈。 我们使用的是 SDK 6.10.0.29。 我正在使用用 python 编写的自定义应用程序通过 TCP 套接字与收集器通信、这与 TI 示例应用程序相同。
我遇到的问题是、在长时间运行(6周左右)并连接8个传感器并进行报告后、协处理器似乎停止响应。 传感器未连接、如尝试重新连接时几个电池电量耗尽以及读取配置文件传感器状态特性所示。 收集器套接字仍处于打开状态、没有可观察到的错误、但协处理器到更高级别的通信显然已损坏。
我想要的是一些关于可能发生的情况的建议、以及下次发生这种情况时我如何收集更好的信息。 我需要实施一个可以部署到现场并在故障后进行检查的解决方案。 对错误行为的单元进行直接实时访问并非总是实用的。 我怀疑可能存在一些资源的泄漏,例如,如果 Mac TX 或 Rx 队列中有从未释放过的条目。
与此同时、我要对收集器到我的应用的通信设置一个看门狗。 如果15分钟内没有看到任何传感器数据包、我将终止收集器、重置协处理器、重新启动收集器并重新建立 TCP 连接。 这是一个相当粗略的解决方案。 它应该有效、但并不理想。
