Differences

This shows you the differences between two versions of the page.

--- pd_connect [2026/02/27 09:53] – created gadmin
+++ pd_connect [2026/02/27 19:00] (current) – gadmin
@@ Line 1: / Line 1: @@
-= Введение =
+=== Введение ===
-Обсуждая процессы чтения маркера и измерения сопротивления кабелей, я обнаружил, что знание процесса подключения устройств к зарядке кабелем Type C относится к очень мифологизированному процессу. Поэтому и решил написать статью, где подробно описать, что происходит на шине во время подключения устройства.
+Обсуждая процессы чтения маркера и измерения сопротивления кабелей, я обнаружил, что понимание процесса подключения устройств к зарядке кабелем Type C покрыто мифами и заблуждениями. Поэтому и решил написать статью, где подробно описать, что происходит на шине во время подключения устройства.
-= Приборы и материалы =
+=== Приборы и материалы ===
+В качестве продвинутого вольтметра использовался тесте KM003C с десктопной программой. Она позволяет записывать показания напряжения и тока на VBUS, а также напряжения на CC1, CC2, D+ и D- с последующим анализом графиков и их экспортом. Сразу замечу, что показания я снимал дважды, один раз в режиме "Data Recorder" с точностью 1000 точек и второй раз в режиме "PD analyzer", там точность меньше раз в 20, зато есть привязка событий PD к графику напряжений.
+В качестве источника (source) выступал павербанк Ugreen с портом на 100W (нужна не мощность, а чтобы он запросил маркер) и кабель с полной разводкой и маркером на 100W. Потребителем выступал телефон Pixel 6A (с ним всё просто и наглядно: попросил 9V, получил и пошел заряжаться).
-= Опыт =
+Советую графики открывать в отдельной закладке, я их сохранял с шириной 1920 px, чтобы можно было видеть детали.
+Вопрос на понимание структуры кабеля: куда подключать тестер? Правильный ответ: между кабелем и павербанком. Потому что при подключении со стороны потребителя мы не увидим активности на линии VCONN, поскольку линия VCONN ничего не передаёт на другой разъем:
+{{ :usb-type-c-equivalent-circuit_0.webp |}}
+=== Опыт ===
 В дальнейшем описании будем рассматривать следующие простые действия.
   * Подключаем тестер к павербанку
@@ Line 16: / Line 23: @@
   * Выключаем запись
-= Вольты и амперы =
+Подключение кабеля с двух сторон разъема покажет отличие в напряжениях на линиях CC1 и CC2.
+=== Вольты и амперы ===
 Начнем с простого вида: напряжение и ток на VBUS.
 {{:2twist_00.png?1024|}}
 Выглядит просто. Пока кабель отключен, на VBUS ничего не подаётся. Подключаем кабель, аналоговое согласование резисторами проходит и источник подаёт напряжение 5V. После этого телефон читает профили источника и выбирает 9V, которые ему источники предоставляет. Процесс подключения небыстрый, может длиться до 200 ms. А процесс отключения вообще теплый и аналоговый, видно, как плавно падает напряжение.
 Теперь добавим на график напряжение на CC1 и CC2:
 {{:2twist_01.png?1024|}}
+Стало интереснее и сложнее. Начнём с середины, с того, что у нас при подключенном кабеле. А там на одном CCx 3.2V, а на CCy 1.7V. Напряжение 1.7V соответствует pull-up резистору 10 kOhm у источника, то есть павербанк обещает до 5V 3A на VBUS. То есть во время первого коннекта CC был на CC2 (смотри легенду в верхнем левом углу), а во время второго на CC1. А напряжение 3.2V указывает на то, что маркер кабеля запросил питание на втором контакте (последовательно CC1 и CC2) и получил низкое напряжение (низкое в смысле того, что оно меньше 5V и может быть использовано микросхемой напрямую, без преобразователя), которое и держал всё время, пока телефон был подключен.
+Приведу для справки значения pull-up сопротивлений для разных источников. Обратите внимание, что в таблице приведены три варианта реализации pull-up на источнике: через источник тока и через сопротивления для двух источников напряжения.
+{{:2twist_pd_08.png?1024|}}
+Вторая таблица - это диапазоны напряжений и их интерпретация sinkом (если вдруг ему важен ток, который может дать источник на 5V). Поскольку сопротивление кабеля ничтожно по сравнению с резисторами Rd и Rp, то эти диапазоны применимы к двум сторонам кабеля.
+{{:2twist_pd_09.png?1024|}}
+Чтобы не заморачиваться с разными источниками можно запомнить общий диапазон: 0.2-2V - эта линия CCx станет CC. От 3V - VCONN.
+А теперь увеличим фрагмент с подключением кабеля.
+{{:2twist_02.png?1024|}}
+До 3.183 видны пики, которые обозначают что источник подаёт на CC1 и CC2 напряжение и смотрит, пошел ли ток (ток на CC1/CC2 смотреть мы не можем, поэтому догадываемся). Пики длительностью 40-50ms и отсутствие падения напряжения говорит о том, что устройства с pull-down резистором на линии нет.
+Подключение второй стороны обнаруживается в 3.404, когда появляется pull-down резистор телефона и напряжение 1.7V на CC2 указывает на коннект устройства. И дальше на CC2 (его уже можно называть CC) держится напряжение, на котором видны всплески модуляции пакетов PD.
+А что со второй линией CC1? Через 150ms после подключения там устанавливается напряжение VCONN для питания маркера, то есть источник увидел резистор rA на VCONN и выдал напряжение.
+Следующая точка - через 550ms от коннекта источник подаёт 5V на VBUS. Управление напряжением на VBUS и VCONN происходят независимо, VBUS можно поднимать сразу же, а VCONN может подниматься после обнаружения резистора на VCONN. Зачем нужен аналоговый способ (с помощью резисторов) для подачи напряжения на VBUS? Для а) потребителей без собственного питания, б) для простых устройств, для которых отдельный чип управления PD - это оверкилл и в) для запуска устройст с пустой батареей. А вот почему стандарт USB решил, что не нужно сразу подавать 5V на VBUS - это другой вопрос с непростым ответом.
+И последние интересные точки на графике - это общение по протоколу Power Delivery для переключения VBUS на 9V. Колебания на линии CC (CC2) незадолго до поднятия напряжения - это и есть взаимодействие PD.
+Перечислим увиденные события
+  * Обнаружение коннекта и выбор линии CC
+  * Обнаружение запроса на питание маркера и подача напряжения на VCONN. Этот пункт опционален, поскольку кабель может быть без маркера. А еще бывает кабель с сопротивлением Ra, но без маркера.
+  * Подача 5V на VBUS (этт и предыдущий пункты независимы и могут случиться в любом порядке)
+  * Переключение на общение протоколом PD по линии CC
+=== А теперь Power Delivery ===
+Еще на шаг глубже в детали протокола, теперь посмотрим на взаимодействие по протоколу PD. Как я писал выше, экран PD Analyzer тестера позволяет видеть пакеты, но к сожалению имеет низкую дискретность измерения напряжений. Поэтому мы будем рассматривать другой замер:
+{{:2twist_pd_04.png?1024|}}
+Видите отличия? Из-за меньшего числа точек мониторинг в неподключенном состоянии схлопнулся до острых пиков. Второй отличие уже в характере подключения: на VBUS и VCONN напряжение подаётся одновременно, так что нужно всегда понимать, что подача двух напряжений асинхронна и независима.
+Но самое ценное на этом графике, что компенсирует все шероховатости - это возможность увидеть на графике временные точки событий power delivery. Видите две вертикальные черты? Первая - это событие "Attach: CC1" (мы помним, что CC становится та линия, где напряжение будет 1.7V), а второе, подписанное как "Vendor defined" - это запрос маркера у кабеля. Вместо убранных модуляций на CC мы теперь напрямую видим запросы по линии CC.
+{{:2twist_pd_05.png?1024|}}
+Протокол PD включается не сразу, в стандарте заданы таймауты после выставления напряжения на VBUS и VCONN. А вот сами транзакции на шине происходят довольно оперативно. Первый блок обмена данными - это сообщения 2-12, сразу перед повышением напряжения до 9V. Там всё просто:
+  - (2) Источник запрашивает у кабеля маркер командой Discover Identity (направление и контрагенты видны в столбце Direction)
+  - (4) Маркер возвращает в ответе данные о кабеле
+  - (6) Источник формирует список профилей в пакете Source Cap
+  - (8) Потребитель запрашивает (Request) профиль 9V 2.2A
+  - (10) Источник подтвержает запрос (Accept) и переключает напржение на VBUS
+  - После Acceptа мы видим рост напряждения на VBUS
+  - (12) После роста напряжения источник рапортует о включении нового профиля (PS RDY). Все предыдущие команды занимали порядка 5-10 ms, а эта пошла через 200 ms после Accept
+Оставшиеся команды - это запросы возможностей источника как потребителя (павербанк в своих возможностях указал про то, что он  может менять роль, вот телефон и поинтересовался). Но нам это уже не так интересно.
+Приведем пару экранов с расшифровкой пакетов. Первый экран - это пакет Source Cap со списком профилей:
+{{:2twist_pd_06.png?1024|}}
+Второй экран - это ответ маркера на Discover Identity, видны все поля из маркера
+{{:2twist_pd_07.png?1024|}}