Понятия и логика сети
Advert (объявление себя)
В MeshCore “advert” — это явное “объявление” ноды в эфир:
- имя/идентичность;
- (опционально) позиция;
- публичный ключ.
Клиентские ноды обычно не “адвертят” сами по таймеру — чаще это действие пользователя. Repeater может периодически отправлять advert, чтобы его видели клиенты.
Zero hop vs Flood
- Zero hop — advert слышат только те, кто напрямую в радиусе.
- Flood — advert может быть подхвачен повторителями и разнесён дальше (это дороже по airtime).
Есть ли лимит хопов?
В прошивке обычно есть внутренний максимум (встречается значение порядка десятков хопов), но в реальных условиях упираются в тайминги, помехи и коллизии, поэтому “до теоретического потолка” почти никогда не доходят.
Почему MeshCore “не как Meshtastic”: про ретрансляцию
Один из ключевых принципов MeshCore: клиенты по умолчанию не ретранслируют.
Ретрансляцией занимаются:
- repeaters;
- а также room server, если ему явно включили ретрансляцию (обычно это не рекомендуют).
Цель такого подхода — не превращать сеть в постоянный flood‑шторм, где сообщения теряются из‑за коллизий.
Дальность, покрытие и цепочки ретрансляторов
На качество связи сильнее всего влияют:
- расположение (высота, “видимость” в сторону сети, отсутствие экранирующих препятствий);
- антенна (реальная настройка под диапазон, качество кабеля/разъёмов);
- правильная частота/пресет региона (совпадение с сетью сообщества).
По наблюдениям сообществ, в сетях с развитой инфраструктурой возможны длинные цепочки repeaters, а количество промежуточных нод может доходить до десятков (встречается ориентир до 64). Но в реальности вы почти всегда упираетесь раньше: в помехи, коллизии, “дырявое” покрытие и неудачное размещение отдельных нод.
Маршруты: как MeshCore ищет путь и почему потом становится “быстрее”
Упрощённая модель:
- Первое сообщение до неизвестного адресата часто уходит flood‑маршрутизацией, чтобы “дотянуться” любым путём.
- Получатель формирует отчёт о доставке/пути (через какие repeaters прошло).
- Этот отчёт возвращается обратно (также flood), и отправитель сохраняет маршрут.
- Следующие сообщения отправитель может пытаться посылать по известному пути, а повторители будут ретранслировать только если “подходят” под путь — это снижает лишние дубли и экономит эфир.
Что если маршрут был через мобильный repeater и он уехал?
Обычно клиент попробует использовать известный (но уже сломанный) путь, несколько раз не получит доставки, после чего сбросит путь и на попытке “в конце” снова попробует flood, чтобы найти новый маршрут. Это поведение может настраиваться в клиенте.
Групповые каналы: почему они “фладят”
Групповые чаты (каналы) по смыслу “всем участникам”, а не “точка‑точка”. Для них нет заранее известного пути на конкретного адресата, поэтому доставка обычно требует flood‑механики.
Администраторы repeaters могут ограничивать flood‑трафик (например, по хопам) — это часть “политики” конкретного repeaters.
BW / SF / CR простыми словами
Это базовые параметры LoRa, которые напрямую влияют на дальность, скорость и нагрузку на эфир.
- BW (Bandwidth, ширина полосы): шире BW → выше скорость, но обычно хуже чувствительность (меньше запас по связи).
- SF (Spreading Factor): выше SF → “дальнобойнее/устойчивее”, но медленнее и больше airtime.
- CR (Coding Rate): больше CR → больше избыточности (надёжнее), но медленнее и больше airtime.
Практический вывод:
- “медленнее” часто значит “дальше”, но почти всегда значит “дороже для сети”;
- в городской/плотной сети слишком “дальнобойные” параметры могут ухудшить доставку всем.
Ключ публичного канала (факт)
В MeshCore встречается “публичный” канал с известным ключом. Один и тот же ключ иногда показывается в разных форматах:
- в приложении может быть hex:
8b3387e9c5cdea6ac9e5edbaa115cd72
- на T‑Deck может использоваться base64:
izOH6cXN6mrJ5e26oRXNcg==
Публичный канал с известным ключом — это не приватность. Для приватной связи используйте собственные секреты/каналы и аккуратно распространяйте параметры.