LR1121: руководство пользователя | arm

В этой статье (перевод оригинальной документации [1]) предоставлена полная информация по использованию трансивера LR1121, раскрывающая как аппаратные, так и программные аспекты применения. Обзор/описание основного функционала LR1121 и параметров см. в даташите LR1121 [2].

Примечание: расшифровку различных абревиватур и терминов см. в Словарике статьи [2].

Режимы, в которых работает LR1121, и переходы между ними показаны на рис. 2-1:

Bootloader (загрузчик) это первое, что запускается после сброса по питанию (power-on reset, POR), и он находится в самом начале flash-памяти. Подробное описание в AN1200.57 LR1110 Program Memory Update применимо ко всем устройствам LR11xx.

• Проверка - допустимо ли для запуска загруженное firmware.
• Загрузка firmware: получение шифрованных блоков данных, передаваемых через SPI, их дешифровка на лету и запись в память flash.

Это режим по умолчанию LR1121. В него происходит возврат из всех других режимов (за исключением специальных fall-back опций), и из этого режима возможен переход в другие режимы. Все команды по конфигурированию устройства должны быть поданы в этом режиме.

В режиме Standby доступны два варианта тактирования: или внутренний 32MHz RC-генератор (Standby RC mode), или внешний 32MHz crystal/TCXO (Standby Xosc mode). Такты RC используются по умолчанию для всех автоматических переходов между режимами. Такты crystal/TCXO позволяют быстрые переходы в другие режимы ценой повышенного энергопотребления.

Команда SetStandby(...) установит устройство в режим ожидания (standby mode) с выбранным генератором 32MHz.

Параметр StdbyConfig выберет генератор, используемый в режиме standby:

• 0x00: внутренний RC-генератор (Standby RC mode)
• 0x01: внешний Xtal/TCXO генератор (Standby Xosc mode)

Во время последовательности запуска (startup sequence), firmware устройства калибрует RC-генераторы высокой и низкой частоты, PLL, ADC и подавление зеркального канала смесителя (mixer image rejection) на частоте 915 МГц. После процедуры калибровки устройство устанавливается в Standby RC mode.

Если работа происходит на другой частоте, то процедура калибровки подавления зеркального канала приема (image calibration) должна быть перезапущена командой CalibImage(...). Процедуру image calibration рекомендуется выполнить после больших изменений температуры для оптимального подавления зеркального канала. Эта калибровка необходима, если частота меняется больше чем на 10 МГц, или изменилась температура больше чем на 10°C.

Команда CalibImage(...) запускает image-калибровку для указанного диапазона частот Freq1 и Freq2 на цепи RFI_N_LF/RFI_P_LF sub-GHz.

По умолчанию image-калибровка выполняется в диапазоне 902 .. 928 МГц. Тем не менее, можно запросить выполнить новую image калибровку на других частотах. Частоты приведены в единицах 4 МГц (например 900MHz -> 0xE1).

Калибровка допускается для всех частот между двумя параметрами. Обычно пользователь выбирает параметры Freq1 и Freq2 из таблицы 2-3. Можно указать одинаковую частоту для Freq1 и Freq2, чтобы выполнить одну калибровку для значения Freq1 / Freq2.

Эта команда работает в любом режиме. По окончанию процедуры калибровки устройство возвратится в режим Standby RC.

Для других диапазонов частот значения Freq1 и Freq2 могу быть получены по следующим формулам:

В случае POR, или когда устройство восстановилось из режима power-down или режима sleep без сохранения параметров, image калибровка выполняется как часть начального процесса калибровки, и для оптимального подавления по соседнему каналу в диапазоне 902 .. 928 МГц. Если подключен TCXO, то эта калибровка терпит неудачу.

Команда Calibrate(...) калибрует запрошенные блоки, определенные параметром CalibParams.

Эта команда работает в любом режиме. По окончанию процедуры калибровки устройство возвратится в режим Standby RC.

Это самый экономный по потреблению энергии режим устройства. В этом режиме:

• Все такты остановлены, так что RTC недоступен.
• Если нет сохранения данных (no data retention), то необходима повторная конфигурация устройства при выходе из режима power down.
• Сигнал BUSY устанавливается в лог. 1, показывая тем самым хосту, что устройство не готово принимать команду.
• Устройство переводится в режим power down командой SetSleep(...), см. описание sleep mode.

Устройство может выйти из этого режима, если обнаружена активность сигнала NSS.

При выходе из этого режима устройство выполняет перезапуск firmware, и устанавливает сигнал BUSY в лог. 0, показывая успешное завершение фазы startup, и что устройство готово к приему команды.

Режим сна (sleep mode) конфигурирует LR1121 в режим низкого потребления энергии между операциями радио, при этом сохраняются значения регистров и данных firmware в памяти RAM. Когда LR1121 находится в sleep mode, сигнал BUSY устанавливается в 1 резистором pull-up, все сигналы MISO SPI находятся в high-Z, и все выводы DIO находятся в режиме Hi-Z (см. DriveDiosInSleepMode).

Опционально источник тактов 32kHz может работать или от внутреннего RC-генератора, или от внутреннего генератора 32.768 кГц, частота которого задается внешним кварцем. Кварцевый генератор 32.768 кГц позволяет быстрее переходит в режим standby, но ценой повышенного потребления энергии. В обоих случаях RTC использует источник тактов 32kHz, что позволяет реализовать автоматическое пробуждение (automatic wake-up) для выхода из Sleep mode.

Команда SetSleep(...) переведет устройство в режим Powerdown или Sleep, и конфигурирует таймаут для автоматического пробуждения (automatic wake-up).

SleepConfig определяет, в какой режим сна будет помещено устройство, и будет ли оно просыпаться после указанного времени по событию RTC:

• Retention (bit 0) определяет, сохраняется ли конфигурация устройства и данные firmware:

- 1: 8kB памяти используется для сохранения состояния устройства и данных firmware.
- 0: No data retention, нет сохранения данных (в режиме Power Down).

• Wakeup (bit 1) определяет, будет ли устройсво просыпаться после истечения указанного времени по событию RTC:

- 1: Разрешен automatic wake-up. Устройство автоматически перейдет в режим Standby с генератором RC по истечению таймаута SleepTime. Для приложений модема конфигурируйте источник тактов 32kHz командой ConfigLfClock(...).
- 0: Automatic wake-up запрещен.

• Другие биты RFU, и должны быть установлены в 0.

SleepTime задает время сна в единицах тактов 32.768 кГц, до момента автоматического пробуждения. Таким образом, время сна можно варьировать от 0 мс до 36.4 часов с шагом 30.52 мкс.

Устройство выйдет из этого режима по спаду уровня NSS, даже когда разрешена функция automatic wakeup. При выходе из этого режима устройство выполнит перезапуск firmware. Когда сигнал BUSY установится в лог. 0, это покажет успешное завершение фазы startup, и что устройство готово к приему команды.

Следующая таблица суммарно показывает режимы сна в соответствии с конфигурацией бит Retention и Wakeup, вместе с их потреблением тока (RC/XTAL) и интервалами времени перехода в Standby (показательные значения, приведены только для сравнения).

Доступны 4 источника сброса для перезапуска LR1121 и выполнения последовательности startup: Power-On-Reset / Brown-Out Reset (POR/BRN), NRESET и команда Reboot(...).

Сигнал BUSY удерживается в лог. 1 для каждой из этих процедур сброса, и возвращается в 0 когда процедура перезапуска завершена. По окончании процедуры сброса устройство готово к приему команд и находится в Standby mode с активным RC-генератором (STBY_RC). Весь предыдущий контекст устройства при этом теряется, и оно должно быть заново сконфигурировано и заново откалибровано. POR/BRN и NRESET также запускают процедуру аутентификации внутреннего firmware.

LR1121 выполнит перезапуск, если произойдет одно любое событие из следующих:

• Напряжение батареи возрастет больше уровня Power-On-Reset (POR).
• Напряжение батареи временно просядет ниже уровня Brown-Out Reset (BRN).

И POR, и BRN приводят к полному перезапуску внутреннего firmware. Поле Status переменной состояния Stat2 покажет, что произошло, POR или BRN.

Для дополнительной информации по POR и BRN обратитесь к секции "5.5. Power-On-Reset и Brown-Out-Reset".

Перевод сигнала NRESET в лог. 0 на время не менее 100 мкс перезапустит LR1121. Этот перезапуск эквивалентен Power-On Reset, и устройство выполнит ту же самую последовательность startup.

Команда Reboot(...) приведет к перезапуску LR1121 firmware.

Параметр StayInBootLoader определит тип перезагрузки (reboot):

• 0: выполнит software restart.
• 3: bootloader не запустит firmware в flash, но разрешит апгрейды firmware.

При перезагрузке сохраняется конфигурация тактирования 32kHz. Команда ConfigLfClock(...) модифицирует конфигурацию тактирования 32kHz.

В режиме приема (RX mode) принимаются RF-пакеты на выводах RFI_N_LF0/RFI_P_LF0 в диапазоне sub-GHz (150 .. 960 МГц), и на выводе RFIO_HF в диапазоне 1.9 .. 2.1GHz Satellite и диапазоне 2.4GHz (2400 .. 2500 МГц), с использованием одного из модемов LoRa или (G)FSK. Устройство входит в RX mode по команде SetRx(...). По приему пакета генерируется прерывание RX_DONE, и принятые данные сохраняются в буфер данных устройства.

Работа режима RX может быть автоматически завершена после приема пакета, после завершения цикла или может быть активной бесконечно, в зависимости от требований приложения.

В режиме RX приемник LR1121 работает в различных подрежимах:

• Continuous mode, непрерывный режим. Устройство остается в RX mode и ждет поступления пакетов, пока хост не запросит переход в другой режим.
• Single mode, одиночный режим. Устройство автоматически возвратится в сконфигурированный режим (Standby RC по умолчанию) после приема пакета.
• Single with timeout mode, одиночный режим с таймаутом. Устройство автоматически вернется в Standby RC после приема пакета, или после истечения указанного таймаута. Если было обнаружено синхрослово (sync word) модуляции (G)FSK, или заголовок LoRa, то отсчет таймаута останавливается.
• RX Duty Cycle mode, циклический режим приема. Устройство периодически переходит в RX mode для приема пакета перед уходом обратно в Sleep mode, пока не будет получен пакет.
• AutoTx mode (автоматическая передача пакета через заданное время после приема пакета). Устройство после приема пакета переходит в промежуточный режим в течение запрошенного времени, перед входом в TX mode для передачи пакета.

Режим передачи (TX mode) использует поддерживаемые модемы для передачи RF пакетов через выбранный sub-GHz PA на выводах RFO_LP_LF или RFO_HP_LF в диапазоне sub-GHz (150 .. 960 МГц), и вывод RFIO_HF в диапазоне 1.9 .. 2.1 ГГц Satellite и диапазоне 2.4GHz (2400 .. 2500 МГц).

После активации PA передается буфер данных на указанной частоте, с заданными конфигурациями PA, выходной мощности, пакета и модуляции. Когда последний бит пакета отправлен, генерируется прерывание TX_DONE, регулятор питания PA выключается, выбранный PA выключается, и устройство переходит обратно в режим Standby RC или режим Xosc, в зависимости от конфигурации FallBackMode.

В TX mode сигнал BUSY перейдет в лог. 0, как только PA активировался и стартует передача преамбулы. Во время TX mode LR1121 работает в различных подрежимах:

• Single mode, одиночный режим. Устройство автоматически возвратится в сконфигурированный режим (Standby RC по умолчанию) после передачи пакета.
• Single mode with timeout, одиночный режим с таймаутом. Устройство автоматически возвратится в сконфигурированный режим (Standby RC по умолчанию) после передачи пакета или после истечение заданного таймаута.
• AutoRX mode, устройство автоматически переходит в RX mode после передачи пакета. В этом режиме устройство после передачи перейдет в промежуточный режим на заданное время перед возвратом в RX для приема пакета, или пока не истечет сконфигурированный таймаут.
• Continuous Wave mode (CW mode), режим генерации непрерывной несущей. Устройство бесконечно передает немодулированную несущую на заданной частоте, пока не поступит другая команда для изменения текущего режима.
• Infinite preamble mode, режим бесконечной преамбулы. Устройство непрерывно передает преамбулу сконфигурированной модуляции.

Режим синтезатора частоты (Frequency Synthesis, FS mode) это промежуточный режим между standby mode и RX mode или TX mode, где PLL и связанные регуляторы включены. Сигал BUSY перейдет в лог. 0, как только произошел захват ФАПЧ (PLL locked).

Команда SetFs(...) установит устройство в Frequency Synthesis mode.

После включения питания или сброса устройство инициирует фазу своего запуска (startup).

• Сигнал BUSY устанавливается в лог. 1, показывая тем самым, что устройство занято и не может принять команду.
• Когда блок управления питанием (power management unit) и RC-генератор становятся доступными, встроенный MCU запустится и выполнит код внутреннего firmware.
• По окончанию последовательности старта (startup sequence) устройство установится в Standby RC mode, сигнал BUSY перейдет в лог. 0 и устройство готово к приему команд.

LR1121 может быть обновлен новым образом firmware, предоставленным Semtech. Полное описание приведено в апноуте AN1200.57 "LR1110: Upgrade of the Program Memory", доступном на сайте Semtech. Соответствующие команды описаны ниже.

FW Major + FW Minor это версия внутреннего firmware LR1121, сохраненного в памяти flash. Поставляемая версия LR1121 после производственного теста rev 01.01. Рекомендуется провести обновление firmware на последнюю версию.

Команда EraseFlash(...), доступная только в режиме bootloader, должна использоваться перед тем, как новый образ записывается в устройство.

Если команда запущена в другом режиме, то статус команды в Stat1 установится в P_ERR.

Команда WriteFlashEncrypted() запишет новый образ firmware в LR1121. Дополнительную информацию можно найти в апноуте AN1200.57. Команда CryptoCheckEncryptedFirmwareImage может быть использована перед записью образа.

Здесь N должно быть в диапазоне от 1 до 32 включительно.

В таблице 2-15 перечислены переходы между режимами и соответствующие тайминги LR1121. См. рис. 2-1, где приведена диаграмма переходов между режимами LR1121.

Таблица 2-15. Переходы между режимами и тайминги.

Память flash LR11xx содержит информационную страницу (Info Page), состоящую из 512 32-разрядных слов, в каждом из которых контроллер хоста может сохранить данные пользователя.

Замечание: максимальное количество обращений R/W к памяти flash LR11x составляет 10k циклов.

Команда EraseInfoPage(...) сотрет запрошенную Info Page в памяти flash LR11xx.

Параметр InfoPage может быть только в значении 1. Другие значения RFU.

Команда WriteInfoPage(...) запишет блок 32-битных слов в Info Page памяти flash, начиная с определенного адреса слова.

InfoPage: может быть только 1. Другие значения RFU.

InfoWordAddr: начальный адрес блока данных в Info Page. Этот адрес автоматически инкрементируется после сохранения каждого слова данных в соседних ячейках памяти.

data: блок данных, записываемый в Info Page. Длина данных должна нацело делиться на 4. Максимальное значение N == 64.

Команда ReadInfoPage(...) читает блок 32-битных слов в Info Page пространстве памяти flash, начиная с определенного адреса слова.

InfoPage: может быть только 1. Другие значения RFU.

InfoWordAddr: начальный адрес блока данных в Info Page. Этот адрес автоматически инкрементируется после чтения каждого слова данных в соседних ячейках памяти.

InfoReadLen: количество считываемых слов. Максимальное значение InfoReadLen == 64.

Возвратит CMD_PERR, если пользователь попытается прочитать данные после окончания страницы.

[3. Интерфейс управляющего контролера (хоста)]

LR1121 предоставляет API, которое позволяет хосту коммуницировать с LR1121 через набор команд и ответов по интерфейсу SPI. Сигнал BUSY используется как сигнал квитирования (handshake), чтобы показать готовность LR1121 к приему команды. Таким образом, перед отправкой команды необходимо проверить состояние уровня сигнала BUSY.

Во время команд записи (Write) LR1121 возвращает хосту регистры статуса и регистры прерывания через вывод MISO, в зависимости от длины кода команды (opcode) и аргументов.

Хост посылает 16-битный opcode, за которым идут необходимые аргументы.

Сигнал BUSY автоматически установится по спаду уровня сигнала выборки NSS.

Как только LR1121 завершит обработку команды, сигнал BUSY снимается (переходит в 0), сигнализируя о готовности устройства к приему другой команды.

Специальные команды чтения (Read) получают данные из LR1121, такие как результаты внутреннего статуса.

Хост посылает 16-битный opcode, за которым идут необходимые аргументы.

Сигнал BUSY автоматически установится по спаду уровня сигнала выборки NSS.

Как только LR1121 завершит подготовку запрошенных данных, сигнал BUSY переходит в 0. После этого хост может прочитать данные отправкой байт NOP (0x00) для того, чтобы данные выдвигались через вывод MISO.

3.3. Command Endianness (порядок следования байт команды)

На следующих рисунках приведены примеры транзакции SPI для команды GetVersion(...).

В LR1121 есть 2 переменные состояния (status) Stat1 и Stat2, которые показывают текущий статус LR1121 (последняя отправленная команда, прерывания устройства, рабочий режим устройства и режим загрузчика). Команда GetStatus(...) возвратит содержимое этих регистров.

Stat1 и Stat2 всегда отправляются хосту, когда хост выдает команду. Когда хост запрашивает данные из LR1121, то посылается только Stat1.

Команда GetStatus(...) возвратит флаги состояния Stat1 и Stat2, и флаги прерывания IrqStatus. Она затем очистит поле ResetStatus в stat2.

Обратите внимание, что существует альтернативный метод получения информации состояния: если через MOSI передается последовательность нулей (NOP), то LR1121 выдвигает через MISO либо ответ на последнюю команду, либо информацию статуса, если ответ хостом не ожидается. Если команда чтения SPI read разработана для записи нуля /NOP через сигнал MOSI, то это предоставляет способ получить информацию статуса, используя одиночную команду SPI read. Однако имейте в виду, что этот метод не очистит поле ResetStatus. См. Stat1/CMD_DAT для дополнительной информации.

Command Status показывает статус последней команды, отправленной хостом:

• 0: CMD_FAIL: последняя команда не выполнена.
• 1: CMD_PERR: последняя команда не обработана (неправильный opcode, неправильные аргументы). Возможна генерация прерывания на DIO, если произошла ошибка команды. Любая попытка использовать функции Wi-Fi или GNSS возвратит этот код.
• 2: CMD_OK: последняя команда была успешно обработана.
• 3: CMD_DAT: последняя команда была успешно обработана, и данные в настоящий момент были переданы данные вместо состояния прерываний (IrqStatus).
• 4-7: RFU

Interrupt Status показывает, было ли прерывание LR1121:

• 0: нет активных прерываний.
• 1: было как минимум 1 прерывание.

• 0: Cleared (нет активного сброса)
• 1: Analog reset (Power On Reset, Brown-Out Reset)
• 2: External reset (внешний сброс, от импульса на выводе NRESET)
• 3: System reset
• 4: Watchdog reset
• 5: Wakeup NSS toggling (пробуждение от активности сигнала выборки SPI)
• 6: RTC restart (перезапуск по таймеру реального времени)
• 7: RFU

• 0: Sleep (сон, режим пониженного потребления энергии)
• 1: Standby with RC Oscillator (приостановка с тактированием от RC-генератора)
• 2: Standby with external Oscillator (приостановка с тактированием от внешнего генератора)
• 3: FS (режим синтезатора)
• 4: RX (режим приема)
• 5: TX (режим передачи)
• 6: RFU
• 7: RFU

• 0: в настоящий момент работает код загрузчика (bootloader)
• 1: в настоящий момент выполняется код программы из flash. Поле ResetStatus очищается по первой команде GetStatus(), выданной после сброса. Оно не очищается ни одной другой командой.

Вывод DIO0 используется для сигнала занятости BUSY: его уровень устанавливается в лог. 1, когда обрабатывается команда, и когда устройство не готово принять новую команду. Диаграмма времени сигнала BUSY показана на следующем рисунке:

Количество времени, в котором сигнал BUSY остается в лог. 1 после нарастания уровня NSS (время перехода между режимами TSW, см. таблицу 2-15) зависит от природы команды.

Команда GetErrors(...) возвратит ожидающие ошибки, которые произошли после последней команды ClearErrors(...), или после запуска схемы (circuit startup).

Есть возможность генерации прерывания на DIO9 или DIO11, когда возникает ошибка. Ошибка не может быть маскирована.

ErrorStat содержит все возможные флаги ошибки, которые могли произойти во время выполнения операций чипа:

• бит 0: LF_RC_CALIB_ERR. Калибровка низкочастотного RC-генератора не завершена. Для исправления этой ошибки заново выполните калибровку.
• бит 1: HF_RC_CALIB_ERR. Калибровка высокочастотного RC-генератора не завершена. Для исправления этой ошибки заново выполните калибровку.
• бит 2: ADC_CALIB_ERR. Калибровка АЦП не была завершена. Для исправления этой ошибки заново выполните калибровку.
• бит 3: PLL_CALIB_ERR. Калибровка максимальной и минимальной частот не завершена. Для исправления этой ошибки заново выполните калибровку PLL.
• бит 4: IMG_CALIB_ERR. Калибровка подавления по зеркальному каналу приема (image rejection) не завершена. Для исправления этой ошибки повторите image-калибровку.
• бит 5: HF_XOSC_START_ERR. Высокочастотный кварцевый генератор XOSC не был корректно запущен. Для исправления этой ошибки выполните заново сброс, или отправьте команду SetTcxoCmd(...), если подключен TCXO, и заново произведите калибровки.
• бит 6: LF_XOSC_START_ERR. Низкочастотный кварцевый генератор XOSC не был корректно запущен. Для исправления этой ошибки выполните заново сброс.
• бит 7: PLL_LOCK_ERR. Не произошел захват петли ФАПЧ. Это может произойти из-за слишком высокой или слишком низкой частоты настройки, или если PLL не была откалибрована. Для исправления выполните заново калибровку PLL, или используйте другие частоты.
• бит 8: RX_ADC_OFFSET_ERR. Калибровка смещения АЦП не была завершена. Для исправления этой ошибки заново выполните калибровку.
• биты 9-15: RFU.

Команда ClearErrors(...) очистит все ожидающие обработки флаги ошибки. Флаги ошибок не могут быть очищены индивидуально.

Команда WriteRegMem32(...) запишет блоки 32-битных слов в пространство регистров/памяти, начиная с определенного адреса.

Адрес автоматически инкрементируется после сохранения каждого байта данных в идущие друг за другом ячейки регистров/памяти. Максимальное значение N == 64.

Команда ReadRegMem32(...) считывает 32-битные слова из пространства регистров/памяти, начиная с определенного адреса.

Адрес автоматически инкрементируется после чтения каждого байта из идущих друг за другом ячеек регистров. Len это количество читаемых слов, максимальное значение Len == 64.

Команда WriteRegMemMask32(...) выполняет операцию чтение/модификация/запись маскированных бит (маскированный бит = 1) одного 32-битного слова в пространстве регистров/памяти по указанному адресу.

Команда WriteBuffer8(...) запишет блок байт в буфер передачи (radio TX buffer).

Data: N байт данных. Максимальное значение N == 255.

Команда ReadBuffer8(...) читает блок Len байт в буфер приема (radio RX buffer), начиная с указанного смещения Offset. Буфер RX должен быть реализован как кольцевой буфер.

Команда ClearRxBuffer(...) очистит все данные в radio RX buffer. Она запишет '0' во все ячейки буфера приема. Это в основном используется для отладки, чтобы гарантировать отсутствие в буфере приема данных предыдущего пакета.

Эта команда генерирует 32-разрядное случайное число. Это не используется в целях безопасности.

Эта команда разрешает/запрещает 8-битную CRC на SPI. Алгоритм CRC использует полином 0x65 (reversed reciprocal) с начальным значением 0xFF. CRC вычисляется по всем данным, принятым через MOSI (включая Opcode), и по всем данным, отправленным через MISO (включая все статусы).

• Чтобы разрешить CRC, вычисленная CRC уже должна быть присоединена к это команде. В качестве примера: полная команда разрешения будет 0x01 0x28 0x01 0x20.
• Чтобы запретить CRC, вычисленная CRC должна быть присоединена к команде начиная с момента, когда команда CRC все еще разрешена. В качестве примера: полная команда для запрета CRC будет 0x01 0x28 0x00 0x1C.

Enable: разрешает/запрещает 8-битную CRC на интерфейсе SPI:

• 0: запрещено. Не ожидается никакой CRC, посылаемой через SPI (по умолчанию).
• 1: разрешено. Ожидается присоединение CRC к данным, пересылаемым через SPI.
• Другие значения RFU.

CRC: cyclic redundancy check, значение контрольной суммы.

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

Прерывания LR1121 мультиплексируются на выводе DIO9 и/или DIO11. Когда приложение принимает прерывание, оно может определить его источник с помощью команды GetStatus(...). Прерывание может быть затем очищено с помощью команды ClearIrq(...).

Команда SetDioIrqParams(...) конфигурирует, какой сигнал прерывания должен быть активирован на выводах DIO9 и/или DIO11.

Статус прерываний LR1121 может быть прочитан командой GetStatus(...), однако эта информация также возвращается хосту через сигнал MISO во время SPI-транзакций через байты IrqStatus, одновременно с передачей в LR1121 аргументов команды. Таким образом, количество отправленных байт IrqStatus из LR1121 во время команд SPI зависит от количества аргументов команды. См. секцию "3. Интерфейс управляющего контролера (хоста)" для дополнительной информации.

Команда SetDioIrqParams(...) конфигурирует, какой сигнал прерывания должен быть активирован на выводе прерывания DIO9 и/или DIO11 (они обозначаются как выводы IRQ 1 и/или 2).

Команда ClearIrq(...) очистит выбранные сигналы прерываний записью 1 в соответствующий бит.

Порты DIO5, DIO6, DIO7, DIO8 и DIO10 могут управлять внешними ключами RF или усилителями LNAs на цепях Sub-GHz т RFIO_HF RF с помощью команды SetDioAsRfSwitch(...). Только младшие 5 бит всех конфигураций, как и разрешение.

Каждый бит Cfg соответствует состоянию выхода RFSW для определенного режима:

Значение RfswEnable показывает, какой ключ используется (1), и какой не используется (0):

• бит 0 - RFSW0 разрешен (вывод DIO5)
• бит 1 - RFSW1 разрешен (вывод DIO6)
• бит 2 - RFSW2 разрешен (вывод DIO7)
• бит 3 - RFSW3 разрешен (вывод DIO8)
• бит 4 - RFSW4 разрешен (вывод DIO10)

RfSwStbyCfg: каждый бит показывает состояние соответствующего RFSW DIO, когда LR1121 находится в standby mode (биты 5:7 RFU).

RfSwRxCfg: каждый бит показывает состояние соответствующего RFSW DIO, когда LR1121 находится в RX mode.

RfSwTxCfg: каждый бит показывает состояние соответствующего RFSW DIO, когда LR1121 находится в low power TX mode.

RfSwTxHPCfg: каждый бит показывает состояние соответствующего RFSW DIO, когда LR1121 находится в high power TX mode.

RfSwTxHfCfg: каждый бит показывает состояние соответствующего RFSW DIO, когда LR1121 находится в radio high frequency TX mode.

По умолчанию ни один DIO не используется как управление ключами RF: все выходы RFSW находятся в состоянии High-Z.

Эта команда работает только когда LR1121 находится в Standby RC mode, иначе на неё будет возвращена ошибка CMD_FAIL в ответе на последующую команду GetStatus.

Эта команда разрешает или запрещает добавление верхних (pull up) или нижних (pull down) подтягивающих резисторов на сконфигурированных выводах RF switch и сигналах прерываний (IRQ line DIO). Эта команда позволяет снизить энергопотребление в приложениях, где ключи RF управляются LR1121 DIO, когда LR1121 находится в sleep mode.

Значение Enable показывает, какой ключ используется для pull-up/pull-down (1) и какой нет (0):

• 0: кодом firmware не были сконфигурированы ни pull-up, ни pull-down (по умолчанию).
• 1: pull-up или pull-down добавлены кодом firmware на сконфигурированном RF switch и IRQ DIO, когда LR1121 переходит в режимы сна (действует на всех режимах сна), в зависимости от состояния DIO в config RC mode.

При пробуждении из sleep mode соответствующие DIO переконфигурируются в режим выходов, управляемых драйверами (push/pull mode), и резисторы pull-up/pull-down удаляются.

Важное замечание: когда выполняется переход в sleep mode без сохранения параметров (retention = 0), все ожидающие обработки IRQ очищаются перед входом в sleep mode.

В LR1121 есть встроенный датчик температуры, который показывает внутреннюю температуру устройства.

Измерение температуры может быть активировано командой GetTemp(...).

Значение температуры вычисляется как функция от внутреннего источника опорного напряжения (типовое значение 1.35V), и типовой температурной характеристики (типовое значение -1.7mV/°C), и оно может быть в градусах Цельсия аппроксимировано по следующей формуле:

Температура(°C) ~= 25 + (1000/-1.7mV°C) * (Temp(10:0)/2047*1.35 - 0.7295)

Важное замечание: GetTemp() использует режим XOSC для получения температуры, так что если подключен TCXO, то это должно быть сконфигурировано командой SetTcxoMode перед вызовом GetTemp().

Доступны 2 варианта регулировки напряжения (понижающий DC-DC или линейный LDO), выбор из которых зависит от приоритетов дизайна приложения. Линейный регулятор LDO всегда представлен во всех режимах, однако трансивер использует регулятор DC-DC, когда он выбран. Альтернативно может быть разрешен высокоэффективный преобразователь DC-DC в режимах FS, Rx и Tx.

DC-DC может управляться двумя источниками тактов:

• В STDBY_XOSC: RC13M предоставляет такты и частоту RC13M/4, частота переключения преобразователя DC-DC 3.25 МГц.
• В FS, Rx, Tx: PLL предоставляет такты, и частота ~5 МГц.

Для приложений, в которых цена и размер являются критическими, возможен вариант использования только LDO. Тогда не нужна индуктивность 15 мкГн, тем самым экономится место на печатаной плате и уменьшается BOM. Однако это достигается ценой повышенного расхода энергии.

Следующая таблица иллюстрирует опции регуляторов напряжения для различных режимов и настроек пользователя.

Таблица 5-1. Типы регулировки напряжения (Regulation Type) против режима схемы (Circuit Mode).

Пользователь может указать использование DC-DC командой SetRegulatorMode(...). Эта операция должна выполняться только в STDBY_RC mode.

Когда разрешен DC-DC, регулятор LDO остается включенным (ON), его целевое напряжение остается установленным на 50mV ниже напряжения DC-DC, чтобы гарантировать стабильность напряжения для пиков потребления тока. Если напряжение на выходе DC-DC упадет ниже этого уровня, то LDO восполняет необходимый ток ценой дополнительного расхода энергии.

Параметры индуктивности очень важны для оптимальной производительности внутреннего блока DC-DC. Неправильно подобранная индуктивность может привести к нежелательным эффектам пульсаций тока, что скажется на ускорении старения устройства и КПД преобразователя DC-DC.

Желательно применить экранированную индуктивность с низким внутренним сопротивлением, и частотой резонанса намного большей, чем частота переключения DC-DC. Когда выбирается индуктивность 15μH, пользователь должен корректировать свой выбор, руководствуясь параметрами:

Таблица 5-2. Рекомендуемые для применения индуктивности.

• DC-DC для приложений, где важно низкое энергопотребление.
• LDO для приложений, где важны снижение цены и размера конечного устройства.

Команда SetRegMode(...) определяет, какой регулятор должен использоваться.

RegMode определяет, должен ли быть включен преобразователь DC-DC:

• 0: не включать DC-DC в любом режиме (по умолчанию).
• 1: автоматически включать DC-DC, в зависимости от режима, как показано в таблице 5-4.
• Другие значения RFU.

Эта команда работает только когда устройство находится в Standby RC mode, иначе будет возвращена ошибка CMD_FAIL на последующей команде GetStatus.

Следующая таблица иллюстрирует опции энергопотребления для различных режимов и настроек пользователя.

Команда GetVbat(...) позволяет мониторить напряжение питания, поступающее от батареи, и она возвратит напряжение Vbat как функцию от опорного напряжения 1.35V:

• POR и BRN обеспечивают правильный запуск схемы (startup), удерживая внутренние блоки LR1121 в состоянии сброса, пока не будет достигнут безопасный уровень напряжения питания от батареи, например когда батарея устанавливается.
• BRN генерирует сброс устройства, если напряжение батареи упадет ниже порога для безопасного функционирования (safe operation threshold, типовое значение 1.7V).
• Детектор POR/BRN обладает гистерезисом 50 mV.
• POR сбрасывает статистику.

Low Battery Detector (LBD) детектирует ситуацию, когда напряжение питания VBAT падает ниже 1.88V (типовое значение). Индикация LBD проходит по сигналу прерывания, минимизируя активность хоста в условиях критического напряжения питания. LBD IRQ активируется командой SetDioIrqParams().

У LR1121 есть встроенный блок Over Current Protection (OCP), который предотвращает импульсные токи, когда устройство используется на самых высоких уровнях потребления энергии, защищая тем самым батарею и приложения, которые от неё питаются. Текущие параметры ограничения тока настраиваются с помощью доступа к регистру. Порог OCP должен конфигурироваться чуть ниже требований к батарее, но как минимум на 25% выше тока потребления выходного каскада PA.

• 60mA для маломощного усилителя (low power PA, LP PA)
• 150mA для мощного усилителя (high power PA, HP PA)
• 50mA для высокочастотного PA (high frequency PA, HF PA)

LR1121 использует как низкочастотный (32 кГц), так и высокочастотный (32 МГц) источники тактов. Для каждой частоты сигнал тактов может быть получен либо от RC-генератора, либо от кварцевого генератора. RC-генераторы позволяют оптимизировать энергопотребление и достичь повышенных скоростей переключения между режимами. Кварцевые генераторы обеспечивают более точную частоту для случает, когда это необходимо. Операции RF требуют точной опорной частоты 32 МГц, которую можно получить либо от внутреннего кварцевого генератора, к которому подключен внешний кварцевый резонатор, либо от внешнего генератора TCXO.

Требования тактирования для устройств LoRa Edge™ сведены в документе AN1200.74 LoRa Edge Clock Requirements.

• 32.768kHz RC-генератор для тактирования RTC, который может использоваться схемой в Sleep mode, чтобы пробуждать устройство для периодически операций. Несколько команд используют этот RTC для генерации событий с привязкой ко времени.
• 32MHz RC-генератор разрешен для всех коммуникаций SPI, чтобы обеспечить возможность конфигурирования устройства без необходимости запуска кварцевого генератора 32 МГц.

В этой секции приводится информация по опорным источникам тактирования. Для дополнительного руководства по источникам внешнего тактирования (кварц и TCXO) см. апноут AN1200.59 Selecting the Optimal Reference Clock. Также см. даташит LR1121 [2] для описания критерия выбора кварц/TCXO.

Кварцевый генератор 32.768kHz может использоваться вместо применяемого по умолчанию 32.768kHz RC-генератора в качестве низкочастотного источника тактирования, что активируется командой ConfigLfClock(...). Амплитуда внешнего сигнала 32.768kHz для подачи на вывод DIO11 должна соответствовать полному размаху логических уровней. Меньшая амплитуда может привести к повышенному потреблению энергии.

Кварцевый генератор 32MHz это самый недорогой и экономный по потреблению энергии вариант для точного тактирования по высокой частоте 32 МГц для LR1121. Корректирующие емкости нагрузки кварца интегрированы в чип, снижая тем самым цену BOM и оптимизируя пространство печатной платы. В случае работы от кварцевого резонатора вывод VTCXO должен оставаться неподключенным.

6.2.2.1. Дрейф частоты во время передачи пакета и теплоизоляция

Передача RF пакетов на высокой мощности приводит к значительному нагреву LR1121, и это тепло может нагреть кварц 32MHz, передаваясь по печатной плате. Для длительных передач это формирует дрейф частоты, который может вводить ошибки на приеме для противоположного конца канала связи, если не были учтены рекомендации по разработке PCB. Более подробно этот эффект для приложения SX1261/SX1262 описывается в апноуте AN1200.37 Recommendations for Best Performance.

Например, при модуляции LoRa, когда используется низкая скорость данных (Low Data Rate, LDRO), дрейф частоты передаваемого пакета 120 Гц/сек обычно приводит к уменьшению чувствительности на 3dB приемника LR1121 для всех SF и BW. Этот максимальный дрейф составит 110 Гц/сек, когда LDRO не используется. Таким образом, дрейф частоты во время передачи пакета должен удерживаться ниже максимальной величины, чтобы гарантировать самый лучший прием пакета. Дизайн, где используется TCXO, не подвержен эффекту дрейфа частоты при передаче пакета.

Реализация вырезов в слоях земляной заливки медью PCB уменьшает передачу тепла между LR1121 и кварцем 32MHz, как показано на рис. 6-1.

Рис. 6-1. Теплоизоляция LR1121 на верхнем слое печатаной платы.

См. образцовый дизайн LR1121 PCB на сайте www.semtech.com для примера реализации печатной платы.

Для применений с экстремальными изменениями температуры может потребоваться использование TCXO (Temperature Compensated Crystal Oscillator), чтобы достичь самой высокой точности стабилизации частоты. Когда используется TCXO:

• TCXO должен быть подключен к выводу XTA через последовательную цепочку из резистора 220 Ом и конденсатора 10 пФ. Апноут AN1200.59 предоставляет рекомендации по выбору 32MHz TCXO и связанных с ним компонентов.
• Вывод XTB должен оставаться неподключенным.
• TCXO получает питание от внутреннего регулятора LR1121 через вывод VTCXO.
• Регулируемое напряжение VTCXO программируется в диапазоне от 1.6 до 3.3V с помощью команды SetTcxoMode().
• VBAT должно оставаться на 200 mV выше, чем запрограммированное напряжение VTCXO, чтобы гарантировать правильную работу стабилизации напряжения питания TCXO.
• Номинальный ток потребления 1.5 mA, однако регулятор может обеспечить в нагрузке VTCXO ток до 4mA.
• На выходе TCXO необходимо наличие сигнала в форме обрезанной синусоиды, с амплитудой не выше 1.2V от пика до пика.

0: Используется 32.768kHz RC-генератор
1: Используется 32.768kHz кварцевый генератор
2: Используются внешнее тактирование 32.768kHz, поступающее на вывод DIO11
3: RFU

0: ожидание готовности для Xtal 32k
1: ожидание готовности для Xtal 32k перед снятием сигнала BUSY

Конфигурирует LR1121 для подключенного TCXO. TCXO должен быть сконфигурирован с помощью SetTcxoMode(...) перед вызовом GetTemp().

RegTcxoTune настраивает выходное напряжение на выводе VTCXO (напряжение питания TCXO), в соответствии с таблицей 6-3. Напряжение питания TCXO меняется установкой RegTcxoTune. Оно устанавливается типично +/-50 mV для настройки VTCXO = 1.8V.

Таблица 6-3. Значения программирования напряжения питания TCXO.

Delay представляет максимальную длительность для старта и стабилизации генератора 32MHz (с шагом 30.52 мкс). Если генерация 32 МГц от TCXO не обнаружена по истечению этого периода задержки, то внутреннее firmware устройства генерирует ошибку HF_XOSC_START_ERR.

• 0: запрещает режим TCXO (значение по умолчанию).
• 1: установит режим TCXO. Потребуется полный сброс чипа лоя возврата к обычному (не TCXO) тактированию XOSC.

Эта команда работает только в Standby RC mode, иначе она возвратит CMD_FAIL на последующей команде GetStatus().

LR1121 это полудуплексный RF трансивер, способный обрабатывать схемы модуляции с постоянной огибающей (constant envelope modulation) такие как LoRa, (G)FSK, Sigfox и LR-FHSS. Модуляции LoRa, Sigfox и (G)FSK полностью совместимы с семейством чипов SX1261/SX1262/SX1268 для диапазона sub-GHz, и могут конфигурироваться для совместимости с семейством SX1280/SX1281 диапазона 2.4GHz.

Подсистема радиотракта показана на рис. 7-1 ниже. Она состоит из синтезатора частоты (также его называют PLL), трех цепей передачи (TX High Power, TX Low Power и High Frequency) и двух цепей приема (RX), в котором применяется широкополосный ADC. И ADC, и PLL связаны с цифровой подсистемой, поддерживаемыми модемами и модулятором LR-FHSS.

Синтезатор частоты LR1121 позволяет непрерывное функционирование в диапазоне частот 150 .. 2500 МГц. Он совместно используется на радио sub-GHz и HF, поэтому одновременная работа в диапазонах sub-GHz / HF невозможна.

Синтезатор частоты LR1121 тактируется от опорной частоты тактов 32 МГц, поступающей либо от кварцевого генератора, либо от TCXO (см. секцию "6. Источники тактирования").

Команда SetRfFrequency(...) устанавливает частоту RF (PLL) радиотракта. В режиме приема (RX mode), частота внутренне преобразуется в частоту IF.

RfFreq: частота RF радиотракта в Hz. все параметры, зависящие от частоты, автоматически пересчитываются кодом LR1121 firmware при обработке этой команды.

Команда SetRx(...) установит sub-GHz радиотракт в режим приема (RX mode). Цепь прохождения сигнала sub-GHz выбирается для частот RfFreq меньше или равных 1.50 ГГц. Для частот выше используется цепь прохождения сигнала HF. Если не был принят пакет после определенного таймаута RxTimeout, устройство перейдет обратно в Standby RC mode.

RxTimeout выражается в периодах частоты 32.768kHz RTC. Максимальное значение длительности таймаута соответствует 512 секундам. Значения 0x000000 и 0xFFFFFF запрещают функцию таймаута.

• 0x000000 установит устройство в RX mode до тех пор, пока не произойдет прием пакета. После приема пакета устройство возвратится в Standby mode.
• 0xFFFFFF установит устройство в RX mode до тех пор, пока хост не поменяет режим работы. Устройство может принять несколько пакетов. Каждый раз, когда принят пакет, выдается индикация хосту (прерывание) о завершении приема пакета, и устройство автоматически ищет новый пакет.

Если таймер активен, то radio остановит прием по окончанию периода таймаута, кроме ситуации, когда был обнаружена преамбула или заголовок (Header), как это было определено конфигурацией StopTimeoutOnPreamble.

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

Сигнал BUSY перейдет в лог. 0 после того, как устройство установится в RX mode.

Команда SetTx(...) установит sub-GHz radio или HF в режим передачи (TX mode), запуская RF передачу пакета, и также запуская RTC с указанным значением TxTimeout. Здесь нет выбора PA на основе конфигурации RfFreq. Подробнее про выбор и работу PA см. главу 9. Если событие RTC возникнет до завершения передачи, то сработает TIMEOUT IRQ, и это остановит передачу. Иначе по окончании передачи пакета генерируется прерывание TX_DONE.

После TIMEOUT IRQ или TX_DONE IRQ устройство перейдет обратно в режим STBY_RC (по умолчанию), STBY_XOSC или FS, в зависимости от конфигурации FallBackMode.

TxTimeout выражается в периодах 32.768kHz RTC. Максимальное значение соответствует 512 секунд. 0x000000 запрещает функцию таймаута.

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

Сигнал BUSY перейдет в лог. 0 после того, как устройство установится в TX mode.

Команда AutoTxRx(...) автоматически выполняет переход в RX mode после передачи пакета, или в TX mode после приема пакета. После второго режима устройство перейдет обратно в Standby RC mode.

• команда SetTx(...) отправлена в устройство, то оно перейдет в RX mode после TX_DONE и указанной задержки. Timeout используется как RxTimeout для автоматического приема (auto RX).
• команда SetRx(...) отправлена в устройство, то оно перейдет в TX mode после RX_DONE и указанной задержки. Timeout используется как TxTimeout для автоматической передачи (auto TX).

Если стартовал Rx Duty Cycle, то этот режим не используется.

Delay определяет время перехода между TX mode и RX mode, выраженную в периодах 32.768kHz RTC. Максимальное значение Delay соответствует 512 секундам.

• 0x000000: выполнит прямой переход от TX к RX или от RX к TX, без прохождения через IntermediaryMode.
• 0xFFFFFF: запрещает функцию AutoTxRx. По умолчанию функция AutoTxRx запрещена.

IntermediaryMode: режим устройства между TX mode и RX mode.

• 0x00: Sleep mode.
• 0x01: Standby RC mode.
• 0x02: Standby Xosc mode.
• 0x03: FS mode.

Timeout определяет таймаут второго режима, переход в который произошел автоматически. Выражается в периодах 32.768kHz RTC. Максимальное значение таймаута соответствует 512 секундам.

Команда SetRxTxFallbackMode(...) определяет, в какой режим устройство переходит после передачи или приема пакета. Если запущен Rx Duty Cycle или сконфигурирован AutoRxTx, то этот режим не используется.

• 0x01: Standby RC mode (значение по умолчанию).
• 0x02: Standby Xosc mode.
• 0x03: FS mode.
• Другие значения RFU.

Fallback mode также исползуется для Rx Duty Cycle после прерывания RX_DONE, или для AutoRxTx после переключения от RX к TX, или когда выполнена последовательность от TX до RX.

Команда SetRxDutyCycle(...) периодически открывает окна RX. Между окнами RX устройство переходит в Sleep mode (с сохранением параметров, retention). Источник тактов для RTC должен быть сконфигурирован командой перед входом в Duty Cycle mode.

RxPeriod определяет максимальную длительность RX-окна, выраженную в периодах 32.768kHz RTC. Максимальное значение задержки соответствует 512 секундам.

SleepPeriod определяет длительность периода Sleep между RX-окнами. Она выражается в периодах 32.768kHz RTC. Максимальное значение задержки соответствует 512 секундам.

Mode выбирает режим устройства во время RX-окна:

0: конфигурирует устройство в RX mode во время RX-окна. Доступно для типов пакетов (G)FSK и LoRa.
1: конфигурирует устройство в CAD во время RX-окна. Доступно только для типов пакетов LoRa. Возвратит CMD_FAIL для типов пакетов (G)FSK.

Параметр Mode опцинальный, и устанавливается в 0, если не посылается.

Если команда посылается в Standby mode, то контекст (конфигурация устройства) сохраняется и устройство входит в цикл, определяемый следующими шагами, как показано на рис. 7-2:

1. Устройство входит в RX и прослушивает эфир на предмет послупления RF-пакета в течение периода времени, заданного параметром RxPeriod.
2. При детектировании преамбулы отсчет таймаута останаливается и перезапускается со значением 2 * RxPeriod + SleepPeriod, как показано на рис. 7-3.
3. Если не был принят никакой пакет во время RX-окна, то устройство входит в Sleep mode с сохраненным контекстом на период времени, определенным SleepPeriod.
4. По окончании окна Sleep устройство автоматически перезапустит процесс восстановления контекста и войдет в RX mode, и так далее.

Хост в любой момент времени может остановить этот цикл.

Рис. 7-3. RX Duty Cycle при детектировании преамбулы.

Цикл прервется, если произойдет что-то из следующего:

• Во время RX-окна был обнаружен пакет, в этот момент чип посылает хосту прерывание через флаг RX_DONE и возвратится к сконфигурированному режиму Fallback (см. секцию "7.2.5. SetRxTxFallbackMode").
• Хост выдал команду SetStandby(...) во время RX-окна.
• Устройство пробудилось из Sleep mode по спаду уровня NSS. В этом случае пользователь должен послать команду SetStandby(...), чтобы избежать ситуаций гонки, если спад NSS был выдан во время фазы загрузки (boot phase).

Если запущена команда RxDutyCycle(...), то режимы AutoRxTx или SetRxTxFallback не используются.

В этом режиме команда StopTimeoutOnPreamble(...) не дает эффекта.

Замечание: команда RxDutyCycle(...) возвратит CMD_FAIL на последующей команде статуса, если не был установлен тип пакета.

Команда StopTimeoutOnPreamble(...) определяет, должен ли быть остановлен RX-таймаут во время обнаружения Syncword/Header, или при детектировании преамбулы.

0x00: остановка на детектировании Syncword/Header (значение по умолчанию).
0x01: остановка на дедектировании преамбулы.

Команда GetRssiInst(...) возвратит мгновенное значение RSSI в момент отправки команды. Таким образом, если не присутствует RF-пакет, то возвращенное командой GetRssiInst(...) значение RSSI соответствует шуму RF.

RSSI вычисляется по следующей формуле: RSSI (dBm) = -Rssi/2.

Команда GetStats(...) возвратит внутреннюю статистику принятых RF-пакетов.

NbPktReceived это общее количество принятых пакетов.

NbPktCrcError это общее количество принятых пакетов с ошибкой CRC.

• Режим (G)FSK: Data1 = NbPacketLengthError(15:0): количество пакетов с ошибкой длины.
• Режим LoRa: Data1 = NbPktHeaderErr(15:0): количество пакетов с ошибкой заголовка.

• Режим (G)FSK: Data2 = 0x00.
• Режим LoRa: Data2 = NbPktFalseSync(15:0): количество сбоев синхронизации.

Статистика сбрасывается при Power On Reset, выключении питания, или по команде ResetStats(...).

Команда ResetStats(...) сбросит внутреннюю статистику принятых RF пакетов.

Команда GetRxBufferStatus(...) возвратит длину последнего принятого пакета и смещение в RX-буфере первого принятого байта.

PayloadLengthRX это длина полезной нагрузки приятого пакета в байтах.

RxStartBufferPointer это смещение в RX-буфере первого принятого байта.

Команда SetRxBoosted(...) установит устройство в RX Boosted mode, что позволяет приблизительно на 2dB увеличить чувствительность ценой повышенного потребления тока ~2 mA в RX mode.

0: RX Boosted mode деактивирован.
1: RX Boosted mode активирован.

Syncword: установит SetLoRaSyncWord. Допустимо для всех SF. Примеры значений:

Команда GetLoRaRxHeaderInfos(...) возвратит информацию, закодированную в последнем принятом заголовке пакета (explicit header mode), или сконфигурированные настройки coding_rate и crc_type:

• биты 7-5: 0 RFU
• бит 4: 1 = CRC ON, 0 = CRC OFF
• бит 3: 0 RFU
• биты 2-0: скорость кодирования (см. команду 8.3.1. SetModulationParams для значений этого поля).

Команда SetRssiCalibration(...) установит смещение усиления для встроенного в чип измерителя мощности (power estimation). Внутренний LNA чипа LR1121 устанавливается в предварительно заданные коэффициенты усиления (G4, G5, ... G13, поделенные на подусиления G13 hp1, G13hp2, ... G13 hp7), используемые для усиления мощности RF на корректном уровне, в зависимости от входной мощности RF. При нормальном использовании чипа управление усилением LNA автоматическое.

На мощность, которую видит LR1121 analog front-end, влияют внешние компоненты, такие как цепь согласования или ключи RF.

• Некорректный RSSI приводит к деградации чувствительности в режиме (G)FSK и к некорректному выбору усиления в режимах LoRa и GFSK.
• Некорректное усиление может привести к пропуску детектирования (потере пакета) или ухудшению устойчивости к помехам.

По умолчанию чип калибруется для диапазона 868-915MHz на LR1121 EVK. Таким образом, чтобы было корректным считываемое значение RSSI чипа, встроенное на печатную плату приложенияPCB, RSSI должен быть откалиброван. RSSI должен быть калиброван для каждого типа аппаратуры, но не для каждого устройства индивидуально: смещение RSSI должно быть определено один раз во время отладки аппаратуры или на фазе тестирования, и затем применено ко все устройствам, использующим то же самое оборудование (идентичные схему, разводку платы и BOM).

TuneGx(...) (аргументы от 2 до 10): значения настройки усиления индикатора уровня сигнала (RSSI Gain Tune). Tune это 4-разрядное значение со знаком, где вес младшего бита = 0.5dB.

GainOffset: глобальное смещение, добавляемое к значениям Gain Tune. Смещение это 12-разрядное значение со знаком, где вес младшего разряда = 0.5dB.

Таблица 7-21. Рекомендуемые значения для Reference EVK.

Значения Gain Tune и Gain Offset могут быть определены с помощью RF-генератора с аппаратной реализацией LR1121 следующим образом:

1. Устройство настраивается в режим GFSK и устанавливается на нужную частоту RF.

2. Устройство настраивается в режим ручной установки усиления (запрещается AGC, Auto Gain Control).

3. Используется SetRssiCalibration API для установки всех tune и offset в 0.

4. Выполняется цикл по всем различным усилениям, включая LNA boost mode (high power mode):

a. С помощью генератора выдается непрерывный тон на указанной выходной мощности gen_pwr (в зависимости от усиления), с учетом всех потерь на кабеле. Рекомендуется применять непосредственное соединение с лабораторным генератором.
b. Считывается мгновенное значение RSSI (rssi_inst).
c. Вычисляется rssi_error = rssi_inst - gen_pwr.
d. Записывается в файл rssi_error.

5. Находится общее смещение между всеми измеренными ошибками, и оно используется как новое глобальное смещение.

6. Находятся индивидуальные ошибки (относительно нового глобального смещения) и они используются в качестве tunes.

7. Вызывается SetRssiCalibration(), и снова выполняется цикл по усилениям для проверки, что мгновенный RSSI теперь откалиброван.

uint8_t gain[] = { 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 };
// ПРИМЕЧАНИЕ: для цепи 2G4 максимальное усиление 16, так что 17-20 можно игнорировать.
float power[] = { -35.0, -41.0, -45.0, -50.0, -53.5, -60.0, -65.0, -69.5, -75.0, -81.0,
                  -82.5, -83.5, -84.0, -85.0, -86.0, -86.5, -87.0 };

/* Конфигурирование чипа на системном уровне */
lr11xx_system_reset( context );
lr11xx_system_set_reg_mode( context, reg_mode );
lr11xx_system_set_dio_as_rf_switch( context, rf_switch_cfg );
lr11xx_system_set_tcxo_mode( context, tune, timeout ); // Опционально - только для TCXO
lr11xx_system_clear_errors( context );
lr11xx_system_calibrate( context, 0x3F ); // 0x3F для разрешения всех полей

/* Конфигурирование чипа на уровне модема */
lr11xx_radio_set_pkt_type( context, LR11XX_RADIO_PKT_TYPE_GFSK );
lr11xx_radio_set_rf_freq( context, freq_in_hz );
lr11xx_system_calibrate_image_in_mhz( context, freq1_in_mhz, freq2_in_mhz );
lr11xx_radio_set_gfsk_mod_params( context, mod_params ); // Rx BW должна быть установлена
                                                         // в LR11XX_RADIO_GFSK_BW_234300,
                                                         // другие параметры модуляции
                                                         // могут быть любыми.
lr11xx_radio_set_gfsk_pkt_params( context, pkt_params ); // Параметры пакета могут быть
                                                         // любыми.

/* Конфигурирование чипа для управления вручную */
lr11xx_regmem_write_regmem32_mask( context, 0x00F20214, 0x00080000, 0x00080000 );
lr11xx_regmem_write_regmem32_mask( context, 0x00F20230, 0x71110000, 0x71100000 );
lr11xx_radio_set_rssi_calibration( context, rssi_cal_table ); // Все параметры rssi_cal_table
                                                              // устанавливаются в 0
lr11xx_radio_set_rx_with_timeout_in_rtc_step( context, 0xFFFFFF );

for(int i = 0; i++; i < 17) // 17 это количество элементов в массиве усилений gain
{
   const uint8_t gain_step = MIN( gain[i], 13 );
   const uint8_t lna_boost = ( gain > 13 ) ? gain - 13 : 0;
   lr11xx_regmem_write_regmem32_mask( context, 0x00F20214, 0x00F00000, gain_step < < 20 );
   lr11xx_regmem_write_regmem32_mask( context, 0x00F3008C, 0x00070000, lna_boost < < 16 );
   /* Ожидание 1 мс */
   /* Здесь вставляется управление вашим тестовым оборудованием, чтобы генерировать
      тон на частоте RF, установленной в freq_in_hz, с выходной мощностью, установленной
      в power[i] dBm */
   lr11xx_radio_get_rssi_inst( context, rssi_in_dbm );
   /* Добавляется способ регистрации триплета (gain[i], power[i], rssi_in_dbm), чтобы
      можно было вычислить значения offset и tunes для калибровки RSSI */
}

The LR1121 содержит различные модемы, которые могут обрабатывать модуляции с постоянной огибающей (constant envelope modulation). Для модемов LoRa®/(G)FSK, модуляций LR-FHSS и Sigfox подходящая последовательность команд следующая:

• Пользователь должен указать используемый модем командой SetPacketType(...).
• Команда SetModulationParams(...) конфигурирует параметры модема (SF, BW, CR и LDRO).
• SetPacketParams(...) определяет параметры RF-пакета (длина полезной нагрузки Implicit/Explicit mode, ...). Эта команда не нужна для LR-FHSS.
• SetPaConfig(...) конфигурирует настройки PA, используемые для передачи RF-пакета (какой PA, режим питания...).
• SetTxParams(...) определяет параметры PA (выходная мощность, время нарастания мощности ramp time).

Рис. 8-1. Последовательность команд настройки модема.

Руководство по использованию Modem-E firmware см. по ссылке [3].

Команда SetPacketType(...) определяет, какой модем используется.

PacketType определяет используемый модем для последующих RF-транзакций:

0x00: None (по умолчанию)
0x01: (G)FSK
0x02: LoRa
0x03: Sigfox Uplink⁽¹⁾
0x04: GMSK (LR-FHSS)
Другие значения RFU.

Эта команда первая из вызываемых перед переходом в RX или TX, и перед определением модуляции и параметров пакета. Она работает только когда устройство находится в режимах Standby RC, Standby Xosc или Fs, иначе в статусе будет возвращена ошибка CMD_FAIL при выдаче следующей команды.

Команда GetPacketType(...) возвратит текущий протокол radio.

PacketType соответствует модему, используемому для последующих RF-транзакций:

Примечание (1): Sigfox downlink выполняется с использованием PacketType 0x01, подробности см. в апноуте AN1200.73.

В этой главе объясняются некоторые термины технологии LoRa.

Модем LoRa использует проприетарную технологию модуляции с расширением спектра (spread spectrum modulation), которая позволяет использовать увеличенный бюджет линка и повышенную устойчивость к помехам на используемой полосе частот в сравнении с традиционными техниками модуляции. Это позволяет принимать сигналы с отрицательным SNR, что увеличивает как бюджет канала связи, так и дальность связи приемника LoRa.

Модуляция spread spectrum LoRa выполняется путем представления каждого бита информации полезной нагрузки несколькими "chips". Скорость, с которой spread-символ (содержащий 2^SF chips) посылается, называют symbol rate (Rs). Соотношение между номинальной symbol rate и chip это Spreading Factor (SF), и он определяет количество бит, посылаемых на символ.

Замечание: spreading factor должен быть заранее известен на обоих сторонах обмена (на приемнике и передатчике), поскольку разные SF ортогональны друг другу.

Модем LoRa работает на программируемой полосе частот (BWL) вокруг центральной частоты fRF. Полоса частот модема LoRa всегда относится к двойной полосе частот (double side band, DSB), как показано на рис. 8-2.

Расширение полосы частот позволяет использовать повышенные эффективные скорости передачи, уменьшая время передачи ценой снижения чувствительности.

Замечание: большинство стран вводят регуляторные ограничения на допустимую полосу частот, поэтому можно использовать ограниченное подмножество вариантов BWL.

Чтобы дополнительно улучшить надежность линка, модем LoRa реализует специальное кодирование (cyclic error coding) для выполнения опережающих обнаружения и коррекции возникающих ошибок (forward error detection and correction, FEC). Такое кодирование вносит в передачу дополнительную информационную нагрузку.

LDRO повышает надежность линка LoRa на низких скоростях данных, повышая чувствительность, устойчивость к дрейфу частоты и эффектам Доплера. Использование LDRO предписано на SF11 и SF12 на полосе частот 125kHz, и SF12 на полосе частот 250kHz.

Зная ключевые параметры, которыми может управлять пользователь, мы определяем скорость передачи символов LoRa следующим образом:

Здесь BWL и SF это программируемые параметры полосы частот и spreading factor. Передаваемый сигнал является сигналом с постоянной огибающей (constant envelope signal). Эквивалентно один chip посылается в секунду на Гц полосы частот.

Модем LoRa поддерживает 2 формата пакета: режимы явного и неявного заголовка (explicit header mode и implicit header mode). Explicit пакет содержит дополнительную информацию, которая включает короткий заголовок, содержащий информацию о количестве байт, скорости кодирования (coding rate) и используется ли CRC в пакете.

В определенных сценариях, когда фиксированы и заранее известны параметры полезной нагрузки, coding rate и наличия CRC, есть смысл уменьшить время передачи использованием режима неявного заголовка (implicit header mode). В этом режиме заголовок удаляется из пакета. В этом случае длина полезной нагрузки (payload length), скорость кодирования коррекции ошибок (error coding rate) и наличие контрольной суммы полезной нагрузки (payload CRC) должны быть одинаково сконфигурированы на обоих концах RF канала связи.

Пакет LoRa начинается с последовательности преамбулы, используемой для синхронизации приемника с приходящим сигналом. Передаваемая преамбула может варьироваться от 1 до 65535 символов. Это позволяет передавать почти произвольно длинные последовательности преамбулы. Для оптимизации приема пакетов рекомендуется использовать минимальную длину преамбулы 12 для SF5 и SF6, и 8 для других SF.

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

8.2.2.2. Header (заголовок, только для explicit пакетов)

Заголовок предоставляет информацию о полезной нагрузке:

• Длина полезной нагрузки в байтах.
• Скорость кодирования опережающей коррекции ошибок (forward error correction coding rate).
• Опциональное применение 16-битной CRC для данных полезной нагрузки.

Заголовок передается с максимальным коэффициентом кодирования для восстановления ошибок (error correction code 4/8). Это также содержит собственную CRC заголовка, позволяющую отбрасывать некорректные заголовки.

Полезная нагрузка это поле данных переменной длины, содержащее полезные данные, закодированные со скоростью, заданной в заголовке explicit-режима, или заданной в настройках регистров при использовании implicit-режима. Опционально может быть добавлена CRC полезной нагрузки.

8.2.2.4. LoRa Packet Time On Air (время передачи пакета по радиоканалу)

Детектирование активности канала CAD, используемое только в пакетах LoRa, это специальный режим LoRa, когда устройство ищет в обоих полях преамбулы и полезной нагрузки наличие сигнала преамбулы LoRa.

По окончании периода поиска устройство генерирует IRQ CADdone. Если был обнаружен корректный сигнал, то также генерируется IRQ CadDetected. Для выполнения CAD рекомендуется минимум 2 символа.

После завершения поиска устройство вернется в режим STDBY_RC. Длина поиска конфигурируется командой SetCadParams(...).

Команда SetModulationParams(...) конфигурирует параметры модуляции для выбранного модема. Поскольку параметры зависят от модема, то приведенное ниже описание применимо только для модема LoRa.

SF определяет spreading factor (не перечисленные ниже значения относятся к RFU). SF5 и SF6 совместимы с семейством устройств SX126x. SF6 может быть совместимым с семейством SX127x в implicit режиме через настройку регистров(1).

0x05: SF5
0x06: SF6
0x07:SF7
0x08: SF8
0x09: SF9
0x0A: SF10
0x0B: SF11
0x0C: SF12

BWL определяет полосу частот модуляции LoRa (не перечисленные ниже значения относятся к RFU):

0x03: LoRa_BW_62, полоса частот 62.5kHz
0x04: LoRa_BW_125, полоса частот 125kHz
0x05: LoRa_BW_250, полоса частот 250kHz
0x06: LoRa_BW_500, полоса частот 500kHz
0x0D: BW203 (только для диапазона 2.4GHz)
0x0E: BW406 (только для диапазона 2.4GHz)
0x0F: BW812 (только для диапазона 2.4GHz)

CR конфигурирует Coding Rate. Длинное чередование (Long Interleaver) повышает устойчивость к помехам (не перечисленные ниже значения относятся к RFU):

0x01: Short Interleaver CR = 4/5 Overhead Ratio 1.25
0x02: Short Interleaver CR = 4/6 Overhead Ratio 1.5
0x03: Short Interleaver CR = 4/7 Overhead Ratio 1.75
0x04: Short Interleaver CR = 4/8 Overhead Ratio 2
0x05: Long Interleaver CR = 4/5(2) Overhead Ratio 1.25
0x06: Long Interleaver CR = 4/6(2) Overhead Ratio 1.5
0x07: Long Interleaver CR = 4/8(2) Overhead Ratio 2

LowDataRateOptimize уменьшает количество бит на символ:

0x00: LowDataRateOptimize выключено
0x01: LowDataRateOptimize включено

(1) LR1121 должен установить бит 18 в 1 и бит 23 в 0 регистра по адресу 0xF20414.
(2) Long Interleaver (CR = 4/5, 4/6 и 4/8) поддерживается для пакетов с минимальной длиной полезной нагрузки 8 байт и максимальной длиной полезной нагрузки 253 байта, если CRC активирована (255 байт, если CRC деактивирована).

Команда SetPacketParams(...) конфигурирует параметры RF-пакета для выбранного модема. Поскольку параметры зависят от модема, то приведенное ниже описание применимо только для модема LoRa.

PbLengthTX определяет длину преамбулы пакета LoRa. Кодируется 2 байтами от 0x0001 (1) до 0xFFFF (65535). Рекомендуется установить минимум 12 для SF5 и SF6, и 8 для других вариантов SF.

HeaderType определяет, явный или неявный заголовок:

0x00: Explicit header (явный заголовок, по умолчанию)
0x01: Implicit header (неявный заголовок)

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

0: допускается прием полезной нагрузки любой длины от 0 до 255 байт.
N: допускается прием полезной нагрузки от 1 до N байт. Длины полезной нагрузки 0 или > N отбрасываются и генерируют HeaderErr IRQ.

В режиме неявного заголовка PayloadLen конфигурирует точную длину полезной нагрузки, которая передается или принимается.

0x00: OFF (CRC не используется)
0x01: ON (CRC используется)

InvertIQ определяет, инвертированы или нет сигналы I и Q.

Эта команда завершится неудачей, если не был установлен тип пакета.

Команда SetCadParams(...) определяет параметры LoRa CAD.

SymbolNum определяет количество символов, используемых для детектирования CAD.

DetPeak и DetMin определят чувствительность модема LoRa, когда он пытается обнаружить корреляцию с актуальными символами преамбулы LoRa. Эти две настройки зависят от LoRa spreading factor, Bandwidth и количества символов, используемых для проверки и детектирования сигнала. Выбор правильного значения должен быть тщательно протестирован для обеспечения наилучшего детектирования для уровня чувствительности, и также для ограничения количества неправильных обнаружений сигнала.

CadExitMode определяет действие, которое выполняется после операции CAD.

Таймаут используется только когда CAD выполняется с cadExitMode = CAD_RX или CAD_LBT.

• Если cadExitMode = CAD_RX, то см. 7.2.2. SetRx для определения таймаута.
• Если cadExitMode = CAD_LBT, то см. 7.2.3. SetTx для определения таймаута.

Команда SetLoRaSynchTimeout(...) конфигурирует модем LoRa для выдачи RX timeout после именно SymbolNum символов, если к тому времени пакет не был обнаружен.

SymbolNum: 0x00 означает отсутствие таймаута (значение по умолчанию).

Команда SetLoRaPublicNetwork(...) установит синхрослово (Syncword) модема LoRa modem для публичной или частной сети.

0x00: Private network (частная сеть, значение по умолчанию).
0x01: Public network (публичная сеть).

Команда GetPacketStatus(...) получает статус последнего принятого пакета. Поскольку возвращенные значения зависят от установленного модема, то приведенное ниже описание применимо только для модема LoRa.

RssiPkt определяет средний RSSI по последнему принятому пакету. Значение RSSI в dBm вычисляется как –RssiPkt/2.

SnrPkt это оценка SNR на последнем принятом пакете. Выражается значением в формате двоичного дополнения (two’s complement format), умноженным на 4. Фактическое SNR в dB вычисляется как SnrPkt/4. Значение SNR является несмещенным масштабированным значением.

Если деление на 4 выполняется операцией плавающей точки, то стандартное округление предоставит корректное значение. Если деление на 4 выполняется операцией с фиксированной точкой, то рекомендуется выполнить округление к ближайшему целому значению. В C-драйверах от Semtech это выполняется путем начального добавления 2, и затем выполняется деление на 4 методом сдвига:

SignalRssiPkt это оценка RSSI сигнала LoRa (после despreading) последнего принятого пакета, в формате двоичного дополнения [negated, dBm, fixdt(0,8,1)]. Актуальный RSSI в dB вычисляется как -SignalRssiPkt/2.

Дополнительную информацию по RSSI можно найти в секции "8.10. Функционал RSSI".

Модем (G)FSK может передавать 2-FSK модулированные пакеты со скоростями данных от 0.6kbps до 300kbps.

И скорость бит (Bitrate), и девиация частоты (Fdev) непосредственно конфигурируется командой SetModulationParams().

Дополнительно в режиме передачи к сигналу могут быть применены несколько формирующих фильтров (shaping filters) в пакетном режиме (packet mode) или непрерывном режиме (continuous mode). В режиме приема пользователю нужно выбрать самую лучшую полосу частот в зависимости от его условий. Для обеспечения корректной демодуляции должно соблюдаться следующее ограничение по полосе частот:

Здесь полоса частот BWF в диапазоне от 4.8kHz до 467kHz.

Полоса частот должна быть выбрана так, чтобы выполнялось условие:

Полоса [DSB] >= BR + 2 x девиация_частоты + ошибка_частоты

Здесь ошибка_частоты это удвоенная ошибка по частоте используемого кварцевого резонатора.

LR1121 разработан для обмена с использованием пакетов. Контроллер пакетов работает только полудуплексном режиме (half-duplex), т. е. в любой момент времени происходит либо передача, либо прием. Это конфигурируется командой SetPacketParams(...). Эта функция может быть вызвана только после определения протокола.

Блок контроллера пакета отвечает за сборку принятых потоков бит данных в пакеты и сохранение их в буфер данных. Он также выполняет операции декодирования потока бит, такие как de-whitening (операция XOR с псевдослучайной последовательностью над данными) & CRC-проверки на принятом потоке бит.

LR1121 может отбросить пакет, если он увидел недостаточное количество чередующихся символов преамбулы (обычно это данные 0x55 или 0xAA). Параметр PblDetect в команде SetPacketParams(...) определяет длину детектора преамбулы, и позволяет пользователю выбрать диапазон от:

• Off: радиотракт не производит регулирование приема по преамбуле, и непосредственно ожидает появление Syncword, до
• 32 бит: радиотракт ожидает приема 32 бит преамбулы перед последующим Syncword. В этом случае, если 32 бита преамбулы не обнаружены, то радиотракт либо отбросит прием в режиме RxSingle, либо перезапустит свой цикл отслеживания в режиме RxContinuous.

Для достижения самой лучшей производительности рекомендуется установить PblDetect в 8 или 16 бит, в зависимости от полного размера преамбулы, передаваемой передатчиком.

Замечание: для корректного детектирования пакетов PblDetect должен быть всегда меньше, чем размер последующего за преамбулой Syncword. Если PblDetect больше, чем длина Syncword (обычно когда Syncword не используется) то пользователь должен заполнить байты Syncword значениями 0x55.

В режиме передачи обработчик пакета должен формировать и посылать поток бит в модулятор. Он может применить операцию whiten над полезной нагрузкой (XOR-наложение на данные псевдослучайной последовательности), а также добавлять контрольную сумму CRC в конец пакета.

Формат пакета (G)FSK предоставляет обычный формат для приложений в проприетарном кодировании NRZ, на каналах связи низкой энергии. В формат пакета встроена проверки CRC для полезной нагрузки. Полезная нагрузка может быть динамическая, и предусматривается подтверждение пакета. Может быть разрешена фича whitening, когда на передаваемые данные накладывается псевдослучайная последовательность. Доступны два принципа формирования пакета в протоколе (G)FSK: фиксированная длина и переменная длина.

8.4.3.1. Fixed-Length Packet (пакет фиксированной длины)

Если длина пакета фиксирована и известна на обоих сторонах канала связи, то длину пакета передавать не нужно. Для этого длина пакета записывается в параметр PacketLength который определяет длину пакета в байтах:

• от 0 до 255, если фильтрация адреса не активирована.
• от 0 до 254, если фильтрация адреса активирована.

Обычно рекомендуется использовать минимум 16 бит для преамбулы, чтобы гарантировать корректный прием пакета. Работа CRC, длина пакета и длина преамбулы определяются командой SetPacketParams(...).

8.4.3.2. Variable-Length Packet (пакет переменной длины)

В пакете содержится поле Length, которое кодирует длину пакета в файлах.

Формат пакета переменной длины показан на рис. 8-5:

• Длина пакета может быть от 0 до 254 байт, если активирована фильтрация адреса.
• Поле Length имеет длину 1 байт, за исключением совместимости с SX128x, когда у него длина 9 бит (см. "8.4.4. Совместимость с SX128x").

8.4.3.3. Установка длины пакета (Packet Length) или адреса узла (Node Address)

Длина пакета и адрес Node или Broadcast не считаются полезной нагрузкой, и автоматически добавляются аппаратурой. Длина пакета автоматически добавляется в пакет, когда поле PacketType установлено в переменный размер командой SetPacketParams(...).

Адрес узда (node address) или широковещательный адрес (broadcast address) может быть разрешен полем AddrComp в команде SetPacketParams(...). Это поле позволяет пользователю разрешить и выбрать дополнительную фильтрацию пакета на уровне полезной нагрузки.

Операция whitening основана на 9-разрядном LFSR [4] с полиномом x⁹+x⁵+1 для диапазона sub-GHz и с полиномом x⁷ + x⁴ + 1 для HF, который генерирует "случайную" последовательность бит. С такой структурой LSB на выходе LFSR операцией XOR объединяется с MSB данных. На начальной стадии команда SetGfskWhitParams(...) установит начальное состояние регистра (whitening Seed).

Тогда вся полезная нагрузка (включая длину полезной нагрузки, адреса Node или Broadcast, а также CRC, когда она необходима) операцией XOR складывается с этой псевдослучайной последовательностью для генерации whitened полезной нагрузки.

Обратная операция восстановления данных (de-whitened) на приемнике выполняется той же самой операцией XOR на такой же псевдослучайной последовательности. Процесс Whitening ограничивает количество идущих друг за другом нулей или единиц 9 разрядами. Обратите внимание, что whitening для данных требуется только когда в пользовательских данных присутствует высокая корреляция длинных последовательностей нулей и единиц. Если данные уже имеют случайный вид, то операция whitening не требуется.

LR1121 предоставляет возможность для выбора полинома CRC и начального значения выбранного полинома. Пользователь также может выбрать полную инверсию вычисленного CRC для соответствия некоторым международным стандартам.

CRC может быть разрешена и сконфигурирована полем CrcType в команде SetPacketParams(...). Это позволяет разрешить CRC и выбрать длину и конфигурацию CRC.

Команда SetGfskCrcParams(...) конфигурирует полином CRC и начальное значение.

Применяются следующие ограничения, когда используется 9-разрядный заголовок SX128x типа пакета PacketType 0x02:

• Payload length: длина полезной нагрузки ограничена максимум 254 - CrcLength (например 252 байта с 16-разрядной CRC).
• CRC length: 0, 1 или 2 байта.
• Syncword length: разрешены только длины синхрослова 8, 16, 24, 32 или 40 бит.
• AddrComp: эта фича должна быть запрещена (её нет в SX128x).
• DcFree фича должна быть либо запрещена (0x00), либо совместимой с SX128x (0x03). 0x01 не принимается.

Чтобы по радиоканалу LR1121 был совместим с SX128x:

• Командой SetGfskWhitParams установите whitening seed 0x0001 (значение по умолчанию SX128x).

1 байт CRC: seed = 0xFF, poly = 0x07
2 байта CRC: seed = 0xFFFF, poly = 0x1021

- для передаваемых кадров передается 7 дополнительных бит;
- для принимаемых кадров принимается 23 дополнительных бит (задержанное RX_DONE IRQ).

8.4.5. Специальные настройки для BRF = 0.6kbps и 1.2kbps

Необходимы дополнительные настройки радиоканала для скоростей 0.6kbps и 1.2kbps, а именно:

• BRF = 1.2kbps: запись 0 в бит 4 по адресу 0x08b8 (инструкцией read-modify-write).

• BRF = 0.6kbps: запись следующих бит (инструкцией read-modify-write):

биты 4:3 @ 0x06D1 в 0x03
биты 4:2 @ 0x089B в 1
бит 4 @ 0x08B8 в 0
бит 6 @ 0x06AC в 1
бит 5 @ 0x06AC в 0
бит 4 @ 0x06AC в 1

Пользователь в любой может может прочитать значения по умолчанию регистров 0x6D1, 0x89B, 0x6AC, 0x8B8, и использовать их для восстановления при необходимости. Эти регистры не восстанавливают свои значения по умолчанию командами SetPacketParams и SetModulationParams.

Команда SetModulationParams(...) конфигурирует параметры модуляции выбранного модема. Поскольку значения параметров зависят от установленного модема, то приведенное ниже описание применимо только для модема (G)FSK.

BitRate: интерпретация скорости бит (G)FSK зависит от BitRate(31). Это либо bits/s, либо 8 LSB дробной части:

BitRate(31) = 0: GFSK Bitrate в bits/s это BitRate(30:0)
BitRate(31) = 1: GFSK Bitrate в bits/s это BitRate(30:0)/256

PulseShape определяет фильтрацию, применяемую к пакету (G)FSK:

0x00: никакой фильтр не применяется
0x08: Gaussian BT 0.3
0x09: Gaussian BT 0.5
0x0A: Gaussian BT 0.7
0x0B: Gaussian BT 1
0x16: Raise Cosine BPSK BT 0.7

Команда SetPacketParams(...) конфигурирует параметры RF пакета для выбранного модема. Поскольку значения параметров зависят от установленного модема, то приведенное ниже описание применимо только для модема (G)FSK.

PblLengthTX определяет длину преамбулы пакета (G)FSK в битах. Она кодируется 2 байтами, от 0x0008 (8 бит) до 0xFFFF (65535 бит).

PblDetect определяет длину детектора преамбулы. Детектор преамбулы работает как шлюз для контроллера пакета. Когда PblDetect не 0x00 (0x00 соответствует выключенному детектору преамбулы), контроллер пакета активируется только если будет успешно обнаружено определенное количество бит преамбулы.

0x00: длина детектора преамбулы выключена
0x04: длина детектора преамбулы 8 бит
0x05: длина детектора преамбулы 16 бит
0x06: длина детектора преамбулы 24 бита
0x07: длина детектора преамбулы 32 бита

SyncWordLen определяет длину синхрослова (Syncword). Синхрослово программируется командой SetGfskSyncWord(...). SyncWordLen должна быть выровнена по размеру байта. Например, в полезную нагрузку попадет до 7 бит Syncword, если SyncWordLen не выровнен по 8 битам.

AddrComp позволяет привести прием пакета к предварительно заданному адресу противоположного устройства. Адрес узла (node address) и широковещательный адрес (broadcast address) могут быть установлены командой SetPacketAdrs(...). Если сравнение адреса терпит неудачу, то прием пакета отменяется, и установится флаг adrsErr.

0x00: фильтрация адреса запрещена.
0x01: Rx и Tx: фильтрация адреса активирована на node address.
0x02: фильтрация активирована для Rx на node и broadcast адресах, для Tx на node адресе.

0x00: длина пакета известна на обоих сторонах, размер полезной нагрузки не добавляется в пакет.
0x01: у пакета переменный размер, PayloadLen это размер пакета (в заголовке он кодируется 8 битами).
0x02: у пакета переменный размер, PayloadLen это размер пакета - в режиме совместимости с чипом SX128x (в заголовке он кодируется 9 битами).

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

0: разрешен прием любой полезной нагрузки длиной между 0 и 255 байт.
N: разрешен прием любой полезной нагрузки длиной между 1 и N байт. Длины полезной нагрузки 0 или > N отклоняются с генерацией HeaderErr IRQ.

В режиме implicit header поле PayloadLen конфигурирует точную длину полезной нагрузки, которая передается или принимается.

CrcType определяет CRC пакета. CRC можно полностью конфигурировать как по используемому полиному, так и начальному значению, что настраивается командой SetGfskCrcParams(...).

0x01: CRC_OFF (без CRC)
0x00: CRC_1_BYTE (CRC вычисляется в 1 байт)
0x02: CRC_2_BYTE (CRC вычисляется в 2 байта)
0x04: CRC_1_BYTE_INV (CRC вычисляется в 1 байт и инвертируется)
0x06: CRC_2_BYTE_INV (CRC вычисляется в 2 байта и инвертируется)

0x00: whitening-кодирование не применяется.
0x01: разрешено whitening-кодирование, совместимое с SX127x/SX126x/LR11xx.
0x03: разрешено whitening-кодирование, совместимое с SX128x.

Команда SetGfskSyncWord(...) конфигурирует синхрослово (Syncword) пакета (G)FSK.

Syncword: по умолчанию 0x9723522556536564. Только для приема, GFSK Syncword должно по размеру нацело делиться на 8 бит. Если это не так, то Syncword должно все еще быть сконфигурировано нацело делящимся на 8 бит, и Syncword должно иметь фильтр, добавленный в начало. Например, если длина Syncword была 30 бит, то длина синхрослова должна быть сконфигурирована в 32 бита, и значения "01b" или "10b" должны быть добавлены в начало Syncword.

Команда SetPacketAdrs(...) установит адрес Node или адрес Broadcast, используемый для приема/передачи пакета (G)FSK, когда фильтрация разрешена (AddrComp 0x01 или 0x02).

Если сравнение адреса потерпело неудачу, то прием пакета обрывается, и установится флаг adrsErr.

Команда SetGfskCrcParams(...) конфигурирует полином CRC и его начальное значение, так что им не надо управлять вручную.

InitValue: начальное значение сконфигурированного полинома CRC (по умолчанию 0x1D0F).

• 0xFFFF для начального значения
• 0x8005 для полинома CRC
• 0x02 (CRC_2_BYTE) для поля CrcType в команде SetPacketParams(...).

• 0x1D0F для начального значения
• 0x1021 для полинома CRC
• 0x06 (CRC_2_BYTE_INV) для поля CrcType в команде SetPacketParams(...).

Команда SetGfskWhitParams(...) устанавливает начальное значение операции whitening (Seed):

Команда GetPacketStatus(...) получает информацию по состоянию последнего принятого пакета. Поскольку возвращенные значения зависят от установленного модема, то приведенное ниже описание применимо только для модема (G)FSK.

• биты 31:24: RssiSync, значения RSSI, захваченные в момент детектирования sync-адреса. Negated, dBm, ufix(8,1).
• биты 23:16 RssiAvg, среднее RSSI по полезной нагрузке принятого пакета. Захватывается в момент генерации packet_done IRQ. Negated, dBm, ufix(8,1).
• биты 15:8 RxLen, длина (Length) принятого пакета.
• бит 7: RFU.
• бит 6: RFU.
• бит 5: Adrserr, статус фильтрации адреса текущего пакета. Установится, когда адрес принятого пакета не совпадет с node_adrs(7:0) или broadcast(7:0) в соответствии с конфигурацией adrs_comp(1:0).
• бит 4: Crcerr, статус проверки CRC текущего пакета. Применимо только в Rx, когда проверка CRC не запрещена. Пакет доступен в FIFO.
• бит 3: Lenerr, статус фильтрации длины (Length) текущего пакета. Установится, когда длина принятого пакета больше, чем Max длина, определенная полем payload_len(7:0). Применяется только на Rx для пакетов переменной длины.
• бит 2: Aborterr, статус Abort текущего пакета. Установится, когда текущий пакет оборван полем pkt_abort_p регистра. Применимо и в режиме Rx и в режиме Tx.
• бит 1: PktRcvd, статус приема пакета. Показывает, что прием пакета завершился. Показывает только то, что процесс приема завершился, но не достоверность пакета. Применимо только для Rx.
• бит 0: PktSent, статус передачи пакета. Показывает, что передача пакета завершена. Применимо только для Tx.

LR-FHSS это frequency hopping spread spectrum modulation, метод модуляции с применением псевдослучайной перестройки рабочей частоты (ППРЧ). Несущая частота радиосигнала быстро и псевдослучайным образом переключается между разными частотами в заданном диапазоне. Передатчик и приемник знают последовательность переключения, что позволяет им синхронно "прыгать" по частотам, обеспечивая надежную передачу данных, устойчивую к помехам.

Этот вид модуляции отлично подходит для коммуникаций дальнего радиуса действия, когда в одной и той же области находятся большое количество устройств. LR-FHSS может обеспечить почти эквивалентный бюджет режиму LoRa SF12 BW125kHz, причем позволяет множеству устройств соседствовать друг с другом в одной области спектра. Реализация LR-FHSS в LR1121 поддерживает только передачу. LR1121 имеет полный контроль над следующим функционалом:

• Конструирование кадров, включая преамбулу, заголовки синхронизации (sync headers), полезную нагрузку (payload), проверку целостности (integrity check), размазывание длинной последовательности одинаковых уровней (whitening), чередование (interleaving) и кодирование для упреждающей коррекции ошибок (forward error correction).
• Вычисление последовательностей прыжков по частоте (hopping sequences).
• Обработка всего механизма прыжков по частоте.

LR-FHSS это модуляция с низкой скоростью передачи данных, наследующая принцип модуляции GMSK, с применением конфигурируемых последовательностей прыжков перестройки по частоте внутри пакета для каждого устройства. В настоящий момент поддерживается только скорость данных 488.28215Hz. Передача полезной нагрузки использует сверточное кодирование для реализации упреждающего обнаружения и коррекции ошибок (FEC), что подразумевает введение некоторой избыточности в передаваемые данные. В контексте распределения спектра пакет LR-FHSS делится на несколько кадров, посылаемых через псевдо-случайно распределенные частоты, разделенные конфигурируемым шагом (Grid). Общее занятие спектра пакета LR-FHSS соответствует параметру Bandwidth. Модуляция LR-FHSS представлена на рис. 8-6.

Рис. 8-6. Спектральная диаграмма примера модуляции LR-FHSS.

Каждый кадр полезной нагрузки (Payload frame), кроме последнего, содержит ровно 50 закодированных бит, и их длительность одинакова по времени. Последний кадр может содержать меньше 50 бит. Таким образом, количество кадров меняется с изменением полезной нагрузки и скорости кодирования (Coding Rate).

Кадры полезной нагрузки предваряются одним - четырьмя последовательностями синхронизации (Headers), чтобы обеспечить надежную синхронизацию по частоте и времени. Даже если прием одного Header достаточен для декодирования полезной нагрузки, как минимум 2 Header улучшают устойчивость против радиопомех. Если используется несколько header, то они посылаются на разных частотах. Каждый header содержит ровно 114 закодированных бит, и таким образом их длительность одинакова по времени.

Дополнительная информация представлена в апноутах AN1200.58 Long Range FHSS Demo и AN1200.64 Long Range FHSS System Performance.

Комада SetModulationParams(...) конфигурирует параметры модуляции для выбранного модема. Поскольку параметры зависят от установленного модема, то приведенное ниже описание применимо только для модуляции LR-FHSS.

BitRate определяет скорость бит LR-FHSS в битах на секунду. Значение скорости в bits/s определяется как Bitrate(30:0)/256, где Bitrate(31) = 1. Например, скорость 488.28215Hz будет кодироваться Bitrate = 125000 с Bitrate(31) = 1.

В текущей реализации поддерживается только LR-FHSS на скорости 488.28215 Гц, другие значения RFU.

PulseShape определяет фильтрацию, применяемую для пакета LR-FHSS:

Команда LrFhssBuildFrame(...) кодирует заданную полезную нагрузку и конфигурирует внутреннюю таблицу перескоков по частотам (hopping table).

HeaderCount: количество заголовков (Headers) для пакета LR-FHSS packet: 1, 2, 3 или 4.

ModType: 0 = модуляция GMSK, скорость данных 488.28125bps.

0x00: 25.390625kHz для случая использования FCC.
0x01: 3.90625kHz для случая, не относящегося к FCC.

Hopping: конфигурирует наличие перестроек по частоте внутри пакета (intra-packet hopping):

0x00: без перестроек, no hopping (для целей тестирования)
0x01: перестройка между кадрами разрешена (hopping)

BW: полоса частот, занимаемая шаблоном перестроек по частоте:

0x00: 39.06kHz
0x01: 85.94kHz
0x02: 136.72kHz
0x03: 183.59kHz
0x04: 335.94kHz
0x05: 386.72kHz
0x06: 722.66kHz
0x07: 773.44kHz
0x08: 1523.4kHz
0x09: 1574.2kHz

HopSequence: 9-битное целое число, начальное значение (seed) для псевдослучайных перестроек по частоте:

Значение в диапазоне [0; 383] для Grid = 0x00, BW в {0x06, 0x07, 0x08, 0x09}
Значение в диапазоне [0; 383] для Grid = 0x01, BW в {0x00, 0x01, 0x02, 0x03}
Значение в диапазоне [0; 511] для Grid = 0x01, BW в {0x04, 0x05, 0x06, 0x07, 0x08, 0x09}

DeviceOffset: смещение частоты на устройстве для уменьшения риска коллизии пакетов. Смещение частоты (Гц) = DeviceOffset * 488.28125Hz:

Значение со знаком в диапазоне [-26; 25] для Grid = 25.390625kHz
Значение со знаком в диапазоне [-4; 3] для Grid = 3.90625kHz

Для случая использования FCC параметр DeviceOffset не должен меняться, будучи сконфигурированным.

Payload: фактически кодируемая полезная нагрузка. Возвратит CMD_OK, если параметры правильные, и если полезную нагрузку можно закодировать, иначе CMD_PERR.

Максимальный поддерживаемый размер пакета составляет 255 кодируемых байт. Максимальная длина полезной нагрузки пользователя приведена в таблице 8-24.

Таблица 8-24. Максимальная полезная нагрузка пользователя (в байтах).

Случай использования FCC соответствует BW = 0x08/0x09, Hopping = 0x01, Grid = 0x00.

Замечание: эта команда не посылает пакет LR-FHSS. Передача срабатывает по команде SetTx(...).

Команда LrFhssSetSyncWord(...) установит синхрослово LR-FHSS Syncword.

Syncword: синхрослово LR-FHSS. Значение по умолчанию {0x2C, 0x0F, 0x79, 0x95}.

8.7.4. Конфигурация устройства для Long Range FHSS Transmission

После включения питания (установка батареи или аппаратного сброса) LR1121 автоматически запустит процедуру калибровки и перейдет в режим STDBY_RC. Это покажет лог. 0 на выводе BUSY.

Из STDBY_RC необходимая последовательность операций для перехода в режим передачи Long Range FHSS следующая:

1. Если устройство не находится в режиме STDBY_RC, то установите схему в этот режим командой SetStandby(...).
2. Установите базовые команды конфигурации, такие как RF switch, конфигурация PA, OCP, TxParams, RfFrequency...
3. Определите модуляцию (LR-FHSS) командой SetPacketType(...).
4. Установите параметры модуляции (командой SetModulationParams(...)) с правильным значением Bit Rate (488.28125 bps), и правильным Pulse Shape.
5. Вызовите команду LrFhssBuildFrame(...).
6. Активируйте IRQ: TxDone.
7. Установите схему в режим передатчика для запуска передачи командой SetTx(...).
8. Ожидайте прерывания TxDone.

Если это сконфигурировано, то генерируется LrFhssHop IRQ на каждом перескоке частоты внутри пакета LR-FHSS, после каждого включения усилителя мощности (PA ramp-up).

LR1121 может передавать Sigfox-пакеты на скоростях как 100, так и 600bps. Это позволяет поддерживать все варианты конфигураций (Sigfox Radio Configurations) от RC1 до RC7. LR1121 также может принимать Sigfox downlinks на 600bps в выбранной Sigfox Radio Configuration. Обратитесь к представительству Semtech за дополнительной информацией.

Внутри LR1121 нет встроенной реализации стека протоколов Sigfox. Пользоватлеь должен сам конфигурировать и передавать пакеты Sigfox в соответствии с порядком команд, обозначенном на рис. 8-1 "Последовательность команд настройки модема".

Поскольку команды SetModulationParams(...) и SetPacketParams(...) специфичны для выбранного модема, здесь приведено описание этих команд в контексте поддержки протокола Sigfox.

Команда SetModulationParams(...) конфигурирует параметры модуляции для выбранного модема. Поскольку параметры зависят от модема, последующее описание применимо только для модуляции Sigfox.

BitRate: см. секцию 8.5.1. Поддерживаются только скорости 100bps (RC1/RC3/RC5/RC6 и RC7) и 600bps (RC2 и RC4).

PulseShape: см. описание в секции 8.5.1. Поддерживается только BT 0.7 (0x16).

Команда SetPacketParams(...) конфигурирует параметры RF пакета для выбранного модема. Поскольку параметры зависят от модема, последующее описание применимо только для модуляции Sigfox.

PayloadLen: длина полезной нагрузки в байтах. Для конфигурирования контроллера пакета.

RampUpDelay: задержка в мкс, для точной настройки времени включения (ramp up time).

RampDownDelay: задержка в мкс, для точной настройки времени выключения (ramp down time).

BitNum: в битах. Используетяс для выключения (ramp down) PA перед окончанием длины полезной нагрузки в случае, когда реальная длина не делится нацело на 8.

LR1121 оборудован двумя буферами данных по 255 байт RAM, которые доступны во всех режимах, кроме sleep mode. Один буфер хранит принятые данные полезной нагрузки, в то время как другой содержит данные полезной нагрузки для передачи. LR1121 автоматически управляет указателями на данные, т. е. нет необходимости ручного управления базовыми адресами буфера со стороны пользователя.

Data Buffer в Receive Mode. Принятая полезная нагрузка сохраняется в RX buffer:

• Она может быть прочитана командой ReadBuffer8(...) (см. команду 3.7.5. ReadBuffer8).• GetRxbufferStatus(...) читает
указатель на первый байт последнего принятого пакета и его длину (см. команрду 7.2.11. GetRxBufferStatus).
• ClearRxBuffer(...) очистит все данные в LR1121 RX buffer (см. команду 3.7.6 ClearRxBuffer).

Data Buffer в Transmit Mode. Данные полезной нагрузки для передачи должны быть записаны в Tx Buffer с помощью команды WriteBuffer8(...) (см. описание 3.7.4. WriteBuffer8).

Информация RSSI LR1121 доступа либо в цепи радиотракта, либо после демодуляции на конце стадии приема. Суммарно информация RSSI и её общий смысл приведен в таблице 8-28:

Таблица 8-28. Происхождение информации уровня сигнала (RSSI Information Origin) и её смысл.

См. описание каждой команды для деталей реализации на различных полях RSSI.

Информация RSSI имеет время распространения в цифровых цепях приемника. Как показано ниже на рис. 8-7, самое большое время обычно необходимо для первого доступного значения RSSI (Twait), в отличие от последующих выборок RSSI (Trssi).

Для GFSK значения Twait и Trssi зависят от выбранной полосы частот, как показано в таблице 8-29:

Таблица 8-29. Значения Twait и Trssi для разных GFSK Bandwidth.

Для модуляции LoRa значения Twait и Rssi идентичны, и равны времени символа протокола (LoRa Symbol time).

В LR1121 встроено 2 усилителя мощности передатчика (power amplifiers, PA) для sub-GHz диапазона, и один для диапазона HF (2.4GHz):

• high power PA (HP PA), оптимизированный для работы +22dBm.
• low power PA (LP PA), оптимизированный для работы +14dBm, который может выдавать до +15dBm выходной мощности.
• high frequency PA (HF PA), оптимизированный для работы +13dBm в диапазоне частот 2.4GHz.

PA конфигурируются двумя командами: SetPaConfig(...) и SetTxParams(...).

• Выбора используемого PA (HP, LP или HF).
• Выбора питания PA (VBAT или VREG).
• Выбора скважности рабочего цикла любого PA.
• Выбора размера PA (применимо только к high power PA).

• Управления напряжением питания PA (VR_PA) и выходной мощностью.
• Выбора времени выхода на мощность (ramp time) при старте/остановке TX.

Пользователь должен сконфигурировать PA на нужную выходую мощность и потребление тока в соответствии с требованиями приложения. При выборе PA нет автоматического ограничения на частоту: выбор частоты должен производиться в соответствии с возможностями, предоставленными аппаратными цепями согласования на основе внешних компонентов, через которые подключается антенна.

Регулятор питания PA (Reg_PA) предоставляет ток для high power PA (HP PA), low power PA (LP PA) и high-frequency PA (HF PA) через вывод VR_PA pin. Оба усилителя, HP PA и the LP PA требуют high-Q choke индуктивностей, подключенных снаружи между соответствующими выходами и выводом VR_PA. Через эти индуктивности предоставляется питание PA и управление выходной мощностью. Для HF PA такая индуктивность не нужна. Лучшей практикой будет подключить резистор 200 Ом параллельно HP PA choke-индуктивности, как показано на рис. 9-2.

Регулятор PA внутренне подключен к выходу DC-DC/LDO для питания low power PA и high frequency PA, позволяя достичь выходной мощности +15dBm и +13dBm для обоих конфигураций - DCDC или LDO. Для high power PA это подключается к выводу VBAT_RF, т. е. к основному напряжению питания. Это означает, что максимальная генерируемая выходная мощность PA зависит от напряжения VBAT.

Основное питание TX может переключаться между батареей VBAT и внутренним регулятором VREG, в соответствии с вариантом использования PA. Когда происходит работа при напряжении VR_PA свыше 1.35V (например в случае высокой мощности, high power), должно быь выбрано питание от VBAT. Когда происходит работа при напряжении VR_PA ниже 1.35V (например в случае низкой мощности, low power PA), можно выбрать любой вариант питания. Однако лучше выбрать внутренний регулятор VREG каждый раз, когда требуется VR_PA 1.35V или ниже, чтобы получить преимущества эффективного использования питания на основе понижающего импульсного преобразователя DC-DC.

LR1121 включает в себя точный триммер рабочего цикла (precise duty cycle trimmer), совместно используемый между тремя усилителями мощности. Этот триммер может использоваться при согласовании выходной мощности, эффективности и гармонического излучения для удовлетворения различных требований региональных стандартов. Триммер рабочего цикла зависит от импеданса, представленного PA, и таким образом, может варьироваться для разных вариантов дизайна PCB.

Для максимальной эффективности low power PA должен работать с максимальным VR_PA, близким к 1.35V. Чтобы получить VR_PA = 1.35V, пользователь должен установить TxPower = 14. На этой настройке:

• PA может выдавать до 15dBm выходной мощности, постоянной для всего заданного диапазона напряжений батареи.
• Реальная выходная мощность может быть установлена в соответствии с настройкой цикла скважности (PaDutyCycle).
• Если необходимо, то выходная мощность может декрементироваться шагами 1dB от максимума, если использовать TxPower < 14.

Изменение VR_PA по запрограммированному значению TxPower для различных напряжений питания и циклов скважности PaDutyCycle показано на рис. 9-3 (при допустимых значениях источников питания VBAT и VREG, в обоих конфигурациях LDO или DCDC).

Рис. 9-3. Зависимость напряжения VR_PA для питания Low Power PA и настройки TxPower.

Для максимальной эффективности high power PA должен работать с максимальным напряжением VR_PA около 3.1V. Чтобы получить VR_PA = 3.1V, пользователь должен установить TxPower = 22. На этой настройке:

• PA может выдавать выходную мощность до 22dBm. Выходная мощность в этом случае меняется в зависимости от напряжения батареи, когда её заряд снижается до напряжения ниже 3.3V.
• Фактическая максимальная выходная мощность может быть установлена в соответствии с PaDutyCycle и PaHpSel.
• Если необходимо, то выходная мощность может декрементироваться шагами 1dB от максимума, если использовать TxPower < 22.

Изменение VR_PA по запрограммированному значению TxPower для различных напряжений питания и циклов скважности PaDutyCycle показано на рис. 9-4.

Рис. 9-4. Зависимость напряжения VR_PA для питания Low Power PA и настройки TxPower.

Как утверждалось выше, два параметра оказывают влияние на генерируемую выходную мощность передачи TX для каждого PA: программируемая мощность TxPower и цикл скважности PaDutyCycle. Третий параметр PaHPSel управляет размером high power PA, и поэтому оказывает непосредственное влияние на выходную мощность high power PA.

Чтобы достичь выходной мощности +22dBm, PaHPSel должен быть установлен в 7. PaHPSel не влияет ни на low power PA, ни на high frequency PA.

Рис. 9-5 показывает выходную мощность low power PA в зависимости от TxPower для различных настроек PaDutyCycle при всех напряжениях питания.

Напряжение питания не влияет на выходную мощность, поскольку low power PA имеет внутреннюю регулировку. На выходную мощность оказывает влияние только PaDutyCycle. Поэтому графики 1.8V, 3.3V и 3.7V накладываются друг на друга, так что виден только график для 3.7V.

Рис. 9-5. Зависимость выходной мощности Low Power PA от TxPower.

• TxPower = 14 и PaDutyCycle = 0 дает +10dBm при любом напряжении питания (1.8V, 3.3V и 3.7V).
• TxPower = 14 и PaDutyCycle = 4 дает +14dBm при любом напряжении питания (1.8V, 3.3V и 3.7V).
• TxPower = 14 и PaDutyCycle = 7 дает +15dBm при любом напряжении питания (1.8V, 3.3V и 3.7V).

На рис. 9-6 показана зависимость выходной мощности high power PA от настроек TxPower для различных установок PaDutyCycle по всем вариантам напряжений питания.

Для определенного PaDutyCycle выходная мощность high power PA поддерживается на определенном диапазоне уровней напряжений, и затем уменьшается при пониженном VBAT.

• Для настройки +22dBm выходной мощности, требуется VR_PA ~3.1V (см. рис. 9-4 выше). Таким образом при падении напряжения 200mV на регуляторе PA выходная мощность +22dBm может быть получена только для диапазона напряжений от 3.3V до 3.7V.
• Для +17dBm требуется VR_PA около 2V. Таким образом, выходная мощность LR1121 упадет до +17dBm для минимального напряжения питания 1.8V.

Поэтому графики 3.3V и 3.7V накладываются друг на друга при заданном PaDutyCycle, и виден только график для 3.7V.

Рис. 9-6. Зависимость выходной мощности HP PA от TxPower.

На рис. 9-7 показана зависимость выходной мощности High Frequency PA от TxPower при разных значениях напряжения питания.

Напряжение питания не влияет на выходную мощность, поскольку HF PA имеет внутреннюю регулировку. Поэтому графики для 1.8V, 3.3V и накладываются друг на друга, и виден только график 3.7V.

Рис. 9-7. Зависимость выходной мощности High Frequency PA от TxPower.

На рис. 9-8 показано влияние на ток потребления напряжения питания для трех вариантов настроек PaDutyCycle (0, 4 и 7) в конфигурации DC-DC.

На заданном напряжении питания большее значение настройки PaDutyCycle приводит к большему току потребления. На заданной настройке PaDutyCycle потребление тока оптимально для напряжения питания равного или больше 3.3V, поэтому графики для 3.3V и 3.7V накладываются друг на друга. Источник питания 1.8V на настолько эффективен, как источник напряжением 3.3V или больше, что приводит к повышенному потреблению тока от 1.8V.

• Для 3.7V настройка PaDutyCycle = 0 дает потребление тока приблизительно 28mA, для PaDutyCycle = 4 приблизительно 47mA, и для PaDutyCycle = 7 приблизительно 62mA.
• Для PaDutyCycle = 4 потребление тока приблизительно 47mA для 3.3V и 3.7V, и приблизительно 49mA для 1.8V.

Рис. 9-8. Зависимость IDDTX от TxPower, Low Power PA, конфигурация DC-DC.

На рис. 9-9 показано влияние напряжения питания на потребление тока для трех вариантов настройки PaDutyCycle (0, 4 и 7) в конфигурации LDO.

Рис. 9-9. Зависимость IDDTX от TxPower, Low Power PA, конфигурация LDO.

Подобно конфигурации DC-DC мы здесь видим, что для заданного напряжения питания повышенная настройка PaDutyCycle приводит к повышению потребления тока. Однако напряжение питания не влияет на потребление тока на заданной установке PaDutyCycle, в результате графики 1.8V, 3.3V и 3.7V накладываются друг на друга.

Рис. 9-8 и рис. 9-9 показывают, что эффективность по мощности low power PA максимальна, когда используется внутренний регулятор DC-DC на напряжении питания 3.3V или выше.

Рис. 9-10 и рис 9-11 показывают влияние напряжения питания на ток потребления для двух вариантов настройки PaDutyCycle (2 and 4) в обоих конфигурациях DC-DC и LDO.

Подобно low power PA, на определенном напряжении питания повышенное значение настройки PaDutyCycle повышает потребление тока устройством. Однако для заданной настройки PaDutyCycle потребление тока стабильно по отношению к напряжению питания при условии, что напряжение питания достаточно высокое, чтобы обеспечить генерацию напряжения VR_PA, требуемого для запрограммированного значения мощности TxPower.

• Для 3.3V ток потребления приблизительно 98mA для PaDutyCycle = 2, и приблизительно 118mA для PaDutyCycle = 4.
• Для 1.8V ток потребления приблизительно 69mA для PaDutyCycle = 2, и приблизительно 81mA для PaDutyCycle = 4. Это связано с тем, что при напряжении питания 1.8V максимальное значение напряжения VR_PA составляет 1.6V, поэтому максимальная выходная мощность +17dBm.

Во время работы high power PA, регулятор DC-DC питает аналоговое и цифровое ядра устройств, в то время как сам PA - как самый большой потребитель мощности - питается напрямую от VBAT. Таким образом, нет значительных различий в потреблении тока между режимами DC-DC или LDO при работе high power PA.

Рис. 9-10. Зависимость IDDTX от TxPower, High Power PA, конфигурация DC-DC.

Рис. 9-11. Зависимость IDDTX от TxPower, High Power PA, конфигурация LDO.

Рис. 9-12 показывает влияние настройки TxPower на ток потребления для трех напряжений питания в конфигурации DC-DC.

Потребление тока оптимально для напряжения питания 3.3V или выше, так что графики для 3.3V и 3.7V накладываются друг на друга. Напряжение питания 1.8V не настолько эффективно по энергопотреблению, как напряжение 3.3V или выше, что приводит к повышенному потреблению тока при питании от 1.8V.

Рис. 9-12. Зависимость IDDTX от TxPower, High Frequency PA, конфигурация DC-DC.

Рис. 9-13 показывает влияние настройки TxPower на ток потребления для трех напряжений питания в конфигурации LDO.

Напряжение питания не влияет на потребление тока, и так что графики для 1.8V, 3.3V и 3.7V накладываются друг на друга.

Рис. 9-13. Зависимость IDDTX от TxPower, High Frequency PA, конфигурация LDO.

Рис. 9-12 и рис. 9-13 показывают, что эффективность по мощности High Frequency PA максимальна, когда используется внутренний регулятор DC-DC при напряжении питания 3.3V или выше.

High power PA и low power PA работают на выходных выводах RFO_HP_LF и RFO_LP_LF соответственно. Они подключены к антенне через отдельные цепи согласования сопротивлений, целью которых является предоставление оптимизированной нагрузки на выходных контактах корпуса, когда на уровне антенны волновое сопротивление нагрузки 50 Ом.

High Frequency PA работает на выходной вывод RFIO-HF. Он внутренне согласован для 50 Ом, чем снижается необходимость во внешних компонентах при работе HF. Некоторые компоненты, присутствующие на выводе RFIO_HF в образцовом дизайне Semtech, предназначены для обеспечения фильтрации в соответствии с нормами регуляторов RF.

Можно реализовать многодиапазонную конфигурацию на одиночной цепи согласования, при этом доступно применение одинакового набора SMD компонентов для обеспечения нескольких sub-GHz ISM диапазонов. Таблицы ниже показывают оптимальные настройки для PA, когда используется цепь согласования эталонного дизайна Semtech. Пользователь может точно подстроить PaDutyCycle и PaHpSel в соответствии с его требованиями к цепи согласования, эффективности, выходной мощности и уровню излучения гармоник. Обратите внимание, что эффект влияния настроек PaDutyCycle и PaHpSel на эффективность, выходную мощность, излучение гармоник зависит от дизайна PCB, так что настройки PA, показанные в таблице 9-1 и таблице 9-2, должны быть оптимизированы на приложении пользователя.

Реализация цепи согласования антенны, предложенная Semtech, оптимизирована для +22dBm и +15dBm верхних диапазонов ISM, т. е. при работе на частотах 868-928MHz.

Таблица 9-1. Оптимизированные настройки для LP PA с одинаковой цепью согласования.

Таблица 9-2. Оптимизированные настройки для HP PA с одинаковой цепью согласования.

Таблица 9-3. Оптимизированные настройки для HF PA с одинаковой цепью согласования.

Примеры реализаций, показанные ниже, объединяют функционирование high power PA и high efficiency PA, при использовании 3-портового RF-ключа SP3T (одно направление три положения). Также возможна работа в одном диапазоне, тогда не используемый вывод PA остается неподключенным. В последнем случае понадобится 2-портовый RF-ключ SPDT (одно направление два положения).

Реализация RF switch оптимизирует импеданс, представленный для PA, и отдельно импеданс, представленный для LNA. Таким образом можно оптимизировать эффективность TX без влияния на чувствительность RX.

RF switch может управляться либо контроллером хоста, либо самим LR1121 (выводами DIO5, DIO6, DIO7, DIO8 and DIO10) с помощью команды SetDioAsRfSwitch(...).

Рис. 9-15. RF Switch, работа одного PA (пример High Power PA).

В случае недорогого приложения можно избавиться от RF-ключа, и применить так называемую реализацию прямого подключения (direct-tie).

В такой конфигурации PA и дифференциальные каскады RX соединены, как показано на рисунках ниже. Обратите внимание, что требуются последовательно подключенные конденсаторы между PA и каскадом RX, чтобы избежать повреждения LR1121 из-за протекания тока в каскаде RX.

Рис. 9-16. Реализация Single Tie: используется только один PA (пример High Power PA).

Рис. 9-17. Реализация Single Tie: используются оба PA (пример High Power PA).

Если сравнивать с реализацией на основе ключа, direct-tie это компромиссное решение между эффективностью TX и чувствительностью RX, т. е. ни то, ни другое не реализовано максимально эффективно. Это неизбежно, поскольку передатчик и приемник требуют разные оптимальные импедансы, достичь которые одновременно не представляется возможным. В случае direct-tie ожидается деградация 2 ~ 3dB для чувствительности RX.

Команда SetPaConfig(...) выберет, какой PA используется, и конфигурирует питание этого PA.

0x00: PA питается от внутреннего регулятора.
0x01: PA питается от VBAT. Пользователь должен использовать RegPaSupply = 0x01 всякий раз, когда TxPower > 14.

PaDutyCycle управляет циклом скважности каждого PA. Значение этого параметра по умолчанию 0x04.

Таблица 9-5. Допустимые диапазоны параметра PaDutyCycle.

Команда SetTxParams(...) установит Tx Power и Ramp Time выбранного PA. Команда SetPaConfig(...) должна быть отправлена перед этой командой.

TxPower определяет выходную мощность dBm в диапазоне:

• От -17dBm (0xEF) до +14dBm (0x0E) с шагом 1dB, если выбран low power PA.
• От -9dBm (0xF7) до +22dBm (0x16) с шагом 1dB, если выбран high power PA.
• От -18dBm (0xEE) до +13dBm (0x0F) с шагом 1dB, если выбран high frequency PA.
• Если TxPower > +14dBm, то пользователь должен выбрать источник питания VBAT для PA с помощью команды SetPaConfig.

RampTime определяет время нарастания выходной мощности (PA power ramping time), которое может быть от 16 до 304 мкс в соответствии со следующей таблицей:

RampTime 48 мкс дает лучший компромисс между быстрой установкой мощности RF и минимумом излучения побочных помех RF, удовлетворяя стандартам радио. 10 мкс ramp time не удовлетворяет регуляторным требованиям Австралии или Новой Зеландии.

Трансивер оборудован 256-байтным буфером данных RAM, который доступен во всех режимах, кроме sleep mode. Эта область RAM полностью настраивается пользователем и позволяет получить доступ либо данным для передачи, либо к данным последнего принятого пакета.

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

В режиме приема RxBaseAddr указывает смещение буфера в памяти, куда записываются данные полезной нагрузки принятого пакета. Смещение буфера последнего байта, записанного в режиме приема, затем сохраняется в RxDataPointer, который инициализируется значением RxBaseAddr в начале приема.

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

В одиночном режиме (single mode) указатель RxDataPointer автоматически инициализируется в RxBaseAddr каждый раз, когда трансивер входит в RX mode.

В непрерывном режиме (continuous mode) указатель RxDataPointer постоянно инкрементируется начиная от предыдущей позиции.

При каждом переходе в режим передачи TxDataPointer инициализируется в TxBaseAddr, и инкрементируется с каждым байтом, отправляемым по радио. Эта операция остановится, как только будет отправлено количество байт, равное параметру Payloadlength, определенному функцией SetPacketParams.

Оба базовых адреса RxBaseAddr и TxBaseAddr устанавливаются командой SetBufferBaseAddresses(...).

По умолчанию RxBaseAddr и TxBaseAddr инициализированы в адрес 0x00.

Из-за непрерывной природы буфера данных базовые адреса для TX и RX полностью конфигурируемы по всей области памяти 256 байт. Каждый указатель может быть независимо установлен в любое место буфера. Чтобы задействовать максимальный объем буфера данных в режиме передачи или приема, весь буфер целиком может использоваться в каждом режиме путем установки базовых адресов TxBaseAddr и RxBaseAddr в нижнюю границу памяти (адрес 0x00).

Буфер данных очищается, когда устройство переходит в Sleep mode (что подразумевает отсутствие доступа к буферу). Во всех других режимах работы содержимое буфера сохраняется.

К буферу данным доступ осуществляется командами WriteBuffer и ReadBuffer. В этих функциях параметр смещения offset определяет указатель адреса первых записываемых или считываемых данных. Offset 0 определяет первую позицию в буфере данных.

Следовательно перед любой операцией чтения или записи необходимо инициализировать это смещение в соответствующее начало буфера. При чтении или записи буфера данных указатель адреса инкрементируется автоматически.

Существует две возможности для получения значения смещения:

• Использовать значение RxBaseAddr, поскольку пользователь его определяет перед приемом полезной нагрузки.
• Инициализировать смещение значением RxStartBufferPointer, возвращенным командой GetRxbufferStatus.

Замечание: все принятые данные записываются в буфер данных даже если CRC неправильная, что позволяет для пользователя выполнить постобработку поврежденных данных. При приеме, если размер пакета превышает область буфера, выделенную для RX, то принятые данные перезапишут область буфера, выделенную для передачи.

Подсистема криптографии (Cryptographic Engine) предоставляет выделенный аппаратный акселератор для алгоритмов шифрования на основе AES-128, и выделенную память flash и RAM для обработки таких параметров устройства, как ключи шифрования, без возможности к ним доступа.

Cryptographic Engine повышает эффективность энергопотребления для криптографических операций и уменьшает размер кода программного стека. Проверка целостности данных, таких как полезная нагрузка downlink кадров важна для обеспечения защищенных коммуникаций. Проверка message integration check (MIC) использует алгоритм AES-CMAC для вычисления хэша. Реализация вычисления MIC программно поставит под угрозу конфиденциальность используемого ключа. Cryptographic Engine предоставляет аппаратную реализацию AES-CMAC, в которой внутри вычисляется и проверяется MIC.

Статус криптографических операций можно проверить либо опросом регистра статуса прерываний, либо используя подпрограмму обработки прерывания (interrupt service routine, ISR).

11.2. Определение ключей криптографии (Cryptographic Keys)

Ключи криптографии рассортированы в несколько групп, в соответствие с выполняемыми ими функциями, как показано в таблице 11-1. Эта таблица обобщает разрешенные использования ключей и некоторые ключи могут быть вычислены из других ключей.

Таблица 11-1. Использование и вычисление криптографических ключей.

Примечание (1): собрано в устройстве, вычислено по команде DeriveRootKeysAndGetPin().

Байт статуса подсистемы криптографии (Crypto Status) CEStatus показывает состояние Crypto Engine. Он возвращается после каждой команды, которая касается Crypto Engine.

0: CRYP_API_SUCCESS. Предыдущая команда была успешной.
1: CRYP_API_FAIL_CMAC. Сравнение MIC потерпело неудачу (первые 4 байта CMAC).
2: RFU.
3: CRYP_API_INV_KEY_ID. Ошибка ключа/параметра источника (Key/Param Source) или идентификатора назначения (Destination ID).
4: RFU.
5: CRYP_API_BUF_SIZE. Размер буфера данных недопустимый. Для CryptoAesEncrypt(...) размер буфера должен нацело делиться на порции по 16 байт.
6: CRYP_API_ERROR. Любая другая ошибка.

Команда CryptoSetKey(...) установит определенный ключ (Key), идентифицируемый по KeyID в Crypto Engine:

KeyID изменяется от 2 до 27, как определено в таблице 11-1. Другие значения RFU.

Key это массив байт, как определено в FIPS-197. С ключом K (2b7e1516 28aed2a6abf71588 09cf4f3c), предоставленным в тестовых векторах rfc4493, мы тогда имеем Key1 = 0x2b, Key2 = 0x7e, Key3 = 0x15, Key4 = 0x16, .. до Key16 = 0x3c.

Команда CryptoDeriveKey(...) вычисляет (шифрует) в указанный Key, идентифицируемый по DstKeyID, входное предоставленное значение (включая LoRaWAN DevNonce), используя ключ источника, идентифицируемый SrcKeyID.

DstKeyID и SrcKeyID для этой функции определены в таблице 11-1:

DstKeyID: Destination Key ID (идентификатор ключа назначения). Допустимы значения от 4 до 25.

SrcKeyID: Source Key ID (идентификатор ключа источника), для этой функции допустимы значения 2-3 и 6-11.

Input[1:16] массив байт. Пример этой конструкции приведен в секции 12.3 и секции 12.4.

Замечание: по окончанию процесса CryptoDeriveKey() сгенерированный ключ находится в выделенной области Crypto Engine RAM, и может быть сохранен в память flash командой CryptoStoreToFlash().

Команда CryptoProcessJoinAccept(...) расшифровывает сообщение join accept (с использованием шифрования AES-ECB согласно спецификации LoRaWAN) на Data и Header, и затем проверяет MIC расшифрованного сообщения. Затем предоставляются расшифрованные данные, если проверка MIC была успешной.

DecKeyID: ключ, используемый для расшифровки сообщения.

LoRaWANVer: определяет ожидаемый размер N для Header: 1 байт (v1.0) или 12 байт (v1.1)

LoRaWANVer = 0: LoRaWAN версия 1.0.x, только MHDR (1 байт)
LoRaWANVer = 1: LoRaWAN версия 1.1.x, SIntKey, JoinReqType | JoinEUI | DevNonce | MHDR

Data1 .. DataM: данные. Размер данных M либо 16, либо 32 бата. Данные должны включать зашифрованную MIC.

Команда CryptoComputeAesCmac(...) вычисляет AES CMAC предоставленных данных, используя указанный Key и возвратит MIC.

KeyID: указанный идентификатор ключа, как определено в таблице 11-1. Поддерживаются 2, 5, 12-17.

Data1, Data2, ..., DataN: предоставленные данные, рассматриваемые как байты буфера.

Например, когда используются тест-векторы RFC4493 example 2, у нас получится:

Таблица 11-11. Ответ на пример команды CryptoComputeAesCmac.

Команда CryptoVerifyAesCmac(...) вычислит AES CMAC от предоставленных данных, используя указанный Key, и сравнит предоставленный MIC с реальным вычисленным MIC (первые 4 байта CMAC).

KeyID: указанный Key ID, как определено в таблице 11-1. Возможны идентификаторы 2, 5, 12-25.

ExpectedMIC: предоставленный MIC (первые 4 байта CMAC).

Data1, Data2, .. DataN: предоставленные данные, рассматриваются как байты буфера.

Если два MIC-а одинаковые, команда возвратит CRYP_API_SUCCESS, иначе CRYP_API_FAIL_CMAC.

Команда CryptoAesEncrypt01(...) шифрует предоставленные данные с использованием указанного Key и возвратит зашифрованные данные. Она не может использоваться на ключах с индексами 2-11, чтобы предотвратить повторное вычисление ключей сессии.

KeyID: указанный Key ID, как определено в таблице 11-1. Допустимы значения от 12 до 25.

Data1, Data2, .. DataN: предоставленные данные, рассматриваемые как байты буфера.

EncryptedData1, EncryptedData2,... , EncryptedDataN: зашифрованные данные, рассматриваемые как байты буфера.

Команда CryptoAesEncrypt(...) шифрует предоставленные данные указанным ключом Key и возвратит их. Это предназначено для использования в обычных non-LoRaWAN криптографических операциях, где Crypto Engine используется как аппаратный ускоритель, только на ключах с индексами 26 и 27 (General Purpose keys, ключи общего назначения).

KeyID: указанный Key ID, как определено в таблице 11-1. Допустимы значения от 26 до 27.

Data1, Data2, .. DataN: предоставленные данные, рассматриваемые как байты буфера.

EncryptedData1, EncryptedData2, ..., EncryptedDataN: зашифрованные данные, рассматриваемые как байты буфера.

Команда CryptoAesDecrypt(...) расшифровывает предоставленные данные и возвращает их, используя указанный Key, и можно использовать только ключи с индексами 26-27, когда Crypto Engine используется как отдельный аппаратный ускоритель для задач безопасности, не относящихся к LoRaWAN.

KeyID: указанный Key ID, как опрелено в таблице Table 11-1. Допустимы значения от 0 до 27.

Data1, Data2 to DataN: предоставленные данные, рассматриваемые как данные буфера.

DecryptedData1, DecryptedData2, ..., DecryptedDataN: расшифрованные данные, рассматриваемые как байты буфера.

Команда CryptoStoreToFlash(...) выполняет сохранение данных Crypto Engine (ключи и параметры) из RAM в память flash.

Команда CryptoRestoreFromFlash(...) выполняет восстановление данных Crypto Engine (ключей и параметров) из памяти flash в RAM.

Команда CryptoSetParam() установит определенный параметр Parameter в Crypto Engine RAM.

ParamID: идентификатор параметра Parameter ID, от 0 до 119.

Команда CryptoGetParam() извлекает определенный параметр из Crypto Engine RAM.

ParamID: идентификатор параметра Parameter ID, от 0 до 119.

Команда CryptoCheckEncryptedFirmwareImage() добавит кусок зашифрованного образа FW для проверки. Она должна быть вызвана несколько раз, пока весь образ не будет передан в чип:

• Он занимает всего 64 куска 32-битных данных (всего 256 байт + команда и код операции) за один раз, за исключением последнего сегмента, который может быть короче.
• Первое смещение offset равно 0.
• Ножка BUSY показывает отсутствие занятости, когда LR1121 готов принять другой кусок данных.

Как только весь образ firmware был передан в чип, вы можете вызвать команду CryptoCheckFirmwareImageResult() чтобы проверить результат передачи. Эти команды полезны для проверки достоверности firmware перед его прошивкой.

Offset: должно нацело делиться на 4 (смещение в байтах)

Data: длина данных должна нацело делиться на 4. Максимальная длина = 256 байт.

Замечание: N = 64 для всех кусочков данных, кроме последнего, который может быть короче.

Команда CryptoCheckEncryptedFirmwareImageResult() извлекает результат проверки переданного образа FW.

Таблица 11-30. Ответ на команду CryptoCheckEncryptedFirmwareImageResult.

1: успешная провека firmware.
0: ошибка верификации firmware.

Во время производственного тестирования Semtech LR1121 предварительно предоставляется с двумя идентификаторами, которые можно использовать для идентификации устройств на сети LoRaWAN®. Для получения дополнительной информации обратитесь к веб-сайту LoRa Alliance®.

• Номер ChipEui глобально уникальный и идентифицирует конкретное устройство.
• SemtechJoinEui повторно используется на устройствах Semtech.
• Также предварительно предоставляется уникальный Device Key (DKEY).
• С этими номерами вычисляется Device PIN при выполнении команды DeriveRootKeysAndGetPin(...). Этот PIN необходим для получения сервисов LoRa Cloud™ JoinServer. Для дополнительной информации обратитесь на официальный сайт LoRa Cloud.

Все эти уникальные идентификаторы сохранены в постоянной памяти устройства. Они предварительно конфигурируются компанией Semtech для упрощения реализации LoRaWAN и доступа к службам LoRa Cloud Join Server, но они также могут игнорироваться пользователем.

Команда GetChipEui(...) считывает предварительно предоставленный LR1121 ChipEui. Это глобально уникальное число, назначенное компанией Semtech при производстве, с использованием одного из назначенных EUI для Semtech (организацией IEEE). В стандартном случае использования ChipEui используется для вычисления двух корневых LoRaWAN ключей (root keys AppKey, NwkKey), и должен также использоваться как DevEui (в определении LoRaWAN) для генерации Join Request (который сам передает DevEui).

ChipEui кодируется 8 байтами, в формате big endian [5].

Команда GetSemtechJoinEui(...) читает предварительно запрограммированный LR1121 JoinEui, установленный при производстве компанией Semtech.

Два LoRaWAN root-ключа (AppKey, NwkKey) в устройстве вычисляются из этого JoinEui, среди других номеров.

На верхнем уровне, в стандартном случае использования, пользователь должен применять SemtechJoinEui как LoRaWAN-поле JoinEui для построения кадра Join Request (который сам передает JoinEui).

SemtechJoinEui кодируется 8 байтами, в формате big endian [5].

Команда DeriveRootKeysAndGetPin(...) вычисляет root-ключи AppKey и NwkKey, и вычисляет соответствующий PIN, необходимый для предоставления устройством на Semtech Join Server. Это очень универсальная функция со стандартным использованием и более расширенным использованием, как описано в следующих разделах:

• Standard: используется предварительно предоставленные ChipEui, DevEui, и используется Semtech Join Server.
• Advanced: DevEui и/или JoinEui могут быть персонализированными, при этом все еще используя Join Server.
• Alternate: AppKey и NwkKey принудительно выполняются пользователем, и не могут использоваться Join Server.

Таблица 12-6. Ответ на команду DeriveRootKeysAndGetPin (Standard).

В стандартном использовании ChipEui применяется как LoRaWAN DevEui, SemtechJoinEui как LoRaWAN JoinEui, и поэтому никакие специальные действия не производятся. Хост должен:

1. Вызвать команду DeriveRootKeysAndGetPin() без аргумента.
2. Прочитать SemtechJoinEui (командой GetSemtechJoinEui()) на назначить его переменной JoinEui.
3. Прочитать ChipEui (командой GetChipEui()) и назначить его переменной DevEui.
4. Выполнить процедуру Join, используя только что прочитанные элементы.
5. На приеме корректного Join Answer все lifetime и session ключи могут быть вычислены в соответствии требуемому стандарту LoRaWAN.

Устройство также должно быть заявлено на Semtech Join Server, чтобы запрос Join Request на присоединение был принят.

LR1121 поддерживает определенный пользователем DevEui и/или выделенный JoinEui, оба отличающиеся от LR1121-встроенных ChipEui и SemtechJoinEui. Если повторно используется схема вычисления, определенная службой Semtech Join Server, то вызов функции DeriveRootKeysAndGetPin() должен быть выполнен следующим образом.

Таблица 12-8. Ответ на команду DeriveRootKeysAndGetPin (Advanced).

В advanced случае использования могут применяться специфические для пользователя DevEui и/или JoinEui. Хост должен:

1. Вызвать DeriveRootKeysAndGetPin() со своими собственными DevEui и/или JoinEui, получить в ответ PIN.
2. Выполнить процедуру Join, использующую DevEui и JoinEui (т. е. не ChipEui и SemtechJoinEui).
3. На приеме корректного Join Answer все lifetime и session ключи могут быть вычислены в соответствии требуемому стандарту LoRaWAN.

Устройство также должно быть заявлено на Semtech Join Server, чтобы запрос Join Request на присоединение был принят.

LR1121 может использоваться вне службы Join Server и его встроенных схем получения корневого ключа (built-in root key derivation schemes). В этом сценарии концепция PIN становится неуместной, и пользователь может предоставить свои собственные NwkKey и AppKey, но все же использовать Crypto Engine для любой из задач аутентификации, подписи и шифрования для повышения безопасности. Обратите внимание на то, что в этом сценарии команда DeriveRootKeysAndGetPin(...) НЕ ДОЛЖНА использоваться, так как это перезаписало бы корневые ключи, персонализированные в устройстве пользователем с помощью команды CryptoSetKey (...). Хост должен:

1. Использовать CryptoSetKey(...) для персонализации NwkKey и AppKey (в соответствии с интересующей версией LoRaWAN).
2. Выполнить процедуру Join, используя DevEui и JoinEui, выбранные пользователем (ChipEui и SemtechJoinEui могут быть повторно использованы в этом отношении).
3. Получить DevAddr и вычислить ключи сессии с принятием ответа Join Response.

Схема вычисления ключей (key derivation scheme) доступная из спецификации LoRaWAN:

Все ключи, необходимые для подписания, аутентификации или шифрования трафика Join, а также ключи сеанса могут быть получены из предоставленных корневых ключей (AppKey, NwkKey) в соответствии со схемой получения, описанной на рис. 12-1. Аргументы функции CryptoDeriveKey (...) должны быть вычислены хост-контроллером и переданы функции в качестве аргумента Input [1:16] с соответствующими заполняющими байтами, когда это применимо. Например, при вычислении FNwkSIntKey команду следует использовать следующим образом:

FNwkSIntKey = CryptoDeriveKey(NwkKey, 0x01 | JoinNonce | NetID | DevNonce | pad16)

Здесь pad16 это требуемое количество байт дополнения 0x00 для расширения в 16-байтное число.

Схема вычисления ключей (key derivation scheme) доступная из спецификации LoRaWAN:

Хотя crypto engine LR1121 следует соглашению именования стандарта LoRaWAN 1.1.x, она может использоваться для LoRaWAN 1.0.x по следующей таблице:

Таблица 12-9. Соответствие LoRaWAN 1.0.x и 1.1.x Security Correspondence.

Примечание (1): GenAppKey может использоваться как материнский ключ (mother key) для вычисления специфического для множественного вещания ключа (multicast-specific key material) в LoRaWAN 1.0.x, в то время как AppKey используется в LoRaWAN 1.1.x.

Несколько тестовых команд LR1121 позволяют упростить конфигурацию устройства для соответствия регулирующим требованиям ETSI или FCC.

В этой секции описаны только RF-режимы, необходимые в регуляторном тестировании для ETSI и FCC. Обратитесь к документам ETSI и FCC для подробного описания теста и для индикации ограничений теста.

Стандарты EN 300 220 описывают 4 тестовых сигнала, которые EUT (Equipment Under Test) должно быть в состоянии передать для сертификации CE. Эти тестовые сигналы перечислены в таблице ниже, с соответствующими рабочими режимами для LR1121.

Пользователь должен быть способен изменить параметры рабочей частоты, выходной мощности и модуляции для проведения тестов ETSI. Пользователь также должен быть способен принять приходящие RF пакеты для любой конфигурации (частота, параметры модуляции), и определить индикацию PER (Packet Error Rate) качества приема.

Все это может быть реализовано обычными командами LR1121 radio.

FCC part 15.247 применяется к системам, использующим скачки по перестройке частоты (frequency hopping) и цифровую модуляцию. Для этих тестов требуется только немодулированная несущая (TX CW) и обычная передача пакета.

Пользователь должен быть способен изменить параметры рабочей частоты, выходной мощности и модуляции для проведения тестов FCC. Это может быть реализовано обычными командами LR1121 radio.

Команда SetTxCw (...) установит устройство в режим передачи непрерывной несущей (TX continuous wave, немодулированная несущая).

Эта команда немедленно переведет устройство в режим TX CW. Таким образом, команды рабочей частоты и конфигурации PA (включая выходную мощность RF) должны быть вызваны перед этой командой.

Команда SetTxInfinitePreamble(...) передает бесконечную последовательность преамбулы.

Эта команда немедленно запустит передачу бесконечной последовательности преамбулы. Таким образом, команды рабочей частоты и конфигурации PA (включая выходную мощность RF) должны быть вызваны перед этой командой.

Для общего описания команд чтения и записи SPI см. секции "3.2. Команды чтения" и "3.1. Команды записи".

14.2. Операции конфигурации системы и получения информации её состояния

14.3. Операции конфигурирования радиотракта и получения информации его состояния

Примечание (1): параметры зависят от модема/пакета.

14.4. Операции конфигурации подсистемы шифрования и получения её состояния

Примечание (1): для использования см. апноут AN1200.57 LR1110 Program Memory Update.