Deep Research on Ultra-Small Wireless Modules for G.729 Voice and MEMS Ear Devices

Executive summary

I interpreted “USID” here as an ultra-small wireless identification or communication device/module rather than a formal semiconductor category name. In practice, the relevant market splits into four very different families: implant-grade MedRadio/MICS radios, ultra-small BLE SoCs, small Wi-Fi/Bluetooth modules, and batteryless RFID/BLE tags. Across the catalog parts I found, the Microchip ZL70323 / ZL70103 family is the only one explicitly positioned for implantable medical telemetry. For non-implant prototyping, the strongest active-radio candidates are Atmosic ATM33e, Silicon Labs EFR32BG22, Nordic nRF52811, Espressif ESP32-C6, u-blox NINA-W10, and Murata Type 2FY, depending on whether you prioritize power, package size, or native IP transport. None of the surveyed radios advertises native G.729 encode/decode in vendor documentation; their real role is to carry G.729 frames or PCM, while codec work remains on a host CPU/MCU/DSP. G.729 itself is an 8 kbit/s codec carried in RTP with 10 ms frames and a default 20 ms packetization interval, so link throughput is usually not the limiting factor; interfaces, power, and latency are.

For the acoustic path, the most relevant commercially documented MEMS speaker/receiver parts for ear- canal-scale assemblies are xMEMS Cowell, xMEMS Lassen, USound Conamara, USound Achelous, and USound Adap. On the microphone side, the smallest practical, publicly documented choices are not bare die but chip-scale packaged MEMS microphones, including Knowles SPH0645LM4H-B (I2S), ST MP23DB02MM (PDM), Knowles SPM0687LR5H-1 (analog), and newer small Knowles digital parts in the company’s official selection guide. This is an important constraint: in the public market, what is realistically available is tiny packaged MEMS, not open-catalog bare die for implantation.

The biggest bottom-line finding is about power. Ambient-harvested or batteryless parts are compelling for ID, sensing, and intermittent beaconing, but they are a poor fit for continuous implanted voice playback. Atmosic’s very low-power ATM33e still draws about 1.4 mA active RX including PMU at 3 V; xMEMS Cowell plus its reference amplifier path is about 1.2–1.32 mA at 3.6 V, and USound’s Achelous plus its reference driver is documented at 13.6 mW under representative audio conditions. Simple datasheet arithmetic therefore puts even a receive-only speech device in the multi-milliwatt continuous regime before adding codec compute, microphone uplink, safety margins, loss in wireless powering, and hermetic/ biocompatible packaging. Batteryless tags such as Wiliot IoT Pixel, ONiO.zero, EM4325, and Hitachi µ- Chip are therefore not credible choices for continuous G.729 voice streaming into an implanted ear device.

The practical ranking is therefore straightforward. If the requirement is closest to a true implantable telemetry link, start from ZL70323 on the implanted side and ZL70123/ZL70103 ADK on the external side, then add a separate MCU/audio front end and a dedicated MEMS-speaker driver. If the requirement is a small active prototype that can really carry G.729 from a computer, use ESP32-C6, u-blox NINA-W10, or Murata Type 2FY + host CPU for Wi-Fi/IP, or ATM33e / EFR32BG22 for lower-power custom BLE transport.

If the requirement is batteryless, the honest answer is that current catalog parts support ID/sensing/ intermittent packets, not continuous narrowband voice playback.

Scenario	Best-fit combination	Why it is the best fit	Main limitation	Source
Closest to a true implantable RF path	Microchip ZL70323 implant module + external base station using ZL70123/ZL70103 ADK + separate MCU/audio front end + xMEMS Cowell or USound Achelous/ Conamara driver path	Only surveyed family explicitly targeted at implantable medical telemetry; MedRadio/ MICS band and implant-grade module ecosystem	No native G.729 codec, no direct mic/speaker interface, still needs power source and custom packaging	5
Small active prototype with IP transport	ESP32-C6 + PDM or I2S mic + external DAC/driver + xMEMS/USound speaker path	Native Wi-Fi makes RTP/IP carriage of G. 729 easiest	Power is too high for realistic batteryless or implant use	6
Lowest-power active BLE build	Atmosic ATM33e or EFR32BG22 + PDM mic + external speaker driver	Strong low-power numbers; both expose audio-relevant interfaces	Still active, not ambient- batteryless for continuous voice	7
Batteryless ID or sensing only	ONiO.zero, Wiliot Pixel, EM4325, Hitachi µ-Chip	Excellent for harvested-energy tags and identifiers	Not credible for continuous G.729 voice streaming	8

The architecture that actually fits the requirement

The requirement combines four layers that are often confused in component searches: voice codec, transport radio, audio interfaces, and electroacoustic transducers. G.729 is just the speech codec. It produces 10-octet speech frames every 10 ms, is defined for an 8,000 Hz timestamp clock, and is commonly packetized at 20 ms in RTP. That means the radio does not need extraordinary bandwidth. What it does need is a clean way to carry either RTP/IP packets or a custom framed payload, while the local electronics still need to handle speaker drive voltages, microphone capture, buffering, and latency management.

A second distinction matters even more: an ear-canal insert, an IEM/earbud module, and a true active implantable medical device are not the same engineering class. The microphone and MEMS speaker datasheets surveyed here describe applications such as TWS earbuds, IEMs, hearing-aid-class devices, wearables, ANC headsets, and audio glasses. The implantable-radio datasheets describe telemetry links for pacemakers, defibrillators, neurostimulators, bedside monitors, programmers, and patient controllers. In other words, the available market already splits into implant radios on one side and consumer/ medical-acoustic MEMS parts on the other. Combining them into an actual implanted voice device would require substantial additional engineering beyond catalog selection.

$Textruta: CPU or VoIP host\nG.729 encode/decode\nRTP or custom packetizer Wireless link\nWi-Fi / BLE / MedRadio Implanted or in-ear radio module\nUSID candidate Local MCU or audio front end\nbuffering, framing, control$ $Textruta: Playback path\nDAC or line-out MEMS speaker driver\nAptos/Aptos2 / Tarvos / boost amp MEMS ear receiver / speaker$

The architecture above also explains the most important product-selection result in this report: no catalog radio here directly drives a MEMS speaker. A MEMS microphone may connect directly to a radio/SoC only if the SoC exposes the right digital input, such as PDM or I2S, or an analog front end with adequate noise performance. The speaker side is harder. Piezo/MEMS speakers are generally driven as capacitive high- voltage loads, so they require either a dedicated amplifier IC or a suitably conditioned line-level source.

Even xMEMS’ new “amplifier-less” Lassen is only “amplifier-less” in the specific sense that it can accept a standard 1 Vrms audio output without an extra high-voltage companion amp; it is still a 6–20 kHz tweeter, not a full-band speech receiver.

Wireless USID and radio candidates

The table below focuses on small wireless parts that could plausibly sit in, near, or upstream of an ear- canal audio assembly. The Source column is the clickable datasheet/product reference.

Model

Manufacturer

RF / protocol

Package or module size

Host and

audio- relevant interfaces

Power notes

How it fits G.729

Source

ZL70323

MiniSIM

Microchip

MedRadio/ MICS

implant telemetry; official product page highlights 18.18, 40,

200, 400

kbit/s raw data rates

Public datasheet summaries describe 4.5

× 5.5 × 1.6

mm ultracompact implant module

Implant module exposes a host interface around the ZL70103

core; public pad references show SPI signals and supply pins; no direct audio interface is documented

Official pages call it ultra-low- power; public industry reporting describes sub-6 mA active and

~10 nA sleep, but the vendor pages surfaced here emphasize implant use and data- rate family rather than a complete public power table

Best implant- grade radio choice, but not a G.729 codec and not a direct mic/ speaker interface; it needs a companion MCU/audio path

ATM33e

Series

Atmosic

Bluetooth

5.3 with integrated energy harvesting support

5 × 5 mm, 40-pin QFN

I2C, I2S, SPI, UART, PWM, GPIO;

documented fixed audio clocks for PDM and I2S

Radio-only about 0.85

mA RX, 2.5

mA TX @ 0 dBm; SoC active about

1.4 mA RX,

3.0 mA TX @ 0 dBm, plus harvested- energy modes

Excellent low-power active custom BLE carrier for G.729

frames; still an active device, not a true ambient batteryless continuous- audio solution

Model

Manufacturer

RF / protocol

Package or module size

Host and

audio- relevant interfaces

Power notes

How it fits G.729

Source

EFR32BG22

Silicon Labs

Bluetooth LE / proprietary

2.4 GHz

4 × 4 mm

TQFN32 or 5

× 5 mm QFN40

PDM

microphone interface, and USARTs that support I2S, plus ADC/ IADC and SPI/I²C

About 3.6

mA RX, 4.1

mA TX @ 0 dBm, 1.40

µA EM2 with RAM

retention

Strong choice for custom BLE

transport

of G.729

frames and direct PDM mic attachment, but still needs external speaker driver and probably external DAC/codec

nRF52811

Nordic Semiconductor

Bluetooth

5.1 /

802.15.4 / proprietary

2.4 GHz

2.482 ×

2.464 mm WLCSP, also 5 × 5 and 6 × 6 QFN variants

PDM digital mic interface, SAADC, SPI, I²C, UART;

no integrated I2S in the product spec surfaced here

About 4.6 mA TX @ 0 dBm and 4.6 mA RX; very small footprint

Attractive when size is paramount and PDM mic input is enough, but weaker for speaker playback because it lacks a native I2S audio path

Model

Manufacturer

RF / protocol

Package or module size

Host and

audio- relevant interfaces

Power notes

How it fits G.729

Source

ESP32-C6

Espressif

Wi-Fi 6 2.4 GHz + BLE

5.3 + 802.15.4

5 × 5 mm QFN

Native I2S, I²C, SPI,

ADC, plus Wi-Fi/IP stack

High compared with implant radios: about 78 mA Wi-Fi RX, 71 mA

BLE RX, 130 mA BLE TX

@ 0 dBm, 7

µA deep sleep

Best catalog fit for carrying G. 729 over IP/RTP

from a computer, because Wi- Fi is native; too power- hungry for realistic implantable or batteryless ambitions

NINA-W10

series

u-blox

Wi-Fi 802.11b/g/ n + Bluetooth

4.2 stand- alone module

10.0 × 10.6 ×

2.2 mm for NINA-W101, other variants larger

Stand-alone module with open CPU; exposes UART, SPI, I²C, I2S, ADC, DAC, GPIO

Product summary lists about 190 mA Wi-

Fi and 130 mA BLE @ 0

dBm; 5 µA hibernate

Not implant- scale, but a practical module- level Wi-Fi/ Bluetooth audio prototype base if you want to run the application on the radio module itself

Model

Manufacturer

RF / protocol

Package or module size

Host and

audio- relevant interfaces

Power notes

How it fits G.729

Source

Type 2FY

Murata

Wi-Fi 6/6E + Bluetooth

5.4 module based on Infineon CYW55513

7.9 × 7.3 ×

1.1 mm

Wi-Fi side uses SDIO; Bluetooth side supports UART, PCM,

and I2S for audio data; module has no onboard processor

Product brief emphasizes small shielded module and reference certifications rather than end- application power

Excellent host- assisted transport module if an external CPU

already handles G. 729 and IP/ Bluetooth stack work; not a standalone implant SoC

One consistent pattern emerges from the vendor documents: G.729 is not a built-in feature of these radios. The MedRadio family gives you an implant telemetry link. The BLE SoCs give you small, low-power packet radios with some audio-friendly interfaces. The Wi-Fi modules make IP/RTP carriage straightforward. But in every case, a host processor or external DSP still does the actual codec work. For a computer- originated voice stream, that is usually acceptable, because the CPU can encode/decode G.729 and the device can simply receive either G.729 packets or already-decoded PCM.

MEMS microphones and ear-canal speaker candidates

A key market reality is that publicly orderable “chip-only” MEMS audio parts are generally documented as tiny packaged devices, not exposed bare die. The smallest realistic options in open vendor literature are therefore RHLGA/LGA/WLCSP microphones and tiny packaged MEMS speakers. For a legitimate ear- canal or hearing-device design, that is usually acceptable, because the acoustic port, sealing, contamination resistance, and assembly reliability all depend on the package.

MEMS

microphone

Manufacturer Interface Electrical

highlights

Mechanical size

Integration note

Source

SPH0645LM4H- B

Knowles

I2S digital

65 dB(A) SNR,

120 dB SPL

AOP, 600 µA,

1.62–3.6 V

3.50 × 2.65

× 0.98 mm

Good when the radio/ MCU

already exposes I2S; convenient for ESP32- C6 or an audio- capable host downstream of a module

MP23DB02MM

STMicroelectronics

PDM

285 µA low-

power, 800

µA normal, 122 dB SPL

AOP, 64–65 dB(A) SNR,

1.6–3.6 V

3.5 × 2.65

× 0.98 mm

Excellent direct fit for PDM-

capable SoCs such as EFR32BG22

or nRF52811

SPM0687LR5H-1

Knowles

Analog, single- ended or differential

70 dB(A) SNR,

130 dB SPL

AOP, 285 µA

@ 2.7 V, 2.3–

3.6 V

4.72 × 3.76

× 1.25 mm

Best used with a proper audio codec or low-noise preamp; Knowles explicitly frames it around codec/ application- processor integration

MEMS

microphone

Manufacturer

Interface

Electrical

highlights

Mechanical

size

Integration

note

Source

SPH18R1LM4H-1

Titan

Knowles

Digital PDM

Official selection guide lists

68.5 dB(A) SNR, 324 µW @ 768 kHz,

1.8 V, and strong overload headroom

3.50 × 2.65

× 1.00 mm

Good newer small PDM option for TWS/ear applications where size and low power matter

SPH88R1LM4H-1

Titan 1.2 V

Knowles

Digital PDM

Official selection guide lists

68.5 dB(A) SNR and 305

µW @ 768

kHz with 1.2 V I/O

compatibility

3.50 × 2.65

× 0.98 mm

Useful when the logic domain is very low voltage or mixed with a 1.2 V

digital rail

The practical interface rule is simple. If your wireless SoC has PDM, parts such as MP23DB02MM or Knowles Titan are the cleanest route. If your SoC or codec has I2S capture, SPH0645LM4H-B is attractive. If you only have an ADC or analog mic input, then SPM0687LR5H-1 is workable, but you should follow codec-front- end guidance or add a preamp; ST’s own application note for analog MEMS microphone preamplification illustrates the kind of analog conditioning involved.

MEMS

speaker / receiver

Manufacturer

Acoustic role

Electrical

load and drive

Mechanical size

Recommended

driver / amplifier

Source

Cowell XSM-2100- S

xMEMS

Full-band earbud/IEM speaker, documented 20 Hz–20

kHz

44 nF

capacitive load, 15 Vac

drive, 10 Vdc bias with Aptos; datasheet shows 112.5

dB @ 1

kHz / 30 Vpp

3.2 × 6.0 ×

1.15 mm

Aptos / Aptos2 companion amplifier family

MEMS

speaker / receiver

Manufacturer

Acoustic role

Electrical

load and drive

Mechanical size

Recommended

driver / amplifier

Source

Lassen

xMEMS

Tweeter only, documented 6 kHz–20

kHz

Official launch states standard 1 Vrms audio output, no extra amplifier required, microwatt- class power

3.2 × 5.0 ×

1.15 mm

Existing standard audio output path; no xMEMS high- voltage amp required

Conamara UA-

C0603-3T

USound

Tweeter / high- frequency MEMS

speaker for IEM/TWS

9 nF,

nominal 1.5

Vrms + 10 Vdc, max

13.5 Vp, up to 121 dB @ 5 kHz under high drive

Ø 6.0 ×

1.49 mm

Tarvos 1.0 /

1.2 linear MEMS-speaker amplifier

Achelous UT-P2020

USound

Full-band in-ear MEMS

speaker

27 nF, max

15 Vp, max

15 Vdc, documented 118 dB @ 1

kHz / 15 Vp in IEC 60318-4

coupler

6.7 × 4.7 ×

1.58 mm

Datasheet reference circuit uses TI LM48580 + TPS61046;

newer USound ecosystem also centers on Tarvos

Adap UT- P2023

USound

Free-field / wearable MEMS

speaker, or tweeter in 2-way earphones

26 nF, max

15 Vp, 15

Vdc, acoustics optimized for free-field and 2-way use

6.7 × 4.7 ×

1.58 mm

USound reference drive circuitry; best treated like other USound piezo/MEMS loads

Two conclusions matter for voice reception. First, xMEMS Cowell and USound Achelous are the most credible choices when you actually need a speech-capable full-band receiver. Second, xMEMS Lassen and USound Conamara 3T are not good stand-alone speech receivers, because their documented operating regions are primarily tweeter / high-frequency ranges. They can be valuable in a 2-way design, but not as the only driver if the goal is intelligible narrowband voice.

A final note on the user’s requested “impedance” field: for the MEMS speakers in this survey, vendors generally specify capacitance and drive voltage, not a classic 8 Ω / 16 Ω dynamic impedance, because these are piezo/MEMS capacitive transducers rather than moving-coil receivers. That is why 44 nF, 27 nF, 26 nF, or 9 nF is the more useful parameter here.

Interface matching and batteryless feasibility

The compatibility matrix below is the most concise answer to the question “which USID module can connect to which MEMS mic and speaker on G.729?” The key concept is that direct microphone connection is often possible, while direct speaker drive is almost never possible.

Radio / USID

candidate

PDM mic such

as MP23DB02MM

or SPH18R1LM4H-1

I2S mic such as SPH0645LM4H- B

Analog mic such as SPM0687LR5H-1

xMEMS

Cowell

xMEMS Lassen

USound Conamara / Achelous / Adap

ZL70323

No direct attach; needs companion MCU/audio IC

No direct attach; needs codec/AFE

Via external DAC/

line-out

+ Aptos/ Aptos2

Via external codec/line-out

Via external DAC/line- out + Tarvos or reference amplifier

i r n a

ATM33e

Directly plausible via documented PDM/I2S clocks and digital interfaces

Plausible through I2S- capable host path

Possible through ADC/ AFE, but not ideal without audio-grade front end

Needs external analog output or DAC plus xMEMS

driver

Possible from standard audio output path if DAC/codec is present

Needs external DAC/

analog output plus Tarvos/ reference amp

l p a a p e

EFR32BG22

Direct PDM attach

Direct or near- direct through USART I2S

mode

Possible via ADC + preamp / codec

Needs DAC or analog codec + driver

Possible with codec/line out

Needs DAC/codec

+ Tarvos or TI

reference amp

d P

Radio / USID

candidate

PDM mic such

as MP23DB02MM

or SPH18R1LM4H-1

I2S mic such as SPH0645LM4H- B

Analog mic such as SPM0687LR5H-1

xMEMS

Cowell

xMEMS Lassen

USound Conamara / Achelous / Adap

nRF52811

Direct PDM attach

No native I2S in the surfaced spec

Possible via SAADC + analog front end

Not a direct fit; needs external codec and more glue logic

Possible only with extra audio hardware

Needs external codec/ driver hardware

t e w p s

ESP32-C6

Direct with I2S/ PDM support

Direct through I2S

Possible through ADC or codec

Needs xMEMS

driver path

Straightforward if a clean 1 Vrms output path is available

Needs Tarvos/ reference amp

p fi

NINA-W10

Indirect, usually through onboard CPU firmware and I2S/PDM-

capable audio chain

Directly plausible because module exposes I2S

Possible via ADC or codec

Needs high- voltage / line- level speaker path

Possible with codec/line-out

Needs driver amplifier

s a m f

i p c

Type 2FY

Only with external host CPU

Only with external host CPU, though module exposes PCM/ I2S on BT side

Only with external host CPU / codec

Only with host, DAC,

and driver

Only with host and audio chain

Only with host and driver

h a t m n e

This matrix is a synthesis of the vendor interface documents. The ZL70323 implant module is fundamentally a radio modem for MedRadio telemetry. The EFR32BG22 and ATM33e are stronger if you want a single low- power active radio node that can ingest a PDM mic directly. The ESP32-C6, NINA-W10, and Type 2FY are better when the real requirement is simply “move G.729 or PCM from a CPU over a standard IP-capable wireless link.”

The batteryless question is much harsher. Ambient-harvested and “no battery” parts are real, but the products I found are aimed at ID, sensing, and intermittent telemetry, not continuous audio. The table below reflects the practical engineering answer.

Batteryless /

harvesting part

What it actually is

Vendor-stated behavior

Continuous G.

729 speech streaming?

Why

ONiO.zero

Wireless MCU with integrated harvesting options

Self-starts from <1 µW, supports BLE 5.4 / 802.15.4, and harvests RF, solar, piezo, thermal

No credible evidence in public docs

Excellent for ultra- low-power sensing/control, but no public catalog ecosystem for continuous implanted audio

Wiliot IoT Pixel

Battery-free BLE sensor / sticker

Postage-stamp sized, 2.8 × 4.4 cm, ~1 MHz

Cortex M0+, BLE, supply-chain sensing, energizing/broadcast ranges up to tens of meters depending on infrastructure

Far too large, and architected as a sensor/beacon rather than an audio receiver

P2110B +

active radio

RF energy harvester front end, not a radio

Charges a capacitor from 915 MHz RF, then enables VOUT after threshold; documented for battery-free micro- power devices and intermittent operation

Not realistically, except with a strong intentional power beam and extra storage

The device’s own functional description is burst-oriented; it is not an always- on radio/audio frontend

ATM33e with harvesting

Active BLE SoC with EH support

Can run from harvested sources, but active receive is still about 1.4 mA at 3 V including PMU

Not from ambient harvesting alone

Even its receive budget is already in the milliwatt range

EM4325

UHF RFID /

battery- assisted- passive transponder IC

It is an RFID IC, not an audio radio

Hitachi µ- Chip / 0.05 mm powder IC

Passive contactless RFID identifier

Receives RF and transmits a 128-bit unique ID

It is literally an ID chip, not a voice link

The core power-budget reason is straightforward. From the vendor numbers, an ATM33e receiver path is about 4.2 mW at 3 V, and xMEMS Cowell + reference amplifier is about 4.3–4.8 mW at 3.6 V. That already implies roughly 8.5–9 mW before codec compute, buffering, and uplink microphone capture. A USound

Achelous + reference amplifier path is documented at 13.6 mW, which pushes the receive-and-playback path higher still. Against that, the batteryless parts emphasize cold start under microwatts, energy storage, or intermittent packet broadcasting. The engineering conclusion is therefore not just “hard,” but “not plausible from ambient harvesting with catalog parts.” A deliberately powered inductive or other near-field energy link is a different class of system entirely.

Implementation, safety, and legal constraints

At the implementation level, the smallest realistic system is still larger than the headline radio dimensions suggest. The ZL70323 implant module may be only a few millimeters across, but the external ecosystem still needs a base station counterpart, a host MCU, power management, a speaker driver, a microphone interface, an antenna, and—if it is truly implanted—biocompatible, sealed packaging. The older Microsemi/Microchip module documents also show that even the external base-station module expects ordinary RF-design disciplines like 24 MHz timing, decoupling capacitors, supply filtering, and antenna/ matching considerations. On the acoustic side, USound and xMEMS both assume purpose-built driver circuits, not direct GPIO drive.

Latency and quality are also constrained by the codec choice. Because G.729 is defined around 10 ms speech frames and RTP commonly uses 20 ms packetization, a practical system must add at least frame accumulation plus transport plus buffering before playback. That is acceptable for telephony-style monitoring, but it is not the same as low-latency transparent hearing assistance. Just as importantly, G.729 is narrowband: even if you attach a high-performance full-range MEMS microphone and a full-range MEMS speaker, the transmitted speech quality will still be bottlenecked by the codec and packetization strategy rather than by the transducer bandwidth alone.

Any design that crosses the line from “in-ear electronics” to “implant” enters an entirely different regulatory world. ISO 14708-1 covers general safety requirements for active implantable medical devices. The FCC MedRadio rules govern implant telemetry spectrum such as the 402–405 MHz band, including bandwidth limits. FDA guidance on RF wireless technology in medical devices and on biocompatibility using ISO 10993-1 is directly relevant if anything is implanted or in prolonged tissue contact. In short, an implanted ear/communication device is not just a PCB problem or a codec problem; it is a medical device risk- management problem.

The cybersecurity expectations are also material. FDA’s current guidance specifically expects cybersecurity design, labeling, and premarket documentation for devices with cybersecurity risk, and FDA has separately warned about Bluetooth Low Energy vulnerabilities affecting some medical devices. For any design that receives voice from a CPU and routes it into a device worn in or on the body, authentication, firmware update controls, pairing behavior, and fail-safe audio behavior are not optional details.

The overall assessment is therefore precise. If your goal is a serious implant-oriented research platform, the most defensible starting point is Microchip ZL70323/ZL70103 for the radio link, paired with a separate audio/control MCU and a full-band MEMS receiver such as xMEMS Cowell or USound Achelous, plus the required driver ICs. If your goal is a working proof-of-concept that really carries G.729 from a computer, a Wi‑Fi/IP-capable device such as ESP32-C6, NINA-W10, or Type 2FY + host CPU is materially easier. If your goal is no battery / ambient energy only, current catalog USID-like parts support ID, sensing, and intermittent packets, but not a believable continuous ear-implant voice receiver.