От примера LoRa на 6 км к надёжной FUOTA: дальность, airtime и Delta OTA в мандариновом саду

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

Кратко

Сначала задача кажется простой: может ли сенсорный узел на базе LoRa передавать данные из мандаринового сада на шлюз? Но после выхода продукта в поле возникает более сложный вопрос: как надёжно передать через то же соединение сотни килобайт прошивки?

В качестве отправной точки это исследование использует пример приблизительно 6 км для SF9/125 кГц из технического обзора Semtech. Далее объясняется, почему это значение нельзя напрямую переносить в густой мандариновый сад, и рассматривается компромисс между дальностью и скоростью передачи, задаваемый spreading factor (SF) и bandwidth (BW). Мы также покажем, почему link budget — это не сложение выходных мощностей двух устройств: нужно совместно учитывать активный передатчик, чувствительность второго приёмника, коэффициенты усиления антенн и потери среды. Затем мандариновый сад выбирается среди нескольких сельскохозяйственных сценариев, а также рассматривается высота антенны. В заключении предлагаются Delta OTA вместо полного образа, многошаговое обновление и выбор delta-маршрута на стороне сервера.

Главный вывод прост: успех FUOTA зависит не только от максимальной дальности. Надёжная downlink-ёмкость, общий airtime, duty cycle, потери пакетов, размещение шлюза, проверка bootloader и оркестрация обновления должны проектироваться вместе.

1. Почему пример Semtech примерно на 6 км не является реальной дальностью в саду

В техническом обзоре LoRa компании Semtech приведён пример примерно 6 км для SF9/125 кГц. В том же документе отмечается, что такие значения зависят от рельефа (Semtech, LoRa and LoRaWAN: A Technical Overview). Это ориентир для конкретной настройки модуляции и идеализированных условий открытой местности, а не гарантия надёжной двусторонней связи в мандариновом саду.

Основные причины:

1. Распространение в прямой видимости на открытой местности отличается от NLOS-распространения между рядами деревьев.
2. Антенна сенсора рядом с землёй отличается от поднятой антенны шлюза, использованной в каталожном тесте.
3. Заявленная производителем дальность зависит от конкретных SF/BW, размера пакета, антенны и мощности.
4. Рабочая дальность должна учитывать более слабое направление двустороннего канала и целевую долю успешных пакетов.
5. Влажность, дождь, полив, плотность листвы и направление рядов меняются в течение сезона.

Полевые исследования в мандариновых и других садах изучали влияние листьев, ветвей, стволов, геометрии рядов и высоты антенн на потери распространения (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). Поэтому таблица Semtech на 6 км может быть исходной гипотезой для полевых измерений, но не итогом.

Центральный вопрос меняется следующим образом:

Во что превращаются открытый ориентир Semtech на 6 км, link margin, доля успешных пакетов и airtime FUOTA внутри густого мандаринового сада?

2. Как SF и BW меняют дальность?

На физическом уровне LoRa spreading factor определяет, насколько данные распределяются по chirp-символам. В обзоре Semtech объясняется, что в диапазоне SF7–SF12 увеличение SF повышает чувствительность приёмника, но снижает bit rate и скорость передачи (Semtech, LoRa and LoRaWAN: A Technical Overview).

Связь можно представить так:

Числовая таблица SF/BW и дальности для мандаринового сада

Ниже приведена инженерная оценка для планирования в цитрусовом саду высотой примерно 2,5–4 м с густой, орошаемой листвой, сохраняющейся круглый год. В ячейках указан формат дальность (м) / брутто PHY bit rate (кбит/с); для надёжного проектирования следует ориентироваться на нижнюю границу диапазона. В расчётном сценарии предполагаются E22-900M22S/SX1262, 868 МГц, CR 4/5, усиление антенны 0 dBi, потери кабеля и разъёмов 2 dB, дополнительный запас 10 dB на fading и безопасность, а также антенна, не заглублённая в почву (информация производителя E22-900M22S).

PHY bit rate вычисляется по формуле R_b = SF × (BW / 2^SF) × 4/5 и не равен реальной пропускной способности приложения. Заголовки LoRaWAN, duty cycle, ожидание, повторные передачи, метаданные фрагментации и потери пакетов дополнительно уменьшают полезную скорость. Указанные дальности — планировочные оценки на основе перечисленных RF-допущений, а не полевые измерения и не гарантированные значения для мандаринового сада. Столбцы SF5–SF6 и BW250/BW500 — сравнение для чистого LoRa; сочетания за пределами стандартных data rate LoRaWAN EU868 нужно отдельно сверять с региональными параметрами.

Региональные параметры LoRaWAN определяют планы каналов, разрешённые data rate, ограничения мощности и другие региональные условия. Поэтому таблицу SF/BW нужно проверять по параметрам страны и используемого диапазона (LoRa Alliance RP002 Regional Parameters; актуальный список публикаций находится в LoRa Alliance Technical Committee Publications).

Почему важен ADR?

LoRaWAN Adaptive Data Rate (ADR) позволяет network server настраивать data rate и мощность передачи устройства по качеству канала. Semtech описывает цель так: сохранить необходимый link margin и одновременно использовать более высокий data rate, чтобы снизить airtime и расход сетевой ёмкости (Semtech, Understanding LoRa Adaptive Data Rate).

Для FUOTA вывод очевиден: переходить на SF12 нужно только при реальной необходимости. Если соединение надёжно на SF9 или SF8, меньший SF сократит время обновления.

3. Link budget: мощности двух устройств не складываются

Выходные мощности Dragino и E22 нельзя просто сложить в одном расчёте. Каждое направление RF нужно рассчитывать отдельно:

принятая мощность =
выходная мощность активного передатчика
+ усиление передающей антенны
+ усиление принимающей антенны
− потери кабелей и разъёмов
− потери распространения
− потери от листвы, стволов, земли и других факторов среды

Для направления E22 → Dragino используются выходная мощность E22 и чувствительность приёмника Dragino. Для Dragino → E22 — мощность Dragino и чувствительность E22. Рабочую двустороннюю дальность определяет более слабое направление. Поскольку чувствительность меняется в зависимости от SF, BW, coding rate и условий измерения, одно значение «дальности устройства» технически неполно. Связь между параметрами модуляции LoRa, чувствительностью и bit rate описана в техническом обзоре LoRa Semtech.

Для полевых расчётов этой статьи нельзя принимать номинальное значение в dBm до фиксации точных моделей Dragino и E22, типа антенны, мощности на выходе кабеля и региональных разрешений. Технические паспорта не заменяют полевые измерения.

4. Почему тип культуры — отдельная RF-задача?

Одинаковая радионастройка даёт разные результаты в разных сельскохозяйственных средах. Листья, ветви, стволы, влажность почвы, геометрия рядов и дождь влияют на рассеяние, поглощение и многолучевое замирание. Исследования в садах показывают, почему прямая видимость часто отсутствует и почему растительность меняет потери распространения (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

Поэтому сначала мы рассмотрели такие культуры:

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

Это не мировой рейтинг производства, а набор инженерных сценариев, объединяющий потребности сенсоров, чувствительность к поливу/EC, экономическую ценность и сложность RF-среды. Для каждой культуры сначала была составлена таблица дальность–bit rate для комбинаций SF/BW, затем таблица airtime FUOTA для тех же комбинаций. Это первичные оценки для плана испытаний, а не гарантии поля.

5. Почему мандариновый сад?

Мандариновый сад хорошо подходит для стресс-теста:

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

Исследования RF в цитрусовых садах, одновременно учитывающие размещение узла, высоту антенны, глубину растительности и расстояние, показывают, что размещение антенны нельзя объяснить одной лишь дистанцией в метрах (citrus orchard RF deployment study). Эксперименты по размещению сенсоров в цитрусовых садах также зафиксировали разные уровни принятого сигнала при разной высоте антенн и плотности деревьев (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

Критический вопрос теперь не «Сколько километров проходит LoRa?», а:

Может ли каждый сенсор в мандариновом саду подключаться с достаточным link margin, и способен ли тот же downlink завершить длительную передачу прошивки?

6. Высота антенны: 1 метр, 5 метров и 50 сантиметров

Шлюз на высоте 1 метр

Мачта высотой около 1 метра может оставить антенну внутри нижнего слоя стволов и листвы. Ряды деревьев, ветви и листья тогда напрямую попадают на трассу распространения. Видимость другой антенны не означает, что зона Френеля свободна: отражения от земли и ряды деревьев всё ещё могут доминировать.

Шлюз на высоте 5 метров

Высота около 5 метров может приблизить антенну шлюза к верхушкам многих мандариновых деревьев или поднять её выше. Это не создаёт автоматически прямую видимость по всему саду, но может уменьшить препятствия со стороны шлюза, потери из-за земли и влияние крон на горизонтальную трассу. Измерения в садах показывают, что влияние листвы зависит от близости антенн к земле или кронам (orchard foliage path-loss study).

Поэтому мачта на 5 метров сама по себе не является «множителем дальности». Её пользу нужно измерять вместе с такими факторами:

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

Обе антенны на высоте 50 сантиметров

Преимущество высоты 50 см в том, что антенна остаётся ниже верхнего слоя листвы и может использовать коридор между стволами. Но «листья не перекрывают путь» не означает «есть прямая видимость». На этой высоте:

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

Сценарий 50 см нужно измерять на том же маршруте, что и сценарии 1 м и 5 м; его нельзя считать теоретическим улучшением дальности. Во многих садах разумная гипотеза — направить антенну сенсора в коридор ряда, поднять антенну шлюза выше крон и при необходимости добавить второй шлюз. Это проектная гипотеза, выведенная из зависимости от высоты и ориентации в исследованиях RF садов; её нужно проверить в поле.

7. Канал телеметрии — не канал FUOTA

То, что сенсор может регулярно передавать небольшой измерительный пакет, не означает, что он сможет скачать по той же сети прошивку размером 1 MB. Телеметрия обычно представляет собой редкий uplink, а FUOTA — длительную операцию, в основном downlink, требующую повторной передачи потерянных фрагментов.

Устройства LoRaWAN Class A открывают два коротких окна приёма после uplink. Устройства Class C дольше держат приёмник доступным, когда не передают, поэтому временный режим Class C полезен для большой downlink-передачи (LoRaWAN Specification).

FUOTA — это не одна команда «отправить пакет прошивки». Спецификации LoRa Alliance разделяют обязанности:

• TS004 Fragmented Data Block Transport: фрагментация больших данных и управление сессией (TS004-2.0.0).
• TS005 Remote Multicast Setup: планирование временного multicast и окон распределения Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: управление версиями firmware и hardware, перезапуском и образами обновления (TS006-1.0.0).
• TS007 Multi Package Access: передача информации о пакетах устройства и FPort, чтобы несколько команд использовали меньше downlink (TS007-1.0.0).

Совместное применение этих стандартов требует дополнительной разработки и HIL-валидации независимо от RF-дальности.

8. Цена полной прошивки размером 1 MB

Грубая нижняя граница для полной прошивки размером 1 MB считается так:

число передаваемых битов / теоретический bit rate

При 1 MB и 5,47 кбит/с только PHY-передача занимает около 25,5 минуты. Если принять использование канала 10% как сценарное допущение, теоретическая нижняя граница составит около 4,25 часа. В расчёт не входят заголовки LoRaWAN, метаданные фрагментов TS004, parity/redundancy, потери пакетов, повторы и настройка сессии Class C. Региональные нормы и ограничения использования канала нужно проверить для конкретной страны и диапазона (RP002 Regional Parameters).

Поэтому выбирать настройки FUOTA только по критерию «максимальная дальность» может быть неверно. Лучшее решение минимизирует общий airtime, сохраняя надёжный link margin.

9. Delta OTA: передавать разницу, а не всю прошивку

При Delta OTA сервер отправляет разницу между базовым образом, сообщённым устройством, и целевым образом. Устройство применяет patch и восстанавливает целевую прошивку:

базовая прошивка на устройстве
        +
delta patch
        ↓
целевая прошивка
        ↓
проверка SHA-256 и подписи
        ↓
тестовая загрузка MCUboot и подтверждение состояния

Проект с открытым исходным кодом detools — пример delta-подхода для embedded-систем: он документирует потоковое применение последовательных patch и incremental apply на C для устройств с ограниченной памятью (detools README). В проекте Agronode поток создания и применения delta определён вместе с base SHA, target SHA, размером образа и размещением MCUboot (документация Agronode Delta OTA, код применения delta).

Текущие измерения проекта сообщают о последовательных delta между release размером примерно 15–53 KB при полном образе около 944 KB (документация проекта Delta OTA). Это измерение относится к этим release; такое же соотношение нельзя ожидать для каждой пары версий.

При том же приблизительном PHY-значении 5,47 кбит/с:

Это не реальная длительность FUOTA, а сравнение размеров. Фрагментация, parity, повторы и управление сессией увеличат время.

10. Можно ли обновлять очень старые устройства маленькими Delta-шагами?

Да, если существует подходящая delta-цепочка:

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

Каждая стрелка — отдельная FUOTA-сессия и отдельный шлюз безопасности. Сервер должен запускать следующий patch только после того, как устройство:

1. завершило сессию фрагментации,
2. проверило base SHA,
3. создало целевой образ и проверило target SHA,
4. успешно прошло тестовую загрузку MCUboot,
5. подтвердило новую прошивку проверкой состояния,
6. сообщило новую версию и идентификатор образа.

Поток test–confirm–revert MCUboot позволяет при сбое нового образа вернуться к предыдущему рабочему образу при следующей загрузке. Это базовый шаблон bootloader для снижения риска brick при удалённых обновлениях (документация дизайна MCUboot, подпись образов и инструменты MCUboot).

Недостаток многошаговой цепочки в том, что настройка сессии, airtime, энергия, перезапуск и риск ошибки повторяются на каждом шаге. Если вероятность успеха каждого hop независимо равна 98%, вероятность пройти десять hop без повторов составляет примерно 0,98^10 = 81,7%. Это не прогноз полевого успеха, а модель того, как число hop умножает риск.

11. Правильная модель — граф delta, а не список delta-файлов

Хранить только соседние release — простая модель:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

В production лучше хранить полные образы и несколько типов delta вместе:

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

Рекомендуемая политика artifact:

• хранить полный подписанный образ каждого release;
• хранить последовательные delta N→N+1 как долгоживущие неизменяемые artifact;
• создавать прямые delta от базовых версий, реально находящихся в поле, к последней release;
• хранить bridge delta от выбранных LTS/checkpoint-версий к последней release;
• хранить вместе с delta метаданные base SHA, target SHA, board, hardware revision, variant и partition geometry;
• не удалять полные образы: они остаются каноническим источником для создания delta, расследований и восстановления.

В Agronode существующий artifact-скрипт показывает создание прямых delta от полевых базовых версий (ensure_field_deltas.py). Текущая backend-политика ищет прямое соответствие base–target; дополнительно нужен graph/path planner, который сможет автоматически построить A→B→C, если существуют A→B и B→C (ota_policy.py).

Сервер может выбирать маршрут по такой функции стоимости:

стоимость маршрута =
общее число байт patch
+ оценочный airtime
+ стоимость сессии/перезапуска на hop
+ риск потери пакетов и сбоя
+ энергия устройства и стоимость обслуживания

Практичная первая политика — использовать прямой patch, если он существует и имеет разумный размер. Если он слишком велик, попробовать checkpoint-маршрут максимум с 2–3 контролируемыми hop. Полный образ нужно хранить как путь восстановления, bootstrap или альтернативный транспорт, а не как автоматический «последний шанс» через LoRa.

12. Шлюзы безопасности, необходимые для Delta OTA

Delta OTA не отменяет проверки безопасности; напротив, точная идентичность базового образа становится ещё важнее.

Для каждого patch нужно проверить как минимум:

• base firmware SHA-256, сообщённый устройством;
• base SHA-256, ожидаемый patch;
• board и hardware revision;
• partition/slot geometry;
• target firmware SHA-256;
• подпись MCUboot и разрешённый signing key;
• соответствие целевой версии политике downgrade.

MCUboot проверяет целостность и подпись образа и может обеспечить rollback, если тестовая загрузка не подтверждена окончательно (официальная документация MCUboot). Код применения delta должен отклонять несовместимые base и layout до создания целевого образа (применение delta в Agronode).

Для очень старых устройств также нужна определённая bootstrap-версия FUOTA. Если в прошивке до этой версии нет клиента фрагментации, кода delta-apply или необходимой поддержки bootloader, устройство нельзя напрямую включить в delta-цепочку. Сначала его нужно обновить через BLE, Wi-Fi, сотовую сеть или контролируемый полный образ.

13. Практическая дорожная карта проекта

Этап 1 — Зафиксировать RF-допущения

• подтвердить точные модели Dragino и E22;
• выбрать регион и частотный план;
• измерить мощность на выходе кабеля или проверить её по datasheet;
• записать усиление антенны, потери кабеля и поляризацию;
• измерить сценарии 50 см, 1 м и шлюз на 5 м на одном маршруте в мандариновом саду.

Этап 2 — Построить карту полевой связности

• записывать RSSI и SNR в каждой точке измерения;
• измерять долю успешных пакетов и зависимость от направления;
• сравнить сухие, политые, дождливые условия и разную плотность листвы;
• измерить один маршрут вдоль рядов и другой поперёк рядов;
• отдельно определить минимальный link margin для FUOTA.

Этап 3 — Завершить транспорт LoRaWAN FUOTA

• реализовать сессию фрагментации TS004;
• реализовать временный цикл Class C/multicast с TS005;
• связать управление версиями firmware/reboot из TS006 и package discovery из TS007;
• протестировать потерю фрагментов, повторы, прерывание и перезапуск шлюза;
• не обещать сквозной успех Delta FUOTA через LoRa до завершения этого этапа.

Этап 4 — Добавить artifact delta и управление маршрутами

• хранить каждый полный подписанный release как канонический artifact;
• создавать соседние delta и прямые delta от активных полевых баз к последней release;
• сделать метаданные delta неизменяемыми, связав их с base/target SHA и идентичностью hardware;
• реализовать на сервере выбор прямого patch и ограниченного multi-hop-маршрута;
• после каждого hop ждать сигналов версии, SHA, состояния boot и состояния приложения.

Этап 5 — Определить метрику успеха FUOTA

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

• байтах patch и общем airtime;
• доле потерянных фрагментов и количестве повторов;
• времени завершения обновления;
• энергопотреблении;
• доле успешных тестовых загрузок;
• доле окончательных подтверждений;
• доле rollback;
• успехе каждого hop и общем успехе, если требуется несколько hop.

Заключение

Проблема LoRa в мандариновом саду — это не только вопрос «Какую дальность в километрах мы получим?». SF и BW создают компромисс между дальностью и bit rate; растительность меняет теоретический канал в реальных условиях; высота антенны и направление рядов влияют на результат; FUOTA требует downlink-ёмкости, совершенно не похожей на ту, что нужна для небольших телеметрических пакетов.

Поэтому справочные 6 км Semtech и надёжная дистанция обновления в густом саду не являются одной и той же метрикой. Правильная архитектура объединяет измеренный RF link budget, подходящую высоту шлюза, стандартный транспорт TS004/TS005 FUOTA, шлюзы безопасности MCUboot и граф artifact Delta OTA.

Когда Delta OTA уменьшает полный образ 1 MB до patch примерно 15–53 KB, airtime FUOTA можно существенно сократить. Но один delta-алгоритм не превращает это преимущество в надёжный продукт. Сервер должен знать точный base SHA устройства, выбрать прямой или ограниченный multi-hop-маршрут, проверить каждый hop и сохранить полный образ как источник восстановления.

Итак, цель — не максимальная дальность, а система LoRaWAN, способная выполнять в мандариновом саду измеримое, повторяемое и обратимое обновление прошивки.

Источники

Стандарты и технические документы производителей

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

Исследования сельскохозяйственного RF-распространения

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling