The chipset and what it fixes
At the centre of every temple board is a Bluetooth audio system-on-chip: a radio, a processor, audio converters and power management in one package. Across the category, current models use Bluetooth 5.2 to 5.4, with 5.3 the most common. The chipset generation fixes a lot that firmware cannot change later: power draw, radio sensitivity, whether LE Audio and the LC3 codec are available, how many devices can be held in multipoint and how much memory is left for features and updates. This site does not name chipset suppliers; the desk compares boards by version, features and the stability of the plant's firmware branch rather than by the chip vendor's name. The practical differences between versions are in Bluetooth 5.3 vs 5.4 in glasses.
Connection behaviour: multipoint, sync and codecs
Multipoint lets a pair stay connected to two devices, typically a phone and a laptop, and switch calls and audio between them. It is a firmware feature on a capable chipset and is the single most requested item for business call models; how it behaves - which device wins when both play, how long switching takes - is set per firmware and should be checked on the sample with the buyer's own devices. Left-right synchronisation between temples is the other connection topic: designs with a board in each temple keep both in sync over a radio link, and drops show up as one side cutting out. Codec support is also per firmware. SBC is universal, AAC is common, and LC3 is available on chipsets that support LE Audio. Codec names on a spec sheet should always be written per firmware and confirmed on the golden sample. More in Bluetooth codecs for audio glasses and multipoint Bluetooth in glasses.
OTA updates and their risks
Over-the-air updates through the companion app let a brand fix bugs and add features after launch. They also carry the highest field risk in firmware: an update that fails half way can leave a temple unresponsive, an update pushed to one temple but not the other can break sync, and an update released without regression testing can bring back old faults. The engineering safeguards are a dual-bank or recovery partition, battery level checks before an update starts, signed firmware images, version checks for both temples and a staged roll-out. The test plan for firmware stability and OTA is part of the order and its scope is a stated working default, confirmed per order. Field failures and fixes are covered in firmware update failures.
App white-label
Most partner plants run a companion app for their boards: pairing, EQ, touch mapping, firmware updates and, for AI or translation models, links to cloud services. White-labelling means your brand's name, icon, colours and store listing on that app, sometimes with removed or added features. The work items are store accounts in your name, privacy policy and data processing terms, hosting location for any cloud services, update responsibility after launch and what happens to the app if the program ends. For translation features, language counts are per app and translation engine, and typical cloud latency is 0.5-3 s per network and language pair. App white-label is normally part of OEM or ODM work, from 3,000 pairs per model as a typical reference range.
EN 18031 and data permissions
Since 1 August 2025 the cybersecurity requirements of the Radio Equipment Directive, Article 3(3)(d), (e) and (f), apply to radio equipment placed on the EU market. Delegated Regulation (EU) 2022/30 names glasses among wearable radio equipment, and the harmonised standards are EN 18031-1, -2 and -3, covering network protection, personal data and, where relevant, financial transactions. In practice this touches default passwords, secure update mechanisms, protection of stored and transmitted data, and logging. From 11 December 2027 the Cyber Resilience Act takes over this role for products with digital elements, under Delegated Regulation (EU) 2026/339.
| Topic | What to specify | Evidence to request |
|---|---|---|
| Updates | Signed images, recovery path, staged roll-out | OTA test record on DVT units |
| Pairing and access | No fixed default passwords, pairing confirmation | EN 18031 assessment scope |
| App permissions | Only permissions the features need; microphone, location and contacts justified | Permission list per app version |
| Data flows | What leaves the phone, where it is processed and stored | Data map and privacy policy draft |
| Support period | How long security updates are provided | Written commitment from the app owner |
The buyer checklist for permissions is in smart glasses data and app permissions; the wider route is on compliance and certifications. Confirm scope and conclusions with your test lab and counsel. To scope firmware and app work, use the quote form.