KIWI Flight Systems Manual

Welcome to the official documentation for KIWI Flight Systems. Engineered with precision. Inspired by a bird that never gave up.

Inside, you’ll find hardware specifications, pinouts, setup procedures, firmware integration guides, and system-level configuration references.

Whether you’re building from scratch, integrating custom sensors, or tuning for flight performance, this documentation is designed to support your development process from start to finish.

For feedback, corrections, or suggestions, please contact us at support@kaponga.nz

Welcome

• Introduction

UAV Electronics

• Ground Station - KIWI GCS Kit
• Antenna Tracker - KIWI AT
• DroboDrone
• SmartESAD System
  • smartESAD v1.2 Protocol Specification
  • Picatinny CLIK v3.0 Payload Protocol

Sensors

• Kiwi-RM3100 CAN Compass
• PyroMiner

Flight Controllers

• Flight Controller - KIWI F405 12S
• Flight Controller - KIWI H743 12S
• Flight Controller - KIWI H743-Wing

Flight Controllers (Obsolete)

• Flight Controller - KIWI F405 6S
• Flight Controller - KIWI F722 6S

Reference

• ICM-42688P (HXY) Datasheet
• MIL-STD-1472H UI/UX Guidelines

Kiwi Ground Station Kit

Firmware

Previous versions

No previous versions archived yet.

Призначення

Комплект наземної станції керування FPV дроном призначений для забезпечення безпеки операторів дронів.

Комплект є основою для побудови інфраструктури наземної станції.

Склад

Комплект складається з двох основних плат:

• Ground Board (плата оператора) — 1 шт
• Antenna Board (плата щогли) — 1 шт
• JR Board (адаптер для підключення до пульта RC)
• Технічна документація — 1 шт
• Кабель Cat5e або Cat6 не входить до комплекту

Плата оператора розміщується у бліндажі або в пункті керування дронами.
Плата щогли встановлюється поблизу антени.
З’єднання між ними здійснюється екранованим кабелем “вита пара” довжиною до 300 м.

Функції

• Перетворення керуючого сигналу S.Port → UART і назад.
• Передача аналогового відео CVBS з VRX до бліндажу.
• Підсилення відеосигналу та його перетворення в цифровий потік.
• Живлення передавального модуля та VRX до 26В.

Переваги Kiwi Ground Station Kit

• Надійна передача до 600 м без ретрансляторів.
• Один кабель передає живлення, відео, та керування.
• Можливість живлення щогли локально або по кабелю.
• Вбудовані DC-DC стабілізатори 5V, 9V, 12V на щоглі.
• 4 відеовиходи без затримки.
• Підтримка UART / CRSF.
• Мінімальна кількість з’єднань.
• Робота в діапазоні температур -20°C до +60°C.

Поширені сценарії використання

• Мобільні наземні станції для FPV-дронів
• Розвідувальні комплекси з щоглою до 10 м
• Модернізація старих систем зв’язку
• Системи спостереження у складних умовах

Технічні характеристики

Схема підключення

Ground Board:

• Video1 → FPV окуляри
• Video2 → Монітор
• Video3 → DVR
• Video4 → USB відео стрім (запис/трансляція)
• UART → Пульт або ПК

Antenna Board:

• TX (наприклад, ELRS TX)
• VRX (аналоговий приймач)

Зʼєднання:
Ground Board ↔ Antenna Board через екранований кабель Cat5e/Cat6 до 300 м

Живлення та втрати напруги

Стабілізація на щоглі

На платі Antenna Board встановлені DC-DC перетворювачі:

• 5V — для VRX
• 9V — для спеціальних пристроїв
• 12V — для передавача

Втрати на довгих кабелях (1А навантаження)

Інструкція з експлуатації

1. Підключіть окуляри, монітор, DVR та USB відео стрім до Ground Board.
2. Підключіть пульт або ПК через UART.
3. Підключіть живлення 6S або 12S.
4. З’єднайте Ground ↔ Antenna через кабель.
5. Підключіть VRX та TX до Antenna Board.
6. Увімкніть систему.

Рекомендації щодо прокладання і маскування кабелю

• Прокладати вздовж укриттів (дерева, рельєф, стіни).
• Уникати відкритих ділянок.
• Маскувати або фарбувати кабель.
• Фіксувати до землі або прокладати у кожусі.
• Біля щогли залишати запас.
• Перевіряти видимість з дронів.

KIWI Antenna Tracker

Antenna tracking module for the KIWI Ground Station Kit. Receives MAVLink telemetry from the UAV and automatically points the antenna toward the aircraft. Based on the KiwiF405-12S flight controller running ArduPilot AntennaTracker firmware.

Features

• Automatic antenna tracking — receives GPS coordinates from the UAV via MAVLink and drives a yaw servo to keep the antenna pointed
• Precision encoder — high-resolution heading sensor for accurate yaw position feedback
• GPS — onboard GPS for tracker’s own position reference
• TBS Fusion VRX control — built-in serial integration for remote frequency control, RSSI monitoring, and band scanning
• Single-servo yaw — continuous rotation servo on output 1
• Plug-and-play — pre-configured defaults, connects directly to the Ground Station Kit

Connections

Modes

Default startup mode is MANUAL.

Video Receiver Control

The tracker supports remote control of 5.8 GHz video receivers over SERIAL4. Two receivers are currently supported:

TBS Fusion VRX Integration

The tracker has built-in support for controlling a TBS Fusion 5.8 GHz video receiver over a single-wire UART connection (SERIAL4). No CAN bus or additional boards required.

Wiring

One wire from TBS Fusion UART TX/RX to the tracker’s SERIAL4 pad. Half-duplex is pre-configured (SERIAL4_OPTIONS=4). Power the Fusion separately — only the data wire is needed.

Features

Real-time RSSI monitoring — dual-receiver signal strength (Receiver A and B) and current frequency are polled at 2 Hz and streamed to GCS as MAVLink NAMED_VALUE_FLOAT messages:

Remote frequency control — change the VRX operating frequency from GCS by setting the VRX_FREQ parameter (in MHz, e.g. 5800). The tracker confirms the change and reports back via GCS status message.

Frequency range scan — trigger a full-band scan from GCS to find active video transmitters. Scan results (RSSI per frequency) are delivered as a binary MAVLink TUNNEL message (payload_type 60100) for GCS-side visualization.

VRX Parameters

Scan Parameters

Scan Results Format

Scan results arrive as a TUNNEL message with payload_type 60100. Binary payload:

SteadyView X VRX Integration

Remote frequency control for the ImmersionRC SteadyView X receiver over SERIAL4. Set VRX_ENABLE=3.

Wiring

Same as TBS Fusion — single wire from SteadyView X UART to SERIAL4 pad, half-duplex.

Features

Remote frequency control — change the VRX channel from GCS by setting the VRX_FREQ parameter (in MHz). RSSI monitoring and band scanning are not available on this receiver.

Parameters

Firmware

ArduPilot AntennaTracker firmware for KiwiF405-12S-Tracker. Flash via Mission Planner or apj upload over USB.

Drobodrone: Плата для керування піротехнічними системами

Buy Online Buy Online

Опис

Drobodrone — це універсальна та безпечна плата для керування піротехнічними навантаженнями (парашути, феєрверки, маркери тощо), призначена для інтеграції у складі FPV, UAV та інших безпілотних систем. Підтримує до 4 незалежних каналів підриву з високим рівнем безпеки.

Плата підтримує багаторазове використання і може бути повністю перепрограмована для кастомних сценаріїв.

Основні функції

• 4 незалежні канали підриву
  Призначені для запуску різних піротехнічних систем. Кожен канал має апаратний ключ для запобігання хибному спрацюванню.

• Інтерфейси керування:

  • PWM IN x2:
    • ARM: активує систему (захист знято)
    • FIRE: активує підрив (при активному ARM)
    • PWM активується при ширині імпульсу 1800–2000us
  • UART (SmartESAD):
    • Для передачі телеметрії, контролю статусу та розширеного керування

• Аудіо сигналізація:
  Вбудований динамік інформує про поточний статус (наприклад: озброєно, відмова, успішне спрацювання).

• Світлова сигналізація:
  Три яскраві LED інформують про стан системи: Ready / Armed / Fired / Error

• Механічна чека (запобіжник):
  Фізичне роз’єднання для запобігання спрацювання під час транспортування чи підготовки.

• Інтерфейс живлення:

  • Живлення від 5V
  • Спрацювання елементів від 20V
  • Захист від перенапруги, короткого замикання

Безпекові елементи

Система побудована за принципом багаторівневого захисту:

1. Механічний вимикач-запобіжник — фізично розриває ланцюг.
2. PWM-сигнал типу ARM — не дозволяє спрацювання без команди.
3. Таймер самозахисту — автоматичне вимкнення при відсутності FIRE протягом заданого часу.
4. Апаратні ключі — унеможливлюють коротке замикання або хибне спрацювання.
5. Світлова та звукова індикація — для візуального та звукового контролю статусу.

Сумісність з автопілотами

Плата легко інтегрується з будь-яким автопілотом, який має PWM-виходи або UART-порти:

PWM-сигнал може бути поданий з пульта, автопілота або окремого модуля запуску.

Роз’єми та підключення

• Pyro Out x4: спеціальні піротехнічні конектори
• PWM IN x2: пади для пайки
• UART: пади для пайки
• 5V In: пади для живлення
• GND, Status LED, Speaker: окремі виходи

Плати мають великі, зручні контактні майданчики, які легко інтегрувати навіть у щільну проводку.

Кастомізація

Плата підтримує:

• Перепрошивку MCU через стандартний bootloader
• Зміну логіки ARM/FIRE
• Зміну таймерів, режимів індикації
• Підтримку альтернативних протоколів (за потреби)

Інтеграція: Швидкий старт

1. Підключіть 5V живлення та землю
2. Підключіть PWM ARM та PWM FIRE від автопілота
3. Підключіть піротехнічні канали
4. Встановіть механічну чеку
5. На землі подайте ARM > FIRE у потрібний момент
6. Перевірте LED та аудіо сигналізацію
7. Опціонально підключіть UART до Companion Computer або логера

Примітка

Перед польотом завжди перевіряйте стан чека, сигналів, підключення піроканалів та акумулятора. Не залишайте плату в режимі ARM без нагляду.

Індикатори станів. Керування

Комбінація помаранчевого 🟠 та зеленого діодів 🟢 – індикатор поточного стану плати.
Червоний діод 🔴 сигналізує про помилку, яку має усунути оператор.
Помилки можливі в будʼякому зі станів плати. Щоб плата могла перейти в наступний стан, спершу треба усунути всі помилки.

• 🔴🔴🔴🔴🔴🔴 (постійно світиться) – плата не отримує валідний PWM ARM чи PWM ARM сигнал, можливо проблема пайки зʼєднання з польотним контроллером.
• 🔴🔴⚪️⚪️🔴🔴 (повільно блимає, 1 раз на секунду, 1гц) – треба відтиснути PWM ARM.
• 🔴⚪️🔴⚪️🔴⚪️ (швидко блимає, 3 рази на секунду, 3гц) – треба відтиснути PWM FIRE.

PWM: 0 ≤ invalid < 900 ≤ valid=0 ≤ 1800 < valid=1 < 2000 ≤ invalid

Для початку роботи:

• плата має “бачити пульт”: отримувати валідні PWM ARM та PWM FIRE (900 < pwm ширина < 2000)
• PWM ARM має бути у положені disarm (0, false, low, відтиснуте, вимкнене, ненатиснуте)
• PWM FIRE має бути у положені nofire (0, false, low, відтиснуте, вимкнене, ненатиснуте)
• вставити запобіжник (чеку)

Стани:

(1) Безпечно. Вітання 🔔:
🔴🔴🔴🔴🔴🔴
🟠🟠🟠🟠🟠🟠
🟢🟢🟢🟢🟢🟢
Триває секунду після подачі живлення, далі автоматично переходить в (2) Очікую Запобіжник

(2) Безпечно. Очікую запобіжник:
⚪️⚪️⚪️⚪️⚪️⚪️
🟢⚪️🟢⚪️🟢⚪️
Чекає поки оператор вставить чеку, далі переходить в (3) Запобіжник

(3) Безпечно. Запобіжник:
⚪️⚪️⚪️⚪️⚪️⚪️
🟢🟢🟢🟢🟢🟢
Чекає поки оператор усуне чеку, далі переходить в (4) Таймер

(4) Безпечно. Таймер:
⚪️⚪️⚪️⚪️⚪️⚪️
🟢🟢⚪️⚪️🟢🟢
Можливо вставити чеку щоб повернутись в (3) Запобіжник
Триває 60 секунд. Дає час відійти після усунення чеки. Далі переходить в (5) Очікую Заряд

(5) Уважно. Очікую Заряд:
🟠🟠⚪️⚪️🟠🟠
Можливо вставити чеку щоб повернутись в (3) Запобіжник
Чекає на PWM ARM від оператора, далі ~секунду заряджає 🔔 і переходить в (6) Заряджено

(6) Небезпечно. Заряджено 🔔:
🟠⚪️🟠⚪️🟠⚪️
Можливо вставити чеку щоб повернутись в (3) Запобіжник
Відтисни PWM ARM щоб розрядити і повернутись в (5) Очікую Заряд
Натисни PWM FIRE щоб зробити (7) Постріл.

(7) Небезпечно. Постріл:
🔴🔴🔴🔴🔴🔴
🟠🟠🟠🟠🟠🟠
🟢🟢🟢🟢🟢🟢
Постріл триває 100ms і автоматично переходить в (5) Очікую Заряд, який одразу переходить в (6) Заряджено якщо не відтискати PWM ARM.
Задля безпеки, для наступного пострілу треба відтиснути PWM FIRE, про що нагадає помилка 🔴⚪️🔴⚪️🔴⚪️.
4 незалежні канали підриву 1234 поділені на 2 групи по 2 канали в кожній 12 34. Постріл підриває поточну активну группу (2 канали одночасно), і готує наступну групу для наступного пострілу. I так по-колу. Тобто постріли 1 2 3 4 5 6 здетонують канали 12 34 12 34 12 34.

Тобто послідовність роботи така:
підготовка: power arm=0 fire=0 вставили_чеку вийняли_чеку 60сек
робота: arm=1 fire=1 fire=0 fire=1
додому: fire=0 arm=0

SmartESAD

Overview

SmartESAD (Electronic Safe-Arm Device protocol) — двосторонній послідовний протокол між польотним контролером і піротехнічним пристроєм, який замінює класичну пару PWM-сигналів ARM/FIRE. Замість двох односпрямованих ліній SmartESAD дає польотному контролеру повний контроль над послідовністю безпеки, а у відповідь отримує стан пристрою, залишок таймерів і телеметрію.

SmartESAD is a bidirectional serial protocol between the flight controller and pyrotechnic device, replacing the classic PWM ARM/FIRE signal pair. Instead of two one-way lines, SmartESAD gives the FC full control of the safety sequence and returns the device’s live state, remaining timer counts, and telemetry.

Ця сторінка описує протокол smartESAD v1.1 (іменування станів Cold/Timer/Safe) та прошивку KIWI Betaflight гілки 2025.12. This page covers smartESAD v1.1 and the KIWI Betaflight 2025.12 firmware line.

Переваги над PWM / Advantages over PWM

Архітектура безпеки / Safety architecture

SmartESAD реалізує модель з кількома незалежними рівнями захисту. Щоб підривник отримав напругу, усі перелічені умови мають бути виконані одночасно. Бажано прочитати MIL-STD-1316F для розуміння принципів.

SmartESAD implements a defence-in-depth model. All the conditions below must hold simultaneously for the initiator to receive energy.

Протокол додатково передбачає GPIO co-sign (IN_ARM, IN_BLAST) — окрему фізичну лінію підтвердження. На платах KIWI підключення суто послідовне (без GPIO), тому цей гейт опційний і залежить від конкретного виробу.

Стани системи / System States

SmartESAD керує пристроєм через послідовність станів безпеки. Перехід між основними станами — лише вперед:

The FC drives SmartESAD through this safety state progression. Forward transitions only:

START ──Version──▶ DEACTIVATED ──Activate──▶ COLD ──Timer──▶ TIMER
                        ▲                     ▲                │ (auto, after
                        │                     │                │  countdown)
                   Deactivate            Cold cmd*             ▼
                 (з будь-якого       (*таймер продовжує      SAFE ──Arm──▶ [CHARGE_UP] ──▶ ARMED ──Fire──▶ FIRED
                  стану крім Fired)    цокати, правило R1)         (лише плати з                (термінальний
                                                                    конденсатором)               стан)

Захисні таймери / Safety timers

SmartESAD веде два незалежні таймери:

Обидва налаштовуються через CLI (kiwi_esad set timer / kiwi_esad set destruct_delay), зберігаються у флеш пристрою командою kiwi_esad save і переживають перезавантаження.

Налаштування пристрою / Device persistent settings

Зберігаються у флеші пристрою (не польотного контролера) у двосторінковому буфері з CRC-32. При пошкодженні — fallback на заводські значення, ніколи на Armed. Змінюються через kiwi_esad set <name> <N> + kiwi_esad save (див. довідник команд).

Stored in the device’s flash (not the FC). On corruption the device falls back to compiled defaults — never to Armed.

Опційний імпакт-постріл працює завжди, коли пристрій у стані Armed: акселерометр виявляє удар понад поріг і пристрій переходить Armed → Fired без жодної команди з UART.

Швидке налаштування / Quick setup

1. Підключення / Wiring

Один UART (TX, RX, GND) від польотного контролера до ESAD:

• FC TX → ESAD RX
• FC RX → ESAD TX
• спільний GND

Швидкість фіксована: 57600 8N1, без апаратного керування потоком.

2. CLI у Betaflight

# Призначити UART для SmartESAD (приклад: UART1 = serial 0)
serial 0 1048576 57600 57600 0 57600

# Налаштування пристрою (зберігаються у флеші ESAD)
kiwi_esad deactivate
kiwi_esad set timer 420
kiwi_esad set destruct_delay 7200
kiwi_esad set impact_threshold 120
kiwi_esad set takeoff_required 0
kiwi_esad set safe_on_lostconnection 0
kiwi_esad save
kiwi_esad activate

# Налаштування польотного контролера
set kiwi_esad_poll_interval_ms = 100
set kiwi_esad_fault_threshold = 3
set kiwi_esad_activate_on_boot = 0
set kiwi_esad_activation_delay_s = 0

# Позиція OSD елементів
set kiwi_osd_esad_status_pos = 2242
set kiwi_osd_esad_debug_pos  = 2498   # 2498 = bottom-left; 341 = hidden

# Перемикачі RC
aux 1 57 2 1725 2100 0 0     # ATAK on AUX3 — momentary, OR logic, no link
aux 2 58 3 1725 2100 0 0     # FIRE on AUX4 — momentary, OR logic, no link

save

Формула позиції OSD: pos = x + (y * 32) + 2048 (2048 = видимий у профілі 1). Значення 341 ховає елемент.

Примітка про маску serial: у прошивках гілки 2025.12 FUNCTION_KIWI_ESAD = 1048576 (біт 20). У збірках на базі 2026.6+ маска змінена на 2097152 (біт 21), а permanentId боксів зсунуто 56/57/58/62 → 57/58/59/63.

3. Betaflight Configurator

1. Ports → оберіть UART і увімкніть KIWI ESAD.
2. Modes → призначте KIWI ESAD ACTIVE / ATAK / FIRE на перемикачі пульта.
3. OSD → розмістіть елемент ESAD Status на екрані.

Перемикачі RC / RC mode boxes

Бокси спрацьовують по фронту (edge-triggered): на кожному rising/falling фронті прошивка один раз відправляє відповідну команду. Між подіями FC опитує стан пристрою кожні kiwi_esad_poll_interval_ms.

Boxes are edge-triggered: each rising/falling edge emits the command once; between events the FC polls device state.

Приклад прив’язки (FC ARM на AUX1, ESAD на AUX2/3/4, CFG на AUX5):

aux 0  0 0 1300 2100 0 0     # FC ARM           on AUX1
aux 1 56 1 1725 2100 0 0     # KIWI ESAD ACTIVE on AUX2
aux 2 57 2 1725 2100 0 0     # KIWI ESAD ATAK   on AUX3
aux 3 58 3 1725 2100 0 0     # KIWI ESAD FIRE   on AUX4
aux 4 62 4 1725 2100 0 0     # KIWI ESAD CFG    on AUX5 (ON=DACT, OFF=ACTV)
save

Формат: aux <slot> <permanentId> <auxChannel_0based> <startUs> <endUs> <modeLogic> <linkedTo>. Поріг 1725 мкс дає мертву зону вище середини стіка.

Двоключовий інтерлок / two-key interlock: прив’яжіть FIRE так, щоб він працював лише коли ATAK теж активний — останнє поле 57 у рядку FIRE:

aux 3 58 3 1725 2100 0 57    # FIRE діє лише поки ATAK (57) теж HIGH

Рекомендовано для бойового спорядження. Recommended for live ordnance.

CFG-бокс (maintenance): поки утримується HIGH, FC призупиняє автоактиваційні цикли, щоб оператор міг заливати налаштування (kiwi_esad set …, kiwi_esad save) навіть при kiwi_esad_activate_on_boot = 1. Автоцикли поновлюються після disarm польотного контролера.

Налаштування польотного контролера / FC-side settings

Звичайні змінні Betaflight CLI (set <name> = <value>, потім save):

Таблиця автоактивації / Auto-activation matrix

Довідник CLI команд / CLI command reference

Прошивка KIWI має вбудовану CLI команду kiwi_esad для керування та діагностики пристрою прямо з CLI Betaflight (Configurator → CLI, або термінал на USB-порту, 115200, символ # вмикає CLI).

The KIWI firmware ships a kiwi_esad CLI command for driving and debugging the device straight from the Betaflight CLI.

Команди стану / Status commands

Приклад виводу kiwi_esad status:

# kiwi_esad status
state: COLD
remaining_secs: 420
status_byte: 0x01
det_check_ok: yes
pin_present: no
vcap_mv: 0
vbat_mv: 12600
peak_metric: 64
link_alive: yes
misses: 0
last_fault: code=0x00 subcode=0x00
firmware_version: 0x01010000
reset_cause: 0x00
auto_phase: IDLE
countdown_remaining_ms: 0
boot_phase: DISABLED
cfg_mode: off

Поля / Fields:

Команди керування / Action commands

Кожна команда чекає відповідь пристрою до 500 мс і друкує результат:

-> OK  state: TIMER  fault: 0x00/0x00

Команди налаштувань / Settings commands

set пише значення у RAM пристрою; зберігає лише kiwi_esad save. Пристрій приймає set/save у станах Cold або Deactivated (save — Safe або Deactivated).

set writes device RAM; only kiwi_esad save persists. Accepted in Cold / Deactivated.

Якщо set/save відхилено з fault: 0x06/0x01 (WrongState), CLI підкаже правильний шлях:

tip: Set/Save accept state in {Safe, Deactivated}. Use
`kiwi_esad deactivate` to enter CFG, push, then `kiwi_esad activate`.

Приклад повної сесії / Full bench session

# kiwi_esad status
state: COLD  remaining_secs: 7
link_alive: yes  misses: 0
...

# kiwi_esad timer
-> OK  state: TIMER  fault: 0x00/0x00

# kiwi_esad status
state: SAFE  remaining_secs: 7189

# kiwi_esad arm
-> OK  state: ARMED  fault: 0x00/0x00

# kiwi_esad fire
-> OK  state: FIRED  fault: 0x00/0x00

Довідник кодів відмов / Fault code reference

last_fault: code=0xCC subcode=0xSS у виводі kiwi_esad status та fault: 0xCC/0xSS після команд. Код не скидається автоматично — тримає останню причину відмови, а не поточний стан.

Top-level codes:

Subcodes для PreconditionFailed (0x06):

OSD-індикація / OSD display

Основний елемент (kiwi_osd_esad_status_pos), 9 символів:

Діагностичний рядок (kiwi_osd_esad_debug_pos, за замовчуванням схований) показує телеметрію: ED+ V24.1 B12.4 P- M64 — det-check, напруга конденсатора, напруга батареї, шунт-пін, peak-metric акселерометра. Для стендів і демонстрацій; у польових збірках ховайте (341).

Поведінка при втраті зв’язку / Failsafe & link-loss

• Disarm польотника повертає пристрій у безпечний стан (якщо boot-latch не активний). Запущені countdown при цьому не скасовуються — правило R1.
• FC-side watchdog: misses ≥ kiwi_esad_fault_threshold → OSD ESAD LOST, стан UNKNOWN. Опитування продовжується; перша успішна відповідь відновлює все.
• Device-side safe_on_lostconnection: коли увімкнено, пристрій сам переводить Timer/Safe/Armed → Cold після ~1 с тиші від FC.
• Відкат стану (пристрій перезавантажився, стан опустився нижче попереднього): FC скидає фіксатори автоактивації — оператор мусить явно повторити послідовність озброєння.
• FC ніколи не стріляє сам. Прошивка лише передає намір оператора; фінальний гейт пострілу — власна логіка пристрою.

Діагностика / Troubleshooting

Усе через CLI Betaflight (Configurator → CLI). Перший крок завжди — kiwi_esad status.

Прослуховування шини / Sniffing the wire

Для глибокої діагностики можна дивитися сирі кадри:

1. Зовнішній USB-TTL адаптер паралельно на лінію TX або RX (спільний GND) — FC продовжує працювати з ESAD, ви бачите трафік.

2. serialpassthrough: звільніть порт і прокиньте його на USB:

   serial 0 0 57600 57600 0 57600     # зняти FUNCTION_KIWI_ESAD з UART1
   save
   # після перезавантаження:
   serialpassthrough usart1 57600
   

   Зверніть увагу: serialpassthrough приймає ім’я порту (usart1, usart2…), а не числовий індекс. Поверніть функцію назад (serial 0 1048576 … + save) після діагностики.

Протокол / Protocol summary

Нижче — стислий підсумок. Повна специфікація інтерфейсу: smartESAD v1.2 Protocol Specification. Full interface specification linked above.

Сумісні плати / Compatible boards

SmartESAD вбудовано у прошивку KIWI Betaflight для всіх плат KIWI:

• KIWI F405 6S
• KIWI F405 12S
• KIWI F722
• KIWI H743

Стандарти / Standards

SmartESAD спроектовано на принципах:

• MIL-STD-1316F — Fuze Design Safety Criteria (DoD)
• STANAG 4560 ed 3 — EED Assessment & Test Methods (NATO)
• NAWCWD TP 8504 — Design Methodology for Safe and Arm Devices (US Navy)
• AOP-4187 Ed A v1 — Fuzing System Safety Design (NATO)

Це не сертифікація; зазначені стандарти — джерело правил дизайну. Цільовий ризик передчасного озброєння — менше 1 на 1 000 000 пристроїв (MIL-STD-1316F §4.3).

smartESAD v1.2 — Serial Control Protocol

Description of the smartESAD serial control interface between a flight controller / host integrator and a smartESAD-compatible Electronic Safe-Arm Device (ESAD) for one-way-attack UAV payloads. It covers the electrical interface, frame format, message set, safety state model, timing, telemetry, and status indication.

This document revision is v1.2; it describes wire protocol version 1 (frame byte 2 Ver = 0x01). “v1.2” is the interface-control revision, not the on-wire version field — an FC still sends and expects Ver = 0x01.

Values a device vendor assigns per program build are marked [vendor]; behaviour the base interface leaves to the integration profile is marked [profile] and summarised in §13. Nothing here identifies a specific manufacturer, board, or part number.

1. Overview

The ESAD is a command server: it transmits only in response to a received command frame and, with a single documented exception (§4.2), it never sends unsolicited traffic. A host reads the device’s status and identity, brings it through a mandatory arming-delay countdown, and drives it through a safety state machine gated by serial commands.

                          UART serial (smartESAD v1)
  Flight Controller ─────────────────────►  smartESAD ── FIRE1 / FIRE2 ──►  initiator
  / Host Integrator                         Device     ── LED(s) / buzzer ──►  operator
  DC Power ──────────── V+ / Return ─────►

The device is the last line of defence between an operator mistake or wiring fault and a premature detonation. Two independent safety features gate the terminal action: the ordered command sequence and a mandatory non-cancellable arming-delay countdown. A forged or corrupted serial command alone cannot fire the warhead.

2. Physical & electrical interface

2.1 Serial link

Signal names are from the device’s perspective: Rx is driven by the host, Tx is driven by the device.

3. Frame format

Every message (command and response) uses one frame. All multi-byte fields are big-endian.

byte:  0     1     2     3     4     5     6 ........ L-3   L-2  L-1
      +-----+-----+-----+-----+-----+-----+----- ... -----+-----+-----+
      | AA  | 55  | Ver | Cmd | Seq | Len |     Data      | CRC | CRC |
      +-----+-----+-----+-----+-----+-----+----- ... -----+-----+-----+
                                                            MSB   LSB

• Total frame size is 8 + N bytes (minimum 8, maximum 263).
• CRC-16/CCITT-FALSE: polynomial 0x1021, init 0xFFFF, no reflection, no final XOR. Check value for ASCII "123456789" is 0x29B1.

3.1 Sequence nonce

The host chooses any 8-bit value per request; the device reply carries (Seq + 1) mod 256. The host verifies the reply nonce equals its request nonce plus one — proving the reply is fresh and matches the request (not a verbatim echo).

3.2 Framing & error handling

• A frame that fails CRC is reported back as a Fault (BadCrc, §4.4) rather than silently dropped — this aids host-side diagnostics. Whether a device silently drops malformed frames instead is a profile choice. [profile]
• Bad-frame conditions never change device state (§8, R6).

4. Message set

4.1 Host → device commands (Cmd 0x00–0x7F)

Read-only / housekeeping:

Safety state-machine commands — each carries a distinct 4-byte guard payload [vendor] in Data; a wrong or missing guard → BadMagic (§4.4). The guard is an integrity/anti-corruption token (false-positive resistance ≈ 2⁻³² against bit-flip noise), not a secret — the safety case rests on the arming-delay gate, not guard secrecy.

Configuration commands — accepted only in Cold or Deactivated; they update RAM and reply with the current state card. Values persist across reboot only after a SaveSettings commit (§3.4).

A device may omit configuration and safety features it does not physically support; unsupported commands reply UnknownCommand. Which features a given unit implements is a capability profile (§12). [profile]

4.2 Boot handshake

The device is a strict server and does not announce its own boot (a one-shot boot frame would be lost while the host’s serial port is not yet open — the device boots in milliseconds, a host OS in seconds). Instead:

1. Device powers up into state Start and silently opens its Rx.
2. Host polls Version (0x01) at its cadence from its own boot.
3. The first Version the device receives returns a StateStart (0x80) card (firmware version + reset cause), immediately followed by one unsolicited Settings (0x87) frame carrying the persisted configuration. This is the only unsolicited frame, emitted exactly once per boot.
4. The device transitions Start → Deactivated. To enable the arming chain the host must then send Activate (0x17) → Cold.

Routing boot through Deactivated is deliberate: an outdated or misbehaving host that only polls Version but never sends Activate can never accidentally arm.

4.3 Optional periodic broadcast

Opt-in (SetBroadcast(0) = default, off). Useful for passive monitors / flight recorders. Broadcast frames coexist with normal request/reply traffic and are identified by their 0x89 Cmd.

5. Command payloads

5.1 Guard-word safety commands

Each safety command (0x10–0x17, and 0x25) carries a fixed 4-byte guard payload [vendor] that must match exactly. Wrong length → BadLength; correct length with a mismatched guard → BadMagic. Guards are per-command distinct so a corrupted Cmd byte cannot alias one safety action onto another.

6. Device → host state replies (Cmd 0x80–0xFF)

A device reply Cmd reflects the device’s current state, not an ack of the received command. Sending Arm while the arm-delay is still running therefore returns a StateTimer card with the remaining seconds, not an error about Arm.

6.1 Trailing telemetry tail

Every state card except StateFault (0x86) and Settings (0x87) carries a fixed 7-byte telemetry tail after its body, so the host renders a uniform view across device variants:

[ peak_metric: u16 BE ][ status_byte: u8 ][ vcap_mv: u16 BE ][ vbat_mv: u16 BE ]

• peak_metric — running-max acceleration metric observed since the most recent Arm (reset to 0 on Arm and at boot). Units follow the impact detector; saturation dominates on a hard impact, so it is informative mainly in the marginal band. 0 = no data / no accelerometer. On StateFired it doubles as the trigger-time acceleration.
• status_byte — boolean health flags. Readers must mask to known bits; reserved bits are not guaranteed 0 in future revisions.

• vcap_mv — firing-capacitor voltage, mV. 0 on devices with no firing capacitor.
• vbat_mv — battery-rail voltage, mV. 0 on devices without battery sense.

Which fields are live vs zero depends on the device capability profile (§12); the tail is always emitted at full size, so a host parser stays device-agnostic.

7. (reserved)

8. Safety state model

[Start] --Version handshake--> [Deactivated] --Activate--> [Cold]
[Cold]  --Timer-------------> [Timer]     starts arm-delay countdown
[Timer] --auto @ countdown=0-> [Safe]      starts self-destruct countdown
[Safe]  --Arm---------------> [Armed]      (via [ChargeUp] on capacitor devices)
[Armed] --Fire--------------> [Fired]      FIRE1/FIRE2 latched ON

Transition rules (non-negotiable; MIL-STD-1316F §4.2)

• R1 — arm-delay is non-cancellable. Once started, a Cold command masks the state back to Cold but does not stop or reset the countdown; re-entry to Timer cannot extend it. Same for self-destruct. Prevents an operator mistake or RF glitch from endlessly resetting the arming timer.
• R2 — Arm/Fire require the ordered sequence. Arm outside Safe, or Fire outside Armed → PreconditionFailed. An optional launch-detect gate (SetTakeoffRequired) can additionally require a detected launch signature before Arm.
• R3 — handshake routes Start → Deactivated; Activate required to arm. A Version from Start replies StateStart and transitions to Deactivated. The host must then Activate to reach Cold. A Version in any other non-terminal state resets the countdowns to configured values and returns to Deactivated (FC-reboot recovery).
• R5 — Fire is one-way. Once Fired, the device stays Fired; fire pins are latched. Only a reboot resets it.
• R7 — impact auto-fire (Armed only). An accelerometer impact ≥ the configured threshold while Armed latches the fire path independent of link state (the terminal-impact case routinely severs the host link). Impact in non-Armed states is recorded but does not transition. [profile]
• R8 — settings changes require Cold and survive only via Save. Set* commands update RAM and are lost on reboot unless committed by SaveSettings (§3.4).
• R9 — opt-in link-loss demote (safe_on_lost_link). When the operator has persisted this flag, a silent link for ≥ 1 s demotes {Timer, Safe, Armed} → Cold and cancels both countdowns. Default off: link-loss handling is otherwise host-driven. Note this is deliberately opt-in — the one-way-attack mission profile normally requires the device to remain committed through link loss to impact. [profile]
• R10 — ChargeUp transit (capacitor devices). On devices with a firing capacitor, Arm routes Safe → ChargeUp; the device reaches Armed only after the capacitor holds fire voltage for a settle window, and reverts to Safe on a charge timeout. Self-destruct expiry on such devices also routes through ChargeUp (best-effort fire on timeout). Devices without a capacitor go Safe → Armed and (on SD) → Fired directly. [profile]
• R11 — SafetyPin (shunt-sense devices). A hardware shunt pin that shorts the initiator leads may drive a dedicated safed state (or, on some devices, act purely as a fire inhibit). All state-advancing commands are rejected while safed. [profile]
• R6 — bad frames don’t transition. Any CRC / version / command / guard / length / precondition error replies StateFault (§4.4) with no state change.

Countdowns

Two independent countdowns (MIL-STD-1316F §4.2.5 independence):

• Arm-delay — default 420 s [vendor]. Starts on the first Timer from Cold; decrements in real time regardless of state; auto-advances Timer → Safe at 0. Reset only by Version or reboot.
• Self-destruct — default 7200 s [vendor]. Starts when the arm-delay expires; decrements only while committed to arm (Armed / Fired, and ChargeUp on capacitor devices) and pauses otherwise, preserving remaining seconds across de-arm. On expiry the device fires automatically (the failure-mode-of-last-resort so a crossed-over UAV is not recoverable in enemy territory). Reset only by Version or reboot.

Fire-pin gate (independent of the state variable)

assert_fire = (state == Fired) AND fire_command_latched AND (link_alive OR sd_expired)
FIRE1 = FIRE2 = assert_fire

FIRE1 and FIRE2 drive two independent initiator channels asserted together; a single stuck/failed driver still leaves the surviving channel functional (MIL-STD-1316F §4.2.1 two independent safety features / §4.2.5 non-subvertibility). The fire pins are driven LOW in hardware as the first action after power-on, before any code that could panic.

9. Timing

3.4 Persistent settings & commit sequence

A small set of operator-tunable parameters (arm-delay, self-destruct delay, impact threshold, launch-required, safe-on-lost-link, accelerometer rate) is held in RAM and updated by the Set* commands. They persist across reboot only after a SaveSettings (0x25) commit, which is Cold-only and re-validates bounds:

1. Device ACKs with the StateCold card.
2. Device writes flash (host Rx may be masked briefly during the erase).
3. Device soft-resets.
4. After boot the device is back in Start; the host’s next Version handshake returns StateStart and the unsolicited Settings frame with the freshly loaded values — the end-to-end confirmation that the commit succeeded.

Host-visible silence between the ACK and the post-reboot reply is ~40–60 ms; the host must tolerate this only on SaveSettings. Every other command replies within 10 ms.

4.4 Fault codes (in Data[0] of StateFault 0x86)

When 0x06, Data[1] sub-codes the failed precondition: 0x01 wrong state, 0x02/0x03 reserved, 0x04 arm-delay still running, 0x05 self-destruct still running, 0x06 value out of bounds, 0x07 launch not yet detected.

4.5 Settings payload (Cmd = 0x87)

10 bytes, fixed layout (same struct on the wire and in flash):

Emitted as the reply to GetSettings (0x23) (any state) and once per boot piggybacked on the first handshake (§4.2).

10. Status indication

Devices carry one or more indicators — commonly a two-LED panel (green + red) and optionally a buzzer. A power-on lamp-test lights all indicators solid for ~1 s to prove them before the per-state pattern shows. LED patterns derive from a single 8 Hz tick base.

Buzzer-equipped devices [profile] add: a boot chime (ready), a distinct impact alert, a pitch-tracking tone that rises with firing-capacitor voltage during ChargeUp, and a soft periodic “capacitor-hot” reminder while the cap holds energy. Exact tones are vendor detail [vendor]; the semantic mapping (ready / impact / charging / cap-hot) is the interface-relevant part.

11. Integration sequence

1. Apply power. From your own boot, poll Version (0x01) at ~50 Hz until a StateStart reply arrives (covers the boot race). Capture the firmware version and the one unsolicited Settings frame.
2. Verify. Check the Ver byte and firmware version; Identifier (0x02) for identity; GetSettings (0x23) if you did not capture the boot Settings frame.
3. Activate. Send Activate (0x17) → Cold. (Without this, the arming chain stays locked out — by design.)
4. Configure (optional). In Cold, Set* the arm-delay / self-destruct / threshold, then SaveSettings (0x25) to persist; tolerate the ~40–60 ms reboot silence and re-handshake.
5. Arm the timeline. Timer (0x11) starts the mandatory arm-delay; the device auto-advances to Safe at 0.
6. Arm. Send Arm (0x13) → Armed (via ChargeUp on capacitor devices).
7. Fire. Send Fire (0x14) → Fired.
8. Abort / safe. Cold (0x10) drops the state (countdowns persist per R1); Deactivate (0x16) returns to the maintenance lock-out.

Host invariants:

• Poll continuously — status polling is the only liveness signal, and the fire-pin gate requires a recent valid frame (~25 ms).
• The arm-delay and self-destruct countdowns are not cancellable once started (R1); design the mission timeline around them.
• Loss of link does not auto-disarm by default; the device is built to remain committed through terminal link loss. Opt into R9 (safe_on_lost_link) only if your concept of operations wants a link-loss safe-down.

12. Capability profiles

Devices share one wire protocol but differ in physical capability. The telemetry tail and state set are single-source (absent fields sent as zero, unsupported states never entered), so a host parser stays device-agnostic. Typical capability axes [profile]:

The base interface currently exposes these only out-of-band — there is no runtime capability-query command. An integrator supporting multiple device variants must know the target unit’s profile in advance. A future protocol revision may add a runtime capability descriptor. [profile]

13. Points requiring profile / vendor agreement

Behaviours the base v1.2 interface leaves to the integration profile ([profile]), collected:

1. Whether malformed frames are answered with BadCrc or silently dropped.
2. Exact GetCounters (0x03) body layout.
3. Which optional features a unit implements (capacitor / vcap / vbat / continuity / shunt / buzzer) — the capability profile of §12.
4. R7 impact-auto-fire threshold semantics and non-Armed recording.
5. R9 link-loss demote timing and whether it is enabled.
6. R10 ChargeUp settle/timeout values and the self-destruct-through-charge contract.
7. R11 shunt-pin behaviour (dedicated safed state vs. fire inhibit).
8. Buzzer tone details and any additional indicators.

Vendor-assigned values ([vendor]): the 4-byte command guard payloads, identity/version strings, default arm-delay and self-destruct times, board pinouts, and electrical thresholds.

This is a manufacturer-neutral interface description. The authoritative wire behaviour is defined by the vendor’s codec implementation and its conformance test vectors; where this document and a conformant device disagree, the device’s tested behaviour governs the wire, and this document should be corrected.

Picatinny CLIK v3.0 — Payload Serial Control Protocol

A manufacturer-neutral description of the CLIK v3.0 serial control interface between a host/integrator (carrier platform, fire-control system) and a CLIK-compatible payload module. It covers the electrical interface, frame format, message set, function-state model, timing, and status indication.

Values that a payload vendor assigns per program build are marked [vendor]; behaviour the base interface leaves to the integration profile is marked [profile] and summarised in §12. Nothing here identifies a specific manufacturer or part number.

1. Overview

The module is a command server: it transmits only in response to a received command frame and never sends unsolicited traffic. A host reads the module’s status/identity, activates it, and drives it through a safety state machine gated by two hardware discretes plus serial commands.

                        RS-232 serial (CLIK v3.0)
  Host / Fire-Control ── SAFETY ENABLE  (discrete) ──►  CLIK Payload ── Firing/actuation output ──►
  System              ── SAFETY EXECUTE (discrete) ──►  Module        ── Status indicator (RGB) ──►
  DC Power ────────────── V+ / Return ───────────────►

2. Physical & electrical interface

2.1 Serial link

Signal names are from the module’s perspective: RS-232 Rx is driven by the host, Tx is driven by the module.

2.2 Power

2.3 Safety discretes

Two isolated discrete inputs form the hardware side of a two-key interlock:

Both discretes share a dedicated isolated return. Arming and the terminal action each require the serial command and the matching discrete — neither alone advances the state (§8).

2.4 Connector (9-19 insert)

The module mates through a single Picatinny CLIK payload connector (micro-miniature dual-start, “Mighty Mouse” class; receptacle; shell 9-19; size #23 male contacts; keying Configuration A). Pins used by a given module are marked in its wiring drawing; unused/reserved pins shall not be repurposed.

3. Frame format

Every message (command and response) uses one frame. All multi-byte fields are big-endian.

+-----+-----+----------+----------+--------+-----+----------+-----------+
| AA  | 55  | MsgID hi | MsgID lo | Sync   | Len | Data...  | CRC16 be  |
+-----+-----+----------+----------+--------+-----+----------+-----------+
  0     1      2          3         4       5     6..6+N     6+N, 7+N

• CRC-16/CCITT-FALSE: polynomial 0x1021, init 0xFFFF, no reflection, no final XOR. Check value for ASCII "123456789" is 0x29B1.
• Total frame size is 8 + N bytes.

Framing rules

• After a valid 0xAA 0x55 header the module waits up to 500 ms for the rest of the frame, then discards the buffer and resynchronises on the next header.
• Frames that fail the CRC are ignored — the module does not reply to a frame it cannot trust (msg_id/sync are unverifiable on a corrupt frame). A Bad checksum result code exists for host-side decode but is not transmitted by the module. [profile]

4. Message set

4.1 Standard messages

A GET response returns a multi-byte data structure. A command/SET response returns a single data byte (a result code, §7); this is how a host distinguishes a data response from a result code.

4.2 Application (vendor) command range

Message IDs 0x8000–0xFFFF are reserved for payload-specific commands. A safety payload typically defines a three-command guard group; the IDs and guard payloads below are an [vendor] example assignment, not part of the base interface:

5. Command payloads

5.1 SetFunctionState (0x0004)

Data: [channel, state]. channel = 1 (single-function modules). state: 0x00 = De-Activate, 0x01 = Activate. Wrong length → 0x03; unknown channel or state value → 0x04.

5.2 Guard-word safety commands

Each application safety command carries a fixed guard payload (a vendor-defined constant that must match exactly) to reduce the chance of an accidental or corrupted command being acted on. The guard word is typically 4 bytes [vendor]. Wrong length → 0x03; correct length with a mismatched guard → 0x04.

“Concurrent discrete” means the serial command must arrive within the discrete-to-serial window (§9) after the corresponding discrete’s rising edge.

6. GET responses

Each success response echoes the request’s Msg ID and Sync, sets Data[0] = 0x00, and appends:

6.1 GetPayloadStatus (0x0000)

Status bits: bit0 Health (1 = OK), bit1 SAFETY ENABLE level, bit2 SAFETY EXECUTE level, bit3 Functions Available, bit4 Functions Activated, bit5 Functions Armed.

6.2 GetPayloadIdentifier (0x0001)

uid:u16-BE, then a null-terminated ASCII identifier string [vendor], then a null-terminated ASCII version string. Identifier ≤32 chars, version ≤16 chars.

6.3 GetPayloadSystemConfig (0x0002)

max_power_cpu:u8 (units of 250 mA @ 28 V), max_weight:u16-BE (0.1 lb units), monitors_discretes:u8 (boolean — whether the module enforces the safety discretes). These are fixed device properties; there is no Set* counterpart. A host uses them as a pre-flight compatibility check (bay power budget, mass/CG update, interlock enforcement).

6.4 GetFunctionStateIdentifiers (0x0003)

The supported state IDs and their names. Byte layout is [profile]; a common encoding is count:u8, then per state {id:u8, name ASCII, 0x00}.

7. Result codes

A rejected message returns exactly one data byte:

A 0x00 result confirms acceptance; a host should always confirm the resulting state with GetPayloadStatus.

8. Function-state model

State IDs are sparse — 4 and 5 are unassigned in v3.0:

        (power on)
            │
            ▼  power-on delay elapsed
       Unavailable ───────────────────► NotActivated
            ▲  idle lockout                 │ ▲
            │  ┌─────────────────────────────┘ │ SetFunctionState(De-Activate)
            │  │ SetFunctionState(Activate)     │
            │  ▼                                │
            └ Activated ◄─────────────────────┘
              │  ▲ ▲
   ENABLE+Arm │  │ └ Disarm / ENABLE released / armed-inactivity timeout
   (in window)│  │
              ▼  │
            Armed │
              │   │ Disarm
 EXECUTE+Fire │   │
 (in window)  ▼   │
            Firing ┘   (Firing exits only via Disarm — not on a discrete drop)

Key rules:

• Edge-triggered arm/execute. Arm requires Activated + SAFETY ENABLE asserted within the discrete-to-serial window of its rising edge; Fire/execute requires Armed + SAFETY EXECUTE the same way. Missing the window → 0x80.
• ENABLE release while Armed demotes to Activated. Firing is not exited by a discrete drop — only Disarm.
• Disarm returns Armed or Firing to Activated.
• Two-key principle: arm and execute each need both the serial command and the matching physical discrete.

If the module reports monitors_discretes = false, it does not enforce the discretes and the serial commands alone drive the states (a bench/test posture; a safety regression for field use).

9. Timing

Timer reset behaviour is [profile]: a common resolution is that the armed-inactivity timer resets on any valid frame (status polls keep it alive) while the idle-lockout timer resets only on actual state transitions.

10. Status indicator

The module drives an RGB indicator:

Modules with only a two-colour indicator approximate the two “blue” states with a distinct pattern (e.g. alternating colours for power-on delay, both solid for fault/lockout). [profile]

11. Integration sequence

1. Apply power. Poll GetPayloadStatus until state = Not Activated (2) — this covers the power-on delay.
2. Discover. GetPayloadIdentifier and GetPayloadSystemConfig; verify identity, bay power budget, mass/CG, and that discretes are monitored.
3. Activate. SetFunctionState(Activate) → Activated (3).
4. Arm. Assert SAFETY ENABLE, then send Arm within the window → Armed (6). Keep SAFETY ENABLE asserted while armed.
5. Execute. With SAFETY ENABLE still asserted, assert SAFETY EXECUTE, then send Fire within the window → Firing (7).
6. Safe / abort. Disarm (→ Activated), or de-assert the discretes; SetFunctionState(De-Activate) to return to Not Activated.

Host invariants:

• Drive the discrete GPIO and the serial command from the same task so the 50 ms window is met.
• Loss of comms does not auto-disarm; the safest abort is to drop the discrete (hardware-authoritative) then Disarm when comms return.
• Status polling is the only liveness signal — the module is server-only.

12. Points requiring profile agreement

The base v3.0 interface leaves several behaviours to the integration profile / vendor. The items marked [profile] above, collected:

1. Whether the module ever transmits 0x01 or silently drops all malformed frames.
2. Exact use of 0x80 vs 0x81, and the retry contract for each.
3. Whether a successful arm/execute consumes its discrete edge (so a held-high discrete needs a fresh drop-and-raise to re-arm).
4. Timer reset semantics (armed-inactivity vs idle-lockout).
5. State/command legality matrix at the edges (arm-while-armed, disarm-from-other-states, deactivate-while-armed).
6. Whether Disarm from Firing de-energises the actuation output, and whether that output latches.
7. Byte layout of the GetFunctionStateIdentifiers (0x0003) response.
8. Entry conditions for the Faulted state.
9. Two-colour indicator substitution for the RGB “blue” states.

Vendor-assigned values ([vendor]): identifier/version strings, UID, MPC/MPW, and the application (0x8000–0xFFFF) command IDs and guard payloads.

Kiwi-RM3100 CAN Compass

Overview

The Kiwi-RM3100 is an external compass module based on the PNI RM3100 magnetometer, designed as a DroneCAN peripheral for ArduPilot-powered flight controllers. Built on the STM32F103 MCU, it connects to any CAN-enabled flight controller and provides high-precision heading data via the DroneCAN protocol.

The RM3100 sensor offers superior magnetic resolution and noise performance compared to common QMC5883L or HMC5843 compasses, making it well-suited for applications where accurate heading is critical — long-range wings, survey drones, and missions in magnetically noisy environments.

Firmware

Previous versions

No previous versions archived yet.

Technical Specifications

Processor

• MCU: STM32F103xB (ARM Cortex-M0, 72 MHz)
• Flash: 128 KB
• Crystal: 8 MHz external oscillator

Compass Sensor

• Sensor: PNI RM3100
• Interface: SPI (1 MHz)
• Mounting orientation: ROTATION_PITCH_180

Communication

• CAN bus — primary interface, DroneCAN protocol
• CAN silent pin on PB5 (active low)

Serial Ports

Additional Interfaces

• SPI2 spare bus (PB13/PB14/PB15) — available for additional sensors
• AUX analog input on PA0

Indicators

• Status LED on PC13 (active low)

ArduPilot Configuration

The Kiwi-RM3100 runs ArduPilot AP_Periph firmware. Once connected to the CAN bus, the flight controller auto-detects the compass.

Flight Controller Parameters

Enable CAN on the flight controller:

CAN_P1_DRIVER = 1
CAN_D1_PROTOCOL = 1   (DroneCAN)

The compass should appear automatically. Verify with:

COMPASS_DEV_ID

Pinout

CAN Connector

Ініціатор для мін універсальний

Призначення

Ініціатор споряджається у протитанкові або протипіхотні міни типу ПOM, ПМН-3, ОЗМ-72, МОН-50, ТМ-62, ПТМ-3, ПТМ-4 тощо.

Основні задачі

• мінування під’їзних шляхів наступу ворожих військ;
• міна-пастка;
• підрив міни при скиді з БПЛА.

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

Міна проектується з метою унеможливити її знешкодження крім фізичного дистанційного знищення. Вона реагує на найменші рухи чи повороти корпусу, а також наближення феромагнітних предметів (бронежилет, зброя, інструменти тощо) при спробі знищення.

Електроніка може встановлюватись у корпуси стандартних серійних мін, щоб ворожий сапер вважав, що він має справу з відомою міною натискної дії (пастка для сапера).

Встановлення опційного приймача команд дозволяє підірвати міну при наближенні до місця її розташування групи ворожої піхоти чи техніки. При переході у наступ можливість віддаленого керування дозволяє оперативно розмінувати шлях наступу дружніх підрозділів.

Переваги

• кілька датчиків цілі;
• можливість зміни програми відповідно до задач;
• віддалене керування (опція);
• неможливість деактивації без пульта;
• можливість пастки з відкладеним вибухом.

Конструкція

• корпус;
• кришка;
• плата з електронними компонентами (16×44×10 мм);
• механічний запобіжник;
• елемент живлення;
• приймальна антена (опціонально);
• вибухова речовина;
• вражаючі елементи;
• електродетонатор.

Датчики цілі

Спрацювання ініціатора відбувається у випадках:

• натискання (8–20 кг);
• замикання сухого контакту;
• переміщення, поворот або нахил міни;
• удар з будь-якого напрямку;
• спроба розібрати корпус;
• зміна магнітного поля, у тому числі наближення феромагнітних об’єктів та металошукачів;
• сигнал від пульта керування (опціонально);
• самознищення за таймером та при розряді батареї нижче критичного рівня.

Керування з пульта: напряму або через ретранслятор. Можливий вибірковий підрив або підрив групи мін.

Запобіжники

• Механічний – чека.
• Електронний – таймер затримки зведення, програмується від 2 хвилин до кількох годин. Таймер обнуляється при найменших рухах міни. Для переведення у бойовий стан вимагається, щоб міна лежала нерухомо протягом усього часу роботи таймера. Це дозволяє витягнути чеку і встановлювати міну вручну або за допомогою дрона без ризику підриву.
• Електронний – активація з пульта (за наявності приймача).

Живлення

• літієва батарея типу 18650 або 2–3 елементи АА/ААА;
• струм споживання – менше 1 мА;
• час безперервної роботи у режимі очікування: до 30 діб залежно від типу батареї;
• при комплектуванні приймачем команд – до 10 діб;
• можливе самознищення при падінні напруги нижче критичного рівня.

Установка

• вручну;
• скид з БПЛА;
• доставка наземним дроном.

Принцип роботи

Після установки або скиду, акселерометр та магнетометр запам’ятовують поточне положення міни відносно вектора прискорення та магнітного поля Землі.

• Зміна положення фіксується акселерометром,
• поворот – гіроскопом,
• зміна магнітного поля – магнетометром.

Перевищення встановлених порогів призводить до підриву.

Заплановані удосконалення у версії 2.0

• інтегрований приймач команд у складі плати;
• покращений алгоритм енергозбереження;
• нові батареї типу LiCOCl₂ з температурним діапазоном від -60 до +80 °C та строком зберігання до 10 років.

Universal initiator for land mines PyroMine

Purpose

The initiator is designed for anti-tank and anti-personnel mines such as POM, PMN-3, OZM-72, MON-50, TM-62, PTM-3, PTM-4, etc.

Main tasks

• mining the supply lines of enemy troops;
• trap mine;
• detonation of a mine when dropped from a UAV.

The electronics ensure the safety of the sapper who installs the mine manually or the UAV pilot who performs the drop, thanks to two fuses (or three with command receiver).

The initiator is designed to make neutralization impossible except by remote destruction. It reacts to even slight movements, tilts, or the approach of ferromagnetic objects.

It can be mounted into standard mine bodies so that enemy sappers mistake it for a known pressure mine (booby trap).

With an optional command receiver, the mine can be detonated upon the approach of enemy infantry or vehicles. During an offensive, remote control allows quick clearance of friendly paths.

Advantages

• multiple target sensors;
• reprogrammable for specific missions;
• remote control (optional);
• impossible to deactivate without remote unit;
• trap with delayed explosion.

Design

• body;
• cover;
• PCB with electronics (16×44×10 mm);
• mechanical fuse;
• battery;
• receiving antenna (optional);
• explosive charge;
• fragments;
• electric detonator.

Target sensors

The initiator is triggered by:

• pressing (8–20 kg);
• dry contact closing;
• moving, turning or tilting the mine;
• impact from any direction;
• disassembly attempt;
• magnetic field changes (ferromagnetic objects, metal detectors);
• remote signal (optional);
• self-destruction on timer or low battery.

Remote control: direct or via repeater. Selective or grouped detonation.

Fuses

• Mechanical – safety pin.
• Electronic – arming delay timer (2 minutes to several hours). Reset on any movement, requires the mine to stay still to arm.
• Electronic – remote activation (if receiver is installed).

Power

• lithium 18650 or 2–3 AA/AAA cells;
• consumption <1 mA;
• standby operation up to 30 days;
• with command receiver – up to 10 days;
• optional self-destruction at critical voltage.

Deployment

• manual;
• UAV drop;
• ground drone delivery.

Operation principle

After deployment, the accelerometer and magnetometer record initial orientation and field values.

• accelerometer detects movement,
• gyroscope detects rotation,
• magnetometer detects magnetic changes.

Threshold exceedance results in detonation.

Planned improvements in version 2.0

• integrated command receiver on PCB;
• enhanced power-saving algorithms;
• new LiCOCl₂ batteries with -60 to +80 °C operating range and 10-year shelf life.

Flight Controller Board: KIWI F405 12S Configuration

Buy Online Buy Online

Overview

KIWI F4.0 is a versatile flight controller based on the STM32F405, designed for FPV, wings, and autonomous platforms. The controller combines precision inertial sensing, OSD support, built-in Blackbox, and relay outputs for controlling external modules. Support for both Betaflight and ArduPilot allows this board to be used in a wide range of applications.

KIWI F4.0 is a reliable platform for building FPV drones, aircraft, and specialized autonomous systems with full support for Betaflight and ArduPilot. Thanks to flexible relay, sensor, and telemetry connectivity, the controller is ready for real-world mission use.

Firmware

Previous versions

Pinout and Diagrams

(Click to zoom in)

Features

• Industrial-grade IMU Invensense ICM-42688P with external clock
• Bosch BMP388 barometer for altitude measurement
• Integrated 128Mbit Blackbox flash memory (W25Q128FV)
• MAX7456 OSD chip for overlaying telemetry on analog video
• High-precision voltage and current monitoring via ADC (VBAT, CURRENT)
• GPIO-controlled relay outputs for powering VTX, cameras, or pyrotechnic systems
• 4 motor PWM outputs (DShot, bidirectional on M1 & M3) + 6 auxiliary channels
• USB Type-C with DFU firmware flashing support
• Full CRSF / ELRS telemetry support (RSSI, LQ, SNR, Power)

Technical Specifications

• MCU: STM32F405RG (168 MHz, 1024 KB flash)
• Crystal: 16 MHz external oscillator
• IMU: ICM-42688P (SPI2, rotation ROLL_180_YAW_90)
• Barometer: BMP388 (I2C1, address 0x76)
• OSD: MAX7456 (SPI1)
• Flash Memory: W25Q128FV 128 Mbit (SPI3)
• Dimensions: 36×36 mm, mounting 30.5×30.5 mm
• LED: PC2 (active low)

Serial Ports

GPIOs, Relays, and AUX

Dedicated GPIO Pads

RELAY1 (F+ pad) works out of the box — pre-configured in hwdef. U1/U2/U3 need params set to use as relays.

PWM Outputs

PWM9/PWM10 have no GPIO ID in hwdef — PWM only. Other PWM pins can be reassigned to GPIO via SERVOn_FUNCTION=0 + RELAYn_PIN=<gpio>.

Relay Usage

MAVProxy:

param set RELAY2_PIN 100
param set RELAY2_FUNC 1
relay set 0 1    # RELAY1 ON (F+ pad HIGH)
relay set 0 0    # RELAY1 OFF
relay set 1 1    # RELAY2 ON (U1 pad HIGH)

Mission waypoint: DO_SET_RELAY — relay number 0-based (0=RELAY1), setting 1=ON / 0=OFF.

Lua:

relay:toggle(0)  -- toggle RELAY1
relay:on(1)      -- RELAY2 ON
relay:off(1)     -- RELAY2 OFF

All GPIO pads default LOW on boot. Use RELAY_DEFAULT params to set initial state.

Power Monitoring

• Battery Voltage: PC0 (ADC1 IN10)
• Battery Current: PC1 (ADC1 IN11)
• Default monitor type: Analog (type 4)

Sensor Calibration

Battery Voltage Thresholds (ArduPilot)

SPI Bus Assignment

I2C Bus

• I2C1: PB8 (SCL), PB9 (SDA) — BMP388 barometer at 0x76, external compass probing

Debug

• SWDIO: PA13
• SWCLK: PA14

Premium Features

Kiwi OSD Pinio Elements (Betaflight 2025.12+)

Custom OSD text elements that change based on PINIO switch state (User 1–4 boxes). Each element displays configurable ON/OFF text labels, useful for showing relay status, arming indicators, or mission state on the OSD.

CLI Settings

Where N is 1–4 corresponding to PINIO1–PINIO4.

Example Setup

# Show SAFE/ARMED on OSD driven by User 2 switch
set kiwi_osd_pinio2_text_on = ARMED
set kiwi_osd_pinio2_text_off = SAFE
set kiwi_osd_pinio2_pos = 2242

# Show PARACHUTE only when User 3 switch is active, hidden when off
set kiwi_osd_pinio3_text_on = PARACHUTE
set kiwi_osd_pinio3_text_off = -
set kiwi_osd_pinio3_pos = 2274

# Assign User 2 to AUX3 switch (high position)
aux 3 41 3 1700 2100 0 0

# Assign User 3 to AUX2 switch (high position)
aux 4 42 2 1700 2100 0 0

save

Hardware Notes

On the KIWI F405 12S, only PINIO4 (PA4 / RELAY1) has a physical GPIO pin. PINIO1–3 are defined as NONE in the hardware config, but the OSD elements still work — the User box toggles the logical state, and the OSD text updates accordingly. No physical pin is needed for OSD-only use.

Kiwi Flyaway Protection Reset (Betaflight 2025.12+)

Allows re-arming your UAV after flying by resetting the flyaway protection on disarm. This premium feature provides enhanced safety and convenience for long-range and autonomous flights.

CLI Settings

Usage

The flyaway protection in Betaflight prevents arming when the drone has been moved significantly since it was last armed. This is a safety feature to prevent accidental arming after transport. However, for certain use cases like:

• Long-range missions where you need to re-arm at a different location
• Search and rescue operations requiring multiple takeoffs
• Delivery drones that need to re-arm after landing

The Kiwi flyaway protection reset feature allows you to reset this protection when disarming, enabling re-arming without power cycling.

Example Setup

# Enable flyaway protection reset on disarm
set kiwi_runaway_reset_on_disarm = ON

# Save configuration
save

Note: This feature requires Betaflight 2025.12 or later with Kiwi custom firmware.

Camera Gimbal Support

KIWI F405 supports camera gimbals out of the box — both servo-based and MAVLink protocol gimbals (CADDX GM3 V2 and compatible).

MAVLink Gimbal

Wire gimbal UART to any free serial port (gimbal TX → FC RX, gimbal RX → FC TX, GND).

RC Control

Assign RC channels to control gimbal axes:

Example: with MNT1_RC_RATE=60, moving the RC6 stick deflects pitch at 60°/s. Set MNT1_RC_RATE=0 for direct angle control (stick position = gimbal angle).

Gimbal firmware must be V2.0 or higher.

Servo Gimbal

Connect pitch/yaw servos to AUX PWM outputs (PWM5–PWM8).

Default Parameters

• Frame: Quadcopter (FRAME_CLASS=1, FRAME_TYPE=3 BetaFlight X reversed)
• Motor protocol: DShot (MOT_PWM_TYPE=5)
• BLHeli passthrough: enabled (SERVO_BLH_AUTO=1, mask=15)
• Flight mode channel: CH8
• VTX: enabled, band 6, channel 4, freq 1240

KiwiH743 12S Flight Controller

Buy Online Buy Online

Overview

The KiwiH743 is a high-performance flight controller based on the STM32H743 MCU, designed for advanced UAV applications. It combines powerful processing, flexible connectivity, and rich sensor support, optimized for ArduPilot firmware.

It is the next generation of the KiwiF405 family, offering 2MB flash, 480 MHz CPU clock, extended UART/SPI/I2C buses, and support for dual IMUs, barometer, and OSD integration.

Premium features: GPS-less takeoff, IRC Tramp VTX control, VRX integration (TBS Fusion, Skyzone Steadyview).

Firmware

Both 4.5 (Plane-4.5.7 LTS) and 4.6 (current) ArduPilot branches are maintained in parallel. Pick the one that matches your fleet.

Previous versions

SD Card Version

The KiwiH743 has a built-in 16 MB DataFlash chip for logging, but if you need more storage (longer flights, detailed logs), you can connect an external SD card module via the SPI1 interface.

Step 1 — Flash SD card firmware

Download and install KiwiH743-sdcard.zip. This firmware disables the onboard DataFlash and enables FATFS file system on the SD card. All logging will go to the SD card instead.

Step 2 — Wire SD card module to SPI1

Connect a 5V-tolerant SPI micro-SD breakout module to the SPI1 pads on the board:

  KiwiH743 (SPI1)           SD Card Module
 ┌──────────────┐          ┌──────────────┐
 │ PA5  (SCK)  ─┼──────────┼─ SCK         │
 │ PA6  (MISO) ─┼──────────┼─ MISO (DO)   │
 │ PA7  (MOSI) ─┼──────────┼─ MOSI (DI)   │
 │ PA4  (CS)   ─┼──────────┼─ CS          │
 │ 5V          ─┼──────────┼─ VCC         │
 │ GND         ─┼──────────┼─ GND         │
 └──────────────┘          └──────────────┘

Use a 5V-tolerant SD card breakout with an onboard voltage regulator. We can ship one with the board upon request — just mention it when ordering.

Format the card as FAT32 before first use.

Features

• Dual IMUs: ICM-42688P + ICM-45686 with EKF3 dual-source fusion
• BMP388 barometer, external compass support (I²C probing)
• Integrated OSD (MAX7456-compatible via SPI4)
• 14 PWM outputs (8 motors + 6 servos), DShot bidirectional on M1–M4
• 7 hardware UARTs + 2 USB ports (OTG1 MAVLink, OTG2 HiSpeed serial)
• 16 MB DataFlash + external SD card slot
• Visual odometry, external AHRS, GPS moving baseline support
• Gyro FFT for vibration analysis
• INS temperature calibration
• Guided (NoGPS), FlowHold, OpticalFlow modes

Technical Specifications

• MCU: STM32H743VIT6 (ARM Cortex-M7, 480 MHz, 2048 KB flash)
• Crystal: 16 MHz external oscillator
• IMU1: ICM-42688P (SPI6, rotation YAW_180)
• IMU2: ICM-45686 (SPI2, rotation YAW_270)
• Barometer: BMP388 (I2C2, address 0x76)
• OSD: MAX7456-compatible (SPI4)
• DataFlash: 16 MB (SPI3)
• LED: PE4 (active low)
• Dimensions: 36×36 mm, mounting 30.5×30.5 mm

Serial Ports

Pin column is in TX, RX order. Ports without DMA fall back to interrupt + FIFO and are not deterministic at high baud.

RC input: SBUS/DSM on PE11.

High-baud MAVLink ports

For peripherals that need >115 k baud (e.g. ELRS+MAVLink, RTK GPS+MAVLink), use the DMA-backed UARTs:

GPIOs, Relays, and AUX

Dedicated GPIO Pads

Note: RELAY1_PIN defaults to GPIO 100 (Camera Switch pad, PA8), not the pad labeled “RELAY1” (PD4, GPIO 101). This is set in the hwdef. Adjust if your wiring differs.

PWM Outputs

PWM pins can be reassigned to GPIO via SERVOn_FUNCTION=0 + RELAYn_PIN=<gpio>.

Spare ADC

Relay Usage

MAVProxy:

param set RELAY2_PIN 101
param set RELAY2_FUNC 1
relay set 0 1    # RELAY1 ON (CAM SW pad HIGH)
relay set 0 0    # RELAY1 OFF
relay set 1 1    # RELAY2 ON (RELAY1 pad HIGH)

Mission waypoint: DO_SET_RELAY — relay number 0-based (0=RELAY1), setting 1=ON / 0=OFF.

Lua:

relay:toggle(0)  -- toggle RELAY1 (CAM SW)
relay:on(1)      -- RELAY2 ON (RELAY1 pad)
relay:off(1)     -- RELAY2 OFF

All GPIO pads default LOW on boot. Use RELAY_DEFAULT params to set initial state.

Power Monitoring

• Battery Voltage: PC5 (ADC1 IN8)
• Battery Current: PB1 (ADC1 IN5)
• Default monitor type: Analog

Sensor Calibration

Battery Voltage Thresholds (ArduPilot)

Buses

SPI

I2C

Example Frame and Modes

• Default frame: Quadcopter X (FRAME_TYPE=18, BetaFlight-X Reversed motor order — props-out rotation)
• Motor protocol: DShot (MOT_PWM_TYPE=5)
• BLHeli passthrough: enabled (SERVO_BLH_AUTO=1, mask=15)
• Flight mode channel: CH8
• VTX: enabled, band 6, channel 4

Camera Gimbal Support

KiwiH743 supports camera gimbals out of the box — both servo-based and MAVLink protocol gimbals (CADDX GM3 V2 and compatible).

MAVLink Gimbal

Wire gimbal UART to any free serial port (gimbal TX → FC RX, gimbal RX → FC TX, GND).

RC Control

Assign RC channels to control gimbal axes:

Example: with MNT1_RC_RATE=60, moving the RC6 stick deflects pitch at 60°/s. Set MNT1_RC_RATE=0 for direct angle control (stick position = gimbal angle).

Gimbal firmware must be V2.0 or higher.

Servo Gimbal

Connect pitch/yaw servos to any Servo PWM outputs (PWM9–PWM14).

Pinout Reference

ESC Pins

1 - ESC Telemetry
2 - ESC Current
3 - Motor4
4 - Motor3
5 - Motor2
6 - Motor1
7 - VBAT
8 - GND

KiwiH743-Wing Flight Controller

Buy Online Buy Online

Overview

The KiwiH743-Wing is a Pixhawk-format flight controller system consisting of two boards: a Flight Controller and a Power Distribution Board (PDB). Designed for expendable quadcopters and long-range fixed-wing drones. Ready to use with Rover, Wing, Quadcopter, and Hexacopter configurations.

Premium features: GPS-less takeoff, IRC Tramp VTX control, VRX integration (TBS Fusion, Skyzone Steadyview).

Firmware

The noclkin build is an A/B test control with the external 32.768 kHz IMU clock disabled — IMUs run on their internal oscillators. Same APJ_BOARD_ID, loads with the same bootloader.

Both 4.5 (Plane-4.5.7 LTS) and 4.6 (current) ArduPilot branches are maintained in parallel. Pick the one that matches your fleet.

Previous versions

Features

• STM32H743 MCU (480 MHz, 2 MB flash)
• 12S power supply
• 5V, 6/7V, 9/12V 5A BECs
• ICM-42688P and ICM-45686 with power and hardware signal filtering
• BMP388 barometer
• Dual camera input, switchable
• 8 motors + 7 servos (15 PWM outputs)
• 5 UARTs, UART7 with flow control
• 1 SPI, 1 I2C, FDCAN
• 5 GPIOs, 2 relay outputs, 9/12V switch
• Analog + digital VTX output
• STM32G4 OSD
• SD card via SDMMC
• 40 x 42 mm board, 36 x 39 mm mounting holes

Technical Specifications

Processor

Sensors

Power

Mechanical

Serial Ports

Ports without DMA fall back to interrupt + FIFO and are not deterministic at high baud.

High-baud MAVLink ports

For peripherals that need >115 k baud (e.g. ELRS+MAVLink, RTK GPS+MAVLink), use the DMA-backed UARTs:

Default firmware already sets SERIAL7_PROTOCOL = MAVLink2 on the Wing, so for a second high-baud link just set SERIAL7_BAUD = 460.

Connectors and Wire Colors

Port connection diagram for cable assembly. Pin order in each connector matches the silkscreen labels on the board, read left to right.

Wire Color Legend

Note: Wire colors are intended to simplify cable assembly and connector identification. Signal names printed on the PCB always take precedence over wire color. On the VTX cable, 5V is the video 5V rail (blue) — distinct from 12V (red).

GPIOs, Relays, and AUX

Dedicated GPIO Pads

Note: RELAY1_PIN defaults to GPIO 100 (Camera Switch, PE2). RELAY6_PIN defaults to GPIO 104 (VIDEO_NRST, PE3 — STM32G4 OSD reset, active low). RELAY 1/2 pads are 9/12V switched outputs.

PWM Outputs

PWM pins can be reassigned to GPIO via SERVOn_FUNCTION=0 + RELAYn_PIN=<gpio>.

Relay Usage

MAVProxy:

param set RELAY2_PIN 101
param set RELAY2_FUNC 1
relay set 0 1    # RELAY1 ON (CAM SW HIGH)
relay set 0 0    # RELAY1 OFF
relay set 1 1    # RELAY2 ON (RELAY1 pad HIGH)

Mission waypoint: DO_SET_RELAY — relay number 0-based (0=RELAY1), setting 1=ON / 0=OFF.

Lua:

relay:toggle(0)  -- toggle RELAY1 (CAM SW)
relay:on(1)      -- RELAY2 ON (RELAY1 pad)
relay:off(1)     -- RELAY2 OFF

All GPIO pads default LOW on boot. Use RELAY_DEFAULT params to set initial state.

OSD Reset (RELAY6):

RELAY6 controls the STM32G4 OSD reset line (VID NRST). Active low — set RELAY6_INVERTED=1 so that “relay on” pulls the line low (reset) and “relay off” releases it.

param set RELAY6_PIN 104
param set RELAY6_FUNCTION 1
param set RELAY6_INVERTED 1
relay set 5 1   # reset OSD
relay set 5 0   # release reset

Power Monitoring

Sensor Calibration

Battery Voltage Thresholds (ArduPilot)

Buses

SPI

I2C

FDCAN

SDMMC (SD Card)

Premium Features

GPS-less Takeoff (ArduPlane)

KIWI firmware supports autonomous takeoff without a GPS fix. Useful for hand launch or catapult deployment in GPS-denied environments.

Parameters:

Procedure:

1. Power on, wait for EKF convergence
2. Set home (from GPS before loss, or manually via MAVLink)
3. Arm in FBWA mode
4. Switch to TAKEOFF mode

IRC Tramp VTX Control

Full IRC Tramp protocol support under ArduPilot. Change VTX power, band, channel, and pit mode directly from your GCS or OSD — no need for SmartAudio.

Works with TBS Unify, Rush Tank, and other Tramp-compatible VTXs.

VRX Integration (TBS Fusion / Skyzone)

Working video receiver control under ArduPilot. Supports:

• TBS Fusion — band/channel tracking via CRSF
• Skyzone Steadyview — auto channel sync

Camera Gimbal Support

KiwiH743-Wing supports camera gimbals out of the box — both servo-based and MAVLink protocol gimbals (CADDX GM3 V2 and compatible).

MAVLink Gimbal

Wire gimbal UART to any free serial port (gimbal TX → FC RX, gimbal RX → FC TX, GND).

RC Control

Assign RC channels to control gimbal axes:

Example: with MNT1_RC_RATE=60, moving the RC6 stick deflects pitch at 60°/s. Set MNT1_RC_RATE=0 for direct angle control (stick position = gimbal angle).

Gimbal firmware must be V2.0 or higher.

Servo Gimbal

Connect pitch/yaw servos to any Servo PWM outputs (SERVO 9–SERVO 15).

Displayport OSD

HD OSD via MSP Displayport on SERIAL8 (OSD UART). Compatible with DJI O3, HDZero, Walksnail.

param set OSD_TYPE 5
param set OSD_UNITS 0
param set MSP_OPTIONS 4
param set MSP_OSD_NCELLS 0
param set SERIAL8_BAUD 115
param set SERIAL8_OPTIONS 0
param set SERIAL8_PROTOCOL 42

Flight Controller

Built around the STM32H743, the flight controller provides dual IMUs with hardware signal filtering, dual switchable camera inputs, and relay-controlled power outputs.

Power Distribution Board (PDB)

Features

• 4S–12S power input
• 5V 5A output
• 5/6/7/9V 5A adjustable output
• 12V 5A output
• 3.3V 1A output
• 0.1 mOhm current sensor
• 36 x 39 mm mounting holes
• 42 x 75 mm board dimensions

Other

Full Pinout Reference

Port A (PA)

Port B (PB)

Port C (PC)

Port D (PD)

Port E (PE)

Flight Controller Board: KIWI F405 6S Configuration

Description

The KIWI F4.0 is a versatile STM32F405-based flight controller designed for FPV, fixed-wing aircraft, and autonomous platforms. It integrates precise inertial sensing, OSD support, built-in Blackbox logging, and relay outputs for controlling external modules. With support for both Betaflight and ArduPilot, the board can be deployed across a wide range of use cases.

KIWI F4.0 is a reliable platform for building FPV drones, aircraft, and specialized autonomous systems. Its flexible support for relays, sensors, and telemetry makes it ready for real-world mission environments.

Firmware

Previous versions

No previous versions archived yet.

Features

• Industrial-grade Invensense ICM-42688P IMU with external clock
• Bosch BMP388 barometer for altitude measurement
• Built-in 128Mbit Blackbox flash memory (W25Q128FV)
• MAX7456 OSD chip for overlaying telemetry on analog video
• High-precision voltage and current monitoring via ADC
• GPIO-controlled relay outputs for powering VTX, cameras, or pyrotechnic systems
• 4 PWM outputs for motors and 6 channels for servos
• USB Type-C with DFU support for firmware updates
• Full CRSF / ELRS support with telemetry (RSSI, LQ, SNR, Power)

Technical Specifications

• MCU: STM32F405RG (168 MHz)
• IMU: ICM-42688P with external clock
• Barometer: Bosch BMP388
• OSD: MAX7456
• Flash: W25Q128FV (128 Mbit)
• Ports:
  • 5× UART (ESAD, RC, GPS, VTX, ESC/MSP)
  • 1× I2C
  • 3× SPI (OSD, IMU, FLASH)
  • ADC: VBAT, CURRENT
• PWM:
  • 4 motor channels
  • 6 servo channels
• GPIO relays:
  • 4 relay outputs: X1, X2, X3, X4 (controlled via GPIO)
• Interfaces:
  • USB Type-C
  • SWD debug interface
• Dimensions:
  • 36×36 mm
  • Mounting: 30.5×30.5 mm
• Status LED indicator

Camera Gimbal Support

KIWI F405 supports camera gimbals out of the box — both servo-based and MAVLink protocol gimbals (CADDX GM3 V2 and compatible).

MAVLink Gimbal

Wire gimbal UART to any free serial port (gimbal TX → FC RX, gimbal RX → FC TX, GND).

RC Control

Assign RC channels to control gimbal axes:

Example: with MNT1_RC_RATE=60, moving the RC6 stick deflects pitch at 60°/s. Set MNT1_RC_RATE=0 for direct angle control (stick position = gimbal angle).

Gimbal firmware must be V2.0 or higher.

Servo Gimbal

Connect pitch/yaw servos to AUX PWM outputs.

FPV Польотний контролер KIWI F722

Опис

KIWI F722 — це високопродуктивний контролер польоту для FPV та автономних дронів, розроблений для максимального рівня точності, стабільності та надійності. Підтримка популярних прошивок Betaflight та iNAV дозволяє легко адаптувати контролер до різних сценаріїв використання.

KIWI F722 — це рішення для тих, хто шукає виняткову стабільність, розширені можливості підключення та готовність до будь-яких викликів у FPV та автономних польотах.

Firmware

Previous versions

No previous versions archived yet.

Особливості

• Наднизькошумний IMU TDK ICM-42688 з зовнішнім тактовим генератором
• Присвячена фільтрація живлення для IMU для ще кращої точності
• Вбудований барометр Bosch BMP388
• Чіп OSD для накладання даних на відео (AT7456E)
• Вбудована флеш-пам’ять чорного ящика 64Мбіт (W25Q128JVPQ)
• Підтримка роботи із зовнішніми сенсорами через UART та I2C
• GPIO керовані релейні виходи для живлення VTX, Raspberry Pi чи іншого обладнання
• Перемикання двох камер на борту
• Підтримка підключення двох VTX з можливістю перемикання живлення
• Пряма підтримка Betaflight ESC (Plug & Play)

Технічні характеристики

• MCU: STM32F722RET6 (216 МГц)
• IMU: ICM-42688 з зовнішнім годинником
• Барометр: Bosch BMP388
• OSD: AT7456E
• Флеш пам’ять: W25Q128JVPQ (64Мбіт)
• Порти:
  • 4x UART
  • 1x I2C
  • 2x PWM виходи для сервоприводів
  • ADC: моніторинг VBAT та струму CURR
• Живлення:
  • Вхід живлення: 6S акумулятор
  • Вбудовані DC-DC конвертори: 5V 3A та 9V 3A
• Світлодіодні індикатори: Power LED, MCU Status LED (PWM керовані)
• Роз’єми: JST-SH 1.0мм
• Кріплення: 30.5×30.5 мм (стандартне для FPV)
• Габарити: 39×39 мм

Застосування

• FPV-квадрокоптери та літальні апарати
• Автономні безпілотники для розвідки, доставки, моніторингу
• Робототехнічні платформи з вимогами до точного управління

Підтримка підвісів камери

KIWI F722 підтримує сервоприводні та MAVLink підвіси камери (CADDX GM3 V2 та сумісні).

MAVLink підвіс

Підключіть UART підвісу до вільного серійного порту (gimbal TX → FC RX, gimbal RX → FC TX, GND).

Керування RC

Прошивка підвісу має бути V2.0 або вище.

Сервоприводний підвіс

Підключіть серво pitch/yaw до PWM виходів сервоприводів.

ICM-42688P — 6-Axis Inertial Sensor Module

Manufacturer: Shenzhen HuaXuanYang (HXY) Electronics CO., LTD Website: www.hxymos.com

Description

The ICM-42688P is a highly integrated, low-power inertial measurement unit (IMU) with a built-in high-performance 3-axis accelerometer and 3-axis gyroscope measurement unit. The accelerometer full-scale range is +/-2g/+/-4g/+/-8g/+/-16g. The gyroscope angular rate full-scale range is +/-125dps/+/-250dps/+/-500dps/+/-1000dps/+/-2000dps. Users can flexibly measure external acceleration and angular velocity, with accelerometer output data rate from 0.78 Hz to 1.6 kHz selectable, and gyroscope output data rate from 25 Hz to 3.2 kHz selectable.

The chip communicates with the MCU via I2C/SPI interface. Accelerometer and gyroscope measurement data can be obtained by interrupt or polling. INT1 and INT2 interrupt pins provide various internal auto-detection interrupt signals for diverse motion detection scenarios, enabling reliable motion detection, attitude estimation, and gesture recognition at extremely low system power. Interrupt sources include 6D/4D orientation detection, free-fall detection, sleep and wake detection, single-tap and multi-tap detection, step counting, pedometer, and OIS function interrupts, as well as temperature detection interrupts.

The chip has a built-in high-precision calibration reference and an internal LDO circuit. At different supply voltages, zero drift remains more stable, correcting sensor gain errors and gain mismatch for precise angle-to-angle conversion testing. The chip has a built-in self-test function that allows customer system testing to detect system functionality, eliminating complex angle-to-angle conversion testing.

The ICM-42688P is applicable to smartphones, drones, game controllers, various IoT, and smart hardware systems. It supports mainstream operating systems for micro-step and motion capture screen functionality, and provides drones, game controllers, VR, and AR algorithm support.

Key Features

• Analog supply voltage range: 1.71~3.6V
• Low-power mode total combined supply current: 399uA
• High-performance mode total combined supply current: 927uA
• Accelerometer and gyroscope 16-bit data output
• I2C/SPI digital output interface
• Built-in temperature sensor
• 6D/4D orientation detection, tilt detection/angle detection, static and motion detection
• Sleep and wake detection, free-fall detection, single-tap and multi-tap detection
• SensorTime function
• OIS function (ODR=6.4kHz)
• Programmable interrupt generation circuit
• Built-in programmable step counter detection, built-in programmable wrist tilt recognition, built-in self-test function
• Built-in FIFO
• 10,000g high shock resistance
• EU-compliant lead-free package, environmentally friendly

Applications

• AR/VR devices
• Smartphones and tablets
• Smart wearable devices
• Head-mounted device accessories
• Attitude detection equipment
• Image rotation scene switching
• Strike detection scene activation
• Motion detection devices
• 9D orientation detection scenarios
• Gesture recognition scenarios
• Vibration detection and compensation scenarios
• Indoor navigation / pedestrian path tracking / positioning scenarios
• 3D scanning / indoor mapping / SLAM scenarios
• Virtual reality games
• Mouse / game controllers
• IoT application scenarios
• Optical image stabilization for cameras
• Toy drones

Product Classification

Internal Block Diagram

The internal architecture includes:

• MEMS gyroscope drive (CV, Demod, LPF, VCO, MUX/VGA) with quadrature compensation
• MEMS accelerometer sensing (CA channels for X/Y/Z with Demod and ADC)
• Gyroscope sensing (CV + ADC for X/Y/Z axes)
• Digital LPF, Composite Filter
• Temperature compensation and sensor
• I2C/SPI interface (CS, SCL/SCK, SDA/SDI, SDO)
• Clock generator, Phase generator
• FIFO, Power Management (PM), Reference (REF)
• Control Logic and Interrupt Generation (INT1, INT2)
• BIAS generator, Charge Pump (CP)

Absolute Maximum Ratings

Pin Description

Package: LGA14-2.5x3x1.00mm3

Acceleration Direction

X, Y, Z axes as marked on package (pin 1 indicator dot at corner).

Gyroscope Direction (top view)

+Omega_X, +Omega_Y, +Omega_Z rotation axes as marked.

Pin Table

Mechanical Parameters — Accelerometer (VDD=1.8V, T_A=25degC)

Note: Circuit is factory calibrated at 1.8V. Actual operating voltage is 1.71V-3.6V.

Mechanical Parameters — Gyroscope (VDD=1.8V, T_A=25degC)

Note: Circuit is factory calibrated at 1.8V. Actual operating voltage is 1.71V-3.6V.

Electrical Parameters (VDD=1.8V, T_A=25degC)

I2C Control Interface Parameters (=1.8V, TA=25degC)

SPI Serial Peripheral Interface Parameters (V_DD=1.8V, T_A=25degC)