Перейти к основному содержимому

Понятия и логика сети

В MeshCore “advert” — это явное “объявление” ноды в эфир:

  • имя/идентичность;
  • (опционально) позиция;
  • публичный ключ.

Клиентские ноды обычно не “адвертят” сами по таймеру — чаще это действие пользователя. Repeater может периодически отправлять advert, чтобы его видели клиенты.

Zero hop vs Flood

  • Zero hop — advert слышат только те, кто напрямую в радиусе.
  • Flood — advert может быть подхвачен повторителями и разнесён дальше (это дороже по airtime).

Есть ли лимит хопов?

В прошивке обычно есть внутренний максимум (встречается значение порядка десятков хопов), но в реальных условиях упираются в тайминги, помехи и коллизии, поэтому “до теоретического потолка” почти никогда не доходят.

Почему MeshCore “не как Meshtastic”: про ретрансляцию

Один из ключевых принципов MeshCore: клиенты по умолчанию не ретранслируют.

Ретрансляцией занимаются:

  • repeaters;
  • а также room server, если ему явно включили ретрансляцию (обычно это не рекомендуют).

Цель такого подхода — не превращать сеть в постоянный flood‑шторм, где сообщения теряются из‑за коллизий.

Дальность, покрытие и цепочки ретрансляторов

На качество связи сильнее всего влияют:

  1. расположение (высота, “видимость” в сторону сети, отсутствие экранирующих препятствий);
  2. антенна (реальная настройка под диапазон, качество кабеля/разъёмов);
  3. правильная частота/пресет региона (совпадение с сетью сообщества).

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

Маршруты: как MeshCore ищет путь и почему потом становится “быстрее”

Упрощённая модель:

  1. Первое сообщение до неизвестного адресата часто уходит flood‑маршрутизацией, чтобы “дотянуться” любым путём.
  2. Получатель формирует отчёт о доставке/пути (через какие repeaters прошло).
  3. Этот отчёт возвращается обратно (также flood), и отправитель сохраняет маршрут.
  4. Следующие сообщения отправитель может пытаться посылать по известному пути, а повторители будут ретранслировать только если “подходят” под путь — это снижает лишние дубли и экономит эфир.

Что если маршрут был через мобильный 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==
warning

Публичный канал с известным ключом — это не приватность. Для приватной связи используйте собственные секреты/каналы и аккуратно распространяйте параметры.