Preparing PTX and PRX Products for Qi 2.3.1: An Engineering and Validation Guide

As wireless power technology continues to mature, the Wireless Power Consortium (WPC) has introduced the Qi 2.3.1 standard to fine-tune interoperability, communication, and hardware efficiency. Crucially, Qi 2.3.1 does not require companies to completely redesign their existing Qi wireless charging products. Instead, it introduces targeted updates to support new communication, power management, and compliance requirements. Power Transmitters (PTX) need to implement new power mode notifications, updated charging responses, and enhanced safety features, while Power Receivers (PRX) must correctly respond to these updates and adapt to power mode changes. Both transmitter and receiver products must also undergo the relevant compliance tests to ensure they meet the Qi 2.3.1 standard requirements. 

Start With the Product Capability Definition 

The first step in a Qi 2.3.1 migration should be to establish exactly what the product supports. This becomes increasingly important because compliance applicability is now more closely aligned with individual power modes.

The engineering team should identify the supported Qi profiles and operating modes before evaluating individual changes. The requirements relevant to an MPP25 transmitter are not necessarily identical to those of an MPP15 device. Similarly, BPP/EPP products may not be affected by every MPP-specific protocol change.

The capability definition therefore becomes the foundation for determining both implementation requirements and test applicability. Qi 2.3.1 reinforces this process through ESDF, which provides a standardized JSON representation of PTX or PRX capabilities that can be imported into compliance test tools. 

PTX Review Areas

PTX Review Area 1: SGC Implementation

For applicable PTX products, the engineering team should review how CTX capacitor changes are performed. If the product changes its CTX capacitor configuration, Qi 2.3.1 defines the new SGC FSK response to notify the receiver.

The validation effort should therefore cover more than whether the hardware successfully switches configurations. The system should verify that the configuration change occurs under the intended operating condition, the required SGC response is generated, the FSK signaling meets the protocol requirements, and the connected PRX can correctly react to the notification.

The Qi 2.3.1 protocol flow explicitly connects the transmitter-side configuration change with the receiver’s ability to optimize charging. This is an area where functional and protocol validation should be performed together.

Learn more about Qi 2.3.1 Key Protocol and Power-Management Changes.

PTX Review Area 2: MSN and Power-Mode Transitions

If the transmitter supports discrete power modes, MSN behavior should be reviewed carefully. Qi 2.3.1 defines the MSN packet as the mechanism by which a transmitter can inform the receiver that changed PTX conditions mean the current power mode can no longer be supported.

The receiver can then request another appropriate mode. A robust PTX validation plan should therefore exercise not only steady-state operation but also transitions.

The engineering team should create operating conditions that cause the current mode to become unavailable and verify the complete sequence. This includes the PTX state change, MSN transmission, PRX response, and successful movement to the appropriate new operating condition.

Power-mode-transition testing should also be repeated across supported receiver implementations where possible because the purpose of the protocol is interoperability, not merely internal consistency within one vendor’s products.

PTX Review Area 3: MPP EPT Timing 

MPP transmitters require an additional review of revised EPT timing. Certain ASK packets could previously be decoded as EPT, causing a longer pause in charging, and Qi 2.3.1 modifies the MPP timing requirements to address this issue.

For firmware and protocol teams, this means existing timing implementations should not automatically be assumed to remain compliant. The relevant timers, decoding conditions, and state transitions should be compared against Qi 2.3.1.

This is particularly important for designs that were originally validated against an earlier Qi 2.x release and are now being updated primarily through firmware.

PTX Review Area 4: MPP15 dPLoss Changes 

Qi 2.3.1 removes dPLoss calibration support for MPP15 PTX and PRX devices. Product teams should therefore identify whether their existing design includes this functionality and determine whether firmware, configuration, or test changes are necessary.

This is also an example of why specification migration cannot be handled simply by adding new features. Removed behaviors can be just as important as added ones, particularly when existing implementations were designed to satisfy earlier versions of the specification.

PRX Review Areas

PRX Review Area 1: SGC Response Handling 

For receivers, the new SGC behavior means that the PRX must correctly interpret the transmitter notification and adjust its charging operation. Validation should check the receiver's behavior before, during, and after the SGC event.

The key question is not only whether the packet is decoded. The receiver must react in the way expected by the updated Qi protocol. This requires coordination between the communication layer and the receiver’s power-control behavior. 

PRX Review Area 2: MSN-Based Mode Adaptation 

The PRX must also handle MSN notifications from the transmitter. When the PTX indicates that the current power mode is no longer supported, the PRX needs to request an appropriate alternative mode.

This transition should be tested under different operating conditions and across all applicable supported modes. The purpose is to confirm that the receiver does not remain dependent on a transmitter mode that is no longer available and that the transition occurs according to the Qi 2.3.1 protocol. 

Common PTX and PRX Requirement: ESDF 

Both transmitter and receiver teams need to adopt the new ESDF device capability declaration. This should be treated as part of the product configuration management process.

The ESDF should accurately represent the same capabilities implemented in hardware and firmware. A mismatch between the declared capability and actual implementation can create incorrect test applicability and unnecessary certification problems.

For internal validation, using the ESDF early allows the same product definition to drive test selection before formal certification. That can improve consistency between design validation and ATL testing.

Review what test engineers need to know about Qi 2.3.1 Compliance and Certification.

Revisit the Compliance Test Plan 

Qi 2.3.1 introduces a more structured test approach, where individual power modes are covered through dedicated main tests instead of being grouped mainly as sub-tests.

• Existing Qi 2.x regression suites should be reviewed and updated, rather than reused without changes.
• Test cases can be categorized into three groups:
  • Existing tests that remain applicable with little or no change.
  • Existing functionality that requires updates because test coverage is now organized by power mode.
  • New tests covering Qi 2.3.1 features such as SGC, MSN, updated protocol behavior, and negative test scenarios.
• This classification helps teams accurately estimate migration effort and prioritize implementation and validation activities.
• An increase in test count does not necessarily mean a proportional increase in development work, as many new tests reflect test restructuring rather than major feature additions. 

Include Negative Testing During Development 

Qi 2.3.1 expands negative-case compliance coverage. This should influence internal validation strategy. Testing only the expected communication path is increasingly insufficient.

Engineering teams should deliberately exercise incorrect, unsupported, and boundary-condition protocol behavior before certification. Doing this during development provides two benefits. First, it identifies implementation weaknesses earlier. Second, it reduces the risk that the product performs correctly in normal functional testing but fails during compliance because an exceptional protocol condition was never exercised.

Build a Qi 2.3.1 Regression Strategy 

For existing products migrating from an earlier release, the most effective approach is usually a targeted regression plan built around changed requirements.

Start with the supported power profiles. Map each relevant Qi 2.3.1 specification change to the product architecture. Identify whether the impact is on hardware, firmware, protocol software, configuration data, or compliance setup. Then run the applicable updated test suite using the correct ESDF capability declaration.

Both PTX and PRX products should adopt the ESDF capability declaration and rerun the compliance tests applicable to their supported power modes. This makes the regression plan traceable to the actual product configuration rather than relying on a generic checklist.

A Practical Readiness Checklist

The Path to Certification

Qi 2.3.1 should be implemented through a combined development and validation approach to ensure smooth adoption. PTX developers need to support new communication features, updated power management behaviour, improved MPP handling, and enhanced safety requirements. PRX developers must correctly respond to these updates, adapt to power mode changes, and accurately report device capabilities. Validation teams should focus on testing different power modes, protocol compliance, and error-handling scenarios. Instead of waiting for certification, teams should integrate Qi 2.3.1 requirements early in the development cycle. This approach helps identify issues sooner, improves interoperability, and makes final certification more efficient and predictable.