蓝牙模组调试笔记

蓝牙(顾凯)模组与APP调试记录

一、目标回顾

目的：
目前的蓝牙实现的是车机通话，需要卫星天通模组将PCM数据通过串口到MCU，再经由MCU将收到的PCM转到蓝牙模组上报给APP端，实现APP拨打接听电话功能；

计划：
预期工期按一个月计算；
1、确认天通模组串口复用功能，参考其提供的mux协议及mux协商图片完成串口复用并建立好通道；（一周）
2、参考天通模组相关文档，修改天通模组的相关配置，确保其走的是串口复用和16K采样率，在此基础上实现PCM数据的传输；（三周）
3、根据音频质量找厂商协助更新固件版本；

预估阻塞点：
1、mux参考资料较少，使用的是linux源码，移植有一定的困难，工期可能会往后延迟50%；
2、目前询问厂商蓝牙一包最大是200，但提供的demo板的蓝牙最大是247，此处可能会影响音频质量；
3、APP那边提供的SDK均是写死的，APP抓日志等调试操作会存在一定困难；

二、结果陈述

从2023年11月28日，截至到2024年1月10日，目前实现的功能如下：
1、APP拨打电话，上行音频流畅，下行蓝牙模组丢包较严重，平均一包丢失2/3的数据，目前确认是蓝牙模组不支持上下行均是16K的情况；
2、APP发送短信至用户手机，已完成；
3、用户手机发送短信至APP，询问APP开发人员，该功能需要和那边协商，暂未定；

2.1 开发重要节点

时间 事件
2023.11.28 开始，串口复用裸数据验证流程完成
2023.12.06 mux搭建完成
2023.12.07 蓝牙模块偶发挂掉以及遇到\r\n自动截断，请求新固件
2023.12.13 MCU发送完整F9 xx F9包
2023.12.14 APP发送短信成功，ASCII显示；语音嘈杂
2023.12.20 修改音频通道为通道2，蓝牙波特率500000，音频丢包
2023.12.25 蓝牙加流控，拨打10000有10s延时，声音嘈杂
2023.12.27 更换新蓝牙模组，修改天通模组波特率9216000，修改新蓝牙模组串口帧大小及超时时间（内部缓存）为0，1，语音流畅，偶尔卡顿
2023.12.28 新蓝牙模组拨号双向均较流畅
2023.01.05 使用spp，上行207缓存蓝牙断连，厂商协助
2023.01.09 上行流畅，下行丢包，经确认该模块目前双行16k存在问题

2.2实际与预期对比

截止至目前（2024.01.10）为止，APP拨打电话功能基本实现。最后状态：蓝牙只支持单边16K，造成丢包现象导致下行音频嘈杂。
就结果而言，是没有达到最初的预期的，该阻塞点在于蓝牙模组的不稳定性；从最开始的蓝牙包上限200达不到APP那边的247，到ble传输丢包改用spp，再到spp异常断连无法再次连接，再到蓝牙模组内部缓存大小问题，最后到蓝牙模组的上下行无法同时满足16K为止，至此该蓝牙的调试使用暂时阻塞，无法在继续开展下去。

三、过程分析

3.1 mux搭建

该部分是参考提供的基于linux环境下的源码进行移植的，移植时涉及到众多linux里使用的库，初期存在较大难度；首先只移植串口接收部分，参考如下图进行裸数据交互，发现天通的返回值和图对应不上；
疑问点：发送第5步时，返回的是第六步的返回值，发送第六步，没有返回值；这属于建链完成吗？

询问后，其提供了一份《卫星通信mux协议流程》,参考其内的交互流程（与图片不符），mux协议屏蔽掉对应未使用的帧；至此通道1、2、3、4、5、6、7、8、9均可建立成功，但目前只使用1（基本AT）、2（语音AT）、9（语音通过串口传输）这三个通道；
后续与APP确认传输时，确认MCU这边的MUX只需做透传即可，转发天通模组下发的PCM以及AT返回值到APP，并转发APP组完的MUX数据包至天通模组，MCU只需确保建立MUX即可，并建一个发送AT指令接口（通道1）用于周期发送AT注网等操作；

3.2 APP联调

至此，MUX搭建完成后，进入下一阶段，与APP联调完成PCM数据的传输，实现APP拨打电话功能

3.2.1 蓝牙上行无数据

疑问点：向蓝牙串口丢数据，使用ble调试宝无法接收到？
该蓝牙并不是真正的透传模式，需要使用特定的AT指令完成上行数据的传输；参考《Source AT 命令手册_V3_5》，且根据蓝牙厂商给的参数一包最大是200字节

该问题解决是在发送给蓝牙的数据包前加上AT#LE指令

3.2.2 APP解音频包失败

MCU将天通传过来的音频数据转发给蓝牙后，APP无法播放出对应的音频；APP解包失败原因分很多种，如下所示：

1、蓝牙模组问题

1）使用ble调试助手连接该蓝牙，不断接收经过MCU转发的天通模组mux协议数据，发现遇到\r\n后，蓝牙会自动截断后面的数据；
例如：发送F9 0B EF 13 41 54 2B 43 4C 43 43 0D 0A 92 F9 0D 0A
Ble调试助手实际接收到的F9 0B EF 13 41 54 2B 43 4C 43 43
2）蓝牙接收音频数据时，会挂掉，这个是蓝牙遇到某些数据后会自动重启，反馈给厂商后解决；
3）BLE存在丢包问题；
4）开启spp，仍会出现遇到\r\n截断，重启，断连后无法连接，spp无法连接车机等问题，反馈给厂商后解决；
5）蓝牙模组内部缓存有问题，说的是1K结果有的一包甚至接近2K，经修改目前稳定在207字节（APP需要）；
6）上下行16K不能同时满足；一边8K一边16K会存在断连问题，反馈给厂商后只解决了断连问题，16K上下行同时暂不支持；

2、程序优化适配

1）疑问点mux协议发送的F9 XX F9数据不完整，有头无尾？
APP没有声音播放后，由于APP的SDK没有打印功能，故MCU这边抓取日志，发现F9 XX F9格式极其不对；并且该段应该是拨打电话时的包，理论上为F9 25 EF 80 07 为开头；

该问题解决是MCU接收天通模组的串口目前是使用的256一个buff，且接收逻辑只是简单的判断F9 F9，有可能数据内部有F9；优化缓存空间，开辟了一个16K的循环buff（后续优化为1K）
2）APP点击拨号，一直显示未入网？
在APP端抓demo板入网日志，与我们的板子日志做对比，初步怀疑是自定义数据问题；根据正在入网这个条打印信息，将此之前的自定义数据均发给APP，排查后无效；

该问题解决是参考天通模组《民口_GMR_MES_Function_Structure_ATC(1)》文档，查到^CPST这个条指令包含入网状态的上报，转发给APP后，流程显示正常，包含正在注网，已入网等状态；
3）疑问点APP状态显示无法跳转至通话中，且时常状态没变化（正在拨号，对方正在响铃，通话中三者跳转）导致无法进入到音频解析状态？
在APP端抓取demo板日志和我们的板子日志，有较大区别如下：
demo板中：APP每次接收到的都是缓存数据，完整数据，也就是说APP每次接收到的都是一帧完整的标准F9 XX F9格式的数据；

而我们的板子APP抓到的日志如下所示：
很明显MCU发送到蓝牙的数据被拆包了，分成了两次发送给蓝牙，导致APP那边当成解析音频数据处理，先缓存在组包，导致没有完整数据日志打印，并影响到后续拨打电话时，产生大量音频数据冲掉了前面缓存的呼叫状态返回值，致使APP无法收到呼叫接通状态无法解音频数据，故没有声音；

该问题解决是MCU不直接转发天通模组下发的数据，先将接收到的数据组成一包完整的帧（F9 XX F9），再转发到蓝牙；
注意点：发送给蓝牙模组的数据包是有限制的，蓝牙是最大200字节，发送超过了，会出现丢包问题；同时每包发送需要有间隔，否则蓝牙内部缓存不过来也会丢包，影响音频；
目前经测试，MCU发送给蓝牙的包，按一小包160字节，每小包间间隔5ms，蓝牙传输的音频状态较为稳定；
4）疑问点APP没有声音？
由于MCU打印蓝牙日志过快会导致MCU挂掉，且APP没有相应的API观察打印信息，故将蓝牙的Tx和Rx飞线出来，使用USB转TTL直接观察；
Demo板通话时的日志：

我们板子的日志暂时没找到文件，但我们的头是F9 23 EF 80 07，显然两者的头是不一致的，排查后发现，是拨打电话时发送的ATD指令使用错误的通道，导致天通模块返回的也是错误的通道号，因此APP那边解不出来该音频；
该问题解决是将APP发过来的AT指令直接转发给天通模块，MCU不做解析；
注意点：串口的Tx和Rx飞线后，需要抓哪个端口，则将其接到USB转TTL的Rx上，每次只抓一个端口；此处可能会出现一种现象，TTL串口抓到了数据，但是该串口本身要传到的地方接收不到数据；
5）电话声音卡顿？
使用APP拨打10000，音频卡顿，断断续续；且拨打11位手机号存在约20秒的延时；
20秒的延时初步分析10000是播放的单方面音频，而11位手机号是要双方建立通信，猜想可能存在一个时间校验，需要校验两边音频的时间，而APP发出的音频转发给天通模块逻辑还未做，怀疑是该原因产生的；

音频卡顿问题，从APP抓取日志发现，不完整音频较demo板而言更多；
排查BLE发送是否存在丢包现象：
（1）与APP累加发送数据，确认顾凯蓝牙一包最大为207字节（与厂商所说不一致）
（2）固定发送160字节，使用BLE调试助手观测，会出现丢包现象
（3）开启蓝牙流控，仍存在丢包问题
（4）联系蓝牙厂商修改版本后，仍会存在丢包问题，转到使用SPP
SPP测试使用：
经过一系列的厂家版本更新，并切换一包大小为160，200，207，目前确定160字节SPP较为稳定，但音频仍存在卡顿
6）疑问点音频卡顿无法突破，更换蓝牙模组，模组
更换新蓝牙模组后，上行仍存在卡顿，此时查询新蓝牙模组的波特率是512000，突然发现天通模组串口配置的是115200，修改其为912600，此时音频仍卡顿；
修改蓝牙模组的内部缓存，也就是串口帧大小及超时时间，AT+PACK=0，1时（0是自适应，1是1ms）时，整个上行质量流畅了很多，但会随着信号质量有一定的卡顿；
紧接着调试下行，拨打11位电话号码时，通话质量流畅，但播放音乐时，采样率可能达不到，导致音乐断断续续；
至此，蓝牙模组验证到此结束，确认目前该mux方案在我们的板子上是可行的，其余问题找蓝牙协助解决；
注意点：天通模组串口波特率修改掉电不保存，也就是每次上电都需要配置该波特率，即在MCU串口为115200时发送配置指令，配置完后需要将MCU的串口波特率更改为9126000；这里有个注意点，MCU不能频繁切换串口配置，否则会切换失败

7）疑问点切回到我们的蓝牙，验证下行不通？
由于之前测SPP时，天通模组波特率是115200，此时更换成912600后，音频质量流畅，使用那套代码验证蓝牙时，下行没有声音；
抓蓝牙TxRx日志，发现蓝牙下行有时候一包1千多，有时候五百多，且每包没有包长，导致解包有问题；而我们的蓝牙最大接收是207，更新一版固件是缓冲区为207，目前版本会重启，反馈厂商解决；
更新一版蓝牙固件后，蓝牙稳定不会异常重启，上行音频正常，下行语音卡顿，嘈杂，但有测试是有音频输出，怀疑丢包，抓包如下：

一行是为一包，一包207字节，很明显丢包严重，该问题已反馈至厂商，等待优化解决上下行16K问题。（截止至2024.01.10，暂未反馈新版本）

四、规律总结

1、调试经验：一级一级排查。如最开始没有音频，现象是APP打印那边没有音频解析的打印日志；第一步开始排查蓝牙的Tx，发现抓的蓝牙Tx日志都是些AT指令状态的返回值，没有涉及音频的数据；紧接着第二步确认天通串口是否将音频给到MCU的串口，使用示波器测天通的串口Tx，发现没有信号；至此怀疑是天通配置问题，修改AT配置指令后，音频数据正常传输到MCU，并能转到APP；
2、蓝牙调试问题：出现蓝牙异常问题后，截取当前发送的异常数据，通过BLE调试助手循环发送，确认是否是该问题，并反馈给厂商；
一般蓝牙会有如下几个常见问题：
（1）遇到\r\n自动截断；
（2）若蓝牙单包发送最大字节不是247左右（小于该值），记得有蓝牙丢包等问题，可以往此方向考虑，毕竟标准蓝牙是247左右；
（3）优先确认所选型号的最大速率是否满足需求，如天通模块目前只能配置16K，且APP也固定为16K，但顾凯蓝牙模组只支持单边16K；
（4）蓝牙是否是透传，这个通过观察蓝牙的Tx，对比发送数据与Tx接收到的数据，若一致，则是透传；若带了固定的头，则是需要解包的；顾凯就是带了固定的头和尾，需要剔除头尾部分；
（5）一般情况下，SPP比BLE传输快，顾凯蓝牙SPP不丢包，BLE丢包；
3、蓝牙升级
这里只单独讲下升级异常问题，若升级工具没有显示soft update这行选项，则在串口输入蓝牙的清除配对指令AT#CV，并删除手机上的蓝牙配对记录，此时再次进行升级操作，则可成功