mt6735 Bluetooth Test -- BLE Test
时间：10-02
整理：3721RD
点击：
[DESCRIPTION]
bluetooth Low Energy:
BLE Adveritiser Test
BLE Scanner Test
[SOLUTION]
关于CTS Verifier 里面BLE test，正确的测试步骤是否是如下所述：
1．BLE Advertiser Test测项
a. 进去BLE Advertiser Test界面；
b. 点击Ble Tx power Level;
c. 点击 Start 之后让另一台测试机进入BLE Scaner Tester界面
2. Ble Scaner Test测项
a. 进去BLE Scanner 界面；
b. 点击Ble Tx Power Level;
3. 观察测试结果
a. 如果在BLE scanner 一端显示有4个device在”Ultra Low/Low/Medium/High”栏位，且Count/Rssi栏位的数值有变动，
则证明BLE Advertiser有正常工作；
b. 在测试过程中由于Count/Rssi的数值在变动，不便于观察是否满足：Ultra Low< Low < Medium< High
可以移动Scanner端远离Advertise端至Count/Rssi数值停止跳动，或者在Ble Advertiser端点击Stop，则在Ble Scanner 端的数据会停止变化，此时可以观察Count/rssi数值是否满足Ultra Low< Low < Medium < High
（如过不满足此规律，敝司有Patch修复此问题。）
4. Pass条件
CTS Verifier判断Pass的条件为High Level device获得一个新的MAC address，在Advertise端点击stop再点击Start，则在Ble Scanner 端就会弹出Get new Mac address的字串，然后Pass Button就可以点亮，这是mtk BT的设计机制，不用等到15分钟之后更新一次stack之后再获得一个Mac Address.
关于Scanner端有Unknown BLe advertise tx power的字串：
CTS 的逻辑是用BTM_BLE_ADV_TX_POWER这一组织来验收到的advertise的tx power，
如果不采用Bluedroid这一组tx power，那么CTS测下上就会显示Unknown BLe advertise tx power
这暂时是MTK的设计，不影响测试结果，后续敝司会做修改，请知悉。
Count/Rssi数值在合了Patch后，测试过程中某个时间点仍不满足：Ultra Low< Low < Medium <High规律?
Count的CTS Verifier这部分的逻辑，count是指各个level scan到的advertise 包的个数，收到一包就加一，
这样一开始测试时，两个device离的很近，4个level可能不能满足这个条件，但数值会很相近，但随着整个测试推进或距离变化，count值会慢慢趋向这个规律，建议多测试一段时间。
移动scanner端，count会慢慢freeze，这时4个level的rssi都不一定满足从小到大的规律，而是在一个小的范围里，都比较接近，因为RSSI变小到一个范围，就会收不到adv，UI不更新，才会freeze， 4个level freeze的时候，rssi的大小应该都比较接近。
因此在测试过程中Count与Rssi的数值情况，并非时刻保持由小到大的规律的情况，是属于正常的，
只要不是长时间不满足由小到大的情况就可认定为Pass。
bluetooth Low Energy:
BLE Adveritiser Test
BLE Scanner Test
[SOLUTION]
关于CTS Verifier 里面BLE test，正确的测试步骤是否是如下所述：
1．BLE Advertiser Test测项
a. 进去BLE Advertiser Test界面；
b. 点击Ble Tx power Level;
c. 点击 Start 之后让另一台测试机进入BLE Scaner Tester界面
2. Ble Scaner Test测项
a. 进去BLE Scanner 界面；
b. 点击Ble Tx Power Level;
3. 观察测试结果
a. 如果在BLE scanner 一端显示有4个device在”Ultra Low/Low/Medium/High”栏位，且Count/Rssi栏位的数值有变动，
则证明BLE Advertiser有正常工作；
b. 在测试过程中由于Count/Rssi的数值在变动，不便于观察是否满足：Ultra Low< Low < Medium< High
可以移动Scanner端远离Advertise端至Count/Rssi数值停止跳动，或者在Ble Advertiser端点击Stop，则在Ble Scanner 端的数据会停止变化，此时可以观察Count/rssi数值是否满足Ultra Low< Low < Medium < High
（如过不满足此规律，敝司有Patch修复此问题。）
4. Pass条件
CTS Verifier判断Pass的条件为High Level device获得一个新的MAC address，在Advertise端点击stop再点击Start，则在Ble Scanner 端就会弹出Get new Mac address的字串，然后Pass Button就可以点亮，这是mtk BT的设计机制，不用等到15分钟之后更新一次stack之后再获得一个Mac Address.
关于Scanner端有Unknown BLe advertise tx power的字串：
CTS 的逻辑是用BTM_BLE_ADV_TX_POWER这一组织来验收到的advertise的tx power，
如果不采用Bluedroid这一组tx power，那么CTS测下上就会显示Unknown BLe advertise tx power
这暂时是MTK的设计，不影响测试结果，后续敝司会做修改，请知悉。
Count/Rssi数值在合了Patch后，测试过程中某个时间点仍不满足：Ultra Low< Low < Medium <High规律?
Count的CTS Verifier这部分的逻辑，count是指各个level scan到的advertise 包的个数，收到一包就加一，
这样一开始测试时，两个device离的很近，4个level可能不能满足这个条件，但数值会很相近，但随着整个测试推进或距离变化，count值会慢慢趋向这个规律，建议多测试一段时间。
移动scanner端，count会慢慢freeze，这时4个level的rssi都不一定满足从小到大的规律，而是在一个小的范围里，都比较接近，因为RSSI变小到一个范围，就会收不到adv，UI不更新，才会freeze， 4个level freeze的时候，rssi的大小应该都比较接近。
因此在测试过程中Count与Rssi的数值情况，并非时刻保持由小到大的规律的情况，是属于正常的，
只要不是长时间不满足由小到大的情况就可认定为Pass。