Capability 02 — Protocols & Integration

The protocol is a contract. We test it like one.

A radio that transmits is not an integration. Integration means the receiver accepts the frame, the pairing flow can be completed by the intended person and a failed link can be recovered without a site visit.

Discuss a protocol Check compatibility

Protocol matrix

What we implement, and how it is verified.

The verification column is the important one. It states what evidence you receive, not what we hope the link will do.

Link	Typical use	Our role	Verification
Infrared	TV, projector, audio, set-top box	Code library, learned codes, discrete commands	Test on the agreed device list; coverage reported as tested models
Bluetooth LE	Streaming devices, voice, app pairing	HID or custom GATT service, pairing and recovery	Two-device interoperability test and reconnection cases
Sub-GHz RF	Furniture, shades, simple remotes	Receiver matching, fixed or rolling code	Range test through the product enclosure and representative obstruction
2.4 GHz proprietary	Hubs, AV integration, multi-device control	Frame implementation against your receiver	Frame-level test with your vectors, plus coexistence check
Zigbee RF4CE	TV and set-top ecosystems, operator handsets	RF4CE profile implementation, pairing and rejoin	Pairing, rejoin and key-mapping test on the agreed target devices
Wi-Fi	Wi-Fi Director class products, cloud-linked control	Module integration, provisioning, cloud link	Provisioning, reconnect and latency test on the agreed router set
Matter / Thread	Smart home ecosystems	Scoped as an integration project	Commissioning and certification path agreed before commitment

“Verified” always means tested on an agreed sample and device list. It does not mean universal compatibility with every unit in a brand’s installed base.:

Interaction

Buttons are one input. These are the others.

Voice, pointing and motion run on the same radio and the same test discipline. What changes is the sensor stack and the firmware budget.

01 / Pointing

6-axis air mouse

Gyroscope and accelerometer fusion for pointer control. Drift and jitter are tuned on the target host, not on a bench.

02 / Voice

Voice remotes

MEMS microphone, wake-word or push-to-talk, audio path tested with the actual codec and the BLE profile the host expects.

03 / Motion

Motion and game control

Gesture recognition at fixed sample rates. Latency and false-trigger rate are measured against the game, not described.

04 / Infrared

Learning and universal

A learning head plus a code library. Coverage is reported as the device list we tested, not as the size of the library.

Silicon: Telink, Realtek, HS6621C, Actions and OnMicro. BLE 4.2, 5.1 and 5.2 designs stay in supply side by side, because a running model keeps its platform — changing it is a new program with its own validation, not a silent substitution.:

Integration sequence

Four steps from document to signed test plan.

Step 01

Read the contract

Frame format, services, timing, security and error behavior. We list what is missing before estimating the work.

Step 02

Build against a receiver

Firmware is developed against your receiver or hub sample, not a generic development board.

Step 03

Test the unhappy paths

Lost link, failed pairing, interrupted update, replaced handset. These cases decide field support cost.

Step 04

Freeze and document

The test plan, firmware version and known limitations are signed before production release.

Built and verified in the same building

01SMT line — YAMAHA YV100II placement, three lines on site.

02Placement head — components placed before reflow.

03Bench instruments — receiver and firmware checked before release.

Test plan

The cases we insist on testing.

A protocol can pass a happy-path demo and still fail in a hotel room or a living room. The test plan is written to find those failures before the pilot build.

First-time pairing completed by someone who has not seen the product
Reconnection after the receiver reboots or the handset leaves range
Behavior when two handsets are bound to one receiver
Latency and repeat behavior under held keys
Range through the final enclosure and a representative obstruction
Recovery from an interrupted firmware update

Compatibility checker

Not sure which path your device needs?

The checker maps a device type, protocol and requirement to an engineering path. It returns a scoping answer — not a claim that a specific brand has been certified.

Three inputs, one path

Device · protocol · requirement

Use the interactive checker to see whether your project is a standard path, needs a prototype, or requires a scope review.

Open the checker →

Questions

Protocol FAQ

Can you guarantee compatibility with a specific TV brand?

No supplier can honestly guarantee every model in a brand’s installed base. We test the models on your list and report coverage. For models outside the list, we can attempt a learned code and add it to the test set before production.

Do you reverse-engineer proprietary protocols?

We analyze a receiver you own and document what can be observed. Whether that is sufficient depends on the encoding and on your right to use it. We report the limits of the analysis before quoting production firmware.

Is BLE secure enough for access or payment use?

That depends on the threat model, not on the radio. For access or payment-adjacent products we require a defined key-storage and pairing design, and we scope a security review with your team. We do not treat “BLE” as a security claim.

Can the same handset ship in IR-only and IR+BLE versions?

Yes, if the PCB is designed for both from the start. We often build a common board with a depopulated radio variant, provided the antenna and certification implications are handled per SKU.

Start a project

Send the frame format. We will send the questions.

The gaps in a protocol document are usually the same ones that become field failures. Better to find them now.

Start a project All capabilities

Typical reply within one business day