XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XX Author: ZHS (cultural person)
XX Contact:
XX Copyright statement: Original article, welcome to comment and reprint~ It’s best to tell me when reprinting
What XX has to say: The author's level is limited, and it is inevitable that there are deficiencies. Please correct me!
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Written in the front: The author is responsible for a TWS speaker (CSR8670) project, which needs to connect to the IOS version of the APP through BLE.
In the process of project development, we experienced your comings and goings, the addition of various needs, and the resolution of various problems ~ finally came over step by step, including the debugging and docking with the project's IOS version APP ( domestic development ) are also very smooth . Towards the end of the project, the client wanted to use the software in another project (called project B), so he directly docked the IOS version of project B ( developed by foreigners ), and found that it couldn't be connected.
The IOS version of project B ( developed by foreigners ) is docked with the old version of the software, and there is no problem with the connection and communication, so the author got the old version of the software and compared the difference between the new and the old software. turn out:
1. The data of the broadcast packet is different:
Because the requirement I got has always been that the APP must specify the Bluetooth name to connect, so the broadcast data only contains the "Bluetooth name" + other information, while the broadcast data of the old version of the software is set according to the format of "Bluetooth name + service UUID" of;
So I changed the broadcast data of the new software and it was able to connect, but there was still a problem with the data transmission and reception.
2. The order of Primary service after connection is different:
This is beyond the author's expectation. Normally, after connecting, the Handle of all services can be obtained, and data can be sent and received according to the required services. Because I really can't think of other reasons, I can only try to modify the display order of the Primary service, and the result is OK.
3. Post a piece of communication between the customer and the foreigner
Not clear if this is supposed to be final implementation, but it causes me to violate Apple’s recommended practices:
When you do, the central manager returns only peripherals that advertise the services you specify (recommended).
If the serviceUUIDs parameter is null, all discovered peripherals are returned regardless of their supported services (not recommended).
In other words, instead of being handed (from CoreBluetooth) the precise ServiceId I want to connect to, I need to crawl through the devices, and query their services to find the one I want. As above, Apple recommends against this for performance and excessive battery use reasons.
Foreigners follow the advice given by Apple for performance and excessive battery usage: find the service you need while scanning.
Apple’s recommended practice is to find services as quickly as possible, so foreigners feel that my software makes him violate Apple’s recommended practices.
At that time, there was a word wtf~ a word appeared in my mind, but at the same time another voice said: No, this is not rigid! This is rigorous! !