Home / Articles / Custom TPMS Sensor Development: Stage by Stage
Custom TPMS Sensor Development: Stage by Stage How a custom TPMS sensor programme runs from specification freeze to mass production, and who owns each decision along the way.
What a custom programme actually changes
"Custom TPMS sensor" means different things to different buyers. For one, it means a logo on the housing. For another, it means a different pressure range, a different valve, a modified Bluetooth service and an app that talks to nothing else. The distance between those two is most of the development effort, and the first useful conversation is about which one you are actually buying.
This is the sequence we run, who owns each decision, and where programmes typically stall. It assumes the supplier manufactures the sensor rather than reselling one, because a reseller can only customise the parts somebody else already built.
Stage 1 — Specification freeze
Everything downstream depends on this stage being finished, not merely started.
The specification covers:
- Vehicle and wheel count. Two, three or four wheels per vehicle, and whether the vehicle is a motorcycle, scooter, ATV, light car or a heavier unit.
- Pressure and temperature range. The real operating envelope, not a round number chosen for the datasheet.
- Valve interface. Clamp-in metal, snap-in rubber, or a specific rim profile. Valve choice is often the item that decides whether a sensor fits at all.
- Radio and protocol. BLE 4.1 on the 2.4 GHz band is our standard; a modified service or data format is a development item with a schedule attached.
- App scope. Android is available. iOS is scoped per project and is not an instant add-on.
- Branding. Laser marking, label, packaging, manual, part numbers.
- Approvals. Which markets, which approvals, who owns the application.
Who owns it: the buyer owns the requirements, the factory owns the technical translation. The stage ends when both sides have signed the same document. A specification that "we will finalise later" is the single most reliable predictor of a late programme.
Stage 2 — Prototype and sample approval
The factory builds samples to the frozen specification. This is where the buyer learns whether the requirements were written precisely enough.
Sample approval should cover more than whether it pairs with the app:
- Pressure accuracy at several points across the range, not only at rest.
- Behaviour at the cold and hot ends of the operating range.
- Valve fit on the actual rim being used.
- BLE range in the real mounting position — a sensor behind a brake assembly does not behave like one on a bench.
- Pairing behaviour after a battery change.
- Marking legibility and correct assignment of front, rear, left and right.
Who owns it: the factory produces and reports; the buyer approves in writing. Approving a sample verbally is how disagreements start later.
Stage 3 — Pilot run
A pilot run is a production run on production tooling, in small quantity, with the line set up as it will be for volume. It exists to expose process problems, not product problems — the product was settled in stage two.
What the pilot should produce:
- Units from the real line, not hand-built ones.
- Per-unit calibration records, so the pilot can be traced.
- Packaging and marking exactly as they will ship.
- A first-article inspection report against the frozen specification.
- The test steps each unit passed, in order.
Who owns it: the factory runs it and reports deviations; the buyer inspects and signs off. Any specification change requested during the pilot resets the pilot. This is the rule that keeps programmes honest.
Stage 4 — Mass production and change control
Volume production is not the end of the engineering. It is where change control starts.
A workable change process has four elements: a named owner on each side, a written change note, a re-validation requirement defined before the change is made, and a rule that no change ships without the buyer's written approval. Without that, a small firmware or component substitution arrives silently inside a shipment, and the buyer discovers it in the field.
Batch traceability belongs here too. Ask how a unit can be traced to a production date and a test record. A factory that calibrates every unit can answer this; one that does not, cannot.
Who is responsible at each stage
| Stage | Factory owns | Buyer owns | Exit criterion |
|---|---|---|---|
| Specification | Feasibility, tolerances, translation | Requirements, priorities, approvals | Signed specification |
| Sample | Build, test, report | Evaluation, written approval | Approved sample |
| Pilot | Line setup, records, deviations | Inspection, sign-off | Approved first article |
| Mass production | Consistency, traceability, change notes | Change approval, market approvals | Repeatable shipments |
The pattern is deliberate: the buyer owns requirements and approvals, the factory owns execution and evidence. Programmes that blur the two produce arguments instead of products.
The four ways programmes slip
An open specification. Every unresolved item becomes a change request later, at a worse moment.
Sample approval by conversation. If the sample was approved verbally, the acceptance criteria do not exist.
A late app decision. The sensor can be finished while the app is only beginning. Decide Android and iOS scope in stage one, and decide whether you are white-labelling an existing app or building your own, because the second path moves the critical path onto your developer.
Certification treated as paperwork. Market approvals have lead times and depend on the final hardware. Raise them at specification freeze, not at the shipping date.
Where we sit
We make the sensor, the measurement and the BLE service, so a programme can change the protocol, the housing or the marking instead of working around a catalogue part. The ODM page sets out the customisation levels, and the BPU100 page shows the platform a two-wheel programme usually starts from. Where a requirement needs a variant — a sealed battery, a wide-temperature build or a heavy-vehicle unit — that is a platform question rather than a new product, and it should be raised before the specification is signed.
Tell us the vehicle, the wheel count, the market and what you need to change, and we will tell you which stages apply and what would have to be frozen first.
Talk to us about your programme
Send the vehicle type, wheel count and target market — we will tell you what fits and what has to change.
Contact us See the BPU100 All articles