prEN IEC 63758-5-1:2026

• Status: Not Published
• Publication Date: 23-Feb-2028
• Technical Committee: CLC/TC 100X - Audio, video and multimedia systems and equipment and related sub-systems
• Current Stage: 4020 - Enquiry circulated - Enquiry
• Start Date: 18-Sep-2026
• Completion Date: 18-Sep-2026
• Directive: 2014/53/EU - Directive 2014/53/EU of The European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC
• Mandate: M/607 - COMMISSION IMPLEMENTING DECISION of C(2025)1207 on a Standardisation Request M/607 as regards charging interface and charging communication protocol for radio equipment capable of being recharged by means of wireless charging in relation with Article 3(4), sixth subparagraph, of Directive 2014/53/EU of the European Parliament and of the Council.
• Ref Project: oSIST prEN IEC 63758-5-1:2026 - Qi specification - Version 2.3 - Part 5-1: MPP communications protocol (Fast Track)

prEN IEC 63758-5-1:2026 is a CLC draft for the Qi specification, Version 2.3, Part 5-1. It defines the Magnetic Power Profile (MPP) communications protocol between a Power Transmitter (PTx) and a Power Receiver (PRx), including the order and timing of messages used to set up, control, pause, and resume wireless power transfer. The document also defines packet formats that support higher-level functions such as authentication, power modes, and extended data streams.

What does prEN IEC 63758-5-1:2026 specify?

prEN IEC 63758-5-1:2026 specifies the messaging used by the Magnetic Protocol for the MPP Power Profile. The main purpose is to set up and control power transfer, and a secondary purpose is to carry higher-level application traffic such as Authentication.

The document is organized into general rules, the Magnetic Power Profile, negotiation, power transfer, cloak, extended data streams, packet definitions for the PRx and the PTx, and Annex A for DPLOSS compatibility. In practice, that means it is both a protocol flow document and a packet dictionary for implementers.

Annex	What it covers
Annex A	Protocol for DPLOSS compatibility with SWCPRx and Boost-Based PTx products

What are the key requirements of prEN IEC 63758-5-1:2026?

Clause 1 sets the rules for how to read the document. Provisions are mandatory unless they are marked as recommended, optional, note, example, or informative. It also fixes the conventions for numbers, packet fields, and text strings, so implementers know how to encode values, pack bits, and interpret quoted text.

Session start and mode advertisement

Clause 3 defines three protocol modes: Restricted Mode, 15W Full Mode, and 25W Full Mode. Restricted Mode uses one-way communication from PRx to PTx at 360 kHz with the Baseline Protocol, while Full Mode uses bi-directional communication and supports higher power and more advanced operations. In practice, a product can begin with limited behavior and then move to a richer session if both sides advertise support.

Clause 3.2 requires a PRx to start the session by sending SignalStrength, Identification, ExtendedIdentification, an optional PowerControlHold-Off, and Configuration. The ID packet must advertise the Qi version correctly, and the XID packet is where the PRx signals MPP support and whether it wants Restricted Mode or Full Mode. This matters because the PTx decides the rest of the flow from those advertisements.

Clause 3.3 sets the PTx side behavior for startup and FSK response handling. MPP uses predefined FSK behavior, including fixed switching-cycle settings and dedicated response patterns such as ACK, NAK, ND, ATN, and the MPP response pattern. For a reader, the practical point is that the implementation cannot improvise these return messages.

Negotiation before power transfer

Clause 4 says MPP negotiation builds on Qi EPP rules, but with explicit MPP changes. MPP does not support the FOD packet or the FOD calibration phase in negotiation, so the session focuses on identification, capability exchange, power loss accounting, frequency selection, power mode selection, and stream setup. That means the negotiation logic must be designed for MPP-specific packets rather than only EPP behavior.

Clause 4.2 lets the PRx use allowed negotiation packets such as GET, EDS, REPORT, PLAP, PLAP_2, ECAP, MSR, MATEDQ_COEFF, and KEST_COEFF. If the PTx receives a power-transfer packet too early, it removes the power signal and returns to ping. In practice, that protects both sides from moving into power transfer before the contract is complete.

Clause 4.4 and 4.5 split negotiation into 128 kHz and 360 kHz flows. The 128 kHz phase is used to select 360 kHz, while the 360 kHz phase is used to exchange capabilities, negotiate power, exchange enabled data streams, select power modes, and adjust cloaking and version behavior. For implementers, this means the session has a frequency-change step and then a richer negotiation step at the target frequency.

Clause 4.7 allows a PRx to change the protocol version it implements during negotiation by using SRQ/verSel. The document shows that version change can be used to move into newer behavior without first removing power, but only when the PTx reports a suitable version. This is important for backward compatibility and for staged upgrades of a receiver.

Power transfer, cloak, and advanced packet exchange

Clause 5 says the power transfer phase follows Qi EPP rules, but MPP adds its own control and accounting packets. Only 360 kHz is supported in this phase, and MPP extends standard control error and received-power behavior with XCE and PLA. In practice, the charger and device must use the MPP packet set rather than standard Qi-only control packets when operating in full MPP transfer.

Clause 5.2 and 5.4 define the extended control and power loss accounting behavior. XCE adds a communication window so the PTx can acknowledge, reject, or request more communication, and PLA provides a throttling-based mechanism for power-loss accounting. This matters because MPP uses these packets for control, feedback, and foreign-object-related behavior during transfer.

Clause 5.8 defines power modes and mode selection. The protocol distinguishes main power modes and auxiliary modes, and it allows a PRx to request a mode with a stated preference for keeping or replacing the current power transfer contract. For buyers and engineers, this is the part that determines whether a product can support low-power, nominal, high-power, or continuous operation strategies.

Clause 6 defines Cloak as a temporary interruption of power transfer without resetting the negotiated contract. Either side can initiate cloak, and the flow includes cloak pings, optional detect pings, and a cloak exit handshake using REPORT and GET[PTxXID]. In practice, Cloak is used when a device needs a short power pause for actions such as coexistence handling, thermal management, or accessory identification.

Clause 7 extends application-layer communication with simultaneous data streams and CRC-16 integrity checking. The document defines open, close, transport, and response behavior for multiple streams, and it lets the initiator compute and report a CRC at close. That means MPP is not only a power protocol - it also supports structured in-band data exchange with error checking.

What terms does prEN IEC 63758-5-1:2026 define?

• Magnetic Power Profile (MPP) - the Qi protocol extension that adds messages, modes, and contract elements for magnetic wireless power transfer.
• Power Transmitter (PTx) - the transmitting device that identifies the receiver, responds to requests, and controls the power signal.
• Power Receiver (PRx) - the receiving device that advertises capabilities, negotiates the contract, and requests changes.
• Amplitude Shift Keying (ASK) - the base signaling method used for PRx-to-PTx communication in the protocol.
• Frequency Shift Keying (FSK) - the return-channel signaling method used by the PTx in negotiation and many response flows.
• Extended Control Error (XCE) - the MPP control packet that extends standard control-error handling with a communication window.
• Power Loss Accounting (PLA) - the MPP mechanism for reporting received power and supporting throttling-based power-loss handling.
• Cloak - a controlled, temporary interruption of power transfer that preserves the negotiated contract.

Who uses prEN IEC 63758-5-1:2026?

prEN IEC 63758-5-1:2026 is used by engineers designing Qi wireless charging transmitters and receivers, especially firmware teams that implement packet exchange, negotiation, and power-mode logic. It is also used by quality and compliance teams that need to verify message order, timing behavior, stream handling, and packet compatibility.

The document is relevant to product developers working on wireless power devices that support MPP features such as cloaking, extended identification, power loss accounting, power mode selection, and simultaneous data streams. Test labs and interoperability teams use it to check that a PTx and PRx respond correctly across startup, negotiation, power transfer, and cloak flows.

Which standards are used with prEN IEC 63758-5-1:2026?

• Qi Communications Protocol book - provides the baseline packet handling, timing rules, and common request patterns that MPP reuses.
• MPP Communications Physical Layer book - provides the FSK parameters and related physical-layer behavior for MPP.
• MPP Power Delivery book - provides related power-delivery behavior, including K-estimation, frequency-change behavior, and some power-mode details.
• MPP Foreign Object Detection book - provides the related power-loss accounting and calibration context used with PLA and DPLOSS.
• Qi Specification, Foreign Object Detection - is cited for FOD-related behavior around stopping and restarting power transfer.
• Qi Specification, NFCTagProtection - is cited for the NFC-related end-power-transfer handling.

What does the prEN IEC 63758-5-1:2026 document contain?

The document contains packet structures for PRx and PTx messages, including request, response, status, identification, capability, calibration, mode, and data-stream packets. It also contains flow diagrams and timing diagrams for startup, negotiation, frequency change, cloak entry and exit, and data-stream recovery.

It includes example sequences that show how devices behave in normal operation, on errors, during version changes, and when power is interrupted or resumed. The packet definitions cover both ASK and FSK usage, which helps implementers map each message to the correct direction and phase.

Annex A adds a compatibility protocol for DPLOSS across power modes, including cases where calibration is retained through a mode transition or restarted on request. This makes the document useful not only for basic charging, but also for systems that need calibration continuity across mode changes.

SLOVENSKI STANDARD
01-november-2026
Specifikacija Qi - Različica 2.3 - 5-1. del: Komunikacijski protokol MPP (hitri
postopek)
Qi specification - Version 2.3 - Part 5-1: MPP communications protocol (Fast Track)
Ta slovenski standard je istoveten z: prEN IEC 63758-5-1:2026
ICS:
29.240.99 Druga oprema v zvezi z Other equipment related to
omrežji za prenos in power transmission and
distribucijo električne energije distribution networks
33.160.99 Druga avdio, video in Other audio, video and
avdiovizuelna oprema audiovisual equipment
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

100/4543/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 63758-5-1 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2026-09-18 2026-12-11
SUPERSEDES DOCUMENTS:
IEC TC 100 : AUDIO, VIDEO AND MULTIMEDIA SYSTEMS AND EQUIPMENT
SECRETARIAT: SECRETARY:
Japan Ms Mahiru Uehara
OF INTEREST TO THE FOLLOWING COMMITTEES: HORIZONTAL FUNCTION(S):
TC 106,TC 108
ASPECTS CONCERNED:
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they
are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
Qi Specification - Version 2.3 - Part 5-1: MPP Communications protocol (Fast Track)

PROPOSED STABILITY DATE: 2029
NOTE FROM TC/SC OFFICERS:
As this is a fast-track process offered by WPC, the Word file is not provided.

electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

QiSpecification
MPPCommunicationsProtocol
Version2.3
PublishDate:09December2025
DISCLAIMER
Theinformationcontainedhereinisbelievedtobeaccurateasofthedateofpublication,butisprovided“asis”andmay
containerrors.TheWirelessPowerConsortiummakesnowarranty,expressorimplied,withrespecttothisdocument
anditscontents,includinganywarrantyoftitle,ownership,merchantability,orfitnessforaparticularuseorpurpose.
NeithertheWirelessPowerConsortium,noranymemberoftheWirelessPowerConsortiumwillbeliableforerrorsin
thisdocumentorforanydamages,includingindirectorconsequential,fromuseoforrelianceontheaccuracyofthis
document.Foranyfurtherexplanationofthecontentsofthisdocument,orincaseofanyperceivedinconsistencyor
ambiguityofinterpretation,contact:[e-mail].

Contents
1. General 8
1.1 StructureoftheQi Specification 8
1.2 Scope 9
1.3 Compliance 9
1.4 References 9
1.5 Conventions 10
1.5.1 Notationofnumbers 10
1.5.2 Tolerances 10
1.5.3 Fieldsinadatapacket 10
1.5.4 Notationoftextstrings 11
1.5.5 Short-handnotationfordatapackets 11
2. Introduction 12
2.1 Overview 12
3. MagneticPowerProfile 13
3.1 Overview 13
3.1.1 RestrictedMode 13
3.1.2 15WFullMode 13
3.2 PowerReceiverRequirements 14
3.2.1 AmplitudeShiftKeying(ASK) 14
3.2.2 StartupBehaviour 14
3.2.3 ProfileActivation 16
3.3 PowerTransmitterRequirements 18
3.3.1 FrequencyShiftKeying(FSK) 18
3.3.2 TimingsOverride 20
3.3.3 StartupBehaviour 21
3.4 SupportingEPPandMPPprotocols 24
3.4.1 MPP/EPPSupportonPRx 24
3.4.2 MPP/EPPSupportonPTx 25
4. NegotiationPhase 26
4.1 Overview 26
4.2 Requirements 26
4.2.1 NegotiationPhaseTimings 28
4.2.2 FSKCycles 28
4.2.3 EnteringNegotiationPhaseWithErrorStatus 28
4.2.4 PowerTransferContractExtension 29
4.3 KEST EcosystemScalingandErrorHandling 32
4.3.1 Introduction 32
4.3.2 ErrorHandling 32
4.3.3 Examples 33
4.4 NegotiationPhase-128kHz 35

4.4.1 Nominalnegotiationflow 35
4.4.2 NegotiationflowwithPTxerrorstatus 37
4.4.3 FrequencySelection 38
4.5 NegotiationPhase-360kHz 39
4.5.1 PRxExtendedCapabilities 41
4.5.2 PTxExtendedCapabilities 41
4.5.3 ExchangePowerLossAccountingParameters 41
4.5.4 PowerNegotiation 41
4.5.5 RetrievePTxExtendedID 41
4.5.6 ExchangeEnabledDataStreams 42
4.5.7 PowerControlProfile 42
4.5.8 CloakingDuration 42
4.5.9 MPPProprietaryRequests/Packets 42
4.6 NFCIdentification(Informative) 42
4.7 Changingtheprotocolversion 43
4.7.1 Example1 44
4.7.2 Example2 44
5. PowerTransferPhase 45
5.1 Overview 45
5.2 ExtendedControlErrorPacket 45
5.2.1 Handling 45
5.2.2 PTxResponse 46
5.2.3 Example 47
5.3 ControlErrorCalculationMethod 48
5.3.1 Changingthecontrolmethod 48
5.3.2 Example1 48
5.3.3 Example2 48
5.4 PowerLossAccountingPacket 49
5.4.1 Handling 49
5.4.2 PTxResponse 50
5.5 ControlStatus 51
5.6 GETRequest 52
5.6.1 PRxInitiated 52
5.6.2 PTxInitiated 52
5.6.3 Examples 53
5.7 MPP-RestrictedtoFullModeTransition 53
5.7.1 Transitionwithpowerinterruption 54
5.7.2 Transitionwithoutpowerinterruption 54
5.8 PowerModes 57
5.8.1 Overview 57
5.8.2 Definition 57
5.8.3 DesignGuidelinesforPowerModes 60
5.8.4 IdentifyingPowerModesCapabilities 60

5.8.5 PowerModeSelection 62
5.8.6 StateDiagram 68
5.8.7 PowerModesCapabilityChangeNotification 69
5.8.8 PowerModesSelectionNotification 70
5.8.9 HandlingCommunicationFailures 71
5.8.10 Examples(Informative) 72
5.9 DPLOSSCalibration 79
5.9.1 Overview 79
5.9.2 ChoosingnottobeginCalibration(PRx) 79
5.9.3 PerformingMated-QFODbeforestartingCalibration(PTx) 79
5.9.4 CalibrationProcedure 79
5.9.5 Example1 81
5.9.6 Example2 82
5.9.7 Timing 83
5.9.8 ExtendingCalibration 83
5.9.9 Example1 83
6. CloakPhase 85
6.1 Overview 85
6.2 CloakPingRequirements 85
6.3 CloakEntry 85
6.3.1 PRxInitiated 85
6.3.2 PTxInitiated 87
6.4 CloakExit 88
6.5 Detectping 89
6.6 StateDiagram 90
6.7 CloakTimings 93
6.8 Examples 95
7. ExtendedDataStreams 99
7.1 Overview 99
7.2 SimultaneousDataStreamExtension 99
7.2.1 ErrorHandling 100
7.2.2 Timings 100
7.2.3 CloakingCompatibility 101
7.3 DataIntegrityExtension 101
7.4 Examples 101
8. PowerReceiverdatapackets 110
8.1 CAL_CAPTURE-CalibrationCapture(0x96) 112
8.2 CAL_ENTER-EnterCalibration(0x2C) 114
8.3 CAL_EXIT-ExitCalibration(0x2D) 115
8.4 CAL_OP-CalibrationOperation(0x23) 116

8.5 CLOAK-Cloak(0x18) 117
8.6 ECAP-ExtendedPowerReceiverCapabilities(0x84) 118
8.7 EDS-EnabledDataStreams(0x29) 119
8.8 EPT-EndPowerTransfer(0x02) 120
8.9 GET-GetRequest(0x28) 122
8.10 KEST_COEFF-KESTCoefficients(0x50) 123
8.11 MATEDQ_COEFF-Mated-QCoefficients(0xA8) 125
8.12 MPP-XID-QiMPPExtendedIdentification(0x81) 126
8.13 MSR-ModeSelectRequest(0x13) 127
8.14 PLA-PowerLossAccounting(0x58:1) 128
8.15 PLA_2-PowerLossAccounting2(0x88) 129
8.16 PLAP-PowerLossAccountingParameters(0x78) 130
8.17 PLAP_2-PowerLossAccountingParameters2(0x90) 131
8.18 PROP-Proprietary(multipleheaders;multipletypes) 133
8.19 REPORT-Report[PRxIdentification](0x58:0) 134
8.20 SADC-SimultaneousAuxiliaryDataControl(0x48) 135
8.21 SADT-SimultaneousAuxiliaryDataTransport(multipleheadercodes) 137
8.22 SDSR-SimultaneousDataStreamResponse(0x38) 138
8.23 SRQ-SpecificRequest(0x20) 139
8.23.1 SRQ/cloakh-SpecificRequest[CloakPingDelay-HighByte](0x20/0xF7) 140
8.23.2 SRQ/cloakl-SpecificRequest[CloakPingDelay-LowByte](0x20/0xF5) 141
8.23.3 SRQ/detect-SpecificRequest[CloakDetectPingDelay](0x20/0xF8) 142
8.23.4 SRQ/egpl-SpecificRequest[PowerLevel](0x20/0xF3) 143
8.23.5 SRQ/freqsel-SpecificRequest[FrequencySelection](0x20/0xF0) 144
8.23.6 SRQ/MppProp-SpecificRequest[ProprietaryParameters](0x20/0xE0-0xEF) 145
8.23.7 SRQ/pcp-SpecificRequest[PowerControlProfile](0x20/0xF6) 146
8.23.8 SRQ/pla-SpecificRequest[PLAFormatSelection](0x20/0xA0) 147
8.23.9 SRQ/verSel-SpecificRequest[VersionSelect](0x20/0xA7) 148
8.23.10 SRQ/xceGain-SpecificRequest[ControlGain](0x20/0xA9) 149
8.23.11 SRQ/xceMethod-SpecificRequest[ControlErrorCalculationMethod]
(0x20/0xA1) 150
8.24 XCE-ExtendedControlError(0x19) 151
9. PowerTransmitterdatapackets 152
9.1 CAL_CAP-CalibrationCapabilities(0x43) 154
9.2 CAL_CAPTURE_RSP-CalibrationCaptureResponse(0x14) 155
9.3 CAL_ENTER_RSP-EnterCalibrationResponse(0x34) 156
9.4 CAL_OP_RSP-CalibrationOperationResponse(0x1B) 158
9.5 CHS-ChargeStatus(0x1F) 159
9.6 CLOAK-CloakRequest(0x1E:0) 160

9.7 dPCAL_PARAM-CalibrationParameter(0x54) 161
9.8 ECAP-ExtendedPowerTransmitterExtendedCapabilities(0x8F:1) 162
9.9 EDS-EnabledDataStreams(0x2F) 164
9.10 EPTR-EndPowerTransferRequest(0x0A) 165
9.11 ERR-ErrorStatus(0x01) 166
9.12 GET-GetRequest(0x2E) 167
9.13 GMP-GainMeasurementParameters(0x61) 168
9.14 INV-InverterVoltage(0x3F:0) 169
9.15 KEST-EstimatedK(0x3F:2) 170
9.16 MATEDQ_RES-Mated-QResult(0x40) 171
9.17 MODECAP-PowerModesCapabilities(0x5A) 172
9.18 MODEXCAP-PowerModesExtendedCapabilities(0xA0) 174
9.19 MSN-ModeSelectionNotification(0x13) 176
9.20 MSS-ModeSelectStatus(0x23) 177
9.21 PLAP-PowerLossAccountingParameters(0x5F) 178
9.22 PLAP_2-PowerLossAccountingParameters(0x88) 179
9.23 PROP-Proprietary(multipleheaders;multipletypes) 180
9.24 RCS-RegulationControlStatus(0x1E:3) 181
9.25 SADC-SimultaneousAuxiliaryDataControl(0x4F) 182
9.26 SADT-SimultaneousAuxiliaryDataTransport(multipleheadercodes) 183
9.27 SDSR-SimultaneousDataStreamResponse(0x3F:1) 184
9.28 XID-ExtendedPowerTransmitterIdentification(0x8F:0) 185
AnnexA: ProtocolforDPLOSSCompatibilitywithSWCPRxandBoost-BasedPTxproducts 186
A.1 ProtocolCarryingDPLOSSCalibrationAcrossPowerModes 186
A.2 PRx-InitiatedRe-CalibrationSequence 187

1. General
TheWirelessPowerConsortium(WPC)isaworldwideorganizationthataimstodevelopandpromoteglobalstandards
forwirelesspowertransferinvariousapplicationareas.Animportantapplicationareacomprisesflat-surfacedevices
suchasmobilephonesandchargersoperatingatpowerlevelsupto25W.
1.1 StructureoftheQi Specification
Generaldocuments
l
Introduction
l
Glossary,Acronyms,andSymbols
l
TechnicalSystemOverview
l
PowerProfiles
Systemdescriptiondocuments
l
Mechanical,Thermal,andUserInterface
l
PowerDelivery
l
CommunicationsPhysicalLayer
l
CommunicationsProtocol
l
ForeignObjectDetection
l
NFCTagProtection
l
AuthenticationProtocol
l
MPPCommunicationsProtocol
l
MPPMagneticsDesign
l
MPP PowerDelivery
l
MPP CommunicationsPhysicalLayer
l
MPP ForeignObjectDetection
l
MPP DesignGuidelines(Informative)
l
MagneticCovers
l
ActiveAlignmentSystem
l
ThermalManagementProtocol
1.2 Scope
TheQiSpecification,MPPCommunicationsProtocol(thisdocument)definesthemessagingbetweenaPowerTransmitter
andaPowerReceiverspecifictotheMagnetic ProtocolusedfortheMPPPowerProfile.Theprimarypurposeofthis
messagingistosetupandcontrolthepowertransfer.Asasecondarypurpose,itprovidesatransportmechanismfor
higherlevelapplicationssuchasAuthentication.Thecommunicationsprotocolcomprisesboththerequiredorderand
timingrelationsofsuccessivemessages.
1.3 Compliance
AllprovisionsintheQiSpecificationaremandatory,unlessspecificallyindicatedasrecommended,optional,note,
example,orinformative.VerbalexpressionofprovisionsinthisSpecificationfollowtherulesprovidedinISO/IEC
Directives,Part2.
Table1-Verbalformsforexpressionsofprovisions
Provision Verbalform
requirement “shall”or“shallnot”
recommendation “should”or“shouldnot”
permission “may”or“maynot”
capability “can”or“cannot”
1.4 References
Forundatedreferences,themostrecentlypublisheddocumentapplies.ThemostrecentWPCpublicationscanbe
downloadedfromhttp://www.wirelesspowerconsortium.com.

1.5 Conventions
1.5.1 Notationofnumbers
l
Realnumbersusethedigits0to9,adecimalpoint,andoptionallyanexponentialpart.
l
Integernumbersindecimalnotationusethedigits0to9.
l
Integernumbersinhexadecimalnotationusethehexadecimaldigits0to9andAtoF,andareprefixedby"0x"
unlessexplicitlyindicatedotherwise.
l
SinglebitvaluesusethewordsZEROandONE.
1.5.2 Tolerances
Unlessindicatedotherwise,allnumericvaluesintheQiSpecificationareexactlyasspecifiedanddonothaveany
impliedtolerance.
1.5.3 Fieldsinadatapacket
Anumericvaluestoredinafieldofadatapacketusesabig-endianformat.Bitsthataremoresignificantarestoredata
lowerbyteoffsetthanbitsthatarelesssignificant.Table2andFigure1provideexamplesoftheinterpretationofsuch
fields.
Table2-Exampleoffieldsinadatapacket(table)
b b b b b b b b
7 6 5 4 3 2 1 0
B (msb)
B 16-bitNumericDataField (lsb)
B OtherField
(msb)
B 16-bitNumericDataField (lsb)
Field
Figure1-Examplesoffieldsinadatapacket

1.5.4 Notationoftextstrings
TextstringsconsistofasequenceofprintableASCIIcharacters(i.e.intherangeof0x20to0x7E)enclosedindouble
quotes(").Textstringsarestoredinfieldsofdatastructureswiththefirstcharacterofthestringatthelowestbyte
offset,andarepaddedwithASCIINUL(0x00)characterstotheendofthefieldwherenecessary.
EXAMPLE: Thetextstring“WPC”isstoredinasix-bytefieldsasthesequenceofcharacters'W','P','C',NUL,NUL,and
NUL.Thetextstring“M:4D3A”isstoredinasix-bytefieldasthesequence'M',':','4','D','3',and'A'.
1.5.5 Short-handnotationfordatapackets
Inmanyinstances,theQiSpecificationreferstoadatapacketusingthefollowingshorthandnotation:
/
Inthisnotation,referstothedatapacket'smnemonicdefinedintheQiSpecification,Communications
Protocol,andreferstoaparticularvalueinafieldofthedatapacket.Thedefinitionsofthedatapacketsin
theQiSpecification,CommunicationsProtocol,listthemeaningsofthemodifiers.
Forexample,EPT/ccreferstoanEndPowerTransferdatapackethavingitsEndPowerTransfercodefieldsetto0x01.

2. Introduction
2.1 Overview
Magneticpowerprofile(MPP)isaprotocolextensionthatprovidesadditionalmessages,newpowerstates/modes,new
powertransfercontractelements,andaimstoprovidethefollowingfunctionalities:
l
OperatingFrequencyNegotiation
l
Cloaking(PowerPause)
l
GenericInformationExchange
l
SimultaneousDataStreamTransactions
l
FastPTxtoPRxcommunication
l
MaximumPowerandPowerControlProfilesDetermination
l
ExtendedPowerNegotiation
l
ExtendedPTx/PRxIdentificationandCapabilities
l
ExtendedControlErrorPacketsandReceivedPowerPackets
l
PowerTransmitterBatteryLevelReporting
l
EcosystemScalability
AsummaryofdifferencesbetweenMagneticPowerProfileandEPPislistedbelowinTable3.
MPPextensionallowsdevicestooperateunderRestrictedmode(noPTxcommunication)at360kHzwithout
performinganyexplicitnegotiationwiththePowerTransmitter.Thisflexibilityenablesdeviceswithlimitedresources
(e.g.,deviceswithnoFSKsupport)totakeadvantageofthefrequencychangefeature.
Table3- MPPSpecificationsDeparturefromQiEPP
Feature EPP MPP
PTxHandshakeMessage  EPPFSKACKMessage  MPPFSKACKMessage
(Section3.3.1,FrequencyShiftKeying
(FSK))
FSKParametersNegotiation EPP allows FSK parameters negotiation  FixedFSKparameters
DataStreams   SingleStreamTransfer  MultipleConcurrentTransfer
ForeignObjectDetection FODPacket,Calibration,RP ReplacedwithMPPPowerLoss
AccountingPacket
3. MagneticPowerProfile
3.1 Overview
ThischapterdescribesthePowerReceiverandPowerTransmitterrequirementsforMagneticPowerProfileandthe
modesdevicesmayusetocommunicate.
MPPsupportsthreeprotocolmodes:
1. RestrictedMode:One-waycommunication(PRxtoPTx)withlimitedpowerlevels(5W )usingQiBaseline
Protocol
2. 15WFullMode:Supportsbi-directionalcommunicationandenablesnegotiationofpowerlevelsupto15W
3. 25WFullMode:Supportsbi-directionalcommunicationandenablesnegotiationofpowerlevelsupto25W,
andpowermodeoptimizations
3.1.1 RestrictedMode
MPPRestrictedmodeallowsPRxtoestablishachargingsessionwithPTxusingone-waycommunication(PRxtoPTx)at
360kHzoperatingfrequencyusingQiBaselineProtocol.
WhenoperatingintheRestrictedModeoftheMagneticProtocol,thePowerTransmitterandPowerReceivershalluse
theBaselineProtocolwiththefollowingextensions:
l
ThePowerTransmittershallsendanMPPResponsePatterninthePowerControlHold-offtimeintervalafter
eachCEdatapacket.
l
ThePowerReceivermaysendaNEGOdatapacketafterreceivinganMPPResponsePatterntotransitiontothe
FullModeoftheMagneticProtocol.
SeeSection5.7.2,Transitionwithoutpowerinterruption,fordetailsaboutthetimingsinvolvedwiththeseextensions.
NOTE:(Informative)MPPRestrictedmodecanbeusedwhenPRxisoperatingunderaconstrainedenvironmente.g.,deviceisfully
discharged
PRxisallowedtotransitionfromMPPRestrictedtoMPPFullModetoenablebi-directionalcommunicationandhigher
powerlevels.RefertoSection5.7,MPP-RestrictedtoFullModeTransition formoredetailsonhowtoperformthe
transition.
3.1.2 15WFullMode
MPPFullModeenablesachargingsessionwithbi-directionalcommunicationbetweenPTxandPRxallowingdevicesto
performmorecomplexoperationssuchasexchangeofidentificationinformation,devicescapabilities,ecosystem
scalabilitycoefficients,powernegotiationandperformauthentication.
InMPPFullMode,devicesmaytransitionbetweendifferentprotocolphasessuchasNegotiation,PowerTransfer,Cloak
andareabletonegotiatehigherpowerlevelscomparedtoRestrictedmode.
MPPFullModeisbasedonQiExtendedPowerProfile(EPP)protocol.PTxandPRxshallfollowtheQiEPPspecifications
whenoperatinginthismode.ChangestotheEPPspecificationsareexplicitlystatedinthisdocument.
Changestospecificationsinclude:

1. AddedMPPPowerTransferContractElementsandremovedsupportforEPPRP(ReceivedPower)contract
elements
2. AddedMPPdatapacketsandremovedsupportforEPPFODdatapackets
3. Overridingtimeparameters
3.2 PowerReceiverRequirements
MPPASKspecificationisbasedonQiEPP,allthetimingrequirements/specificationsspecifiedbyExtendedPower
ProfileapplytoMPP.
AllstandardQipacketsusedinMPPfollowtheQispecifications.Changestothehandlingorthedefinitionofthepackets
areexplicitlystatedinthisdocument.
3.2.1 AmplitudeShiftKeying(ASK)
MPPfollowstheQiASKspecifications.
3.2.2 StartupBehaviour
AnMPP-compatiblePowerReceivershallstartbysendingthefollowingsequenceofpacketsduringthe
ping/configurationphase.
1. SignalStrength(SIG)
2. Identification(ID)
3. ExtendedIdentification(XID)
4. PowerControlHold-Off(PCH)-Optional
5. ConfigurationPacket(CFG)
ThepacketsshallcontaintheMPPidentifiersasdescribedinthissectiontoallowanMPP-compatiblePower
TransmittertoidentifythePowerReceiver.
Figure2-MPPID/CFGPhasePackets
SignalStrength(SIG)
PowerReceivershallreporttheSignalStrength(SIG)datapacketfollowingtheQispecifications.
Identification(ID)
PowerReceivershallreporttheIdentificationPacket(ID)withtheEXTbitsettoONE.
ExtendedIdentification(XID)
PowerReceivershallreporttheMPP-ExtendedIdentificationPacket(XID)toadvertiseMPPsupport.Detailedpacket
definitionisdescribedinSection8.12,MPP-XID-QiMPPExtendedIdentification(0x81).
b b b b b b b b
7 6 5 4 3 2 1 0
B 0xFE
B Restricted MfgRsvd
B MfgRsvd
B
VRECT
B
B
B
B MfgRsvd
Figure3-MPPXIDPacketParameters
PowerreceivermaychoosetoadvertiseMPP-compatibilityandoperateunderMPPrestrictedmodebysettingthe
RestrictedbitasdescribedinSection8.12,MPP-XID-QiMPPExtendedIdentification(0x81).Otherwise,thePower
ReceivermayrequesttooperateunderMPPFullModebysettingtheRestrictedbittozero.
ThePowerReceivermaychoosetonotadvertiseMPPcapabilitiesbyperformingoneofthefollowing:
1. Settingthe(XIDSubHeader)fieldtoanyvalueotherthan0xFE
2. SkippingXIDpacket,andsettingExtbitto0inIDpacket
PowerControlHold-Off(PCH)-Optional
PowerreceivermaychoosetooperateinRestrictedmodeandlaterswitchtoMPPFullMode.Thistransitionrequires
thePowerReceivertoreportPCHpacketduringtheconfigurationphase.
RefertoSection5.7,MPP-RestrictedtoFullModeTransition formoredetailsonvalueselection.
Configuration(CFG)
PowerReceivershallreporttheConfiguration(CFG)packetaccordingtotheQispecifications.

3.2.3 ProfileActivation
DependingontheselectedoperatingmodeinXIDpacket(Section3.2.2,StartupBehaviour),PowerReceivershall
proceedasfollows:
1. MPP-Restricted:PRxshallproceedtoRestrictedPowerTransferPhaseat360kHz(FollowsQiBaseline
Protocol)
2. MPP-Full:PRxshallenabletheFSKdecoder,dependingonthedecodingresult:
1. FSKMPPPattern:PRxshallproceedtoMPPNegotiationPhase(Section4,NegotiationPhase)
2. FSKNAKPattern:PRxshallproceedtoMPPNegotiationPhasewithMPPerrorstatusSection4,
NegotiationPhase)
3. Timeout/Else:PRxshallproceedaccordingtotheQispecifications(BPP/EPP)
1. FSKpatternresponsetoConfiguration(CFG)packetsisalwaystransmittedusingthedefault512switching
cycles.
2. RefertotheMPPCommunicationsPhysicalLayerbook formoreinformationonFSKparameters.

Figure4summarizestheflow.
Figure4- MPPPowerReceiverConfigurationPhaseDecisionTree

3.3 PowerTransmitterRequirements
MPPFSKspecificationisbasedonQiEPP,allthetimingrequirements/specificationsspecifiedbyExtendedPower
ProfileapplytoMPP.Updatedparametersareexplicitlystatedinthisdocument.
3.3.1 FrequencyShiftKeying(FSK)
MagneticPowerProfilev1.xdefinesfixedFSKparametersasshowninTable4MPPusespredefinedFSKparametersas
specifiedintheMPP CommunicationsPhysicalLayer book.
Table4-MPPFSKParameters
Parameter Value Notes
SwitchingCycles 512/128 FSK512switchingcyclesisonlyused
whenPTxrespondstoCFGpacket
(Section3.2.3,ProfileActivation)
Otherwise,PTxshalluse128
switchingcycles
Preamble 4-bits(1111) AppliestoFSKPacketsonly(Patterns
areexcluded)
PacketFormat
MPPFSKPacketstructureisshowninFigure5
Figure5-MPPFSKPacketStructure
FSKPattern
MPPextendsQiEPPFSKpatternresponseswithMPPPattern(Table5,Figure6).

Table5-MPPFSKPatterns
Response Patternb0.b7 Notes
ACK 11111111
NAK 00000000
ND 10101010
ATN 11001100
MPP 10001000 MPPPattern
APP 11110000 Reservedproprietarypattern(Note)
SGC 00110011 UsedtoinformthePRxofachangeinSystemGain
NOTE:NoteonAPPpattern:TheproprietaryprecursorimplementationtoMPPusesthispattern.Topreventinteroperability
problems,useofthispatternisreserved.
Figure6-MPPFSKPatternFormat
3.3.2 TimingsOverride
FSKResponseWindow
DuetotheadditionofpreambletotheFSKpackets,thestartoftheFSKpacketnowpointstothestartofpreambleof
theFSKpacketasshowninFigure7.
Figure7-MPPFSKResponseTiming
NoPowerSignalWindow
Timedurationbetweentwoconsecutivepings(t )hasbeenupdated.RefertoTable6.
nopower
Table6-MPPPTxParametersOverride
Parameter Symbol Minimum Target Maximum Unit
NoPowerSignalwindow t 50 N/A N/A ms
nopower
3.3.3 StartupBehaviour
AfterdetectingPRxplacementonthechargingsurface,MPPPTxshallperformdigitalpingandidentifythePower
ReceiverusingtheinformationembeddedinIDandXIDpacketsasdescribedinSection3.2.2,StartupBehaviour.
FromthePowerTransmitter's’sperspective,aPRxsupportsMPPifbothofthefollowingconditionsaresatisfied:
1. QiVersion:QiprotocolversioninIDpacket(Section3.2.2,StartupBehaviour)issetto(Major=2,Minor=0)or
higher.
2. MPPSupportAdvertised:Sub-header(byte0)inXIDpacketissettoMPPselector(Section8.12,MPP-XID-Qi
MPPExtendedIdentification(0x81))
Iftheconditionsarenotsatisfied,thePowerTransmittershallproceedtothenextphaseaccordingtotheQi
specifications.
Dependingonthedigitalpinglevelusedtoestablishthecommunicationat128kHzfrequency,PTxshallsetaninternal
errorstatusasfollowing:
l
Error=None:Communicationat128kHzwasestablishedusing’Qi_HB_Low’digitalpinglevel
l
Error=digitalpinglevelmismatch:Otherwise
PTxshallthenproceedtotherequestedMPPoperationmodereportedinMPP-XIDpacketasfollowing:
l
ActivateRestrictedMode:IfRestrictedflagissettoone.
l
ActivateFullmode:IfRestrictedflagissettozero.
PTxshallcleartheerrorstatusifitdecidestoremovethepowersignalforanyreasoni.e.,errorstatusshallnotpersist
acrosscommunicationrestarts.
MPPRestrictedMode
PRxmaychoosetooperateunderMPP-RestrictedPowerModebysettingtheRestrictedfieldinMPP-XIDpacketto1.
PTxshalldecodetheMPP-XIDpacketandproceedasfollowing:
l
Ifactivefrequencyis360kHz:ProceedassumingMPPRestrictedmode
l
Else:Proceeddependingontheerrorstatus
Iftheerrorstatusisnotset,PTxshallremovePowerSignalandstartdigitalpingusing360kHzasoperatingfrequency
aftert_nopower.Otherwise,PTxshallremovethepowersignalandperformdigitalpingagainusing128kHzand’Qi_HB_
Low’digitalpinglevel.
Figure8describesthefrequencychangebehaviourunderRestrictedmode.

Figure8-MPPRestrictedFrequencyChangeSequence
MPPFullMode
PTxshallcontinueprocessingallpacketsinconfigurationphaseandrespondtotheConfiguration(CFG)packetas
following:
l
FSKMPPPattern:errorstatusisnotset
l
FSKNAKPattern:errorstatusisset
PTxshallgeneratetheFSKresponseusing512switchingcycles.AfterrespondingwithFSK,PTxshallproceedtoMPP
negotiationphaseasdescribedabove.
FSKpatternsaredescribedinTable5.
Figuresbelowsummarizethe128kHzand360kHzdigitalpingsbehaviourforbothRestrictedandFullmodes.
Where"DigitalPing"isstatedintheflowchart,forfurtherinformation,refertotheDigitalPingFlowdiagraminthe
DigitalPings128kHz/360kHzsectionintheMPPPowerDeliverybook.

Figure9-MPPPowerTransmitterConfigurationPhaseDecisionTreeFlow-128kHzping
NOTE:Whenrestrictedmodeisrequestedand"CommunicationestablishedusingQi_HB_Lowdigitalping?"is"no",thePRxislikely
tobepositionedoutsideofthe2x2cylinderandthebehaviourisimplementationdependent.

Figure10-MPPPowerTransmitterConfigurationPhaseDecisionTreeFlow-360kHzping
3.4 SupportingEPPandMPPprotocols
Devicesmaychoosetosupportmultiplepowerprofiles/protocolse.g.,PRx/PTxmaysupportEPPinadditiontoMPP.
ThissectiondiscusseshowthesedevicesbehavewhenattachedtoanotherdevicethatsupportsEPP,MPPorboth.
3.4.1 MPP/EPPSupportonPRx
PRxmaychoosetoadvertiseMPPandEPPsupportbyperformingthefollowing:
l
MPPSupport:DescribedinSection3.2.2,StartupBehaviour
l
EPPSupport:FollowtheQicommunicationsprotocolspecifications
PRxwillsendtheMPP-XIDpackettothePowerTransmitter,andalsoproperlysettheconfigurationpackettoadvertise
EPPsupport(e.g.FSKparameters,NEGbitsetto1,etc.).
AftersendingtheCFGdatapacket,PRxwillhavetoattempttodecodeFSK,PRxwillproceeddependingonthedecoding
result:
l
MPPSupportedPatternsreceived(MPP,NAK):PTxsupportsMPP,PRxshallproceedusingMPPprotocol
l
ACKPatternreceived:PTxsupportsEPP,PRxshallproceedusingEPPprotocol
l
Timeout:PRxshallproceedusingBPPprotocol
3.4.2 MPP/EPPSupportonPTx
DependingonthedataprovidedbyPRxduringconfigurationphase,thePTxwillbeabletodeterminewhichpower
profileissupportedbythePRx.
l
MPPSupportadvertised:PRxadvertisesMPPsupportasdescribedinSection3.2.2,StartupBehaviour
l
EPPSupportadvertised:PRxadvertisesEPPsupportasdescribedinQicommunicationsprotocolbook(e.g.,NEG
bitissetinCFGpacket)
PTxmaydetectaPRxthatsupportsoneormoreprofiles,PTxshallproceedasfollowing:
l
PRxsupportsMPPandEPP:PTxshallalwaysprioritizeMPPprotocolbyrespondingwithasupportedFSK
pattern(MPP,NAK)toCFGpacketasdescribedinSection3.3.3,StartupBehaviour
l
PRxsupportsEPP:PTxshallproceedwithEPPprotocolbyrespondingwithACKpatterntoCFGpacketas
describedinQicommunicationsbook
PTxusesfixedFSKparameterswhenengagedinMPPsession.IfPTxdecidestoengageinEPPsession,PTxshallusethe
FSKparametersasdescribedinCFGdatapacket

4. NegotiationPhase
4.1 Overview
MPPNegotiationphaseisbasedonQiEPPspecificationsi.e.,EPPtimingspecifications,packets,andrulesapplytoMPP
negotiationphase.Anychangestothespecificationsareexplicitlystated.
NOTE:NoteonEPPcompatibility:MPPdoesnotsupportFODpacketorFODcalibrationphase.
4.2 Requirements
AfterConfigurationphase,PRxandPTxshallproceedtonegotiationphaseifthePRxrequestedtoenableMPPfull
operatingmode.
Inthisphase,PRxshallonlyusepacketsthatareallowedtobeusedinnegotiationphasebyQiEPPspecificationsand
MPPspecifications(Table7).
IfPTxdetectsapowertransferphasepackete.g.CEpacketbeforecompletingtheMPPnegotiation,itshallremovethe
powersignal,andproceedtoPingPhase.ReceivingaCEpacketafterenteringMPPnegotiationphaseindicatesthatPRx
wasunabletodecodeMPPFSKpatterncorrectly.RemovingthepowersignalallowsthePTxtoretryactivatingMPP.
Table7-PRxpacketsallowedduringMPPnegotiationphase
Mnemonic Name Section
SRQ SpecificRequests QiSpecification,Communications
Protocol
GRQ/id GeneralRequest QiSpecification,Communications
Protocol
GET GetRequest Section8.9,GET-GetRequest(0x28)
EDS EnabledDataStreams Section8.7,EDS-EnabledDataStreams
(0x29)
REPORT Report Section8.19,REPORT-Report[PRx
Identification](0x58:0)
PLAP PowerLossAccountingParameters Section8.16,PLAP-PowerLoss
AccountingParameters(0x78)
PLAP_2 PowerLossAccountingParameters2 Section8.17,PLAP_2-PowerLoss
AccountingParameters2(0x90)
ECAP ExtendedReceivedCapabilities Section8.6,ECAP-ExtendedPower
ReceiverCapabilities(0x84)
PROPn MPPPRxProprietaryPackets Section8.18,PROP-Proprietary
(multipleheaders;multipletypes)
MSR ModeSelection Request Section8.13,MSR-ModeSelectRequest
(0x13)
MATEDQ_COEFF Mated-QCoefficients Section8.11,MATEDQ_COEFF-Mated-Q
Coefficients(0xA8)
Mnemonic Name Section
KEST_COEFF KESTCoefficients Section8.10,KEST_COEFF-KEST
Coefficients(0x50)
PRxnegotiationbehaviourmaydifferbasedontheactiveoperatingfrequencye.g.,PRxmayperformPTxidentification
andFrequencySelectionat128kHznegotiationphase,andperformpowernegotiationafterswitchingto360kHzbase
frequency(inMPPnegotiationphase).

4.2.1 NegotiationPhaseTimings
MPPnegotiationphasetimingsfollowtheEPPtimingsasdescribedinQicommunicationsprotocolbookwiththe
additionofthefollowingtimingsparameters:
Table8-MPPNegotiationPhaseTimingParameters
Parameter Side Symbol Minimum Target Maximum Unit
Re-negotiation PTx t 700 800 900 ms
renegotiate
Timeout
t onlyappliestorenegotiationphase.TimingdiagramisshowninFigure11
renegotiate
Figure11-NegotiationPhaseTimingParameters-t
renegotiate
4.2.2 FSKCycles
PRxandPTxshallupdateFSKswitchingcyclesto128cycles,immediatelyuponenteringMPPnegotiationphase.
PRxandPTxshallsetFSKcyclesto512afterenteringpingphase(e.g.,afterdisconnect).
4.2.3 EnteringNegotiationPhaseWithErrorStatus
Insomescenarios,PTxmaydecidenottoproceedwithMPP-Fullmode.Reasoncouldbeduetothepingconfiguration
usedtoestimate-k(e.g.,digitalpinglevelisnot’Qi_HB_Low’).PTxshallletthePRxknowbyrespondingwithFSKNAK
patterntoCFGdatapacketasdescribedinSection3.2.3,ProfileActivation.AfterreceivingNAKpattern,PRxshallenter
negotiationphasewitherrorstatus.
Innegotiationphase,PRxmayoptionallyretrieveanyinformationsuchastheerrorstatusdatapacketfromPTxusing
GET[ErrorStatus].PTxshallrespondwithERRdatapacketSection9.11,ERR-ErrorStatus(0x01).
Whenready,PRxshallrequestcommunicationrestartusingEPT/rstinsteadofsendingSRQ/entoavoidenteringPower
TransferPhase.
PTxshallnotallowPRxtoenterpowertransferphaseandshallrespondtoSRQ/enwithNAK.

Figure12-Negotiationwitherrorstatus
4.2.4 PowerTransferContractExtension
MPPusesQiEPPpowertransfercontractelementsasabaselineandadds/removeselementsasdescribedinthis
section.
Notsupportedelements:
1. ReceivedPowerwindowsize:Thiselementisnon-negotiableinthisversionofthespecification.Refertothe
CommunicationsProtocolbook formoreinformation.
2. ReceivedPowerwindowoffset:Thiselementisnon-negotiableinthisversionofthespecification.Refertothe
CommunicationsProtocolbook formoreinformation.
3. ReferencePower:Thiselementisnon-negotiableandnotusedinthisversionofthespecification.
4. ReceivedPowerResolution:Thiselementisnon-negotiableinthisversionofthespecificationanditis
automaticallysettoPLAheader(0x58).RefertotheCommunicationsProtocolbook formoreinformation.
5. FSKPolarityandModulationdepth:Thiselementisnon-negotiableinthisversionofthespecification.
6. GuaranteedPower:ReplacedbyExtendedGuaranteedPowerelement,PRx/PTxshallnotusethisversionofthe
element.
7. FSKSwitchingCycles:SpecifiesthenumberofswitchingcyclesperFSKbit.Thiselementisnon-negotiableinthis
versionofthespecification.
Supportedelements:
1. PowerControlHold-off:RefertotheCommunicationsProtocolbook formoreinformation.
2. Re-pingdelay:RefertotheCommunicationsProtocolbook formoreinformation.
3. PotentialLoadPower:RefertotheCommunicationsProtocolbook formoreinformation.
4. ExtendedGuaranteedPower:AllowsPRxtonegotiatetheguaranteedpowervaluein100mWresolution.This
elementreplacestheQiGuaranteedPowertransfercontractelement.
5. FrequencySelection:AllowsPRxtonegotiateadifferentoperatingfrequency(e.g.,negotiate360kHzwhen
operatingat128kHz)
6. CloakPingDelay:PRxcanrequestatemporaryinterruptionofpower(cloak).ThiselementallowsPRxto
negotiatethedelaybetweencloakpings.
7. CloakDetectPingDelay:AllowsPRxtonegotiatethetimedelaybetweensubsequentshortcloakdetectpings.
8. PowerControlProfile:AllowsPRxtoselectaspecificpowercontrolprofiledependingoncouplingandother
parameters.
9. PLAFormatSelection:AllowsthePRxtoselectthepowerlossaccountingprofileID.
10. ControlErrorCalculationMethod:AllowsthePRxtoselectwhichcontrolerrorcalculationmethodtouse.
11. ControlGain:AllowsthePRxtocontrolgainwhenthegainlinearizationfeatureisactive.
12. VersionSelect:AllowsthePRxtochangetheversionoftheprotocolitimplements.
13. ActivePowerMode:RefertoSection5.8,PowerModes
DefaultvaluesforthenewelementsaddedbyMPParedescribedinTable9.
RefertotheCommunicationsProtocolbook formoreinformationonthedefaultvaluesofQipowercontractelements
Table9-MPPPowerTransferContractElements
Element Symbol Unit Negotiable DefaultValue Details
Frequency N/A Hz Yes Activefrequency Section8.23.5,SRQ/freqsel-
Selection SpecificRequest[Frequency
Selection](0x20/0xF0)
Extended N/A W Yes 5W Section8.23.4,SRQ/egpl-Spe-
Negotiated cificRequest[PowerLevel]
Power (0x20/0xF3)
CloakPing t ms Yes 500ms Section8.23.2,SRQ/cloakl-
cloak
Delay SpecificRequest[CloakPing
Delay-LowByte]
(0x20/0xF5),Section8.23.1,
SRQ/cloakh-SpecificRequest
[CloakPingDelay-HighByte]
(0x20/0xF7)
CloakDetect t ms Yes 0ms(disabled) Section8.23.3,SRQ/detect-
cloakdetect
PingDelay SpecificRequest[CloakDetect
PingDelay](0x20/0xF8)
PowerCon- N/A N/A Yes 0 Section8.23.7,SRQ/pcp-Spe-
trolProfile cificRequest[PowerControl
Profile](0x20/0xF6)
PowerLoss N/A N/A Yes 0 Section8.23.8,SRQ/pla-Spe-
Accounting cificRequest[PLAFormat
Format Selection](0x20/0xA0)
Selection
N/A N/A Yes 10 Section8.23.10,SRQ/xceGain-
SpecificRequest[Control
Gain](0x20/0xA9)
Element Symbol Unit Negotiable DefaultValue Details
N/A N/A Yes 4 Section8.23.10,SRQ/xceGain-
SpecificRequest[Control
Gain](0x20/0xA9)
DPLOSSCal- ⍺andβ N/A No N/A
ibrationcoef-
ficients
Control N/A N/A Yes N/A Section8.23.11,SRQ/x-
Error ceMethod-SpecificRequest
Calculation [ControlErrorCalculation
Method Method](0x20/0xA1)
Version N/A N/A Yes Major.MinorVersionfromthe Section8.23.9,SRQ/verSel-
IDpacket
SpecificRequest[Version
Select](0x20/0xA7)
ActivePower N/A N/A Yes Implementationdependent Section5.8,PowerModes
Mode
l
Extended N/A N/A No Version2.3orhigher Section8.24,XCE-Extended
XCE powertransfercontract: ControlError(0x19)
Reporting enabled
l
Version2.2orlower
powertransfercontract:
disabled
NOTE: and countastwoparameters,whichmeansthatasingleSRQ/xceGaindatapacketcanresultacountupdateof
0,1,or2.
4.3 KEST EcosystemScalingandErrorHandling
4.3.1 Introduction
Insomescenarios,thePowerTransmitterscannotcompute .
Forexample:
1. DigitalPingLevel:ThePTxcannotaccuratelyestimatethecouplingfactorbecausethepinglevelisoutof
range.
2. Timings:ThePTxcannotmeetthetimingsforthemeasurementsinvolved.
3. Confidence:ThePTxhaslowconfidenceintheestimatedcouplingfactor.
Dependingonthescenario,thePTxcancorrecttheoperatingconditionsbyitself,orwithassistancefromthePRx,as
explainedinthefollowingsections.
4.3.2 ErrorHandling
TheflowchartdetailedinFigure13showsanexampleoftheerrorhandlingprocess.
Figure13-Errorhandlingflow
Table10-RecommendedPTx/PRxactions
k-estimationerrorreason PRxactions(A) PTxActions(B)
Measurementerror(e.g.timingerror, None Retrydigitalping
valueout-of-range)
Digitalpingleveluseddoesnotallow None Retrydigitalpingusingadifferent
KEST(e.g.HB-H) digitalpinglevelthatallowsKEST
measurement(example:HB-L)
Digitalpinglevelusedrequireseco- Provideecosystemscalingcoefficients Retrydigitalpingusingadifferent
systemscalingcoefficients(e.g.high digitalpinglevelthatdoesnot
voltagedigitalping) requireecosystemscaling
coefficients.
MayrequirePowerModechange.
4.3.3 Examples
Figure14-RestrictedMode
Figure15-FullMode(Scenario1)
Figure16-FullMode(Scenario2)
4.4 NegotiationPhase-128kHz
4.4.1 Nominalnegotiationflow
PRxshallusethe128kHznegotiationphasetoselectthe360kHzoperatingfrequencyusingSRQ/freqselasdescribed
inSection4.4.3,FrequencySelection).
NOTE:IfthePTxdoesnotreceiveSRQ/freqsel,e.g.duetoacommunicationserror,itrespondsNAKtoSRQ/enduetoacount
mismatch.Ifthisscenariopersistsafter3ormoreattemptsthenthePTxshutsdownandinitiatesa128kHzdigitalping.
Inadditiontofrequencyselection,PRxmayperformthefollowingactionsbeforeexitingthenegotiationphase.
1. RequestPTxID:RetrieveQiprotocolversionandmanufacturercodeusingGRQdatapacket(RefertoQi
CommunicationsProtocolformoreinformation)
2. RequestExtendedPTxID:RetrieveMPPPTxExtendedIDusingGET[PTxXID]Request( Section8.9,GET-Get
Request(0x28))
3. Adjustre-pingduration:Adjustthetimedelaybeforethenext360kHzpingwhenPRxsendsEPT/rep.
Itisrecommendedtoperformpowerrelatednegotiationatthepreferredoperatingfrequencyi.e.at360kHzinsteadof
128kHz,toavoidlosingthenegotiatedcontractelementsduetopowersignalremovalcausedbyoperatingfrequency
changes.
Aftercompletingthetransactions,PRxshallterminatethenegotiationusingSRQ/enandthensendEPT/reptostartthe
frequencychangeflowasshowninFigure17.

Figure17-MPPPowerNegotiationFlowat128kHzwithouterror

4.4.2 NegotiationflowwithPTxerrorstatus
RefertoSection4.2.3,EnteringNegotiationPhaseWithErrorStatus formoreinformation.
Figure18-MPPPowerNegotiationFlowat128kHzwitherrorstatus

Figure19-MPPPowerNegotiationFlowat128kHzwitherrorstatus-MisbehavingPRx
4.4.3 FrequencySelection
PRxshallselectanewoperatingfrequency(360kHz)usingSRQ/freqsel( Section8.23.5,SRQ/freqsel-SpecificRequest
[FrequencySelection](0x20/0xF0)).
AfterselectingthenewfrequencyandterminatingthenegotiationusingSRQ/en,PRxshallrequestare-pingusing
EPT/reptoallowPTxtoactivatethenewselectedfrequency.
1. EPT/repwillcausethePTxtoremovethepowersignal,changetheoperatingfrequencytotheselectedvalueand
resetthepowercontractelements.
2. EPT/rstwillcausethePTxtoremovethepowersignal,changetheoperatingfrequencyto128kHzandresetthe
powercontractelements.
PTxshallfollowEPT/repandEPT/rsttimingsasspecifiedinQiCommunicationsProtocolbook.

4.5 NegotiationPhase-360kHz
PRxshallusethe360kHznegotiationphasetonegotiatetherequiredpowercontractelementsbeforeenteringpower
transferphase.
PRxshallperformthefollowingactionsin360kHznegotiationphase:
1. GRQ/id:PRxshallrequestthePTxID(seeCommunicationsProtocolbook).
2. SendECAP:PRxshallsenditsextendedcapabilitiesdatapackettoPTx(Section4.5.1,PRxExtendedCapabilities).
3. RequestECAP:PRxshallrequestPTxextendedcapabilitiesusingGET[ECAP]Request(Section8.9,GET-Get
Request(0x28)).
4. RequestPLAP:PRxshallrequestPTxpowerlossaccountingparametersusingGET[PLAP]Request(Section8.9,
GET-GetRequest(0x28))–PLAPexchangeisdescribedinSection4.5.3,ExchangePowerLossAccounting
Parameters.
5. SendPLAP:PRxshallsenditspowerlossaccountingparameterstoPTxusingPLAPdatapacket(Section8.16,
PLAP-PowerLossAccountingParameters(0x78)).
6. RequestPLAP2:PRxshallonlysendthisdatapacketifthePTxindicatessupportforit
7. SendPLAP2:PRxshallsenditspowerlossaccountingparameterstoPTxusingPLAP_2 datapacket(Section8.17,
PLAP_2-PowerLossAccountingParameters2(0x90)).
8. RequestMODECAP:PRxshallrequestthePTxpowermodecapabilitiesbyusingtheGET[MODECAP]request
(Section9.17,MODECAP-PowerModesCapabilities(0x5A)).
9. SendMSR:PRxshallrequesttoactivateaspecificpowermode(Section8.13,MSR-ModeSelectRequest(0x13)).
NOTE:IfthePTxfailstoreceiveanyoftheabovepackets,thePTxshouldreplyNAKtoSRQ/en,andremaininthenegotiationphase.
ThePRxmayalsoperformthefollowingactionsbeforeexitingthenegotiationphase:
1. RequestExtendedPTxID:RetrieveMPPPTxExtendedIDusingGET[PTxXID]Request(Section8.9,GET-Get
Request(0x28)).
2. PowerLevelNegotiation:RefertoSection4.5.4,PowerNegotiation.
3. ExchangeSupportedDataStreams:RefertoSection4.5.6,ExchangeEnabledDataStreams
4. SendSRQ/pch:Adjustthepowercontrolhold-offtime, (refertotheCommunicationsProtocolbook).
5. Negotiateotherelementsdescribedinthischapter
Aftercompletingthetransactions,PRxshallterminatethenegotiationusingSRQ/enandtransitiontoPowerTransfer
PhaseasshowninFigure20.
Figure20-MPPPowerNegotiationFlowat360kHz

4.5.1 PRxExtendedCapabilities
PRxshallreportitscapabilitiestoPTxusingthePRxExtendedCapabilitiespacket(Section8.6,ECAP-ExtendedPower
ReceiverCapabilities(0x84)).
4.5.2 PTxExtendedCapabilities
PRxshallrequestthePTxExtendedCapabilitiespacketusingGET[ECAP]Request(Section8.9,GET-GetRequest(0x28)
).PTxshallrespondwithPTxFSKECAPdatapacketSection9.8,ECAP-ExtendedPowerTransmitterExtended
Capabilities(0x8F:1)).
4.5.3 ExchangePowerLossAccountingParameters
PRxshallrequesttheparametersfromthePTxusingaGET[PLAP]Request(Section8.9,GET-GetRequest(0x28)).PTx
responseisdescribedinSection9.21,PLAP-PowerLossAccountingParameters(0x5F).
AfterreceivingtheparametersfromthePTx,PRxshallcomputetheadjustedcoefficientsandreportthevaluestothe
PowerTransmitterusingPowerLossAccountingParameters(Section8.16,PLAP-PowerLossAccountingParameters
(0x78)).
4.5.4 PowerNegotiation
MPPPowernegotiationisperformedbythePowerReceiverasfollowing:
1. RequestPTxExtendedCapabilitiesusingaGET[ECAP]Request(Section8.9,GET-GetRequest(0x28)).PTx
responseisdescribedinSection9.8,ECAP-ExtendedPowerTransmitterExtendedCapabilities(0x8F:1).
2. UsingSRQ/egpl,selectapowerlevel≤NegotiableLoadPowervaluereportedinPTxExtendedCapabilities
packet.
1. MPPusesQiEPPtermsfordescribingthepotentialandnegotiableloadpower.
2. Powernegotiationisnotrequiredifse
...