Защо е критично важно да се минимизира Broadcast трафикът в Meshtastic
Meshtastic е проектиран да работи в среди с ограничен радио ресурс – ниска скорост, споделен ефир и устройства, често захранвани от батерии. Поради това Broadcast трафикът („до всички“) трябва да се поддържа до абсолютния минимум, за да се запази стабилността, обхватът и полезният капацитет на мрежата.
Тази публикация обяснява защо и как да се ограничи Broadcast трафикът, с фокус върху:
Node Info BroadcastPosition BroadcastMap Report- Автоматични тракери и сензори
- Разграничение между радио и MQTT трафик
Какво представлява Broadcast трафикът
Broadcast съобщение в Meshtastic се:
- получава от всички възли в обхват
- ретранслира от рутери (в зависимост от hop limit)
- заема ефирно време (airtime) за всички
Едно ненужно Broadcast съобщение не е просто „още един пакет“ – то:
- блокира канала
- увеличава колизиите
- влошава доставката на реални съобщения
- намалява живота на батериите
Node Info Broadcast – кога и колко често
Какво е Node Info
Node Info съдържа:
- Node ID
- Име / Short name
- Роля (Client, Router, Repeater и т.н.)
- Хардуерна информация
Това е статична информация, която рядко се променя.
Препоръки
📡 Рутери и репитери
- Минимум: на всеки 6 часа
- По-често е излишно и вредно
🔋 Клиенти (портативни устройства)
- 12–24 часа са напълно достатъчни
❌ Грешна практика: Node Info на всеки 10–30 минути
Position Broadcast – особено критичен трафик
Статични устройства (рутeри, базови станции)
Ако устройството не се движи:
✅ Препоръка:
- Position report на 72 часа (максималната опция)
Причина:
- Позицията е постоянна
- Повтарящи се координати = чист шум в ефира
Мобилни устройства
- Само ако има реално движение
- С разумен интервал (напр. 5-15 минути)
❌ Грешна практика:
- Статичен рутер, който излъчва позиция на всеки 5–10 минути
Map Report – защо трябва да е MQTT-only
Map Report е предназначен основно за:
- визуализация
- статистика
- външни системи
❗ Проблемът
Map Report няма място в LoRa mesh-а като Broadcast:
- големи payload-и
- никаква оперативна полза за радиомрежата
✅ Правилният подход
Map Report → само към MQTT- НЕ като Broadcast към всички mesh възли
Това важи с особена сила за:
- градски мрежи
- EU868 / EU433 канали
Тракери и автоматични сензори – най-честият проблем
Типичен лош сценарий
- GPS тракер или сензор
- изпраща данни на всеки 60 секунди
- като Broadcast (всички)
Резултат:
- запушен канал
- драстично повишен airtime
- други възли „изчезват“
✅ Добра практика
📡 Данни за инфраструктура / логване
- Изпращане при поискване
- Без Broadcast
📍 Тракери
- Минимална честота
- Само при значима промяна
- По възможност direct / личен канал , ограничено, не global broadcast
❌ Meshtastic не е LTE мрежа – ефирът не е безкраен
👉 Всичко, което не е критично за локалната mesh комуникация, трябва да отива в MQTT, а не в Broadcast.
Заключение
Минимизирането на Broadcast трафика не е „препоръка“, а необходимост за:
- стабилна мрежа
- по-голям обхват
- по-малко колизии
- по-дълъг живот на батериите
Обобщени препоръки
- 📦 Node Info: ≥ 6ч за рутери
- 📍 Position (статични): 72ч
- 🗺️ Map Report: само MQTT
- 🤖 Тракери/сензори: без Broadcast, минимална честота
Една дисциплинирана мрежа е работеща мрежа.
Meshtastic работи най-добре, когато ефирът се уважава.