Урок 5. Приёмник — INAV … ↩

Цели урока и модель сигнала

После урока вы сможете без GUI:

• различать три уровня: тип приёмника, назначение последовательного порта и provider протокола;
• считать конфигурацию командами serial, get, map, rxrange и status;
• подготовить безопасные CLI-команды для Serial RX, channel map и RSSI, не копируя синтаксис Betaflight;
• отличить проверку связи/состояния от визуальной проверки каждого канала.

Путь управления для Serial RX: передатчик → радиоприёмник → сигнальный провод и общий GND → физический UART → функция RX_SERIAL на записи порта → receiver_type = SERIAL → serialrx_provider → внутренние каналы и их карта. Ошибка на любом слое может выглядеть как «приёмник не работает».

В INAV также есть MSP receiver: команды управления приходят в FC по MSP. Это отдельный тип входа, не обычный UART Serial RX. PPM в документации INAV 9.1.0 указан как поддерживаемый только до INAV 3.x; для 9.1.0 не планируйте новую конфигурацию на PPM.

Вход в CLI и исходная диагностика

Если Configurator недоступен, подключите терминал к CLI serial port: обычно это тот же порт, что MSP; скорость берётся из msp_baudrate (по умолчанию 115200). В терминале отправьте символ #, чтобы войти в CLI. Сначала выполните только чтение:

version
status
serial
get receiver_type
get serialrx_provider
map
rxrange
get rssi_source
get rssi_channel
diff all

get печатает текущее значение и допустимые варианты/диапазон. Сохраните вывод serial, map, rxrange, status и diff all во внешний файл. Команда save сохраняет изменения и перезагружает FC; выход из CLI через exit без save не сохраняет изменения.

Если связь с CLI идёт по тому же FC, не удаляйте функцию MSP с используемого порта. ID порта в serial — это CLI identifier, а не гарантированная надпись UART на плате; сопоставьте его с target и схемой платы по уроку 3.

Выбрать тип приёмника: SERIAL, MSP или SIM

Переменная receiver_type задаёт путь входных команд. В INAV 9.1.0 допустимы NONE, SERIAL, MSP и SIM (для SITL).

get receiver_type

Для обычного цифрового приёмника, подключённого UART-сигналом, используют receiver_type = SERIAL [Receiver > Receiver Type]. Для приёмника, передающего RC-команды по MSP, выбирают MSP; источник MSP должен обновлять MSP_SET_RAW_RC не реже 5 Hz. SIM предназначен для SITL. Не задавайте serialrx_provider как замену выбора типа: это отдельная переменная, применимая к типу SERIAL.

Перед настройкой определите по фактической схеме, какой путь используется. Разъём, USB-кабель или марка приёмника сами по себе не говорят прошивке, какой тип выбрать.

Serial RX: функция порта и provider

Для последовательного приёмника сначала назначают RX_SERIAL конкретной записи аппаратного UART; в INAV serial receiver не следует подключать к SoftSerial. Затем выставляют receiver_type и протокол serialrx_provider. Это отдельные настройки, а не одна команда.

Важное отличие от Betaflight: команда feature RX_SERIAL из BF-урока не является способом настройки RX_SERIAL в INAV. В INAV это serial-функция, задаваемая командой serial; тип входа задаётся переменной receiver_type. Не вводите Betaflight-команду как будто это INAV-команда.

Сокращённая команда serial PORT_ID +6 использует Bit Identifier 6, а не числовую маску 64. Не пишите +64. Перед применением прочитайте serial и подтвердите точный PORT_ID по схеме платы. Не используйте готовую строку с номером порта из другого target. Полный формат serial заменяет всю function mask и все поля скорости; в этом уроке для добавления RX используется короткая форма, чтобы не перезаписать чужие назначения.

В INAV 9.1.0 используйте только значения из списка настроек прошивки; в актуальном metadata enum присутствует также SBUS2 (в кратком тексте docs/Rx.md он пропущен). Команда get serialrx_provider на вашем target — окончательная проверка допустимых вариантов. Список включает:

Читать текущий выбор и допустимые имена можно командой get serialrx_provider. Таблица из справочника не доказывает, что любой приёмник/target поддерживает любой provider. Например, CRSF и ExpressLRS часто используют CRSF, но прошивка RX и подключение должны реально выдавать этот протокол.

Два частых отказа: назначили provider, но забыли receiver_type = SERIAL; либо задали SERIAL/provider, но на UART отсутствует функция RX_SERIAL/не тот сигнальный провод.

Инверсия и half-duplex: только по протоколу

До любых изменений прочитайте оба параметра:

get serialrx_inverted
get serialrx_halfduplex

serialrx_inverted меняет инверсию serial RX; значение OFF оставляет протокольное поведение по умолчанию (например, SBUS использует инвертированный сигнал). serialrx_halfduplex разрешает работу serial RX на UART TX pin; default INAV 9.1.0 — AUTO.

Для F.Port официальная документация сообщает: начиная с INAV 2.6 настройки по умолчанию должны работать; если конфигурация мигрировала со старой версии, могут понадобиться set serialrx_inverted = OFF и set serialrx_halfduplex = AUTO. Значения для INAV до 2.6 были иными. Не переносите из старого Betaflight или старого INAV команды ON вслепую. Для SBUS инверсия зависит также от инвертора на приёмнике/плате и конкретной разводки.

Channel map и диапазоны rxrange

Команда map без аргументов читает карту. В INAV CLI карта содержит четыре буквы для основных каналов: A (aileron/roll), E (elevator/pitch), R (rudder/yaw), T (throttle). Строка должна содержать каждую букву ровно один раз. Дополнительные AUX-каналы этой командой не переставляются.

map
map CHANNEL_ORDER

CHANNEL_ORDER — заполнитель для четырёхбуквенной последовательности, которую реально передаёт радио. Например, вводить map AETR можно только если измерено/подтверждено, что входные каналы идут Aileron, Elevator, Throttle, Rudder. Это не универсальная карта. Команда map TAER1234 из Betaflight для INAV неверна: INAV CLI ожидает только четыре символа.

Отдельная команда rxrange показывает и задаёт входные границы каналов. Без аргументов она показывает текущие диапазоны. Каналы в команде нумеруются с нуля: 0 — первый основной канал, 1 — второй и т.д. По документации менять диапазон стоит только если после настройки endpoints на передатчике/приёмнике сигнал действительно не укладывается в ожидаемый диапазон.

rxrange
rxrange CHANNEL_INDEX MIN_US MAX_US

Все три поля во второй строке — заполнители: CHANNEL_INDEX обычно 0–3, а MIN/MAX берутся из фактически измеренного импульсного диапазона; допустимый CLI диапазон проверит сам контроллер. Например, документация приводит rxrange 0 1070 1930 только для случая, когда первый канал действительно измерен как 1070–1930 μs. Не переносите эти числа на свой приёмник.

rxrange reset сбрасывает все пользовательские диапазоны. Это не диагностическая команда чтения; сначала сохраните исходные значения rxrange, затем используйте reset только как осознанное восстановление. После любой правки проверяйте вывод rxrange, а не только факт отсутствия ошибки.

Поля Receiver и их параметры CLI

Ниже — точные соответствия полей, видимых на добавленном Receiver-скриншоте, настройкам INAV 9.1.0. Квадратные скобки указывают путь в Configurator только как справочную карту; все чтение и настройка в таблице выполнимы через CLI. Значения в последнем столбце — лишь то, что отображено на снимке, а не рекомендуемый профиль.

Для чтения всего набора без GUI используйте отдельные запросы get и map. Не применяйте все значения из правого столбца как пакет: настройте только те параметры, необходимость которых подтверждена протоколом, реальным поведением каналов и документацией оборудования. На скриншоте канальные индикаторы стоят около 1500, но поскольку он сделан в SITL, это нельзя выдавать за измерения с реального приёмника.

RSSI, потеря сигнала и failsafe

RSSI — источник/оценка качества связи; канал RSSI, если он применяется, не следует путать с четырьмя основными каналами управления. Текущие параметры читаются так:

get rssi_source
get rssi_channel
feature

Если используется analog RSSI, проверьте физический ADC input, активное состояние функции RSSI_ADC и источник rssi_source. При подтверждённой аппаратуре соответствуют команды feature RSSI_ADC и set rssi_source = ADC [Receiver > RSSI Source]. При источнике CHANNEL прочитайте rssi_channel и сверяйте его с тем, какой AUX-канал реально передаёт RSSI. При PROTOCOL выбирайте этот источник только если provider сообщает RSSI/LQ и это подтверждено документацией RX. Не включайте сразу несколько несовместимых источников на пробу.

Потеря входного сигнала обнаруживается INAV автоматически. Значения rx_min_usec и rx_max_usec задают границы валидного импульса (в документации 9.1.0 значения по умолчанию 885 и 2115 μs); это пороги обнаружения некорректного/потерянного сигнала, не настройка endpoint по центру 1000–2000. Читайте их через get rx_min_usec и get rx_max_usec; менять можно только по расчёту и документации failsafe.

Изменение, проверка и сохранение

Для Serial RX порядок настройки в CLI следующий:

1. По схеме конкретной платы найдите физический UART, к которому подключён сигнал RX; проверьте питание, общий GND и направление сигнала.
2. По выводу serial и target документации подтвердите его PORT_ID и убедитесь, что не теряете MSP/CLI доступ.
3. Добавьте функцию RX_SERIAL командой serial PORT_ID +6 [Ports > Serial RX]. Здесь PORT_ID заменить реальным ID, а +6 — битовой идентификацией RX_SERIAL.
4. Выберите receiver_type = SERIAL и точный serialrx_provider, подтверждённый для прошивки приёмника.
5. Проверьте map. Меняйте его только при доказанном несовпадении порядка каналов.
6. Перечитайте serial, get receiver_type, get serialrx_provider, map, rxrange, status и diff all.
7. Если конфигурация верна и канал/сигнал проверен безопасным способом, выполните save [Save and Reboot]. После перезагрузки снова проверьте состояние.

Пример только для подтверждённого тестового стенда: если документированно выбран порт ID 3, приёмник действительно выдаёт CRSF, а входной порядок каналов измерен как A-E-T-R, последовательность изменений будет:

serial 3 +6
set receiver_type = SERIAL
set serialrx_provider = CRSF
map AETR

Не копируйте этот блок целиком на неизвестную плату. ID 3, протокол CRSF и карта AETR здесь лишь конкретный условный пример. Если хотя бы одно условие не подтверждено, сначала оставьте конфигурацию только в режиме чтения.

После любой ошибки до save верните сохранённое исходное значение соответствующей настройки и перечитайте его. Если изменения уже сохранены, восстановление выполняйте по своей резервной копии именно для того же target и версии; не используйте чужой dump.

Практическая работа без GUI

1. Подключитесь к CLI через терминал, войдите символом # и снимите исходный вывод: version, status, serial, get receiver_type, get serialrx_provider, map, rxrange, get rssi_source, get rssi_channel, get serialrx_inverted, get serialrx_halfduplex, get rc_filter_smoothing_factor, get thr_mid, get thr_expo, get deadband, get yaw_deadband, diff all.
2. По target docs сопоставьте сигнал приёмника с аппаратным UART и CLI PORT_ID. Не используйте SoftSerial для Serial RX.
3. Заполните план команд с собственными, проверенными значениями: serial PORT_ID +6, set receiver_type = SERIAL, set serialrx_provider = PROVIDER, map CHANNEL_ORDER. До ввода в FC преподаватель/документация должны подтвердить все заполнители.
4. После пробного применения на стенде перечитайте настройки и status. Подтвердите отдельным MSP-инструментом или внешним средством, что первые четыре канала двигаются в правильную сторону и диапазон соответствует командам передатчика.
5. Только после подтверждения сигнала, канальной карты и failsafe сохраните изменения через save. Перезапуск и повторная проверка обязательны.

Чек-лист и контрольные вопросы

• Сохранены version, исходные serial/map/rxrange и diff.
• Для Serial RX выбран аппаратный UART и корректный target-specific PORT_ID.
• Не использована команда Betaflight feature RX_SERIAL; в INAV заданы serial function, receiver_type и provider отдельно.
• map содержит только четыре основных канала и соответствует реальному порядку; AUX каналы не добавлены в карту.
• rxrange не менялся без измеренных фактических границ.
• Проверка канальных движений и failsafe выполнена без тяги и не подменена одним выводом status.
• save введён только после проверки; после reboot выполнено повторное чтение.

1. Чем отличаются receiver_type, RX_SERIAL и serialrx_provider?
2. Почему в INAV для добавления RX_SERIAL используется serial PORT_ID +6, а не serial PORT_ID +64?
3. Почему команда map TAER1234 из BF не является корректным примером для INAV?
4. Что меняет rxrange и почему его не нужно использовать для исправления ошибочного channel map?
5. Какие данные CLI может подтвердить, а для чего потребуется MSP-клиент или измерительный прибор?

Источники и следующий урок

1. INAV 9.1.0 Rx: Serial RX, MSP RX, provider, channel map, rxrange
2. INAV 9.1.0 Serial: ports, constraints, function masks
3. INAV 9.1.0 CLI reference
4. INAV 9.1.0 Settings reference
5. INAV 9.1.0 settings metadata (включая provider enum и параметры RC)
6. Controls and arming checks

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