RGB and Wireless Charging Mouse Pad

The quickest way to turn a simple accessory into a project with five open issues is to take an existing cloth mouse pad specification and append two lines: “add RGB lighting” and “add wireless charging.” That is how most troubled RGB wireless charging mouse pad programs begin.

The supplier returns a sample that lights up and charges a phone. Approval looks close.

Then the field reports come in: the pad runs noticeably warm around the coil after half an hour, charging only works when the phone sits in one exact spot, and the controller module inside the sample is not the one named on the packaging drawing.

None of these failures is exotic. All three trace back to the same root cause: lighting and charging were treated as bolt-ons to a passive pad design instead of as an integrated product with its own power, thermal, mechanical, firmware, and compliance workstreams.

A cloth pad has no power budget, no surface temperature limit, no EMC emissions, and no firmware. The moment you add electronics, all of those appear, whether or not the specification acknowledges them.

This guide walks through what changes when a plain pad becomes a powered, illuminated, wirelessly charging product.

It covers the architecture decisions, the power budget math, the validation protocols, the production tests, and the regulatory questions you need to put in front of a compliance professional.

Nothing here replaces engineering review or the conformity assessment that applies to your specific design and target markets.

What it gives you is the set of questions and acceptance criteria to hand to a supplier before you approve samples — and a way to tell a prototype that merely works from a design that is ready to ship.

1. Product Architecture and Use-Case Definition

Before any component is selected, decide what the product actually is. A pad that charges a phone on a desk at home, a pad used in a hot warehouse office, and a pad that must survive being rolled up in a laptop bag every evening are different products with different constraints.

If the architecture is defined only as “a mouse pad with lights and a coil,” the supplier will make the architecture decisions for you, and you will discover them during testing.

Start from the delivered experience

Walk the three symptoms backward. Each one points to a design gap that should have been closed before tooling.

Heat around the coil: wireless power transfer is never lossless. The transmitter driver, the coil, the ferrite, and the receiving side all dissipate some of the input power as heat. In a desk charger sitting on a hard surface, that heat has an easy path out through the enclosure.

In a mouse pad, the coil sits under a layer of fabric and foam that insulates it, and the pad is in contact with a desk that may itself be a poor conductor. The result is that a pad designed with the same coil mounting as a standalone charger runs hotter.

The symptom “warm around the coil after 30 minutes” is not a defect in the coil; it is a missing thermal analysis and a missing temperature-rise protocol.

You cannot fix it by adding more power or a faster charging profile — you fix it by defining how much heat the pad may generate, where it is allowed to go, and what surface temperature is acceptable.

Position sensitivity: inductive charging depends on coupling between the transmitter coil and the receiver coil. Coupling falls off quickly with lateral offset and with vertical separation.

A phone case, a thick pad top layer, or a phone placed casually near the edge of the marked zone all reduce the transferred power or stop it entirely.

If the sample only charges in one exact position, the design did not include a defined charging zone, alignment guidance, or (where applicable) magnetic alignment. That is a specification gap, not a manufacturing issue.

Controller and packaging mismatch: the sample contains a controller module that differs from the one named on the packaging drawing, or the label lists features the installed firmware does not have. This is a bill-of-materials discipline problem.

It happens when the supplier changes parts to cut cost or because of availability, and nobody updates the documentation or re-validates.

It matters because the compliance file, the user manual, and the packaging must describe the product that is actually shipped, and because a silent component change can invalidate test results.

Another symptom is brightness or color that differs from sample to sample. One unit glows warm white, the next is visibly blue, and the box artwork shows a third tone.

That points to missing requirements for observable brightness, chromaticity, LED binning, surface uniformity, measurement conditions, and production acceptance. The chosen quantities and tolerances need a defined method and must be achievable by the selected lighting system.

The common thread: the sample proved the concept could light up and move power. It did not prove the concept met defined requirements, because the requirements did not exist. The rest of this guide is about creating those requirements.

Define use cases before power ratings

Power, thermal, and compliance decisions follow from use cases. Write down, for each intended environment, what the user expects to charge, what lighting is for, and what the pad must survive. The table below is a starting matrix; adjust it to your market and price point.

For each row, note the charging power class you actually need. A phone that sits on the pad all day needs far less delivered power than a user who expects a 30-minute top-up before a meeting.

The charging power class drives the input power, the coil and driver selection, the thermal budget, and in some markets the radio regulatory assessment. Do not pick “as much as possible” — pick the power that satisfies the use case, then prove the pad stays cool and compliant at that power.

Map the functional blocks and their interfaces

An RGB wireless charging pad is at minimum these blocks, each with an owner and an interface to the next:

Draw the block diagram even if the supplier provides it. The diagram is the contract for where each requirement lives. When you later change one block — a smaller coil, a different LED strip — the diagram shows you which interfaces and which tests are affected.

Draw the boundary of what the pad is not

Equally important is what the product is not expected to do. Write these boundaries into the specification so nobody is surprised later:

•Not a general-purpose charger. One receiver at a time, in a defined zone, with defined alignment guidance. Two phones, a phone plus earbuds case, or an oversized tablet are out of scope unless specified.

•Not a heater. Any input power that is not delivered to the phone becomes heat inside the pad. The specification should state the maximum acceptable surface temperature, not just the charging power.

•Not a network device. Unless you specify app control, firmware updates, or wireless connectivity, the pad is a standalone device. Do not let a supplier add cloud or app dependencies you did not ask for.

•Not a substitute for a rated power source. The pad must not be expected to run at full load from an arbitrary USB port that cannot supply the current. The specification must state the required input power and the behavior when input power is insufficient.

•Not liquid-proof unless specified. Fabric tops absorb spills. If a drink can reach the electronics through the fabric, either the design must isolate the electronics or the user manual must state the cleaning rules. Decide which one the product is before you ship.

Writing these boundaries down converts vague expectations into reviewable requirements and prevents the “but we assumed” conversation at sample approval.

Write the requirement baseline and assign owners

Every requirement needs an owner and a verification method. The owner can be the supplier, your engineering team, or a third-party laboratory. The verification method is inspection, analysis, or test. The gate is where you check it: design review, first article, sample approval, or production audit.

Sample approval gates and evidence rules

Sample approvals happen in stages, and each stage answers a different question. If the stages blur together, evidence gets borrowed from the wrong place — a demo video standing in for a thermal measurement.

A pilot-run unit standing in for a design review — and the gaps hide until field returns surface them. Define the gates in the purchase agreement and name the evidence required at each one.

Gate 1, design review: block diagram, power budget with the basis for every number, thermal analysis, component selection mapped to the requirement matrix, and the compliance classification questions answered in writing. No hardware is required; documents are the deliverable.

Gate 2, first article samples: functional checks against the requirement matrix, the thermal protocol run to steady state, the grid test for the charging zone, an EMC pre-scan if the laboratory schedule allows.

And a firmware feature check against the user manual draft. The deliverable is the sample plus the test records.

Gate 3, pilot run samples: production test stations proven, traceability records generated for real units, burn-in executed per the project plan, and packaging and label artwork reviewed against the installed firmware and bill of materials.

The deliverable is evidence that the process, not just the sample, produces the product.

Gate 4, production release: test yields reviewed, a first-batch audit of the serial and test records, and a packaging audit on actual shipping units.

The operating rule: a later-stage sample does not answer an earlier-stage question, and a functional demonstration does not substitute for a measured protocol. When a supplier says the samples speak for themselves, the correct reply is that samples demonstrate and records prove.

Write the evidence list into the requirement matrix, and attach the actual records to the approval sign-off, because the approval memo is the document a future dispute will be resolved against.

Do not sign off samples with open cells in this matrix. An open “thermal” cell is exactly how the warm-pad complaint reaches your support team instead of the design review.

2. Power, Lighting, and Wireless Charging Design Inputs

Chapter 1 defined what the product is. This chapter defines how much power it needs, where that power comes from, how the lighting is driven, and how the charging coil and its control system are specified.

This is the chapter where most “it works in the sample but fails in the field” stories are written.

USB input and adapter boundary

The pad is powered over USB, but “USB” covers a wide range of delivered current. A pad that draws more than a port can supply will brown out, reset the controller, or charge intermittently — symptoms that users report as “the pad is broken.” Define the input boundary explicitly.

The specification should state the verified input range, required source characteristics, included or excluded adapter, cable requirements, and reduced-function behavior.

Lighting may dim or charging may pause when available power falls below the controlled-load requirement, but that behavior must be designed, documented, and tested; an uncontrolled reset loop is not an acceptable fallback.

The adapter itself is a separate product with its own compliance obligations. If you ship one in the box, its safety certification, marking, and documentation are your responsibility too, and the adapter’s output must be matched to the pad’s input protection.

If the user supplies the adapter, the pad must tolerate the range of adapters people actually plug in, including marginal ones.

Build the power budget from the top down

The power budget is the arithmetic backbone of the thermal and input decisions. Build it from the top down: list every load, its worst-case current, its efficiency, and sum them.

The method matters more than the example numbers; replace the values below with measured or datasheet data for your design.

This is arithmetic, not a proposed product rating. At 5 V, 15.0 W corresponds to 3.0 A before cable and conversion margin; at 9 V it is about 1.67 A; at 12 V, 1.25 A; at 20 V, 0.75 A.

The actual input source, charging class, LED current limit, conversion losses, cable drop, transient behavior, and safety margin must come from the selected design and measurements.

Charging efficiency changes with alignment, receiver, case, load, control mode, and temperature. Measure input and delivered power at the defined operating points rather than applying the illustrative 80% value to the whole product.

In this example, the charging block dissipates 2.5 W before other conversion losses because 12.5 W enters that block and 10.0 W reaches the receiver. Lighting and controller input also becomes light, external output, or heat according to the actual circuit.

Thermal validation must therefore use measured losses and the final assembly, not the difference between two marketing power labels.

Keep the budget in a spreadsheet with the basis written next to every number, because at the next component change the buyer will be asked which numbers are still valid.

LED, light guide, and controller

Lighting decisions often begin with visual preferences but need measurable requirements.

Specify observable behavior—brightness steps, uniformity, color consistency, modes, transitions, startup, and memory—then evaluate the supplier’s proposed LED, optical, driver, and firmware architecture against those requirements.

Lighting current must be calculated from the selected LED architecture, driver, channel-current setting, duty cycle, LED count, voltage, and firmware limit.

A nominal current printed in a component example does not prove the assembled strip will draw that value, and addressable LEDs, analog strips, and constant-current drivers behave differently.

Define and measure the maximum lighting input for the brightest allowed mode, then use that verified value in the power and thermal budgets.

Light guide design determines whether the pad looks like a uniform glow or a row of dots. Edge-lit pads feed light from LEDs at the edge through a diffusing layer; direct-lit pads place LEDs under the surface.

Both need a uniformity target you can measure, for example a maximum ratio between the brightest and dimmest point across the surface. Specify that target numerically instead of with the word “even.”

The controller choice decides the feature set. Simple constant-current drivers give fixed colors and brightness steps. Addressable LED parts allow per-LED effects — waves, gradients, chase patterns — at the cost of more firmware complexity and a stricter timing requirement.

Ask the supplier which parts they use, what the total current is at the maximum effect, and how the firmware is versioned.

The controller model and firmware version must be recorded in the traceability file, because they will appear on the packaging and in the user manual, and they must match what is inside the box.

Two lighting parameters deserve written values. The first is the PWM frequency used for dimming: if it sits in an audible range, the LEDs or the driver can whine, and if it sits in a range the camera user notices, video of the pad shows banding.

Specify the frequency or the acceptance criteria, and listen to the pad in a quiet room during validation, not in a noisy showroom. The second is color consistency across the surface and across units: LED bins differ, and a pad with mixed bins shows visible patches.

Put a color tolerance in the specification, agree with the supplier which binning they purchase, and check the first article against both. These are the parameters that turn “the lighting looks fine” into a number the line can verify.

Wireless charging coil, driver, and position tolerance

The charging function should be specified as a system, not as a coil to be mounted under a mouse pad.

The realistic choice for most programs is a wireless charging transmitter module — coil, driver, control, and foreign object detection together — supplied as a unit that has been validated against the receiver types you care about.

The supplier of that module owns the transfer efficiency, the FOD behavior, and the compatibility list. The pad designer owns the mechanical integration: coil position under the surface, pad top thickness, and the marking that shows the user where to place the phone.

Every layer between transmitter and receiver changes the coupling condition. The specification should state the final top construction and receiver-case scope, then verify the charging map on that assembly.

A bare phone placed directly on an exposed coil does not represent the shipped product.
Position tolerance is verified with a grid test: a reference receiver moved across the surface in small steps, delivered power recorded at each point.

The result defines the usable zone, and the printed or embossed zone marking must be drawn inside it. If the sample only charges in one exact spot, this grid test is where that failure shows up as a number.

Production mounting tolerance is the second half of position control. The coil position under the surface is set by the assembly — mounting posts, adhesive, or a pocket in the foam — and every unit must land within the tolerance the grid test used.

Add a fixture check on the production line: a reference receiver positioned at the nominal spot, delivered power recorded, with the pass band taken from the design validation data.

That single station catches mis-mounted coils, displaced ferrites, and wrong foam thickness before the pad is boxed.

Foreign object detection and receiver compatibility

Metal objects near a charging coil heat up — keys, coins, paper clips — which is why foreign object detection (FOD) is a required behavior, not an optional feature. In a mouse pad the risk is higher than in a desk charger because the metal can be hidden under the fabric where the user does not see it.

The FOD behavior is part of the chosen transmitter system; you do not tune it in-house, and you do not disable it to make a demo more impressive. Disabling FOD converts a compliance question into a safety incident waiting to happen.

Specify the FOD verification: place standard metal coupons of defined sizes at the coil center and at the zone edges, and confirm the transmitter reduces power or stops within the time the system specifies.

That test belongs in the production functional test as well as in the design validation, because a damaged or mis-mounted coil changes the FOD signature.

Receiver compatibility is verified by the chosen system, not by assumption. If the module was validated against a set of phones and earbuds cases, that list is your interoperability baseline.

Devices outside the list — older phones, third-party receivers, receivers with thick cases — may charge slowly or not at all.

Avoid an unrestricted “works with all Qi phones” claim unless the finished product’s certification status and documented compatibility evidence genuinely support the exact wording.

Qi certification, where it applies, is the mechanism that gives cross-brand confidence, and it is covered in the compliance chapter; the point here is that a coil that works with your test phone proves nothing about the rest of the market.

The compatibility matrix is also a maintenance item. New phone models appear on a schedule, and each one is a new data point: does it charge at the rated power, does it align to the marked zone, does its case defeat the coupling?

Decide who owns this testing — supplier or buyer — and how often it runs, because the matrix is what keeps the marketing claims true eighteen months after launch, when the original test phones have been retired.

Electrical protection and fault behavior

The pad is a powered device sitting on a desk, plugged into a wall adapter through a cable that people pull, trip over, and spill drinks on. Define the fault behavior explicitly:

•Input protection: reverse polarity, overcurrent, and overvoltage on the input rail should shut the pad down or clamp, not damage it.

•LED rail faults: a shorted LED or strip should trip a limit, not draw unlimited current.

•Thermal cutoff: if the temperature sensor trips, the pad should reduce lighting, pause charging, or shut down — and the recovery behavior must be defined (auto-resume at a lower power level, or stay off until the user cycles power).

•Receiver removal: when the phone is lifted mid-charge, the transmitter should return to its detection state without glitching the lighting controller.

•Brownout: with a weak input source, the pad should enter its reduced-function mode cleanly, not reset in a loop.

None of these behaviors should be defeatable by the user, and none should be disabled in firmware to pass a demonstration. Write each one as a numbered requirement with a test, and put them in the production test where they can be checked quickly.

Behavior under combined load

The lighting and the charging block share one input and one thermal budget, and their interaction must be specified, not discovered.

Define the priorities: at full lighting plus full charging, either the design delivers both — which is what the power budget and the thermal protocol assumed — or it defines a degradation rule, lighting dims first or charging power steps down, and the user manual states the rule.

What must not happen is an undocumented fight: the charging controller restarting in a loop, the LEDs flickering, or the pad resetting when the user switches to the brightest mode mid-charge.

Two tests belong in the validation set specifically for this interaction. The first: switch the brightest lighting effect on while charging at maximum power, and monitor the input current and the pad for resets.

The second: cycle the mode button through all modes while charging, watching for glitches in either function. Both tests should also run with a weak input source, because the combined worst case is what exposes an undersized input stage.

The no-load case is a product decision of its own. When the phone sits off the pad and the lighting stays on, the charging block should idle in its detection state, and the total draw — lighting plus standby — is a real number the user pays for in an office where the pad stays plugged in all day.

If the lighting is on for eight hours, its current draw at the default brightness is not a technical detail, it is the product’s idle behavior, and it belongs in the manual and on the energy-conscious buyer’s checklist.

3. Thermal, Mechanical, and User-Safety Validation

The power budget in the previous chapter produced two numbers that matter here: the total input power and the portion that stays inside the pad as heat.

This chapter turns those numbers into validation protocols — thermal, mechanical, material, liquid, and electromagnetic — that run at sample stage and again when anything changes.

Thermal path and surface temperature rise protocol

The pad must be validated at its worst realistic operating point: all LEDs at maximum brightness in the brightest mode, charging at maximum rated power with the receiver at nominal position, in the warmest ambient the use case allows.

Run it in still air on a real desk surface, because airflow assumptions from a datasheet do not apply to a cloth-covered pad.

There is no universal surface-temperature limit for every pad material, contact duration, user group, or jurisdiction.

The compliance professional and qualified laboratory should identify the applicable method and limit for the actual design. The protocol makes conditions repeatable; it does not create the limit.

If the product exceeds its approved limit or lacks adequate margin under defined boundary conditions, possible controls include reducing internal losses, changing power or lighting behavior, improving heat spreading or enclosure design, and revising the duty cycle.

Each change needs electrical, thermal, mechanical, EMC, and user-interface review as applicable. A photograph of one passing reading is not a thermal validation record.

Add a thermal imaging pass to the protocol. Thermocouples give accurate numbers at defined points, but they cannot see where the heat actually concentrates: a hotspot under the coil’s edge, a warm connector pad, a bright spot at the LED strip’s power entry.

An imaging scan after steady state — with the pad opened if needed — shows the heat map the thermocouple grid missed.

And it is the fastest way to find the assembly detail that will fail in the field: the thermal pad that is missing, the ferrite that is cracked, the LED driven harder than its neighbors by a layout imbalance.

The imaging pass is documentation too: keep the images with the protocol record so a later component change can be compared against them.

Cable, connector, and housing mechanical requirements

A powered pad is shipped with a cable that carries current, and the cable exit is where pads die: users pull the pad across the desk, the cable bends at the exit, and repeated flexing breaks the strands.

Mechanical requirements are specified per design — there is no universal set — but the standard list to negotiate is flexing, pull, connector retention, and drop.

The applicable product, component, and transport standards plus the intended use determine the actual values. If the pad ships flat in a box with the cable folded, check the fold radius against the cable’s minimum bend radius.

If it ships rolled, the rolling test belongs in this list, not in the marketing photos. The connector choice is a design decision with field consequences.

A fixed cable is simpler and cheaper but means the whole pad is the service unit; a detachable connector adds a failure point but eases replacement and compliance documentation.

Whatever is chosen, the connector must be rated for the input current with margin, and the housing around it must survive the pull test without opening gaps that let liquid or dust in.

Transport, packaging, and drop

The pad travels in packaging that may not survive what logistics does to it. A box dropped onto its corner transfers the impact through the carton to the pad.

And the failure is often invisible — a cracked ferrite under the coil, a delaminated light guide — showing up weeks later as a field return with no obvious cause.

Specify the transport validation: a drop test at a height and an orientation set that matches your logistics reality, with drops on faces, edges, and corners, followed by a functional test of the pad, not just a visual check.

Compression is the second item: palletized cartons sit under weight, and a thin pad box collapses easily, so the carton and the internal cushioning need a compression test at realistic stacking loads.

If the pad ships rolled, the packaging must hold the roll at its minimum bend radius and protect the cable exit from crushing.

Transport damage is not a manufacturing defect in the supplier’s eyes, but the buyer pays for it either way — which makes transport validation a purchasing decision as much as an engineering one.

Flame retardant materials

The housing and pad materials sit near live circuitry, a charging coil, and a cable entry. Flame retardant requirements are design-dependent:

A pad whose electronics are fully enclosed in a rated internal enclosure may place fewer demands on the outer fabric than a pad where the PCB is exposed behind a thin cover.

The relevant conversation starts with the applicable product-safety assessment and the exact material grade, thickness, location, enclosure function, and supporting test evidence.

Flammability classifications such as those in the UL 94 family may be relevant when the governing design and standard call for them, but they are not automatic requirements for every pad layer.

Flammability classifications describe performance under a defined test. They are not blanket legal requirements, and the applicable product-safety framework determines which parts and evidence matter.

What you can require is evidence: material datasheets and, where the applicable standard demands it, test reports from a laboratory that is qualified to issue them.

Do not accept “it’s the same plastic” as documentation — the flame behavior of a molded part depends on the exact grade, wall thickness, and additives, and the molded part must be checked against the material certificate.

Liquids, cleaning, and folding

Fabric surfaces invite the wrong cleaning methods. The specification must decide, and the user manual must state: what the pad may be cleaned with, what happens if liquid is spilled on it, and whether it may be folded or rolled.

A desk pad will see coffee, tea, and cleaning spray. Unless the electronics are sealed behind a liquid barrier, a spill over the coil or the controller area is an electrical event, not a laundry event.

Two design approaches exist: isolate the electronics (sealed cable entry, coated PCB, a liquid barrier between the fabric and the electronics) or design for controlled failure (define what breaks and make sure it is the pad, not the adapter or the phone).

Most products take the first path and document the second as a limitation in the manual.

Cleaning is specified as a procedure: unplug first, wipe with a damp cloth, no immersion, no spray directly onto the surface, dry before use. If the pad is not liquid-resistant, say so in the manual in plain language, and keep the claim out of the marketing copy.

Whether the pad carries an ingress protection (IP) rating is a separate decision from its cleaning rules. An IP rating is a tested claim against defined dust and water conditions, and most desk pads do not pursue one because the test conditions do not match the product form.

The alternative — and the more honest approach for a fabric product — is a stated cleaning procedure plus a defined failure behavior if liquid reaches the electronics.

If a supplier offers an IP rating as a selling point, ask which test standard and which level, and whether the rated unit is the same construction that ships, because a fabric product that passes an IP test on a bare sample may not pass it with the final adhesive and stitching.

Folding and rolling need validation when the use case or packaging includes them. A bend can stress the LED interconnects, cable, solder joints, ferrite, coil mounting.

And laminated stack. Define the bend radius, orientation, dwell, cycle count, conditioning, functional checks, and acceptance criteria from the intended handling and failure analysis.

The validated minimum bend radius and packaging restrictions should then appear in the specification and user instructions; there is no universal cycle count for this product family.

EMC and ESD in the lab

A pad with a switching power stage, PWM-driven LEDs, and a wireless transmitter is an emitter and a victim. Electromagnetic compatibility work happens at design time and is proven in the lab; the pad cannot be made compliant by testing alone if the layout and filtering are wrong.

The compliance professional and laboratory select the applicable methods, levels, configurations, and performance criteria from the product architecture and target market. This table is a design-review map, not a test plan.

The practical items to verify during design: ESD strikes on the cable and the pad edge (plastic and fabric surfaces generate charge), LED PWM frequency and its harmonics in the emissions scan, and the charging inverter’s switching noise coupling into the lighting controller.

These are the three items that generate the classic “sample works in the office, fails in the test house” report.

4. Firmware, Controls, and Production Test

The firmware is the least visible and most complained-about part of the product. Users experience it as: does the pad remember my settings, does the button do what the box says, and does it behave after a power cut.

Production test is where the supplier proves every unit does those things. Both need written requirements, because “the firmware does what the demo showed” is not a specification.

Light effects, memory, and default state

Define the observable behavior table before approving the sample, and freeze it with a version number.

The memory requirement deserves attention because it is a favorite source of “the pad is broken” tickets.

If the spec says the pad remembers the last mode, it must survive power loss; if the spec says the pad always boots to a default, that is also fine — but the behavior must be stated and tested.

Not left to the firmware engineer’s mood. And the packaging must match: a box that advertises “20 lighting modes” cannot ship firmware with 6.

Production functional test

Every shipped unit should pass a functional test that covers the failure modes this product is known for, including the three from the opening scenario.

The test fixture uses a reference receiver — the same one used in design validation — positioned by a fixture that enforces the same alignment every time. Position-dependent results are the reason this matters: a charging test done by hand will pass or fail depending on who placed the phone.

The thermal spot check at production is a screen, not a substitute for the design validation protocol; it exists to catch assembly variation, and its threshold is set from the design validation data, not from an educated guess.

The fixture itself needs calibration and control. The reference receiver ages, the thermocouple drifts, and the fixture’s alignment can shift when a line is moved or a jig is dropped.

Define how often the fixture is verified against the design validation reference, what the allowed drift is.

And what happens when a station fails its check — units tested since the last verification are the population in question, and the traceability records decide whether they are retested or released on judgment.

This sounds like overhead until the day a production line quietly drifts out of alignment and a batch of pads ships with charging zones that no longer match the printed marking.

Burn-in and aging defined by the project

Burn-in or ageing parameters are defined by the project rather than inherited from another product.

Decide whether coverage is unit-level or sampled, identify the load profile, ambient, duration, measurements, failure criteria, and disposition, and justify the plan from component risks, qualification evidence, pilot results, field history, warranty exposure, and throughput cost.

Do not use “several hours” or an elevated temperature merely because another product did; the chosen stress must be relevant and must not introduce a failure mode unrelated to intended use.

If the burn-in is defined, it must be documented — the procedure, the recorded values, the disposition of failures — because that record is what a customer audit asks for when they want to know how you know units are reliable.

If the project decides burn-in is not cost-justified, that is a decision too, but it should be made with the warranty math on the table, not by omission.

Serial, batch, and traceability

When a field problem appears — a batch of pads that runs hot, a coil batch with an FOD anomaly — the question is which units are affected. The answer requires traceability records.

Require the supplier to keep these records and to provide them on request. Traceability is not expensive at the planning stage and is effectively impossible to retrofit after a recall-sized question.

Fault Tree and Evidence Chain

A powered pad can show the same customer symptom for several different reasons. “Charging stops” may result from weak input power, cable voltage drop, receiver misalignment, a foreign-object event, thermal protection, firmware state, component damage, or an interoperability limit.

Replacing the coil before identifying the branch can make the symptom disappear on one sample while leaving the real cause in production.

Build a fault tree from observable symptoms to evidence. Start with the product state: input source, cable, receiver and case, phone position, lighting mode, ambient condition, firmware version, and elapsed time.

Then read the records that separate the branches: negotiated input profile, input current, delivered power, temperature sensors, protection flags, firmware logs where available, and production-test results.

The service or engineering instruction should say which evidence to collect before reset or replacement, because a reset can erase the state that explains the event.

The evidence chain should link the field unit to its model, hardware revision, firmware, coil and controller lots, production station, and test result. If the buyer cannot identify those records, a complaint becomes an anecdote instead of an engineering input.

Trend the verified cause, not merely the symptom label. Five reports called “charging issue” can represent five unrelated causes; one repeated brownout signature across a component lot is a controllable population.

A fault tree also improves change review. A new cable can affect input drop and resets without changing the charging module. A thinner top layer can improve coupling while changing surface temperature and mechanical protection.

A firmware update can alter current demand, lighting duty cycle, thermal behavior, and regulatory evidence. Each approved change should identify which fault-tree branches and validation records require reassessment.

Fail-safe behavior

The firmware is the last line of defense for the hardware failures defined in the electrical protection list. The fail-safe requirements to write down: thermal trip reduces lighting and pauses charging before the surface temperature reaches the limit;

FOD events reduce or stop power as the system specifies; a shorted LED rail does not leave the pad drawing uncontrolled current; a firmware crash does not leave the charging coil live — a watchdog resets the controller into a safe state;

And after power loss the pad returns to its defined default or memory state, never to an undefined one.

These behaviors are test items, and they are not optional: they are what keeps a blocked ventilation path, a spilled drink, or a metal key under the pad from turning a $30 accessory into a warranty claim or worse.

If a supplier asks to remove a protection to simplify a demo, treat that as the end of the conversation.

5. Compliance, Documentation, and Supplier Control

Compliance for this product is a set of conditional questions, not a checklist you can copy from another product. Whether each regime applies depends on the design (does it have wireless power transfer, what input voltage, what materials), the market, and how the product is classified.

The sections below describe what each regime is about and what determines whether it applies. The decision on applicability for your specific product must be confirmed by a compliance professional — this guide does not certify anything, and neither does a component datasheet.

RoHS, REACH, and SCIP

RoHS restricts hazardous substances in electrical and electronic equipment (EEE) placed on the EU market.

The directive’s scope is defined around what counts as EEE, and an electronic mouse pad with active lighting, a controller, and a charging circuit is a product that needs that assessment: it is not a passive textile accessory, and it should not be treated as one.

Whether it is in scope, and under which category, is confirmed against the directive text — the official reference is the European Commission’s RoHS page at rohs-directive.

What RoHS compliance looks like in practice: the supplier provides material declarations and, where needed, test evidence covering the restricted substances; the results feed the technical documentation and the declaration.

RoHS does not require a third-party certificate in the EU — that is a self-declaration regime with supporting technical files — but buyers commonly ask for laboratory analysis anyway, because it is the evidence the file stands on.

REACH regulates chemical substances, including the Substances of Very High Concern (SVHC) list.

The practical question for a pad is whether any component or material contains an SVHC above the concentration threshold, and what obligations follow if it does, including SCIP notifications under the waste framework where applicable.

This is a screening task on the bill of materials: ask the supplier for declarations covering the SVHC list, and do not assume that because the pad is mostly fabric the answer is “nothing to declare” — the coatings, dyes, adhesives, and flame retardants are where surprises live.

The format of the supplier evidence matters for your file. A material declaration should identify the component, the manufacturer and part number, the declared substance concentrations.

And the date and version of the declaration, because an undated declaration that predates the last SVHC list update is evidence of nothing.

Set the rule with suppliers up front: declarations are refreshed when the SVHC list changes or when the component changes, and the refreshed versions are recorded in the traceability file next to the component batches they cover.

WEEE and producer responsibility

WEEE covers waste electrical and electronic equipment. A powered pad that ends up as e-waste is the kind of product the directive exists for, and if you place it on the EU market, producer responsibilities — registration.

Marking with the crossed-out wheelie bin symbol, financing of collection and treatment — apply where the directive reaches you. The official reference is waste-electrical-and-electronic-equipment-weee_en.

The mechanics differ by member state, which is exactly why this is handled with your compliance professional rather than from a template.

Note the interface with the manual and label: the marking requirements attach to the product and its documentation, so the WEEE decision has to be made before the artwork is final, not after.

EMC, LVD, RED — whether they apply

The European regimes for this product family, in plain terms:

The EMC Directive reference is at https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en . Two points to internalize.

First, “below the LVD thresholds” is not the same as “no safety obligations” — safety aspects are addressed through other legislation and standards, and the thermal and mechanical work from earlier chapters is still the evidence.

Second, the RED classification question is real: some wireless power transfer devices have been treated as radio equipment because they use radio frequency energy.

And the answer depends on the device and the interpretation that applies at the time you place the product. Get it answered in writing before you commit to a compliance timeline.

FCC equipment authorization

For the US market, determine whether each radio-frequency function is subject to FCC rules and which authorization procedure applies before importation or marketing.

The applicable rule part and approval route depend on the finished device’s technical characteristics and intended function; they cannot be assigned from the product name alone.

The FCC’s own description of the authorization system is at https://www.fcc.gov/engineering-technology/laboratory-division/general/equipment-authorization .

Confirm the applicable part and the authorization route with your compliance team and your test laboratory before the design is frozen, because the testing requirements can influence hardware choices such as filtering and coil shielding.

The same logic applies in other markets: wireless power transfer is regulated as a radio matter in several jurisdictions, and each market has its own process.

The functions that trigger radio-frequency rules must be determined from the finished product and applicable jurisdiction; a charging transmitter is an obvious focus, while other switching electronics can still create emissions obligations.

A module supplier’s authorization or report does not automatically cover the integrated finished pad. The US testing also shapes the hardware.

The applicable part influences what the laboratory measures — emissions limits, spurious output, the behavior of the charging field — and a design that was never intended to pass those measurements will need layout and filtering changes after the fact.

That is why the FCC question belongs at the design review gate in the requirement matrix, alongside the thermal and mechanical items, not discovered when the first shipment is sitting at the port.

Confirm the applicable part and the authorization route with your compliance team before the coil and driver selection is final, and put the laboratory schedule into the project plan with a date.

Wireless charging interoperability and Qi certification

Interoperability is what makes “works with my phone” true for phones the buyer has never tested.

The Qi specification, maintained by the Wireless Power Consortium, is the mechanism the market uses for cross-brand compatibility; the consortium’s site at wirelesspower describes the specification, the certification program, and the registered product lists.

The boundary to keep straight: a Qi-certified coil, driver, or receiver module does not make the finished pad Qi-certified.

Certification applies to the end product — the pad as shipped, with its specific coil mounting, surface thickness, and firmware — and it requires testing through the consortium’s recognized process.

If your commercial plan includes the Qi mark, the pad itself must go through that process, and the schedule belongs in your project plan, not discovered at launch.

If you do not pursue Qi certification, you can still use Qi-compliant components, but then interoperability is whatever your compatibility matrix proves, and the marketing language must match the evidence — no “Qi certified” claims, and no implication of certification the product does not hold.

Component change control

Components change after sample approval. The supplier runs out of a part, a cheaper one appears, a factory moves. The process that protects you is change control: a rule for what needs approval, re-validation, or re-testing when something changes.

The requirement to write into your purchase agreement: the supplier must notify you of any component change before implementation, with a classification and a proposed validation plan, and you approve the change in writing.

This clause is what prevents the controller mismatch from the opening scenario from recurring, and it is also what protects the compliance file: a compliance declaration is only valid for the product as declared, and a silent change can void it.

Documentation, manual, and labeling

The paperwork is part of the product. The user manual and the label are where the design decisions become user-facing obligations, and they must match the shipped configuration.

The manual’s charging guidance is a practical compliance item: if the pad charges only within a defined zone, the manual and the pad surface marking must say where that zone is, in the user’s language. The label’s rating must match the actual input the pad accepts.

And the packaging artwork — including any feature list and the controller or model references — must be reviewed against the shipped firmware and BOM at every change, because that review is the specific control that catches the mismatch the opening scenario described.

Make the packaging review a standing agenda item, not a one-time check: every BOM change, every firmware change, and every label revision triggers a comparison of the packaging artwork against the shipped configuration, with the result recorded in the change log.

The specific items to compare are the feature list on the box, the model and controller references, the input ratings, and any certification marks or logos the artwork carries — a mark on the box that the product does not hold is a compliance problem of its own, not a cosmetic one.

Laboratory qualification and test evidence

When test evidence is required—EMC, safety-related, material, or performance—the laboratory, method, sample identity, and scope all matter. ISO/IEC 17025 provides a basis for demonstrating laboratory competence.

Where accreditation is required or relied upon, confirm that the laboratory’s current scope covers the specific method and that the report identifies the tested product revision.

Accreditation alone does not make an irrelevant method or non-representative sample useful, while some regulatory routes impose their own laboratory-recognition rules, such as the FCC process described earlier.

Where to go from here. Before you approve the next sample, take the tables in this guide and turn them into a requirement matrix with owners and verification gates:

The use-case table, the power budget, the thermal protocol, the production test stations, the change-control rule, and the documentation list.

Send it to the shortlisted suppliers and ask each one to return a gap analysis — which requirements they already meet, which need design work, and what their compliance plan and schedule look like.

The supplier who treats the gap analysis as a negotiation is telling you how the project will go; the supplier who returns a dated plan with owners is giving you the project. Then approve samples against the matrix, not against the demo.

Frequently Asked Questions

Can an existing cloth pad specification be extended with lighting and charging requirements?

You can, but only as the baseline for the mechanical dimensions and surface feel. The electrical, thermal, firmware, and compliance requirements form a separate specification with their own owners and verification gates.

Treating them as appended lines is exactly how the three problems in the opening scenario — heat, position sensitivity, and configuration mismatch — get built into the product.

Why did my sample run warm around the charging coil?

Wireless charging is never lossless. The power that is not delivered to the phone is dissipated as heat inside the pad, and a cloth-and-foam pad insulates the coil better than a hard charger enclosure does.

The fix is a defined thermal budget, a measured temperature-rise protocol at worst-case load, and then design work — heat spreading, lower LED current, or a lower charging power — until the surface temperature meets the applicable limit with margin.

Why is charging position-sensitive, and what improves it?

Inductive coupling falls off fast with lateral offset and with vertical separation. The pad top layer and the phone case add separation that a bare desk charger does not have.

Improvements: a defined charging zone verified by a grid test, a printed zone marking inside the usable area, magnetic alignment where the receiver supports it, and a maximum stated total separation (pad top plus case) at which the power class still holds.

Does a Qi-certified coil or module make my finished pad Qi-certified?

No. Certification applies to the end product as shipped — its coil mounting, surface thickness, firmware, and FOD behavior.

A Qi-certified component is a head start, not a certificate. If the pad will carry the Qi mark, the finished product must go through the consortium’s certification process; the Wireless Power Consortium’s site describes the program.

Does a wireless charging pad need FCC authorization in the US?

A pad that transmits radio frequency energy for power transfer is generally subject to equipment authorization; the applicable rules and the authorization route depend on the device’s classification.

Confirm the part that applies and the route with your compliance team and laboratory, and plan the schedule before the design is frozen.

Is my pad within RoHS scope?

RoHS covers electrical and electronic equipment. A pad with active lighting, a controller, and charging circuitry is not a passive textile accessory and needs the scope assessment — which category it falls into is confirmed against the directive.

The European Commission’s RoHS page is the reference. REACH SVHC screening and SCIP considerations follow the same bill-of-materials review.

Does the Low Voltage Directive apply to a 5–20 V pad?

LVD applies within specific voltage thresholds (50–1000 V AC, 75–1500 V DC), so a USB-powered pad usually sits below them — but the applicability question is answered per design, and being below the thresholds does not mean there are no safety obligations.

Safety-relevant aspects are addressed through other legislation and standards, and the thermal and mechanical evidence still has to exist.

What does foreign object detection do, and can it be turned off?

FOD detects metal objects near the coil and reduces or stops power before they heat up. It is part of the chosen transmitter system, it is verified with standard metal coupons, and it must never be disabled — not for demos, not for troubleshooting.

A pad with a fabric top can hide metal from the user, which makes FOD verification a production test item, not just a design one.

What surface temperature is acceptable?

The acceptance limit must come from the applicable safety framework and touch analysis for the actual material, contact duration, user population, and market, confirmed through the product’s compliance process.

The protocol—ambient, load, receiver, alignment, measurement points, sensor method, and steady-state definition—makes the result repeatable. Do not substitute a generic temperature range for that assessment.

Can users clean the pad with sprays or wet wipes?

Only what the design and the manual allow. Unless the electronics are sealed behind a liquid barrier, the procedure is: unplug first, wipe with a damp cloth, no immersion, no spraying directly onto the surface, dry before use.

If the pad is not liquid-resistant, the manual must say so plainly, and the marketing copy must not imply otherwise.

Why did the controller inside my sample differ from the packaging drawing?

That is a bill-of-materials discipline failure: a component changed after the documentation was printed, and nobody updated the artwork or re-validated.

The controls are change control with written approval, packaging review at every BOM or firmware change, and a production check that the installed controller and firmware match the label.

What burn-in or aging test should the project require?

Document the rationale for coverage, sampling if used, load condition, ambient, duration, measurements, pass criteria, and failure disposition.

The plan should reflect component qualification, design risks, pilot findings, field history, warranty exposure, and throughput cost rather than a duration copied from another product. Any temperature or electrical limit still comes from the applicable safety and design-validation framework.

What happens if a component changes during production?

Under your change-control clause, the supplier notifies you before implementing, classifies the change, and proposes validation. Equivalent changes get retested on affected functions; major changes get full re-validation and a compliance re-check.

The compliance file is valid only for the product as declared, so silent changes void it — which is why written approval is the rule.

What documentation should be collected from the supplier?

The compliance file, at minimum: the technical documentation and declarations relevant to your markets (with applicability confirmed by your compliance professional), test reports from qualified laboratories, material declarations for RoHS/REACH screening.

The traceability records (serial, batches, firmware, test results), the user manual and label artwork, and the change-control log. Review the manual and label against the shipped configuration at every change — that review is what prevents the packaging mismatch class of failures.

What if the product is sold only through online marketplaces?

The marketplace is a sales channel, not a compliance exemption. The obligations that apply to your product — RoHS assessment, WEEE registration where applicable, EMC testing, FCC authorization for the US market.

And the rest — attach to you as the party placing the product on the market, regardless of where the order is processed.

What changes with marketplaces is documentation: platform requirements often ask for declarations, test reports, or registration numbers before a listing goes live, and market surveillance authorities do check listings.

The practical effect is that the compliance file has to exist before the listing is published, and it is the same file the technical review in this chapter describes — build it once, and it serves the platform, the distributor, and the auditor alike.

How long does compliance take, and when should the work start?

Compliance work runs in parallel with design, not after it. Classification questions (EMC versus RED, FCC part and route, RoHS scope) should be answered in writing before the design is frozen, because the answers can change hardware choices such as filtering, coil shielding, and marking.

Testing and certification add weeks to months depending on the lab and the regimes involved, so the compliance plan with dates belongs in the project schedule from the first supplier conversation, not added at launch.