От нажатия до доставки
Android и ПМ-1 работают как две части одной системы. Телефон отвечает за смысл события, узел — за его физическую доставку.
Приложение сохраняет событие и присваивает ему устойчивый идентификатор.
Пакет передаётся ПМ-1. При разрыве Bluetooth он остаётся в очереди телефона.
Прошивка выбирает прямой маршрут, назначенного ретранслятора или ограниченный резервный режим.
Получатель проверяет пакет, применяет событие и возвращает подтверждение по доступному пути.
Почему не обычный flood
В простой mesh-сети каждый узел, услышав новый пакет, повторяет его. На трёх устройствах это выглядит нормально. На десятках устройств повторов становится больше, чем полезных сообщений.
Проблема плотной сети
Несколько соседей начинают передавать одно и то же почти одновременно. Возникают коллизии, растёт очередь, а подтверждения и важные пакеты ждут освобождения канала.
Наш подход
Кандидаты на ретрансляцию ранжируются детерминированно. Основной ретранслятор отправляет первым, резервный ждёт, остальные включаются только при необходимости. Услышав успешный повтор, они отменяют свою передачу.
Для адресного пакета используется кэш маршрутов. Если сеть уже знает путь к узлу, сообщение идёт по этому пути, а не распространяется по всей комнате. Широковещательный режим остаётся резервом, а не основным способом доставки.
Primary relay
Первый кандидат с наилучшим детерминированным рангом.
Backup relay
Ждёт результат основного кандидата и включается при отсутствии повтора.
Emergency relay
Резерв для неполной карты соседей и разрыва маршрута.
Отмена по дубликату
Узел слышит успешную ретрансляцию и снимает собственную передачу.
MANET-логика без тяжёлого IP-стека
Архитектура сети выросла не только из LoRa mesh-проектов. В ней используются идеи мобильных ad hoc сетей, где маршруты меняются вместе с положением участников, а каждый узел способен стать промежуточным.
On-demand route discovery
Как в реактивных MANET-протоколах, адресный путь ищется тогда, когда он нужен. Route request ограничивается по времени и области распространения, а найденный route proof устанавливает проверяемый путь.
Route maintenance
Следующий hop подтверждает передачу. Таймаут, изменение поколения или потеря соседа инвалидируют маршрут и запускают ограниченное восстановление.
MPR-подобная ретрансляция
Как в OLSRv2, широковещательная доставка опирается на выбранное подмножество соседей. Coverage, качество связи, загрузка очереди и уже потраченное эфирное время важнее одного максимального RSSI.
Loop avoidance и freshness
Путь имеет поколение, срок жизни и подтверждённое происхождение. Старый или противоречивый маршрут не применяется как «почти подходящий».
AODV, OLSRv2 или Babel рассчитаны на маршрутизацию произвольных IP-пакетов и собственный служебный обмен. На LoRa 433 МГц это означало бы слишком крупные заголовки и слишком много control traffic. Поэтому ПМ-1 использует компактный специализированный протокол с теми же базовыми принципами, но с жёстким лимитом 128 байт и знанием приоритета события.
Эфирное время важнее красивой цифры скорости
LoRa хорошо передаёт короткие пакеты на дистанции, но канал остаётся медленным и общим. Поэтому прошивка считает длительность передачи, ограничивает телеметрию и защищает важные события.
Калиброванный airtime
Планировщик использует измеренное время от начала передачи до готовности радиомодуля, а не только теоретическую скорость UART.
QoS
SOS, приказы и подтверждения получают приоритет над заменяемой телеметрией позиции.
Мягкие лимиты очередей
Телеметрия не может занять всю память. Более важный пакет способен вытеснить устаревающую позицию, но не подтверждённое событие.
Адаптивная телеметрия
Позиция отправляется при движении, повороте или улучшении точности, а не на каждом тике GPS.
Что делает прошивка ПМ-1
Узел работает с установленной идентичностью и ключами комнаты. Случайное устройство не становится участником только потому, что знает частоту.
Пакеты проверяются до применения. Старый перехваченный пакет нельзя бесконечно проигрывать как новый.
Критичные данные сохраняются с ограниченным бюджетом памяти и восстанавливаются после перезапуска.
Радиообмен не должен замораживать BLE, диагностику и обработку входящих пакетов.
Роль, мощность, режим работы и допустимая нагрузка задаются профилем, а не разрозненными ручными настройками.
Прошивка считает таймауты, отменённые ретрансляции, переполнение очередей и ошибки радио. Это позволяет проверять сеть по фактам.
Как сеть ведёт себя при отказах
Маршрут, Bluetooth и отдельный узел могут пропасть в любой момент. Прошивка рассматривает это как штатное состояние полевой сети.
После своего окна включается backup-кандидат. Emergency-кандидаты остаются последним ограниченным резервом.
Адресная попытка завершается в пределах retry budget, после чего запускается ограниченный поиск нового пути.
Свежая важная информация вытесняет заменяемую телеметрию. Надёжные события не удаляются по правилам обычной позиции.
Дубликат отменяет лишнюю ретрансляцию и не создаёт повторное событие на Android.
Узел восстанавливает разрешённое состояние комнаты, профиль и ограниченные долговременные очереди.
Планировщик учитывает фактическое время E22 и переносит передачу без блокировки Bluetooth и входящего радио.