Тонкая настройка параметров Power‑Saving в BLE‑модулях для длительной работы от батареи

Когда пишешь прошивку для BLE-устройства, которое должно отработать год-два от батарейки CR2032, стандартные настройки оказываются неоптимальными. Модуль слишком часто просыпается, слишком долго находится в активной передаче или не использует энергосберегающие режимы. Разберём, как именно настраивать параметры, ради которых вы вообще взяли BLE, а не какой-нибудь Zigbee или 433 МГц.

Почему голый BLE-стек не экономит энергию

Bluetooth Low Energy — это протокол, который позволяет экономить энергию. Он не делает это сам по себе. Модуль по умолчанию работает как обычный радиопередатчик: просыпается, слушает эфир, передаёт, снова слушает. Если вы просто подключили модуль и отправили данные без настройки power-saving, вы получите рабочее устройство, но батарея разрядится в разы раньше, чем могла бы.

Реальная экономия достигается за счёт трёх вещей:

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

Режимы энергопотребления в BLE-модулях

Большинство BLE-чипов (nRF52, ESP32, DA145xx, CC26xx) предлагают несколько уровней сна. Чем глубже сон, тем меньше потребление, но тем дольше модуль выходит из него и тем меньше функциональности доступно в спящем состоянии.

Вот типичная иерархия, которую вы встретите в любом нормальном BLE-чипе:

1. Active (активный режим) — процессор работает на полной частоте, радио активно. Потребление порядка единиц миллиампер. В этом режиме модуль делает основную работу: передаёт, принимает, шифрует.
2. Idle / Light Sleep — процессор остановлен, но периферия и память работают, радио может быстро выйти. Потребление — десятки-сотни микроампер. Выход за микросекунды.
3. Deep Sleep / System OFF — процессор выключен, бо́льшая часть периферии обесточена, работает только RTC и, возможно, несколько GPIO для пробуждения. Потребление — от единиц до десятков микроампер. Выход за миллисекунды.
4. Full Power Off — потребление на уровне наноампер, но единственный способ проснуться — аппаратный сброс или сигнал с внешнего пина. Подходит только для устройств, которые «спят» неделями и просыпаются по кнопке.

Задача разработчика — как можно дольше удерживать модуль в Deep Sleep, минимизируя переходы в Active.

Реклама — что экономить нельзя, но можно оптимизировать

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

Что можно сделать:

• Использовать разные интервалы в разных состояниях. Когда устройство никому не нужно, рекламируйте раз в 1–2 секунды. Когда устройство только включили или к нему недавно подключались — можно участить до 200–500 мс на короткое время (30–60 секунд).
• Отключать рекламу без необходимости. Если устройство не предполагает поиска со стороны смартфона, не надо его рекламировать. Незачем.
• Отслеживать отсутствие подключений. Если в течение определённого времени никто не подключился, увеличивайте интервал или сворачивайте рекламу ещё агрессивнее.

Параметры подключения: баланс между отзывчивостью и автономностью

После подключения к телефону модуль начинает «слушать» эфир в определённые окна. И здесь есть несколько настроек, которые критически влияют на энергопотребление.

Connection Interval (интервал подключения)

Это периодичность, с которой модуль обязан «ехать» (принимать пакеты от мастера). Минимум 7.5 мс, максимум – до нескольких секунд. Чем меньше интервал, тем быстрее происходит обмен данными и тем выше потребление. Для датчика, который отправляет показания раз в минуту, интервал в 7.5 мс — это расточительность.

В моей практике для носимых устройств и носимой электроники частый интервал оправдан (20–50 мс), для домашних датчиков температуры или сенсоров открытия вполне достаточно 500 мс – 1 с.

Slave Latency (задержка ведомого)

Параметр, о котором часто забывают, а зря. Он позволяет модулю «пропускать» окна подключения. Если установлен Slave Latency = 10, модуль может не отвечать на пакеты мастера в течение 10 окон из 11, оставаясь в спящем режиме. Для устройств, которые не обязаны передавать данные немедленно, это мощный инструмент.

Правило: чем выше Slave Latency, тем дольше работает батарея.

Supervision Timeout (таймаут потери подключения)

Логично связан с предыдущими двумя параметрами. Это максимальная продолжительность, которую модуль будет считать, что подключение живо, даже если мастер (телефон) пропал за пределами приёма. По умолчанию часто стоит несколько секунд, но если Slave Latency большой, то таймаут должен быть не меньше, чем Interval * (1 + Latency). Иначе модуль будет постоянно терять подключение без реальных причин.

Мощность передачи и чувствительность приёма

BLE позволяет настраивать мощность передатчика в диапазоне примерно от −20 дБм до +20 дБм в зависимости от конкретного чипа. На максимальной мощности модуль потребляет заметно больше, особенно при передаче.

Если устройство работает рядом с телефоном (браслет, наушник), мощностью +8…+20 дБм вы не выиграете ничего, но потребление может вырасти в разы. Для комнатных условий часто достаточно −4…+4 дБм.

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

Какие параметры дают наибольшую экономию

Если показать влияние разных настроек на время автономной работы, получится примерно так:

Параметр	Что изменяет	Во сколько раз может продлить время работы	Где чаще всего ошибаются
Интервал рекламы	Частота просыпаний в рассыпах между подключениями	2–10× при переходе от 100 мс до 1–2 с	Устанавливают «для надёжности» слишком частый
Период опроса эфира в подключении (Connection Interval)	Частота приёмных окон после установления связи	2–8× при переходе от 7.5 мс до 500 мс – 1 с	Копируют значения из примеров datsheet без анализа
Slave Latency	Число пропущенных окон, пока модуль может спать	До 10–20× при переходе от 0 до 10–30	Оставляют нулевым, потому что «так задано»
Глубина сна (Sleep mode)	Доля времени, которую чип проводит без работы процессора	3–30× в сравнении с отсутствием сна вообще	Не используют или мешают источники пробуждения
Мощность передачи	Потребление при передаче пакета	До 2–5× в зависимости от дальности	Не адаптируют под реальные условия
Объём передаваемых данных в одном событии	Время, которое модуль проводит в активной передаче	1.5–3× при грамотной агрегации	Передают каждое изменение температуры отдельно

Как выстроить стратегию энергопотребления для своего устройства

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

Шаг 1. Честно посмотреть, как устройство живёт в реальности

Любая оптимизация начинается с ответа: как часто нужно передавать данные и с какой задержкой это критично? Датчик протечки воды может молча спать неделями, а потом за секунду отправить тревогу. Фитнес-браслет должен каждые десятки миллисекунд отдавать данные акселерометра и при этом работать сутки от маленькой батареи.

Шаг 2. Выбрать сценарий энергопотребления

Для BLE-модулей обычно доступны несколько предопределённых конфигураций, либо вы строите свою:

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

Шаг 3. Настроить параметры под выбранный сценарий

• Для первого сценария — Connection Interval 50–200 мс, Slave Latency 0–2, реклама 100–200 мс в активной фазе.
• Для второго — реклама 1–2 с, Interval между сеансами подключения 200–500 мс, Slave Latency до 20–30 в зависимости от требований к свежести данных.
• Для третьего — реклама может ещё более редкой, а Slave Latency не играет роли, потому что устройство само инициирует обмен.

Связанные настройки, о которых забывают

Помимо очевидных параметров подключения и рекламы, есть ещё несколько мест, где «утекает» энергия:

• Длительность рекламного события. Даже при редкой рекламе её можно сделать более или менее длинной. Сократите время активной фазы до необходимого минимума.
• Источники пробуждения. Каждый таймер, каждый сработавший GPIO может вытащить модуль из Deep Sleep. Оставьте только реально нужные источники. Лишний RTC-будильник разрядит батарею.
• Периферия в режиме сна. Аналого-цифровые преобразователи, компараторы, интерфейсы вроде I²C или SPI — всё это необходимо отключать перед уходом в сон. Если вы не отключите питание датчика через MOSFET или не переведёте его в power-down режим, модуль может спать, а датчик — потреблять, сводя на нет все усилия.
• Повторные передачи и переподключения. Зацикленные попытки рекламироваться при потере партнёра тоже убивают батарею. Введите ограничение по времени или числу попыток, а потом уходите в глубокий сон до следующего внешнего события.

Частые ошибки при настройке Power‑Saving

Копипараметры из примеров разработчика. Даташит и SDK дают примеры, приближённые к «универсальным», часто с максимальной отзывчивостью и минимальными таймаутами. Это удобно для отладки, но не для работы от батареи.

Несогласованные параметры между модулем и телефоном. Модуль может предлагать хороший Slave Latency, но Android-приложение согласится только на 0–4. Если вы не проверяте окончательные принятые параметры через HCI лог или sniffer, вы не знаете, в каком режиме реально работаете.

Тестирование «на столе». Если датчик лежит в метре от телефона, он никогда не увидит проблем с чувствительностью, которые возникнут в реальном использовании. И если вы выставили низкую мощность и высокий Slave Latency, это может проявиться только на расстоянии или при зашумлённом эфире — потерей пакетов и внеочередными пробуждениями для переподключения.

Как проверить, что настройки сработали

Без реальных замеров вы не узнаете, попали ли вы в желаемые микроамперы.

1. Профилировщик потребления. Используйте анализатор тока с высоким разрешением (Nordic PPK, Qoitech Otii Arc, Keysight N6705C или даже простой осциллограф с токовыми клещами, если хватает полосы). Вам важно видеть разницу между активной фазой и сном.
2. Лог HCI. Подключите BLE-сниффер (nRF Sniffer, Ellisys, Frontline) и посмотрите, какие параметры реально подтверждены стороной телефона. Часто оказывается, что выставленные числа не те, которые пошли в эфир.
3. Подсчёт времени жизни батареи. Не ограничивайтесь измерением тока в статике — определите профиль нагрузки (сколько времени в каком режиме проводит устройство за сутки типичной работы) и рассчитайте ожидаемый срок службы с учётом саморазряда батареи.

Практические рекомендации

Вот короткий чек-лист, который я держу в голове при доработке прошивок для BLE-устройств с батарейным питанием:

• Устройство по умолчанию должно спать. Не передавать — значит не просыпаться.
• Интервал рекламы и интервал подключения подбираются с учётом реальной частоты обмена данными, а не из желания «на всякий случай взять покороче».
• Slave Latency — друг, когда ведомый не обязан быть на связи в каждом окне.
• Сначала определите профиль работы и только потом настраивайте мощность передачи и количество рекламных каналов.
• Любые внешние компоненты (датчики, светодиоды, модули памяти — это всё должно обесточиваться или переводиться в спящий режим, пока вы спите.
• Каждый источник пробуждения должен быть осмысленным и предсказуемым.
• Проверяйте реальные параметры соединения через лог HCI, а не только то, что вы отправили в HCI.

Что в итоге

Тонкая настройка Power‑Saving — это не магический переключатель, а совокупность согласованных параметров рекламы, подключения, сна и периферии. Если вы уже пишете под конкретный BLE-чип, возьмите за привычку: для каждой новой прошивки сначала честно определить реальный сценарий использования, а затем под него подбирать значения Interval, Latency, Timeout и другие.

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