VOOC Wiki

В статье описаны применения USB тестера, которые выходят за пределы “продвинутого вольтметра”. Опишем функции, которые применимы к Type C разъемам и протоколу Power Delivery.

USB тестеры выросли из специализированных вольтметров. Первые модели умели только показывать текущее напряжение и ток на линии VBUS, позже к этому добавилась статистика, графики и измерение пройденной энергии. Но это всё было про измеритель напряжения и тока.

Тестеры развивались, у них стали появляться новые функции, такие как обнаружение протоколов, поддерживаемых зарядным устройством, и функция триггера. Это были эвристические функции, которые работали по неведомым алгоритмам, иногда неточно, но у них было общее свойство: они выходили за рамки “продвинутого вольтметра” и делали тестер отдельным устройством, которое стало вести самостоятельную роль на шине USB.

Эта позиция усилилась в моменте, когда тестеры стали осваивать USB Type C. Этому способствовало то, что новая версия шины USB стала полноценнее, у неё вместо “если у нас чистая зарядка, то задействуем неиспользуемые линии D+/D-” появились линия CC для конфигурации соединений. Стандарт шины оперировал двумя с половиной ролями: источник source, потребитель sink и маркер plug (опустим второй маркер). И для продвинутых функций пришлось изобретать разнообразные хаки. Вот неполный список нюансов и компромиссов, с которыми столкнулись и которые решали производители тестеров:

• При подключении тестера ничего не происходит, потому что Type C не подает напряжение на VBUS, как делал USB A
• Переключатель PD или зажатие кнопки позволяет включать подключенный без кабеля прибор
• но это может внезапно выключить его в дальнейшем при подключении кабеля
• а еще использование переходника USB A - Type C может сжечь тестер
• Стандартного механизма чтения маркера кабеля просто нет в стандарте. Это может делать только зарядка в роли source
• А еще симметрия разъемов порождает вопрос, куда подключать тестер, к source или к sink
• А если у нас переходный тестер типа Witrn U3, то вообще нужно два кабеля
• и непонятно что получится, если оба кабеля с маркерами

Оказалось, что Type C - это вообще не старый добрый USB A. С одной стороны это стандарт, с другой стороны функции USB тестера в стандарт вписываются плохо.

Неочевидность комбинаций для подключения можно сократить, если каждую из функций рассматривать в контексте роли, которую выбирает тестер: source или sink. Это позволит понять то, как нужно подключать тестер для получения результата.

Первая нестандартная функция не является полноценной, она нужна как вспомогательная для других функций. Это функция эмуляции маркера. Она сразу накладывает множество ограничений на конфигурацию теста. Чтобы она гарантированно работала нужно, чтобы тестер разъемом “папа” втыкался в источник, а с другой стороны не было кабеля. Ну или хотя был кабель без маркера. А если уж между источником и тестером кабель, то он точно должен быть без маркера и возможно, что придется перевернуть разъем, втыкаемый в тестер (именно в тестер!). Но лучше использовать только первый вариант, с тестером, воткнутым папой в источник. Все остальные варианты зависят от тестера и не гарантируют успех.

Зачем эмулировать маркер? Чтобы при обнаружении протоколов (полноценного или для триггера) источник выдал максимум поддерживаемых профилей. Для обнаружения поддержки питанием EPR (240W) можно либо подключить тестер к источнику кабелем с EPR маркером, либо заранее записать в тестер EPR-маркер и выдать его источнику напрямую. Если вы используете триггер на 48V, то эмуляция позволит избежать наличия лишнего кабеля между источником и тестером, при этом 48V на внешнем кабеле - ваша ответственность. Можно придумать еще какие-то способы использования эмулятора, но при этом раскаленный кабель, воткнутый в тестер - это ваша проблема.

Сложно придумать дополнительные преимущества от эмуляции маркера, кроме указания мощности, поддерживаемой кабелем. Возможно, кому-то удастся подменить вендора кабеля на Oppo, чтобы получить ток, больший, чем 5A.

Сложность с маркером в том, что списка ситуаций, когда он работает нет. Возможно, что он включается только при детекте протоколов. Или наоборот, включается всегда. Это неизвестно, поэтому требует изучения для каждого тестера.

Термином триггер в контексте usb называют функцию устройства включать нужное напряжение (и максимальный ток) для тупых устройств. То есть тестер включает 9/12/20V, а тупое устройство потребляет напряжение с VBUS, при этом оно ничего не знает о power delivery.

Функцию триггера стали использовать в те годы, когда USB (еще A) стали активно использовать как зарядки в мире нестандартных зарядок. Переходники с Type C на разнообразные штекеры зарядок ноутбуков позволили перейти на компактные универсальные зарядки c экономией на размерах блоков питания. Сейчас актуальность функции триггера уменьшилась, но всё равно остаются ноутбуки, бритвы, паяльники и другие гаджеты с нестандартными разъемами, которые прекрасно заменяются на Type C с триггером. Мы будем говорить про тестеры в роли триггеров, хотя по моему мнению, автономные триггеры-переходники удобнее.

Функция триггера на PD работает просто: тестер получает список профилей, выводит его на экран. Пользователь выбирает профиль и на выходном разъеме получает необходимое напряжение. Мощный плюс триггера в тестере (если нужно) - это поддержка PPS: триггер поддержит любое напряжение и ток, а не только 9/12/20V.

Как говорилось в главе про маркер, функция триггера выбирает профили из предложенных источником. А источник при создании списка смотрит на маркер, который может быть как маркером кабеля до тестера, так и эмулироваться тестером. Поэтому, если у вас триггер не включает профили с мощностью больше, чем 65/100/240W, то стоит обеспечить источнику кабель или симуляцию правильного маркера.

Подключение тупого потребителя должно быть тупым. Если вы используете для потребителя готовый разъем Type C, то стоит убедиться, что у него нет распаянного pull-down резистора между CC и GND. Резистор вместе с резистором в тестере изменит результирующее сопротивление и источник просто не воспримет комбинацию тестера и кабеля как готовое устройство. Поэтому потребитель должен задействовать только линии VBUS/GND.

Что делает тестер в роли триггера? Очень просто. Он выставляет pull-down резистор на CC1 (в этом месте не нужно варьировать имитацию CC) и после получения профилей питания выбирает требуемый профиль. Интерфейс на экранчике тестера просто посылает команду смены профиля источнику. То есть тестер работает в роли потребителя sink, поэтому подключать других “умных” потребителей нельзя.

С функцией триггера связана проблема интерфейса тестеров: не все тестеры умеют держать параметры протокола после выхода с экрана. KM003C такое не умеет (хотя может через команды с декстопа), Ryken X3 предлагает при выходе со страницы опции Close (выключить)/Run BG (поддерживать параметры VBUS в фоне). Это стоит изучить для того, чтобы пользоваться тестером после запуска триггера (если такое нужно).

Если сузить тему обнаружения протоколов до Power Delivery, то она становится абсолютно аналогичной тому, что мы обсуждали в главе про триггеры. Главное - это обеспечить источник максимально мощным маркером (даже если нет реального кабеля и возможности включить 240W).

Поскольку обнаружение протоколов не ограничивается PD, то при сканировании может возникнуть отключение напряжения на VBUS. Некоторые тестеры готовы к такому и правильно обрабатывают перезагрузку, но лучше привыкнуть к тому, что обнаружение протоколов лучше делать при включенном питании в разъеме HID, причем туда подается напряжение от другого источника, не того который мы изучаем (или другие разъемы изучаемого источника).

Чтобы не было скучно, можно отдельно сказать пару слов про расширения PD типа MiPD и SVOOC. К сожалению это знание сложно где-то прочитать, поэтому будьте готовы к тому, что для обнаружения поддержки проприетарщины типа MiPD стоит отдельно запустить обнаружение с тестером около зарядки (и разъемом USB A) и отдельно с тестером у другого конца кабеля. Ryken X3 на родном кабеле (с пятым контактом в разъеме USB A) показывает MiPD до 120W на стороне Type C. А как ведет себя ваш тестер - нужно проверять.

В качестве развлечения. Если хочется сжечь что-то дорогое, то можно подключить выход тестера к какому-нибудь дорогому гаджету. Он сгорит от высокого напряжения. Утонченный способ сжигания гаджетов описан тут .

Подытожим. Детект протоколов - это вырожденная функция триггера “ни для кого”. Запитываем тестер от HID, включаем в источник и запускаем обнаружение. Остальное усугубит ситуацию и повысит шансы что-то сжечь.

Про маркеры я написал отдельную статью, поэтому здесь ограничимся описанием того, как обнаружение маркера вписывается в общую концепцию.

Чтение маркера - это самая нестандартная операция, из-за того, что маркер стандартно может читать только источник. Поэтому чтение маркера сопряжено с нестандартной конфигурацией тестера и прочих устройств:

• Роль source исполняет тестер, поэтому настоящий источник отлучают от шины (линии CC) адаптером
• Или вообще подают питание только на HID (но есть кабели, маркеры которых не могут стартовать без VBUS)
• На шине отсутствует sink, мы общаемся с маркером, надеясь, что ему достаточно напряжения на VCONN
• И иногда даже придётся покрутить разъем

Читайте статью, процесс чтения маркера оказался хитрее, чем обнаружение протоколов. Вообще, роль источника требует следования множеству правил, поэтому на эту функцию есть много нареканий.

Про измерение сопротивления посоветую свою же статью, а здесь замечу, что, несмотря на разъемы Type C, адаптеры измерения сопротивления используют только линии USB 2.0 и рекомендуют подключать тестер через адаптер USB A, что сразу убирает всевозможные хитрости современных протоколов. Поэтому измерение сопротивления кабелей никак не затрагивает линии Type C и это хорошо!

Мы рассмотрели несколько способов использования USB тестера, которые завязаны на особенности стандарта Type C. Эти функции требуют необычных способов подключения источников или кабелей к тестеру, которые становятся понятнее, если осознать роль тестера в конкретном измерении.

Надеюсь, что было полезно! Удачи с опытами с кабелями и зарядками!