Почему 100 узлов в Meshtastic не означают связь со 100 узлами

Это первая ошибка в диагностике Meshtastic.

Список Nodes показывает не только устройства, с которыми ваш радиомодуль способен прямо сейчас установить надёжную прямую связь. Туда попадают узлы, информация о которых была получена через mesh.

Поэтому ситуация вполне нормальная:

• в списке 100 узлов;
• напрямую слышны только несколько;
• часть находится в двух или трёх hops;
• часть давно не передавала пакеты;
• некоторые временно выключены;
• некоторые были услышаны через мобильный узел или временный маршрут.

Количество записей в NodeDB нельзя использовать как показатель реального покрытия.

Намного полезнее смотреть:

• Last Heard;
• Hops Away;
• SNR;
• RSSI;
• успешность direct messages;
• результат traceroute;
• Channel Utilization;
• Air Utilization TX.

Сообщение отправлено, Acknowledged и доставлено - не всегда одно и то же

При диагностике важно понимать статусы сообщений.

Для широковещательного сообщения Meshtastic может получить подтверждение того, что пакет был услышан и ретранслирован другим участником mesh. Это ещё не является гарантией, что его получили абсолютно все устройства сети.

Для direct message предусмотрено подтверждение от конечного получателя.

Если приложение показывает Max Retransmission Reached, узел не получил ожидаемого подтверждения после предусмотренных попыток передачи.

Причины могут быть совершенно разными:

• адресат выключен;
• маршрут распался;
• пакет потерялся из-за коллизии;
• обратный ACK не смог пройти назад;
• исчерпан Hop Limit;
• эфир перегружен;
• передающий или принимающий узел имеет плохой радиотракт;
• часть сети использует несовместимые радионастройки.

Поэтому ошибка доставки сама по себе не говорит, какой именно узел неисправен.

Главное ограничение Meshtastic - не количество устройств, а эфир

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

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

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

Но полностью исключить коллизии невозможно.

Представим небольшую сеть:

Теперь сеть выросла:

Добавим несколько неправильно настроенных ROUTER:

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

Что такое ChUtil и AirUtilTX

Для диагностики Meshtastic есть два особенно полезных показателя.

Если Channel Utilization начинает заметно расти, это повод искать источник трафика.

Но нельзя использовать одно универсальное число в качестве границы между «хорошей» и «плохой» сетью.

Например, разработчики Meshtastic отдельно приводят ориентиры для инфраструктурной роли ROUTER_LATE: если на таком узле ChUtil превышает 25%, либо AirUtilTX достигает примерно 7-8%, рекомендуется пересмотреть использование этой роли.

Это рекомендация именно в контексте ROUTER_LATE, а не правило, что любая сеть перестаёт работать при 25%.

Для диагностики полезнее смотреть динамику:

• каким был ChUtil раньше;
• что происходит вечером или во время активности пользователей;
• увеличивается ли он после запуска конкретного узла;
• падает ли доставка одновременно с ростом ChUtil;
• какой узел показывает высокий AirUtilTX.

Почему LongFast может стать проблемой

LongFast остаётся популярным универсальным preset Meshtastic. Он даёт хороший запас по радиолинии, поэтому удобен для небольших и разреженных сетей.

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

Чем больше время передачи одного пакета:

• тем дольше занят общий канал;
• тем меньше пакетов можно передать за одинаковое время;
• тем выше вероятность пересечения передач;
• тем больше задержка при нескольких hops.

Разработчики Meshtastic отдельно обращали внимание на проблему плотных сетей LongFast и рекомендовали рассматривать более быстрые presets там, где число участников и объём трафика уже становятся большими.

В качестве ориентиров для плотных сетей рассматриваются MediumSlow, MediumFast, ShortSlow и ShortFast.

Стоит ли всем переходить с LongFast?

Нет.

Для небольшой сети, удалённых объектов, похода или местности с редкими узлами LongFast может оставаться хорошим вариантом.

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

• в зоне слышимости много активных устройств;
• Channel Utilization регулярно высокий;
• сообщения приходят с большой задержкой;
• растёт количество потерянных пакетов;
• пользователи активно отправляют Position и Telemetry;
• радиолинии имеют достаточный запас и не требуют максимального link budget.

Официальная команда Meshtastic в своём разборе приводит примерно 60 узлов как один из поводов задуматься о более быстром preset, особенно если устройства находятся относительно близко друг к другу. Но это не жёсткая техническая граница: сеть из 40 очень активных устройств может быть тяжелее для эфира, чем сеть из 100 редко передающих.

Ошибка №1 в больших сетях: поставить везде ROUTER

Название ROUTER звучит так, будто эта роль автоматически делает сеть лучше.

На практике это одна из наиболее опасных ошибок настройки Meshtastic.

ROUTER и REPEATER имеют повышенный приоритет при ретрансляции. Они предназначены для действительно хороших инфраструктурных точек.

Если ROUTER стоит:

• на подоконнике первого этажа;
• в квартире за железобетоном;
• в металлическом шкафу;
• в автомобиле;
• на балконе среди плотной застройки;
• просто потому, что владелец захотел «усилить mesh»;

он способен заставлять другие узлы отказываться от более удачной ретрансляции.

В результате маршрут может стать хуже.

Актуальные рекомендации проекта предлагают большинству пользователей оставлять роли:

• CLIENT;
• CLIENT_MUTE;
• CLIENT_BASE.

ROUTER, REPEATER и ROUTER_LATE нужны только тогда, когда понятно, какую конкретную проблему топологии они решают.

CLIENT_BASE: полезный вариант для дома

Представим типичную ситуацию:

• один хороший узел находится на крыше или чердаке;
• карманный узел находится внутри дома;
• в доме есть ещё несколько личных устройств;
• рядом уже существует достаточно плотная mesh-сеть.

Не обязательно превращать крышный узел в ROUTER.

Для такого сценария появился CLIENT_BASE. Он может отдавать приоритет сообщениям избранных личных узлов, при этом не ведёт себя как агрессивный глобальный ROUTER для всей окружающей сети.

Это более аккуратный подход для домашней базовой станции.

А когда нужен ROUTER_LATE

ROUTER_LATE предназначен для специфической инфраструктурной задачи: закрыть участок сети, который из-за рельефа или препятствий плохо связан с основной mesh-инфраструктурой.

Например:

ROUTER_LATE может помогать такому сегменту, но он не является универсальной ролью для домашней крыши или автомобиля.

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

Отсюда возникает парадокс: ретранслятор виден, работает и передаёт часть сообщений, но остальные сообщения периодически исчезают.

Почему увеличение Hop Limit до 7 не лечит плохую сеть

Логика кажется очевидной: три hops мало, поставим семь и сообщение сможет пройти дальше.

Но каждый дополнительный hop потенциально означает ещё одну передачу пакета.

Увеличение Hop Limit:

• не улучшает сигнал;
• не исправляет плохую антенну;
• не уменьшает коллизии;
• не ускоряет сеть;
• может увеличить количество ретрансляций.

Если необходимый адресат находится в двух hops, установка семи не делает этот маршрут лучше.

Высокий Hop Limit полезен только тогда, когда топология действительно требует длинной цепочки.

Почему хороший mesh старается не повторять один пакет всеми узлами

Meshtastic использует Managed Flooding.

Когда несколько CLIENT слышат пакет, они не обязаны все немедленно его повторить. Используются задержки и оценка SNR. Узлы, способные потенциально перенести пакет дальше, получают преимущество.

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

Именно поэтому добавление ещё десяти ретрансляторов не означает десятикратное улучшение покрытия.

Задача правильного mesh - использовать минимально необходимое количество радиопередач для доставки пакета.

Куда исчезает эфир, если никто почти не пишет сообщения

Ещё одна распространённая ситуация: в чате тишина, но Channel Utilization остаётся высоким.

Потому что пользовательские сообщения - только часть трафика.

По сети также могут передаваться:

• NodeInfo;
• Position;
• Device Telemetry;
• Environment Telemetry;
• маршрутная информация;
• служебные подтверждения;
• traceroute;
• Store & Forward heartbeat;
• MQTT-трафик;
• данные дополнительных модулей.

Каждый отдельный пакет маленький. Но если таких устройств сотня, а информация периодически повторяется через несколько hops, суммарная нагрузка становится заметной.

Position

Для мобильных узлов координаты полезны. Для стационарного устройства частое обновление положения обычно не несёт такой же ценности.

Перед увеличением частоты Position Broadcast стоит задать простой вопрос: действительно ли остальным участникам нужны настолько частые координаты?

Telemetry

Температура, напряжение аккумулятора и другие показатели полезны для мониторинга. Но чрезмерно частая телеметрия на десятках устройств превращается в постоянный фоновый трафик.

Traceroute

Traceroute полезен при диагностике, но массово и постоянно запускать его в загруженной сети не стоит. Диагностический инструмент тоже создаёт пакеты.

Store & Forward

Если используется Store & Forward Server, стоит проверить необходимость его периодического heartbeat. В документации Meshtastic отдельно предусмотрена возможность отключить heartbeat для уменьшения сетевого трафика.

MQTT может незаметно добавить нагрузку

MQTT позволяет соединить Meshtastic с IP-сетью и внешними сервисами. Это удобно для Home Assistant, Node-RED, телеметрии и удалённых интеграций.

Но здесь есть важное правило:

Если интернет-система начинает массово отправлять данные обратно в LoRa, физическая пропускная способность радиоканала от этого не увеличивается.

Поэтому при неожиданной перегрузке нужно проверить:

• включён ли MQTT;
• какие каналы разрешено передавать;
• какие типы пакетов возвращаются из MQTT в LoRa;
• не соединены ли через интернет несколько очень больших mesh-сегментов;
• не создаёт ли автоматизация избыточный поток сообщений.

Если после отключения MQTT Channel Utilization заметно снизился, искать проблему только в антеннах уже бессмысленно.

Иногда проблема вообще не в перегрузке

Допустим, ChUtil невысокий, вокруг немного активных узлов, но сообщения конкретного устройства всё равно регулярно не доставляются.

Тогда нужно переходить от сетевого уровня к радиотракту.

Проверьте антенну

Типичные проблемы:

• антенна рассчитана на другой диапазон;
• некачественная комплектная антенна;
• плохой контакт SMA/IPEX;
• повреждён переходник;
• антенна находится рядом с металлом;
• антенна закрыта телом человека;
• неправильно подобран противовес;
• внешняя антенна подключена длинным кабелем с большими потерями.

Высота часто важнее мощности

LoRa хорошо работает со слабыми сигналами, но железобетон, рельеф, металл и низкое расположение антенны всё равно остаются препятствиями.

Узел на втором этаже внутри здания и тот же узел с корректно установленной антенной выше крыши могут иметь совершенно разное покрытие.

Поэтому плохую топологию нельзя надёжно исправить только настройками прошивки.

RX и TX могут быть несимметричными

Иногда пользователь видит удалённые узлы, но они не получают его сообщения.

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

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

Почему RSSI нельзя оценивать без SNR

Для LoRa одного RSSI недостаточно.

SNR показывает отношение полезного сигнала к шуму. Благодаря особенностям LoRa связь может сохраняться даже при отрицательном SNR.

Поэтому при сравнении узлов полезно смотреть сразу:

• RSSI;
• SNR;
• прямой это пакет или ретранслированный;
• стабильны ли показатели во времени;
• проходит ли двусторонняя передача.

Один случайно принятый пакет с далёкого узла ещё не является устойчивой радиолинией.

Почему traceroute иногда не проходит, хотя сообщения проходят

Это не обязательно противоречие.

Mesh динамический. Узлы меняют положение, появляются и исчезают, эфир занят разными пакетами, а маршруты direct messages могут изменяться.

Кроме того, traceroute сам требует обмена служебными пакетами. В загруженной или пограничной сети вероятность потерять один из этапов диагностики может быть выше.

Поэтому traceroute лучше использовать как один из инструментов, а не как единственный критерий работоспособности.

Почему очистка NodeDB не улучшает радиосвязь

Очистка NodeDB полезна, если список заполнен старыми или некорректными записями и мешает анализировать ситуацию.

Но сама по себе она:

• не освобождает радиоканал;
• не улучшает антенну;
• не изменяет расположение узлов;
• не устраняет чужие ROUTER;
• не уменьшает общий ChUtil вокруг.

После очистки список станет аккуратнее, но физическая mesh-сеть останется той же.

Пошаговая диагностика Meshtastic, если сообщения не доходят

Когда переход с LongFast действительно может помочь

Смена preset оправдана, если проблема подтверждена измерениями, а не ощущением.

Хороший сценарий:

1. зафиксировать ChUtil в часы минимальной и максимальной нагрузки;
2. оценить процент успешной доставки сообщений;
3. проверить наиболее длинные необходимые радиолинии;
4. временно перевести контролируемую группу узлов на более быстрый preset;
5. снова измерить доставку, задержку и покрытие;
6. сравнить результаты.

Так можно понять, действительно ли сеть ограничена airtime или проблема находится в другом месте.

Переносить всю городскую mesh-сеть на другой preset без координации нельзя: часть пользователей останется на прежних настройках и сеть фактически разделится.

Чего не нужно делать

• Не выставлять всем ROUTER. Это способно сделать сеть хуже.
• Не увеличивать Hop Limit до максимума без причины.
• Не включать максимально медленный preset только ради дальности.
• Не увеличивать частоту Position и Telemetry без необходимости.
• Не считать любое устройство в NodeDB доступным прямо сейчас.
• Не оценивать качество радиолинии по единственному случайно принятому пакету.
• Не менять регион на чужой ради большей мощности или другой частоты.
• Не отключать ограничения duty cycle ради эксперимента.

Что с частотами и мощностью в России

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

Для устройств малого радиуса действия в России применяются требования законодательства об использовании радиочастотного спектра и решения Государственной комиссии по радиочастотам.

Роскомнадзор указывает в числе используемых для соответствующих устройств полосы 864-865 МГц, 866-868 МГц и 868,7-869,2 МГц. Но допустимые условия зависят от конкретного диапазона, назначения оборудования, мощности, ширины полосы и режима работы.

Поэтому фраза «868 МГц разрешено» сама по себе недостаточна для выбора настроек Meshtastic.

В самой прошивке существуют параметры, позволяющие менять регион, мощность и ограничения duty cycle. Наличие технической возможности не означает законность её использования.

Главный вывод

Если Meshtastic показывает 100 узлов, но сообщения не доходят, не начинайте с покупки более мощного передатчика.

Сначала выясните четыре вещи:

1. кого вы реально слышите;
2. насколько занят радиоканал;
3. кто и сколько ретранслирует;
4. в каком состоянии ваш радиотракт.

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

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