wifi-bt常见问题总结

WIFI和蓝牙所遇到的相关问题如下所示：

【WIFI】

1.NX907J  WIFI AP测试有fail项 

2.NX907J   不插卡开启wifi待机10H耗电27%

3.NX907J   wifi扫描且频繁切换连接状态导致功耗增加

4.NX907J   连接1信道的WiFi后，不能正常上网

5.NX907J   终端连接WiFi信号值为68dBm左右时，WiFi自动断开

【蓝牙】

1.NX907J  【蓝牙】连接2.4GWiFi，蓝牙传输速率较慢

2.NX907J  【蓝牙】蓝牙支持profile确认

3.NX907J  【蓝牙】蓝牙连接智能手表失败

4.NX907J  【蓝牙】测试机和辅助机之间用蓝牙传输文件失败

5.FX55B71 【蓝牙】使用DR-BT140Q SONY蓝牙，手机通话时，来电，点击蓝牙接听键，无法保持第一通电话

6.FX55B71 【蓝牙】连接“Fotopro”自拍杆，使用自拍杆上的按钮无法拍照

7.NX907J  【蓝牙】蓝牙文件传输：BQB fail

8.NX907J  【蓝牙】PC给测试机发送文件失败

【WIFI】

Case 1：NX907J-WIFI AP测试有fail项 

初步了解：这个是关于VMM的测项，主要验证VI，VO，BE，BK优先权的问题。

 

知识拓展：WMM是一种无线QoS协议，用于保证高优先级的报文有优先的发送权利，从而保证语音、视频等应用在无线网络中有更好的质量。WMM定义4种接入类型，这4种接入类型是按照特定的业务类型(话音、视频、尽力而为、低优先级数据)和与之相关联的优先级设计的，但WMM可让网络运营商只有选择最适合的网络对策，并决定采用具有哪种优先级的网络。

高通给的解决方案：

#1.提高发包大小

#2.换换手机距离，角度。

#3.必过方法：WMM主要测的是前后10s比率，对速率本身关注不大，前10s拿远一些，例如屏蔽房外面，后10s拿近。

 

最终解决：把手机拆开，把天线拿掉，最终pass。原因可能是因为power太强或者手机本身干扰大的原因。

 

Case 2：NX907J-不插卡开启wifi待机10H耗电27%

初步了解：这个是测试不插卡并打开WIFI的待机功耗。

 

分析原因：从第一次提供的log里分析，并没有找出具体导致功耗的原因，然后我们本地也没有复现此log，唯一复现的一次是因为GMS包不断的初始化配置而导致系统无法休眠。后来从客户复现之后提供的log里面可以看到，导致功耗的原因是因为因为这两次是由于系统唤醒锁ActivityManager-Sleep一直保持唤醒而导致的功耗问题，是Google已知的一个bug，这个bug是必现的。

 

复现条件：手机处于关机状态，然后开机，手机启动后不要亮屏解锁，让手机自动休眠。（注：手机重新启动，不会导致此bug产生，只有在手机处于关机状态下，开机会产生此bug）判断此bug是否出现：从bugreport log中可以看出，进去bugreport.txt直接搜索All partial wake locks:，然后下面第一个就是耗时最长的唤醒锁。

 

知识拓展：GMS包是goggle相关的一些应用，在国内无法正常联网初始化，会导致很多问题，在手机内一般在system/priv-app和system/app里面。具体GMS包的触发是不确定的，会被其他应用调用到，也可能app自己主动对server发起同步活动。

 

解决方案：android/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

修改：在上面文件里找到函数isSleepingLocked()，将return mSleeping && (mWakefulness ==PowerManagerInternal.WAKEFULNESS_ASLEEP || mWakefulness ==PowerManagerInternal.WAKEFULNESS_DOZING);改为return mSleeping;，修改完成后就不会复现此bug。

总结：这种方法可以规避这个bug，但是不知道会不会导致其他问题；如果不修改代码，此bug是必现的，但是一般对于用户来说，很少会复现出此bug。

 

Case 3：NX907J-wifi扫描且频繁切换连接状态导致功耗增加

初步了解：这是Case2客户工程师分析的可能导致功耗的原因。

 

高通回复：WIFI每隔10s扫描是属于WIFI正常工作，并不会导致功耗增加

 

 

Case 4.NX907J-连接1信道的WiFi后，不能正常上网

初步分析：从log看，WIFI断开的过程是由上至下的，不是驱动上报的断开，而是用户发起的断开。但是从客户提供的视频看，WIFI图标并没有断开。需要客户重新抓取log，结果客户未复现。

 

 

Case 5.NX907J-终端连接WiFi信号值为68dBm左右时，WiFi自动断开

初步分析：从log可以看出，WIFI信号值在62dBm时就已经断开，但是需要提供snifflog和QXDM log进行具体分析。结果客户未复现。

 

【蓝牙】

Case 1：NX907J-连接2.4GWiFi，蓝牙传输速率较慢

初步了解：客户给的蓝牙传输速率的测试标准是100-156KB/S！转换一下为：0.78Mbps-1.22Mbps！

 

高通回复：当WIFI打开时，传输速率的典型值在最大值的30%（0.6M)左右。BT的传输速率和WCNSS_qcom_cfg.ini文件中btcActiveWlanLen和btcActiveBtLen有关。

如果WCNSS_qcom_cfg.ini文件没有这两个参数，则使用默认值：

      #defineCFG_BTC_ACTIVE_WLAN_LEN_NAME "btcActiveWlanLen"

      #defineCFG_BTC_ACTIVE_WLAN_LEN_MIN ( 0 )

      #defineCFG_BTC_ACTIVE_WLAN_LEN_MAX ( 250000 )

      #defineCFG_BTC_ACTIVE_WLAN_LEN_DEFAULT ( 60000 )

 

      #defineCFG_BTC_ACTIVE_BT_LEN_NAME "btcActiveBtLen"

      #defineCFG_BTC_ACTIVE_BT_LEN_MIN ( 0 )

      #defineCFG_BTC_ACTIVE_BT_LEN_MAX ( 250000 )

      #defineCFG_BTC_ACTIVE_BT_LEN_DEFAULT ( 90000 )

 

      高通默认BT传输速率请见文档80-y8113-22_a_msm8937_wcn36x_la_1.0_wireless_connectivity_cs_release_test_report.pdf

 

Case 2：NX907J- 蓝牙支持profile确认

初步结论：

1. HSP1.2--AG =====> Support, No support V1.1 and HS role.

      2.DUN1.1-- GW =====> Support, No support V1.2 and DT role.

      3.OPP1.2-- Server/Client =====> Support

      4.FTP1.1-- Server =====> Support

      5.A2DP1.2-- Source AVDTP 1.2 =====> Support V1.2, Source and Sink role

      6.AVRCP1.3-- TG AVCTP 1.4 =====> Support AVRCP V1.6, Controller and targetrole.

      7.HFP1.6-- AG =====> Support AG(V1.7) and HF(V1.6) role

      8.PAN1.0-- NAP/PANU =====> Support, Support NAP and PANU role,

      9.PBAP1.2-- PSE =====> Support

      10.MAP1.2-- MSE =====> Support

      11.GAVDP1.2 =====> Support V1.2 Support Initiator and Acceptor role

      12.HID1.0-- Host ====> Support V1.0, Support Host and Report protocol role

      13.DID1.3 =====> Support

      14.IOPT =====> This is "互操作性配置文件", Please refer link: https://www.bluetooth.com/zh-cn/specifications/assigned-numbers/acronyms-specification-names

问题所在：

      6.AVRCP1.3-- TG 不支持（支持AVRCP1.6—control，target ） 这是我通过贵司提供的网站资料查询的，也与你提供的信息一致。

      但实验室说：手机实际支持是1.3版本，并也只支持TG角色，如要支持1.6需要修改软件。

      7.HFP1.6-- AG 不支持（支持HFP1.7--AG/HF） 这是我通过贵司提供的网站资料查询的，也与你提供的信息一致。

      但实验室说：手机也实际支持是1.6版本AG角色，而需要支持到1.7也是需要修改软件，并不会支持到HF角色。

分析原因：

AVRCP分析：

      ===>AVRCP Version

      //Path:system/bt/include/bt_target.h

      #ifndefSDP_AVRCP_1_6

      #defineSDP_AVRCP_1_6 TRUE

      #endif

      从上面的定义，代表我们可以支持AVRCP版本高达1.6。

版本控制如下：

      1.默认情况下，我们启用了SDP_AVRCP_1_6，所以支持1.6

      2.大部分IOT设备存在兼容性问题，所以我们有回退策略，首先检查IOT设备是否存在于黑名单中，如果是，将在DUT上直接回退到1.3以与IOT设备进行通信（path： system/bt/stack/sdp/sdp_server.c   func：sdp_fallback_avrcp_version）

      3.如果黑名单中不存在，则判断IOT设备是否存在于BT地址的/data/misc/bluedroid/iot_devicelist.conf(Version+（NAP + UAP）部分）中，如果版本是从.conf文件中获取的是1.6，所以代表我们不需要回退AVRCP1.3，我们将继续使用AVRCP1.6与IOT设备通信，或表示我们将回退到指定版本（func：sdp_get_stored_avrc_tg_version）

         

AVRCP

      //如何在Android N上启用CT角色功能

      1.在 packages/apps/Bluetooth/res/values/config.xml中，确保将profile_supported_avrcp_controller设置为true：------<boolname="profile_supported_avrcp_controller">true</bool>

      2.insystem/bt/include/bt_target.h，确保下面的宏设置为TRUE：

           #ifndefAVRC_CTLR_INCLUDED

           #defineAVRC_CTLR_INCLUDED TRUE

           #endif

 

           #ifndefBTA_AV_SINK_INCLUDED

           #defineBTA_AV_SINK_INCLUDED TRUE

           #endif

 

HFP分析：

      ===>HFP版本问题

      请按照以下方法对PTS不匹配DID问题。

      //修改HFP AG 1.6为1.7版本。

      请先运行“IOPT/SDAS/BV-03-I”

           adbroot

           adbshell setprop bt.pts.certification true

           adbshell getprop bt.pts.certification /* make sure return 'true' */

          

HFP

      //如何在Android N上启用HF客户端

      1.请在 packages/apps/Bluetooth/res/values/config.xml中将以下标记设置为true：------<boolname =“profile_supported_hfpclient”> true </ bool>  

      2.在打开BT之前，将属性“persist.service.bt.hfp.client”设置为“true”。

      3.确保以下内容存在于 packages/apps/Bluetooth/AndroidManifest.xml中   

           <service

           android:process="@string/process"

           android:name= ".hfpclient.HeadsetClientService"

           android:enabled="@bool/profile_supported_hfpclient">

           <intent-filter>

           <actionandroid:name="android.bluetooth.IBluetoothHeadsetClient" />

           </intent-filter>

           </service>

默认支持AG协议：

SourceCode:packages/apps/Bluetooth/res/values/config.xml

      <boolname="profile_supported_hs_hfp">true</bool> -----> AGRole

      <boolname="profile_supported_hfpclient">false</bool> -----> HFRole

 

这些协议的版本信息我们可以从btsnooplog里面看出来。

Case 3：NX907J-蓝牙连接智能手表失败

初步分析：从log里看出是SMP pair failed，也就是SMP协议出现了问题。需要OTA设备进行进一步的分析。经过OTA设备分析，确认这是一个IOT问题。

 

问题原因：蓝牙手表只支持LE，并不支持BR / EDR（基本上如果远程设备只有LE，并且不支持BR / EDR，则这些设备中的某些设备不会像配对请求中的启动器和分配器密钥分发中设置BR / EDR键。）

 

知识拓展：蓝牙协议包括两种技术：BasicRate（简称BR）和Low Energy（简称LE）。这两种技术，都包括搜索（discovery）管理、连接（connection）管理等机制，但是他们是互不相通的！

蓝牙诞生之初，使用的是BR技术，此时蓝牙的理论传输速率，只能达到721.2Kbps。在那个年代，这个速度可以说是惊为天人了啊！但是科技变化太快了，BR技术转眼就过时了，于是Enhanced Data Rate就出现了。 使用EDR技术的蓝牙，理论速率可以达到2.1Mbps。但是很快EDR又落伍了，当时WIFI可以达到几十Mbps，上百Mbps。然后把WIFI的物理层和MAC层这种方式拿过来用用，于是就有了AMP（Alternate MAC and PHY layer extension）技术，速率可以达到54Mbps。但是能量是守恒的，传输速率的越快，意味着功耗越高，接下来就有了LE低功耗蓝牙技术。

 

修改方法：检查Adv数据标志，用来检查远程设备是否仅为LE，然后在配对请求中禁用BR / EDR Link键的位。

Case 4.NX907J-【压力测试】测试机和辅助机之间用蓝牙传输文件失败

初步分析：从btsnoop log分析原因是资源访问失败，log如下：

877,090 EventConnection Complete 00:00:00.000488 5/17/2017 2:49:18.362114 PM RequestRejected due to limited resources 0x0007 11 14，具体原因需要QXDM分析。但由于我们换了新机器，DVT3五株机器未复 

 

Case 5.FX55B71-使用DR-BT140Q SONY蓝牙，手机通话时，来电，点击蓝牙接听键，无法保持第一通电话

分析：可以从btsnoop  log中确认不支持DR-BT140Q SONY蓝牙耳机此功能。

Log如下：

314 Slave2017-6-9 9:18:05.423620 2 AT+BRSF=8. Retrieve AG Supported Features 23              Call waiting or 3-way calling: NotSupported  

 

 

Case 6.FX55B71-连接“Fotopro”自拍杆，使用自拍杆上的按钮无法拍照

      高通原生基线ok，阿里的问题

Case 7.NX907J-蓝牙文件传输：BQB fail

      由于时间戳对不上，所以log无法分析，我把我们的软件版本发给客户进行测试，结果pass。得出结论：我们的版本ok，客户的问题。

 

 

Case 8.NX907J-PC给测试机发送文件失败

      这个和BQB fail是一种类型的问题，客户已经解决。

 

关于WIFI吞吐率测试：

1.    测试方法参考文档kba-170524040257_2_how_to_do_tput_test.pdf。

2.    使用工具iperf 2.02版本测试，以server端结果为准。

3.    UDP-DL测试时出现掉坑现象，是因为手机在做split scan。

4.    如果聚合没跑起来，手机端就会发一个80211的ack协议。

5.    如果TCP 或者UDP的聚合没有跑起来，可能是因为手机在做scan动作，可用命令临时关掉scan：iwpriv wlan0 dump 311 1 。

6.    在ini里面是否有rps_mask=f0，高通一般f0比0f好，但是我们实际测试结果是0f比f0好。

7.    如果从sniffer log看出有较多的重发报文，让硬件把nv,bin里面调整一下看看，具体如下：

<HwParam11>340</HwParam11>-------0是缺省值，缺省是10us, 340差不多9us不到
要设置相应的<validBmap> ， 如果其他HwParam没设对的话，设置<validBmap>2048</validBmap>

 

validBmap 转成二进制时，bit位决定nv.bin里面那个HwParam起作用。
HwParam11 设置的值影响发完包之后切换到接收所需时间。有些AP发包过快，可能手机还没来得及切换到接收状态，引起丢包，调整该值让切换时间更短一点可能能解决这个问题。

8.    测试5m，10m时，如果屏蔽房不是足够大，可以找硬件加衰减器测试。