При переходе от прототипа к серии каждый миллиметр на плате и каждый цент в BOM‑листе имеют значение. В этой статье я как ведущий инженер покажу на реальном примере, почему бездумное копирование референсных схем PoE+/HiPoE/UPoE приводит к установке лишних компонентов, и дам решение, как выкинуть лишний (третий) трансформатор из сигнальной линии без нарушения стандартов IEEE 802.3
Далее речь пойдет про схемотехнику и разработку девайсов питающихся по стандартам IEEE 802.3af, IEEE 802.3at, IEEE 802.3bt и скорее всего ко всему остальному набору стандартов PoE которые существуют.
Проблема в том, что большинство разработчиков схемотехников используют референс дизайны как отправную точку, а иногда и полностью копируют референс дизайн, не погружаясь в физику процесса. В таком случае на этапе отладки схема может работать, но при переходе в серию может возникнуть удивительно высокий процент брака.
Конкретно в этом случае у нас был лишний сигнальный трансформатор на стороне девайса, нашей IP камеры. Исторически сложилось, что камера устройство проектировалось без технологии питания PoE вообще, и соответственно на основной материнской плате с PHY→RGMII уже должен быть трансформатор. Со временем заказчики начали спрашивать про PoE+ (25Вт) и HiPoE (65Вт), поэтому нужно было внедрять технологию на уже отработанную плату.
И если взять любой референс дизайн, по изучать материалы по теме, то быстро обнаруживается что питание снимается именно со средних выводов трансформатора. Смотрим на картинку выше — это фиолетовая и желтая линии на блоке PSE (power source) и PD (Power device).
Само собой при отработанной, поставленной в серию, произведенной и положенной на склад дорогой партии материнских плат, в голову приходит мысль сделать отдельную плату с просто еще одним трансформатором как во всех референс дизайнах. Да, на мат плате не было предусмотрено дополнительного коннектора со средних выводов трансформаторов.
Получается вот такая схема:
Стандарт IEEE 802.3, и сам стандарт Ethernet очень устойчив к целостности сигнала, и на 8 из 10 первых сэмплов, все работало — и flyback преобразователь на 65Вт и 1Гбит ethernet, 2 платы мы скинули на банальный брак компонентов.
У нас были жесткие сроки по отправке устройств клиенту и нам необходимо было срочно произвести 100 таких плат, и что оказалось неожиданным — статистика брака сохранилась, и даже увеличилась — из 100шт, на 30 платах была либо скорость только в 100Мбит, либо линка с девайсом не было вообще, даже с коротким кабелем.
Небольшая ремарка — сигнальный трансформатор был рассчитан на стандарт UltraPoE.
В процессе исследования проблемы было разобрано несколько китайских девайсов и изучено некоторое количество материалов в интернете.
На камерах с PoE+ китайцы делают абсолютно так же — то есть просто добавляют плату с дополнительным трансформатором и оставляют трансформатор на основной плате. Все найденные референс дизайны так же имеют этот самый трансформатор. Только в референсе известного Техасского бренда было упомянуто, что после трансформатора должен стоять преобразователь PHY, а не трасса к следующему трансформатору.
По поводу китайцев и стандарта PoE+, я предполагаю, что при токах при 25Вт сигнальный трансформатор не доходит до уровня потенциального насыщения катушек и поэтому сигнал проходит достаточно чистым. Но когда речь про 65Вт и выше — подозреваю, что насыщение трансформатора играет роль.
Таким образом схема работает на грани, и погрешность изготовления компонентов в нашем случае играет критическую роль.
К сожалению у нас нет осциллографа которым мы могли посмотреть на глазковую диаграмму. Поэтому картинок сигнала здесь так и не будет.
Пообщавшись с ИИ и покопавшись стандарте — стало очевидно, лишний трансформатор нужно убирать, стандарт не предусматривает такого подключения.
Задача получается следующая — мне нужно снять постоянное напряжение 48–57В с четырех дифференциальных 100омных линий, не повлияв на сигнал частотой 125МГц, и на низкочастотные служебные команды.
В целом если работаете с ВЧ электроникой задача решаемая — ВЧ сигнала идет по пути наименьшей индуктивности, а для постоянного напряжения и тока высокая индуктивность — как обычное КЗ, только с более плавным переходным процессом. То есть можно просто повторить одну часть обмотки трансформатора, поставив две катушки на каждую диф пару.
Либо альтернатива — использовать такой компонент как Common Mode Choke, только подключить катушки в встречном направлении.
Затем я наткнулся на технологию PoDL — Power over Data Line, и оказывается подобное уже реализовано и мне нужен компонент DMI — Differential Mode Inductor
Оказалось на рынке таких компонентов буквально штучно от компании TDK
Конечно, можно сказать, что есть разница между скоростями, и между применением в этих технологиях. Но моё любопытство провести эксперимент не покидало.
Здесь остается еще один для меня открытый вопрос — стандарт IE802.3 накладывает определенные ограничения на величину индуктивности катушек трансформатора, 250–350uH. На первый взгляд — можно действительно подобрать обычный CMC и подключить во встречном направлении, но их индуктивность даже близко недотягивает до таких величин, а при использовании индуктивности порядка 20uH, гарантировано будут проблемы с низкочастотными сигналами протокола.
DMI от TDK гарантируют индуктивность на уровне 250uH на каждой катушке — что удовлетворяет стандарту. Во всей этой ситуации мне только крайне не нравится привязка к одному бренду и паре парт номеров.
Была разработана и произведена очень простая плата с двумя разъемами и четырьмя компонентами, чисто проверить идею.
Как результат получилась вот такая схема вместо лишнего трансформатор, которая работает и уже целый месяц тестируется под нагрузкой.
Некоторое пояснение — для 1Гбит (128Мгц) сигнала эти катушки просто не существуют, точнее пути через катушки просто не существуют, для ВЧ сигнала это как огромный резистор для постоянного тока. И наоборот — для постоянного напряжения на диф парах это резисторы номиналом 0,25–2,25 Ома (Параметр Rdc). Даже при полной нагрузке в HiPoE (65Вт) при комнатной температуре эти компоненты имеют такую же температуру как окружающая среда.
Таким образом, не смотря на изначально не заложенную технологию, оказалось, что внедрить ее простым способом не получиться, а данное решение пришлось уже обдумывать на сделанных ошибках. Так как решение не классическое, возможно будут еще подводные камни с которыми мы столкнемся, хотелось бы обсудить потенциальные проблемы с теми кто сталкивался с подобной проблемой.