An OEM Checklist for Customising a TPMS Sensor The six layers of a TPMS sensor you can customise, which of them normally carry an engineering charge, and the sampling order that avoids expensive rework.

Customisation is a list, not a feeling

"Can you make it ours?" is almost always answered with a yes. The useful answer is narrower: yes to which parts, in what order, and which of them carry an engineering charge.

A TPMS sensor programme has six separable layers, and they differ enormously in cost, lead time and risk. Treating them as one lump is how programmes end up late.

The six layers you can customise

Layer	What it covers	Typical commercial treatment
Laser marking	Your logo, part number, wheel position (L.F, R.F, L.R, R.R)	Usually no engineering charge; artwork and programming setup
Packaging	Retail box, private label, manual, language set, accessory layout	Usually no engineering charge; artwork and print preparation
App	Branding, thresholds, layout, language set	Depends on scope; a branded build and a new app are different projects
BLE protocol and data format	Service and characteristic definitions, byte layout, advertising, identity	Engineering work; normally a development item
PCBA and firmware behaviour	Component selection, alarm logic, storage, power behaviour	Engineering work; normally a development item
Housing and valve interface	Body, seal, valve interface for the rim in question	Tooling may be involved if the existing interface does not fit

The top two rows are a print job, the middle two are software, the bottom two are mechanics. A buyer who knows which row they are asking about gets a straight answer on cost and schedule; a buyer who asks for a custom sensor gets an estimate that covers everything.

Which items normally carry an engineering charge

The industry term is NRE — non-recurring engineering. It is not a markup on parts; it is the one-off cost of work that will not repeat per unit. It normally applies when something has to be designed, tested or re-verified rather than merely printed.

Normally no engineering charge, assuming you supply finished artwork:

• Laser marking content, provided it fits the available marking area
• Packaging artwork, manuals and language sets
• Kit composition — how many sensors in which box, with which accessories

Normally carries an engineering charge:

• Changes to the BLE service or data format
• Firmware behaviour changes that are not configuration
• A new housing or valve interface, where tooling is required
• Any change that invalidates an existing verification result and forces it to be repeated

Depends on scope:

• App work. Putting your logo on an existing app is a different project from building a client for your own product, and they should be quoted separately.
• Certification. Handled per market and per project, so which approvals apply — and therefore what work is needed — depends on where the product is going.

You should be suspicious of anyone who quotes these before knowing your scope. Ask what the charge is for, what it delivers, and whether it buys you the source artwork or only the output.

The sampling order that avoids rework

Most programmes that go wrong do so because the layers were decided in the wrong sequence — usually because packaging and marking were left to the end, or because the app was assumed to be free. Front-load the decisions that constrain everything else.

1. Define the vehicle, the market and the wheel count. Two, three or four wheels, and whether the destination needs the wide-temperature configuration.
2. Settle the valve interface and housing. Does the existing interface fit the rim? This is the longest-lead item, so it goes first.
3. Decide the app route. Supplier app, branded build, or your own app against the sensor protocol. This determines whether you need protocol documentation and a firmware change.
4. Decide the protocol and data format, if you are taking the third route. Do it now, not after the app has been written.
5. Produce the marking and packaging artwork. Content, part numbers, wheel-position scheme, languages and regulatory text per destination. Cheap to change on paper, expensive to change on print.
6. Build samples and validate on the vehicle. Not on a bench. Range, mounting position and app behaviour all have to be checked on the real wheel.
7. Run a pilot batch through the same production and test flow as volume. This is where calibration, water-immersion, RF-range and protocol verification get exercised on your configuration.
8. Freeze the specification, then scale. Changes after this point become engineering changes, with the cost and delay that implies.

Documentation to bring to the first meeting

• Vehicle and rim details. Vehicle class, wheel count, rim type, valve hole, whether the wheel runs an inner tube.
• Destination market. Country or region, and the ambient conditions the vehicle will actually see.
• Artwork files. Vector source, not a screenshot, for laser marking and packaging.
• Part number scheme. Yours, so the marking can carry identifiers your dealers already recognise.
• App decision and volumes. Which of the three routes, on which platforms, and the volumes you are planning for.

Common mistakes worth avoiding

Deciding marking and packaging last. They are the cheapest layers and the ones that most often delay a launch, because print and tooling lead times do not compress.

Assuming the app is free. It is the layer most likely to be underestimated. A branded build and a new client are different projects with different schedules.

Leaving the wheel-position scheme to the dealer. A marking scheme decided at the factory costs nothing; an installation error in the field costs a support call and a ruined tyre.

Treating certification as a formality. It is handled per market and per project. Which approvals apply, and their current status, should be stated in writing rather than assumed from a general brochure.

Where we stand

We make the sensor ourselves. The sensing element is Infineon; the measurement, alarm logic, BLE service and data format are ours, which is what makes the software layers customisable rather than fixed. The sensor can be laser marked by wheel position and with your own identifiers, and the BLE service and data format can be adapted for OEM programmes. We supply more than 10,000 sets a month into the Chinese two-wheeler aftermarket, with capacity of 30,000 sensor units a month. Every sensor is pressure-calibrated on our own test software before it ships, and we run water-immersion, RF-range and protocol verification in house.

Bring this checklist to a conversation and it becomes a scoping session rather than a sales call. Send us the vehicle, the wheel count, the market and the layers you want to change and we will come back with what is configuration, what is engineering, and what order to do it in. The sensor specification is on the BPU100 product page, documentation is on the downloads page, and the rest of this series is on the blog index.

FAQ

Which customisations require NRE? As a rule, work that has to be designed, tested or re-verified carries an engineering charge: BLE service and data format changes, firmware behaviour changes, new housing or valve tooling. Laser marking, packaging artwork and kit composition usually do not, provided you supply finished vector artwork.

Can you laser mark our logo and our part numbers on the sensor? Yes. The sensor can be laser marked by wheel position — L.F, R.F, L.R, R.R — and the same step can carry your own part numbers or logo.

What is the minimum order for a branded programme? It depends entirely on the scope. Marking only is a very different proposition from packaging, app and protocol changes together. Send us the scope and we will come back with a concrete proposal rather than a general number.

Can we change the app to carry our brand? Yes, and there are three routes: our app, a branded build of our app, or your own app talking to the sensor protocol. They differ in cost, ownership and schedule, so choose the route before development starts.