HMMD — радар присутствия (24 ГГц mmWave)

📡 Радар присутствия HMMD (24 ГГц mmWave)

HMMD — миллиметровый радар: в отличие от PIR-датчиков (см. PIR_sensor_AM312), которые видят только резкое изменение теплового излучения, радар обнаруживает цель по отражению собственного излучаемого сигнала (эффект Доплера) и различает не только движение, но и почти неподвижного человека (дыхание) — физика в THEORY.md.

⚠️ Протокол датчика не полностью подтверждён документацией (официальная wiki Waveshare недоступна из окружения разработки, независимые источники расходятся в формате) — драйвер поэтому не отправляет радару никаких команд настройки и распознаёт оба вероятных формата вывода (текстовый и бинарный). Подробности и как проверить свой экземпляр — THEORY.md, раздел 3.

📋 Навигация

🛠 Состав компонента

• include/HmmdRadar.h — интерфейс класса драйвера.
• src/HmmdRadar.cpp — приём UART, распознавание ASCII/бинарного формата.
• src/main.cpp — тестовый стенд: серийная диагностика, режим сырого HEX-дампа, встроенный LED-индикатор.
• tools/radar_view.py — визуализация радар-экрана в реальном времени (см. ниже).

🚀 Сборка и прошивка (PlatformIO)

cd Components/HMMD-mmWave
pio run -t upload && pio device monitor

По умолчанию UART2 на GPIO16 (RX)/GPIO17 (TX) — см. WIRING.md.

Первый запуск на новом экземпляре датчика

1. Прошейте и откройте Serial Monitor (115200 бод).
2. Отправьте r — включится сырой HEX-дамп всех байт, приходящих от радара. Это подтверждает физическое подключение и позволяет увидеть реальный формат вывода вашего конкретного модуля.
3. Отправьте r ещё раз, чтобы вернуться в обычный режим — статус печатается каждые 0.5с:

[EMPTY]  зона свободна  формат=?     isAlive=1
[TARGET] дистанция=1.35 м формат=ASCII isAlive=1

формат=ASCII или формат=BINARY(FD FC FB FA) показывает, какой протокол реально распознан у вашего датчика. isAlive=0 означает, что от радара давно не было ни одного валидного кадра — обрыв UART или неподтверждённый формат вывода (см. HmmdRadar::isAlive()).

⚙️ Настройки в коде

Зона контроля и удержание статуса задаются в конструкторе (main.cpp: HmmdRadar radar(Serial2, kMaxDistanceM, kHoldTimeMs)):

• kMaxDistanceM (по умолчанию 2.10 м) — показания дальше игнорируются.
• kHoldTimeMs (по умолчанию 2000 мс) — сколько ждать без валидных данных, прежде чем считать цель ушедшей из зоны (защита от дребезга на границе обнаружения, см. THEORY.md, раздел 4).

Настройка самой чувствительности/дальности радара HEX-командами в этой версии не выполняется — см. THEORY.md, раздел 3 о том, почему.

🖥️ Наглядная визуализация (для демонстрации детям)

tools/radar_view.py рисует живой “радар-экран” в реальном времени: сектор обзора ±60°, кольца дальности до 2.1 м, красная дуга — где сейчас цель. Датчик отдаёт только дистанцию, без угла, поэтому дуга рисуется через весь сектор, а не точкой в конкретном направлении — это честное отображение того, что реально измеряется (см. THEORY.md, раздел 3).

cd Components/HMMD-mmWave/tools
pip install -r requirements.txt
python3 radar_view.py /dev/ttyUSB0   # порт как в pio device monitor

Прошивка должна быть в обычном режиме (не r/сырой дамп) и не занята другим Serial Monitor — порт может слушать только одна программа одновременно.

🔧 Устранение неисправностей

• Постоянно isAlive=0, дамп (r) пустой — проверьте, что TX радара идёт на RX2 ESP32 и наоборот (частая ошибка — перепутать местами), питание 3.3В (не 5В).
• Дамп (r) не пустой, но обычный режим не распознаёт [TARGET]/[EMPTY] осмысленно — скорее всего, ваш датчик выдаёт бинарный формат (формат=BINARY), для которого декодирование точной дистанции ещё не реализовано (только факт обнаружения кадра) — см. THEORY.md.
• isAlive=1, формат=ASCII, но всегда [EMPTY] — цель может быть дальше kMaxDistanceM; попробуйте подойти ближе, в пределах 1 метра.

📡 Теория: миллиметровый радар присутствия HMMD

1. Принцип работы: радар, а не тепловизор

PIR-датчик (см. PIR_sensor_AM312) — пассивный: он ничего не излучает, а только пассивно ловит изменение инфракрасного (теплового) излучения в поле зрения. Из-за этого он видит только движение — неподвижный, пусть даже тёплый человек, для него невидим.

HMMD — активный радар: сам излучает электромагнитную волну в диапазоне 24–24.25 ГГц (миллиметровый диапазон, mmWave) и анализирует отражённый от объектов сигнал. Определение цели основано на эффекте Доплера: если отражающая поверхность движется относительно радара (включая микроскопические колебания грудной клетки при дыхании), частота отражённой волны чуть сдвигается относительно излучённой — именно этот сдвиг радар и детектирует, отличая “живую”, хоть бы и почти неподвижную цель, от статичной обстановки комнаты (мебель, стены). Это принципиально другой физический механизм, чем у PIR, и именно поэтому радар способен замечать сидящего неподвижно человека, а PIR — нет.

2. Технические характеристики

Модуль HMMD построен на чипе S3KM1110 (по данным официального магазина Waveshare) и использует технологию FMCW (Frequency Modulated Continuous Wave — непрерывная волна с частотной модуляцией): вместо одиночных импульсов радар постоянно излучает сигнал с плавно меняющейся частотой, что позволяет одновременно измерять и скорость (через доплеровский сдвиг), и расстояние до цели (через сравнение фазы/частоты излучённого и принятого сигнала в момент приёма).

Эти цифры относятся к общей линейке модулей на чипе S3KM1110 (в объявлениях Waveshare этот же чип фигурирует и под названием HMMD, и под названием S3KM1110) — взяты из карточки товара поставщика, не из официального PDF-даташита (тот на момент написания недоступен для скачивания в этом окружении).

3. Протокол — что подтверждено, а что нет

Это важный раздел: предыдущая версия этого компонента использовала HEX-команды настройки вида 55 5A ..., которые не подтверждены ни одним независимым источником и, скорее всего, были придуманы при первом черновом написании кода, а не взяты из документации. Официальная wiki Waveshare (waveshare.com/wiki/HMMD_mmWave_Sensor) на момент проверки недоступна напрямую из этого окружения (сервер отвечает 403 Forbidden ботам), а по независимым отзывам (обсуждение в репозитории проекта Tasmota, где мейнтейнер прямо сравнивал протокол HMMD с семейством LD2410) сама эта wiki признана неполной — например, без описания «входа в режим команд».

Независимый рабочий пример (electroniclinic.com, ESP32 + HMMD) показывает другой формат кадра — бинарный, в стиле семейства радаров Hi-Link LD2410: заголовок FD FC FB FA, хвост 04 03 02 01. При этом тот же источник и другие примеры кода параллельно показывают, что датчик также способен выводить простые текстовые ASCII-строки вида "Range [N]" — именно такой формат парсит текущий драйвер.

Прямого подтверждения, какой из двух форматов (ASCII или бинарный) выдаёт именно ваш экземпляр модуля “из коробки”, без сторонних команд настройки, на момент написания этого компонента нет. Поэтому:

• HmmdRadar::begin() не отправляет никаких HEX-команд настройки — они не подтверждены, могли не делать ничего полезного на реальном железе, и их удаление не может ничего сломать (датчик по спецификации должен сам начинать выдавать данные после подачи питания).
• HmmdRadar::update() параллельно пытается разобрать оба формата: tryParseAsciiLine() ищет строку "Range", tryParseBinaryFrame() ищет байтовые границы FD FC FB FA ... 04 03 02 01. Для бинарного формата драйвер честно фиксирует только сам факт валидного кадра (FrameFormat::Binary), не пытаясь декодировать точное смещение поля дистанции внутри — чтобы узнать реальное смещение, нужен доступ к официальному протоколу или ручной разбор дампа.
• В main.cpp есть режим сырого HEX-дампа (команда r в Serial Monitor) — он печатает каждый байт, пришедший от радара, как есть, без парсинга. Это единственный надёжный способ на практике увидеть, что реально шлёт конкретный физический экземпляр датчика.

Как проверить протокол на реальном железе

1. Подключить датчик по WIRING.md, прошить, открыть Serial Monitor.
2. Отправить r — включить сырой дамп.
3. Посмотреть на вывод:
   • Если видно читаемый текст ASCII (буквы, “Range”, цифры) — подтверждён текстовый протокол, всё уже работает, [TARGET]/[EMPTY] в обычном режиме будут показывать формат=ASCII.
   • Если видно повторяющиеся байты FD FC FB FA в начале “пачек” — подтверждён бинарный LD2410-подобный протокол; в обычном режиме будет формат=BINARY, но дистанция при этом не будет заполняться (только факт присутствия), пока кто-то не разберёт точное смещение байта дистанции внутри payload вручную по дампу и не допишет декодирование в tryParseBinaryFrame().

4. Логика удержания статуса (hold time)

Реальный сигнал радара немного “дрожит” на границе зоны обнаружения — цель может на долю секунды пропасть из отчёта и снова появиться, хотя физически человек никуда не уходил. Наивная логика “нет данных в этом кадре → сразу гасим статус” даёт заметное мерцание индикации. Поэтому драйвер использует hold time (HmmdRadar::update(), по умолчанию 2000 мс, задаётся в конструкторе) — статус “цель обнаружена” гаснет только после holdTimeMs миллисекунд подряд без единого валидного показания, а не при первом же пропуске.

5. Ограничения технологии

• mmWave-радар не проникает через металл — металлические стены/двери полностью экранируют сигнал.
• Движение постороннего объекта в зоне обзора (например, работающий вентилятор, штора на сквозняке) может давать ложные срабатывания — это плата за высокую чувствительность к любому движению, включая микроскопическое.
• Возможны взаимные помехи при работе нескольких radar-модулей близко друг к другу на той же полосе частот.

6. Почему нет расчёта дБ/точной дальности “из коробки”

В отличие от INMP441/ICS43434, где сырой АЦП-сигнал напрямую доступен коду ESP32, у HMMD вся физика (доплеровский сдвиг, FMCW-обработка, вычисление дальности) происходит внутри самого чипа радара — ESP32 получает уже готовый результат по UART, а не сырые данные для собственной обработки. Это упрощает код на микроконтроллере, но и ограничивает то, что можно “увидеть” программно — на этом уровне нет доступа к самому отражённому сигналу, только к финальному выводу датчика.

🔌 Подключение: ESP32 DevKit v1 + HMMD mmWave

Таблица подключения

Пины GPIO16/17 заданы в main.cpp как kRx2Pin/kTx2Pin — поменяйте их там при другой разводке. TX радара идёт на RX2 ESP32 и наоборот — типичная ошибка проводки UART — перепутать TX↔RX местами.

Почему не используется пин OT2

У HMMD есть отдельный цифровой выход OT2 (высокий уровень = обнаружена цель, по данным сторонних источников) — это самый простой способ подключения без единой строчки кода, годится для прямого управления реле. Этот компонент сознательно его не использует: датчик подключён по UART, а дистанция до цели считывается из потока данных — OT2 такой детализации не даёт (только да/нет). Если нужен вариант “без программирования” — можно попробовать подключить OT2 напрямую к модулю реле, но поведение этого пина в рамках подготовки этого компонента не проверялось на реальном железе.

Проверка перед первым включением

1. Мультиметром между 3V3 и GND — должно быть ~3.3В.
2. TX радара → RX2 ESP32 (GPIO16), RX радара → TX2 ESP32 (GPIO17) — не перепутаны местами.
3. После прошивки в Serial Monitor (115200 бод) отправьте r (сырой HEX-дамп) — если данные идут, вы увидите поток байт. Это первая проверка, которую стоит сделать на новом экземпляре датчика — она подтверждает физическое подключение независимо от того, какой именно протокол (ASCII/бинарный) использует ваш модуль (см. THEORY.md, раздел 3). Если байт нет — UART не настроен или пины перепутаны (см. README.md, “Устранение неисправностей”).

Если нужны другие GPIO

UART2 на ESP32 можно переключить почти на любые GPIO. Не годятся:

• GPIO0, GPIO2 — участвуют в загрузке платы; GPIO2 также используется в этом компоненте под статусный LED (см. main.cpp) — не занимайте его под UART.
• GPIO6–11 — заняты встроенной Flash-памятью.
• GPIO34–39 — только вход, без подтяжки; для TX2 (выход ESP32 → радар) не подойдут.

Методическое пособие: серия уроков «Радар присутствия HMMD»

Стенд: ESP32 + HmmdRadar (24 ГГц mmWave радар) + серийная диагностика и режим сырого HEX-дампа в main.cpp. Пособие связывает работу датчика с темами физики (электромагнитные волны, эффект Доплера) 9–11 класса и с азами инженерной практики: как работать с датчиком, когда документация производителя неполна — реальная, а не выдуманная задача, встречающаяся в проектах постоянно.

Рассчитано на 2 урока по 40–45 минут: физика радара и сравнение с PIR-датчиком → практикум “инженерный детектив” (проверка реального протокола датчика по сырым байтам). Если в кабинете уже есть PIR_sensor_AM312 — урок 1 выигрывает от прямого сравнения на живых приборах.

Кто чем пользуется

1. Инженер собирает схему по WIRING.md, прошивает src/main.cpp.
2. Учитель на уроке открывает Serial Monitor — весь функционал доступен без Python и дополнительных программ, только текстовый вывод.

⚠️ Важная методическая особенность этого урока

В отличие от других компонентов лаборатории, протокол HMMD не полностью подтверждён документацией производителя на момент подготовки этого пособия (подробности — THEORY.md, раздел 3). Это не недостаток урока, а сознательно используемая особенность: реальные инженерные проекты регулярно сталкиваются с неполной или противоречивой документацией, и умение проверить факт “вручную”, глядя на сырые данные, а не слепо доверять и не слепо изобретать — ценный навык сам по себе.

Урок 1. Радар против PIR: как обнаружить неподвижного человека

Тема: электромагнитные волны, отражение, эффект Доплера, сравнение активных и пассивных датчиков.

Ход работы.

1. Включить стенд, открыть Serial Monitor. Пройти перед датчиком — статус переключится в [TARGET], дистанция обновится (если формат ASCII подтверждён — см. врезку про Урок 2). Встроенный LED тоже загорится.
2. Встать перед датчиком и замереть (не размахивать руками, дышать спокойно). Обсудить с классом прогноз: погаснет ли [TARGET] через holdTimeMs (2 секунды по умолчанию), как это было бы у PIR-датчика?
3. Если в кабинете есть PIR-датчик (см. PIR_sensor_AM312) — повторить тот же эксперимент “замри” на нём параллельно. PIR потеряет цель почти сразу после прекращения движения, HMMD — заметно позже или не потеряет вовсе, пока человек продолжает дышать в пределах чувствительности датчика.

Разбор. PIR — пассивный датчик: он ничего не излучает, а лишь регистрирует изменение инфракрасного излучения в поле зрения, поэтому видит только движение. HMMD — активный радар: сам излучает электромагнитную волну ~24 ГГц и анализирует отражение (THEORY.md, раздел 1). Определение цели основано на эффекте Доплера — если отражающая поверхность (например, грудная клетка при дыхании) хоть немного движется, частота отражённой волны сдвигается относительно излучённой, и именно этот сдвиг радар засекает — даже когда человек кажется совершенно неподвижным. Это тот же физический эффект, из-за которого сирена скорой помощи меняет тон при приближении и удалении, и тот же принцип, которым автомобильные радары ГИБДД измеряют скорость.

Практическое задание. Заполнить сравнительную таблицу “PIR vs HMMD” по итогам собственного наблюдения (не по теории): что каждый датчик заметил, а что пропустил, за одинаковое время эксперимента “замри на месте”. Обсудить, для какой задачи (охранная сигнализация, освещение в переговорке, где люди подолгу сидят неподвижно) какой датчик подходит лучше, опираясь на разницу в физическом принципе, а не только на маркетинговые преимущества.

Урок 2. Инженерный детектив: какой протокол на самом деле шлёт датчик

Тема: протоколы передачи данных, работа с неполной документацией, шестнадцатеричная система счисления, чтение “сырых” данных.

Подготовка. Учителю заранее стоит один раз проверить, какой формат выдаёт конкретный физический экземпляр датчика в классе (ASCII или бинарный, см. ниже) — тогда на уроке можно управлять ожиданиями, не тратя время урока на непредсказуемый результат. Сам эксперимент от этого не становится менее настоящим: ученики результата заранее не знают.

Ход работы.

1. Рассказать контекст: у этого датчика найдено расхождение между разными источниками в интернете о том, в каком формате он присылает данные — текстом или байтами (THEORY.md, раздел 3). Задача класса — выяснить правду для конкретного датчика в руках, как это бы сделал инженер на реальном проекте.
2. Отправить r в Serial Monitor — включить сырой HEX-дамп. На экране побегут пары шестнадцатеричных символов.
3. Разобрать вместе с классом, что значит “шестнадцатеричный” (каждая пара символов — один байт, значения от 00 до FF, то есть от 0 до 255 в десятичной системе).
4. Искать закономерность: если в потоке видны читаемые ASCII-коды букв (например, 52 61 6E 67 65 — это код слова “Range” в таблице ASCII) — протокол текстовый. Если видна повторяющаяся последовательность FD FC FB FA — это заголовок бинарного кадра.
5. Отправить r ещё раз, вернуться в обычный режим, проверить: строка формат=ASCII или формат=BINARY в выводе подтверждает то, что класс только что увидел вручную.

Разбор. Программный код умеет распознавать оба варианта одновременно (HmmdRadar::update() параллельно пробует tryParseAsciiLine() и tryParseBinaryFrame()) именно потому, что заранее не было уверенности, какой из них верный — это осторожная, а не идеальная инженерная стратегия: “попробовать оба варианта и посмотреть, какой сработает” вместо того, чтобы гадать один раз и рисковать полностью нерабочим устройством.

Если формат оказался бинарным. Класс увидел, что кадр есть (заголовок FD FC FB FA находится), но код пока не знает точное место дистанции внутри кадра — самая интересная методическая развилка: предложить сильным ученикам сосчитать по дампу, на каком по счёту байте после заголовка стоит число, похожее на реальное расстояние до датчика (в сантиметрах или похожих единицах), пока они физически двигают рукой на известном расстоянии. Это реальная работа реверс-инжиниринга протокола, а не учебное упражнение “понарошку”.

Практическое задание. Написать короткий отчёт от лица “инженера, тестирующего новую партию датчиков”: какой протокол подтверждён у датчика в классе, какие данные это дало, что стоит доработать в коде дальше (если формат бинарный и точное смещение дистанции не найдено).

Приложение: тайминг и оборудование

Урок 2 предполагает, что учитель заранее (не на самом уроке) один раз проверил, какой протокол выдаёт датчик в классе — иначе результат непредсказуем и урок может затянуться на анализ.

Презентация: радар присутствия HMMD (24 ГГц)

Слайд 1: Что это

HMMD — миллиметровый радар: излучает электромагнитную волну ~24 ГГц и анализирует отражённый сигнал. В отличие от PIR-датчика, который видит только резкое изменение теплового излучения, радар способен обнаруживать и почти неподвижного человека — по микро-движениям вроде дыхания.

Слайд 2: Чем отличается от PIR

• Обнаруживает не только движение, но и присутствие неподвижной цели.
• Измеряет дистанцию до цели, а не только факт “что-то изменилось”.
• Работает в темноте — принцип не связан с видимым или тепловым излучением.
• Как и любой датчик, имеет ограничения (см. THEORY.md) — не заменяет PIR во всех задачах.

Слайд 3: Путь сигнала

Радар сам генерирует и излучает СВЧ-сигнал → анализирует отражение по протоколу внутри своего чипа (FMCW, эффект Доплера) → передаёт готовый результат (дистанция/наличие цели) по UART → ESP32 разбирает поток в HmmdRadar::update() и обновляет состояние.

Слайд 4: Программная реализация

• Класс HmmdRadar принимает UART и распознаёт формат вывода датчика на лету (ASCII-строки или бинарные кадры) — официальная документация протокола на момент разработки была неполна, см. THEORY.md.
• Вотчдог isAlive() — если радар перестал присылать данные (обрыв UART), это будет заметно сразу, а не тихо “зависнет” на последнем известном состоянии.
• Hold time — простая защита от дребезга: цель не “пропадает” мгновенно при кратковременной потере сигнала на границе зоны.
• Режим сырого HEX-дампа в тестовом стенде — инструмент для проверки реального протокола на конкретном физическом экземпляре, а не только теория.

Слайд 5: Применение

• Системы освещения, которые не гаснут, пока человек сидит неподвижно (в отличие от PIR).
• Подсчёт присутствия в помещении.
• Робототехника — обнаружение препятствий с измерением дистанции.