Advanced Wireless RX Power Path

1) What This Page Solves: Wireless RX as a Charging Entry

This section explains why a wireless charging receiver cannot be treated like a stable DC source and why it must enter your system through a managed power-path. We are not describing wireless power transfer theory, TX-side design, or Qi certification. We focus on how to let this wireless entry feed your system (VSYS) and your battery safely, and why we must add fine-grained FOD, thermal zoning, and skin-temperature limiting on top.

Three wireless-specific problems when used as a charging entry:

• Power fluctuation: received power changes with alignment and coil distance, so system rails cannot follow it directly.
• Efficiency drop under poor coupling: when coupling is bad, more of the received energy becomes heat in the RX front-end.
• User / enclosure temperature limit: unlike wired inputs, the user may touch the enclosure directly, so surface temperature must stay low.

Because of these three issues, a wireless RX must go through a VSYS-first power-path: the system stays alive, and the battery charging current is the first thing to be derated. This is different from your wired DC jack or USB-C entry.

In the global “Battery Charging / Gauging / Protection / BMS” hierarchy, the wireless RX is just one source: downward it feeds the charger / battery, upward it only reports state to BMS/host (“I derated”, “I hit thermal limit”, “FOD trigger”). It does not control pack balancing, does not replace multi-cell charger controllers, and does not negotiate USB-PD.

Wired inputs usually have higher priority. A practical rule to write into the BOM / firmware spec is: “When wired source is valid, wireless RX shall derate or shut.” That is the simplest way to avoid two entries fighting on the same power-path.

Anti-crossing note: this chapter does not describe TX, PD negotiation, or multi-cell charge state machines.

2) Wireless RX Operating Scenarios & Constraints

Before we tune FOD tables and thermal limits, we must fix the operating envelope of the RX: power level, mechanical enclosure, and temperature budget. The same RX IC behaves very differently in a 5 W wearable, a 15 W in-vehicle mount, and a 10–15 W thick handheld. This chapter tells you which constraints to write down so the power-path logic later knows what to derate first.

Power levels we target in this page:

• 5 W wearables: surface / skin is the limiting factor, not the RX silicon.
• 10–15 W phones / embedded: typical Qi/EPP level, good balance between speed and heat.
• 20–30 W enhanced Qi / vehicle dock: possible, but only if FOD and thermal zoning are well characterized.

For each scenario, define at least: ambient or enclosure temperature, maximum surface temperature, and coil/enclosure distance or materials. Without this, FOD will keep seeing “unexpected loss” and will drop you back to 3 W even though the TX can send 15 W.

Experience note: if your enclosure is thicker than the vendor’s reference design, or if you added a metal rim, you must re-characterize the FOD lookup table. Otherwise the receiver will see unexpected loss and keep derating to 3 W, even though the transmitter can deliver 15 W.

Anti-crossing note: this chapter does not cover Qi certification flow, TX coil array design, or USB-C/PD coordination.

3) RX Front-End & Rectification Path (the Efficiency Base)

This chapter makes the wireless RX front-end the baseline for all later tuning. Whatever loss you leave here will reappear as heat in the thermal zones, forcing derating earlier. So we first fix the chain Coil → synchronous rectifier → DC output, then decide where the DC goes.

A practical wireless RX front-end is always: Coil → Sync Rectifier → DC Bus → (Power-Path / Buck / LDO) Using a synchronous rectifier (as in TI bq5105x, ST STWLC38, NXP 15 W RX, Renesas P9221-R) gives you stable, repeatable sampling points so fine-grained FOD is even possible.

After rectification, the DC can: (1) go straight to the wireless power-path, (2) pass a small buck to match a downstream charger IC, or (3) be cleaned by an LDO (simplest, but hottest). Choice here = how soon thermal zoning will fire.

Engineering takeaway: the synchronous rectifier’s Rds(on) and the maximum user-facing temperature you can sustain are on the same line. If you burn watts here, thermal zoning can only react by reducing power.

Anti-crossing: this chapter does not cover AC field / coupling theory, TX-side compensation, AirFuel variants, or transmitter rectification.

4) Power-Path Architectures for Wireless RX

Wired sources are usually stable, so a simple system-first path works. Wireless RX entries are availability-driven: they only have as much power as coupling and FOD allow. That is why we need wireless-specific power-path patterns instead of copying the wired page.

We will compare three patterns: VSYS-first (for wearables, IoT, anything that must stay alive), Battery-first (for dock/maintenance charging), and Hybrid/auto (for advanced designs that read available power and current thermal zone).

Derating sequence to write into the spec: (1) reduce battery charge current; (2) if supported, reduce non-critical VSYS loads; (3) stop battery charging but keep RX powering the system. This prevents user-visible brown-outs.

Anti-crossing: this chapter does not cover wired OTG, reverse fast-charge, or pack-level ideal diode / back-to-back FET topics (handled in protection pages).

5) Fine-Grained FOD: From “On/Off” to “Per-Point Derating”

Traditional FOD logic is mostly binary: pass/fail, sometimes with a rough safety margin. For a wireless RX used as a real charging entry, this is not enough. We need FOD to tell us “how much power is still safe and thermally acceptable right now” and feed that number into the wireless power-path, so the power-path can derate gracefully instead of shutting down.

Fine-grained FOD therefore becomes not only safety but also an efficiency distribution strategy: it classifies the current RX condition and publishes an “available power” figure that the power-path can consume.

What must be monitored:

• Theoretical received power (from TX capability / negotiated profile).
• Actual received power (measured at the rectified DC / front-end sense point).
• Coil Q / coupling quality (to tell “bad structure” from “real foreign object”).
• Thermal trend (is any zone rising faster than expected?).

Once the FOD engine has this view, it should not just open the switch. It should publish a lower power level (for example 15 W → 9 W → 5 W) to the power-path. The power-path, which already knows the derating order (first reduce battery charge, then non-critical VSYS, then stop charge), will apply it.

Re-characterization rule: if the mechanical structure changes (thicker enclosure, metal rim, different coil P/N), recalibrate the FOD table, otherwise the receiver will keep falling back to a low power tier (3–5 W) even when the TX can deliver more.

Procurement note: do not swap the RX coil to a “compatible” but uncharacterized one. FOD tables are paired with the coil and enclosure stack.

Anti-crossing: this chapter does not describe metal-detection algorithms, TX-side foreign-object policy, or Qi packet-level strategies.

6) Thermal Zoning for Wireless RX (Coil / IC / Enclosure)

Wireless RX heating does not occur at one point. The coil/ferrite, the RX IC / rectifier, and the user-facing enclosure can all heat up at different speeds. A single board NTC cannot represent all of them. That is why wireless RX needs multi-zone thermal control with clear limits and a single derating output.

We define three zones: Zone A for the coil/ferrite (high temperature allowed, but efficiency goes down), Zone B for the RX IC/rectifier (lifetime and current-limit), Zone C for the enclosure/skin (user-facing, strict).

Why some devices feel hot but are “within spec” inside: only Zone B was monitored (IC temperature OK) but Zone C (surface) was never fed back to the control loop. Adding C will make the device derate earlier, but in a user-friendly way.

Sensor placement warning: if the NTC is too far from the real hot spot or from the enclosure, the system will derate late or derate wrongly. Pick NTC/thermal IC/MLX IR according to the zone you are actually controlling.

Anti-crossing: this chapter does not cover system-level thermal design (fan, graphite, heat pipes) or automotive whole-vehicle thermal validation (these belong to platform / enclosure pages).

7) Skin-Temperature Limiting with External IR Sensor (Melexis Angle)

Board-level or IC-level temperature sensing can only see PCB / RX IC / coil temperatures. It cannot see what the user actually touches — the enclosure or skin surface. For wearable and in-vehicle wireless RX, that is the limiting factor. So we add an external IR sensor such as Melexis MLX90632 / MLX90614 on I²C and feed its result into the same “available power” path used by FOD and thermal zoning.

The control policy is simple and aggressive: >42 °C → 7–9 W, >45 °C → 3–5 W, >48 °C → stop / keep-alive only. This maps 1:1 to the power tiers defined in the fine-grained FOD chapter, so the power-path can understand it immediately.

Kids / medical wearables: shift every threshold down by 2 °C (40 °C → 7–9 W, 43 °C → 3–5 W). This creates headroom for sensitive skin without touching the rest of the power-path logic.

Calibration note: different enclosure paints, silicone sleeves, or dark coatings change the apparent IR temperature. Run a one-time factory calibration with the real enclosure and commit the offset into the RX / host side.

Anti-crossing: this chapter does not cover Melexis thermal imaging, automotive optics, Hall sensing, or full IR theory — we only use IR as an external skin-temperature source for wireless power derating.

8) Coordination with Downstream Charging IC / System Rail

Wireless RX typically provides 5–15 W, but the battery below may accept far less current due to cell chemistry, pack temperature, or charger IC limits. After the wireless power-path has computed the available power now, this information must be pushed into the downstream charger and the system rail rules, so that the whole BMS chain stays consistent.

A good BOM-level statement is: “When wireless RX is present, reduce battery charge current to <XXX mA> and keep VSYS first.” This makes hardware, firmware, and procurement all see the same rule.

BOM wording example: “When wireless RX present, reduce battery charge current to 450 mA and maintain 3.3 V / 5 V system rails. If USB-C present, disable wireless charging or limit to 3 W keep-alive.”

Procurement note: choose charger ICs from TI, ST, Microchip, NXP, or Renesas that can be current-limited or power-notified over I²C / registers; otherwise the derating must be done early at the wireless RX side, which wastes available power.

Anti-crossing: this chapter does not describe full buck/boost topologies, multi-cell balancing FETs, or USB-PD message flows — those live in their own pages under the BMS template.

9) Faults, Events & Reporting to BMS / Host

Wireless RX has several entry-specific conditions that do not kill the system but do require reporting: FOD abnormal loss, internal thermal zone over-limit, user-surface (skin) over-limit, poor alignment, and brown-out on the RX supply. These must be sent to the BMS / host over the same I²C / interrupt path so engineering and procurement can see why the wireless port derated.

Key events to report:

• FOD fail / abnormal loss → EVENT_FOD_ABNORMAL (derate, do not just turn off).
• Thermal zone B over → EVENT_THERMAL_ZONE_B (rectifier / RX IC too hot).
• Skin-temp over (IR) → EVENT_SKIN_LIMIT (surface > 42–45 °C → 7–9 W / 3–5 W).
• RX alignment poor → EVENT_ALIGNMENT_POOR (power limited due to coil mismatch).
• RX supply brown-out → EVENT_RX_BROWNOUT (wireless dropped but system must survive).
• (Optional) Source overridden → EVENT_SOURCE_OVERRIDDEN (USB-C / wired won, wireless derated).

Ring buffer idea: store the last 8–16 derating reasons as {event_id, cause, power_at_that_time} and overwrite oldest entries. Host reads it on boot or periodically.

Anti-crossing: this chapter does not cover full device logging (cloud / fleet), SoC/SOH algorithms, or CAN/UDS diagnostic trees.

10) Seven-Brand Parts Mapping & Selection Notes

To keep this page aligned with your global sourcing strategy (TI, ST, NXP, Renesas, onsemi, Microchip, Melexis), this section maps typical wireless power receiver ICs and the companion infrared sensors used in the previous chapters. English full names are included for quick search and documentation.

Note that several of these parts require a vendor-recommended RX coil / stack-up to keep the FOD table valid. If procurement swaps the coil, re-run characterization — otherwise Chapter 9 events will appear often.

Anti-crossing: no China-based alternatives here; no re-listing of PMIC / buck / boost parts already covered in other hubs.

1) Why does my wireless RX drop from 15 W to 5 W when the enclosure is thicker?

Because the FOD table was characterized for a certain coil–distance–material stack. A thicker or metal-edged enclosure changes the loss model, so the RX only exposes a lower available_power_now (typically 5 W). Re-characterize FOD whenever you change the housing.

2) Can I make the wireless RX always feed VSYS first?

Yes. Use a wireless-optimized power-path in VSYS-first or hybrid mode. The RX reports its available power to the power-path, which allocates to the system rail first and only then to the battery. Write this rule in the BOM so validation and procurement know it is intentional.

3) What happens if the RX supply browns out — will the system rail die?

It should not. A correct RX power-path keeps VSYS alive by derating or pausing the battery charge and by raising an EVENT_RX_BROWNOUT to the host/BMS. The host can log the event and show that the dip came from the wireless entry, not from the battery.

4) Why is wireless weaker than USB-C even when the coil looks aligned?

Because the source priority rule is “wired wins, wireless derates.” When a valid USB-C/DC source is present, the RX must step back to a keep-alive power (e.g. 3–5 W) to avoid fighting the wired charger. This is normal behaviour in BMS-oriented designs.

5) Do I need to re-characterize FOD after changing the coil or cosmetics?

Yes. Wireless RX is highly tied to the original coil, shielding and enclosure. If procurement changes to a “similar” coil, you must re-run FOD and store a new table — otherwise you will see frequent 3–5 W derates and FOD events in the host log.

6) Why does it derate on skin temperature while the board is still cool?

Board/IC sensors only see internal heat (coil, rectifier). The user touches the enclosure, which can be 5–10 °C hotter. An external IR sensor (e.g. Melexis MLX90632) enforces the user-facing limit, so the system derates even if PCB NTCs are not at their limit.

7) How do I plug a Melexis MLX90632/90614 into the derating loop?

Read IR temperature over I²C → run the 42/45/48 °C policy → convert the result to an available power tier (15→9→5 W) → hand it to the wireless power-path. From the power-path’s view it is just another input, same as FOD and thermal zones.

8) What thresholds should I use for kids or medical wearables?

Use the same 3-step policy but shift it down by 2 °C. Example: 40 °C → 7–9 W; 43 °C → 3–5 W; 46 °C → stop. This keeps integration identical but gives more safety margin for sensitive skin.

9) Will enclosure color or coating affect IR-based limiting?

Yes. Different emissivity changes the apparent temperature. Run a one-time factory calibration with the final housing and store the offset in NVM so the IR reading maps to the real surface temperature.

10) Can I rely only on the internal NTC and skip the IR sensor?

You can, but you will lose control over the user-facing temperature. For wearables or in-vehicle hot cabins, IR-based skin limiting is the only way to guarantee comfort while keeping power as high as possible.

11) Which wireless RX events must the BMS / host always log?

At minimum: FOD abnormal, thermal zone B over, skin-temp over, alignment poor, and RX brown-out. Optionally also log “wired source overrode wireless.” These explain every derate to engineering and to purchasing.

12) How big should the fault/event buffer be?

8–16 entries in a ring buffer is enough. Store event ID + cause + power-at-that-time. Overwrite the oldest entries. Host can dump the buffer on boot or when a service tool connects.

13) Why do procurement and QA need access to these logs?

Because wireless RX behaviour depends on vendor sensing parameters. If a coil, shield or enclosure was swapped, the log will suddenly fill with FOD / alignment / skin-limit events. This proves it is a BOM change, not a design flaw.

14) Can the downstream charger IC be told to reduce current when wireless is present?

Yes. Select TI / ST / Microchip / NXP / Renesas charger ICs that accept I²C current-limit or power-notification writes. Then add a BOM note: “When wireless RX present, reduce battery charge current to <XXX mA>; keep VSYS.”

15) Is this wireless RX scheme valid for 2S–6S multi-cell chargers?

The entry logic (FOD → thermal → skin → available power → tell power-path) is valid. But multi-cell balancing, pack FET driving, and safety cutoffs must stay in the dedicated “Multi-Cell Charger Controller (2S–6S)” page to avoid content overlap.