This is an article published in the electronic product world 2009 selected practical electronic design 100 cases, discusses the reasons and solutions for the compatibility of Bluetooth technology.
This article refers to the address: http://
introduction
Bluetooth technology has been widely used for more than 10 years, and part of the reason is that the Bluetooth SIG organization defines the application protocol in the form of profiles for various applications, so the interoperability between Bluetooth devices has rules to follow, but even so, Bluetooth Interoperability between devices, also known as compatibility issues, still exists in almost all Bluetooth applications. The author has developed a Bluetooth car product for a joint venture car manufacturer for two years, realizing hands-free calling, dual call management, automatic download and manual download of the phone book, streaming music playback and remote control functions. Mobile phones and music players have encountered and solved various compatibility issues. Combined with the experience of testing and solving compatibility problems during product development, this paper analyzes the causes of compatibility problems. There are three reasons for this: the specific application itself is not strictly defined, the application context is different, and the introduction protocol brings Compatibility. The following three aspects are analyzed in detail and combined with specific examples to illustrate their solutions.
Application definition is not strict
The Bluetooth SIG organization defines Profiles, which standardizes the implementation of various functions, and defines mandatory and optional features. Device vendors can choose which options to implement, which can cause certain differences. Moreover, Profile does not strictly define the application itself, but defines the function, and the application is a collection of functions. The profile does not define how to implement an application by multiple functions, so that the Bluetooth device manufacturer implements an application. There is a difference. Double call is one of the most compatible applications in the hands-free calling application of in-vehicle devices. The following is the reason for the compatibility problem of the application and an example of its solution.
For hands-free calling, several important functions are call setup prompt CALL_SETUP, call hold CALL_HELD, call result CALL, call information CLCC, and the mobile phone transmits these prompt messages to the hands-free device in real time when the call state changes. The device end can be consistent with the call status of the mobile phone, and the call control on the hands-free device side is in line with expectations. Among them, CALL_SETUP and CALL are mandatory functions, but CALL_HELD and CLCC, which are very important for double call, are optional functions. Dual call is defined as Three way calling in HFP (Hands-Free Profile). This is also a Optional features. In this way, when supporting dual calls, various mobile phones are supported or partially supported in their own way, thus bringing compatibility problems of dual calls. Let's take the second call as an exhalation as an example to analyze the solution.
When the second call is made, the mobile phone will send a CALL_SETUP=2 message, indicating that the call is being made, and the result is that the other party refuses to pick up, the other party answers, and does not dial the call. Obviously, it is crucial to judge the result of the call. We test the mobile phone and classify it according to its performance characteristics. The mobile phone is divided into the following categories: A-support CALL_HELD does not support CLCC, B-supports CALL_HELD and CLCC, C- Support CLCC does not support CALL_HELD and the phone does not support CALL in Three way calling, CL-supports CLCC does not support CALL_HELD but the phone supports CALL in Three way calling, E- does not support CALL_HELD does not support CLCC but the phone supports in Three way calling CALL, F- does not support CALL_HELD and does not support CLCC and the phone does not support CALL under Three way calling.
For the AB mobile phone that supports the CALL_HELD message, we can judge the outgoing call result by CALL_HELD, CALL_HELD=1 means the other party answers, CALL_HELD=0 means the other party rejects or fails to dial; for the CD type mobile phone supporting CLCC, If the mobile phone supports CALL in Three way calling, CALL=1 means the other party answers. If there is no CALL message indicating that the other party rejects or fails to dial, then the current call information of the mobile phone needs to be read when CALL_SETUP=0, and then according to the The call information updates the call status of the hands-free device; for EF mobile phones that do not support CLCC and CALL_HELD, if the mobile phone supports CALL in Three way calling, CALL=1 means the other party answers, otherwise the call will be made by default when CALL_SETUP=0. The result is handled as the other party rejects, that is, the call result cannot be judged at this time.
Application context difference
Bluetooth is an application that requires strict time characteristics. Each Bluetooth behavior and each phase must be completed within the corresponding time. Otherwise, it may cause failure or failure to respond for a long time. The context of the application refers to what kind of Bluetooth behavior will be performed after the completion of a Bluetooth behavior. It is determined by the application of the Bluetooth device. The difference in the application of the similar product will bring about the difference in the application context. This can lead to compatibility issues. For example, after the Bluetooth car device and the Bluetooth mobile phone interoperate and complete the pairing, when the car device realizes the automatic connection after the pairing, the compatibility problem is encountered due to the difference in the processing of the mobile phone after the pairing is completed. The in-vehicle device realizes the automatic connection function after pairing. After the pairing is completed, the in-vehicle device reads the SDP of the external device to perform a service inquiry to determine the external device type (including three types of hands-free, audio stream, hands-free + audio stream) and then automatically Connecting to its hands-free or audio streaming service resulted in some mobile phones failing to read SDP, some mobile phones failing to connect automatically, and some mobile phones were unable to respond for a long time.
For this compatibility problem, the performance characteristics of the mobile phone in different application contexts need to be analyzed and classified according to the differences. By analyzing the processing of the mobile phone after the pairing is completed, some mobile phones are automatically connected immediately after the pairing is completed, and some need the user to confirm and then manually connect, and some will read the service list of the in-vehicle device through the SDP and then provide the service for the in-vehicle device. Automatic connection (in-vehicle equipment provides hands-free service, SPP service, SyncML service, streaming music music playback service), and some will not automatically connect, so after classification, the automatic connection after pairing according to the different characteristics of the mobile phone is as follows:
The Bluetooth car device does not operate within 4 seconds after the pairing is completed. The phone that is automatically connected immediately after pairing (such as nokia 6500c) and most phones that are automatically connected after reading SDP (such as Samsung SGH-U608, SGH-E208) can Quickly connect to the vehicle. After the pairing is completed, the Bluetooth in-vehicle device judges the type of the paired device (including hands-free, audio stream, hands-free + audio stream) through SDP. If the type is hands-free + audio stream, wait after the connection hands-free success. 10 seconds to connect to the audio stream, the reason why the audio stream is connected after 10 seconds is because the hands-free connection is successful, you need to connect PBAP or SyncML or SPP to download the phone book, if the A2DP connection is connected at the same time to connect the paired device stream Media services can cause link loss, hands-free connection and audio stream connection disconnection. If the connection hands-free fails, the audio stream service is no longer connected, because some mobile phones, such as the Dopod D600 PDA phone, read the SDP after the pairing is completed and then automatically connect, sometimes causing the hands-free connection to be unsuccessful, if you connect the audio Streaming, the connection is successful, but after connecting from the car device side, the phone cannot be connected successfully. After disconnecting the streaming media, the connection hands-free has failed and must be re-paired.
For the user to confirm the manually connected mobile phone and the mobile phone that partially reads the SDP and then automatically connects the in-vehicle device, during the automatic connection of the in-vehicle device to the mobile phone, the mobile phone connection request may be received, if the mobile phone connected with the request is the same device as the automatically connected mobile phone. (The Bluetooth address is the same), the connection request is received, otherwise the automatic connection will fail. At the same time, since the in-vehicle device supports SPP dev A, the dev A of the PDA phone may automatically connect to the SPP dev A of the in-vehicle device after pairing. At this time, the connection is rejected. If the connection request is not processed, the PDA phone is long. A state in which time cannot respond.
Introducing the compatibility brought by the protocol
Bluetooth technology is an open protocol. It draws on many mature protocols that have been widely used, such as Syncml. The Bluetooth OBEX protocol can be used to synchronize the update of personal information, such as vCard, which is combined with PBAP and OPP protocols. To encapsulate, download, and parse phonebook entries and call logs, these protocols have inherent compatibility issues. You need to delve into the introduced protocols and try to test more phones to try to improve the application. The following is an example of vCard analysis to illustrate the solution to this compatibility problem.
vCard is an electronic business card specification that defines the storage format of personal information data and the specification of the access interface. Now it is widely used in v2.1 and 3.0. For phonebook entries and call logs, the key information is name and phone number. And call time. A phone book entry with multiple phone numbers, we define it as a VCARD, and its phone number includes four attributes: home phone, work phone, mobile phone, and car phone.
The vCard looks like this:
BEGIN: VCARD
VERSION: 2.1
N; CHARSET=UTF-8; ENCODING=QUOTED-PRINTABLE;:=9A=6C=5E=FA=8F=89
TEL; CELL
TEL; WORK
END: VCARD
In the above vCard example, the name field is extracted as "Ma Jianhui" UTF-8 character 0x9A6C 0x5EFA 0x8F89. The compatibility of this part is that the character set and encoding method used by different mobile phones in encapsulating the person name field of the phone book entry are inconsistent, characters There are ASCII and UTF-8, the encoding method is 8BIT, QUOTED-PRINTABLEPRINTABLE, BASE64. It needs to be processed separately. For example, the above vCard name field needs to be processed = 9A=6C=5E=FA= 8F=89 is converted to 0x9A6C 0x5EFA 0x8F89, the processing code is as follows, the temp_name array is the unprocessed name string, and the processed name is placed in the NAME array:
If(temp_name[i]=='=')
{
If((temp_name[i+1]>=0x41)&&(temp_name[i+1]<=0x46))
Temp1=temp_name[i+1]-0x37;
Else if((temp_name[i+1]>=0x30)&&(temp_name[i+1]<=0x39))
Temp1=temp_name[i+1]-0x30;
If((temp_name[i+2]>=0x41)&&(temp_name[i+2]<=0x46))
Temp2=temp_name[i+2]-0x37;
Else if((temp_name[i+2]>=0x30)&&(temp_name[i+2]<=0x39))
Temp2=temp_name[i+2]-0x30;
NAME[name_len]=(temp1<<4)+temp2;
Name_len++;
i+=3;
}
In addition, some special circumstances need to be considered. For example, the name field of the Sony Erricson mobile phone book entry sometimes treats the space as 0xE38080, so if 0xE38080 is extracted, the special character needs to be replaced with a space 0x20, otherwise it will be treated as garbled.
For the extraction of the number field, the keywords are not only HOME, WORK, CELL, CAR, but also PREF and VOICE as keywords that can be recognized, and there are mobile phones without keywords, and the processing without keywords is CELL. Phone properties are fine.
Call time, the field is represented by X-IRMC-CALL-DATETIME. The standard format is as follows T1212, four bytes per year, two bytes each month and day, but for some mobile phones, the month and day do not strictly follow the The specification, month + day field has a total of two bytes or a total of three bytes, which requires special handling according to the characteristics of the month and day. The processing code is as follows, the number of bytes on the day of the month is temp_month_date_length, and is stored in the temp_month_date array.
If(temp_month_date_length==2)
{
Temp_month=temp_month_date[0]-0x30;
Temp_date=temp_month_date[1]-0x30;
}
Else if(temp_month_date_length==3)
{
If(temp_month_date[0]>0x31)//then the character must be month
{
//214-2 14
Temp_month=temp_month_date[0]-0x30;
Temp_date=(unsigned char)((temp_month_date[1]-0x30)*10+(temp_month_date[2]-0x30));
}
Else if(temp_month_date[1]>0x32)
{
//130-1 30
Temp_month=temp_month_date[0]-0x30;
Temp_date=(unsigned char)((temp_month_date[1]-0x30)*10+(temp_month_date[2]-0x30));
}
Else
{
//114 to month=11 date=4
Temp_month=(unsigned char)((temp_month_date[0]-0x30)*10+(temp_month_date[1]-0x30));
Temp_date=temp_month_date[2]-0x30;
If(temp_month>=11)
{
Temp_month=0;
Temp_date=0;
}
}
}
Conclusion
Compatibility is a difficult problem in the development of Bluetooth products. This paper analyzes the causes of compatibility problems and analyzes their solutions in combination with specific examples. It has good reference significance.
SHENZHEN YINZHIGUAN DIGITAL TECHNOLOGY CO.,LTD , http://www.yzgmusiccrown.com