oSIST prEN IEC 63758-9:2026

• Status: Not Published
• Public Enquiry End Date: 29-Nov-2026
• ICS: 29.240.99 - Other equipment related to power transmission and distribution networks
• ICS: 33.160.99 - Other audio, video and audiovisual equipment
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: AVM - Audio, video and multimedia systems and equipment
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 28-Sep-2026
• Due Date: 15-Feb-2027
• 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: prEN IEC 63758-9:2026 - Qi Specification - Version 2.3 - Part 9: Communications protocol (Fast Track)

oSIST prEN IEC 63758-9:2026 is the CLC/IEC draft for Qi Specification - Version 2.3, Part 9, covering the communications protocol between a Power Transmitter and a Power Receiver. It specifies the message exchange, packet types, timing, and phase sequence used to set up and control wireless power transfer, and in the ExtendedProtocol to renegotiate contract items and carry higher-level data such as Authentication. Engineers, test labs, quality teams, and product designers use it when implementing or verifying Qi wireless power products.

What does oSIST prEN IEC 63758-9:2026 specify?

oSIST prEN IEC 63758-9:2026 specifies how a Power Transmitter and a Power Receiver communicate over the Qi Power Signal. The document covers the payloads of data packets, the order in which messages appear, and the timing relations that make the protocol work in practice.

The structure is:

• Clause 1 - general rules, compliance language, notation, and references
• Clause 2 - protocol overview, protocol phases, PowerTransferContract, packet types, higher-level messages, power-profile integrity, and backward compatibility
• Clause 3 - PowerReceiver and PowerTransmitter identification
• Clause 4 - ping phase
• Clause 5 - configuration phase
• Clause 6 - negotiation phase
• Clause 7 - power transfer phase
• Clause 8 - PowerReceiver data packets
• Clause 9 - PowerTransmitter data packets

The document is built around two protocol variants. The BaselineProtocol is the original Qi communication mode, while the ExtendedProtocol adds negotiation, calibration at the start of power transfer, and datatransport streams.

What are the key requirements of oSIST prEN IEC 63758-9:2026?

oSIST prEN IEC 63758-9:2026 is a state-based protocol specification. The practical requirement is that both devices must follow the right phase, send the right packet type, and respect the timing windows for that phase.

How does the protocol flow work?

Clause 2 defines the overall flow, and Clauses 4 to 7 define the detailed phase logic. The PowerTransmitter starts the sequence with a DigitalPing, then the PowerReceiver takes over message exchange through configuration, negotiation, and power transfer. In practice, this means firmware must implement the same state machine on both sides or the link will not stay synchronized.

The document also states that the PowerReceiver drives all data packet communications after the ping phase. The PowerTransmitter waits for an invited packet or response pattern, and it should not answer a corrupted packet. In practice, a bad packet is treated as a communication failure, not as a packet to guess at.

How is the PowerTransferContract handled?

Clause 2.2 and Clause 6 define the PowerTransferContract, which is the shared set of settings and limits for the transfer. The baseline contract includes ReferencePower, ReceivedPower window settings, PowerControlHold-off, and ReceivedPower reporting resolution. The extended contract adds FSK communication settings, PotentialLoadPower, GuaranteedLoadPower, and Re-ping delay.

This matters because both devices must keep matching copies of the contract. When a setting changes, both sides track the change and only switch to the new copy after the change is confirmed. In practice, that prevents one side from sending packets with stale parameters while the other has already moved on.

Clause 6.1 also defines which items can be negotiated, including ReferencePower, FSK polarity and modulation depth, number of cycles per FSK bit, GuaranteedLoadPower, Re-ping delay, PowerControlHold-off, and ReceivedPower reporting resolution. The reader should treat these as the main tuning points for interoperability and performance.

What does the identification logic do?

Clause 3 and Clauses 8.11 and 8.19 define how devices identify themselves. The PowerReceiver sends version information, PRMC, a BasicDeviceIdentifier, optional XID data, and optionally WPID. In the ExtendedProtocol, it can also request the PowerTransmitter’s PTMC and certificate data.

This identification data is not just naming information. It helps a transmitter distinguish one receiver from another in the operating volume, and it supports proprietary packet handling and authentication workflows. The document also says PRMC and PTMC are not to be used to limit the design freedom of the opposite side.

Which packet types matter most?

Clause 2.3 groups PowerReceiver packets into statusupdate, powercontrol, simplequery, and datarequest. Clause 8 then defines the individual packet types. The most important ones for implementation are SIG, CFG, PCH, CE, EPT, RP8, RP, FOD, GRQ, NEGO, ADC, ADT, CHS, XID, and WPID.

This grouping matters because each packet type has a different expected reply behavior. Some do not get a reply, some request a power change, some invite a ResponsePattern, and some request a full packet back. In practice, the packet category is as important as the payload itself.

How do timing and safety features work?

Clauses 4.2, 5.2, 6.7, and 7.3 define the timing windows for wake-up, reset, response, timeout, and retry behavior. The document uses these windows to keep both ends aligned during ping, configuration, negotiation, and power transfer. In practice, implementers need to schedule packet handling carefully or the other side will time out and fall back to fault handling.

The document also ties the communications protocol to foreign object detection and NFC tag protection. Clause 6.3, Clause 6.5, and the FOD and XCAP packet definitions give the receiver and transmitter a way to exchange design information and tag-protection status before and during power transfer. That matters because the protocol is not only about moving power - it also carries the information needed to decide whether power transfer should continue safely.

How do datatransport streams fit in?

Clause 2.4 and Section 7.2 define datatransport streams for higher-level application data. Clause 8.1 and 9.1 use ADC to open, close, or reset a stream, and Clauses 8.2 and 9.2 use ADT to carry the application payload. Authentication and proprietary applications are the main uses named in the document.

In practice, this is the part of the protocol that goes beyond power control. It lets the Power Transmitter and Power Receiver exchange structured data while still charging, so buffer sizing, stream direction, and response handling all matter.

How is backward compatibility handled?

Clause 2.6 and the packet definitions in Clauses 8 and 9 define version-sensitive behavior. The standard expects devices to look at the version number reported in identification packets and adjust their handling of packet types, response patterns, and packet interpretation accordingly.

That matters for interoperability. A device that only follows the latest behavior can still meet the standard, but it must recognize when the peer reports an older version and use the compatible behavior for that peer.

What terms does oSIST prEN IEC 63758-9:2026 define?

• PowerTransferContract - The shared set of settings and limits that both devices use to run the power transfer, including power level, timing, and reporting choices.
• BaselineProtocol - The original Qi communications mode, where the PowerReceiver talks to the PowerTransmitter without a negotiation phase.
• ExtendedProtocol - The Qi mode that adds negotiation, calibration at the start of power transfer, and datatransport streams.
• DigitalPing - The PowerTransmitter’s wake-up attempt that starts active communication after the receiver has been detected.
• EPT (EndPowerTransfer) - A power-control packet used by the PowerReceiver to stop, restart, or delay restart of power transfer for a stated reason.
• FOD (ForeignObjectDetection) - The information and methods used to judge whether foreign objects may be present before or during power transfer.
• WPID (WirelessPowerID) - An optional receiver identifier sent in two parts, with a CRC check on the combined identifier.
• PRMC / PTMC - The manufacturer codes for the PowerReceiver and PowerTransmitter, used for identification and selective handling of proprietary behavior.

Who uses oSIST prEN IEC 63758-9:2026?

oSIST prEN IEC 63758-9:2026 is used by teams that design, test, certify, or buy Qi wireless power products. It is especially relevant for flat-surface devices such as mobile phones and chargers, where Qi power transfer is a common use case.

Typical users include:

• Firmware and embedded engineers implementing the packet state machine
• Hardware engineers working on transmitter and receiver behavior
• Test and certification labs checking packet handling, timing, and interoperability
• Quality managers writing conformance checks or acceptance criteria
• Buyers and product managers specifying which Qi protocol features a product must support

Which standards are used with oSIST prEN IEC 63758-9:2026?

oSIST prEN IEC 63758-9:2026 relies on other Qi parts for lower-layer behavior and adjacent functions. It also cites ISO/IEC Directives, Part 2 for the wording rules used in the specification.

Standard / part	What it contributes
ISO/IEC Directives, Part 2	Rules for the meaning of shall, should, may, and can wording
Qi Specification, CommunicationsPhysicalLayer	Low-level formats for data bits, data bytes, and packets
Qi Specification, PowerDelivery	Power-transfer behavior, pre-power measurements, and restrictions around power transfer
Qi Specification, ForeignObjectDetection	Foreign object detection methods, calibration, and related design information
Qi Specification, NFCTagProtection	NFC tag protection methods and safe power guidance
Qi Specification, AuthenticationProtocol	Authentication messages and certificate-related behavior
Qi Specification, MPPCommunicationsProtocol	MPP-specific communications behavior referenced by some packet reasons
Qi Specification, MPP PowerDelivery	MPP power-transfer behavior referenced by packet reasons
Qi Specification, MPP CommunicationsPhysicalLayer	MPP-specific physical-layer behavior
Qi Specification, MPP ForeignObjectDetection	MPP-specific FOD behavior
Qi Specification, MPP DesignGuidelines	MPP design guidance
Magnetic Covers	Related Qi system topic listed in the document structure
Active Alignment System	Related Qi system topic listed in the document structure
Thermal Management Protocol	Related Qi system topic listed in the document structure

What does the oSIST prEN IEC 63758-9:2026 document contain?

oSIST prEN IEC 63758-9:2026 contains the phase diagrams, timing rules, packet definitions, and message-field descriptions needed to implement Qi communications. It includes detailed packet handling for the PowerReceiver and the PowerTransmitter, plus the rules for how each side responds in each phase.

The document also contains examples of PowerTransferContract values, load-power negotiation, and phase transitions. Those examples are used to show how the protocol behaves in baseline and extended operation, and how the device state changes when negotiation succeeds or fails.

It further contains datatransport stream procedures, including the control packets that open, close, or reset a stream and the data packets that carry the application payload. That part is used for Authentication and other higher-level data exchange, not just power control.

SLOVENSKI STANDARD
01-november-2026
Specifikacija Qi - Različica 2.3 - 9. del: Komunikacijski protokol (hitri postopek)
Qi Specification - Version 2.3 - Part 9: Communications protocol (Fast Track)
Ta slovenski standard je istoveten z: prEN IEC 63758-9: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/4552/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 63758-9 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 9: 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
CommunicationsProtocol
Version2.3
PublishDate:08December2025
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 7
1.1 StructureoftheQi Specification 7
1.2 Scope 8
1.3 Compliance 8
1.4 References 8
1.5 Conventions 9
1.5.1 Notationofnumbers 9
1.5.2 Tolerances 9
1.5.3 Fieldsinadatapacket 9
1.5.4 Notationoftextstrings 10
1.5.5 Short-handnotationfordatapackets 10
2. Overview 11
2.1 Protocolphases 11
2.2 PowerTransferContract 12
2.2.1 LoadPowerlevelnegotiation 14
2.2.2 Examples 16
2.3 Datapackettypes 17
2.4 High-levelmessagesanddatatransportstreams 18
2.5 RCPX001-PowerProfileIntegrity 19
2.6 Backwardcompatibility 20
3. PowerReceiverandPowerTransmitteridentification 21
4. Pingphase 22
4.1 Pingphasestatediagram 23
4.1.1 Transitionsfromstate0 24
4.1.2 Transitionsfromstate1 24
4.1.3 TransitionsfromstateF 25
4.2 Pingphasetimings 25
4.2.1 PowerReceiverdetection 25
4.2.2 PowerReceiverwake-up 27
4.2.3 DigitalPingtimeout 27
4.2.4 EndPowerTransfer(EPT)datapacket 28
4.2.5 PowerReceiverreset 28
4.2.6 Illegaldatapacket 29
5. Configurationphase 30
5.1 Configurationphasestatediagram 31
5.1.1 Transitionsfromstate2 31
5.1.2 Transitionsfromstate3 32
5.1.3 Transitionsfromstate4 32
5.1.4 Transitionsfromstate5 33

5.1.5 Transitionsfromstate6 33
5.1.6 Examples 34
5.2 Configurationphasetimings 34
5.2.1 Genericconstraints 35
5.2.2 Consecutivedatapackets 36
5.2.3 Configuration(CFG)datapacket 36
5.2.4 Illegalvalueinadatapacket 37
5.2.5 Illegaldatapacket 37
6. Negotiationphase 38
6.1 NegotiableelementsofthePowerTransferContract 39
6.2 UpdatingthePowerTransferContract 40
6.3 ForeignObjectDetectionsupport 41
6.4 WirelesspowerID 41
6.5 NFCtagprotectionsupport 41
6.6 Negotiationphasestatediagram 42
6.6.1 Transitionsfromstate7 43
6.6.2 Transitionsfromstate8 45
6.6.3 Transitionsfromstate9 45
6.6.4 Transitionsfromstate10 46
6.6.5 Examples 47
6.7 Negotiationphasetimings 54
6.7.1 Consecutivedatapackets 55
6.7.2 Simple-queryanddata-requestdatapackets 56
6.7.3 EndPowerTransfer(EPT)datapacket 57
6.7.4 Illegaldatapacket 58
6.7.5 FODgracewindow 58
7. Powertransferphase 59
7.1 Powertransferstatediagram 60
7.1.1 Transitionsfromstate11 62
7.1.2 Transitionsfromstate12 63
7.1.3 Transitionsfromstate13 63
7.1.4 Transitionsfromstate14 64
7.1.5 Transitionsfromstate15 65
7.1.6 Examples 65
7.2 Datatransportstream 67
7.2.1 Datatransportstreamformat 67
7.2.2 Datamodel 69
7.2.3 Even/oddADTheadermechanism 70
7.2.4 Examples 74
7.3 Powertransferphasetimings 82
7.3.1 Generictimingconstraints 84
7.3.2 ControlError(CE)datapackets 84
7.3.3 ReceivedPower(RPandRP8)datapackets 85

7.3.4 EndPowerTransfer(EPT)datapacket 86
7.3.5 Simple-queryanddata-requestdatapackets 86
7.3.6 Comms-loss-timeout(PowerTransmitter) 86
7.3.7 Action-timeout 86
7.3.8 Illegaldatapacket 89
7.3.9 Datatransportstreamtiming 90
8. PowerReceiverdatapackets 91
8.1 AuxiliaryDataControl—ADC(0x25;simplequery) 93
8.2 AuxiliaryDataTransport—ADT(multipleheadercodes;simplequery) 94
8.3 ChargeStatus—CHS(0x05;statusupdate) 95
8.4 Configuration—CFG(0x51;simplequery) 96
8.5 ControlError—CE(0x03;powercontrol) 98
8.6 DataStreamResponse—DSR(0x15;datarequest) 99
8.7 EndPowerTransfer—EPT(0x02;powercontrol) 100
8.8 ExtendedIdentification—XID(0x81;statusupdate) 102
8.9 FODStatus—FOD(0x22;simplequery) 103
8.10 GeneralRequest—GRQ(0x07;datarequest) 104
8.11 Identification—ID(0x71;statusupdate) 105
8.12 PowerControlHold-off—PCH(0x06;statusupdate) 106
8.13 Proprietary—PROP(multipleheaders;multipletypes) 107
8.14 ReceivedPower—RP8(0x04;statusupdate) 108
8.15 ReceivedPower—RP(0x31;simplequery) 109
8.16 Renegotiate—NEGO(0x09;simplequery) 111
8.17 SignalStrength—SIG(0x01;statusupdate) 112
8.18 SpecificRequest—SRQ(0x20;simplequery) 113
8.18.1 SRQ/en—Endnegotiation:parameterfieldandresponses 114
8.18.2 SRQ/fsk—FSKconfiguration:parameterfieldandresponses 114
8.18.3 SRQ/gp—GuaranteedLoadPower:parameterfieldandresponses 115
8.18.4 SpecificRequest[PowerControlHold-off]-SRQ/pch 116
8.18.5 SRQ/prop—Proprietary:parameterfieldandresponses 117
8.18.6 SRQ/rcs—Recalibrationsupport:parameterfieldandresponses 117
8.18.7 SRQ/rep—Re-pingdelay:parameterfieldandresponses 118
8.18.8 SRQ/rp—ReferencePower:parameterfieldandresponses 119
8.18.9 SRQ/rpr—ReceivedPowerreporting:parameterfieldandresponses 120
8.19 WirelessPowerID—WPID(0x54,0x55;simplequery) 121
8.20 Reserved 122
9. PowerTransmitterdatapackets 123
9.1 AuxiliaryDataControl—ADC(0x25) 125
9.2 AuxiliaryDataTransport—ADT(multipleheadercodes) 126
9.3 DataNotAvailable—NULL(0x00) 127

9.4 PowerTransmitterCapabilities—CAP(0x31) 128
9.5 PowerTransmitterExtendedCapabilities—XCAP(0x32) 129
9.6 PowerTransmitterIdentification—ID(0x30) 130
9.7 Proprietary—PROP(multipleheaders) 131
9.8 Reserved 132
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,CommunicationsProtocol(thisdocument)definesthemessagingbetweenaPowerTransmitterand
aPowerReceiver.Theprimarypurposeofthismessagingistosetupandcontrolthepowertransfer.Asasecondary
purpose,itprovidesatransportmechanismforhigherlevelapplicationssuchasAuthentication.Thecommunications
protocolcomprisesboththerequiredorderandtimingrelationsofsuccessivemessages.
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. Overview
WhenauserplacesaPowerReceiverwithintheOperatingVolumeofaPowerTransmitter,thetwostartto
communicatewiththeaimtoconfigureandcontrolthepowertransfer.ThePowerSignalprovidesthecarrierforall
communications.TheQiSpecification,CommunicationsPhysicalLayerdefinesthelow-levelformatsofdatabits,data
bytes,anddatapackets.TheQiSpecification,CommunicationsProtocol(thisdocument)definesthepayloadsofthedata
packetsandtheiruseinthepowercontrolprotocols.
2.1 Protocolphases
TheQiSpecificationdefinestwocommunicationsprotocols.
l
BaselineProtocol—theoriginalprotocolintroducedinversion1.0oftheQiPowerClass0Specification,which
usesPowerReceivertoPowerTransmittercommunicationsonly.
l
ExtendedProtocol—addedinversion1.2oftheQiPowerClass0Specificationtosupportbi-directional
communicationsandenhancedForeignObjectDetection(FOD)features.Version1.3oftheQiSpecificationadds
datatransportstreamfunctionalityandauthenticationoptions.
AsshowninFigure2,thecommunicationsprotocolcomprisesseveralphases.Thenegotiationphaseisnotpresentin
theBaselineProtocol.
Figure2-Protocolphases
l
Pingphase.ThePowerTransmittertriestoestablishcommunicationswithaPowerReceiver.Beforedoingso,it
typicallyperformsmeasurementstodetermineifthereareobjectssuchasbankcards,coinsorothermetals,
whichcandamageorheatupduringthepowertransfer.Thesemeasurementsproceedwithoutwakingupthe
PowerReceiver.SeetheQiSpecification,PowerDelivery,forrestrictionsonsuchmeasurements.
NOTE:ThePowerTransmittertypicallypostponesaconclusionwhetherdetectedmetalsareForeignObjectsorFriendly
Metalstothenegotiationphase,afterobtainingdesigninformationfromthePowerReceiver.SeetheQiSpecification,
ForeignObjectDetection,fordetailsaboutrecommendedmethods.
l
Configurationphase.ThePowerReceiversendsbasicidentificationandconfigurationdatatothePower
Transmitter.BothsidesusethisinformationtocreateabaselinePowerTransferContract.Moreover,thePower
TransmitterandPowerReceiverdecidewhethertocontinuewiththeBaselineProtocolortheExtendedProtocol.
NOTE:APowerReceivercanonlymakeuseoffeaturessuchasenhancedFOD,datatransportstreams,andauthenticationif
itimplementstheExtendedProtocol.
l
Negotiationphase.ThisphaseisnotpresentintheBaselineProtocol.ThePowerTransmitterandPowerReceiver
establishanextendedPowerTransferContractcontainingadditionalsettingsandlimits.ThePowerReceiveralso
providesdesigninformationtothePowerTransmitter,whichthelattercanusetocompleteFODbeforeswitching
tothepowertransferphase.SeetheQiSpecification,ForeignObjectDetection,fordetailsaboutthisinformation.
l
Powertransferphase.ThisisthephaseinwhichthepowertransfertothePowerReceiver’sLoadoccurs.Inthe
ExtendedProtocol,thePowerTransmitterandPowerReceiverperformasystemcalibrationatthestartofthis
phase.SeetheQiSpecification,ForeignObjectDetection,fordetailsaboutcalibration.Occasionalinterruptionsof
thisphasemayoccurtorenegotiateanelementofthePowerTransferContract.However,thepowertransfer
continuesduringsuchrenegotiations.
Table3summarizesthemainfeaturesofthetwoprotocolvariants.

Table3-ComparisonoftheBaselineProtocolandtheExtendedProtocol
Feature BaselineProtocol ExtendedProtocol
PowerTransmitterdesign TypeAxandtypeBxdesigns Alldesigns
only
PowerReceivertoPower Loadmodulationatafixed2 Loadmodulationatafixed2kHzclock
Transmitter kHzclock
Communications
PowerTransmitterto N/A Frequencyshiftkeyingatafrequency
PowerReceiver dependentclockof /512
Communications
Operatingphases Ping,configuration,and Ping,configuration,negotiation,and
powertransfer powertransfer
Powerlevelcalibration N/A Atthestartofthepowertransfer
phase
Authentication N/A Usingdatatransportstreamsinthe
powertransferphase
2.2 PowerTransferContract
APowerTransferContractcomprisesthesettingsandlimitsgoverningthepowertransfer.ThePowerReceiversetsup
aninitialPowerTransferContractasapplicabletotheBaselineProtocol.ThefirstpartofTable4showstheelementsof
thisinitial(orbaseline)PowerTransferContract.ThePowerTransmitterreceivesallinformationtoduplicatethe
baselinePowerTransferContractintheconfigurationphaseoftheprotocol.
SomeelementsofthePowerTransferContractarenegotiable,enablingthePowerTransmitterandPowerReceiverto
determinenewvaluesfortheseelementsinthenegotiationphaseoftheprotocol(ExtendedProtocolonly).Inthe
BaselineProtocol,allelementsofthePowerTransferContractkeeptheirvaluesuntilthepowertransferends.
TheExtendedProtocolmakesuseofanextendedPowerTransferContractthatcontainstheadditionalelementsshown
inthesecondpartofTable4.SeetheQiSpecification,PowerDelivery,andSection6,Negotiationphase,fordetailsabout
theuseoftheseelements.
Table4-PowerTransferContract
Element Symbol Unit Negotiable Comment
ElementsofabaselinePowerTransferContract
ReferencePower W Yes* ThereferencepowerlevelforRP8andRPdata
packets.TheCFGdatapacketprovidestheinitial
value.SeeSection8.14,ReceivedPower—RP8(0x04;
statusupdate),foranexampleofitsusage.
ReceivedPower ms No Thepropertiesofthetimewindowformeasuringthe
windowsize ReceivedPower.TheCFGdatapacketprovidesthese
values.SeeFigure63inSection7.3,Powertransfer
ReceivedPower ms No
phasetimings.
windowoffset
PowerControlHold- ms Yes ThedelaybetweentheCEdatapacketandthepower
off leveladjustmentwindow.Defaultsto5ms.SeeFigure
62inSection7.3,Powertransferphasetimings.
ReceivedPower N/A N/A Yes* TheresolutionofthereportedReceivedPower.
reportingresolution Defaultsto8bit(RP8datapacket).
AdditionalelementsofanextendedPowerTransferContract
FSKpolarity,  N/A N/A Yes PowerTransmittertoPowerReceivercommunications
modulationdepth, parameters. TheCFGdatapacketprovidestheinitial
andnumberof valuesforthepolarityandmodulationdepth.The
cyclesperbit numberofcyclesperbitdefaultsto512.
PotentialLoad W No ThehighestGuaranteedLoadPowerlevelthePower
Power Transmittercannegotiate.Nodefault.SeeSection
2.2.1,LoadPowerlevelnegotiation,andtheQi
Specification,PowerDelivery,fordetails.
GuaranteedLoad W Yes Thenegotiatedpowerlevel.Defaultsto5W.See
Power Section2.2.1,LoadPowerlevelnegotiation,andtheQi
Specification,PowerDelivery,fordetails.
Re-pingdelay ms Yes ThedelaybetweenanEPT/repdatapacketandthe
nextDigitalPing.Defaultsto12.6second.
*InthenegotiationphaseoftheExtendedProtocol

2.2.1 LoadPowerlevelnegotiation
APowerReceivercantypicallyoperateatmultipletargetpowerlevels.Todeterminethemostappropriateone,the
PowerReceivernegotiatesaGuaranteedLoadPowerlevelwiththePowerTransmitter.Figure3showsthesteps
involved.
Figure3-LoadPowerlevels
ThePotentialLoadPowerlevelisthehighestLoadpowerlevelthePowerTransmittercannegotiateatanytime.The
NegotiableLoadPowerlevelisthehighestLoadpowerlevelthePowerTransmitteriswillingtonegotiateatagiven
time.Usually,theNegotiableLoadPowerlevelisequaltothePotentialLoadPowerlevel.However,insomeconditions,
thePowerTransmittermaysettheNegotiableLoadPowerleveltoalowervalue.Afirstexampleofsuchaconditionis
anoperatingtemperaturethatcancausethePowerTransmittertooverheatwhentransferringpoweratthehighest
level.AsecondexampleisaninsufficientlycapablepowersupplydrivingthePowerTransmitter.ThePowerReceiver
canretrievethePotentialLoadPowerlevelandtheNegotiableLoadPowerlevelfromthePowerTransmitterusinga
GRQ/capdatapacket.
TheRequestedLoadPoweristheLoadpowerlevelatwhichthePowerReceiverintendstooperate.Itprovidesthis
powerleveltothePowerTransmitterusinganSRQ/gpdatapacket.IftheRequestedLoadPowerlevelislessthanor
equaltotheNegotiableLoadPowerlevel,thepowerlevelnegotiationissuccessful,andboththePowerTransmitterand
PowerReceiverstoretheRequestedLoadPowerlevelasaGuaranteedLoadPowerlevelintheircopiesofthePower
TransferContract.
Section6,Negotiationphase,Section8.18.3,SRQ/gp—GuaranteedLoadPower:parameterfieldandresponses,andSection
9.4,PowerTransmitterCapabilities—CAP(0x31),providedetailsandexamplesofpowerlevelnegotiationsequences.
TheLoadPowerlevelaPowerTransmittercansupportdependsonseveralfactors.
l
ThedesignsofthePowerTransmitterandPowerReceiver
l
ThepositionofthePowerReceiverintheOperatingVolume
l
ThepowersupplyofthePowerTransmitter
l
TheLoadofthePowerReceiver
l
Theoperatingtemperature
ThePotentialLoadPower,NegotiableLoadPower,andRequestedLoadPowerlevelsusedinthenegotiationprocessare
meaningfulonlyifthePowerReceiverhasadesignthatis“similar”toonethereferencedesignslistedinTable5.See
theQiSpecification,PowerDelivery,fordetails.
NOTE:APowerReceivermayattempttodrawmorepowerthantheGuaranteedLoadPowerlevel,andaPowerTransmittermay
providemorepowerthantheGuaranteedLoadPowerlevelorPotentialLoadPowerlevel.However,thesystemoperationis
undefinedinthosecases.SeetheQiSpecification,PowerDelivery,fordetails.

Table5-PowerLevels
PowerLevel ReferencePowerReceiver*
5W PowerReceiverexample1,
PowerReceiverexample2
8W PowerReceiverexample3
12W PowerReceiverexample5
15W PowerReceiverexample4
*TheQiSpecification,PowerDelivery,definesthereferencePowerReceiverslistedhere.

2.2.2 Examples
Table6,Table7,andTable8provideexamplesofPowerTransferContracts.IntheExtendedProtocol,theinitialPower
TransferContractcontainstheelementsofthebaselinePowerTransferContractplustheelementsoftheextended
PowerTransferContract.
Table6-ExampleofabaselinePowerTransferContractwhenleavingtheconfigurationphase
Element Symbol PowerReceiverValue PowerTransmitterValue
ReferencePower 5W 5W
ReceivedPowerwindowsize 8ms 8ms
ReceivedPowerwindowoffset 8ms 8ms
PowerControlHold-off 5ms 5ms
ReceivedPowerreportingresolution N/A 8bit 8bit
Table7-ExampleofanextendedPowerTransferContractwhenenteringthenegotiationphase
Element Symbol PowerReceiverValue PowerTransmitterValue
ReferencePower 5W 5W
ReceivedPowerwindowsize 8ms 8ms
ReceivedPowerwindowoffset 8ms 8ms
PowerControlHold-off 5ms 5ms
ReceivedPowerreportingresolution N/A 8bit 8bit
FSKpolarity,modulationdepth,and N/A Positive/Category0/512 Positive/Category0/512
numberofcyclesperbit
PotentialLoadPower Unknown 15W
GuaranteedLoadPower 5W 5W
Re-pingdelay 1000ms 1000ms
Table8-ExampleofanextendedPowerTransferContractwhenleavingthenegotiationphase
Element Symbol PowerReceiverValue PowerTransmitterValue
ReferencePower 10W 10W
ReceivedPowerwindowsize 8ms 8ms
ReceivedPowerwindowoffset 8ms 8ms
PowerControlHold-off 5ms 5ms
ReceivedPowerreportingresolution N/A 16bit 16bit
FSKpolarity,modulationdepth,and N/A Positive/Category0/512 Positive/Category0/512
numberofcyclesperbit
PotentialLoadPower 15Worunknown* 15W
GuaranteedLoadPower 8W 8W
Re-pingdelay 500ms 500ms
*IfthePowerReceiverdoesnotrequesttheCAPdatapacketintheExtendedProtocol,thePotentialLoadPower
remainsunknowninthePowerReceiver’scopyofthePowerTransferContract.
2.3 Datapackettypes
WhereasthePowerTransmitterstartsthecommunicationsprotocolbyapplyingaDigitalPing(attheendoftheping
phase),thePowerReceiverdrivestheexecutionoftheremainingphasesoftheprotocol.ThismeansthatthePower
Receiverinitiatesalldatapacketcommunications,andthatthePowerTransmitterwaitstosendadatapacketor
ResponsePatternuntilexplicitlyinvitedtodoso.
NOTE:AlthoughitisthePowerReceiverthatdrivesthecommunicationsprotocol,thePowerTransmittermayadjustthepowerlevel
orstopthepowertransfercompletelyatanytimeifitconsidersthatnecessarytoensuresafesystemoperation.For
additionalinformation,seetheQiSpecification,PowerDelivery.
ThePowerReceivercansendfourkindsofdatapackets:
l
Statusupdate—thePowerTransmitterdoesnotreplytothesedatapackets.
l
Powercontrol—thePowerTransmitteradjuststhepowerlevelinresponsetothesedatapackets.
l
Simplequery—invitesthePowerTransmittertoreplywithaResponsePattern(ACK,NAK,ND,ATN).
l
Datarequest—invitesthePowerTransmittertoreplywithafulldatapacket.
NOTE:TheBaselineProtocolusesstatusupdateandpower-controldatapacketsonly.
ThePowerTransmittershouldnotrespondtodatapacketsthatsufferfromcommunicationserrors.Thereasonisthat
datapacketcorruptioncouldresultinthePowerTransmitterprovidingthewrongtypeofresponse,confusingthe
PowerReceiver.ThelackofaresponseisaclearsignaltothePowerReceiverthatsomethingwentwrongandthatit
shouldresendthedatapacket.
2.4 High-levelmessagesanddatatransportstreams
Thepurposeofmostcommunicationsintheprotocolistoconfigureandcontrolthepowertransfer.However,the
ExtendedProtocolalsosupportsdatatransportstreams,whichcanpasshigh-levelmessages(oftenunrelatedtothe
powertransfer)betweenthePowerTransmitterandPowerReceiver.Examplesofsuchmessagesincludethe
authenticationmessagesthatthePowerTransmitterandPowerReceivercanusetoverifyeachother'scredentialsina
tamper-resistantmanner.
NOTE:ThegoalofauthenticationistoensurethatthePowerTransmitterand/orthePowerReceiverhavepassedindependenttests
certifyingsafeoperation.
APowerReceivertoPowerTransmitterdatatransportstreamconsistsofasequenceofsimple-querydatapackets,with
thepayloadsofthesedatapacketscarryingthehigh-levelmessagedata.ThePowerReceivercaninitiateadata
transportstreamatanytimeinthepowertransferphase.Conversely,whenaPowerTransmitterhasahigh-level
messagetosendtothePowerReceiver—andhasensuredthatthelattercanprocessthatmessage—itcandrawthe
PowerReceiver'sattentionbyrespondingwithanATNResponsePatterntoanincomingsimple-querydatapacketin
thepowertransferphase.ThissignalsthePowerReceivertotransmitaseriesofdata-requestdatapacketsenablingthe
PowerTransmittertosendadatatransportstream.

2.5 RCPX001-PowerProfileIntegrity
APRxproductshallonlyoperateusingtheprotocol(s)definedforthepowerprofilestatedonthePRxproductself-
declarationform.
2.6 Backwardcompatibility
Table9summarizesthekeydifferencesbetweenpreviousversionsandversion1.3oftheQiSpecification,
CommunicationsProtocol(thisdocument),otherthanthoseassociatedwiththenewdatatransportstreamand
authenticationfunctionalities.PowerTransmittersandPowerReceiversshouldexaminetheircounterpart’sversion
numbertohandlethesedifferencesappropriately.
NOTE:Priortoversion1.3,thedefinitionofthecommunicationsprotocolwascontainedinsection5oftheQiWirelessPower
TransferSystem,PowerClass0Specification,Parts1and2,InterfaceDefinitions.
Table9-Backwardcompatibility
Version Backwardcompatibilitynotes
1.0.x BaselineProtocoldifferencestoversion1.3
l
ThevaluecontainedinanRP8datapacketrepresentsarectifiedpowerlevel
ratherthanaReceivedPowerlevel.
1.1.x —
1.2.x NoBaselineProtocoldifferencestoversion1.3
ExtendedProtocoldifferencestoversion1.3
l
APowerTransmitterdoesnotsupportadefineddelaybetweentheremovalofthe
PowerSignalandthenextDigitalPing
l
APowerTransmitterdoesnotsupportaPowerReceiverabortingthenegotiation
phaseandproceedingtothepowertransferphaseofthebaselineprotocol
l
APowerTransmitterdoesnotsupportFOD/rfdatapackets(butitshouldbe
resilienttoreceivingsuchdatapackets)
l
Inthenegotiationphase,aPowerTransmitterrespondswithNDtosimple-query
datapacketshavingoneormorereservedbitssettoONEratherthanignoring
thosebits
l
APowerTransmitterdoesnotacceptadditionalSRQ/endatapacketsaftersending
anACKResponsePatterntothefirstSRQ/endatapacketattheendofthe
negotiationphase.IfaPowerReceiversendsasecondSRQ/endatapacket,the
PowerTransmitterinterruptsthepowertransfer.Notethatthereisnopower
transferinterruptionwhenboththePowerReceiverandPowerTransmitterare
v1.3compliant.
l
APowerReceiverdoesnotrecognizeATNResponsePatterns.Accordinglyitwill
notsendDSRdatapacketsinvitingthePowerTransmittertosendCAPdata
packetswiththeaimtotriggerthePowerReceiverintorenegotiating.
l
APowerTransmittermaysendCHS,PROP,and/orreserveddatapacketswhile
calibrating (thatis,beforesendingitsfirstRP/0orRP/4datapacketinthepower
transferphase).
1.3.x Extendedprotocoldifferencestoversion2.0
l
APowerTransmitterdoesnotsupportareducednumberofcyclesperFSKbit.

3. PowerReceiverandPowerTransmitteridentification
APowerReceiveridentifiesitselftoaPowerTransmitterwiththefollowinginformation.
l
TheversionoftheQiSpecification,CommunicationsProtocolwithwhichthePowerReceivercomplies.
l
APowerReceiverManufacturerCode(PRMC)identifyingthePowerReceiver'smanufacturer.
l
AbasicdeviceidentifieridentifyingthePowerReceiveramongmultiplePowerReceiver'spresentinthe
OperatingVolume.
NOTE:ThebasicidentifiermaychangefromtimetotimeasdefinedinSection8.11,Identification—ID(0x71;status
update).
l
Anoptionalextendeddeviceidentifierprovidingadditionalinformation.
l
OptionallyaWirelessPowerID(WPID).SeeSection6.4,WirelesspowerID,fordetails.
l
IntheExtendedProtocol,thePowerReceivercanrequestthePowerTransmittertoidentifyitselftothePower
Receiverwiththefollowinginformation.
l
TheversionoftheQiSpecification,CommunicationsProtocolwithwhichthePowerTransmittercomplies.
l
APowerTransmitterManufacturerCode(PTMC)identifyingthePowerTransmitter'smanufacturer.
l
APowerTransmitterCertificate.SeeQiSpecification,AuthenticationProtocol,fordetails.
NOTE:IntheBaselineProtocol,aPowerReceivercannotretrieveaPTMCfromthePowerTransmitter.However,thisdoesnotmean
thatthelatterdoesnothaveanassociatedPTMC.TheproductregistrationoftheWPCrequiresthemanufacturerofthe
PowerTransmittertosubmitaself-declarationformlistingthePTMC.
APowerTransmittershallnotusethePRMCinanywaythatlimitsthedesignfreedomofthePowerReceiver.
Conversely,aPowerReceivershallnotusethePTMCinanywaythatlimitsthedesignfreedomofthePower
Transmitter.
ThepurposeofthePRMCandPTMCistoenablePowerTransmittersandPowerReceiversofthesamemanufacturer
recognizeProprietary(PROP)datapacketsmoreeasily.
Asanexample,amanufacturercanhavemultiplePowerReceiverProductswithsubstantiallydifferentdesignproperties
suchascouplingfactor,FriendlyMetalarrangement,etc.WhenusingknowledgeofthePRMConly,aPowerTransmitter
canthereforeeasilymakeincorrectassumptionsabouttheseproperties.Byadjustingitsoperationbasedonits
assumptions,suchasadjustingthresholdsetc.,interoperabilityfailureislikelytooccur.

4. Pingphase
Atthestartofthepingphase,thePowerTransmitterdoesnotyetknowwhetheraPowerReceiverispresentwithinits
OperatingVolume.ThePowerReceiverisnotawareofthePowerTransmittereither,becauseitssystemsaretypically
inactiveduetothelackofaPowerSignal.
Figure4illustratesthestagesofthepingphase.Inthefirstthreestages(dottedarrows),thePowerReceiverisnot
active.Moreover,thePowerTransmittershouldensurethatanysignalsitusesinthesephasesdonotwakeupthe
PowerReceiver.Inthefourthstage(dashedarrow),thePowerTransmitterattemptstowakeupthePowerReceiver.In
thelaststage(solidarrow),thePowerReceiverstartsitscommunications.
Figure4-Stagesofthepingphase
BeforeinitiatingaDigitalPingtosolicitaresponsefromaPowerReceiver,thePowerTransmittershouldgothroughthe
followingstages.
l
Detectobjects.Forthispurpose,thePowerTransmittercanuseAnaloguePingsoravarietyofalternative
methods.TheQiSpecification,PowerDelivery,providesanumberofexamples.
l
OptionallyapplyNFCtagprotectionasdefinedintheQiSpecification,NFCTagProtection.
TheQiSpecification,NFCTagProtection,providesrecommendationsabouthowtoexecutetheabovesteps.
NOTE:InsteadofperformingNFCtagdetection,aPowerTransmittermaylimitthePowerSignalthroughoutthepowertransferto
levelsthatdonotdamageNFCtags.TheQiSpecification,NFCTagProtection,providesguidelinesandmethodstodetermine
safepowerlevels.
l
CollectinformationthathelpstodecidewhetherForeignObjectsarepresentinadditiontoaPowerReceiver.For
thispurpose,thePowerTransmittercanuseavarietyofmethodscommonlyknownaspre-powerFODmethods.
TheQiSpecification,ForeignObjectDetection,definesthesemethods.
AfterperformingtheabovestepsanddeterminingthattherepotentiallyisaPowerReceiverinitsoperatingVolume,the
PowerTransmitterinitiatesaDigitalPingtosolicitaresponsefromthePowerReceiver,whichiseitheraSignal
Strength(SIG)datapacketoranEndPowerTransfer(EPT)datapacket.Ifthereisnosuchresponse,thePower
Transmitterstaysinthepingphaseandshouldrepeattheabovesteps.
NOTE:PowerTransmittersemployingmultiplecoilstoenableagreaterpositioningfreedomforaPowerReceivertypicallyinitiatea
DigitalPingmultipletimesusingdifferentcoil.Typically,suchPowerTransmittersaborttheprotocolafterreceivingtheSIG

datapacketfromthePowerReceiveruntiltheyhavedeterminedtheoptimumcoiltouseforthepowertransfer.TheQi
Specification,PowerDelivery,providesexamplesofthisapproach.
4.1 Pingphasestatediagram
TheQiSpecification,CommunicationsProtocol(thisdocument)describestheprotocolusingstatediagramthatapplyto
boththePowerTransmitterandthePowerReceiver.Inmoststates,thePowerTransmitterorPowerReceivercansend
orreceiveadatapacket.Dependingonthisdatapacket,thePowerTransmitterandPowerReceiverswitchtothenext
state.Inthecaseofcommunicationserrors,thePowerTransmitterandPowerReceivercanswitchtodifferentstates.
ThepowertransferprotocolprovidesmechanismstoresynchronizethePowerTransmitterandPowerReceivertothe
samestate.
SomestatetransitionsapplyonlytothePowerTransmitteroronlytothePowerReceiver,asindicatedbytheirlabels.
Mostofthesetransitionsrelatetoerrorconditionssuchastimeoutsorunexpectedcontentinareceiveddatapacket.
Additionally,somestatetransitionslistmultipleconditions.Satisfyinganyoneofthoseconditionsissufficienttofollow
suchatransitiontothenextstate.
ThedescriptionofstatetransitionsthatapplytoboththePowerTransmitterandthePowerReceiverusethedata
packetsender'sperspective.Thedatapacketreceiver'sperspectiveofthesetransitionssimplyistohavereceivedthe
datapacketcorrectly.Ifthedatapacketreceiverdoesnotreceivethedatapacketcorrectly,atransitionthatis
associatedwithanappropriatetimeoutapplies.
ThestatediagramshowninFigure5appliestoboththeBaselineProtocolandtheExtendedProtocol.
Figure5-Statediagramofthepingphase

4.1.1 Transitionsfromstate0
State0isthefirststateoftheprotocol.ThePowerTransmitterswitchestothisstateaftercompletingitspower-up
initializationfunctions.Inthisstate,thePowerTransmitterattemptstodetectthepresenceofaPowerReceiver,NFC
tags,andForeignObjects.Thefollowingtransitionsarepossiblefromthisstate.
l
PTx:AnaloguePing.ThePowerTransmitterhasattemptedtodetectobjectsusinganAnaloguePingoran
alternativemethod.SeetheQiSpecification,PowerDelivery,fordetails.
l
PTx:NFCtagdetection.ThePowerTransmitterhasattemptedtodetectNFCtagsintheOperatingVolume.Seethe
QiSpecification,NFCTagProtection,fortherecommendedapproach.
l
PTx:DigitalPing.ThePowerTransmitterhasfoundanobjectthatislikelytocontainaPowerReceiverand
thereforehasinitiatedaDigitalPing.
l
PTx:ForeignObjectdetected.ThePowerTransmitterhasdetectedaForeignObject,orNFCtag,whichpreventsit
frominitiatingaDigitalPing.SeetheQiSpecification,ForeignObjectDetection,forexamples.
l
PTx:nopower.ThePowerTransmitterhasdiscoveredthatitcannotsustainapowertransfertothePower
Receiver.
NOTE:ThePowerTransmittermayconcludethatitcannotsustainapowertransferwhenthePowerReceiverrepeatedly
requestsittoterminatethepowertransferusingEPT/nrorEPT/andatapackets(inthenegotiationphaseand/or
powertransferphase).Forexample,thePowerTransmittercannotsustainapowertransferiswhenthePower
TransmitterispluggedintoanunderratedUSBpowersource.
4.1.2 Transitionsfromstate1
State1isthefirststateoftheprotocolinwhichthePowerReceiverparticipatesactively.Thefollowingtransitionsare
possiblefromthisstate.
l
SIG.ThePowerReceiverhassentaSIGdatapacket.
l
PRx:EPT.ThePowerReceiverhassentanEPTdatapacket.
l
PTx:EPT.ThePowerTransmitterhasreceivedanEPTdatapacket.
l
PTx:illegaldatapacket.ThePowerTransmitterhasreceivedadatapacketotherthanSIGorEPT.
l
PTx:pingtimeout.ThePowerTransmitterhasnotdetectedthestartofadatapacketbeforetheDigitalPing
timeoutt .SeeSection4.2.3,DigitalPingtimeout,forthetimeoutvalue.
ping
l
PRx:noresponse.Inexceptionalcases,thePowerReceivermaychoosenottorespondtoaDigitalPing.

4.1.3 TransitionsfromstateF
InstateF,thePowerTransmitterresolvesanyfaultconditionthatcanoccurinexecutionoftheprotocol.ThePower
Transmittercanreachthisstatefromanyoftheotherprotocolphases,inparticularwhen
l
ItreceivesanEPTdatapacket.
l
IttimesoutonadatapacketfromthePowerReceiver.
l
Itdetectsaprotocolerror(e.g.onreceivinganunexpecteddatapacket).
l
Itdecidestoaborttheprotocolforinternalreasons(e.g.whenexecutingconsecutiveDigitalPingsonmultiple
coils).
NOTE:ReceptionofanEPTdatapacketdoesnotnecessarilymeanthatafaulthasoccurred.Forexample,itcaninvolvearequest
fromthePowerReceivertodelayrestartingtheprotocol.SeeSection8.8,ExtendedIdentification—XID(0x81;status
update),foralistoferrorcodes.
UponenteringstateF,thePowerTransmittershallremovethePowerSignalwithinthetimewindow .
l
PTx:faultresolved:ThePowerTransferhasresolvedthefaultconditionsandisreadytorestartexecutionofthe
protocol.
4.2 Pingphasetimings
Table10providesanoverviewofthetimingconstraintsthatapplytothepingphase.
Table10-Timingconstraintsinthepingphase
Parameter Side Symbol Minimum Target Maximum Unit
Detectiontimewindow PTx N/A N/A 5,000 ms
Wake-upwindow PRx 19 40 64 ms
DigitalPingtimeout PTx 65 65 70 ms
Powertermination PTx N/A N/A 28 ms
window
Resetwindow PRx N/A 25 28 ms
NoPowerSignalwindow PTx 32 N/A N/A ms
NextDigitalPingwindow PTx SeeTable24inSection8.7,EndPower
Transfer—EPT(0x02;powercontrol)
Restartafterillegal PTx N/A 400 500 ms
packet
ForthetimingdetailsandotherpropertiesoftheAnaloguePingsthePowerTransmittermayusetodetectobjects,see
theQiSpecification,PowerDelivery.
4.2.1 PowerReceiverdetection
ThePowerTransmittershallinitiateaDigitalPingat fromtheuserplacingaPowerReceiverwithinitsOperating
Volume.
Figure6-Detectiontimewindow
NOTE:TheblacklinerepresentsthePowerSignal,whichinitiallyiszeroandincreaseswhenthePowerTransmitterinitiatesthe
DigitalPing.ThePowerTransmittermayapplyAnaloguePingsbeforeinitiatingtheDigitalPing.SuchAnaloguePingswould
showasbriefdeparturesoftheblacklinefromthezerolevel.

4.2.2 PowerReceiverwake-up
IfthePowerReceiverintendstoengagewiththePowerTransmitter,itshallsendaSIGdatapacketat afterthe
PowerTransmitterhasinitiatedtheDigitalPing.IfthePowerReceiverdoesnotintendtoengagewiththePower
Transmitter,itshalleithersendanEPTdatapacketat afterthePowerTransmitterhasinitiatedaDigitalPing,or
notrespondatall.
NOTE:APowerTransmittermayusemultipleDigitalPingstoenhancethepositioningfreedomofaPowerReceiver.APower
ReceivershouldthereforerespondconsistentlywithaSIGdatapackettosuchDigitalPings.SeeSection8.17,Signal
Strength—SIG(0x01;statusupdate),foranexplanationofhowthePowerReceivershoulddeterminetheSignalStrength
ValueintheSIGdatapacket.
Figure7-Wake-upwindow
NOTE:SeetheQiSpecification,CommunicationsPhysicalLayer,forthereferencetimeofthestartofadatapacket.
4.2.3 DigitalPingtimeout
IfthePowerTransmitterhasnotdetectedthestartofadatapacketat ,itshallremovethePowerSignalat .
ThestartoftheDigitalPingtimeoutistheapplicationofthePowerSignal.
Figure8-DigitalPingtimeout
NOTE:SeeSection4.2.5,PowerReceiverreset,fordetailsabout and .

4.2.4 EndPowerTransfer(EPT)datapacket
APowerTransmittershallremovethePowerSignalat fromtheendofanEPTdatapacketandswitchtostate
Fofthepingphase,regardlessoftheEndPowerTransferCodecontainedinthedatapacket.AfterremovingthePower
Signal,thePowerTransmittershallinitiateafirstDigitalPingat fromtheendoftheEPTdatapacket.Thevalue
of dependsonthevaluecontainedintheEPTdatapacket.
Figure9-EndPowerTransferdatapackettiming
AftersendingafirstEPTdatapacket,thePowerReceivershouldcontinuetosendEPTdatapacketswhilethePower
Signalispresent.Thetransmissionofthesedatapacketsshallcomplywiththetimingconstraintsforconsecutivedata
packetsprovidedinSection5.2.2,Consecutivedatapackets.
NOTE:ConsecutiveEPTdatapacketsmaycontaindifferentvaluesintheirEndPowerTransferCodefields.
4.2.5 PowerReceiverreset
ThePowerTransmittershallnotapplyanAnaloguePingorinitiateaDigitalPinginthetimewindow after
removingthePowerSignal.ThePowerReceivershalldiscardthePowerTransferContractat ,andshallenablethe
1MHzresonance,afterthePowerTransmitterremovesthePowerSignal.IfthePowerSignalreappearsbeforethe
PowerReceiverhasdiscardedthePowerTransferContract,itmaycontinuewiththeprotocolfromthestateitwasin
whenthePowerSignaldisappeared.
NOTE:Thetimewindow appliesinparticulartoconsecutiveDigitalPingsinPowerTransmittersthatusemultiplecoilsto
enableagreaterpositioningfreedomforPowerReceivers.
Figure10-Resettimewindow
4.2.6 Illegaldatapacket
ThePowerTransmittershallremovethePowerSignalat afterreceivinganillegaldatapacket.
Figure11-Illegaldatapackettimeout
NOTE:IfthetimetoreceivethefirstdatapacketinthepingphasetakeslongerthanthetimetoreceiveaSIGorEPTdatapacket,the
PowerTransmittershouldtreatthatdatapacketasanillegaldatapacketandremovethePowerSignalwithoutwaitingto
receivetheremainderofthedatapacket.
Afterremovingthepowersignaldueto“illegalpacket,”aPTxshallimplementdigitalpingwithin .
APRxproductshouldwaitforthepowersignaltoberemovedforgreaterthan ,beforesignallingtothe
userachangeinchargingstatus.
5. Configurationphase
Theconfigurationphaseisthepartoftheprotocolinwhich:
l
ThePowerReceiveridentifiesitselftothePowerTransmitter.
l
ThePowerReceiverandPowerTransmitterestablishabaselinePowerTransferContract.SeeSection2,Overview
,fordetailsabouttheinformationcontainedinthePowerTransferContract.
l
ThePowerReceiverandPowerTransmitterdeterminetheprotocolvarianttouseinthepowertransfer.
Intheconfigurationphase,thePowerTransmitterandPowerReceivercontinuetooperateusingtheDigitalPing
parameters.ThismeansthatthepowerandcurrentlevelsinboththePowerTransmitterandPowerReceiverchange
onlyifausermovesthePowerReceiverfromitspositionwithintheOperatingVolume.
NOTE:Multi-coilPowerTransmittersmayproceedintotheconfigurationphasetoobtainthePowerReceiver'sidentificationdata
beforeexecutinganewDigitalPingwithadifferentcoilconfiguration.ThisenablessuchPowerTransmitterstodiscriminate
betweenmultiplePowerReceiverslocatedwithintheirOperatingVolumes.SeetheQiSpecification,PowerDelivery,for
examplesofthisapproach.
Figure12summarizesthedataflowintheconfigurationphase.ThePowerReceiveridentifiesitselfusingan
Identification(ID)datapacketandoptionallyanExtendedIdentification(XID)datapacket.Itprovidesdataforusein
thePowerTransferContractusinganoptionalPowerControlHold-off(PCH)datapacketandaConfiguration(CFG)data
packet.Inthefinalstep,thePowerTransmitteracknowledgesExtendedProtocol(ifapplicable).
Figure12-Dataflowintheconfigurationphase

5.1 Configurationphasestatediagram
ThestatediagramshowninFigure13appliestoboththeBaselineProtocolandtheExtendedProtocol.
NOTE:Fordetailsabouthowtointerpretthisdiagram,seeSection4.1,Pingphasestatediagram.
Figure13-Statediagramoftheconfigurationphase
5.1.1 Transitionsfromstate2
Instate2,thePowerReceiveridentifiesitselftothePowerTransmitter.Thefollowingtransitionsarepossiblefromthis
state.
l
ID.ThePowerReceiverhassentanIDdatapacketwithitsExtbitsettoZERO.SeeSection8.11,Identification—ID
(0x71;statusupdate),forthemeaningoftheExtbit.
l
ID/x.ThePowerReceiverhassentanIDdatapackethavingitsExtbitsettoONE.
l
PTx:illegaldatapacket.ThePowerTransmitterhasreceivedadatapacketotherthanID.
l
PTx:next-timeout.ThePowerTransmitterhasnotdetectedthestartofadatapacketfromthePowerReceiver
beforethenextdatapackettimeout .SeeSection5.2.2,Consecutivedatapackets.
l
PTx:abort.ThePowerTransmittermayabortfu
...