TWS headset solution development

With the advent of the era of all-round mobile communication, light and compact Bluetooth products are receiving more and more favor. In recent years, Bluetooth TWS headsets and audio gateway products have developed rapidly and become a bright spot in the Bluetooth field. The Bluetooth TWS headset and audio gateway can guarantee a fast and stable voice connection within a range of 10m. The audio gateway is not only a wireless terminal, it is directly connected to the Bluetooth TWS headset for conversation. Its more important function is to serve as an access point for earphones and expand the short distance of GSM modules, fixed voice terminals and other devices.

Bluetooth is a 214GHz short-distance radio frequency wireless communication technology that can be freely used around the world. It uses short-distance, low-cost wireless connections to replace cable connections, thus providing support for existing data networks and small peripheral devices. Interfaces provide unified connectivity. Bluetooth HeadSet applies Bluetooth technology to realize wireless communication between TWS Bluetooth headsets and audio gateways (such as mobile phones), thereby providing the function of hands-free answering of mobile phone calls. In the Bluetooth HeadSet model, two roles need to be clarified first: one is AG (AudioGateway), which acts as an audio gateway and can be used as both audio input and audio output; the other is HS (HeadSet), which is the TWS Bluetooth headset, which is A device that acts as Bluetooth remote audio input and output, and provides some remote control methods.

1. TWS headset development process

In the development of Bluetooth TWS headsets (Bluetoothheadset, HS) and audio gateways (audiogateway, AG), we adopted the fully embedded Bluetooth development solution of the British CSR company and designed it with the BlueCore22External Bluetooth chip as the core. CSR provides developers with several basic profile lower-level firmware (fireware) to realize the functions of the Bluetooth core protocol stack. The focus of our work is to use the application API provided by it based on the headset profile firmware to write earphones and audio gateway applications that are suitable for actual needs and comply with Bluetooth specifications, and combine them with hardware entities. Finally, Completely realize all functions of HS/AG. Writing a Bluetooth embedded program on a PC requires a Linux cross-compilation environment. The corresponding bluetooth debugging, emulation, and downloading software are all based on the Windows operating system. The way to solve this contradiction is to use Cygwin software, which provides a Unix system library based on Win32API, which can simulate a Linux environment running on a Windows platform. Enter the command makebc02 in Cygwin, and the application and corresponding firmware will be compiled into a .

2. TWS Bluetooth headset hardware development

CSR's BlueCore22External Bluetooth chip is fully compatible with Bluetooth V1.1 and V1.2 specifications. It integrates radio frequency, baseband signal processor, microcontroller and 32KBRAM, and an external 8MB Flash is used to store Bluetooth protocol stack and applications. The air interface of the Bluetooth module provides three compression encoding methods: 64Kbps A-law PCM, μ-law PCM and CVSD (continuously variable slope delta modulation). Therefore, according to the encoding method selected by the software, the corresponding codec with performance above 64Kbps should be used. . We adopt a fully embedded development method, all Bluetooth software stacks and applications run on a single chip, and interact with users through buttons and LEDs.

3. Architecture of TWS Bluetooth headset software

The Bluetooth protocol architecture adopts a layered approach, including the Bluetooth core protocol and some special protocols. The headset profile defines the Bluetooth specification protocol used in HS and AG applications and indicates some messages and processes in the Bluetooth specification. It can be regarded as a vertical section of the protocol stack. Mono headphones and audio gateways are fully compatible with the headset profile in the Bluetooth specification. Their software systems are basically the same, but the programs at the application layer are different.

Among them, baseband, link management (LMP), logical link control and adaptation protocol (L2CAP) and service search protocol (SDP) are the core parts of the Bluetooth stack, which respectively complete frequency hopping and data frame disassembly and assembly, data flow filtering and Transmission, link control, quality of service (QoS), protocol multiplexing, service discovery and other functions. The Serial Cable Emulation Protocol (FCCOMM) provides cable replacement capabilities for advanced services that use serial lines as the transport mechanism.

The Bluetooth baseband supports both ACL (asynchronous connectionless) and SCO (synchronous connection 2 oriented) connections on the same radio frequency link. ACL is used for asynchronous data transmission, and SCO is suitable for synchronous voice. Between the HS and AG, the application relies on the ACL-based RFCOMM connection to send and receive AT commands, perform call responses and exchange control operations such as MIC and speaker volume gain parameters. The voice stream based on SCO is directly sent to the baseband transmission by the upper layer, which is also the key to ensuring the real-time performance of voice processing.

According to the profile regulations, both HS and AG can initiate the establishment of ACL. After the ACL link is successfully established, you can create a SCO whenever you want. It can be that the AG actively initiates SCO, or it can be that after receiving AT+AKPD from the HS (indicating that the headset TALK key is triggered), the AG responds to establish SCO, but in essence, only the AG has the final decision when to generate SCO. Likewise, the removal of ACL and SCO is also the responsibility of AG.

4. Software implementation of Bluetooth link building process

The bluetooth application program runs on the virtual machine in the chip, and adopts message (message) driving mode. The scheduler is responsible for collecting message events and starting corresponding task functions.

4.1 Initialization (initialisation)

First initialize the headset library function, register the corresponding headset service with SDP, and set the device type (classofdevice). If there is a device that has been paired, the application will send a CM_ADD_SM_DEVICE_REQ message to register it as a trusted device in the link manager, thereby simplifying the authentication steps of both parties and speeding up the link establishment.

4.2 Pairing

The pairing request CM_PAIR_REQ puts the device into pairing mode, and then the Bluetooth address of the other party can be queried, and a personal identification number (PIN) can be exchanged for authentication. Only when the PIN codes entered by the devices at both ends are consistent can the authentication succeed. Finally, the link key (linkkey) used for communication is generated based on the PIN code, Bluetooth address and random number, and the PsStore() function is called to store it in Flash for re-use. Used when connecting.

4.3 Connecting

Either side can request to establish an RFCOMM connection as a master or a slave. It is worth noting that only the AG can then issue CM_SCO_CONNECT_REQ to request the establishment of a SCO connection. If both parties get the correct status returned, the voice link is established.

5. Principle design scheme of TWS Bluetooth headset system

His functional modules include antenna unit, link controller, link management, and software functions.

5.1 Wireless Technical Specifications

The Bluetooth antenna belongs to the microstrip antenna, and the Bluetooth wireless interface is designed based on the conventional wireless transmission power of 0dBm, which complies with the regulations of the ISM frequency band of the United States Federal Communications Commission (FCC). The application of spread spectrum technology makes the power increase to 100dBm, which can meet the needs of different countries. In Japan, Spain, and France, due to the relatively narrow frequency bands stipulated locally, it can be realized by internal software conversion.

5.2 Bluetooth baseband technical specification

The baseband describes the digital signal processing part of the device, that is, the Bluetooth link controller, which completes the baseband protocol and other underlying link procedures. It mainly includes the following aspects:

(1) Establishment of network connection; (2) Link type and grouping type: The link type determines which grouping mode can be used on a specific link. Bluetooth baseband technology supports two link types: synchronous connection-oriented Type SCO (mainly used for voice) and asynchronous connectionless type ACL (mainly used for packet data). (3) Error correction: The baseband controller adopts three error correction methods: 1ö3 rate forward error correction coding (FEC), 2ö3 rate forward error correction coding (FEC), and automatic request retransmission (ACL) of data. (4) Authentication and encryption: The Bluetooth baseband part provides protection and information confidentiality mechanisms for users at the physical layer. Authentication is based on a "request-response" algorithm. Authentication is a key part of the bluetooth system, which allows users to establish a trust domain for personal bluetooth devices, such as only allowing the owner's own laptop to communicate through the owner's own mobile phone. Encryption is used to protect connected personal information. Keys are managed at a high level of the program. Network transmission protocols and applications can provide users with a strong security mechanism.

6. Protocol stack structure of HeadSet application model

The Bluetooth protocol stack adopts a layered structure, as shown in Figure 2.

The functions of each layer are briefly introduced as follows:

Baseband is the physical layer of Bluetooth. It is mainly responsible for the encoding and decoding of physical channels, underlying timing control, and link management during the transmission of a single data packet. It adds address domains and control domains to the original payload data. and perform error detection or correction.

The LC (LinkControl) layer is responsible for responding to upper-layer LM commands during the transmission of a batch of data packets (such as executing LM commands for establishing transmission links for data packets, maintaining links, etc.).

The LM (LinkManager) layer is the link management layer protocol of the Bluetooth protocol stack. It is responsible for translating upper-layer HCI commands into operations acceptable to the baseband, establishing ACL (data) and SCO (voice) links, and putting Bluetooth devices into an energy-saving state. working mode etc.

ME (ManagementEntity) is a management entity. Its function is to discover remote devices and establish connections with them. It provides interface APIs for the application layer and other system layers that need to manage Bluetooth piconet.

SE (SecurityManager) and ME work together to allow applications to set authentication and encryption, and the real authentication and encryption are implemented by hardware.

The Logical Link Control Protocol (L2CAP) uses the concept of channels to establish different paths between different applications of Bluetooth devices, but it only supports ACL links. The main function is to provide protocol multiplexing for high-level application layers, allowing them to share low-level data links. It also performs grouping and reassembly operations on large data packets that exceed the support of the lower layer, and at the same time provides quality management for the upper layer services.

Service Discovery Protocol (SDP) is an extremely important part, which provides a way for SDP clients to inquire about service information from SDP servers. A server maintains a service record list, which describes the service characteristics related to the server. The client can request service information, services and service characteristics from the server record by sending an SDP request, and establish a connection between two or more Bluetooth devices after querying.

RFCOMM provides serial port simulation, and the lower layer of Bluetooth is responsible for providing wireless connection methods. However, many traditional applications have been developed based on wired methods before this. If Bluetooth cannot solve the adaptation problem to traditional protocols, it will be difficult to become a widely used standard. For this reason, Bluetooth has developed an adaptation protocol like RFCOMM to support traditional applications.

HeadSet control layer: Mainly implements the functions defined by the Profile of HeadSet, such as volume control of the MIC (microphone) of the audio gateway, volume control of the SPK (speaker), establishment and release of SCO links, and audio transfer, etc.

Audio port application layer: It is some application-specific functions. The application characteristics that the headset application layer must implement are:

(1) An audio link can be established when receiving a call from AG, and the audio link can be disconnected after the call ends. (2) It can initiate a call to a distant place, and it can also disconnect the audio link after the call is over. (3) Audio link transfer. (4) Volume control of the remote AG.

7. Link building of Bluetooth HeadSet

When the Bluetooth audio gateway AG receives a call and initiates a link with the HS, in order to make the application layer voice communication reliable, the Bluetooth protocol stack needs to establish a reliable communication link. According to the operation of the Bluetooth protocol stack, the link establishment from the bottom layer to the high layer generally needs to go through the following processes:

(1) Establish ACL, which is the baseband layer link; (2) Establish the L2CAP layer link; (3) Perform the SDP query process; (4) Establish the RFCOMM layer link; (5) After the RFCOMM link is established, Transmit some AT commands of the HeadSet control layer through the RFCOMM channel; (6) establish the SCO link; (7) perform audio communication between Bluetooth HS and AG according to the actions of the application layer. The link building process of the Bluetooth protocol stack is discussed in detail as follows.

7.1 Establish ACL, that is, the link of the baseband layer

When the AG receives a call, it first establishes an ACL link with the HS. The HS and the AG need to be pre-bound, or the HS that was originally in a dormant state needs to be awakened. This is done through the page process. When using the page process to establish the ACL, AG is defined as the Master role, so the AG first initiates a query and obtains the Bluetooth address of the HS by querying the AG. Then the AG initiates a page process to the queried HS driven by the application layer. When receiving the response returned by the HS, the ACL link between the AG and the HS has been successfully established.

Once the ACL link is established, it can be used to send ringing signals. The sending of the ringing signal is accomplished through the AT command RING. Ringing signals can also be sent on the SCO link.

7.2 Establish the link of L2CAP layer

After the ACL link is completed, then build the L2CAP link. AG first sends a link request signaling on the signaling channel, requesting the establishment of L2CAP with channel label 0x0040 (0x0001~0x003F is reserved by the protocol and cannot be dynamically allocated, 0x0040~0xFFFF can be freely allocated), the PSM (Protocol Service Complex) of this channel Use ) to mark 0001. When the other party returns a link response signal, it indicates that the 0x0040 channel has been established. Then configure this channel. After configuring the channel, you can use this L2CAP channel with CID 0x0040 to perform SDP query.

7.3 SDP query process

Use the L2CAP channel with CID 0x0040 to perform the SDP query process. First, the AG sends an SDP query packet on this L2CAP channel. The SDP query packet will query whether the SDP server HS has the required services. If the query is successful, create another L2CAP link numbered 0x0041 on the ACL link. The PSM of this channel is 0003, which is used to transmit RFCOMM data streams. At the same time, disconnect the L2CAP link numbered 0x0040 used for SDP query.

7.4 Establish the link of RFCOMM layer

After the L2CAP channel with CID 0x0041 is established, the RFCOMM link establishment process follows, as shown in Figure 3. First, a control channel is established. The link establishment initiator AG sends a SABM frame on the channel, which requires the establishment of Channel 0 on the RFCOMM layer. If the responder HS wishes to establish a link, a UA frame is returned, indicating that the RFCOMM channel Channel 0 has been established. . This channel is a control channel and is used to transmit UIH frames carrying control messages and commands. If the responder HS does not wish to establish a link, a DM frame is returned.

Secondly, the data channel is established. First, the parameters of the data transmission channel are negotiated. The negotiation command PN parameters include the priority of the channel Channel1 to be established, the maximum frame length, etc. After the two parties negotiate, the channel Channel1 for transmitting data is established.

After the data channel of the RFCOMM layer is established, the control commands of the HeadSet control layer are transmitted. That is, the UIH frame is used to transmit commands such as AT+CKPD=200 on the data transmission channel Channel1. After receiving the OK response from the other party, the SCO link can be established.

7.5 Establish SCO link

During initialization, HCI sends a WRITE_VOICE_SETTING command to set the audio state. When receiving the request from AG to establish a SCO link, if HS allows, send a received HCI command. After the command is completed, the SCO link for transmitting audio signals is activated. Once built, voice communication can be carried out at this time.

8. State machine design of Bluetooth application layer

After the communication link of the protocol stack is established, application layer communication can be carried out. The application layer has a main state machine running, as shown in Figure 4. According to the user's actions and the commands sent by the AG, the HS application process will run between states. There may already be an ACL link between HS and AG in the idle state, but no RFCOMM channel is established, and no SCO link for audio signals exists. When the AG responds to internal events or user requests, it initiates a link establishment request. When the HS receives the link establishment request, the HS and AG start to build ACL, L2CAP, and RFCOMM links. After the RFCOMM channel is established, the AG sends one or more An AT+RING ringing instruction command notifies the HS user that an incoming audio link has arrived. At this point the state will turn to the incoming call ringing state.

Incoming call ringing state At this time, the audio gateway AG has established the ACL and RFCOMM channels with the HS, and the HS has received the ringing signal, which indicates that the audio gateway requires the establishment of an SCO link. If the user does not respond to the ringing, the audio gateway will The RFCOMM channel will be terminated, and the state will return to the idle state. If the user presses the Bluetooth button on the HS, it means that the user accepts the incoming audio link request. At this time, the HS will send the AT control command AT+CKPD to the AG. At this time A SCO link will be established between the two, and the status will be transferred to the linked status.

Call state When the HS user presses the Bluetooth button on the HS, the user sends a request to call the audio gateway, at this time, the HS will first establish an ACL link, and then perform SDP query on the audio gateway. If the SDP query is successful, the HS opens the RFCOMM channel linked to the AG and sends the AT command + CKPD to request the establishment of the SCO audio link. When the SCO link is established, the state will be transferred to the connected state. If the SCO link establishment fails, the state will be transferred to the idle state.

Link state In the link state, ACL, L2CAP, and RFCOMM have been established, SDP query has been executed, and the audio call is ready. If the user speaks to the HS, the voice will be transmitted to the AG through the SCO link, and the voice will be transmitted to the remote end through the AG.

Link disconnection status Link disconnection can be accomplished through the Bluetooth key on the HS, or it can be triggered by internal events of the AG or user intervention. Regardless of the cause, it is essentially the result of AG link release. If the HS sends a disconnection request, and sends an AT command +CKPD to the audio gateway to request the audio gateway to disconnect, then the audio gateway disconnects the SCO link and the RFCOMM channel. When RFCOMM is disconnected, the state will transition to the idle state. The ACL link may be disconnected or connected.

9. Implementation of Bluetooth HeadSet

Take Motorola's Bluetooth solution as an example. Motorola is very experienced in advanced radio frequency technology. Motorola's Bluetooth solution can use UART, RS232, USB or SPI to connect to the main processor, and the main processor can handle functions such as the stack on the Bluetooth protocol and the interface of the main controller through these interfaces; and this Bluetooth solution is responsible for executing the next The rest of the stack (host controller interface, link manager protocol, baseband and radio) functions. It also adopts Motorola's MCORETM32-bit Simplified Instruction Set Computing (SISC) processor core, which contains a highly flexible set of peripheral devices, suitable for many different embedded Bluetooth applications.

Summarize

In recent years, the rapid development of mobile communication, portable computer and the Internet has made people's demand for various data information transfers other than telephone communication increasing. "Bluetooth" technology connects various portable computers and cellular mobile phones with wireless circuits, integrating computers and communications more closely, allowing people to exchange and transmit data information anytime and anywhere.

The above are the details of the TWS headset solution introduced to you by Shenzhen Zuchuang Microelectronics Co., Ltd. If you have Bluetooth TWS headset development needs, you can rest assured to leave it to us. We have rich experience in customized electronic product development and can evaluate the development cycle and IC price as soon as possible, and can also calculate PCBA quotations. We are a number of chip agents at home and abroad: Songhan, Yingguang, Jieli, Ankai, Quanzhi, realtek, with MCU, voice IC, Bluetooth IC and module, wifi module. Our development capabilities cover PCB design, single-chip microcomputer development, Bluetooth technology development, software customization development, APP customization development, WeChat official account development and other hardware and software design. It can also undertake the research and development of smart electronic products, the design of household appliances, the development of beauty equipment, the development of Internet of Things applications, the design of smart home solutions, the development of TWS earphones, the development of Bluetooth earphone speakers, the development of children's toys, and the development of electronic education products.