43rd #USB #TypeC analysis: +Anker PowerPort Speed PD 60w wall charger [Model A2015111].
tl;dr: Noncompliant charger. Printed and advertised levels do not match actual capabilities. Overload protection is better (shuts off), but still iffy (cycles on and off rapidly). It will not work properly on laptops and high-power devices.

Anker got the 15v PDO right this time.... except they typoed the programming as 15/2a (30w) instead of 3a (45w). </Jackie Chan face>

The below is almost a verbatim Copy + Paste from the 30w version, since the exact same failures apply.


=================================

[PDF of Compliance Checklist for Anker A2015111]
(to be posted later, data in images)

Anker released this product just a few days ago. It seems they repeated certain design errors common to their other products.

https://plus.google.com/+BensonLeung/posts/71FgNerD8TB

This charger violates [Section 10.2.2 Normative Voltages and Currents] [Table 10-2 Normative Voltages and Currents] of the USB-PD spec. This sates "Table 10-3, Table 10-4, Table 10-5 and Table 10-6 show the Fixed Supply PDOs that shall be supported for each of the Normative voltages defined in Table 10-2."

Per [Section 1.4.2.10 Shall/Normative]: "Shall and Normative are equivalent keywords indicating a mandatory requirement. Designers are mandated to implement all such requirements to ensure interoperability with other compliant Devices."

Furthermore, Anker misrepresents the capabilities of the charger on marketing materials and text on the charger itself. On the side of the charger and online it claims: "5v/3a 9v/3a 15v/3a 20v/3a". USB D+/D- BC1.2 DCP signaling mandatory. [I advocate "Autodetect" signaling here.]

The actual electronic capabilities of the charger are "5v/3a 9v/3a 15v/2a  20v/3a". USB D+/D- have Apple 12W signaling.  (Attached traffic dumps from a TotalPhase PD-Analyzer and Google/Plugable Twinkie linked.)

This will cause it to silently fail when used with certain high-power devices and laptops needing the 15v rail. I dislike this type of error since users without very expensive test equipment will never know what is happening.

Another ramification of this is certain devices like Chromebooks which prefer "lower voltage for same wattage" will latch on to the higher voltage rail and generate more heat converting voltage than they otherwise should.

15v*2a=30w, 2/3 the claimed 45w of the supply. 20v*3a=60w. The rules were set up so devices which can only accept 20v get 20v (like laptops) -- but flexible ones (like Chromebooks) which accept 15v or 20v can take whatever is most efficient for them to convert. In this case, 15v is more "efficient" and runs cooler.

But because Anker used 15v/2a advertisement (instead of 3a), Laptops needing 45w will have to snap to the higher 20v/1.5a instead of asking for 15v/3a. You're probably generating 5-7.5W of waste heat [and losing that much from charging] as a result. (See my recent disclosure about the Pixel charging behavior for "thermal" notes.)

This appears as if Anker simply messed up the settings in the USB-PD IC chip. The fix is to type a "3" instead of a "2".

This suggests other bugs in the PD controller firmware, which I found.

The IR drop compensation is sawtooth, not linear. This suggests non-optimal design. With the chips already in the charger, it should have been possible to use linear PWM compensation. The PD controller firmware has bugs shared with some chargers, like inappropriate packet header incrementing, and claiming  to be "dual role data" when it is not appropriate.

Finally, the overload protections are better than the 30w version, but still iffy. The charger uniformly shuts off and reboots into 5v. But it does not stay off until replugged like a safe Apple charger. (Documentation supplied in the form of TotalPhase PD-Analyzer voltage and current logs.)

All in all I'd say this was a VERY close attempt by Anker, but due to borking the USB-PD chip programming I can't recommend it.

  #USBC  
PhotoPhotoPhotoPhotoPhoto
[Plus] Analyses Anker A2015111
18 Photos - View album
Shared publiclyView activity