Compatibility check

Three inputs. One honest answer about the control path.

This tool maps a device type, protocol and engagement model to an engineering path. It does not certify a brand or promise a specific model will work — those answers require a sample and a test plan.

Fig. 01 TV, streaming and sound in one handset

Start here

What has to be controlled, and how?

Most projects fall into one of three paths: a standard platform with configuration, a prototype program for a link we have not built yet, or a scope review where the protocol is still unclear.

The result is a starting point for a conversation. A definitive compatibility answer requires the device list, a receiver sample and a written test plan.

What this checker will not do. It will not tell you that a specific TV brand, hotel system or furniture receiver is "supported". That claim only comes after testing, and it is reported as tested models — not as a brand-wide promise.

Compatibility check

Describe the control target.

01 · Device to control

02 · Protocol or link

03 · Engagement model

No email required. Nothing is stored.

Scope review

The link cannot be identified from the information given; start with a scope review.

Take this to the brief

Start here

What has to be controlled, and how?

Most projects fall into one of three paths: a standard platform with configuration, a prototype program for a link we have not built yet, or a scope review where the protocol is still unclear.

The result is a starting point for a conversation. A definitive compatibility answer requires the device list, a receiver sample and a written test plan.

What this checker will not do. It will not tell you that a specific TV brand, hotel system or furniture receiver is “supported”. That claim only comes after testing, and it is reported as tested models — not as a brand-wide promise.

Checker

Path first, quotation second.

The answer comes from the link and the receiver, not from a catalogue.

Pick all three. The result can be carried into the enquiry form, parameters filled in.

Device to control

Protocol or link

Engagement model

Send this path to an engineer

Reading the result

Three statuses, three different commitments.

Standard path

We have done this before

The link is on an existing platform. The work is configuration, code coverage and validation against your device list. A functional prototype usually follows 3–5 weeks after the specification is agreed.

Prototype required

The link needs proving

The radio or protocol is feasible but not yet demonstrated on our hardware. We scope an engineering review and a prototype before committing to a production schedule.

Scope review

The brief is not defined yet

We need the device model, a sample remote or the protocol document before quoting. The first deliverable is a gap list, not a price.

Definitive answer

What turns a path into a commitment.

A compatibility claim is only as good as the evidence behind it. For a production program, we replace the checker’s estimate with a test report.

A device list with models and regions
One sample remote or receiver per device family
The protocol document, if the link is digital
Target markets and certification scope
An agreed definition of “working” — keys, latency, range

Evidence we return

Coverage reported as tested models, not a percentage claim
A gap list for models that could not be verified
A protocol test plan with pass/fail cases
A signed report before tooling release
Certification copies only for the exact model and market

Questions

Compatibility FAQ

Why can’t you just say a brand is supported?

A brand ships many models, regions and firmware versions. A code that works on one panel may fail on another. We report tested models so the claim matches the evidence. For a specific model, send a sample and we will add it to the test set.

Is the checker result a quotation?

No. It is a scoping estimate of the engineering path. Price and schedule depend on key count, tooling, protocol complexity, volume and the certification markets you need.

Can you test a receiver we already have in production?

Yes. Send the receiver and its firmware version. We test our handset against it and report pairing, range and recovery behavior. If the receiver is locked to another supplier, we will tell you before quoting a clone.

What if the protocol is undocumented?

We start with a discovery step: observe the link, capture frames and describe what is testable. The output is a written assessment of what can be implemented and what remains uncertain. Only then do we quote firmware work.

Next step

Turn the estimate into a test plan.

Send the device list and a sample. We will tell you what is tested, what is a gap and what it costs to close it.

Start a project See platforms

Typical reply within one business day