By Paul Giletti, Vincent Richard (Dolphin Integration)
In mobile electronics, a single device suffices to cover various daily usages: calling, taking pictures, playing music, geolocating, etc… All of these common features should fit in one’s hand. To adequately implement these new functionalities, audio electronics must not be limited to basic plug and play functionalities any longer. Smartphone applications should be compliant with new user practices by enabling more interactivity and giving more possibilities to control the inner functionalities.
If we focus on the audio application domain, the new usages of the headset is an important concern for every system maker. In so many situations, the headset becomes an essential accessory which replaces the touchscreen of the device. Indeed, users now want to control their Smartphone without taking it out of their pocket for not only hand-free phone calls but also for other applications, such as voice recognition. Buttons on the hand-free module can be used to pick-up a new call or control volume, play or stop music, jump to next or previous tracks, as well as for more advanced control operations which can be imagined by customizing long or multiple touches.
Today, audio devices need to handle more functionalities between the headset and the audio converter, at least more that simply carrying the audio signal. But this capability cannot be handled otherwise than directly by the analog front-end. The audio converter needs to manage not only one hook button, but up to three buttons. Most of the time, this functionality is left to an external component but even when it is embedded in Integrated Components; the functionality is often limited to a dedicated headset and application schematic. The result is that each device uses its own headset, provided with the mobile phone or the tablet. As a consequence, users buying a new headset from a different maker generally lose the initial functionalities. The main risks are to have a non-working control button or a not recognized microphone by the application or, even worse, a notably deteriorated quality of sound.
The reasons are that no unified standard exists, neither for headset schematics nor for the connectors themselves. Different microphones may also have different electrical models, especially equivalent resistance and current consumption, leading to different detection conditions from one microphone to another. Added with the fact that different application schematics are used, it is merely impossible for one circuit to support all headset button modules. Moreover, the drivers of the application interface may be trapped by false or ambiguous detection sequences, which can lead to extra development cost and duration.
We will strive to detail in the following article the main issues and will highlight that solutions exit to achieve a robust, adaptive and easy to use design.
Different standards for an infinity of models and application schematics
The standards start with the connector. Two types of connector co-exist in the Headphone jack world: the TRRS and TRS. The TRS connector is only used for listening while the TRRS connector is used to listen and speak thanks to an additional path for the microphone data. Usually, the headset jack is a TRRS connection where the position of ground and microphone, unlike the left and right audio connections, varies from one maker to another. The sleeve and the last ring of the connector may be interchanged to connect microphone or ground. The choice of connection order thus depends on the hardware configuration, and headset makers need to provide adaptors for both standards.
Figure 1: Jack connector schematic
The whole story could have ended here. However, variations of headset electrical models are more difficult to handle. The communication between the headset and the audio converter is generally based on a voltage level detection of the microphone output or on a current level detection of the microphone bias input.
Each button of the headset is associated with a shunt resistor between microphone output and ground. So different voltage dividers are created under the microphone bias voltage, which create several microphone output levels when buttons are pressed and released as shown in the figure below.
Figure 2: Level variation at microphone output when buttons are pressed and released
The equivalent schematic of the headset module is presented in the next figure with its application schematic. The combination of the bias resistor and the headset module creates a voltage divider, where the output voltage changes depending on the equivalent resistances of the module. It clearly appears that whatever measurement the detection is based on (voltage level or current), the conditions of detection are greatly correlated with all schematic parameters, such as microphone equivalent resistance, biasing voltage and resistance.
Figure 3: Headset model and application schematic of microphone and button detection
Among the main headset makers, even the more popular ones, we find different switches and shunt resistors for each of them. According to tests made on a selection of headsets, it has been verified that the values of the external components are not identical from one maker to another, but also that the dispersion of the components may differ. The diversity of the headset electrical schematics leads to identifying key characteristics which should be analyzed before selecting the relevant detection block.
Let us begin with the biasing resistance, which is an important factor of variation. It has to be selected to fit with the gain of the microphone and its targeted biasing voltage. Typically, this resistor value is between 1 kΩ and 4.7 kΩ, so it has a significant impact on biasing current and microphone output level. As the detection module is sensitive to temperature and process variations, and as microphone biasing output is a regulated signal with its own intrinsic offset and load dependency, the microphone bias level needs to be shared by the headset application circuitry and the detection block to avoid any risks of false detection.
The second key characteristic is the microphone model, more precisely its equivalent resistance. The main concern is the difference observed between Electret and MEMS microphones. The first category has an equivalent resistance around 1.5 kΩ, sometimes down to 1.1 kΩ, while the second one consumes lower current, i.e. an equivalent resistance as large as 25 kΩ or 50 kΩ in biased conditions. Moreover, these different types of microphones have different biasing constraints in order to reach their optimum intrinsic sensitivity. As a result, one detection block, designed for an electret microphone, may not work in association with a MEMS microphone.
Detach IC from a specific detection scheme with an adaptable microphone and button detection system
For all these reasons, common solutions that support up to three buttons are designed for a specific application schematic only. This leads to making a specific design, targeting a well-defined architecture, a known microphone and biasing circuitry. This approach is of course more restrictive, risky and limits final users from benefiting from the so appreciated flexibility in the headset choice.
Moreover, even with a steady and well-defined application schematic, precision of biasing circuit and resistance may impact detection levels in a way where the final detection block may work only with a tight range of headsets.
In the development process of a System on Chip, for cost, delay or strategy reasons, the architecture should not be dependent on a type of microphone or on a specific application schematic. Dolphin Integration’s sCODa96-H1-LB-IO-VD.01 audio converter offers up to four combinations of detection with two levels of microphone bias output. All of them are suitable independently for MEMS or Electret microphones down to 1.1 kΩ. In its default configuration, it covers a wide range of headsets, suitable for leading smartphone and tablet makers. The microphone and 3-button detection module can be fully configured by the dedicated registers of the audio converter. The detection module of the sCODa96-H1-LB-IO-VD.01 audio CODEC is therefore able to address multiple application schematics, allowing a better design adaptability and limiting development risks. As a result, it also ensures a high compatibility coverage with various headsets of the market, whatever the type of microphone is used.
Beyond the adaptability: the key challenges for a robust detection feature
Robustness of the system depends on design analysis and optimization. Special care must be paid to on-chip as well as component dispersions. The error in the comparators (systematic or stochastic) needs to be minimized and characterized for a wide range of supply and biasing conditions. The reference design, and finally the mismatch of resistances and parasitic routing, must ensure the lowest detection dispersion. A stringent design process is thus required for avoiding design traps.
Another key issue of robustness is the ability of the detection system to filter false detections. Many artifacts are sources of temporary detection instability: for instance, the set-up time or stand-by delays of the detection block when internal signals have not reach their steady states, the settling time of microphone biasing which is highly dependent on the application schematic, or the mechanical bounces during jack insertion or button presses and releases. The use of a debounce technique is thus necessary to ensure steady states at the outputs of detection comparators. This is a first step to ensure a robust and easy to program detection sequence.
Figure 4: Measurement of level ripple during button pressure
At application processor interface, there is also no unified standard. Each audio device must use its specific drivers to handle jack detection and communication with the headset.
However, the detection principle does not differ much from one device to another. The audio interface sends dedicated interruptions to the application processor that will add the headset to its peripheral list. For button control, there is a need to separate press and release detection in order to detect long or short pressures of the buttons. In the case where no specific variable is defined by the application, the software interface may use a GPIO and define its own protocol and detection latency.
Nowadays, the driver should handle most of the detection: by controlling the detection sequence, the biasing microphone and the set-up latency. But the programming of a robust detection sequence may be greatly facilitated by the hardware. The whole sequence of detection can be divided into three consecutive phases:
- Jack detection
- Microphone detection
- Button detection
Indeed, no microphone detection is needed while no jack insertion has been detected before. And no button detection is needed when no microphone has been detected before. So, jack detection is a necessary condition to the microphone detection, and microphone detection is a necessary condition to button detection.
The sCODa96-H1-LB-IO-VD.01 audio converter discriminates unwanted detection and waits for successive detections of jack and microphone. It uses its own settling time latency so that the application may not be bothered by delay control or adjustment.
At the opposite, when the jack is removed, there is no need to wait for microphone detection interruptions. When the jack status is seen “removed”, no microphone or buttons can be detected.
For button press detection, as the user may arbitrarily press and release several buttons in an incoherent way, a preliminary state machine is implemented inside the detection block of the audio converter in order to avoid unwanted behavior. When several buttons are pressed at the same time, parallel resistances of button switches modify the microphone output level, and can distort the detection behavior. Each button needs to be taken successively, one after another, so that the pressure of one button waits for the state of release before another can be detected. In this way, the application receives robust and confirmed information from the audio converter and is not interrupted by unwanted detection.
Managing ON/OFF sequences to optimize power consumption
As power consumption has become a major concern in every portable device, the detection sequence should be designed for low power, for instance by automatically activating or deactivating the converter functionalities. The sCODa96-H1-LB-IO-VD.01 audio converter uses pre-configured deep-sleep and sleep modes to facilitate the programming of the driver and reduce overall consumption.
In deep-sleep mode, the application processor can only activate always-on features like jack detection, which is powered separately from the rest of the detection block. Always-on features also benefit from the low-power design techniques in power domain management and from Dolphin Integration’s know-how in regulation design and low-power standard-cells.
Once a jack is inserted in the device, the jack detection can be used to wake-up the audio converter or at least to activate sleep mode in which the application can bias the microphone and its detection circuit. Then, when a microphone is detected, the application can set the converter in normal mode and power the Analog-to-Digital Converter or Digital-to-Analog Converter.
The audio converter is therefore aware of its accessory environment and can react properly regardless the type of jack connector plugged into the socket. To enable final users to benefit from the best power autonomy, only necessary functions are turned on and off. In this way, the power consumption is optimized for all different audio usages of the media device.
In this disclosure, we have seen the principles and the main issues of the 3-type button headset detection. Consumption, robustness and flexibility are the main challenges to overcome for succeeding the integration of a headset detection block within the audio converter.
In its latest generation of audio converters, Dolphin Integration embed an advanced and easy-to-use microphone detection system. All issues and solutions discussed here are addressed to achieve the best robustness and adaptability.
The detection module is programmable to fit most application schematic and microphone types, whether MEMS or electret microphones. The default configuration supports a wide range of headsets and can be re-programmed to match custom headset requirements. Bounce filtering, false detection sorting and state machine prevent multi-buttons issues, ensure a right on first pass development and simplify the interface driver.
Furthermore, thanks to its low-power design technique, the always-on jack detection feature is very low power consuming and additional detection blocks may be powered only when needed. The sCODa96-H1-LB-IO-VD.01 audio converter is a reliable Silicon IP component for tablet, smartphone and smartwatch applications. It is a small area, high performance converter, designed at 28 nm and retargetable in all advanced CMOS nodes without any extra process option.
For more information please contact email@example.com. See all Dolphin Integration’s products on http://www.dolphin-integration.com/
About the Authors:
Paul Giletti - Analog design architect, Dolphin Integration
After a brief experience in I/O and physical design (2003-2004), Paul Giletti became an analog design engineer in Dolphin Integration. Specialized in delta-sigma converters and audio power amplifiers, its R&D works mainly focus on low area and low power design for high performance audio applications.
He graduated in electronic and signal processing from the Polytechnical National Institute of Toulouse (INPT-ENSEEIHT, 2003)
Vincent Richard – Product marketing manager, Dolphin Integration
He joins in 2012 the Mixed-Signal product line of Dolphin Integration. He is in charge of the marketing positioning and promotion of audio and measurement mixed-signal converters.
Mr. Richard is graduated of a Microelectronic Engineering Master degree from the engineering school of Polytech’Marseille, he completed his training with a diploma in Management of Technologies and Innovation from the Grenoble School of Management.