Потребление тока: Schischek Explosionproof | EEX | Ex protection according ATEX

Содержание

Часто задаваемые вопросы – Schneider Electric

{"searchBar":{"inputPlaceholder":"Выполните поиск по ключевому слову или задайте вопрос","searchBtn":"Поиск","error":"Введите ключевое слово для поиска"}}

ATV212: ошибка «Р»

Это не ошибка ПЧ, а предупреждение (alarm): «Перенапряжение на ЗПТ». Проверьте входное напряжение — повышенное напряжение вызывает это предупреждение. Другой причиной может быть малое время…

Какая Modbus адресация интеллектуального реле Zelio Logic?

При использовании коммуникационного модуля SR3MBU01BD с интеллектуальным реле Zelio Logic имеется возможность подключения реле к шине Modbus (протокол Modbus RTU). В этом случае адресация реле будет…

Какое программное обеспечение используется для программирования…

Для программирования контроллеров серии Modicon M168 используется программа SoHVAC. Программа SoHVAC бесплатная и её можно скачать с нашего сайта: www.schneider-electric.com

Какие ПЛК Modicon от Schneider Electric поддерживают горячее…

Есть три линейки ПЛК с функцией горячего резерва (Hot Stanby): Modicon Premium — время переключения состовляет порядка 500 мс. (в настоящий момент сняты с продаж) Modicon Quantum — время переключения…

Часто задаваемые вопросы о популярных видеороликахПопулярные видеоролики

Обновление прошивки (Firmware) модулей BMENOC03xx

Как настроить Sepam 20?

ATV12 Настройка реверса

Подробнее о часто задаваемых вопросах по нашим общим знаниямОбщие знания

Обязательно к прочтению при подборе аналогов Шнейдер Электрик

Парт-номер (он же референс, он же артикул, он же каталожный номер) продукции Шнейднер Электрик, подобраной на замену продукции, снятой с производства, либо на замену продукции другого производителя,…

Каков объём элегаза в оборудовании Schneider Electric?

В ыключатели: для SF2 максимальное количество составляет 721г, для LF – 614г, для SF1 – 337г, для LBSkit — 210г, для Rollarc – 107г. Распределительные ячейки: для GHA максимальное количество…

Глоссарий — словарь технических терминов APC by Schneider Electric

Прилагаемый словарь-глоссарий содержит список часто используемых англоязычных терминов по марке APC компании Schneider Electric в области систем бесперебойного питания и решений для серверных комнат,…

Что такое класс коммутаций емкостного тока С1 и С2 ?

С1 и С2 — это классы вероятности возникновения вторичного перекрытия. С1 — вероятность маленькая, С2 — очень маленькая .

Измеряем потребление батарейки на мобильных устройствах. Эксперимент в Яндексе / Хабр

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

Производители как железа, так и софта, стараются решить эту проблему. Для Яндекса она тоже актуальна, потому что наши сервисы — это то, что должно быть под рукой у человека в любой момент. Мы по-разному над этим работаем и в рамках эксперимента создали устройство для измерения тока, который потребляется телефоном с батарейки. Теперь мы умеем мерить мгновенные значения тока с батарейки телефона (Nexus, iPhone и др.) в миллиамперах 500 раз в секунду, сохранять эту метрику на диск и считать по ней среднее потребление.

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

Несколько месяцев назад, когда мы начинали прикручивать нагрузочное тестирование телефонов к Яндекс.Танку (это наш opensource инструмент для тестирования производительности), мы столкнулись с тем, что одну из самых важных метрик — потребление тока с батарейки — мы не можем замерить достоверно, а на некоторых телефонах не можем замерить вообще. Например, вот как выглядит график потребления тока на iPhone, полученный стандартными средствами от Apple:

Все три запуска теста значение потребления вообще не изменялось и было равно 1/20. Удивляет использованная единица измерения — 1/20 означает, что если телефон дальше будет работать с тем же энергопотреблением, то сядет он за 20 часов. То есть, метрика получается очень неточная и не очень интерпретируемая. Кроме того, цифры в сыром виде получить нельзя, только разве что скриншот сделать и приложить его к тикету.

С Android девайсами ситуация выглядит лучше, но все равно далека от идеала. Ток замерять можно, читая из /proc/… циферку, но лучше не делать это слишком часто — опросом значения можно просадить производительность телефона и испортить тесты. На разных девайсах циферка находится в разных местах файловой системы. На части Android телефонов вообще отсутствует железка, измеряющая ток, поэтому на них не получится программными средствами снимать потребление. На Nexus, которые мы взяли как reference, значение в /proc меняется раз в 20 секунд.

В общем, мы решили попробовать измерять потребление хардверно и таким образом убить всех зайцев разом: так можно мерить вообще на всех девайсах, включая ноутбуки и холодильники. Мы знали о существовании Power Monitor, но цена устройства (примерно $800 за штуку, а на каждый телефон потребуется свой девайс), и его несовместимость с Linux (а значит, и сложности с автоматизацией), заставили задуматься о своем велосипеде. Аналогичная ситуация наблюдается с осциллографами и другими измерительными устройствами общего назначения на рынке — покупать дорого, автоматизировать сложно.

Существует еще проект BattOr, по описанию это примерно то, что мы хотим. Сам я не пробовал связаться с авторами, но коллеги говорят, что команду купил Google и с тех пор от них ничего не слышно и на почту они не отвечают. Совпадение? =)

Для начала, в качестве proof-of-concept, мы собрали схему с шунтом, аналогичную представленной в этой статье. Ток мы измеряли в разрыве провода USB. Поскольку значение силы тока ожидалось небольшое, до 500 мА, пришлось усиливать напряжение с помощью инструментального усилителя, а не снимать его напрямую с шунта ардуинкой.

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

Как известно, все, чему нас учили на уроках физики и электротехники, — ложь, никаких электронов не существует, а устройства работают на белом дыме. И если этот белый дым выходит, то устройство работать перестает. В очередном эксперименте белый дым вышел из Arduino и мы ее потеряли. Оказалось, что между “0” на входе нашего блока питания и “-“ на его выходе — 88 вольт переменного напряжения. После еще нескольких экспериментов с разными БП мы поняли, что не все они одинаково хороши, но есть такие, которые нам подходят. И мы стали использовать эти подходящие. Также мы решили больше не использовать схему с шунтом и инструментальным усилителем и вместо этого взять готовый модуль измерения тока к Arduino на базе MAX471, которая по сути то же самое, только в виде микросхемы. Еще мы рассматривали вариант на базе датчика Холла (ACS712), но, изучив документацию на этот чип, увидели, что он сильно шумит и решили даже не пробовать.

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

Чтобы вернуть модифицированный таким образом iPhone (или другое устройство) в собранное состояние, мы сверлим корпус и выводим два проводка.

Вот такая коробочка у нас получилась в результате. Правда, в метро ее лучше не возить, телефон, провода, вот это все… могут не понять =)

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

Для получения релевантного результата теста при прямых замерах батарейки этим устройством достаточно пяти минут. Если же замерять «как раньше», то есть смотреть на скорость уменьшения % заряда батареи — то требуется 6-8 часов, плюс не забывайте про человеческий фактор. То есть, время теста сократили с 8 часов до 5 минут: почти в 100 раз.

Текущий разброс результатов замера ± 15%. Это не идеал и надо погрешность уменьшать. Однако, теперь доверие к результату повысилось за счёт исключения человеческого фактора и существенно меньшего времени на 1 замер. Достаточно выполнить за полдня много-много замеров и отсечь результаты, пострадавшие от внезапных всплесков непонятной активности на телефоне.

Стало возможным кросс-платформенное, и кросс-девайсное сравнение значений. Единица измерения — mA, а не «скорость уменьшения процентов заряда», которая зависит от платформы, объёма батареи, «свежести» батареи, не говоря уже про запущенные процессы… Сравнить только mA при одном и том же запущенном Я.Сервисе на Andoird и на iOS — нельзя. Надо добавить поправочный коэффициент — сколько жрёт каждая платформа, без Я.Сервиса. Но, это опять-таки вопрос на пол дня замеров (и это с кофе-поболтать).

Чтобы собирать данные от Arduino (а она просто 500 раз в секунду шлет их по USB), мы написали простенькую читалку. На Python возникли проблемы с повторным открытием устройства на чтение — во второй раз данные уже не читались. Мы не стали разбираться и просто переписали то же самое на Golang — после этого все заработало.

Тут нас ждали еще небольшие грабли: в буфере устройства с предыдущего запуска остаются старые данные. Поэтому сейчас мы просто отбрасываем первые 500 измерений (1 секунда). Затем собранные в .csv данные обрабатываем скриптом на Python (в котором используются Pandas и Seaborn) и получаем графики, которые вы видели в начале статьи.

Если вам интересны исходники читалки, прошивка и код для обработки данных — могу поделиться, пишите в личку.

Объяснение энергопотребления

  • Ресурсы:
  • Умный дом и автоматизация зданий
  • Беспроводное подключение для Интернета вещей
  • Промышленный Интернет вещей

Ресурсы ▼

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

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

  Посетите нашу страницу ресурсов, посвященную беспроводному подключению

Потребляемая мощность часто не имеет значения

Обычно потребление энергии, измеряемое в джоулях (обычно в микроджоулях, мкДж), определяет, сколько энергии фактически уходит из батареи для завершения работы. конкретная задача. Энергопотребление будет интегралом от потребляемой мощности за время, необходимое для выполнения операции. Опять же, со статическими сигналами это будет простое умножение потребляемой мощности и времени, но с переменными сигналами это потребует более сложного анализа.

Потребляемая мощность наиболее актуальна при использовании источника питания с ограничением по току, например, литий-ионной батарейки типа «таблетка». Популярные в небольших гаджетах с датчиками и интеллектуальных устройствах, эти батареи могут обеспечивать пиковый ток всего в несколько мА без повреждения. Пытаясь нарисовать более высокий пик, вы рискуете навсегда уменьшить емкость батареи, что также может повлиять на выходное напряжение. Пиковое энергопотребление не будет проблемой для приложений, где ток достаточен для поддержки пика.

Подробнее: Важность среднего энергопотребления для срока службы батареи

Дьявол кроется в деталях

В технических описаниях продуктов обычно указывается энергопотребление для различных модулей и условия работы MCU (блока микроконтроллера). Цифры легко измерить, и они документировались таким образом на протяжении десятилетий. Но только в последнее время мы начинаем видеть цифры энергопотребления устройств.

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

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

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

Низкое энергопотребление благодаря цифровым вентилям

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

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

Реальный пример

Внутри семейства микросхем Nordic Semiconductor nRF52 и nRF53 функциональные блоки, такие как регуляторы, генераторы и цифровая логика, запускаются и останавливаются в фоновом режиме по мере необходимости. Потребляемая мощность постоянно меняется, поэтому нет «статического» показателя для измерения.

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

Сложность прогнозирования энергопотребления возрастает, но в то же время значительно повышается энергоэффективность.

Одним из способов оценки энергопотребления этих систем является создание небольших программ для тестирования, а затем их профилирование с помощью подходящих инструментов для создания модели, соответствующей вашим требованиям. Nordic Semiconductor Online Power Profiler использует данные, собранные в результате реальных измерений для работы радио, а затем извлекает из них данные для оценки энергопотребления.

Вот пример показаний такого измерения nRF52832 (щелкните, чтобы увеличить)

 

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

 

Эта статья была впервые опубликована в октябре 2017 года

 

 

Темы:

Bluetooth с низким энергопотреблением

Автор: Пол Кастнес

Пол Кастнес присоединился к Nordic в марте 2015 года. Он имеет 18-летний опыт работы на рынке встроенных систем, работая в нескольких областях. Это включает в себя проектирование ИС, проверку системы, производственные испытания и спецификацию устройства на заводе. Он провел 6 лет в качестве менеджера по работе с ключевыми клиентами в отделе продаж для азиатского рынка в Токио, Япония. В последние годы он руководил программами обучения по всему миру, а также обеспечивал поддержку ключевых клиентов в регионе EMEA.
Сейчас его основное внимание уделяется обучению и пользовательскому опыту, уделяя особое внимание простоте использования всех элементов, участвующих в процессе проектирования подключенных устройств.

Поиск в блоге

Поиск

Блог Get Connected

Этот блог предназначен для тех, кто впервые знакомится с подключенным миром Интернета вещей (IoT), независимо от того, являетесь ли вы старшим руководителем, занимаетесь разработкой продуктов или просто любопытствуете.

Наша цель — информировать вас, держать вас в курсе и помогать вам понимать возможности и проблемы IoT для вашей отрасли.

Если вы разработчик, вы можете ознакомиться с нашими блогами и руководствами для разработчиков в DevZone 9.0013

Посетите www.nordicsemi.com

Последние сообщения

Темы

Потребляемый ток

I ON_IDLE1

Система включена, 0 КБ ОЗУ приложения, пробуждение по любому событию

 1,3 UA
I ON_IDLE1,LDO

Система включена, 0 КБ ОЗУ приложения, пробуждение по любому событию, регулятор = LDO

 3. 3 UA
I ON_IDLE2

Система включена, пробуждение по любому событию

 1,3 UA
I ON_IDLE2,LDO

Система ВКЛ, пробуждение по любому событию, регулятор = LDO

 3. 4 UA
I ON_IDLE3

Система включена, пробуждение по любому событию, включен компаратор сбоя питания

 1,3 UA
I ON_IDLE3,128 МГц

Система включена, пробуждение по любому событию, включен компаратор сбоя питания, часы = HFINT128M

 785 UA
I ON_IDLE4

Система включена, пробуждение по входу GPIOTE (режим событий, LATENCY=LowLatency)

 48 UA
I ON_IDLE4_LP

Система включена, пробуждение по входу GPIOTE (режим событий, LATENCY=LowPower)

 1,3 UA
I ON_IDLE5

Система включена, пробуждение по событию GPIOTE PORT

 1,3 UA
I ON_IDLE6

Система включена, 0 КБ ОЗУ приложения, пробуждение по RTC (запуск от часов LFXO)

 1,5 UA
I ON_IDLE7

Система включена, пробуждение по часам RTC (работает от часов LFXO)

 1,5 UA
I ON_IDLE8

Система включена, 0 КБ ОЗУ приложения, пробуждение по RTC (работает от часов LFXO), питание 5 В на VDDH, выход VREGH = 3,3 В

 1,7 UA
I ON_IDLE7

Система включена, сетевое ОЗУ 0 КБ, пробуждение по сети RTC (работает с часов LFXO)

 1,5 UA
I ON_IDLE8

Система включена, сетевое ОЗУ 64 КБ, пробуждение по сети RTC (запуск от часов LFXO)

 1,7 UA
I ON_IDLE9

Система включена, 0 КБ ОЗУ приложения, пробуждение по RTC (запуск от часов LFRC)

 2. 1 UA
I ON_IDLE10

Оба ядра в системе включены, пробуждаются при любом событии. VREQH=Отключено.

 1,3 UA
I ON_IDLE10_VREQH

Оба ядра в системе включены, пробуждаются при любом событии. VREQH=Включено.

 1,4 UA
I ВЫКЛ0

Система выключена, 0 КБ ОЗУ приложения, пробуждение при сбросе

 1,0 UA
I OFF0,LDO

Система выключена, 0 КБ ОЗУ приложения, пробуждение при перезагрузке; регулятор = LDO

 1,4 UA
I ВЫКЛ1

Система выключена, 0 КБ ОЗУ приложения, пробуждение по LPCOMP

 0,9 UA
I ВЫКЛ2

Система выключена, пробуждение при сбросе

 0,9 UA
I ВЫКЛ3

Система выключена, 0 КБ ОЗУ приложения, пробуждение при сбросе, питание 5 В на VDDH, выход VREGH = 3,3 В

 1.

Top