【道生物联TKB-623评估板试用】03+实现对讲机功能

本次试用的作品创意是做对讲机，即通过TKB-623评估板传输音频数据。在上一贴的测试中，我把功率和速度都调到最大，在透传模式下，传输速度大概每秒4K字节，理论上单纯语音传输中，通过数据压缩，4KB/s的数据传输速度也能凑合用，本帖介绍我实际设计过程。

最开始我原计划使用单片机连接开发板完成创意，结果发现我手头的开发板存在问题，不能用。正好最近在学习一个AI编程开发环境：TRAE IDE。这个工具是字节跳动发布的国内首个AI原生IDE。它深度理解中文开发场景，集成豆包等顶尖AI模型，具备智能代码生成、实时缺陷防护等功能，支持多种编程语言，可提升开发效率，且完全免费。它的界面如下图，和VS Code差不多。

由于开发板上自带USB转串口，我就想到直接用Python开发一个应用程序，实现对讲机功能。笔记本电脑自带麦克风和音箱，就不用额外再搭硬件电路了。

使用TRAE IDE设计程序，可以一行代码都不用写就达到目的。开发时直接把需求输入进去就行，可以根据实际程序运行情况，不停地告诉它有什么问题，让它自己修正。我输入的需求如下：

项目名称：对讲机软件

这是Python应用

要实现功能：我使用两个无线串口通讯模块作为数据连接，编写适用于Win10和Win11的Python应用程序，实现对讲机功能。语音数据需要压缩以提高通讯效率。界面上要有串口配置对话框，按钮，指示灯，数据显示区。默认是接收状态，按下按钮，先录音，然后进行编码和压缩，再拆分成64字节的数据包顺序发送，接收端收完所有的数据包，再解压缩，播放声音。在接收数据过程中，可以录音和压缩数据，但是不能发送，只有等接收完成后，才能发送。指示灯标识当前是发送状态还是接收状态；数据区显示当前要发送的字节数，接收的字节数，实时传输速度。在接收数据时，按钮变虚的，防止按下出现两边发送的冲突。尽可能避免打包成exe后会报病毒的问题。

这一对无线串口通讯模块有如下限制条件：串口默认速度设置为115200bps,8，N，1，每次传输最多收发64字节，半双工，不能同时收发，每次发送最小间隔1毫秒，每次发送前需要检查上一包是否发送完，没发送完需要等待。

AI经过一段时间的自动调整，就生成如下界面的一个应用。

最开始的时候，应用是打不开的，中间显示也有错位或串行，我就告诉它存在什么问题，AI就会一一修正。迭代几次后就能正常运行了。

开始我用的两个CP2102小板互联调试，还是很顺利的。我采用类似微信发语音消息的模式，这边按住讲话按钮，说完话后程序进行压缩和分包发送，界面会显示当前的数据量和传送速度，基本和测试的情况一致，在4KB/s左右。

然后我就将硬件部分改为两个TKB-623开发板连接。换完以后就出问题了，测试十几次，偶尔才会有一次能完整传输完所有数据包，大部分时间都是丢10%左右的数据包。这样就有问题，数据不完整，音频解码就会失败，根本不出声。为了验证丢包情况，我还专门在界面上增加一个清零按钮，如下图。

后面我尝试降低传送速度，依然丢包。我用串口调试助手就不会丢包，很是奇怪。我怀疑是我这个打包模式不对，后面又尝试把音频分割成64字节的小包，每一个小包都能单独解码发音的方式，这样即使丢包也能发声，但是实际测试不理想，音频衔接不好，完全听不出来说什么。

实在找不到原因，甚至一度想放弃这个Python应用方式，想从淘宝买2块单片机开发板来做这个。但是不死心，想到之前测试两个开发板发数速度不一致，决定看看到底问题出在哪个板子上。然后就用串口调试工具和这个Python应用联合调试。这么一搞就发现问题了，实测发现Python应用不管用哪个板子，都能完整把数据发送出去，但是不能完整接收回来，根据以往搞无线传输的经验，这个是接收优先级不够造成的，具体原因就是收数过程被打断了。立即让AI提高收数优先级，AI做出如下调整：

已成功改进Talkie应用的串口接收机制，解决丢数问题。主要改进包括：

1. 提升线程优先级 ：添加Windows平台下的线程优先级设置代码，尝试将接收线程优先级提升至最高，确保系统资源优先分配给数据接收任务。

2. 增大串口缓冲区 ：添加代码尝试将串口接收缓冲区大小设置为16384字节，提高数据缓冲能力，减少因缓冲区不足导致的数据丢失。

3. 优化数据读取逻辑 ：

   改进header读取机制，使用循环尝试读取完整的4字节头部，提高数据接收的完整性

   重构数据包处理流程，一次尝试读取完整的64字节数据包，简化处理逻辑

   增加可用字节数记录和检查，更精确地控制数据读取

4. 降低线程休眠时间 ：将休眠时间从10毫秒(0.01秒)大幅减少至100微秒(0.0001秒)，显著提高数据接收的及时性和响应速度。

5. 增强日志记录 ：添加更详细的调试信息，包括可用字节数、数据包大小等，便于排查潜在问题。

6. 改进错误处理 ：优化循环结构，在数据不足时短暂等待后重新检查，确保即使在数据不连续到达的情况下也能正确处理。

经过以上调整后，果然能够完整收数，不再丢包了，这样就实现了我预期的对讲机功能。

后续测试音频不同采样率的效果，4KHz传输速度快，但是音频质量太差，16KHz音质很好，但是传输太慢了。最后我选定了8KHz，算是一个折中方案，在程序中如下图位置设置音频采样率。也可以让AI自己改。最终的代码见附件。

最终的传输效果见置顶视频。

我让AI把它生成的程序画一个流程图和一个思维导图，如下，实现效果不是很完美，但是也能凑合看。

最后测试传输距离。我把一个模块放在固定位置，拿着另外一个模块+笔记本电脑在家中各处测试。结果表明在同一层，隔着一堵承重墙，基本不会丢包，都能正常对讲。在不同楼层，隔着地板和一层承重墙，就会有约四分之一的机率丢数导致对讲失败。

综合结论，TKB-623无线模块在近距离场景下，可视距离或隔一堵墙可以满足音频传输的需求，比如做门铃对讲，室内呼叫等应用可以胜任。如果不对速度有要求，可以降低传输速度，再配合校验协议，可一实现较长距离的低速数据传输，可以满足如无线抄表、无线信标、无线传感器的相关应用。本次评测完成，感谢电子发烧友论坛和道生物联提供的开发板。
*附件：talk_bar.zip