I've made a quick demo video about the Advanced Cable Tester (Level 2) addons on OpEval from +Total Phase​. If you're interested in the kind of factory-grade hardware I use, and help companies troubleshoot, check it out.

Skip to the end if you want to see an example of some actual tests demonstrating why not all cables are created equal; during live testing, the Apple Store A-to-C cord proves its premium.

Major note: I plan to make this detailed data publicly accessible. I will revisit my prior reports and standardize in a single format. The actual data on many cables from various manufacturers will be collated so Power Users, manufacturers, and consumers alike can come to an informed decision and hopefully lead to better products.

Please contact me if you are interested in contributing data to (or accessing) this repository.

#USB #TypeC #USBC

Thanks to a generous equipment donation by +Total Phase​​​​​​, I'll now able to provide refutable data on USB3.1Gen2 (10gbps) A-to-C and C-to-microB cords.

These add-on boards and mounting baseplate (along with a firmware update) will allow resistance measurement, conductivity checking, eMarker probing, and (basic) signal integrity measurement. More practically for me, it automatically generates pretty cable reports! 😁

Previously I did this all manually using several pieces of equipment, such as my Arduino cable tester, Twinkie PD sniffer, and load testers.... it was extremely labor intensive. (And explains why I stopped making those reports.) My data was also qualitative, since I had to use a single power adapter across all tests from which I back-calculated voltage drop, then resistance -- I could not measure it directly.

This piece of kit is generally intended for "every cable" QC testing at the end of a production line. So "bad cables" will stick out like a sore thumb.

I'm going to use this as an opportunity to quickly re-run tests of all my previous cables in one standardized format and share the data publicly in one repository. Hopefully it helps power users out there looking for the best cable, or manufacturers for what mistakes to avoid! 😎

(Please keep in mind this is a Quality Assurance tool, NOT a replacement for proper USB-IF Certification! This is intended as a sanity check at the end.)

Next post will be a quick "deep dive' video tutorial on how to set it up, and what a sample run looks like.

#USB #TypeC #USBC

[Correction notice] This is an addendum about the 75th-76th #USB #TypeC evals/bad cables.
tl;dr: USB3.1 spec has redundancies for reversed polarity SS lanes (like PCIe). See [Section 6.4.2 Lane Polarity Inversion]. The cable will appear to work -- however, it is still miswired and unsafe. This was a "saved by skin of their tooth" situation. (Note: USB2.0 polarity reversal will still result in severe errors.)

I'd like to offer a big thank you to an industry expert "CY" for providing a consult on this issue. While discussing the exact failure mode of the Nekteck cable, they brought it to my attention that physical hardware damage was unlikely. Further research on my behalf yielded the rest. Please be warned, this only applies for the USB3.1 protocol. Any other "sideband" uses of this cable will still potentially result in hardware damage. Crisis was only averted due to the robustness of the USB3.1 protocol.

http://www.cypress.com/knowledge-base-article/swapping-polarity-usb-30-differential-pairs-kba86900
http://electronics.stackexchange.com/questions/227892/rx-polarity-inversion-in-usb3-x

Basically put, with high speed signals, the mere routing of wires can cause radio interference that degrades the "signal integrity" of data and cause corruption. To simplify PCB routing (and cost), the USB3.1 spec was designed with the ability to connect SS pin pairs together in any polarity. During "link training" a fixed set of patterns is transmitted, and the pins identified automatically that way. However, this only applies for internal PCB connections and routing -- not external ones, like cables!!

See [Section 5.5 Cable Assemblies] in the USB3.1 spec or [Section 3.5 Legacy Cable Assemblies] in the Type-C spec for concrete proof that miswired cables are not allowed.

Note that in USB2.0, this will result in severe signal degradation. (High speed [2.0] and Full speed [1.1] as Low speed [1.0] due to inversion of the J and K idle states.)
http://www.usbmadesimple.co.uk/ums_3.htm

#USBC

[Correction notice] This is an addendum about the 74th-76th #USB #TypeC evals/enclosures.
tl;dr: USB to PCIe bridges are not mature yet. After speaking with Anton Shilov of +AnandTech (regarding feedback +Benson Leung had on his article), we found an error in a press release.

http://www.anandtech.com/show/10938/sharkoon-launches-rapidcase-usb-31-typec-storage-device-diy-kit

In my evals, I cited the above article as evidence some enclosures use an ASMedia 1142 bridge chip to support full 10gbps. (USB3.1Gen2 to PCIe bridge followed by a PCIe controller.) However, after Benson cited it was "highly unlikely", I contacted Anton for clarification.

It seems Sharkoon misstated the capabilities of their enclosure in their press release, or Anandtech misinterpreted the document. It is not "true" USB3.1Gen2 10gbps. It instead uses an ASM1351 USB-to-SATA bridge which caps bandwidth at 6gbps per the SATA protocol. The article was mistaken when it stated a 1142 is used inside the box.

However, in the process of investigating this issue, I did discover a "no name" chipset that supports USB3.1Gen1 (5gbps) to PCIe SSD's (AHCI only, not NVMe). It's called a "LM900" and no whitepapers exist for it. I believe it to be a clone of +SanDisk's Extreme 900 SSD RAID chip (Incorrect: the TweakTown article states it is a 1352R) or +Plextor SSD's EX1 (doubtful, VL716), although I only have marginal basis for that guess.

=========================================
https://www.amazon.com/M-2-NGFF-PCIe-Adapter-Case/dp/B01ENG9PCA/
https://www.amazon.com/Bplus-PCIe-USB3-0-Adapter-U3M2M/dp/B00LX0Z1IW

http://www.bplus.com.tw/Adapter/U3M2M.html

Some more:
https://www.amazon.com/Micro-Plextor-M-key-PCI-E-Enclosure/dp/B01N4OLCBY/
https://www.amazon.com/Cablecc-Micro-Plextor-M-key-Enclosure/dp/B01N6QZN3M/

What chipset is "LM900"?
http://i.ebayimg.com/images/g/BCsAAOSw4DJYfIBP/s-l1600.jpg
http://www.ebay.com/itm/381925726493
=========================================
http://www.anandtech.com/show/10852/plextor-launches-ex1-usb-c-external-ssd-up-to-550-mbs-512-gb-and-ldpc
http://www.goplextor.com/PressCenter/NewsContent/84
http://www.viatech.com/en/2016/10/via-labs-vl716-usb-if-certification/

http://www.anandtech.com/show/10245/sandisk-extreme-900-usb-31-gen-2-portable-ssd-review
http://www.tweaktown.com/reviews/7623/sandisk-extreme-900-usb-3-1-gen-2-portable-ssd-review/index.html
http://www.usb.org/press/presskit/ASMedia_Technologies_Announced_Industrys_First_SuperSpeed_USB_10_Gbps_to_SATA6G_with_RAID_device_controller_20150825.pdf
=========================================

I have asked Anton if he would be willing to test/investigate this "LM900" chip. A USB3.1Gen2 to PCIe 2x2 or 3x1 bridge would be an great chip to have. Although the latency will be high from all the encoding/decoding, it would still be an invaluable tool to maximize the capabilities of USB-C.

This has also been eye-opening to the source of bandwidth bottlenecks. Even though your computer may claim USB3.1Gen2, if an inferior controller chip is used (ASMedia 1142 vs Intel Alpine Ridge) or uses inferior hardware design with insufficient PCIe lanes dedicated to it (Dell laptops with single-port, PCIe 2-lane/20gbps Thunderbolt 3 port vs dual-port, PCIe 4-lane 40gbps Thunderbolt 3 port), you will end up with weird scenarios where you aren't getting what was advertised/you were sold.

http://www.kitguru.net/peripherals/anton-shilov/asmedia-and-intel-cut-prices-of-usb-3-1-chips-speed-up-adoption/
https://plus.google.com/u/0/102612254593917101378/posts/EF9mvx7M1Q9

I've put this in "Writeups" as this is a bit of a technical rant, but feedback is welcome.

#USBC

I'm proud to announce two bugs I discovered + reported with the #madebygoogle Pixel Sailfish have now been corrected.

(1) "Overdraws OEM 18w charger": The Pixel Sailfish had a bug causing it to error out with its own charger and report a "capability mismatch". It claimed only a 5v/2a contract, but drew 5v/3a in violation of said contract. (Again, this is with all OEM Google equipment.)

(2) "9v PSU hog": The Pixel Sailfish can only draw 9v/2a. Yet it was claiming a 9v/3a contract. This "hogging" behavior overprovisioned the PSU and denied other devices use of that spare capacity.

Both issues were reported to +Benson Leung​ who in turn passed them to the Pixel team. I am reporting them now since both issues are fixed, and should be out shortly.

(There are additional bugs I am investigating, but will disclose later as appropriate. I am still a bit concerned nobody caught these...?)

#USB #TypeC #USBC #anyonehiring ?

Documenting this. #madebygoogle Pixel (Sailfish) NMF26U has a somewhat serious charge controller firmware flaw. See pictures. Passing this off (with Bug Reports + PD dumps).

Basically, the Pixel is wigging out and (a) requesting the wrong current value (b) claiming a "mismatch" on its own charger and (c) "overcurrenting" it's own supply as a result. (Oi.) This may explain some "not charging" issues you guys are experiencing.

Thanks to Reddit user /r/Lumiii for sharing her problem. I did some debugging as a reply and discovered this in the process.

https://www.reddit.com/r/GooglePixel/comments/5nmg8s/pixel_not_charging_properly/

This is how I normally troubleshoot issues for you guys.... surfing social media, then replicating. So if you run into an issue -- please post! Or call in to Google Support and tell them. Or send feedback from Settings -> About phone on your device. Unless you let Google know, there's no way they can tell there's a problem.

(I am a rather glaring exception to this, but you shouldn't count on that!)

This is a followup to my previous test of the Nexus 6P "Sudden Shutoff" bug. I ran another experiment, this time without using a heat reservoir.
tl;dr: I've pretty much identified (one particular) cause of the sudden shutoffs, and have a proposed fix for Google.

https://plus.google.com/102612254593917101378/posts/dpUd5Bm8Df5

Same methods, except this time no icepacks or battery saver. Notice the discharge and voltage curves are almost completely linear. I was able to plot this data in relation to the "heatsinked" data. Please see graph #1. This tells me Google "calibrated their battery algorithm" by running a phone at full tilt ONLY at max temperature. Likely they didn't consider the possibility people would use the phone in environments that would sink heat faster than thermal throttling would kick in.

You know how I said "errors during the production process"? This means not location testing the phone around the world. This phone and battery cell was qualified in the tropics (China/Taiwan). Likely they didn't send units to Norway/Russia/Japan/etc. to test thermal effects... if they did, they would have encountered this a lot sooner. (This is what they do for cars/motorcycles/tanks. Idle them in a metal box in Death Valley, and run them with thick oil in Alaska. Apparently consumer electronics haven't come that far.) And no lab machine can substitute for real-world testing. It can only approximate what you already know. ("Known unknowns vs unknown unknowns.")

https://plot.ly/~Nathan-K/2/

I also plotted all four metrics in a 3d scatterplot to visualize the effects of (a) "True % remaining" (b) temperature (c) call voltage and (d) applied load simultaneously.  See the attached 3d scatterplot link. It's a little dense, but basically:

Left/right = "True % remaining"
Forward/back = Temperature
Up/down = Cell voltage
Color =  Intensity of current draw

You can think of it as a bunch of blankets on top of each other.  Or digging through the crust of the earth. The deeper you dig, you'll find "flat layers"  of different colors. (Or in these graphs, those colors are a certain current draw.)

I'll follow this up in a bit with another post explaining it, but basically (one possible) cause for the sudden shutoffs is:

(1) When battery is cold, voltage sags more
(2) When battery is loaded heavily, voltage sags more
(3) When battery is highly charged, voltage sags more

Hence (1) when it is cold (2) and people fire up the camera (3) at high battery % -- their phone dies.


Google will have to redo their battery calculation logic from scratch to incorporate an empirically determined 4-dimensional calibration curve (only part of which is illustrated, with only 2 runs of points). You have to compensate out for these 3 measures when calculating battery "level".

Right now, the battery level calculation doesn't account for (a) temperature or (b) applied current load. Because of the battery's natural internal resistance, which rises in these conditions

This calibration system would also have the benefit of compensating for "weak" or "old" batteries. (Battery age/cycles/wear could be a theoretical fifth axis to the curve. Completely possible.) Also, Google needs to fix "Battery Saver" bug breaking the internal sensor polling intervals (and readouts), which is exacerbating this problem.

Data is at the usual place.
https://drive.google.com/open?id=0B2OJRSgNnm4GaHVHemFqaEp6bkE

#USB #TypeC #USBC

This is a followup to the +Perigears​​​​​ PG015CW analysis, and my recent poll about the #madebygoogle Pixel 18w charger. I want to present a case study of what causes chargers to flicker on and off rapidly, and why the #USB #TypeC Compliance thresholds of "0.85-2.45v ON, >2.75 OFF" matter.

This is actually the scenario that prompted the poll. I've been messaging Perigear's engineers for the last few days trying to explain why USB-C Spec Compliance is so important, and why they should re-make their product to be Compliant.
https://plus.google.com/102612254593917101378/posts/Ddho6Wef7Vq
https://plus.google.com/102612254593917101378/posts/hDFLbnBHRd1

tl;dr: "Flickering" can be caused by bad charger thresholds (no Schmitt trigger) combined with GND DC offset caused at load by cable resistance.

Please see the attached picture.

Perigears' charger "claims" to have a 2.20v threshold on the CC line to turn on. (This is an issue too, but bear with me.) The problem this causes is some devices with resistor values at legal and acceptable values at the edge of manufacturing thresholds will cause the charger to switch off mid-charge, then switch back on. Again and again.

Obviously, this is very bad for the device.

This is because USB-C shares a common ground for Power and Analog signaling. When loaded, the ground resistance value of the cable causes a DC offset proportional to the current applied, up to 250mV max per the spec.

This in turn causes an increase in the "apparent Rd" of the device. With Vcc voltage near the upper limit, this means the charger will be operating just-below the threshold at 0a. But at 3a, will be just ABOVE that threshold.

Bob's your uncle, you're stuck in a hysteresis loop.

This is what the "Schmitt trigger" in the spec (only turning off above vOpen of 2.75v) was all about.... in addition to the finite state machine diagram stuff. It is to prevent situations like this where simple analog noise can cause a charger to fail to operate properly.

All these values are pre-calculated into the spec -- with exacting tolerance. So it is critical manufacturers "stick to the blueprints" exactly as instructed.

Hopefully this has been informative, and explains a type of failure mode some of you might have experienced out there.

#USBC  

If I said the Google Pixel 18W USB-PD power supply was technically noncompliant.... would people be upset ...? (；¬д¬)

(Note: this just affects an obscure USB-PD command. And if you pay close attention, Google makes no claims about the charger being compliant in the first place! I just checked the manual.)

Two days ago, I found myself stranded in the boonies in 35 degree weather because my car wouldn't start. I pulled over for a bite and had stopped for less than 5 minutes, but when I tried cranking, the battery voltage sagged. It couldn't turn the engine over -- let alone keep the cabin lit. It sucked. It was only thanks to my familiarity with how to preheat a battery (and the fact I use a tender) did I manage to get home.

Why do I mention this? I've been following people having sudden battery shutoff with their Nexus 6Ps. I did some experiments over Christmas showing it was related to the cold and sudden current loading. There were some other elements I was reluctant to discuss given my position as a +Google Top Contributor Program TC for Nexus/Pixel devices -- I intentionally avoided this topic since I want to avoid any semblance of COI. (Full disclosure: even my family member who also owns a Nexus 6P and does nothing "hackerish" with his phone was affected, and complains to me about it regularly. He's taken to carrying around a RavPower #USB #TypeC pack wherever he goes.)

However, having experienced the same crappy situation many other have been -- for very similar reasons -- I wanted to put this study out with the goal of helping users help themselves.

My main concerns are showing you guys what the potential issues are and (a) what aspects of it you can benefit from being aware of, (b) how to avoid them, and (c) discuss possible avenues for Google to fix. Again, I am out of the loop, and the below is independent experimentation and data. My conclusions may be wildly incorrect. All data is shared at the drive link below. Use it for what you will.

============================
[Processed data and Linux scripts]
https://drive.google.com/open?id=0B2OJRSgNnm4GaHVHemFqaEp6bkE

The following was conducted on an Angler Nexus 6P running 7.1.1 NMF26F.

[My previous experiments replicating:]
https://plus.google.com/102612254593917101378/posts/aTCSVkBC7ra
https://plus.google.com/102612254593917101378/posts/SjPzsvmQp4y

[Associated reading]
https://plus.google.com/+HendrikvanNiekerk/posts/SjLR8HqyFY1
https://code.google.com/p/android/issues/detail?id=227849

============================
Methods:
Charge Nexus 6P to 100%. Place on ice packs over a towel to maintain a constant core battery temperature (manually) while discharging to avoid thermal throttling. Use wireless ADB logging scripts to dump battery system data. Disable BatterySaver mode. Engage airplane mode, turn on WiFi (for wifi ADB).

Use battery waster app and/or flashlight to drain to shutoff with a constant load. (This is important.) Use "tail -f" to monitor log and adjust phone on ice packs as needed to maintain constant temperature and monitor for errors.

============================
Results and Disussion:
See the attached excel image. Findings of note:

(1) The "battery level" indicator on the Nexus 6P is wildly miscalibrated. Notice how it gets "stuck" at 10% level for over an hour despite the constant drain. Also consult the "Level + Charge counter" and "Charge counter vs level" graphs.

I am aware some CPU throttling may be going on. But consult the "Current now" graph. There was clearly at least 1A of load, and the battery level stayed flat at 10% throughout. This indicates a significant level determination error.

(2) The Nexus shut off abruptly (Level transition from 4% to 0% in under 30s) when the Voltage reached 3.300 volts exactly. The Charge counter still indicated 795691 Coulombs (?) available.

(3) The Coulomb counter sensor becomes highly inaccurate after the threshold "battery saver" should kick on. I disabled it immediately, but you can see from the "Charge counter" graph the level gets "stuck" at certain levels and becomes highly inaccurate.

(Edit: only the ADB dumpsys battery counter gets frozen, the dumpsys batteryproperties remains linear!!!)

This suggests some sensor hardware is being turned off or not working at low battery, including critical battery monitoring sensor hardware. Which seems weird.

(4) The temperature sensor hardware apparently also wigs out at low battery. Notice how abrupt the temperature sensor transitions become, and are almost discrete states.

Despite my best efforts to reposition the Nexus 6P on the cooling pad as necessary to maintain a constant temperature, because it became "stuck" at certain levels, I over/undershot -- hence the jerkiness in the graph. It was by feel at that point. (Again, I'm marginally employed/broke, unfunded, and working out of a basement. I lack a peltier thermoelectric heatsink.)

It's important to maintain the battery at an isotherm to avoid affecting Voltage readout due to the battery's internal resistance.

(5) Voltage and Charge counter does not appear to have a direct relationship to battery level. It is likely indirect, or based off a sensor I cannot monitor.

There must be some algorithm abstracting multiple metrics to get the "Level". Unfortunately I am not skilled enough in AOSP code to determine what it is.

(6) It seems at 35:14 mm:ss into the run is when everything went tits-up. Sensors stopped working as they should, and despite disabling battery saver things still went awry.

(Edit: This is when the Charge counter from ADB dumpsys battery starts significantly diverging from ADB dumpsys batteryproperties. It repeats values -- first intermittently, then a lot. This suggests Battery Saver is partly to blame, and it does it by killing critical sensor processes!)

This is the exact moment "15%" battery level was reached. This suggests some internal threshold was triggered. Likely Battery Saver.

============================
So in summary, I've identified and replicated two, possibly three different factors causing this. There are a few more I speculate at.

[Core findings]
(1) Per my first experiment, I've determined when subjected to cold, battery voltage drops SIGNIFICANTLY more than normal when loaded. [Such as by firing up camera, or running Pokemon Go/sensors.]

This sudden drop of voltage is apparently considered an "emergency crash" by the phone and it shuts off into some safe mode -- where you must hook it to a charger to turn back on. This suggests bootloader voltage protection safeties are kicking on inappropriately.

(2) Per this current experiment, there is a clear battery charge miscalculation problem. The level displayed does not accurately represent the electrical capacity remaining in the battery pack.

It appears the Coulomb counter is the closest approximation to the ACTUAL linear capacity of the battery. However see (3) for a caveat regarding this sensor:

(3) There is some Android code problem with battery saver mode, or some low-voltage hardware issue, causing critical sensors to fail to operate at low charge. This lack of feedback is causing other more complex problems I cannot fully identify.

(4) Physical heatsinking characteristics of the phone itself and efficiency of powersave modes may be contributing to this problem.

This one is trickier, and is related to battery pre-heating. Two goals oppose heat retention: (1) phone bodies are built to have a low "k" (thermal resistance) value to dissipate as much heat into the environment as possible. However, this also means they cool down to ambient excessively as well. (2) Android doze, energy saver, low power, etc. mean less power is going through circuits to keep them warm during long sleep states. Then when they are abruptly brought online, it is causing the physical battery hardware to be overload due to thermal effects. (Think of Apollo 13 where they had to carefully bring the equipment online slowly in a specific order so as to not overtax the cold batteries.) This is related to the Thevenin Equivalent Circuit of a battery.

So by being too efficient, we essentially are running into a new class of physical/thermal hardware failures. At least, that is my opinion.

============================
[How you can protect yourself:]
(a) Please keep your phone as warm as possible when carrying it in the cold. Use an insulated pouch, keep it in your inside jacket, use a case that RETAINS heat like silicone. (Fight that low k value.)

(b) If you must travel in the cold exposed, please keep a small portable battery pack and A-to-C cable with you to "jump start" your phone in an emergency. Again, this is not ideal advice, but it is practical until a software calibration solution is found.

(c) If there is any software fix to this "hardware" problem, YOU MUST BE PATIENT. Fudging with core  power circuit calibration code is very delicate, and potentially dangerous if done inappropriately. So Google is likely being careful. Everything will likely need to be validated and tested 6 ways from Sunday.

Also keep in mind Google didn't write most of the power IC code -- Qualcomm did. At least, that's what the comments in the code say, and the committers e-mails on AOSP say. So now you have two companies having to play ball.

(d) General Winter always wins.

(Edit:)
(e) - try disabling Battery Saver! It seems it is disturbing some critical battery voltage monitoring processes, exacerbating the problem!


I plan to do another post following up this one, explaining more clearly using a purely synthetic model (graphs and curves).

#USBC