标签: QC

手机、电脑等科技产品性能越来越强大，屏幕也越生产越大，连带耗电量也逐渐增加，如何实现快速充电是用户关心的话题。但是，在用户体验中，以下问题现象成为了消费者困扰的难题。 手机具备快充功能，但是充电速度为什么依旧很慢？ 快充安全有隐患？充电爆炸成恐慌。 边滑手机边充电，手机发热惹惊慌？！ 市场产品品质参差不齐，消费者若使用不符合规范的充电器进行充电，或是使用标准不合的充电器或者使用了劣质线材，手机不但无法实现快充功能，更会产生安全隐患。关于快充，您又知多少？ 快充原理： 在电学上，电压（伏特， V ）乘以电流（安培， A ）就可以得到功率（瓦特， W ），充电瓦数越高，代表充电所需的时间越短。现在的快充技术可透过以下三种方式实现。 1. 高电压低电流模式：增强电压，提高充电功率 2. 低电压高电流模式：提高电流，加强充电功率 3. 高电压高电流模式：增强电压，提高电流 简单来讲，快充就是在安全的负载范围内，能够有效提升产品充电速度、降低充电时间。目前市面上热议的快充技术，包括高通推出的 Quick Charge™ (QC) 及 USB 开发者论坛所定义的 USB Power Delivery (PD) 。 什么是 USB Power Delivery? USB Power Delivery (USB PD) 是利用 USB (Universal Serial Bus) 线缆，最大可供 100W 供电受电的 USB 供电扩充标准。过往 USB 最大供电功率分别为 USB 2.0 (2.5W) 、 USB 3.0 (4.5W) 、 BC 1.2 版本（ 7.5W ），现在一跃至 100W 供电受电，因此笔记本电脑、平板电脑等以往无法支援的设备也能进行供受电，可支援的设备大幅扩大。 USB PD 使用 USB Type-C® 连接器，可以在以往 USB 资料通讯的同时进行供电，涵盖手机、相机、充电宝、平板电脑、笔记本电脑、显示器等，一条线简单搞定充电及数据传输。另外还支援 Alternate Mote 模式，因此可以处理视频信号。使用 1 个 USB 段子就可以进行数据传输、供电受电、视频信号传输，从而可以搭建简单、便利性高的环境。 USB Power Delivery (USB PD) 技术 USB Power Delivery (USB PD) 1.0 规范种对供电能力设定为五个级别（ Profile 1~5 ） : Profile 1 （提供 5V@2A ， 10W 供电，适用于手机等各类可便携式装置） Profile 2 （提供 5V@2A 、 12V@1.5A 、 10~18W 供电，适用于平板电脑或外接存储装置） Profile 3 （提供 5V@2A 、 12V@3A 36W 供电，适用于超极本等装置） Profile 4 （提供 5V@2A 、 12/20V@3A 60W 供电， microUSB 支持的最大供电规格，适用于 All in One 电脑） Profile 5 （提供 5V@2A 、 12V@5A 、 20V@5A 100W 供电，用于标准 A/B 与 USB Type-C® 连接头，适用于液晶显示器、平板电视） USB PD 1.0 支持四种电压 5V 、 9V 、 15V 、 20V ，最高 100W ，并向下兼容 USB 3.2/2.0 、 BC 1.2/1.1/1.0 ，并有 5 种 Profile 。 USB PD 2.0 可使用 Type-A 、 Tyep-B 及 Type-C 接口。到了 USB PD 3.0 ，仅能使用 USB Type-C® 接口，并加入 PPS （ Programmable Power Supply ）。 USB PD 2.0 VS. USB 3.0 什么是 QC 快充？ Quick Charge™ (QC) 快充为高通公司（ Qualcomm® ）所研发的快充技术，只要有搭载旗下晓龙 ™Snapdragon 系统晶片的安卓手机，皆可使用其快充技术。除了支持多款采用晓龙 ™Snapdragon 处理器的手机之外，也支持部分其他品牌的处理器。 QC 快充技术推出的历史版本如下： QC 1.0 支援 10W 起； QC 2.0 支援 15W 起； QC 3.0 支援 18W 起； QC 3+ 支援 18W 起； QC 4 支援 18W （ A ） /27W （ B ）起； QC 4+ 支援 18W （ A ） /27W （ B ）起； QC 5 支援 45W 起。 2020 年高通（ Qualcomm® ）推出商用快速充电技术 Quick Charge™ 5 (QC 5) ，可支持 Android 智能手机大于 100W 充电功率的快充晶片。其效率较前一代高 70% ，且充电速度快 4 倍，装置电量于 5 分钟可从 0% 充至 50% ；同时采用高通（ Qualcomm® ）旗下充电功率智能识别配接器技术，可在最高电力转换传输效率下确保充电安全，因此可延长装置电池的寿命。 除此之外， QC 5 不但相容于之前的 QC 4+ 、 QC 4 、 QC 3 和 QC 2 ，而且延续 QC4 ，一样能运用于 USB-PD 和 Type-C 技术，并相容于 USB Type-C 协议等产业标准，因此可进而扩充到其他装置。 QC4+ VS. QC5 读到这里相信您对快充的规范也有所了解，但是市面宣称拥有快充功能的产品千百种，这些产品又是否真的具备这些功能呢？市场上形色不同的快充产品又是否能够通过 USB Power Delivery 或 Qualcomm Quick Charge 的相关测试呢？ 延伸Q&A Q1: 是不是产品应用了通过 PD 认证的芯片，产品就可以通过 PD 认证呢？ A1: 不是。即使产品应用了通过 PD 认证的芯片，若厂商自身设计产品的技术有局限，依旧会导致产品无法通过 PD 测试项目，最后无法达到快充功效。 Q2: 若产品想要通过 PD 认证，是不是一开始就必须使用通过 PD 认证的芯片？ A2: 不是。只需要您的产品最后通过 PD 快充认证，产品即可打 PD 快充 Logo ，具备快充功能，针对是否使用通过 PD 认证芯片无要求。 Q3: 如何识别产品是否具备快充功能？ A3: PD 快充为非强制性认证，但是若您想要打上 Logo ，则必须要过认证哦！而若您的产品使用了 QC 技术，就必须做 QC 认证。

供应QC 2.0快速充电功能 CX7811 CX7811 快速充电接口控制器 概述      CX7811 是一款支持Quick Charge 2.0（QC 2.0）快速充电协议的充电接口控制器IC，可自动识别充 电设备类型，并通过充电协议与设备握手，使之获得 设备允许的安全最高充电电压，在保护充电设备的前 提下节省充电时间。                             特点  完全支持 Quick  Charge  2.0 规范          A类：5V、9V及12V输出电压          B类：5V、9V、12V及20V输出电压         可选12V或20V输出限制  兼容USB充电规范1.2         支持USB充电规范DCP模式         默认5V模式工作  待机功耗低          5 V输出电压时低于350uW  可靠的保护功能        引脚间短路保护        引脚开路保护及电路故障保护  封装形式：SOP8/SOT23-6 应用领域 支持QC 2.0快速充电功能的移动电源、 便携式充电器、车载充电器

“The Quality Assurance team is there to test the system and generate a list of bugs. Developers then fix those, and, after passing QA’s tests, the product ships.” Not. First, in manufacturing QA is not quality control. QA is about defining the processes used, raw material fitness, and the like. Instead, quality control insures that a product meets a standard defined by the QA group. However, almost every software group conflates QA and QC, generally folding both operations into the single term QA. I have no reason to tilt against windmills so will use the term “QA.” Software engineering isn’t manufacturing; we don’t need to adopt their nomenclature. I believe that developers have the responsibility to deliver extremely high-quality code. Tiny teams may deliver directly to the customer, while larger groups have a separate QA operation. Regardless, we engineers must create the very best work products. QA’s role is to demonstrate the absence of defects. Sure, life is tough and software complex. Sometimes they will find problems. But that doesn’t absolve the engineers of their responsibility to strive for perfection. We engineers must take pride in our work, demonstrate exceptional craftsmanship, and constantly hone our tools, processes and techniques to achieve the highest quality. Wise managers will use the results of QA’s verification and validation work to audit the software engineering process. If they’re finding more than a few problems, that’s an indication that there’s something wrong in the firmware group. This is a quantitative result, something measureable, which can be monitored over time to see if the engineering team is getting better or worse. Three important principles are embodied in the notion of using QA’s results to audit the development team:Metrics – Engineering without numbers is not engineering – it’s art. Metrics hold us accountable and let us evaluate the process. Feedback – Every EE knows that feedback stabilizes electronic systems. It also stabilizes human systems. Use the results of any operation (in this case QA) to continuously improve the process. Filters – Software is tough to get right, which means we need to use as many filters as possible. The compiler identifies syntax errors, inspections other problems, test even more. QA is the last one. If the last filter is still finding problems that’s an indication something is wrong… or another filter is needed. QA should also be responsible for constructing and managing regression tests. That should be done outside of the engineering team since it’s a meta-operation that requires constant attention, an attention of the sort that is quite orthogonal to writing code. That may mean building and maintaining test jibs, continuous integration servers, and all of the infrastructure verification and validation demand. Aim for the perfect. When imperfections sneak in, figure out why. Take corrective actions as required.

“The Quality Assurance team is there to test the system and generate a list of bugs. Developers then fix those, and, after passing QA’s tests, the product ships.” Not. First, in manufacturing QA is not quality control. QA is about defining the processes used, raw material fitness, and the like. Instead, quality control insures that a product meets a standard defined by the QA group. However, almost every software group conflates QA and QC, generally folding both operations into the single term QA. I have no reason to tilt against windmills so will use the term “QA.” Software engineering isn’t manufacturing; we don’t need to adopt their nomenclature. I believe that developers have the responsibility to deliver extremely high-quality code. Tiny teams may deliver directly to the customer, while larger groups have a separate QA operation. Regardless, we engineers must create the very best work products. QA’s role is to demonstrate the absence of defects. Sure, life is tough and software complex. Sometimes they will find problems. But that doesn’t absolve the engineers of their responsibility to strive for perfection. We engineers must take pride in our work, demonstrate exceptional craftsmanship, and constantly hone our tools, processes and techniques to achieve the highest quality. Wise managers will use the results of QA’s verification and validation work to audit the software engineering process. If they’re finding more than a few problems, that’s an indication that there’s something wrong in the firmware group. This is a quantitative result, something measureable, which can be monitored over time to see if the engineering team is getting better or worse. Three important principles are embodied in the notion of using QA’s results to audit the development team:Metrics – Engineering without numbers is not engineering – it’s art. Metrics hold us accountable and let us evaluate the process. Feedback – Every EE knows that feedback stabilizes electronic systems. It also stabilizes human systems. Use the results of any operation (in this case QA) to continuously improve the process. Filters – Software is tough to get right, which means we need to use as many filters as possible. The compiler identifies syntax errors, inspections other problems, test even more. QA is the last one. If the last filter is still finding problems that’s an indication something is wrong… or another filter is needed. QA should also be responsible for constructing and managing regression tests. That should be done outside of the engineering team since it’s a meta-operation that requires constant attention, an attention of the sort that is quite orthogonal to writing code. That may mean building and maintaining test jibs, continuous integration servers, and all of the infrastructure verification and validation demand. Aim for the perfect. When imperfections sneak in, figure out why. Take corrective actions as required.