Датчики и АЦП — для чайников-практиков (2/3) :: датчики и счетчики событий

Продолжаем тему про «датчики и АЦП — для чайников практиков». Начало тут, конец тут. Продолжаем изложение. Тут мы рассмотрим вопрос про датчики и счетчики событий.
Также есть полная PDF-версия статьи.

Оглавление:
  1. Пару слов про систему управления
  2. Немного о терминах — в том числе о документации
  3. Специфика цифровой обработки информации с датчиков
  4. Какие датчики и зачем
  5. Датчики событий и их характеристики
  6. Счетчики событий
    • Окна интегрирования
    • Характеристики

    • Часы реального времени
  7. Аналоговые датчики
  8. Вкратце об АЦП

Датчики событий

Самый распространенный случай такого датчика — это банальная кнопка. Вот уж действительно да/нет — нажали или нет???
Кнопки бывают разные — емкостные, резистивные, еще какие-нибудь. Но факт в том, что у всех у них результат один: состояние «нажатия нет», состояние «нажатие есть», состояние «нажатия нет… есть… есть… нет… нет… нет… есть… нет» и состояние «бобик сдох».
Состояния датчика событияПервая зона — уверенное «нет». Палец от кнопки еще далек, емкость/сопротивление (или просто «параметр») достаточно мал. Палец приближается к кнопке, но расстояние еще достаточно далеко, и параметр достаточно мал.
Но вот, палец подошел достаточно близко, и параметр подходит к границе, когда датчик начинает говорить «да». Если это емкостной датчик, то емкость уже близка границе, разделяющей «да» и «нет». Допустим, палец замер на очень близком расстоянии от такого датчика (в пределах миллиметра). Допустим, замер, как вкопанный. Но температура воздуха непостоянна, на пальце могут быть волосинки, которые наэлектризованы… А по емкостному датчику гуляют всякие токи… Микроскопические, но они слегка меняют емкость, и она иногда выдает «да», хотя должна бы говорить «нет». Наступает дребезг контактов.
Слава Богу, палец устал висеть в воздухе и таки ткнул кнопку. Все, параметр перешел граничное значение и попал в зону уверенного «да».
Ну а коли палец оказался варварским и давит все сильнее и сильнее, то датчик рано или поздно сломается. Что нам выдаст кнопка — да или нет? Это знает лишь разработчик, и то он не всегда может это предусмотреть… Но не будем о печальном.
Итак, мы имеем четыре зоны работы датчика — зона устойчивого ответа «нет» (или «0» по науке), устойчивого «да» (соответственно, «1»), неустойчивое состояние («0» или «1», выпадающее непредсказуемым образом) и поломка (четкое «0» или «1», не соответствующее параметру). Хороший датчик зону неустойчивого состояния минимизирует (делает предельно узкой), а при поломке устанавливается в некоторое оговоренное заранее состояние. Но все равно — зона неустойчивости всегда есть, а поломку можно создать кувалдой, и тогда уже ничего заранее предсказать нельзя.
Впрочем, с зоной неустойчивости бороться можно. И призван это делать гистерезис. Суть предельно проста.
Гистерезис
Для начала мы в состоянии «нет». Параметр нарастает. Подошли к зоне неустойчивости — но мы все равно говорим «нет». Параметр в зоне — все равно говорим «нет». Параметр уже вышел за зону неустойчивости — о! тогда говорим «да». Обратная дорога — палец начинает кнопку отжимать. Еще уверенное «да» — говорим «да». Зона неустойчивости — по-прежнему говорим «да». Параметр уже упал настолько, что устойчивое «нет» — тогда начинаем говорить «нет».
Гистерезис может использоваться и в других случаях и другими методами (например, тот же дребезг контактов может оцениваться временем — скажем, устойчивое нажатие должно длиться не менее 30 микросекунд). Но суть все равно одна и та же.

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

В конце концов, не забываем, что датчик общается с микроконтроллером. Те говорят на языке напряжений. Как правило, «0» — это напряжение от минимального (земляного) до трети питания. «1» — это напряжение от 2/3 питания до питания. Посередке присутствует некоторая неопределенность — те же дребезги, но уже в электрической цепи.

Также нужно учесть, что физическая величина не мгновенно превращается в электрическую интерпретацию «да»/«нет». Иными словами, изменение емкости в емкостном датчике с некоторым запаздыванием на выходе датчика порождает «0»/«1». Это время, как правило, измеряется в наносекундах.
Запаздывание возможно и по другим причинам. Это запаздывание в документации к датчику всегда есть. И датчик нужно выбирать такой, чтобы это запаздывание было как минимум в 4 раза меньше ожидаемых событий.

Итак, мы подошли к основным характеристикам датчиков событий:
  • Физическая природа. Вы должны четко себе представлять какой физический процесс вы используете. Емкостной датчик нажатия? Значит, речь о емкости, единица измерения Фарады. Фоторезистор? Значит, меняется сопротивление, единица измерения Омы.
  • Начало области чувствительности. Очевидно, что у любой физической величины есть значение «0». Но не всегда с этим значением будет работать ваш датчик. Иногда «0» означает поломку. В случае фоторезистора «0» может означать полное отсутствие света (залепили жвачкой?) или максимально допустимую яркость.
  • Границы зоны дребезга. Это выражается в измеряемой величине.
  • Максимально допустимый параметр. Это та граница, после которой датчик уже становится неисправным.
  • Электрические параметры. Это очевидно — датчику для работы нужно определенное (строго и четко определенное!) напряжение питания, потребляемый им в разных режимах ток. Также оговаривается напряжение для «0» и «1». Впрочем, эти характеристики относятся к взаимодействию датчика и микроконтроллера. Они не так важны при определении условий задачи, но важны при выборе конкретного датчика.
  • ВременнЫе параметры. Оговаривается время установки «0»/«1» в зависимости от физического параметра (ну или в формальном виде — спасибо Fahivec — время установки соответствующего выходного состояния при достижении определенного порогового значения воздействующей величины).
  • Интерфейс. «Интерфейс» дословно с английского переводится как «между лицами» и обозначает способ взаимодействия. С компьютером можно взаимодействовать по Ethernet/WiFi/Bluetooth (локальные сети), USB, COM-порту, LPT-порту. С микроконтроллером общение другое — это UART, I2C, SPI, CAN… Это тоже не важно на начальном этапе, но существенно при выборе конкретного типа датчика.
Вроде бы все? Если чего забыл — напоминайте в комментариях, исправим!

Счетчики событий

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

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

Очевидно, что основой таких датчиков будет являться датчик события. На его совести стоит решение задачи о разделении событий во времени, зона дребезга и прочее. Задача счетчика событий — воспринимать единичные события и превращать их в необходимую единицу измерений. Не забываем о том, что время реакции датчика на события должно быть значительно меньше ожидаемой величины (т. е. мы способны воспринять одну машину за 50 мсек — порядок, вряд ли на дороге по одной полосе способны пролететь 20 машин в секунду).

Окна интегрирования
Продолжаем тему счетчика машин — допустим, что мер района Shibuya города Токио заказал нам установить на нескольких основных дорогах датчики потока машин. Его интересует простой параметр — сколько машин за минуту проезжает. На основании этих данных он надеется оптимизировать работу светофоров и полиции. Нам — лестно, и лицом в грязь ударить не хочется.
Мы решили проблему с датчиком событий — в дороги будут вмонтированы датчики давления, которые способны обслужить поток 20 машин/секунда. От них проведены провода (или радио) к постам полиции, и там надо поставить простой стрелочный индикатор: кол-во машин / минута.
Поехали!

Самое первое решение — делаем счетчик, вначале минуты он равен 0. Проехала машина — добавили. Еще проехала — еще добавили. И так считаем целую минуту. Потом вновь сбрасываем. И что тогда будет видеть полицейский? Когда часы будут подходить к 0-ой секунде, стрелка будет резко падать в ноль и снова расти.

Нет, это не фонтан! Эдак мы опозоримся перед японцами!

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

Нам надо узнать количество машин за одну минуту? Значит, у нас размер окна интегрирования составляет минуту. Мы разбиваем это окно на 4 кадра — каждый по 15 секунд. Один кадр — это обыкновенный счетчик. Вначале кадра он равен 0, через 15 секунд мы оставляем это значение и переходим к следующему. На рисунке значения счетчиков в кадрах составляет для первого 6, для второго — 5, потом 3, 6, 6, 7, 4.
За первую минуту окно заполняется — значение постепенно растет. К концу первой минуты мы суммируем все 4 кадра и получаем 6 + 5 + 3 + 6 = 20 машин.
В следующий момент времени (на 1-ой секунде 2-ой минуты) мы сдвигаем окно. Теперь у нас первый кадр, уже заполненный, равен 5, 2-ой 3, 3-ий 6. А новый кадр вначале равен 0.
Итак, 1мин 0 сек — значение равно 20. За последующие 15 секунд последний кадр составил 6. В 01:15 счетчик равен 5 + 3 + 6 + 6 = 20.
Опять сдвигаем окно. Теперь у нас младший кадр 3, потом 6, потом 6, потом 0. За 15 секунд последний кадр вырос до 7 — к 01:30 счетчик составил 3 + 6 + 6 + 7 = 22. За следующие 15 секунд счетчик составит 6 + 6 + 7 + 4 = 23.

Какая тут специфика?

До заполнения текущего кадра мы его в результат не выводим. Т. е. в 14 секунд у нас значение было по-прежнему 0, потом в 15 секунд оно резко дернулось в 6.

Также у нас все время наблюдается запаздывание. Если, допустим, после последней минуты поток машин резко иссяк, то мы увидим вначале 23, потом 23 — 6 = 17, потом через 15 секунд 11, потом еще через 15 секунд 4, и лишь к концу минуты — 0.

Это два недостатка. А достоинство — у нас все время плавно меняющееся значение. И если в случае машин это не так важно, то для счетчиков радиации эта плавность важна.

С этими недостатками легко, впрочем, бороться.

Во-первых, необходимо здорово уменьшить размер кадра. Сделаем его равным 1-ой секунде — и тогда у нас значение будет изменяться раз в секунду. Можно и меньше сделать — тогда оно будет меняться еще быстрее.

Во-вторых, окно интегрирования может составлять не весь период, а какую-то его часть — допустим, 20 секунд. Это означает, что, если машины остановились, то за 20 секунд стрелка упадет в 0.
Но при этом надо учитывать, что окно уже показывает количество машин за 20 секунд, а нам нужно за минуту! Это, впрочем, не беда — в минуте таких 20-секундных окон 3. Значит, мы можем значение окна умножить на 3, предполагая, что за минуту поток сильно меняться не будет. Мы делаем в данном случае аппроксимацию, но она всегда дает погрешность, что хорошо видно на рисунке. Зеленая линия показывает, что было бы, если бы поток машин сохранился. Синяя — аппроксимация после 40 секунд. Ну а красная — реальное значение за минуту. Как видим, первое расхождение было слишком уж большим, второе — поменьше, а истина оказалась посередине… э-э… выше середины, не важно. Погрешность есть, и она слабо предсказуемая. Поэтому так имеет смысл поступать в случае статистически однородных последовательностей. Для нашего случая это все-таки не очень допустимо.
В нашем случае я бы сделал 2 индикатора: первый для мгновенной индикации (с окном не более 10 секунд), второй для сбора статистики (тут окно должно быть с минуту или даже вообще без окон — прямой подсчет).
А можно поступить иначе. Делаем окно на всю минуту. Но, если за десять секунд движения машин все-таки нет, то выводим текущее значение как 0, но счетчик все равно ведем. Если машины пошли, то выводим значение всего кадра.

Итак, можно подвести итоги и перечислить основные характеристики счетчиков событий:

  • Параметры базового датчика событий. Это и тип физической величины, дребезги и границы чувствительностей базового датчика, его электрические и временнЫе параметры, интерфейс.
  • Размер окна интегрирования. Не забываем, что он должен быть не больше и кратным итоговой величине. Если "… за минуту", то это может быть 60 секунд, 30, 20 и так далее.
  • Размер кадра / количество кадров. Понятное дело, что размер кадра = размер окна / количество кадров.
  • Алгоритм отработки резких изменений. Как в нашем примере: если машин нет длительное время, то предусмотрено ли резкое изменение итогового показателя?

Если величина статистически более или менее однородная (говоря математически, производная у нее небольшая), то можно кол-во окон увеличивать. Но если важна корректность значений, то лучше окно интегрирования делать максимально большим.
Меняя размер кадра, мы управляем резкостью изменения показаний. Это также влияет на память — на количество значений в памяти микроконтроллера.

Часы реального времени
Слегка особняком стоит такой полезный класс датчиков, как часы реального времени (real-time clock — RTC). Их задача — выдавать наружу точное время в формате «год-месяц-день-день_недели-час-минута-секунда». Их можно отнести к счетчикам событий, т. к. они считают такты от кварцевого генератора или резонатора (и те и другие в данном случае являются задающим элементом). Их точность напрямую зависит от точности задающего элемента.
Это именно часы, хотя их также можно отнести и к датчикам.
Весьма распространенным и дешевым примером является микросхема DS1307 фирмы Maxim.
Читаем дальше!

P. S.Хочу поучаствовать в конкурсе, поэтому добавляю: Спонсоры
  • +15
  • 27 сентября 2012, 18:20
  • PICC

Комментарии (11)

RSS свернуть / развернуть
Будь я электриком, застрелился бы уже сейчас.
0
Ну, кстати, тот, для кого я писал, в теме разобрался. И даже пытался чего-то там гонять из десятичной в двоичную систему…
0
аффтар, бери качеством а не количеством букаф
датчики реального времени (real-time clock — RTC)
хотя для електриков такое может и прокатит
0
Вот именно!
0
ВременнЫе параметры. Оговаривается время установки «0»/«1» в зависимости от физического параметра.
Наверное имеется ввиду «время установки соответствующего выходного состояния при достижении определенного порогового значения воздействующей величины»?
0
Вставил со ссылкой на Вас, спасибо!
0
Ну ссылаться на меня не обязательно :)
Цель моих подсказок другая: помочь вам «подшлифовать» статью (таки ж на конкурс!)
А она мне понравилась.
0
Ну… Сказать честно — конкурс это приятно ( особенно коли в призовые места попасть :-) ). А вот помочь начинающим разобраться в море информации на эту тему — вот это действительно интересно и полезно!
0
Границы зоны дребезга. Иногда это выражается в измеряемой величине, иногда во времени.
Приведите, пожалуйста, пример, когда эти границы выражаются во времени.
0
Я имел в виду те датчики, которые временнЫе характеристики выдают… Хотя, возможно, я намудрил… Лучше уберу про «время».
0
По многочисленным просьба трудящихся (да и сам мог бы догадаться...) я сделал PDF-ку — читайте!
0
  • avatar
  • PICC
  • 26 октября 2012, 15:38
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.