Design Differences Between Push-to-Talk and Hands-Free Remotes - Part 4

Push-to-talk (PTT) voice-operated systems require only one microphone to function as the user must press the button to use the system, meaning the remote will always be close to their mouth. This is not the case for handsfree remotes, where the system will often be sat in a different location in the living room, such as on a living room table, and the user can be speaking to the remote from any possible angle/direction.

Systems which use voice wakeup also need to be able to recognize the wakeup command when it is spoken. Such a system should use a multiple microphone array as this provides a better signal-to-noise ratio, meaning that recognition of the wake command is more accurate.

In systems equipped with Vesper’s ZPL™ the VM1010 microphone can work alongside one or two additional microphones which provide noise suppression. The VM1010 microphone behaves as an acoustic lookout which alerts the system when the external acoustic environment exceeds a set noise threshold. Following the alert, the signal processor is turned on to recognize voice activity and detect the wake command.

Vesper’s research has used 2 digital microphones working alongside a VM1010 microphone with the digital microphones used to perform beamforming algorithms to suppress noise. If the system does not require noise suppression via beamforming then only one additional microphone would suffice.

Despite the huge benefits it brings, integrating the VM1010 microphone into existing system designs requires very little to change. When compared to conventional capacitive MEMS microphones the VM1010 needs only an external PCB resistor, to set the noise threshold, and two more processor-based GPIO pins; these pins are connected to the Dout and Mode on the system to enable switching between Wake on Sound (WoS) and fully functioning modes.

When the microphone is in WoS mode the microphone runs digital signals through the Dout pin when a noise is registered. The processor then switches the Dout pin to digital throughput to switch the microphone to its normal, fully functioning mode. Following recognition of the voice command the processor then sets the Mode pin back to digital high, which results in the microphone returning to WoS mode.

The following sections cover the design parameters for the ZPL™ system.

Battery Size (mAh)

Conventional TV remotes usually run using either 2 AAA or 2 AA alkaline batteries, with voltages of 1.5 V each, with the anticipated battery lifetime for the system dependent on the battery size in terms of mA hours.

AA batteries tend to be the industry standard, e.g. in the xFinity TV remote, some manufacturers prefer to use AAA as this facilitates a more compact remote design, despite these batteries having half the capacity, and therefore life time, of AA batteries.

Some remote systems, such as the Logitech Harmony Elite Remote or Apple TV remote, operate using a rechargeable Lithium-ion battery – e.g. the CR2032 which operates at 1050 mAh at 3.7 V.

Even these devices with rechargeable batteries need to last at least a couple of weeks on a single charge as consumers often leave them on the couch instead of returning them to the charging base daily.

In all these cases, Wake on Sound mode reduces the need to replace batteries more often making them last for months and even up to a year.

Vesper’s VM1010 microphone alongside ultra-low power digital SOCs can be operated using just a coin-cell battery, allowing extremely compact systems to be produced that still run optimally.

Figure 7 demonstrates the effect that battery size has on battery lifetime when in WoS mode. Batteries of any size will have a longer lifetime when running on WoS mode when compared to other power management methods, even in cases where there is 5 hours TV playback in the background.

Battery Life savings Vs Battery size for a WoS solution.

Figure 7: Battery Life savings Vs Battery size for a WoS solution.

Low-Power Wireless Technologies

Ultra-low power communication methods such as Zigbee RF4CE, IrDA, Wi-Fi and Bluetooth Low Energy (BLE) can all provide energy harvesting at low duty cycles and the ability to stay in sleep mode for long time periods. The power savings provided by WoS mode work well with low power wireless technologies for voice-operated systems, and choosing a transport mechanism that runs on low standby current and with reduced latency improves battery lifetime alongside an enhanced user experience.

The voice-operated remote only needs to be in full power mode whilst listening for voice commands, and this represents only a fraction of the total TV viewing time in the average household. For this reason, to provide a handsfree system with a good user experience, the wireless communication method used should have minimal voice processing latency and optimized battery lifetimes.

Table 1, as shown below, illustrates the different technologies available alongside their latency and their power consumption. Figure 8 shows a comparison of these technologies regarding battery life.

Zigbee RF4CE (Radio frequency for Consumer Electronics) has completely replaced IR technology recently, because this communication method does not require there to be a line of sight between the remote and the TV.

BLE provides the best current consumption out of the technologies discussed and has a minimum latency of 2.5 ms – this is key to providing an optimum user experience for far-field voice operated remotes.

BLE technology, the rapid wakeup time of 300 μs for the VM1010, and the low latency over SoC processors provide optimized user experience for hands-free remote systems. ZPL™ provides all of this at significantly reduced power consumption when used with ultra-low power wireless communication methods.

Table 1: Comparison of different Low Energy communication protocols.

Parameter / Protocol BLE RF4CE IrDA Wi-Fi
Standby current (mA) 0.0001 0.0018 N/A 10
Tx Current (mA) 8 30 1.95 100
Datarate (bps) 960 250 k 121 40 M
latency (msec) 2.5 20 25 1.5


Battery Life comparison with different communication protocols.

Figure 8: Battery Life comparison with different communication protocols.

Other Components

Some Push to Talk remotes use an accelerometer in order to wake up the system when the remote is lifted, prior to the button being pushed. Using a handsfree remote equipped with a VM1010 microphone removes the need to use an accelerometer.

Whilst accelerometers tend to use very little power (in the order of μA), removing this part can result in overall BOM savings in the design of the system, and make remote production more economical.

Download the Full White Paper Here

This information has been sourced, reviewed and adapted from materials provided by Vesper Technologies, Inc.

For more information on this source, please visit Vesper Technologies, Inc.


Please use one of the following formats to cite this article in your essay, paper or report:

  • APA

    Vesper Technologies, Inc.. (2019, April 04). Design Differences Between Push-to-Talk and Hands-Free Remotes - Part 4. AZoSensors. Retrieved on April 19, 2024 from

  • MLA

    Vesper Technologies, Inc.. "Design Differences Between Push-to-Talk and Hands-Free Remotes - Part 4". AZoSensors. 19 April 2024. <>.

  • Chicago

    Vesper Technologies, Inc.. "Design Differences Between Push-to-Talk and Hands-Free Remotes - Part 4". AZoSensors. (accessed April 19, 2024).

  • Harvard

    Vesper Technologies, Inc.. 2019. Design Differences Between Push-to-Talk and Hands-Free Remotes - Part 4. AZoSensors, viewed 19 April 2024,

Tell Us What You Think

Do you have a review, update or anything you would like to add to this article?

Leave your feedback
Your comment type

While we only use edited and approved content for Azthena answers, it may on occasions provide incorrect responses. Please confirm any data provided with the related suppliers or authors. We do not provide medical advice, if you search for medical information you must always consult a medical professional before acting on any information provided.

Your questions, but not your email details will be shared with OpenAI and retained for 30 days in accordance with their privacy principles.

Please do not ask questions that use sensitive or confidential information.

Read the full Terms & Conditions.