Для чего нужен процесс детектирования
Детектирование
Полезное
Смотреть что такое «Детектирование» в других словарях:
ДЕТЕКТИРОВАНИЕ — (от лат. detectio обнаружение) (радио) преобразование электрических колебаний, в результате которого обычно получаются колебания другой (как правило, более низкой) частоты. Наиболее важный случай детектирования, используемого в радиоприемных… … Большой Энциклопедический словарь
детектирование — Преобразование электромагнитного колебания для получения напряжения или тока, величина которого определяется параметрами колебания, с целью извлечения информации, содержащейся в изменениях этих параметров. [ГОСТ 24375 80] детектирование… … Справочник технического переводчика
ДЕТЕКТИРОВАНИЕ — (демодуляция) (от лат. detectio открытие, обнаружение), преобразование электрич. колебаний, в результате к рого получаются колебания более низкой частоты (или пост. ток). В радиотехнике Д. выделение НЧ модулирующего сигнала из модулиров. ВЧ… … Физическая энциклопедия
ДЕТЕКТИРОВАНИЕ — выделение с помощью детектора из модулированных колебаний высокой частоты содержащихся в них колебаний низкой частоты, воспринимаемых в телефон. Самойлов К. И. Морской словарь. М. Л.: Государственное Военно морское Издательство НКВМФ Союза ССР,… … Морской словарь
детектирование — сущ., кол во синонимов: 2 • видеодетектирование (1) • преобразование (41) Словарь синонимов ASIS. В.Н. Тришин. 2013 … Словарь синонимов
ДЕТЕКТИРОВАНИЕ — (1) обнаружение сигнала; (2) выделение колебаний низкой частоты из высокочастотных модулированных колебаний (см. ), иногда называемое демодуляцией. Д. широко применяют в радиоприёмном устройстве для получения колебаний звуковой частоты, сигналов… … Большая политехническая энциклопедия
детектирование — (от лат. detectio обнаружение) (радио), преобразование электрических колебаний, в результате которого обычно получаются колебания другой (как правило, более низкой) частоты. Наиболее важный случай детектирования, используемого в радиоприёмных… … Энциклопедический словарь
детектирование — detektavimas statusas T sritis automatika atitikmenys: angl. detection vok. Demodulation, f; Gleichrichtung, f; Rückmodulation, f rus. детектирование, n pranc. détection, f … Automatikos terminų žodynas
детектирование — detekcija statusas T sritis automatika atitikmenys: angl. detection vok. Gleichrichtung, f rus. детектирование, n; детекция, f pranc. détection, f … Automatikos terminų žodynas
Детектирование и оценка сбоев
Поговорим про инциденты и инцидент-менеджмент. Буквально погрузимся в них, разберём основные черты и характер. Рассмотрим типовые ситуации из моего опыта, как этот процесс работает в Авито, как мы измеряем наши инциденты, как их фиксируем, какие есть тонкие моменты и каких результатов мы в этом добились.
Меня зовут Дмитрий Химион, я работаю в компании Авито и в последнее время занимаюсь механизмом, который автоматизировано детектирует деградации продуктов Авито, определяя потери и собирая информацию по сбоям.
Погружение в проблематику
Давайте разберемся, как этот механизм появился и для чего используется. Чтобы было понятно, с чем мы имеем дело, немного расскажу про размер Авито. Год назад у нас было 40 кросс-функциональных команд разработки, но их количество постоянно растет. Они объединены в юниты, в каждом из которых от 2 до 5 фиче-тим, в которых сидит по 3-5 разработчиков.
Разработка весьма интенсивная — сотни релизов сервисов и несколько релизов нашего монолита в день, плюс мобильные релизы. Из-за этого достаточно интересное и большое количество инцидентов, которые мы начали автоматизировано фиксить.
Процесс автоматизации инцидентов в Авито зародился в марте 2018 года. До этого они заводились вручную, примерно по 15-20 в месяц. Они отмечены желтыми столбиками на диаграмме. Потом мы начали фиксировать больше 30 инцидентов в месяц, а значит приблизительно по 1 сбою в день. Если сравнить с количеством команд на 2020 год, то выходит около 1 инцидента на команду разработки в месяц.
Обработка вручную такого количества инцидентов с поиском концов и оценкой потерь — затратный процесс с множеством коммуникаций. Уже на тот момент было понятно, что масштабировать его будет дорого. Поэтому мы решили его автоматизировать. Так появился MVP, который за 3 квартала достиг хороших результатов в обнаружении инцидентов. Покрытие достигло 95+%. Можно сказать, что сейчас любой значимый сбой в Авито становится видим, что дает нам возможность их анализировать, а собранные данные использовать в различных целях. Например, на диаграмме видно, что в последние два месяца был прирост инцидентов. В это время мы масштабировали наш инструмент на новый продукт, поэтому получили небольшой поток дополнительных инцидентов.
В 2020 году у нас уже получалось 250-270 инцидентов. На таких статистически значимых величинах можно было проводить глобальный анализ и выделять общности. Это давало инструменты, например, какие технические цели нам брать в нашей Objectives and Key Results, в цели технических и продуктовых команд.
Благодаря автоматизации мы понимаем частоту, серьёзность инцидентов и их влияние на бизнес. Теперь попробуем понять, какие они бывают и на какие когорты их можно разделить.
Прозрачность
Инциденты можно делать в разные градации, одна из них — понятность\прозрачность:
Яркие и понятные. Это инциденты, в которых абсолютно понятно что случилось. Они прозрачны с точки зрения мониторинга. Мы видим падение тех или иных метрик и понимаем, что нужно чинить, после чего чиним это или откатываем, и видим, что метрики пришли в норму.
Само появилось, само прошло, никому не интересно. Инциденты, про которые никто не знает, как их воспринимать. Например, начало трясти какую-то ноду в кластере Kubernetes, инстансы сервиса начали «пятисотить» или у них выросло response time, поды упали, их отключили и переподняли на другой ноде. А пока разбирались, что происходило, оно само починилось.
Полтергейст. Дата-центру или чему-то внутри него стало плохо. Потом это переключилось на базы или в транспорт, упала сеть, еще что-то, а что происходит и как это починить — совершенно непонятно. Благо, такие кейсы бывают очень редко.
Видимость&Опасность
Еще интересно понимать про видимость и опасность сбоев. Разберем пару кейсов, чтобы понимать, что это такое.
Например, у нас есть пользователь, который хочет купить лыжи или продать шкаф на Авито. При этом должны собираться аналитические данные в рантайме. Но иногда аналитические события меняются, теряются или перестают отправляться. С точки зрения пользователя и с точки зрения наших технических метрик — продукт работает идеально. С точки зрения аналитических данных и возможности построения mission critical отчетов — это катастрофа. Такие инциденты невидимы, но опасны. Они не вызывают сбоев в работе продукта как такового, но «ослепляют» бизнес в выводах или в принятии решений.
Следующий пласт инцидентов более технический.
Например, есть микросервис и прокси, который занимается направлением запросов в Redis. Мастер Redis перестал работать, но у нас есть Stand by, мы на него переключились, и все снова начало работать. В это время поднялся новый мастер, и на него начали идти новые connections. А после поднятия нового мастера старые connections почему-то не переключились на новый Redis.
Мы увидели эту проблему на маленьком сервисе с небольшой нагрузкой и низкой важностью. Дело было в конфигурировании HAProxy, которую мы используем много где, и есть бага в конфигурации, которая автоматизирована для всех сервисов и всех конструкций, которые используют HAProxy в Авито. Мы поняли, что если произойдет сбой подобного масштаба в mission critical сервисе, то у нас будут большие проблемы.
Так мелкий инцидент помог нам увидеть общую проблему на уровне HAProxy. На его основе мы смогли предотвратить появление этой проблемы в будущем и пофиксили конфиг в HAProxy.
Проблема вроде бы маленькая, но ее потенциальная опасность высокая. На опыте разбора инцидентов, мы сделали простой и наверное очевидный вывод: «Инцидентов не избежать – учись с ними работать!».
Некоторые говорят, что нужно писать «код без багов», очень много тестировать и будет меньше инцидентов. Скорее всего так и будет, но надо принять одну простую истину — сколько бы мы ни тестировали, как бы хорошо ни покрывали наши сервисы тестами, у нас все равно будут инциденты (ибо исчерпывающее тестирование слабо реализуемо в больших системах. См. 7 принципов тестирования). Это нормально. Их не надо избегать, но надо стремиться их минимизировать. То есть, если мы упали, надо уметь очень быстро подняться — «быстро поднятое упавшим не считается».
Понимать, какие есть узкие места и где у нас пока плохо с мониторингом или еще с чем-то, нам помогает автоматизированный анализ и сбор данных по инцидентам.
Процесс Live Site Review
Есть еще один способ разделения инцидентов на внешние и внутренние. Внешние инциденты — это когда какой-нибудь эквайринг внешнего провайдера, например, платежный шлюз или еще какая-то интеграция с внешней системой доставки “отъехала”. Мы на таком концентрироваться не будем, а поговорим про внутренние инциденты, которые зависят только от нас и на которые мы однозначно можем повлиять.
Концептуально процесс Live Site Review выглядит так:
Устранение проблемы. Первое, что нужно делать — это устранять проблему, а не заводить тикеты. Вроде капитанская штука, но anyway.
Описание post-mortem;Автоматизировано собирается контекст инцидента и производится его автоматизированная оценка (какого размера он был, длительность, глубина, какие метрики пострадали, что мы потеряли и т.д.)
Оценка post-mortem и встреча;У нас есть специальный человек, который хороводит все наши инциденты, устраивает встречи, где мы обсуждаем, что можно сделать, чтобы предотвратить подобное в будущем.
Выполнение action items;Дальше мы фиксируем определенный набор action items в виде задач с конкретными исполнителями, который позволяет нам не допустить этой проблемы в будущем.
Выполнение action items и закрытие post-mortem;
Дополнение базы знаний.
Для простых и мелких инцидентов мы никакие разборы не делаем:
После инцидента мы собираем статистику и в принципе на этом работа с ним заканчивается. Мы их видим и учитываем в анализе инцидентов на больших временных промежутках. Если у вас есть практика разбора внутренних инцидентов, можете взять это на вооружение.
Как процесс происходит внутри? Post-mortem у нас заводит не какой-то конкретный человек, хотя чаще всего это делают ребята из Problem Mangement, его может завести кто угодно. Инцидент, как таковой, уже можно не заводить, не описывать и не обсчитывать — это все делается автоматизировано:
После того, как появился автоматизированный инцидент и по нему собрались все метрики, скриншоты, мы анализируем работу сервисов, все деплойменты в Kubernetes, которые пострадали, все это выписываем в тикет в Jira. После чего смотрим на этот тикет, оценивая его и принимая решение — является ли он ложно положительным срабатыванием или это валидный сбой.
Это значит, что иногда замеченный инцидент — это не инцидент, а случайно сложившееся обстоятельство, которое не является инцидентом. Но такое бывает не часто.
Ключевые моменты в тикете
Ключевая информация, которую мы автоматически собираем по каждому инциденту, нужна чтобы разобраться, что случилось же случилось. Чтобы понять какие сервисы подскочили в response time, какие показали ошибки в момент сбоя, а какие чувствовали себя нормально, какое было нод в кластерах Kubernetes у нас есть восемь пунктов ключевой информации.
Давайте разберём каждый подробнее.
Влияние. Чтобы понимать, стоит ли обратить внимание на инцидент, всегда смотрим на его влияние на работу бизнеса. Влияние мы измеряем: в пострадавших пользователях, потенциально недополученных деньгах и потерянных данных.
Первопричина. Это то, что необходимо лечить во избежание повторения истории в будущем. Мы стараемся погружаться в наш бэкенд и метрики со всех сторон для того, чтобы собрать всю информацию и быстрее понять первопричины:
Нет анализа изменений;
Нет обратной совместимости;
Триггер. Что послужило триггером? Какие исследования нужно проводить для создания определенных механизмов, какие факторы и какие ситуации в реальности приводят к проявлению проблем? Например, баг может быть посажен в продукт хоть год назад. Но фактором его проявления — «триггером» может быть всё, что угодно.
Сочленение первопричин появления проблемы и триггера фактически является взрывоопасным коктейлем, который приводит к сбоям. Но надо сказать, что триггер и первопричина — это разные вещи. Если вы занимаетесь инцидент-менеджментом, возьмите себе на вооружение, что их необхоимо разделять и отдельно описывать.
Как ликвидировали. Нам важно знать, что мы делали, в какой последовательности и сколько это времени заняло устранение инцидента:
Это позволяет понимать, что мы делаем правильно или неправильно. Если time line ликвидации инцидента был быстрым, с короткими коммуникациями по таймингу, значит реакция на сбой у нас работает идеально. Другая ситуация, если у нас нет каких-то метрик или мы не сможем понять, в чем проблема, это всегда дает зазор между действиями в time line и устранением проблем.
Как обнаружили. Варианты от лучших к худшим:
Обнаружили при выкатке канареечного релиза, затронули минимум пользователей, соответственно, все откатили;
Заметили быстрее, чем пользователи успели заметить;
Узнали из мониторинга;
Получили сообщение от саппорта;
Узнали от руководителя;
Худший вариант — узнать о проблеме из СМИ, это лютое фиаско. Но пока что я не припомню таких случаев.
Action items. Дальше мы должны выделить action items (задачи на доработку) по всей этой информации: что нам сделать, как устранить первопричины и как повлиять на триггеры, чтобы не наступить на те же грабли в следующий раз. Для этого настраиваем мониторинг и алерты, пишем авто-тесты, добавляем активности в грумминг, изменяем инженерные практики и рефакторинг компонентов продукта.
Платформа. Технические данные мы собираем по областям появления проблем, чтобы использовать их для аналитики:
Команда. Интересно понимать, в области какой команды чаще всего происходят инциденты. Это помогает выявить проблемы с инженерией, тестированием или разработкой, и дает возможность зайти в конкретную команду, решить проблему и сократить количество инцидентов.
Что измеряем?
Давайте подробнее рассмотрим, что мы измеряем, из чего строится понимание влияния инцидента на бизнес:
Клиентский капитал. Например, во время инцидента у нас был баг, и мы можем посчитать, сколько пользователей его видели и посмотреть, как мы просели по различным продуктовым конверсиям, регистрациям и авторизациям. Таким образом мы видим, как еще мы повлияли на пользователей.
Финансовые потери. Терминологически это не финансовые потери, а недополученная и потенциально недополученная ликвидность и прибыль. Фин. потери достаточно сложно считать, но, тем не менее, мы считаем: недополученную прибыль, провалы в биллинге и монетизационные инструменты. Мы видим, что в нашу компанию приносит revenue, и из этого считаем, что недополучили.
Потеря данных. Мы считаем, какое количество mission critical данных для аналитики и принятия бизнес-решений потеряли в процессе технических сбоев. Это могут быть аналитические, пользовательские и технические данные. Это большая область, которая не сильно развита, потому как пока не хватает ресурсов. Но это у нас в планах. Мы эту область развиваем и будем развивать.
И вот что из ключевых параметров мы измеряем в наших инцидентах, чтобы понимать их размер.
Оценка бизнес-метрики
Я сделал несколько обезличенных скриншотов из Grafana, которые демонстрируют описание наших инцидентов. У нас есть механизм, который показывает деградацию по ключевым метрикам. Если деградация этих метрик определенным образом коррелирует, то есть метрики из разных когорт, и если деградация метрик из этих когорт совпадает по временному интервалу, то мы говорим, что здесь деградация и нужно дальше копать, чтобы разобраться — это реально инцидент или нет. Соответственно, мы ведем подсчеты по метрикам и записываем в тот или иной вид потерь.
Мы измеряем те же потери данных, например в миллионах запросов от пользователей. Это происходит при углублении в инцидент, то есть, когда у нас есть тайминг инцидента, мы начинаем копать, как какая метрика себя вела в этот промежуток времени, из чего у нас и получаются потери.
Конечно, здесь все данные специально изменены.
После того, как по нашему инциденту определили время начала и окончания, можем взять какую-то метрику и увидеть просадку.
В данном случае это регистрация пользователя на платформе. Можно увидеть, что за время инцидента у нас недозарегистрировалось около 90 пользователей. Это бизнесовая потеря, потому что маркетинг кропотливо работал над маркетинговой компанией, чтобы привести пользователей на регистрацию. А из-за инцидента этого не случилось.
Примерно так выглядит оценка бизнес-метрики по потерям данных, клиентского капитала и пользователям.
Тонкие моменты
Распространение практики. Если вы у себя сейчас делаете инцидент-менеджмент или что-то близкое, наберитесь терпения. Эта практика должна созреть и врасти в культуру разработки, стать частью top of mind, чтобы превратиться в бытность. Нашему инструменту то же не сразу начали доверять, считали, что он неправильно работает, что-то не так считает и находит фейковые штуки, но со временем мнение изменилось.
Временной ресурс. Часто на закрытие action items необходимо выбивать ресурс. Раньше у нас это вызывало сопротивление людей, так как не всем, не всегда и не во всем было понятно, какая ценность в закрытии action items. Со временем это размылось. Для того, чтобы полноценно вести этот процесс Live Site Review (инцидент-менеджмент), part time человека не хватит. Если вы хотите нормально этим заниматься, то нужен dedicated человек, который будет строить этот процесс.
«Люркинг» людей. Когда мы начинаем в неправильной форме выяснять, почему люди что-то не сделали, происходит «люркинг». Они стараются скрыть свои инциденты. Это происходит из-за неправильной подачи самих инцидентов, когда их называют позором, а не процессом по борьбе с проблемами в разработке. Процесс нужно направить не на поиск виноватых, а подавать с ракурса: «Всем привет, у нас есть такая то проблема, давайте ее обсудим», и обсуждать не людей, а как эта проблема появилась и что менять в процессах. Тогда проблему «люркинга» можно сильно снизить, что повысит выхлоп всего процесса.
Драйвер процесса. Естественно, это капитанская вещь, но если у процесса нет идеолога, то есть человека, который видит горизонт его развития, то процесс либо стагнирует, либо развалится.
Итоги
Что же дает инцидент-менеджмент?
Для инженеров:
Это очень простой набор действий:
Инцидент?! — «Устраняй ➜ Описывай ➜ Обсуждай». Ещё инцидент? — «Устраняй ➜ Описывай ➜ Обсуждай».
А еще пропагандирование культуры, в которой мы не стараемся закрыть все баги и сделать 100% покрытие, а хотим быть готовы к инциденту, чтобы уменьшить его влияние на работу компании. Тестирование — не краеугольный камень всего и вся, оно лучше работает в связке с мониторингом.
Для руководителей:
В такой большой организации, как Авито, автоматизация инцидент-менеджмента позволяет понимать, каково состояние продукта, видеть сбои, которые у нас происходят. Это формирует картину, насколько все хорошо или плохо, может быть, не в рантайме, но на горизонте временных промежутков.
Имея на руках автоматизировано собранный и оцененный большой инцидент или видя какой-то тренд по инцидентам, можно своевременно принять сложное решение. Например, остановить релизы, решить проблемы, которые могут привести к коллапсу, восстановить работу и начать релизить снова. Это весьма ценное, на мой взгляд, свойство процесса, которое позволяет принимать сложные решения.
Видео моего выступления на эту тему:
Конференция об автоматизации тестирования TestDriven Conf 2022 пройдёт в Москве, 28-29 апреля 2022 года. Кроме хардкора об автоматизации и разработки в тестировании, будут и вещи, полезные в обычной работе.
Расписание уже готово, а купить билет можно здесь. С 1 января будет повышение цен!
Детектирование
Передача по радио звуков (речи, музыки и т. д.) осуществляется с помощью радиоволн. Для этого звуковыми колебаниями, преобразованными в электрические, воздействуют на высокочастотные колебания радиопередатчика. Высокочастотные колебания, подвергшиеся воздействию передаваемых звуковых колебаний, называются модулированными.
Достигнув приёмной антенны, радиоволны возбуждают в ней колебания, модулированные так же, как и те, которые излучаются антенной передатчика. Для того, чтобы воспроизвести передаваемые сигналы, из поступивших в приёмник модулированных колебаний должны быть получены низкочастотные колебания, соответствующие передаваемому звуку. Процесс получения последних называется детектированием, а устройства, в которых этот процесс осуществляется,- детекторами.
Для передачи сигналов можно воздействовать на высокочастотные колебания так, чтобы эти сигналы изменяли либо амплитуду высокочастотных колебаний (амплитудная модуляция), либо их частоту (частотная модуляция), или применением ещё какого-нибудь более сложного вида модуляции. Процесс детектирования различно модулированных высокочастотных колебаний протекает по-разному. Поскольку для целей радиовещания пока наиболее широко применяется амплитудная модуляция, и процесс детектирования мы будем рассматривать только для случая колебаний, модулированных по амплитуде.
В своих первых приёмниках изобретатель радио А. С. Попов для детектирования высокочастотных колебаний применял так называемый когерер. Однако когерер обладает рядом недостатков, и А. С.Попов вынужден был поэтому заменить его кристаллическим детектором. В дальнейшем П. Н. Рыбкин (ближайший сотрудник А. С. Попова) предложил метод непосредственного преобразования принимаемых затухающих высокочастотных колебаний в звуковые сигналы при помощи кристаллического детектора и телефона. Это позволило производить приём на слух телеграфных сигналов и послужило первым и наиболее важным шагом в осуществлении радиотелефонии.
«ИДЕАЛЬНЫЙ» ДЕТЕКТОР
Для того, чтобы форма «огибающей» модулированных колебаний (рис. 1), подводимых к детектору приёмника, была такой же, как и форма «огибающей» колебаний, излучаемых передающей антенной, необходимо, чтобы приёмник «пропускал» всю передаваемую полосу частот.
Рис. 1. Кривая, проходящая через «вершины» модулированных колебаний, называется «огибающей» этих модулированных колебаний.
Низкочастотный ток, имеющий форму этой огибающей, может быть получен с помощью цепи, пропускающей ток только в одном направлении (полное выпрямление) или пропускающей ток в одном направлении лучше, чем в другом (частичное выпрямление).
Рассмотрим сначала случай полного выпрямления.
Представим себе проводник, который обладает следующими свойствами: если к его концам приложено напряжение U одного направления, по этому проводнику течёт ток I, пропорциональный этому напряжению, как и в обычном проводнике; но при перемене знаков напряжения ток в проводнике вовсе не возникает. Такой проводник называют идеальным детектором.
Посмотрим теперь, какой ток течёт в цепи идеального детектора, когда на него действуют немодулированные колебания.
Рис. 2. Вольтамперная характеристика идеального детектора.
Для этого поступаем следующим образом: под характеристикой детектора вдоль её вертикальной оси изобразим графически зависимость приложенного напряжения от времени t (рис. 3). Каждому значению приложенного напряжения соответствует определённое значение силы тока в цепи детектора, которое можно найти по его характеристике (для нахождения этих значений тока служат вертикальные пунктирные линии на рис, 3). Так как приложенное напряжение всё время изменяется, то изменяется и ток. Откладывая различные значения тока вправо в такой же последовательности, как соответствующие изменения напряжения (для этого служат горизонтальные пунктирные линии на рис. 3), мы получим графическое изображение изменения тока в цепи детектора от времени t.
Рис. 3. Графическое построение кривой изменения тока в цепи идеального детектора при приложенном к нему синусоидальном напряжении.
Сила тока в цепи изображается «половинками синусоид» одного направления. Иначе говоря, в цепи детектора получаются лишь отдельные импульсы тока, текущего только в одном направлении. Такой ток называется пульсирующим.
ПОСТОЯННАЯ И ПЕРЕМЕННАЯ СОСТАВЛЯЮЩИЕ
Так как количество электричества, протекающего в цепи за какое-либо время, равно произведению силы тока на время, в течение которого этот ток протекает, то, следовательно, оно выражается площадью, заключённой между кривой, изображающей изменения силы тока, и осью времени. Поэтому постоянная составляющая данного пульсирующего тока, т. е. его среднее значение, изображается такой прямой, для которой площадь между ней и осью времени (заштрихованная площадь на рис. 4, Б), равна площади, ограниченной импульсами пульсирующего тока (заштрихованная площадь на рис. 4, А).
Постоянная составляющая пульсирующего тока будет тем большей, чем больше высота импульсов, т. е. в конечном счёте, чем больше амплитуда подводимого к детектору напряжения.
Рис. 4. График А представляет собой сумму постоянного тока, показанного на графике Б, и переменного тока, показанного на графике В.
Переменная составляющая пульсирующего тока в сумме с постоянной составляющей должна дать рассматриваемый пульсирующий ток. Как видно из рис. 4, В, эта переменная составляющая имеет ту же частоту, что и подводимое к детектору напряжение, но её кривая по форме не является синусоидальной. В то же время площади, ограниченные участками этой кривой, лежащими выше и ниже оси времени (штриховка с разным наклоном), равны, а следовательно, количества электричества, протекающего за период в том и другом направлении, одинаковы. Следовательно, количество электричества, протекающее в цепи, в среднем за период равно нулю, как и в случае обычного переменного тока. Величина переменной составляющей пульсирующего тока тем больше, чем больше «высота» импульсов.
Рис. 5. Схема простейшего детекторного приёмника.
Рассмотренный нами способ разложения пульсирующего тока на постоянную и переменную составляющие может показаться искусственным и чисто формальным. Однако в действительности такое разложение и происходит в цепи детектора и телефона. Рассмотрим простейшую схему приёмника с кристаллическим детектором (рис. 5). Здесь к концам катушки L1 колебательного контура присоединяется цепь, состоящая из последовательно включённых детектора Д и обмотки телефона Т. Параллельно обмоткам телефона обычно включается блокировочный конденсатор Сб. При наличии колебаний в контуре на катушке L1 возникает высокочастотное напряжение, которое должно быть подано на детектор. Включённые последовательно с детектором обмотки телефона обладают значительным активным сопротивлением и, кроме того, большим индуктивным сопротивлением для токов высокой частоты. Поэтому, если бы напряжение высокой частоты подавалось на детектор через эти обмотки, то на них падала бы значительная часть этого напряжения. Следовательно, на детекторе падала бы лишь малая доля всего высокочастотного напряжения, возникающего в колебательном контуре. Чтобы избежать этого и служит блокировочный конденсатор Сб ёмкостью от нескольких сот до тысячи пикофарад. Такой конденсатор обладает малым сопротивлением для токов высокой частоты и поэтому высокочастотное напряжение с контура почти полностью поступает на детектор (Между витками обмотки телефона и проводами, с помощью которых они соединяются со схемой приёмника, всегда существует ёмкость, которая как бы включена параллельно обмоткам. Она играет такую же роль, как и блокировочный конденсатор Сб; поэтому и при отсутствии в приёмнике блокировочного конденсатора схема цепи детектора и телефона практически остаётся такой же, как изображённая на рис. 5.).
Итак, в цепи детектора под действием синусоидального напряжения возникают как постоянная составляющая тока, так и переменная. При этом постоянная составляющая будет тем большей, чем больше амплитуда напряжения, подаваемого на детектор.
ДЕТЕКТИРОВАНИЕ МОДУЛИРОВАННЫХ КОЛЕБАНИЙ
Теперь рассмотрим случай, когда на детектор действуют модулированные колебания. Так как величина постоянной составляющей зависит от амплитуды подводимого к детектору напряжения, то в данном случае «постоянная» составляющая будет изменяться в соответствии с изменением амплитуды этих модулированных колебаний (рис. 6, В). Иначе говоря, в случае детектирования модулированных колебаний в цепи детектора возникает ещё и переменная составляющая напряжения низкой частоты, кривая изменения которого по форме подобна огибающей модулированных колебаний, подаваемых на детектор.
Переменная составляющая низкой частоты, проходя через обмотки телефона (Ёмкость конденсатора подбирается так, чтобы его сопротивление для составляющей низкой частоты было значительно больше сопротивления обмоток телефона.), заставляет его воспроизводить те звуки, которые воздействуют на микрофон передатчика. Так же как и в случае, когда на детектор подаётся немодулированное напряжение, высокочастотная переменная составляющая пройдёт через блокировочный конденсатор.
Реальный детектор пропускает ток в обратном направлении, т. е. обладает несимметричной проводимостью. Его вольтамперная характеристика имеет различную крутизну при различных направлениях приложенного напряжения. Предположив, что она имеет вид, изображённый на рис. 7, повторим и для этого случая построение, аналогичное рис. 3. В этом случае мы получаем импульсы двух направлений. Можно считать, что импульсы каждого из них дают постоянную составляющую, определяемую их высотой. А поскольку высота импульсов тока различных направлений неодинакова, то и их постоянные составляющие также различны. Так как эти постоянные составляющие текут в разные стороны (поскольку импульсы направлены в разные стороны), то результирующее значение постоянной составляющей в цепи равно разности этих двух постоянных составляющих. Величина результирующей постоянной составляющей будет очевидно меньше, чем в случае идеального детектора, но она и в этом случае будет зависеть от амплитуды подводимого напряжения. Поэтому реальный детектор, так же как и идеальный, в случае модулированных колебаний будет давать низкочастотную составляющую, по форме подобную огибающей модулированных колебаний, но амплитуда её будет меньше, чем в случае идеального детектора.
Рис. 7. Графическое построение кривой изменения тока в цепи реального детектора при приложенном к нему синусоидальном напряжении.
КОНСТРУКЦИИ КРИСТАЛЛИЧЕСКИХ ДЕТЕКТОРОВ
Наиболее простым является контактный или кристаллический детектор, в котором несимметричной проводимостью обладает, контакт между кристаллом и металлом или двумя различными кристаллами.
Большинство таких детекторов довоенных выпусков обладали одинаковыми недостатками: для того, чтобы они детектировали, нужно было переставлением конца спиральки отыскивать та поверхности кристалла чувствительную (детектирующую) точку и регулировать степень нажима спиральки на кристалл; при малейшем толчке спиралька смещалась и детектор переставал работать. Только детектор с кристаллом карборунда был свободен от этого недостатка, но зато он отличался низкой чувствительностью.
Современные детекторы обладают постоянной рабочей точкой и поэтому не требуют настройки и регулировки. К наиболее распространённым современным детекторам относятся купроксный и кремниевый детекторы.
Первый из них представляет собой миниатюрный купроксный выпрямитель. Такой детектор обладает не очень высокой чувствительностью и поэтому применяется главным образом при приёме местных радиостанций.
Описанный детектор обладает хорошей чувствительностью; он дёшев, прост и удобен в обращении.
Группа советских специалистов под руководством инженера А. Пужай разработала конструкцию германиевого детектора.
Такой детектор по внешнему виду напоминает маленький круглый конденсатор постоянной ёмкости. Германиевый детектор обладает высокой чувствительностью и «весьма устойчив в работе.
В заключение отметим, что до появления электронной лампы кристаллический детектор был единственным типом детектора, применявшимся в радиоприёмниках. Однако после появления электронной лампы положение изменилось. Электронная лампа, способная не только детектировать, но также усиливать и генерировать колебания, стала вытеснять кристаллический детектор.
Но в будущем положение, повидимому, снова должно измениться. Дело в том, что, как показал ещё в 1922 году советский изобретатель О. В. Лосев, кристаллический детектор также может служить для усиления и генерирования колебаний. Это изобретение Лосева в своём дальнейшем развитии привело к созданию кристаллического триода, в котором имеются не один, а два металлических проводника, образующих контакт с кристаллом. Кристаллический триод может служить усилителем колебаний.