# Home

<figure><img src="/files/agXkRIa5mwCK07Iy3u1I" alt=""><figcaption></figcaption></figure>

{% content-ref url="/pages/GLST3ZCO49Xk3K3Arg9L" %}
[Knowledge Base](/knowledge-base/knowledge-base)
{% endcontent-ref %}

{% content-ref url="/pages/WR9St4ewUyVZVL0rHy6U" %}
[Embedded Computers](/products/embedded-computers)
{% endcontent-ref %}

{% content-ref url="/pages/lxn9i0DXXmY8dD3Tn7N7" %}
[Flight Controllers](/products/flight-controller)
{% endcontent-ref %}

{% content-ref url="/pages/vxg0q0V2mrI3X3f9KOSO" %}
[ESCs](/products/electronic-speed-controller)
{% endcontent-ref %}

{% content-ref url="/pages/8Y6RUsSBLbEKsLZVfx3h" %}
[Radios](/products/radio)
{% endcontent-ref %}

{% content-ref url="/pages/bLkF6HeVkoY5REUrNiFR" %}
[Sensors](/products/sensor)
{% endcontent-ref %}

{% content-ref url="/pages/ZW5H67lpP8TVZh1ivU0N" %}
[GPS](/products/gps)
{% endcontent-ref %}

{% content-ref url="/pages/9vJfny2gwzbvpcXllkH2" %}
[Power Modules](/products/power)
{% endcontent-ref %}

{% content-ref url="/pages/8BOqrxpN7NzHvR6k1Eba" %}
[IMUs](/products/imu)
{% endcontent-ref %}

{% content-ref url="/pages/ARxUtSQRs8ixeaFjsrEs" %}
[Accessories](/products/accessories)
{% endcontent-ref %}

{% content-ref url="/pages/z8oq9amdLqtf04oIEfDv" %}
[Airframes](/products/airframes)
{% endcontent-ref %}

{% content-ref url="/pages/sMVc60WefCOLazj3ZOME" %}
[ROS2 & PX4](/tutorials/ros2-and-px4)
{% endcontent-ref %}

{% content-ref url="/pages/boq7xpQCr7sGcBSU00iB" %}
[Radio Integration](/tutorials/radio-integration)
{% endcontent-ref %}

***

{% embed url="<https://arkelectron.com/>" %}
Webshop
{% endembed %}

{% embed url="<https://www.linkedin.com/company/ark-electronics-llc>" %}

<https://x.com/ARK_Electr0nics>


# Knowledge Base

Core concepts for working with ARK products, drone electronics, and embedded systems.

Reference pages covering core concepts for working with ARK products, drone electronics, and embedded systems.

{% content-ref url="/pages/ouMhukhelnOtJ32K0REZ" %}
[Microcontrollers](/knowledge-base/knowledge-base/microcontrollers)
{% endcontent-ref %}

{% content-ref url="/pages/dGUaOFVox2UtlbAw5Hqe" %}
[SWD Programming](/knowledge-base/knowledge-base/swd-programming)
{% endcontent-ref %}

{% content-ref url="/pages/k32VFyNfiBsHUDZCRczD" %}
[Serial Communication (UART)](/knowledge-base/knowledge-base/serial-communication-uart)
{% endcontent-ref %}

{% content-ref url="/pages/SL1pjYhfqE9YGKcw5UKE" %}
[CAN Bus](/knowledge-base/knowledge-base/can-bus)
{% endcontent-ref %}

{% content-ref url="/pages/4BbCZEqLQXpKEBNEgn4W" %}
[MAVLink](/knowledge-base/knowledge-base/mavlink)
{% endcontent-ref %}

{% content-ref url="/pages/LpJfs7RXdbAWX6WCbaaq" %}
[Connectors and Wiring](/knowledge-base/knowledge-base/connectors-and-wiring)
{% endcontent-ref %}

{% content-ref url="/pages/vir7X6J3wxfEUbNdprFF" %}
[Power and Grounding](/knowledge-base/knowledge-base/power-and-grounding)
{% endcontent-ref %}

{% content-ref url="/pages/LRLfP0DLR4dtkgEoZ6Rr" %}
[GPS Placement](/knowledge-base/knowledge-base/gps-placement)
{% endcontent-ref %}

{% content-ref url="/pages/ErcnVraCVi7cI3Pya3Sz" %}
[Communication Buses (I2C, SPI)](/knowledge-base/knowledge-base/communication-buses)
{% endcontent-ref %}

{% content-ref url="/pages/GV2RV5izsoBJE8mBB2Hk" %}
[Recommended Tools](/knowledge-base/knowledge-base/recommended-tools)
{% endcontent-ref %}

{% content-ref url="/pages/vARfEK4UNX5azdeGTN7c" %}
[ST-LINK Flashing Guide](/knowledge-base/knowledge-base/st-link-flashing-guide)
{% endcontent-ref %}

{% content-ref url="/pages/tB18bYz9kWARWJ45zruc" %}
[DroneCAN GUI Tool Guide](/knowledge-base/knowledge-base/dronecan-gui-tool-guide)
{% endcontent-ref %}

{% content-ref url="/pages/teQGD4TM8fftXJ2bdhKZ" %}
[PX4 Log Encryption](/knowledge-base/knowledge-base/px4-log-encryption)
{% endcontent-ref %}


# Microcontrollers

What microcontrollers are, the STM32 family, firmware vs bootloaders, and the NuttX RTOS.

## What is a Microcontroller?

A microcontroller (MCU) is a small computer on a single chip. It contains a processor, memory, and input/output peripherals all in one package. Unlike a full computer (like a Raspberry Pi or Jetson), an MCU has no operating system by default, runs a single firmware image, and boots in milliseconds.

Microcontrollers are the core of nearly every ARK product. They read sensors, drive outputs, and handle communication buses — all in real time.

## How It Works

### The STM32 Family

ARK products use STM32 microcontrollers from STMicroelectronics. These are ARM Cortex-M based chips that are widely used in the drone industry.

| Series  | Core      | Example MCU   | Used In                        |
| ------- | --------- | ------------- | ------------------------------ |
| STM32F4 | Cortex-M4 | STM32F412CGU6 | ARK CANnode, ARK Flow, ARK MAG |
| STM32H7 | Cortex-M7 | STM32H743     | ARKV6X, ARK FPV                |

Key characteristics of STM32 MCUs:

* **Flash memory** — stores firmware persistently (survives power cycles)
* **SRAM** — working memory for runtime data (lost on power off)
* **Hardware peripherals** — UART, SPI, I2C, CAN, timers, ADC, and more are built into the chip
* **Clock speeds** — typically 100–480 MHz depending on the series

### Firmware vs Bootloader

An MCU runs two distinct pieces of software:

* **Bootloader** — a small program that lives at the start of flash memory. It runs first on power-up and decides whether to enter firmware update mode or jump to the main firmware. On ARK DroneCAN products, the bootloader enables firmware updates via CAN bus.
* **Firmware** — the main application. For flight controllers this is PX4 or ArduPilot. For DroneCAN sensors it is a PX4 CANnode build or AP\_Periph build.

The bootloader is flashed once (usually via [SWD](/knowledge-base/knowledge-base/swd-programming)) and rarely changes. Firmware is updated regularly as new versions are released.

### NuttX RTOS

PX4 runs on top of **NuttX**, a real-time operating system (RTOS). NuttX provides:

* A POSIX-like environment (file-based device access, shell commands)
* Task scheduling with deterministic timing
* Device drivers for STM32 peripherals

When you connect to the [debug console](/knowledge-base/knowledge-base/serial-communication-uart), you are interacting with the NuttX shell (NSH). You can list running tasks, read sensor data, and set parameters directly.

## How ARK Products Use It

* **Flight controllers** ([ARKV6X](/products/flight-controller/arkv6x), [ARK FPV](/products/flight-controller/ark-fpv)) run PX4 or ArduPilot on STM32H7 MCUs, handling sensor fusion, control loops, and communication at hundreds of Hz.
* **DroneCAN sensors** ([ARK CANnode](/products/sensor/ark-cannode), [ARK Flow](/products/sensor/ark-flow), [ARK MAG](/products/sensor/ark-mag)) run lightweight firmware on STM32F4 MCUs, reading a sensor and publishing data over [CAN bus](/knowledge-base/knowledge-base/can-bus).
* **ESCs** ([ARK 4IN1 ESC](/products/electronic-speed-controller/ark-4in1-esc)) use STM32F0 MCUs running AM32 open source firmware for motor control.

## Common Pitfalls

* **Flashing the wrong firmware** — each MCU variant needs a firmware binary compiled specifically for it. An ARKV6X binary will not run on an ARK FPV, even though both use STM32H7 chips.
* **Forgetting the bootloader** — DroneCAN nodes need a bootloader flashed via SWD before they can accept firmware updates over CAN. If the bootloader is missing or corrupted, the node will not appear on the bus.
* **Confusing flash and SRAM** — parameters stored in flash persist across reboots. A mass erase (`st-flash erase`) wipes everything, including saved parameters.

## Further Reading

* [STM32 Product Page](https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html)
* [NuttX Documentation](https://nuttx.apache.org/docs/latest/)
* [PX4 Autopilot Architecture](https://docs.px4.io/main/en/concept/architecture.html)
* [SWD Programming](/knowledge-base/knowledge-base/swd-programming) — how to flash firmware onto an MCU


# SWD Programming

What SWD is, how it works, what hardware you need, and when to use it.

## What is SWD?

SWD (Serial Wire Debug) is a two-wire debug and programming interface for ARM microcontrollers. It lets you flash firmware, set breakpoints, inspect memory, and access a debug console — all through a physical connection to the chip.

Every ARK product with an STM32 [microcontroller](/knowledge-base/knowledge-base/microcontrollers) exposes SWD through a debug connector. It is the most reliable way to flash firmware and the only way to recover a board with a corrupted bootloader.

## How It Works

SWD uses two signals plus ground:

| Signal | Name                 | Direction      | Purpose                                |
| ------ | -------------------- | -------------- | -------------------------------------- |
| SWDIO  | Serial Wire Data I/O | Bidirectional  | Data transfer between debugger and MCU |
| SWCLK  | Serial Wire Clock    | Debugger → MCU | Clock signal driven by the debugger    |
| GND    | Ground               | —              | Common reference                       |

The debugger (e.g., ST-LINK) connects to the MCU's internal debug port, giving it direct access to flash memory, registers, and peripherals. This works even if the firmware is completely broken — SWD operates at the hardware level, below any software.

### What You Need

* [**ST-LINK V3 Mini**](https://www.digikey.com/en/products/detail/stmicroelectronics/STLINK-V3MINIE/16284301) — programmer/debugger that connects to your computer via USB. The V3 Mini is recommended because it also provides a virtual serial port for [UART debug console](/knowledge-base/knowledge-base/serial-communication-uart) access through the same USB connection.
* [**ARK Pixhawk Debug Adapter**](https://arkelectron.com/product/ark-pixhawk-debug-adapter/) — routes the ST-LINK's STDC14 connector to the Pixhawk Standard 6-pin or 10-pin JST-SH debug connector found on ARK boards. Includes debug cables.

The connection chain looks like this:

```
Computer ↔ USB ↔ ST-LINK V3 Mini ↔ STDC14 Cable ↔ ARK Debug Adapter ↔ JST-SH Cable ↔ Board Debug Port
```

### When to Use SWD

Most firmware updates don't require SWD. The day-to-day methods depend on the type of board:

* **Flight controllers** (ARKV6X, ARK FPV, etc.) — firmware is typically loaded via QGroundControl over USB. SWD is not needed for routine updates.
* **DroneCAN nodes** (ARK CANnode, ARK Flow, ARK MAG, etc.) — the flight controller pushes firmware from its SD card to the node over the [CAN bus](/knowledge-base/knowledge-base/can-bus), or you can use the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) directly. This is the normal update path once a bootloader is installed.
* **USB DFU** — a fallback used on some boards (like the [ARK FPV](/products/flight-controller/ark-fpv)) to flash a bootloader over USB when the board is placed into DFU mode. Rarely needed.

SWD is for situations where none of the above work:

* **Initial bootloader flash** — a brand-new or factory-fresh DroneCAN node has no bootloader. SWD is the only way to install one so the node can accept CAN firmware updates going forward.
* **Recovery** — if a bootloader becomes corrupted or a bad firmware flash leaves the board unresponsive, SWD can overwrite flash directly and bring it back.
* **Development and debugging** — SWD lets you set breakpoints, step through code, and inspect memory. Not required for firmware development, but useful when you need it.

SWD operates at the hardware level, below any software on the chip. As long as the board is not physically damaged, SWD can recover it — regardless of the state of the bootloader or firmware.

## Debug Connector Pinouts

ARK products use one of two **Pixhawk Standard Debug Connectors** (both JST-SH). The [ARK Pixhawk Debug Adapter](https://arkelectron.com/product/ark-pixhawk-debug-adapter/) includes cables for both.

### 6-Pin Debug Connector

Used on most ARK DroneCAN sensors and smaller boards.

| Pin | Signal  | Voltage |
| --- | ------- | ------- |
| 1   | 3.3V    | 3.3V    |
| 2   | UART TX | 3.3V    |
| 3   | UART RX | 3.3V    |
| 4   | SWDIO   | 3.3V    |
| 5   | SWCLK   | 3.3V    |
| 6   | GND     | GND     |

### 10-Pin Debug Connector

Used on flight controllers like the [ARKV6X](/products/flight-controller/arkv6x). Adds a second UART and reset line.

| Pin | Signal                   | Voltage |
| --- | ------------------------ | ------- |
| 1   | 3.3V                     | 3.3V    |
| 2   | UART5 TX (Debug Console) | 3.3V    |
| 3   | UART5 RX (Debug Console) | 3.3V    |
| 4   | FMU SWDIO                | 3.3V    |
| 5   | FMU SWCLK                | 3.3V    |
| 6   | SWO                      | 3.3V    |
| 7   | IO SWDIO                 | 3.3V    |
| 8   | IO SWCLK                 | 3.3V    |
| 9   | nRST                     | 3.3V    |
| 10  | GND                      | GND     |

## Software Setup

Install the stlink tools from source for the most up-to-date version with the best device support:

```bash
sudo apt install build-essential cmake libusb-1.0-0-dev
git clone https://github.com/stlink-org/stlink.git
cd stlink
cmake .
make
sudo make install
sudo ldconfig
```

{% hint style="info" %}
**Prefer building from source** over `sudo apt install stlink-tools`. The packaged version in most distributions is outdated and may not support newer STM32 chips or ST-LINK firmware versions. See the [stlink-org/stlink GitHub page](https://github.com/stlink-org/stlink) for full build instructions and troubleshooting.
{% endhint %}

If you encounter permission errors after installation, add your user to the `dialout` group:

```bash
sudo usermod -aG dialout $USER
```

Log out and back in for the change to take effect.

## Common Pitfalls

* **Skipping the debug adapter** — the ST-LINK's STDC14 connector does not directly plug into the JST-SH debug port on ARK boards. You need the ARK Pixhawk Debug Adapter or manual wiring.
* **Wrong bootloader for the firmware stack** — PX4 CAN nodes need the PX4 `canbootloader`, and AP\_Periph nodes need the ArduPilot CAN bootloader. Flashing the wrong bootloader means the node won't accept firmware updates over CAN. If a node isn't picking up firmware, check which bootloader is installed.
* **Wrong flash address** — STM32 flash starts at `0x08000000`, but that is the bootloader's address on a DroneCAN node. The node application lives at `0x08010000` on ARK CAN nodes, and writing it to `0x08000000` wipes the bootloader. The flash reports success either way. Flashing the combined bootloader + application image (`AP_Periph_with_bl.hex`) avoids the problem entirely — see the [ST-LINK Flashing Guide](/knowledge-base/knowledge-base/st-link-flashing-guide#flashing-dronecan-nodes).
* **Outdated stlink tools** — the version from `apt install stlink-tools` is often too old to recognize newer STM32 chips or ST-LINK firmware. Build from source (see [Software Setup](#software-setup) above).
* **Powering conflicts** — the ST-LINK can supply 3.3V to the target. If the board is already powered externally, this is usually fine, but avoid powering high-current peripherals through the debug connector.

## Further Reading

* [ST-LINK Flashing Guide](/knowledge-base/knowledge-base/st-link-flashing-guide) — step-by-step flashing procedure for ARK products
* [ARM SWD Protocol Overview](https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port--SW-DP-)
* [stlink-org/stlink on GitHub](https://github.com/stlink-org/stlink) — open source ST-LINK tools


# Serial Communication (UART)

UART basics, RX/TX cross-wiring, baud rates, and using the debug console.

## What is UART?

UART (Universal Asynchronous Receiver/Transmitter) is a simple serial communication protocol used to send data between two devices over two wires. It is the most common way to access the debug console on a flight controller, connect GPS modules, and link telemetry radios.

Unlike [SPI or I2C](/knowledge-base/knowledge-base/communication-buses), UART is point-to-point — it connects exactly two devices with no shared bus or addressing.

## How It Works

### Signals

A UART connection uses two data lines plus ground:

| Signal | Purpose                                |
| ------ | -------------------------------------- |
| TX     | Transmit — data output from the device |
| RX     | Receive — data input to the device     |
| GND    | Common ground reference                |

### RX/TX Cross-Wiring

This is the single most common wiring mistake in drone electronics: **TX on one device connects to RX on the other, and vice versa.**

```
Device A          Device B
  TX  ──────────→  RX
  RX  ←──────────  TX
  GND ────────────  GND
```

One device's transmit line must feed into the other device's receive line. If you connect TX to TX, neither device hears anything.

{% hint style="warning" %}
**The #1 UART debugging step:** if you get no data, swap TX and RX. This fixes the problem more often than not.
{% endhint %}

### Baud Rate

Both devices must agree on the same data speed, called the **baud rate** (bits per second). If the baud rates don't match, the receiving device sees garbage characters.

Common baud rates in the ARK/PX4 ecosystem:

| Baud Rate | Typical Use                                                   |
| --------- | ------------------------------------------------------------- |
| 9600      | Some GPS modules (default)                                    |
| 57600     | PX4 debug console (NuttX shell)                               |
| 115200    | MAVLink telemetry, some GPS modules                           |
| 921600    | High-speed MAVLink, companion computer links (see note below) |

{% hint style="warning" %}
**921600 baud and above requires hardware flow control** (CTS/RTS) unless the UART connection is very short (PCB-to-PCB, like the on-board link between the Jetson and flight controller on the [ARK Jetson PAB Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier)). Over cables of any significant length, data will be lost at these speeds without flow control. If you must run high baud rates over a cable, use a TELEM port with CTS/RTS lines connected.
{% endhint %}

### Data Format

UART data is typically configured as **8N1**:

* **8** data bits
* **N**o parity
* **1** stop bit

This is the default on virtually all PX4 and ArduPilot peripherals. You almost never need to change it.

## How ARK Products Use It

### Debug Console

Every ARK board with a debug connector exposes a UART on pins 2 (TX) and 3 (RX) of the [Pixhawk Standard Debug Connector](/knowledge-base/knowledge-base/connectors-and-wiring). Connecting to this UART at 57600 baud gives you the NuttX shell (PX4), where you can:

* View boot messages and error logs
* Run diagnostic commands (`sensors status`, `listener sensor_accel`)
* Set parameters directly

The easiest way to access the debug console is with an [ST-LINK V3 Mini and ARK Debug Adapter](/knowledge-base/knowledge-base/st-link-flashing-guide), which provides both SWD and UART through a single USB connection.

### GPS Modules

ARK GPS modules ([ARK SAM GPS](/products/gps/ark-sam-gps), [ARK DAN GPS](/products/gps/ark-dan-gps)) that support non-CAN connections use UART to send position data to the flight controller. The flight controller's GPS port provides a UART with the Pixhawk Standard pinout.

### Telemetry

MAVLink telemetry between a flight controller and a ground station radio uses UART. The flight controller's TELEM ports are UART interfaces running MAVLink at 57600 or 115200 baud by default.

### Companion Computers

The [ARK Jetson PAB Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier) and [ARK Pi6X Flow](/products/flight-controller/ark-pi6x-flow) use UART connections between the companion computer and the flight controller MCU for MAVLink or XRCE-DDS communication.

## Common Pitfalls

* **TX and RX swapped** — see [RX/TX Cross-Wiring](#rxtx-cross-wiring) above. Always the first thing to check.
* **Baud rate mismatch** — if you see garbled characters instead of readable text, double-check that both ends are set to the same baud rate. The PX4 debug console is 57600, not 115200.
* **Missing common ground** — UART signals are referenced to ground. If two devices don't share a common ground, communication will be unreliable or fail entirely.
* **Voltage mismatch** — STM32 UART signals are 3.3V. Connecting directly to a 5V device (like some Arduino boards) can damage the MCU. Use a level shifter if needed.
* **Long or untwisted wires** — UART signals degrade over distance. Keep cables as short as possible and use twisted pairs (TX with GND, RX with GND) to reject noise. Runs over 15–20 cm at 115200 baud or above become unreliable without twisted wires, especially on a drone with motors running.
* **Port already in use** — on Linux, if `screen` or another terminal is already connected to a serial port, a second connection will fail silently. Kill existing sessions before reconnecting.
* **Not using an oscilloscope** — if UART isn't working and you've checked TX/RX wiring and baud rate, connect an oscilloscope to the TX and RX lines. This immediately tells you whether the signal is present, at the right voltage level, and clean. It also catches bad solder joints, broken traces, and damaged connectors that are invisible to the eye.

## Further Reading

* [ST-LINK Flashing Guide — UART Debug Console](/knowledge-base/knowledge-base/st-link-flashing-guide#uart-debug-console) — step-by-step instructions for connecting to the debug console
* [PX4 System Console](https://docs.px4.io/main/en/debug/system_console.html)
* [Communication Buses (I2C, SPI)](/knowledge-base/knowledge-base/communication-buses) — comparison of UART with other protocols


# CAN Bus

CAN bus fundamentals, differential signaling, termination, DroneCAN protocol, and 4-pin JST-GH wiring.

## What is CAN Bus?

CAN (Controller Area Network) is a robust communication bus designed for noisy environments. Originally developed for automobiles, it is the standard for connecting sensors, GPS modules, and other peripherals in the Pixhawk drone ecosystem.

CAN uses **differential signaling** over a twisted pair, which makes it highly resistant to electromagnetic interference — critical on a drone where motors, ESCs, and radios generate significant noise.

## How It Works

### Differential Signaling

CAN uses two wires, **CAN\_H** (high) and **CAN\_L** (low), that carry the same signal in opposite polarities. The receiver reads the *difference* between the two, which cancels out any noise that affects both wires equally.

| Bus State     | CAN\_H | CAN\_L | Difference |
| ------------- | ------ | ------ | ---------- |
| Recessive (1) | 2.5V   | 2.5V   | 0V         |
| Dominant (0)  | 3.5V   | 1.5V   | 2V         |

This is why CAN is so much more reliable than [UART](/knowledge-base/knowledge-base/serial-communication-uart) or [I2C](/knowledge-base/knowledge-base/communication-buses) in electrically noisy environments.

### Bus Topology

CAN is a true **multi-drop bus** — all devices share the same two wires. Any device can transmit, and all devices receive every message. Message priority is handled by arbitration built into the protocol.

```
[Flight Controller] ──── CAN_H/CAN_L ──── [GPS] ──── [Flow Sensor] ──── [Mag]
       120Ω                                                               120Ω
```

Devices are daisy-chained, with two 120-ohm termination resistors at each end of the bus.

### Termination

A CAN bus requires a **120-ohm termination resistor** at each physical end of the bus. Without proper termination, signal reflections corrupt data and cause intermittent communication failures.

Most ARK DroneCAN products have a software-configurable built-in termination resistor controlled by the `CANNODE_TERM` parameter. Only the two devices at the physical ends of the bus should have termination enabled.

{% hint style="info" %}
**Rule of thumb:** if you measure the resistance between CAN\_H and CAN\_L with everything powered off, you should see approximately 60 ohms (two 120-ohm resistors in parallel).
{% endhint %}

### Bit Rate

The Pixhawk standard CAN bit rate is **1 Mbps** (1000000 bps). This is the default for PX4, ArduPilot, and all ARK DroneCAN devices. Unlike UART, you almost never need to change the CAN bit rate.

### 4-Pin JST-GH Connector (Pixhawk Standard CAN)

All ARK DroneCAN products use the Pixhawk Standard CAN connector:

| Pin | Signal | Voltage |
| --- | ------ | ------- |
| 1   | 5V     | 5.0V    |
| 2   | CAN\_H | —       |
| 3   | CAN\_L | —       |
| 4   | GND    | GND     |

Devices are connected in a daisy chain using these 4-pin JST-GH cables. Most ARK DroneCAN products have **two CAN connectors** so you can chain one into the next without a splitter.

### DroneCAN Protocol

DroneCAN (formerly UAVCAN v0) is the application-layer protocol that runs on top of CAN bus. It defines standard message types for sensor data, firmware updates, parameter configuration, and node management.

Key DroneCAN concepts:

* **Node ID** — each device on the bus has a unique ID (1–127). PX4 and ArduPilot assign these automatically by default.
* **Message types** — [standardized data structures](https://dronecan.github.io/Specification/7._List_of_standard_data_types/) (e.g., `uavcan.equipment.ahrs.RawIMU`, `uavcan.equipment.gnss.Fix2`) that all compliant devices understand.
* **Dynamic node allocation** — devices can obtain a node ID automatically from the flight controller on first boot.
* **Firmware update** — the flight controller or a tool like the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) can push firmware updates to any node on the bus.

## Common Pitfalls

* **Missing termination** — the most common CAN issue. If devices appear and disappear intermittently, check that exactly two nodes have termination enabled (one at each end of the bus).
* **All nodes terminated** — enabling termination on every device drops the bus resistance too low, causing signal distortion. Only the two end nodes should be terminated.
* **Wrong bit rate** — all devices must use the same bit rate (1 Mbps). A device configured for a different rate will be invisible on the bus.
* **Node ID conflicts** — two devices with the same node ID will interfere with each other. Dynamic node allocation usually prevents this, but manually assigned IDs can collide.
* **Cable length** — CAN is robust but not unlimited. For runs over 1 meter, use quality twisted-pair cable and ensure proper termination.
* **5V power through CAN** — the CAN connector provides 5V power. If a device draws too much current through the cable, the voltage can drop below the minimum for reliable operation. Check the power budget for your bus.

## Further Reading

* [DroneCAN GUI Tool Guide](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) — how to inspect, configure, and update firmware on DroneCAN devices
* [PX4 DroneCAN Documentation](https://docs.px4.io/main/en/dronecan/)
* [PX4 CAN Wiring Guide](https://docs.px4.io/main/en/can/#wiring)
* [DroneCAN Specification](https://dronecan.github.io/Specification/)
* [Connectors and Wiring](/knowledge-base/knowledge-base/connectors-and-wiring) — details on the JST-GH connectors used for CAN


# MAVLink

What MAVLink is, how ground stations and companion computers communicate with the flight controller, and MAVLink vs XRCE-DDS.

## What is MAVLink?

MAVLink (Micro Air Vehicle Link) is a lightweight messaging protocol for communicating with and between drones. It is the standard protocol used by ground control stations (like QGroundControl and Mission Planner) to talk to flight controllers running PX4 or ArduPilot.

MAVLink handles everything from live telemetry and parameter configuration to mission uploads and command execution.

## How It Works

### Messages and Packets

MAVLink defines hundreds of standardized message types. Each message has a numeric ID and a fixed set of fields. Messages are wrapped in packets that include source and destination addresses, sequence numbers, and checksums.

Common message categories:

| Category      | Examples                               | Purpose                        |
| ------------- | -------------------------------------- | ------------------------------ |
| Telemetry     | `HEARTBEAT`, `ATTITUDE`, `GPS_RAW_INT` | Live vehicle state             |
| Commands      | `COMMAND_LONG`, `COMMAND_INT`          | Arm, takeoff, set mode, reboot |
| Parameters    | `PARAM_REQUEST_LIST`, `PARAM_SET`      | Read and write configuration   |
| Missions      | `MISSION_ITEM_INT`, `MISSION_COUNT`    | Upload and download waypoints  |
| File Transfer | `FILE_TRANSFER_PROTOCOL`               | Log download, firmware update  |

### System and Component IDs

Every device on a MAVLink network has a **system ID** (identifies the vehicle) and a **component ID** (identifies a specific part of that vehicle, like the autopilot, gimbal, or companion computer).

* The flight controller is typically system ID 1, component ID 1
* A ground station is usually system ID 255
* A companion computer might be system ID 1, component ID 191

### Transport Layers

MAVLink is transport-agnostic — it doesn't care how the bytes get from A to B. Common transports:

| Transport                                                               | Use Case                                             |
| ----------------------------------------------------------------------- | ---------------------------------------------------- |
| [UART](/knowledge-base/knowledge-base/serial-communication-uart) serial | Telemetry radios, direct FC-to-companion links       |
| UDP                                                                     | Ethernet/Wi-Fi connections (QGC default: port 14550) |
| TCP                                                                     | Stable connections over network links                |
| USB                                                                     | Direct QGC connection to flight controller           |

### MAVLink Versions

* **MAVLink v1** — original protocol, 8 bytes overhead per message
* **MAVLink v2** — current standard, supports message signing, extensible fields, and 16-bit message IDs. PX4 and ArduPilot both default to v2.

## MAVLink vs XRCE-DDS

PX4 supports two protocols for companion computer communication:

|                | MAVLink                                                       | XRCE-DDS (uORB over DDS)                       |
| -------------- | ------------------------------------------------------------- | ---------------------------------------------- |
| **Maturity**   | Battle-tested, supported everywhere                           | Newer, actively evolving                       |
| **Ecosystem**  | QGC, Mission Planner, pymavlink, MAVSDK                       | ROS 2 native integration                       |
| **Data model** | Fixed message definitions                                     | PX4 uORB topics published as ROS 2 topics      |
| **Best for**   | GCS communication, telemetry radios, simple companion scripts | ROS 2 applications, high-bandwidth sensor data |
| **Transport**  | Serial, UDP, TCP                                              | Serial (Micro XRCE-DDS Agent)                  |

{% hint style="info" %}
**Which should I use?** If you're building a ROS 2 application on a companion computer, use XRCE-DDS — it gives you direct access to PX4's internal topics as ROS 2 messages. For everything else (GCS, telemetry, simple offboard control), MAVLink is the standard choice.
{% endhint %}

## How ARK Products Use It

### Ground Station Communication

Flight controllers like the [ARKV6X](/products/flight-controller/arkv6x) and [ARK FPV](/products/flight-controller/ark-fpv) use MAVLink to communicate with QGroundControl or Mission Planner over USB, telemetry radio, or network connections.

### Companion Computer Links

The [ARK Jetson PAB Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier) and [ARK Pi6X Flow](/products/flight-controller/ark-pi6x-flow) use both MAVLink and XRCE-DDS for communication between the companion computer (Jetson or Pi) and the integrated flight controller:

* **MAVLink** — used by the [QGroundControl connection](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os/autopilot-connections/qgroundcontrol-connection) and [MissionPlanner connection](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os/autopilot-connections/missionplanner-ardupilot-connection) forwarded from the companion computer
* **XRCE-DDS** — used by [ROS 2 applications](/tutorials/ros2-and-px4/ros2-and-px4-teleop-example) running on the companion computer

### MAVCAN

Ardupilot supports MAVLink can tunnel [CAN bus](/knowledge-base/knowledge-base/can-bus) traffic over any MAVLink link using the MAVCAN protocol. This lets you use the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) to manage CAN devices remotely — even over a telemetry radio link. PX4 does not yet support this.

## Common Pitfalls

* **Baud rate mismatch** — MAVLink over serial requires matching baud rates on both ends. PX4 TELEM ports default to 57600 baud. If QGC shows "Communication Lost," check the baud rate first.
* **Same port, multiple connections** — only one application can open a serial port at a time. If MAVProxy is already connected, QGC cannot connect to the same port.
* **Firewall blocking UDP** — QGC listens on UDP port 14550 by default. Firewalls or VPNs can block these packets silently.
* **System ID conflicts** — if two vehicles share the same system ID on the same network, the GCS will merge their telemetry into a confusing mess. Each vehicle needs a unique system ID.
* **MAVLink vs XRCE-DDS confusion** — these are separate protocols on separate interfaces. You cannot connect QGC to an XRCE-DDS port or subscribe to ROS 2 topics over MAVLink.
* **Baudrate and throughput** — Ensure the baudrate is high enough for the configured mavlink throughput. Baudrates at or above 921600 tend to only work with very short wires, otherwise hardware flow control must be used.

## Further Reading

* [MAVLink Developer Guide](https://mavlink.io/en/)
* [PX4 MAVLink Documentation](https://docs.px4.io/main/en/middleware/mavlink.html)
* [PX4 XRCE-DDS (ROS 2)](https://docs.px4.io/main/en/middleware/uxrce_dds.html)
* [QGroundControl User Guide](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/getting_started/quick_start.html)
* [MAVSDK — MAVLink SDK](https://mavsdk.mavlink.io/main/en/)


# Connectors and Wiring

JST-GH vs JST-SH connectors, wire color conventions, Pixhawk standard pinouts, and cable kits.

## What Are JST Connectors?

JST connectors are the small locking connectors used on virtually all Pixhawk-ecosystem flight controllers and peripherals. The **Pixhawk Connector Standard** specifies two JST connector families for different purposes:

| Connector  | Pitch   | Use                                                      | Found On                  |
| ---------- | ------- | -------------------------------------------------------- | ------------------------- |
| **JST-GH** | 1.25 mm | Peripheral connections (CAN, I2C, UART, SPI, GPS, power) | All main board connectors |
| **JST-SH** | 1.0 mm  | Debug connections (SWD + UART console)                   | Debug ports only          |

Both are polarized locking connectors — they only plug in one way and click into place.

## How It Works

### Pixhawk Standard Pinouts

The Pixhawk Connector Standard defines pin assignments for each connector type. This means an ARK GPS plugs into any Pixhawk-compatible flight controller without custom wiring.

#### CAN — 4-Pin JST-GH

| Pin | Signal | Color  |
| --- | ------ | ------ |
| 1   | 5V     | Red    |
| 2   | CAN\_H | Yellow |
| 3   | CAN\_L | Green  |
| 4   | GND    | Black  |

Used by all ARK [DroneCAN](/knowledge-base/knowledge-base/can-bus) peripherals. See [CAN Bus](/knowledge-base/knowledge-base/can-bus) for protocol details.

#### I2C — 4-Pin JST-GH

| Pin | Signal | Color  |
| --- | ------ | ------ |
| 1   | 5V     | Red    |
| 2   | SCL    | Yellow |
| 3   | SDA    | Green  |
| 4   | GND    | Black  |

Used by [I2C devices](/knowledge-base/knowledge-base/communication-buses) like external magnetometers and barometers.

#### UART/I2C (Basic GPS) — 6-Pin JST-GH

| Pin | Signal | Color  |
| --- | ------ | ------ |
| 1   | 5V     | Red    |
| 2   | TX     | Yellow |
| 3   | RX     | Green  |
| 4   | SCL    | Blue   |
| 5   | SDA    | Orange |
| 6   | GND    | Black  |

Combined UART and I2C port, typically used for GPS modules with a compass.

#### TELEM — 6-Pin JST-GH

| Pin | Signal | Color  |
| --- | ------ | ------ |
| 1   | 5V     | Red    |
| 2   | TX     | Yellow |
| 3   | RX     | Green  |
| 4   | CTS    | Blue   |
| 5   | RTS    | Orange |
| 6   | GND    | Black  |

Used for [MAVLink](/knowledge-base/knowledge-base/mavlink) telemetry connections with hardware flow control.

#### Debug — 6-Pin JST-SH

| Pin | Signal  |
| --- | ------- |
| 1   | 3.3V    |
| 2   | UART TX |
| 3   | UART RX |
| 4   | SWDIO   |
| 5   | SWCLK   |
| 6   | GND     |

Used for [SWD programming](/knowledge-base/knowledge-base/swd-programming) and [debug console](/knowledge-base/knowledge-base/serial-communication-uart) access.

### Wire Color Conventions

Pixhawk standard cables follow a consistent color scheme:

| Color      | Typical Signal                               |
| ---------- | -------------------------------------------- |
| **Red**    | Power (5V or 3.3V) — always pin 1            |
| **Black**  | Ground (GND) — always last pin               |
| **Yellow** | First data signal (CAN\_H, TX, SCL)          |
| **Green**  | Second data signal (CAN\_L, RX, SDA)         |
| **Blue**   | Third data signal (CTS, SCL on combo ports)  |
| **Orange** | Fourth data signal (RTS, SDA on combo ports) |

{% hint style="info" %}
**Power is always pin 1 (red), ground is always the last pin (black).** This is consistent across all Pixhawk Standard connectors and makes visual inspection easy.
{% endhint %}

### Cable Kits

If you need additional or custom-length cables, these pre-crimped kits include connectors and wires ready to assemble (no crimping tool required):

* **JST-GH 1.25 mm**: [GH1.25 Connectors Kit on Amazon](https://www.amazon.com/Pre-Crimped-Connectors-Pixhawk2-Pixracer-Silicone/dp/B07PBHN7TM)
* **JST-SH 1.0 mm**: [JST SH 1.0mm Connector Kit on Amazon](https://www.amazon.com/Teansic-Connector-Pre-Crimped-Housing-Controller/dp/B0D5X6BY5Z)
* **JST-GH 1.25 mm to JST-SH 1.0 mm**: [GH1.25 to SH1.0 Connector Kit on Amazon](https://www.amazon.com/dp/B0D2SVX4S4)

## Common Pitfalls

* **JST-GH and JST-SH are not interchangeable** — they look similar but have different pitches (1.25 mm vs 1.0 mm). Forcing the wrong connector will damage the socket.
* **Inserting cables backwards** — JST connectors are keyed, but enough force can overcome the key. Always check orientation by the latch, not by pushing harder.
* **Pulling on wires instead of the connector** — grip the plastic housing when disconnecting, not the wires. The wires will pull out of the crimps.
* **Missing the latch click** — if the connector doesn't click, it is not seated. A partially inserted connector makes intermittent contact, causing random disconnects.
* **Assuming wire colors match between vendors** — not all cable manufacturers follow the Pixhawk color standard. When in doubt, check the pinout for your specific product.

## Further Reading

* [Pixhawk Connector Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf)
* [PX4 Wiring Quick Start](https://docs.px4.io/main/en/assembly/)
* [CAN Bus](/knowledge-base/knowledge-base/can-bus) — CAN bus protocol and wiring details
* [SWD Programming](/knowledge-base/knowledge-base/swd-programming) — debug connector usage


# Power and Grounding

Voltage levels, power distribution, ground loops, signal integrity, and noise avoidance on drones.

## What is Power Distribution?

Every component on a drone — flight controller, sensors, GPS, companion computer, radio — needs clean, stable power at the correct voltage. Power distribution is how you get the right voltage to the right place while keeping electrical noise from corrupting sensor readings and communication buses.

Getting this right is the difference between a drone that flies reliably and one that suffers mysterious glitches.

## How It Works

### Voltage Levels

Drones deal with multiple voltage levels simultaneously:

| Voltage                                 | Source                       | Powers                                          |
| --------------------------------------- | ---------------------------- | ----------------------------------------------- |
| **Battery voltage** (3S–6S, 11.1–25.2V) | LiPo battery                 | ESCs, motors                                    |
| **5V**                                  | BEC or power module          | Flight controller, CAN peripherals, GPS, radios |
| **3.3V**                                | On-board regulator (from 5V) | MCU logic, sensors, communication interfaces    |

The flight controller and all Pixhawk standard peripherals run on **5V** supplied through their connectors. The 5V rail is typically provided by a power module or a BEC (Battery Eliminator Circuit) that steps down the battery voltage.

The **3.3V** level is internal to each board — the MCU and sensors operate at 3.3V, but this is regulated on-board from the 5V input. You generally don't need to supply 3.3V externally.

### Power Module Role

ARK power modules ([ARK PAB Power Module](/products/power/ark-pab-power-module), [ARK 12S PAB Power Module](/products/power/ark-12s-pab-power-module)) do two things:

1. **Regulate** battery voltage down to clean 5V for the flight controller and peripherals
2. **Measure** battery voltage and current, reporting it to the flight controller over I2C.

### 5V Power Through CAN

On ARK systems, the [CAN bus](/knowledge-base/knowledge-base/can-bus) carries both data and power on the same cable. Pin 1 of every 4-pin JST-GH CAN connector is 5V. This means DroneCAN peripherals are powered through their CAN cable — no separate power wiring needed.

{% hint style="warning" %}
**Power budget matters.** Every device in the CAN daisy chain draws current through the same cables and connectors. If the total current draw exceeds what the source can provide, voltage will drop and devices will behave erratically. Check the current draw of each peripheral and ensure the power module or BEC can handle the total.
{% endhint %}

### Ground Loops

Ground is not an ideal zero-ohm conductor. Every wire and trace has finite resistance and inductance, so when current flows through a ground path it creates a small voltage drop. If two circuits share a ground path, the return current from one circuit creates noise that the other circuit sees. When multiple ground paths between devices form a closed loop, that loop also acts as an antenna — picking up and radiating electromagnetic interference proportional to the loop area.

On a drone, where ESCs are switching tens of amps at high frequency just centimeters from a GPS receiver trying to hear signals at -130 dBm, even microvolts of ground noise are enough to corrupt sensitive measurements.

**Use a star grounding topology.** In a star ground, every subsystem's ground return connects back to a single common point — typically at or near the battery/power supply return. This means:

* **No shared impedance** — each subsystem has its own dedicated ground return, so motor drive currents never flow through the IMU's ground path.
* **No loops between subsystems** — with only one path from each device to the common point, there is no closed loop to act as an antenna.
* **One unambiguous ground reference** — all voltages are measured with respect to the same point, eliminating ground potential differences between boards.

**Keep every current return path short.** Every current that flows out on a signal or power trace must return to its source, and that outgoing path plus return path form a loop. The radiated EMI and noise susceptibility of that loop is directly proportional to the enclosed area. Keeping return paths short and close to their signal paths minimizes this area. In practice: route ground returns parallel and adjacent to their signal or power traces, don't break ground planes under signal traces, and place decoupling capacitors as close to IC power pins as possible.

**Additional tips:**

* Avoid mounting electronics directly to a conductive (carbon fiber) frame without insulation — this creates unintended ground paths that form loops.
* Keep signal wires away from high-current motor wires to reduce inductive coupling.

For a deeper dive on grounding, see Analog Devices' [Staying Well Grounded](https://www.analog.com/en/resources/analog-dialogue/articles/staying-well-grounded.html) and TI's [PCB Design Guidelines for Reduced EMI](https://www.ti.com/lit/an/szza009/szza009.pdf).

### Signal Integrity and Noise

Digital communication buses ([CAN](/knowledge-base/knowledge-base/can-bus), [UART](/knowledge-base/knowledge-base/serial-communication-uart), [I2C, SPI](/knowledge-base/knowledge-base/communication-buses)) all depend on clean signal transitions. Electrical noise can corrupt these signals, causing:

* Intermittent sensor dropouts
* CAN bus errors or node disconnects
* Garbled serial console output
* I2C bus lockups

**Major noise sources on a drone:**

| Source             | Frequency                    | Affects                                                                    |
| ------------------ | ---------------------------- | -------------------------------------------------------------------------- |
| Motor commutation  | kHz–MHz                      | All buses, especially I2C and analog                                       |
| ESC switching      | 10–100 kHz                   | Power rail ripple, sensor noise                                            |
| USB                | 480 MHz (harmonics into GHz) | GPS reception — USB is a major source of RF interference in the L-band     |
| Radio transmitter  | GHz                          | Possible digital bus upset at close range                                  |
| High-current wires | DC–kHz                       | Magnetometer — motor wires and battery leads create strong magnetic fields |
| PWM servo signals  | 50–400 Hz                    | Ground bounce on shared connectors                                         |

**Noise reduction strategies:**

* Keep sensor cables short and routed away from motor/ESC/power wires
* Use shielded cables for long runs (>15 cm) on sensitive interfaces
* Ensure all connectors are fully seated — intermittent contacts cause noise
* Twist signal pairs to reduce pickup

### GPS Placement

GPS modules are particularly sensitive to both RF interference (which degrades satellite reception) and magnetic interference (which corrupts the built-in compass). Proper placement is critical for reliable position and heading data.

For detailed guidance on interference sources, mounting best practices, and common mistakes, see the dedicated [GPS Placement](/knowledge-base/knowledge-base/gps-placement) page.

### Servo and Actuator Power Isolation

Servos and other actuators with motors are among the worst power consumers on a drone. A stalled servo can draw several amps, and even normal operation causes large current spikes that collapse the voltage rail it shares with other devices.

{% hint style="warning" %}
**Never power servos from the same regulator as the flight controller.** A servo stall or jam can brown out the entire 5V rail, causing the flight controller and all CAN peripherals to reboot mid-flight. Always use a dedicated BEC for servos and actuators.
{% endhint %}

This applies to any high-current load: gimbal motors, LED arrays, radio amplifiers, or payload actuators. If it can draw more than a few hundred milliamps, give it its own power supply with only a shared ground to the flight controller.

## Common Pitfalls

* **Under-rated power supply** — a BEC that can handle bench testing may brown out under load when motors spin up. Size your power supply for worst-case current draw plus margin.
* **Ground loops through the frame** — carbon fiber frames are conductive. If two boards are bolted to the frame and also connected by a cable, you have a ground loop. Use nylon standoffs or insulating tape.
* **Long I2C runs** — I2C/Serial is highly susceptible to noise and capacitance. Runs longer than 10–15 cm are unreliable on a drone. Use [CAN bus](/knowledge-base/knowledge-base/can-bus) for any peripheral that isn't directly next to the flight controller.
* **Servos on the flight controller BEC** — see [Servo and Actuator Power Isolation](#servo-and-actuator-power-isolation) above. A stalled servo will take down your entire avionics power rail.
* **GPS mounted near USB or motor wires** — see [GPS Placement](/knowledge-base/knowledge-base/gps-placement). USB interference and magnetic fields from high-current wires are the two most common causes of poor GPS and compass performance.
* **Ignoring decoupling** — if you're building custom hardware, every IC needs 100 nF decoupling capacitors on its power pins. ARK products include these, but custom carrier boards sometimes omit them.
* **Assuming USB power is sufficient** — USB provides 5V but limited current (500 mA from USB 2.0). A flight controller may boot on USB power but behave erratically because peripherals are under-powered.

## Further Reading

* [PX4 Power Module Setup](https://docs.px4.io/main/en/power_module/)
* [CAN Bus](/knowledge-base/knowledge-base/can-bus) — CAN wiring and 5V power delivery
* [Connectors and Wiring](/knowledge-base/knowledge-base/connectors-and-wiring) — connector types and pinouts
* [Communication Buses (I2C, SPI)](/knowledge-base/knowledge-base/communication-buses) — bus noise susceptibility comparison


# GPS Placement

GPS module placement, interference sources, and mounting best practices for reliable satellite reception and compass accuracy.

## Why Placement Matters

ARK GPS modules do two jobs: receive satellite signals and measure the earth's magnetic field. Both are easily disrupted by nearby electronics. A GPS module that works perfectly on the bench can perform poorly on a drone if it's mounted in the wrong spot.

All GPS antennas have a **reception pattern** — they are designed to receive signals from satellites above and to the sides, but objects near the antenna can block or distort this pattern. Batteries, carbon fiber, metal brackets, and other conductive materials placed too close to the antenna will shadow parts of the sky and reduce the number of satellites the receiver can track.

Poor placement causes:

* **Low satellite count, high noise, high epv/eph** — RF interference or blocked reception pattern masks weak satellite signals, reducing position accuracy or preventing a GPS fix entirely.
* **Compass calibration failures** — magnetic fields from motor wires, battery leads, and power electronics corrupt magnetometer readings, making calibration impossible or unreliable.
* **Toilet-bowling in flight** — a corrupted compass heading causes the drone to orbit in circles during position hold or autonomous flight.
* **Inconsistent RTK fix** — RTK GPS requires strong signal quality on multiple frequency bands. Even minor RF interference can prevent a fixed solution.

## RF Interference Sources

Radio frequency interference degrades satellite signal reception. The most common on-board sources:

### USB 3.0

USB 3.0 (SuperSpeed) is the single worst source of GPS interference on most drones. USB 3.0 uses 5 Gbit/s signaling, which produces **broadband noise continuously from DC to 5 GHz**. This noise spectrum directly blankets the GPS L1 band (1575.42 MHz), L2 (1227.60 MHz), and L5 (1176.45 MHz) — all at once. The USB 3.0 cable and connectors act as antennas that radiate this noise.

This is a qualitatively different problem than USB 2.0. USB 2.0 runs at 480 MHz and only affects GPS through weak harmonics. USB 3.0 has substantial energy density across the entire GPS frequency range and can raise the noise floor by 20 dB or more, enough to completely kill satellite reception.

{% hint style="danger" %}
**USB 3.0 cables and cameras are a GPS killer.** If you are using USB 3.0 devices (cameras, SSDs, companion computers), keep all USB 3.0 cables and connectors as far from the GPS antenna as possible. If USB 3.0 bandwidth is not required, use a USB 2.0 cable instead — this eliminates the problem entirely.
{% endhint %}

If you must use USB 3.0 near a GPS module, **shield the cable**. Wrapping a USB 3.0 cable with conductive shielding (copper foil tape or a double-shielded cable) and adding ferrite chokes near the connectors can significantly reduce radiated interference. See [Alex Klimaj's demonstration of USB3 cable shielding on a Septentrio Mosaic-X5](https://x.com/alexklimaj/status/1752197126120189962) for a real-world example.

### ESC Switching Noise

ESCs switch at 10–100 kHz, but the fast switching edges produce broadband RF noise that extends well into the MHz and GHz range. This noise radiates from the ESC itself and from the motor phase wires, which act as antennas.

### Radio Transmitters and Antennas

Telemetry radios (900 MHz, 2.4 GHz), RC receivers, and Wi-Fi antennas can all desensitize the GPS receiver if mounted too close. The GPS front-end has a low-noise amplifier that can be overloaded by strong nearby transmitters, even on frequencies well outside the GPS bands.

## Magnetic Interference Sources

The magnetometer (compass) built into most GPS modules measures the earth's magnetic field to determine heading. Any current-carrying wire or magnetized component near the magnetometer will distort this measurement.

### Confirming Magnetic Interference in Logs

You can verify magnetic interference by reviewing a PX4 flight log on [PX4 Flight Review](https://review.px4.io). Look at the **magnetometer field norm** — it should remain stable throughout the flight. If the mag field norm correlates with throttle or thrust, that indicates magnetic coupling from the power system. This is a clear sign that the GPS/compass needs to be moved further from motor wires and battery leads.

### Motor Wires and Battery Leads

These carry the highest currents on the drone (tens of amps) and create proportionally strong magnetic fields. The field strength drops with distance, so even a few centimeters of additional separation makes a meaningful difference.

### ESCs and Power Distribution Boards

ESCs contain inductors and carry high switching currents. Power distribution boards concentrate high-current traces in a small area. Both are strong magnetic interference sources.

### Steel Hardware

Steel screws, nuts, and brackets near the GPS module can distort the magnetic field. Use non-magnetic hardware (nylon, brass, aluminum, titanium) for GPS mast mounting.

## Mounting Best Practices

### Use a Mast

The single most effective thing you can do for GPS performance is mount it on a mast above the frame. Even 5–10 cm of vertical separation dramatically reduces both RF and magnetic interference from the electronics below and keeps the antenna reception pattern clear of obstructions.

### Top of Frame

If a mast isn't practical, mount the GPS on the top of the frame, centered, and as far above the electronics stack as possible. Avoid mounting it underneath the frame where the entire electronics stack is between the GPS antenna and the sky.

### Keep the Reception Pattern Clear

Make sure nothing blocks the sky view around the GPS antenna. Batteries mounted on top of the frame right next to the GPS, tall carbon fiber standoffs, or other conductive objects near the antenna will shadow satellites and reduce fix quality. The GPS antenna needs a clear view of the sky above and to the sides.

### SMA Extenders for Flexible Placement

Some GPS modules support external antennas via SMA connectors. You can use SMA cables or extenders to place the GPS antenna in a more favorable location — for example, on top of a mast or away from a crowded electronics bay — while keeping the GPS receiver module closer to the flight controller.

{% hint style="warning" %}
**Update your GPS position offset parameters.** If you move the GPS antenna away from the module using an SMA extender, the antenna's physical position relative to the flight controller has changed. Update `EKF2_GPS_POS_X`, `EKF2_GPS_POS_Y`, and `EKF2_GPS_POS_Z` in PX4 to reflect the actual antenna location, not the module location.
{% endhint %}

### Orientation

Most GPS modules have an arrow or marking indicating the forward direction. Mount the module with this arrow pointing toward the front of the drone. If the module is rotated, you must set the corresponding autopilot parameter (e.g., `CAL_MAGx_ROT` in PX4) to match, or compass heading will be wrong.

### Separation Distances

There are no universal numbers — it depends on your specific hardware and how much current it draws. As a rough guide:

* **USB 3.0 cables/connectors** — as far as possible; use USB 2.0 cables or shielded cables if separation is limited
* **Motor wires and battery leads** — at least 5–10 cm, preferably on opposite side of frame
* **ESCs** — at least 5 cm
* **Radio antennas** — at least 10 cm from telemetry/RC antennas

## Common Mistakes

* **GPS mounted too close to the battery** — a LiPo battery is a large conductive object that blocks the GPS antenna reception pattern. If the battery sits right next to or above the GPS, it shadows satellites and degrades fix quality. Mount the GPS above or well away from the battery.
* **GPS too close to other antennas and RF-noisy devices** — clustering the GPS antenna near telemetry radios, RC receivers, Wi-Fi antennas, or USB 3.0 cameras creates a high-noise environment. Spread antennas out and keep the GPS away from other RF sources.
* **Power wires routed near the GPS** — high-current battery leads and motor wires near the GPS create magnetic interference that corrupts the compass. Route power wiring on the opposite side of the frame.
* **Carbon fiber infused 3D-printed enclosure** — carbon fiber is conductive. A 3D-printed enclosure made with carbon fiber filament acts as a Faraday cage around the GPS, blocking satellite signals. Use non-conductive materials (PLA, PETG, nylon) for any GPS enclosure or mount.
* **GPS blocked by the carbon fiber airframe** — mounting the GPS below a carbon fiber plate or inside a carbon fiber fuselage attenuates satellite signals. Always mount the GPS above and outside any conductive airframe structure.
* **RTK antennas mounted too close together** — dual-antenna RTK heading setups require sufficient baseline separation between the two antennas to get an accurate heading. Mounting them too close together reduces heading precision. Follow the GPS manufacturer's recommended minimum baseline distance.

## Further Reading

* [Power and Grounding](/knowledge-base/knowledge-base/power-and-grounding) — voltage levels, noise sources, and signal integrity
* [CAN Bus](/knowledge-base/knowledge-base/can-bus) — CAN wiring and 5V power delivery for DroneCAN GPS modules
* [PX4 Magnetometer Calibration](https://docs.px4.io/main/en/config/compass.html)
* [PX4 Flight Review](https://review.px4.io) — upload ulogs to check magnetometer field norm and GPS quality
* [USB3 cable jamming and shielding](https://x.com/alexklimaj/status/1752197126120189962) — Alex Klimaj demonstrating the impact of USB3 cable shielding on GPS reception
* [USB 3.0 Radio Frequency Interference Impact on 2.4 GHz Wireless Devices](https://www.usb.org/sites/default/files/327216.pdf) — Intel whitepaper on USB 3.0 broadband emissions


# Communication Buses (I2C, SPI)

I2C and SPI basics, a comparison of UART vs I2C vs SPI vs CAN, and why CAN wins for drones.

## What Are Communication Buses?

A communication bus is a set of shared wires and protocols that allow multiple chips or devices to exchange data. Drones use several different buses, each with different trade-offs in speed, distance, noise immunity, and wiring complexity.

This page covers **I2C** and **SPI** — two buses commonly found inside or very near the flight controller. For the other major buses, see [UART](/knowledge-base/knowledge-base/serial-communication-uart) and [CAN Bus](/knowledge-base/knowledge-base/can-bus).

## How They Work

### I2C (Inter-Integrated Circuit)

I2C is a two-wire bus that supports multiple devices on the same pair of wires. Each device has a unique 7-bit address, and the controller (flight controller) selects which device to talk to by address.

| Signal | Purpose                                     |
| ------ | ------------------------------------------- |
| SCL    | Clock — driven by the controller            |
| SDA    | Data — bidirectional, shared by all devices |

**Key characteristics:**

* **Multi-device** — many devices share two wires (plus power and ground)
* **Addressable** — each device has a hardware address (e.g., 0x76 for a barometer, 0x1E for a magnetometer)
* **Speed** — typically 100 kHz (standard) or 400 kHz (fast mode)
* **Distance** — very short, typically on-board or a few centimeters. Unreliable beyond 10–15 cm on a drone due to capacitance and noise.
* **Pull-up resistors** — SDA and SCL require pull-up resistors to 3.3V. These are usually included on the flight controller board.

I2C is used for on-board sensors (barometers, magnetometers, IMUs) and short-range external connections via the [Pixhawk Standard I2C connector](/knowledge-base/knowledge-base/connectors-and-wiring) (4-pin JST-GH).

### SPI (Serial Peripheral Interface)

SPI is a high-speed bus that uses separate wires for data in each direction plus a chip-select line for each device.

| Signal | Purpose                                               |
| ------ | ----------------------------------------------------- |
| SCLK   | Clock — driven by the controller                      |
| MOSI   | Master Out, Slave In — data from controller to device |
| MISO   | Master In, Slave Out — data from device to controller |
| CS     | Chip Select — one per device, active low              |

**Key characteristics:**

* **Fast** — typically 1–10 MHz, some devices support 20+ MHz
* **Full duplex** — data flows in both directions simultaneously
* **No addressing** — each device needs its own CS line, so wiring grows with each added device
* **Short range** — on-board only, not designed for inter-board connections
* **No bus contention** — only the selected device responds, making it very reliable on a PCB

SPI is used for the primary IMU, high-speed flash memory, and other on-board sensors that need fast data transfer.

## Comparison: UART vs I2C vs SPI vs CAN

| Feature             | UART                          | I2C                                    | SPI                                 | CAN                                |
| ------------------- | ----------------------------- | -------------------------------------- | ----------------------------------- | ---------------------------------- |
| **Wires (data)**    | 2 (TX, RX)                    | 2 (SCL, SDA)                           | 3 + 1/device (SCLK, MOSI, MISO, CS) | 2 (CAN\_H, CAN\_L)                 |
| **Topology**        | Point-to-point                | Multi-drop bus                         | Multi-drop (with CS lines)          | Multi-drop bus                     |
| **Speed**           | Up to 921600 bps typical      | 100–400 kHz                            | 1–20 MHz                            | 1 Mbps                             |
| **Distance**        | Meters (with proper levels)   | Centimeters                            | On-board only                       | Tens of meters                     |
| **Noise immunity**  | Low (single-ended)            | Low (single-ended)                     | Low (single-ended)                  | **High (differential)**            |
| **Devices per bus** | 2 (point-to-point)            | Up to 127 (by address)                 | Limited by CS lines                 | Up to 127 (by node ID)             |
| **Connector**       | 6-pin JST-GH                  | 4-pin JST-GH                           | 7-pin JST-GH                        | 4-pin JST-GH                       |
| **Hot-pluggable**   | Yes                           | No (can lock bus)                      | No                                  | Yes                                |
| **Drone use case**  | Debug console, telemetry, GPS | On-board sensors, short-range external | Primary IMU, flash                  | **Peripheral sensors, GPS, power** |

### Why CAN Wins for Drone Peripherals

For any sensor or module that is not on the flight controller PCB itself, [CAN bus](/knowledge-base/knowledge-base/can-bus) is the clear choice:

1. **Noise immunity** — differential signaling rejects the electromagnetic noise from motors and ESCs that plagues I2C
2. **Distance** — works reliably over the cable lengths found on real drones (10 cm to 1+ meter), where I2C fails
3. **Hot-pluggable** — devices can be connected and disconnected without locking the bus or requiring a reboot
4. **Power delivery** — 5V power and data on the same 4-pin cable
5. **Firmware updates** — DroneCAN supports over-the-bus firmware updates, no debug adapter needed

I2C and SPI remain critical for on-board sensors where their speed advantages and tight PCB integration make them the right choice. The pattern is:

* **On the board** → SPI (fastest) or I2C (fewer pins)
* **Off the board** → CAN (robust and long-distance)

## How ARK Products Use It

### I2C

* [ARK CANnode](/products/sensor/ark-cannode) provides a Pixhawk Standard I2C connector to bridge non-CAN I2C sensors onto the [CAN bus](/knowledge-base/knowledge-base/can-bus)
* Flight controllers use I2C internally for barometers and secondary magnetometers
* External I2C is available on ARK flight controllers but not recommended for long cable runs

### SPI

* All ARK flight controllers use SPI for the primary IMU (e.g., Bosch BMI088, Invensense ICM-42688-P)
* [ARK CANnode](/products/sensor/ark-cannode) provides a Pixhawk Standard SPI connector for bridging SPI sensors onto CAN
* SPI connections are on-board only — there are no long SPI cables in a typical ARK build

### CAN

* Most external ARK sensors use [DroneCAN](/knowledge-base/knowledge-base/can-bus) as their primary interface
* This is by design — CAN's noise immunity and robustness make it the right bus for inter-board communication on a drone

## Common Pitfalls

* **Using I2C for external sensors on a drone** — I2C works perfectly on a bench but fails intermittently in flight due to motor noise and cable capacitance. Use CAN for any sensor that isn't on the flight controller board.
* **I2C bus lockup** — if an I2C device holds SDA low (due to noise, interrupted transfer, or a bug), the entire bus locks up. The only recovery is usually a power cycle. CAN does not have this failure mode.
* **Address conflicts on I2C** — two devices with the same I2C address cannot share a bus. Some sensors have configurable addresses, but many do not.
* **Missing I2C pull-ups** — if you connect an external I2C device to a port that doesn't have pull-up resistors, communication will fail. The Pixhawk Standard I2C port on ARK boards includes pull-ups.
* **SPI chip-select wiring** — each SPI device needs its own CS line wired correctly. A floating or mis-routed CS line will cause data corruption or no communication.

## Further Reading

* [CAN Bus](/knowledge-base/knowledge-base/can-bus) — detailed CAN bus reference
* [Serial Communication (UART)](/knowledge-base/knowledge-base/serial-communication-uart) — UART protocol details
* [Connectors and Wiring](/knowledge-base/knowledge-base/connectors-and-wiring) — Pixhawk standard connector pinouts
* [I2C Specification (NXP)](https://www.digikey.com/en/pdf/n/nxp-semiconductors/um10204-i2c-bus-specification-and-user-manual)
* [SPI Overview (Analog Devices)](https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html)


# Recommended Tools

Essential bench tools for building, debugging, and maintaining drone electronics.

## Why Good Tools Matter

You can build a drone with just a soldering iron and a prayer, but when something goes wrong — and it will — having the right tools on your bench turns a multi-day guessing game into a 10-minute diagnosis. Every tool on this list has earned its spot by saving real debugging time.

## Debug and Programming

### ST-LINK V3 Mini

The [ST-LINK V3 Mini](https://www.digikey.com/en/products/detail/stmicroelectronics/STLINK-V3MINIE/16284301) is the recommended programmer/debugger for all ARK products with STM32 microcontrollers. It handles both [SWD programming](/knowledge-base/knowledge-base/swd-programming) and [UART debug console](/knowledge-base/knowledge-base/serial-communication-uart) access through a single USB connection — no separate USB-to-serial adapter needed.

See the [ST-LINK Flashing Guide](/knowledge-base/knowledge-base/st-link-flashing-guide) for setup and usage.

### ARK Pixhawk Debug Adapter

The [ARK Pixhawk Debug Adapter](https://arkelectron.com/product/ark-pixhawk-debug-adapter/) bridges the ST-LINK V3 Mini's STDC14 connector to the Pixhawk Standard 6-pin and 10-pin JST-SH debug connectors found on ARK boards. Includes debug cables. Without this adapter, you would need to manually wire the ST-LINK to JST-SH connectors.

### CAN-to-USB Adapter

A CAN-to-USB adapter like the [Zubax Babel](https://zubax.com/products/babel) lets you connect your computer directly to the [CAN bus](/knowledge-base/knowledge-base/can-bus) for diagnostics, firmware updates, and parameter configuration using the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide).

This is essential for:

* Updating firmware on DroneCAN nodes when no flight controller is available
* Inspecting raw CAN bus traffic to diagnose communication issues
* Configuring device parameters outside of a flight controller setup

{% hint style="info" %}
With ArduPilot, the flight controller itself can act as a CAN interface via SLCAN, so a separate adapter is not strictly required. However, a dedicated adapter is useful for standalone bench work and does not depend on a working flight controller.
{% endhint %}

## Test and Measurement

### Oscilloscope

An oscilloscope is the single most useful debugging tool for embedded electronics. When a communication bus isn't working and you've checked the obvious (wiring, baud rate, configuration), an oscilloscope shows you exactly what is happening on the wire — signal presence, voltage levels, noise, rise times, and timing.

Use it to:

* Verify [UART](/knowledge-base/knowledge-base/serial-communication-uart) TX/RX signals are present and clean
* Spot power rail noise, ripple, and brownouts
* Confirm connector and solder joint integrity — a broken connection is immediately obvious
* Check voltage levels and signal rise/fall times

An oscilloscope shows you the actual analog waveform, which matters because a logic analyzer applies a voltage threshold and only shows you 1s and 0s. A signal that is ringing, has a slow rise time, or is sitting at an ambiguous voltage will show up clearly on a scope but may look perfectly fine on a logic analyzer. Always verify with a scope first, then move to a logic analyzer for protocol decoding.

Any decent digital oscilloscope with at least 100 MHz bandwidth and two channels will cover drone electronics work.

### Logic Analyzer

A logic analyzer captures and decodes digital bus traffic over time. The [Saleae Logic Pro 16](https://www.saleae.com/) is an excellent choice — 16 channels, high sample rate, and the Saleae Logic 2 software includes built-in protocol decoders for UART, I2C, SPI, and more.

This is the right tool for protocol-level debugging — verifying that the correct bytes are being sent, spotting framing errors, checking timing between messages, and decoding multi-wire buses like I2C (SCL + SDA) and SPI (SCLK + MOSI + MISO + CS) where you need to see clock and data together.

{% hint style="info" %}
**Oscilloscope first, logic analyzer second.** A logic analyzer applies a voltage threshold to classify signals as high or low — it won't tell you if a signal is noisy, has poor rise times, or is floating at an intermediate voltage. Use an oscilloscope to confirm signal integrity first, then switch to a logic analyzer for protocol decoding.
{% endhint %}

### Multimeter

A basic digital multimeter handles the everyday measurements:

* **Voltage** — verify 5V and 3.3V rails are within spec, check battery voltage
* **Continuity** — trace wires, check solder joints, find broken traces
* **Resistance** — measure [CAN bus termination](/knowledge-base/knowledge-base/can-bus) (should read \~60 ohms between CAN\_H and CAN\_L with two 120-ohm terminators)

Any reputable multimeter with DC voltage, resistance, and continuity modes will work.

### Benchtop Power Supply

A benchtop power supply with adjustable voltage and current limiting lets you power your electronics safely during development without a battery.

{% hint style="warning" %}
**Quality matters here.** Cheap power supplies have high output ripple (voltage noise) that can cause the same problems you're trying to debug — sensor noise, communication errors, and erratic behavior. Look for a supply with low ripple specification (under 10 mV peak-to-peak). A supply with ripple in the hundreds of millivolts can mask or create issues that won't appear on battery power, and vice versa.
{% endhint %}

Key features to look for:

* Adjustable voltage (0–30V covers everything from 3.3V logic to 6S battery simulation)
* Current limiting — set a limit so a wiring mistake trips the supply instead of releasing the magic smoke
* Low ripple and noise (< 10 mV p-p)
* Voltage and current readout

## ESC Programming

### Betaflight-Capable Flight Controller

To configure or flash firmware on AM32 ESCs (like the [ARK 4IN1 ESC](/products/electronic-speed-controller/ark-4in1-esc)), you need a flight controller running Betaflight that supports ESC passthrough. The [ARK FPV](/products/flight-controller/ark-fpv) works for this — flash it with [Betaflight](/products/flight-controller/ark-fpv/betaflight-instructions), connect the ESC, and use the Betaflight configurator's ESC tab to configure or update AM32 firmware via passthrough.

See the [ARK 4IN1 ESC firmware guide](/products/electronic-speed-controller/ark-4in1-esc/firmware) for detailed instructions.

## Cables and Connectors

### JST Cable Kits

Pre-crimped cable kits let you make custom-length cables without a crimping tool:

* **JST-GH 1.25 mm** (peripheral connectors — CAN, I2C, UART, GPS, power): [GH1.25 Connectors Kit on Amazon](https://www.amazon.com/Pre-Crimped-Connectors-Pixhawk2-Pixracer-Silicone/dp/B07PBHN7TM)
* **JST-SH 1.0 mm** (debug connectors): [JST SH 1.0mm Connector Kit on Amazon](https://www.amazon.com/Teansic-Connector-Pre-Crimped-Housing-Controller/dp/B0D5X6BY5Z)

See [Connectors and Wiring](/knowledge-base/knowledge-base/connectors-and-wiring) for pinout details and wire color conventions.


# ST-LINK Flashing Guide

Guide for using ST-LINK to flash firmware and access the debug console on ARK products.

## Overview

### What is SWD?

SWD (Serial Wire Debug) is a two-wire debug interface for ARM microcontrollers. It provides programming and debugging capabilities using just two signals (SWDIO and SWCLK) plus ground. All ARK products with STM32 microcontrollers include an SWD interface on their debug connector.

### What is ST-LINK?

ST-LINK is a programmer/debugger from STMicroelectronics designed for their STM32 microcontroller family. It connects to your computer via USB and to the target board via the SWD interface, allowing you to flash firmware and debug applications.

### Why ST-LINK V3 Mini?

We recommend the **ST-LINK V3 Mini** because it is a composite USB device that provides both the programmer interface and a virtual serial port in a single USB connection. This means you can flash firmware and access the UART debug console without needing a separate USB-to-serial adapter.

When you connect an ST-LINK V3 Mini to your computer, it creates multiple USB interfaces:

**Example `dmesg` output:**

```
usb 1-3: new high-speed USB device number 66 using xhci_hcd
usb 1-3: New USB device found, idVendor=0483, idProduct=3754, bcdDevice= 1.00
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: STLINK-V3
usb 1-3: Manufacturer: STMicroelectronics
usb 1-3: SerialNumber: 003500313133510F37363734
cdc_acm 1-3:1.1: ttyACM0: USB ACM device
```

The `ttyACM0` device is the virtual serial port you can use for UART debug console access.

***

## What You'll Need

* [**ARK Pixhawk Debug Adapter**](https://arkelectron.com/product/ark-pixhawk-debug-adapter/) - Includes 6-pin and 10-pin JST-SH debug cables
* [**ST-LINK V3MINIE**](https://www.digikey.com/en/products/detail/stmicroelectronics/STLINK-V3MINIE/16284301) (recommended) or ST-LINK V2
* **Computer** running Ubuntu or Windows
* **Firmware binary file** (.bin)

### Optional: JST Cable Kits

If you need additional cables for custom wiring, these pre-crimped cable kits are convenient (no crimping tool required):

* **JST-SH 1.0mm** (debug connectors): [JST SH 1.0mm Connector Kit on Amazon](https://www.amazon.com/Teansic-Connector-Pre-Crimped-Housing-Controller/dp/B0D5X6BY5Z)
* **JST-GH 1.25mm** (peripheral connectors): [GH1.25 Connectors Kit on Amazon](https://www.amazon.com/Pre-Crimped-Connectors-Pixhawk2-Pixracer-Silicone/dp/B07PBHN7TM)

***

## Hardware Setup

The [ARK Pixhawk Debug Adapter](https://arkelectron.com/product/ark-pixhawk-debug-adapter/) makes connecting an ST-LINK to ARK products simple - no manual wiring required.

1. Connect the ST-LINK V3 Mini to the adapter's STDC14 connector using the cable that comes with the ST-LINK
2. Connect the appropriate JST-SH debug cable (6-pin or 10-pin) from the adapter to your ARK product's debug port
3. Connect the ST-LINK to your computer via USB

The adapter routes SWD signals (SWDIO, SWCLK, GND) and UART signals (TX, RX) between the ST-LINK and the Pixhawk Standard Debug connector.

{% hint style="warning" %}
**Power:** The ST-LINK can provide 3.3V power to the target. If your board is already powered from another source (battery, USB, etc.), the adapter handles this safely. However, for boards that draw significant current, power from an external source is recommended.
{% endhint %}

***

## Software Installation

### Ubuntu

Install the stlink tools from the official repository:

```bash
sudo apt install stlink-tools
```

Alternatively, you can build from source by following the instructions on the [stlink-org/stlink GitHub page](https://github.com/stlink-org/stlink).

**Permissions:** If you encounter permission errors, add your user to the `dialout` group:

```bash
sudo usermod -aG dialout $USER
```

Log out and back in for the change to take effect.

### Windows

1. Download the **ST-LINK Utility** from the [STMicroelectronics website](https://www.st.com/en/development-tools/st-link-v2.html#tools-software)
2. Install the utility and USB drivers
3. Refer to the [ST-LINK documentation](https://www.st.com/en/development-tools/stsw-link007.html#documentation) for detailed usage instructions

***

## Flashing Firmware

### Ubuntu

#### Test the Connection

After connecting your ST-LINK to both your computer and the target board, verify the connection:

```bash
st-info --probe
```

**Expected output (example for ARK FPV):**

```
Found 1 stlink programmers
  version:    V3J8
  serial:     003800333433510937363934
  flash:      2097152 (pagesize: 131072)
  sram:       131072
  chipid:     0x450
  dev-type:   STM32H74x_H75x
```

**Expected output (example for ARK 4IN1 ESC):**

```
Found 1 stlink programmers
  version:    V2J45S7
  serial:     543C0A135550
  flash:      32768 (pagesize: 1024)
  sram:       4096
  chipid:     0x0440
  dev-type:   STM32F03x/STM32F05x
```

If you see an error or no device found, check your wiring connections.

#### Erase Flash Memory (Optional)

Before flashing new firmware, you may want to erase the existing flash. On PX4 boards with FLASH based parameters (ARK FPV, ARK Pi6X) this will also wipe all parameters back to default. If you don't mass erase, parameters will remain unchanged.

```bash
st-flash erase
```

#### Flash Firmware

Navigate to the directory containing your firmware binary, then flash:

```bash
st-flash write firmware.bin 0x08000000
```

{% hint style="warning" %}
`0x08000000` is the start of flash. It is the correct address for a single-image firmware or a bootloader, but **not** for a DroneCAN node application — see [Flashing DroneCAN Nodes](#flashing-dronecan-nodes) below.
{% endhint %}

**Expected output:**

```
st-flash 1.8.0
2025-01-15T10:30:00 INFO common.c: STM32H74x: 128 KiB SRAM, 2048 KiB flash
file firmware.bin md5 checksum: abc123..., stlink checksum: 0x00abcdef
2025-01-15T10:30:00 INFO common.c: Attempting to write 524288 (0x80000) bytes to stm32 address: 134217728 (0x8000000)
2025-01-15T10:30:05 INFO common.c: Flash written and verified! jolly good!
```

### Windows

1. Open **ST-LINK Utility**
2. Click **Target > Connect** to connect to your board
3. Click **File > Open File** and select your firmware binary (.bin file)
4. Click **Target > Program & Verify**
5. Verify the success message in the log window

***

## Flashing DroneCAN Nodes

DroneCAN nodes — ARK RTK GPS, ARK CANnode, ARK Flow, ARK MAG, ARK DIST, and the other CAN products — run **two** separate images: a bootloader at the start of flash and the application at a fixed offset above it. On ARK CAN nodes the bootloader region is 64 KB, so the application lives at `0x08010000`, not `0x08000000`. This applies to both ArduPilot AP\_Periph and PX4 CAN node firmware.

| Image                                                        | Flash address |
| ------------------------------------------------------------ | ------------- |
| Bootloader (ArduPilot CAN bootloader or PX4 `canbootloader`) | `0x08000000`  |
| Application (AP\_Periph or PX4 CAN node firmware)            | `0x08010000`  |

{% hint style="warning" %}
Writing the application to `0x08000000` overwrites the bootloader. `st-flash` reports success, but the node boots with a single LED flash and then goes dark — it never appears in the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) or the Mission Planner DroneCAN/UAVCAN tab. If you see this after an SWD flash, reflash with the combined image below.
{% endhint %}

### Recommended: Flash the Combined Bootloader + Application Image

ArduPilot publishes a combined bootloader and application image as an Intel HEX file. HEX files carry their own load addresses, so there is no offset to get wrong. This is the recommended way to flash a node over SWD, and the only way to bring up a node that has no bootloader at all.

Download `AP_Periph_with_bl.hex` for your board from the [ArduPilot firmware server](https://firmware.ardupilot.org/AP_Periph/stable/), then flash it:

```bash
st-flash --format ihex write AP_Periph_with_bl.hex
```

Power-cycle the node afterward. It should enumerate on the CAN bus within a few seconds.

### Firmware Files

Each board directory on the ArduPilot firmware server contains several files. Pick the one that matches how you are flashing:

| File                    | Contents                 | Use with                                                                                                    |
| ----------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------- |
| `AP_Periph_with_bl.hex` | Bootloader + application | ST-LINK / SWD — no address needed                                                                           |
| `AP_Periph.bin`         | Application only         | ST-LINK / SWD, written at `0x08010000`                                                                      |
| `AP_Periph.apj`         | Application only         | [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide) or flight controller CAN update |

### Flashing the Application Only

If the node already has a working bootloader and you only want to replace the application, write the `.bin` at the application offset:

```bash
st-flash write AP_Periph.bin 0x08010000
```

Prefer the combined HEX unless you have a specific reason not to — an application flashed at the wrong address is the most common way to leave a node unresponsive.

{% hint style="info" %}
Once a bootloader is installed, SWD is no longer needed for routine updates. Firmware can be pushed over CAN from the flight controller's SD card or with the [DroneCAN GUI Tool](/knowledge-base/knowledge-base/dronecan-gui-tool-guide).
{% endhint %}

### PX4 Nodes

PX4 CAN nodes use the same split — the PX4 `canbootloader` at `0x08000000` and the node application at `0x08010000`. Flash the bootloader first, then the application at its offset. PX4 does not publish a combined image, so both writes are separate:

```bash
st-flash write canbootloader.bin 0x08000000
st-flash write firmware.bin 0x08010000
```

***

## UART Debug Console

The debug connector provides a serial console (UART) for viewing system output and debugging. This is useful for accessing the NuttX shell, viewing boot messages, and debugging issues.

### Connection

When using the ARK Pixhawk Debug Adapter with an ST-LINK V3 Mini, the UART signals are routed through the adapter. The ST-LINK V3 Mini's composite USB creates a virtual serial port (`/dev/ttyACM0` on Linux, `COMx` on Windows) that provides access to the debug console.

No additional wiring or adapters are needed.

### Serial Terminal Settings

* **Baud rate:** 57600
* **Data bits:** 8
* **Stop bits:** 1
* **Parity:** None
* **Flow control:** None

### Ubuntu

Using `screen`:

```bash
screen /dev/ttyACM0 57600
```

To exit screen, press `Ctrl+A` then `K`, then `Y` to confirm.

### Windows

Use a serial terminal application such as:

* **PuTTY** - Select "Serial" connection type, enter the COM port, and set speed to 57600
* **Tera Term** - Select serial port and configure 57600 baud, 8N1

***

## Troubleshooting

### "No ST-LINK detected"

* Check that the USB cable is connected properly
* Try a different USB port
* Verify the ST-LINK USB drivers are installed (Windows)
* Check `dmesg` output (Linux) to see if the device is recognized

### "Target voltage detected" or Similar Errors

* Ensure proper power configuration - either power from ST-LINK OR external source, not both.
* Disconnect peripheral devices in case they are drawing too much power.

### Permission Denied (Linux)

Add your user to the dialout group:

```bash
sudo usermod -aG dialout $USER
```

Then log out and back in.

### Flash Verification Failed

* Ensure the correct firmware binary for your target
* Try erasing flash first with `st-flash erase`
* Check that the flash address is correct for your target — `0x08000000` for a single-image firmware or a bootloader, `0x08010000` for a DroneCAN node application

### Node Flashes Its LED Once at Boot, Then Nothing

The application was almost certainly written over the bootloader at `0x08000000`. The node has no bootloader to hand off to, so it never joins the CAN bus and no DroneCAN tool will see it. Reflash with the combined image — see [Flashing DroneCAN Nodes](#flashing-dronecan-nodes).

### Serial Console Shows Garbage Characters

* Verify the baud rate is set to 57600
* Check TX/RX connections are not swapped
* Ensure common ground between ST-LINK and target board


# DroneCAN GUI Tool Guide

Guide for using the DroneCAN GUI Tool to configure, update firmware, and monitor ARK DroneCAN devices.

## Overview

The DroneCAN GUI Tool is an open source application for managing DroneCAN devices. It allows you to:

* Upload firmware to DroneCAN nodes
* View and modify device parameters
* Monitor CAN bus traffic in real-time

This guide covers using the tool with ARK DroneCAN products such as the ARK Flow, ARK CANnode, ARK DIST, ARK MAG, and ARK GPS modules.

{% embed url="<https://github.com/dronecan/gui_tool>" %}

***

## Installation

Install the required dependencies and the DroneCAN GUI Tool on Ubuntu:

```bash
sudo apt-get install -y python3-pip python3-setuptools python3-wheel
sudo apt-get install -y python3-numpy python3-pyqt5 python3-pyqt5.qtsvg git-core
python3 -m pip install git+https://github.com/DroneCAN/gui_tool@master
```

Run the tool with:

```bash
dronecan_gui_tool
```

***

## Connecting to DroneCAN Devices

### PX4 - USB to CAN Adapter

PX4 requires a USB-to-CAN adapter that supports the SLCAN protocol to connect to DroneCAN devices. The Zubax Babel is a commonly used adapter.

1. Connect the adapter to your CAN bus and plug it into your computer via USB
2. Launch the DroneCAN GUI Tool
3. Select the adapter's serial port from the dropdown
4. Set the CAN bus bit rate to 1000000 (1 Mbps)
5. Click OK to connect
6. Once connected press the "Set" button to the right of "Set local node ID."

![](/files/vx4OMblDUUqG7yb7WmPK)

![](/files/l4svvWlRtqUFhCn7n9bC)

### ArduPilot - Flight Controller as CAN Interface

With ArduPilot, the flight controller can act as a CAN interface, eliminating the need for a separate USB-to-CAN adapter.

#### SLCAN

SLCAN exposes the CAN bus over the flight controller's USB serial port. This is the simplest method when the vehicle is not armed.

This is already enabled by default on ARK boards running Ardupilot.

* [SLCAN on F7/H7 Autopilots](https://ardupilot.org/copter/docs/common-slcan-f7h7.html)

{% hint style="info" %}
SLCAN access is disabled when the vehicle is armed to reduce CPU load.
{% endhint %}

#### MAVCAN

MAVCAN tunnels CAN frames over a MAVLink connection. This method works while armed and over any MAVLink link (USB, telemetry radio, etc.).

To connect via MAVCAN in the DroneCAN GUI Tool, enter the connection string with the `mavcan:` prefix, for example `mavcan:udp:14550`.

{% hint style="info" %}
It is not recommended to run MAVCAN while the vehicle is armed, due to the high amount of link traffic it creates.
{% endhint %}

***

## Firmware Upload

DroneCAN nodes that require firmware will appear with a status of MAINTENANCE in the node list.

To upload firmware:

1. Double-click on the node to open its properties window
2. Click **Update Firmware**
3. Select the firmware file for your device

**Firmware file formats:**

* `.bin` - AP\_Periph firmware (ArduPilot)
* `.uavcan.bin` - PX4 CANnode firmware

{% hint style="info" %}
Check the individual ARK product documentation pages for which firmware types are supported by each device.
{% endhint %}

![](/files/s4Jeg6RUgMiE2Xs6VoUX)

***

## Parameter Configuration

To view and modify device parameters:

1. Double-click on a node in the node list to open its properties window
2. Click **Fetch All** to retrieve parameters from the device
3. Edit parameter values as needed
4. Click **Send** to write the changed parameters to the device

![](/files/SxHePttWj5zY3x9cneKw)

***

## Bus Monitor

The Bus Monitor provides real-time visibility into CAN bus traffic, useful for debugging and verifying device communication.

To open the Bus Monitor:

1. Go to **Tools** in the menu bar
2. Select **Bus Monitor**
3. Press the camera icon to begin capturing frames
4. Press the pause icon to stop cature and review

The Bus Monitor displays:

* CAN message types and data type names
* Source and destination node IDs
* Decoded message contents

![](/files/BDhJUaK29RvRMp4G0qls)


# PX4 Log Encryption

This section guides you through setting up log encryption in PX4 on our flight controllers, and then explains how to access, decrypt, and view the encrypted logs.

{% embed url="<https://www.youtube.com/watch?v=ixmzCn4nH9c>" %}

### Creating PX4 Board files for Encrypted logs

```
git clone --recurse-submodules git@github.com:PX4/PX4-Autopilot.git
```

Generate your Private and Public Key

```
cd PX4-Autopilot/Tools/log_encryption
python3 generate_keys.py
```

You can find your keys in

```
PX4-Autopilot/
│
├── keys/ 
│ ├── private/
│ │ ├── private_key.pem # RSA private key (2048-bit)
│ │
│ ├── public/ 
│ │ ├── public_key.der # Public key in DER format
│ │ ├── public_key.pub # Public key in hex format
```

The ARK flight controllers have targets setup for encryption

You should navigate to

```
PX4-Autopilot/boards/ark
```

* ARK FPV
* ARKV6X
* ARKPI6X

You should replace the Dummy Key with your own Public Key in the following file

```
encrypted_logs.px4board
```

```
CONFIG_PUBLIC_KEY1="../../../keys/public/public_key.pub"
```

Then you can go ahead and make your board file

```
make ark_fpv_encrypted_logs
OR
make ark_fmu-v6x_encrypted_logs
OR
make ark_pi6x_encrypted_logs
```

Once that is done you can find your build file in

```
PX4-Autopilot/build/*.px4
```

You can go ahead and flash it on your flight controller.

### Downloading and Decrypting log files

The encrypted logs can be found on the SD card in .ulge format.

You can either extract the files directly from the SD card our use the log tool provided below

Addresses might need to be adjusted

```
cd PX4-Autopilot/Tools/log_encryption

python3 download_logs.py /dev/ttyACM0 --baudrate 57600

OR

python3 download_logs.py udp:0.0.0.0:14550
```

To Decrypt the logs you can use

```
cd PX4-Autopilot/Tools/log_encryption

AND
# Uses default key + default folder
python3 decrypt_logs.py

OR
# Use --help to get all the options
python3 decrypt_logs.py --help
```

Your logs can be found in the following structure

```
PX4-Autopilot/
│
├── logs/ 
│ ├── encrypted/ 
│ │ ├── log-YYYY-MM-DD_HH-MM-SS_ID.ulge 
│ │
│ ├── decrypted/
│ │ ├── log-YYYY-MM-DD_HH-MM-SS_ID.ulg
```

Once you've decrypted your logs, you can view them using your preferred method.

### Flight Review

{% embed url="<https://www.youtube.com/watch?v=Dhd3jYyHgI0&t=1s>" %}

If you choose to use Flight Review, you can embed your Private Key on your local Flight Review server, allowing your encrypted logs to be decrypted automatically when the .ulge is uploaded .

```
git clone --recurse-submodules git@github.com:PX4/flight_review.git
```

You should follow these steps

```
cd flight_review/app
pip install -r requirements.txt
# Note: preferably use a virtualenv
./app/setup_db.py
```

Add your Private Key to

```
flight_review/app/private_key/private_key.pem
```

Then you need to edit, the config file. There you can define your own network setup (Domain, VPN, etc).

```
flight_review/app/config_default.ini
```

You have to update the Private Key path with your own.

```
ulge_private_key = ../private_key/private_key.pem
```

Once you are done you can just open your server using

```
cd app
./serve.py --show
```

Once you have your server ready you can upload the Encrypted logs and view them.

Optionally you can also integrate logloader developed by ARK.

The repository can be found here:

<https://github.com/ARK-Electronics/logloader>

You should specify your server in the config file

```
logloader/config.toml
```


# PX4 Setup

{% embed url="<https://www.youtube.com/watch?v=c2G0YkwViTc>" %}

{% embed url="<https://docs.px4.io/main/en/config_mc/>" %}


# USB Peripherals

Tested USB Wi-Fi and Bluetooth adapters, and USB camera EMI on GPS.

Applies to every ARK Jetson carrier. Adapters below were tested against the [ARK Jetson Kernel](https://github.com/ARK-Electronics/ark_jetson_kernel).

## Wi-Fi Adapters

<table><thead><tr><th>Wi-Fi Adapter</th><th>Status</th><th data-hidden></th></tr></thead><tbody><tr><td><a href="https://a.co/d/3MhAIhk">Edimax Wi-Fi 4 802.11n Adapter</a></td><td>Working with rtl8xxxu driver</td><td></td></tr><tr><td><a href="https://a.co/d/afkaRWw">TP-Link TL-WN725N</a></td><td>Module exists in kernel but is missing driver</td><td></td></tr><tr><td><a href="https://a.co/d/gagruxP">TP-Link AX1800</a></td><td>Does not work. No kernel driver in 5.15</td><td></td></tr><tr><td><a href="https://a.co/d/at9haBv">TP-Link AC1300</a></td><td>Does not work. No kernel driver in 5.15</td><td></td></tr></tbody></table>

## Bluetooth Adapters

<table><thead><tr><th>Bluetooth Adapter</th><th>Status</th><th data-hidden></th></tr></thead><tbody><tr><td><a href="https://a.co/d/bp0okc0">TP-Link UB500</a></td><td>Working with btusb driver</td><td></td></tr><tr><td><a href="https://a.co/d/2u3XvwS">UGREEN 5.3 Bluetooth Adapter</a></td><td>No driver exists in 5.15 for the Actions ATS2851 chipset</td><td></td></tr></tbody></table>

## USB Cameras and GPS

USB 3.0 signalling emits broadband EMI overlapping the GPS L1, L2, and L5 bands. It raises the noise floor enough to degrade or prevent GPS lock.

Use a USB 2.0 camera where possible. If not, shield the cable and connectors with faraday tape.

Before flight testing:

1. **Measure** the noise floor across the GPS bands with the camera active, using a GPS receiver with spectrum monitoring or a spectrum analyzer.
2. **Shield** the cable, connectors, and exposed sections with faraday/EMI tape if interference is severe.
3. **Re-measure** to confirm the noise floor recovered.

See [this post from Alex Klimaj](https://x.com/ArkElectron/status/1752197126120189962).


# ARK-OS

[ARK-OS](https://github.com/ARK-Electronics/ARK-OS) is ARK's companion computer software suite: a set of systemd services for MAVLink routing, video streaming, flight log management, firmware updates, and network RTK corrections, plus a web UI to manage it all. It comes pre-installed on the ARK Jetson image.

## ARK-UI

The web UI is served at <http://jetson.local> (or the Jetson's IP). Pages: **System** (hardware and resource info, hostname), **Autopilot** (status, firmware update, reset), **Connections** (WiFi/Ethernet/LTE, data usage), **Services** (start/stop, autostart, logs, config editing), **Video** (live camera stream), and **Logs** (flight log download and upload to Flight Review).

<figure><img src="/files/HUwnDbxl6Kpf1eL38Kxw" alt=""><figcaption><p>Services page — start/stop services, toggle autostart, view logs, edit configs</p></figcaption></figure>

## Services

See the [Services](/software/ark-os/services) page for what each service does and which are enabled by default.

## Command-Line Tools

ARK-OS puts its operator scripts on `PATH` (open a login shell and run them by name):

```
mavlink_shell.py              # interactive PX4 NSH shell over MAVLink
px4_shell_command.py <cmd>    # run a single PX4 console command
flash_firmware.sh <fw.px4>    # flash flight controller firmware
reset_fmu_fast.py             # reset the flight controller
reset_fmu_wait_bl.py          # reset the flight controller into bootloader
jetson_serial_number.py       # print the carrier serial number
can_check.py can0             # check DroneCAN traffic on a CAN interface
check_cameras.sh              # stream-test the CSI cameras
check_fan.sh                  # verify the cooling fan
```

## Updating ARK-OS

ARK-OS is distributed as a Debian package on the [releases page](https://github.com/ARK-Electronics/ARK-OS/releases). To update a device, run the install script from a clone of the repo on the Jetson:

```bash
git clone https://github.com/ARK-Electronics/ARK-OS.git
cd ARK-OS
sudo ./packaging/install_ark_os.sh --ark-os-version=X.Y.Z
```

{% hint style="warning" %}
Upgrading resets the service configuration under `/etc/ark-os/` to packaged defaults — reconfigure via the web UI afterward.
{% endhint %}


# Services

What each ARK-OS service does.

ARK-OS services are system-level [systemd services](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) running as the `jetson` user. Manage them — including configuration editing — from the [ARK-UI](http://jetson.local) **Services** page, or with `systemctl`. Configuration files live under `/etc/ark-os/`.

## Enabled by Default

**mavlink-router** routes MAVLink between the flight controller (USB, `/dev/ttyACM0`) and user-defined UDP/TCP endpoints such as QGroundControl. Default config: [main.conf](https://github.com/ARK-Electronics/ARK-OS/blob/main/services/mavlink-router/main.conf).

**rtsp-server** streams the first CSI camera over RTSP at `rtsp://jetson.local:5600/camera1` using gstreamer.

**go2rtc** restreams the RTSP feed to the browser over WebRTC for the ARK-UI **Video** page.

**ark-ui-backend**, **system-manager**, **service-manager**, **connection-manager**, **autopilot-manager** are the REST APIs behind the ARK-UI (hidden from the Services page).

**jetson-can** brings up the Jetson CAN interface (`can0`).

## Optional (installed, disabled by default)

Enable from the ARK-UI Services page or with `systemctl enable --now <service>`.

**dds-agent** bridges PX4 uORB topics to ROS 2 by running the [Micro XRCE-DDS Agent](https://github.com/eProsima/Micro-XRCE-DDS-Agent) on the high-speed serial connection to the flight controller (`/dev/ttyTHS1` ↔ TELEM2, 3 Mbps). The bridged topics are defined in [PX4's dds\_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml). Set these PX4 parameters:

| Parameter       | Value   | Description |
| --------------- | ------- | ----------- |
| UXRCE\_DDS\_CFG | 102     | TELEM 2     |
| SER\_TEL2\_BAUD | 3000000 | 3 Mbps 8N1  |

**logloader** downloads PX4 `.ulg` flight logs from the flight controller's SD card over MAVLink FTP and optionally uploads them to [Flight Review](https://review.px4.io/). Driven from the ARK-UI **Logs** page.

**flight-review** hosts a local [PX4 Flight Review](https://github.com/PX4/flight_review) server at <http://jetson.local/flight-review> for the logs downloaded by logloader.

**polaris** receives network RTK corrections from the [Point One Polaris](https://pointonenav.com/polaris) service (subscription required) and publishes them to the flight controller over MAVLink.

**pointperfect** receives GNSS corrections from the [u-blox PointPerfect](https://www.u-blox.com/en/product/pointperfect) NTRIP service and publishes them to the flight controller over MAVLink. For u-blox receivers it can also request AssistNow start-up assistance for a faster first fix.

**rid-transmitter** broadcasts Remote ID over Bluetooth per ASTM F3411 (requires a Bluetooth 5.x capable radio).


# Apt: Hold Back Risky Packages

Running `apt upgrade` on the ARK Jetson image can pull in NVIDIA kernel, firmware, or driver packages that overwrite the ARK kernel and device tree, breaking WiFi, cameras, or other carrier hardware.

The ARK image already pins its camera userspace packages. Before running a full `apt upgrade`, we recommend also holding the kernel and firmware packages:

```
sudo apt-mark hold linux-firmware nvidia-l4t-kernel nvidia-l4t-kernel-dtbs nvidia-l4t-firmware nvidia-l4t-kernel-headers nvidia-l4t-kernel-oot-headers wireless-regdb
```

Show packages on hold:

```
sudo apt-mark showhold
```

Remove a hold and upgrade a specific package:

```
sudo apt-mark unhold <package>
sudo apt upgrade <package>
```

To move to a newer JetPack release, re-flash with the latest ARK image instead of upgrading in place — see your carrier's Flashing Guide.


# Embedded Computers

ARK embedded computers for onboard AI and autonomous computing, built around NVIDIA Jetson and Raspberry Pi compute modules.

{% content-ref url="/pages/QoFTB30a2YpQPrYwhPWS" %}
[ARK Just A Jetson](/products/embedded-computers/ark-just-a-jetson)
{% endcontent-ref %}

{% content-ref url="/pages/yH43mJpQecvpkla2XIAs" %}
[ARK Just a Pi](/products/embedded-computers/ark-just-a-pi)
{% endcontent-ref %}


# ARK Just A Jetson

The ARK Just A Jetson (JAJ) is a compact carrier board for the NVIDIA Jetson Orin NX/Nano module. It provides essential connectivity including USB-C, Ethernet, WiFi/Bluetooth, CSI camera, CAN bus, and GPIO in a minimal form factor.

## Where to Start

**Your bundle arrived preflashed.** It already runs ARK-OS. Go to [Set Up Your Jetson](/products/embedded-computers/ark-just-a-jetson/setup), then manage it from the ARK-UI web interface.

**You have a bare board, or you want to flash it yourself.** Install a Jetson module and NVMe SSD, then start at the [Flashing Guide](/products/embedded-computers/ark-just-a-jetson/developer/flashing-guide).

## Sections

* [Set Up Your Jetson](/products/embedded-computers/ark-just-a-jetson/setup) — connect to it and get it on your network
* [Using ARK-OS](/products/embedded-computers/ark-just-a-jetson/using-ark-os) — the preinstalled services and web interface
* [Hardware Reference](/products/embedded-computers/ark-just-a-jetson/hardware) — pinout, GPIO, cameras, onboard sensors
* [Developer Guide](/products/embedded-computers/ark-just-a-jetson/developer) — flashing, serial console, building from source


# Set Up Your Jetson

## What's Pre-Installed

Bundles ship ready to use — no flashing required:

* **Jetson**: Latest ARK Jetson image (JetPack 6 / L4T r36) on the NVMe SSD, with [ARK-OS](https://github.com/ARK-Electronics/ARK-OS) pre-installed
* **Credentials**: Username `jetson`, password `jetson`, hostname `jetson`

{% hint style="info" %}
The default password is well known — change it (`passwd`) before putting the device on a network you don't control.
{% endhint %}

A bare carrier board (no Jetson module or SSD) has no OS on it. Install your module and NVMe SSD, then follow the [Flashing Guide](/products/embedded-computers/ark-just-a-jetson/developer/flashing-guide).

## Steps

1. [Connect](/products/embedded-computers/ark-just-a-jetson/setup/connect) — reach the Jetson over USB-C, WiFi hotspot, or Ethernet.
2. [Get Online](/products/embedded-computers/ark-just-a-jetson/setup/get-online) — join it to your WiFi network.
3. [ARK-OS](/software/ark-os) — the preinstalled services and the ARK-UI web interface.


# Connect

## USB-C

Connect the USB-C port to your PC. The Jetson appears as a USB network device at `192.168.55.1`:

```bash
ssh jetson@192.168.55.1
```

The web UI is reachable the same way at <http://192.168.55.1>.

The same cable also carries a serial login console — see [USB-C Console](/products/embedded-computers/ark-just-a-jetson/developer/usb-c-console).

## WiFi Hotspot

On first boot, if no known WiFi network is available, the Jetson brings up a hotspot:

* **Network**: `jetson-<serial>`
* **Password**: `password`

Connect to it and open <http://jetson.local>.

{% hint style="info" %}
**MHF4 antenna cables are required for WiFi and are not included.** Compatible MHF4 to RP-SMA cables: [option 1](https://www.amazon.com/female-Pigtail-Antenna-Extension-wireless/dp/B07GTL2G69), [option 2](https://www.amazon.com/dp/B076SGTMFS).
{% endhint %}

## Ethernet

Plug the Ethernet port into your network — the Jetson requests an address over DHCP.

Once the Jetson is on your network:

```bash
ssh jetson@jetson.local
```


# Get Online

## From ARK-UI

Open <http://jetson.local> (or <http://192.168.55.1> over USB-C) and join a network from the **Connections** page:

<figure><img src="/files/osyXWg6wonr7N6RblBS4" alt=""><figcaption><p>ARK-UI Connections page</p></figcaption></figure>

## From the Command Line

Scan for networks:

```bash
sudo nmcli device wifi
```

Connect to a network:

```bash
sudo nmcli device wifi connect 'SSID' password 'PASSWORD'
```

## Sharing Your PC's Internet over USB

The kernel repo ships a helper that NATs the Jetson's traffic out through your host PC's WiFi — see [share\_wifi.sh](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/scripts/share_wifi.sh).

You can also bake a WiFi profile into the image before flashing with `./scripts/add_wifi_network.sh JAJ <ssid> <password>`.


# Using ARK-OS

[ARK-OS](/software/ark-os) is preinstalled on every bundle: MAVLink routing, video streaming, flight log management, firmware updates, and network RTK corrections, plus the ARK-UI web interface at <http://jetson.local>.

* [ARK-OS and ARK-UI](/software/ark-os)
* [Services](/software/ark-os/services) — what each service does, and which are enabled by default
* [Apt: Hold Back Risky Packages](/software/ark-os/apt-hold-back) — read before running `apt upgrade`

## On This Carrier

* [Updating the Flight Controller Firmware](/products/embedded-computers/ark-just-a-jetson/using-ark-os/updating-the-flight-controller-firmware)


# Updating the Flight Controller Firmware

Flash PX4 or ArduPilot firmware on a USB-connected flight controller.

The Just a Jetson has no onboard flight controller, but ARK-OS can flash one connected over USB.

## From the Web UI

Open the [ARK-UI](http://jetson.local) **Autopilot** page, select the **Firmware** tab, and upload a `.px4` or `.apj` firmware file.

<figure><img src="/files/Zb85j85arfC2dlHoXmGl" alt=""><figcaption></figcaption></figure>

## From the Command Line

SSH into the Jetson and run the ARK-OS flashing tool (on `PATH`):

```bash
flash_firmware.sh <firmware.px4>
```

## Firmware Binaries

* **PX4**: [PX4 releases page](https://github.com/PX4/PX4-Autopilot/releases/)
* **ArduPilot**: [firmware.ardupilot.org](https://firmware.ardupilot.org/)


# Hardware Reference

* [Pinout](/products/embedded-computers/ark-just-a-jetson/hardware/pinout)
* [Ports and Serial](/products/embedded-computers/ark-just-a-jetson/hardware/connections) — USB-C modes and the UART map
* [Block Diagram](/products/embedded-computers/ark-just-a-jetson/hardware/block-diagram)
* [3D Model](/products/embedded-computers/ark-just-a-jetson/hardware/3d-model)
* [GPIO Control](/products/embedded-computers/ark-just-a-jetson/hardware/gpio-control)
* [Camera Overlays](/products/embedded-computers/ark-just-a-jetson/hardware/camera-overlays)
* [IMU ICM-42688P Guide](/products/embedded-computers/ark-just-a-jetson/hardware/imu-icm-42688p-guide) — the onboard IMU on SPI1
* [INA238 Power Monitor Guide](/products/embedded-computers/ark-just-a-jetson/hardware/ina238-power-monitor-guide) — carrier rail monitoring over I2C
* [Power Cycling USB Ports](/products/embedded-computers/ark-just-a-jetson/hardware/power-cycling-usb-ports)


# Pinout

<figure><img src="/files/p0XyvlSeJaYrbRiiDNky" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/mg1vJT4M2eHZOkLbt0OZ" alt=""><figcaption></figcaption></figure>

{% file src="/files/vE3uMIcMKGlrHxeWElJe" %}

#### BAT IN - XT60

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>+</td><td>VBAT_IN</td><td>5.5V - 75V</td></tr><tr><td>-</td><td>GND</td><td>GND</td></tr></tbody></table>

#### BAT OUT - XT30

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>+</td><td>VBAT_OUT</td><td>VBAT_IN</td></tr><tr><td>-</td><td>GND</td><td>GND</td></tr></tbody></table>

#### 5V IN - 6 Pin Molex CLIK-Mate

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VBRICK1</td><td>5.0V</td></tr><tr><td>2</td><td>VBRICK1</td><td>5.0V</td></tr><tr><td>3</td><td>I2C0_SCL_PWR_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>I2C0_SDA_PWR_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>GND</td><td>GND</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### Fan - 4 Pin PicoBlade

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>GND</td><td>GND</td></tr><tr><td>2</td><td>VDD_5V_JPERIPH</td><td>5.0V</td></tr><tr><td>3</td><td>FAN_TACH_CON</td><td>5.0V</td></tr><tr><td>4</td><td>FAN_PWM_Q*</td><td>5.0V</td></tr></tbody></table>

#### UART0/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH</td><td>5.0V</td></tr><tr><td>2</td><td>UART0_TXD_3V3</td><td>3.3V</td></tr><tr><td>3</td><td>UART0_RXD_3V3</td><td>3.3V</td></tr><tr><td>4</td><td>UART0_CTS_3V3</td><td>3.3V</td></tr><tr><td>5</td><td>UART0_RTS_3V3</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### UART1/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH_2</td><td>5.0V</td></tr><tr><td>2</td><td>UART1_TXD_3V3</td><td>3.3V</td></tr><tr><td>3</td><td>UART1_RXD_3V3</td><td>3.3V</td></tr><tr><td>4</td><td>UART1_CTS_3V3</td><td>3.3V</td></tr><tr><td>5</td><td>UART1_RTS_3V3</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### UART2/I2C0 - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH_2</td><td>5.0V</td></tr><tr><td>2</td><td>UART2_TXD_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>UART2_RXD_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>I2C0_SCL_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>I2C0_SDA_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### CAM1/CSI2- 22 Pin 0.5mm FFC

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>GND</td><td>GND</td></tr><tr><td>2</td><td>CSI2_D0_N</td><td>1.2V</td></tr><tr><td>3</td><td>CSI2_D0_P</td><td>1.2V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr><tr><td>5</td><td>CSI2_D1_N</td><td>1.2V</td></tr><tr><td>6</td><td>CSI2_D1_P</td><td>1.2V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr><tr><td>8</td><td>CSI2_CLK_N</td><td>1.2V</td></tr><tr><td>9</td><td>CSI2_CLK_P</td><td>1.2V</td></tr><tr><td>10</td><td>GND</td><td>GND</td></tr><tr><td>11</td><td>CSI3_D0_N</td><td>1.2V</td></tr><tr><td>12</td><td>CSI3_D0_P</td><td>1.2V</td></tr><tr><td>13</td><td>GND</td><td>GND</td></tr><tr><td>14</td><td>CSI3_D1_N</td><td>1.2V</td></tr><tr><td>15</td><td>CSI3_D1_P</td><td>1.2V</td></tr><tr><td>16</td><td>GND</td><td>GND</td></tr><tr><td>17</td><td>CAM1_PWDN_3V3</td><td>3.3V</td></tr><tr><td>18</td><td>CAM1_MCLK</td><td>1.8V</td></tr><tr><td>19</td><td>GND</td><td>GND</td></tr><tr><td>20</td><td>CAM1_SCL</td><td>3.3V</td></tr><tr><td>21</td><td>CAM1_SDA</td><td>3.3V</td></tr><tr><td>22</td><td>3.3V</td><td>3.3V (1A)</td></tr></tbody></table>

#### CAM0/CSI0- 22 Pin 0.5mm FFC

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>GND</td><td>GND</td></tr><tr><td>2</td><td>CSI1_D0_N</td><td>1.2V</td></tr><tr><td>3</td><td>CSI1_D0_P</td><td>1.2V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr><tr><td>5</td><td>CSI1_D1_N</td><td>1.2V</td></tr><tr><td>6</td><td>CSI1_D1_P</td><td>1.2V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr><tr><td>8</td><td>CSI1_CLK_N</td><td>1.2V</td></tr><tr><td>9</td><td>CSI1_CLK_P</td><td>1.2V</td></tr><tr><td>10</td><td>GND</td><td>GND</td></tr><tr><td>11</td><td>CSI0_D0_N</td><td>1.2V</td></tr><tr><td>12</td><td>CSI0_D0_P</td><td>1.2V</td></tr><tr><td>13</td><td>GND</td><td>GND</td></tr><tr><td>14</td><td>CSI0_D1_N</td><td>1.2V</td></tr><tr><td>15</td><td>CSI0_D1_P</td><td>1.2V</td></tr><tr><td>16</td><td>GND</td><td>GND</td></tr><tr><td>17</td><td>CAM0_PWDN_3V3</td><td>3.3V</td></tr><tr><td>18</td><td>CAM0_MCLK</td><td>1.8V</td></tr><tr><td>19</td><td>GND</td><td>GND</td></tr><tr><td>20</td><td>CAM0_SCL</td><td>3.3V</td></tr><tr><td>21</td><td>CAM0_SDA</td><td>3.3V</td></tr><tr><td>22</td><td>3.3V</td><td>3.3V (1A)</td></tr></tbody></table>

#### SPI/GPIO - 7 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH</td><td>5.0V</td></tr><tr><td>2</td><td>SPI0_MOSI_3V3</td><td>3.3V</td></tr><tr><td>3</td><td>SPI0_SCK_3V3</td><td>3.3V</td></tr><tr><td>4</td><td>SPI0_MISO_3V3</td><td>3.3V</td></tr><tr><td>5</td><td>SPI0_CS0n_3V3</td><td>3.3V</td></tr><tr><td>6</td><td>SPI0_CS1n_3V3</td><td>3.3V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr></tbody></table>

#### I2S/GPIO - 7 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH_2</td><td>5.0V</td></tr><tr><td>2</td><td>I2S0_DOUT_3V3</td><td>3.3V</td></tr><tr><td>3</td><td>I2S0_DIN_3V3</td><td>3.3V</td></tr><tr><td>4</td><td>I2S0_LRCLK_3V3</td><td>3.3V</td></tr><tr><td>5</td><td>I2S0_SCLK_3V3</td><td>3.3V</td></tr><tr><td>6</td><td>AUD_MCLK_3V3</td><td>3.3V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr></tbody></table>

#### CAN - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_JPERIPH</td><td>5.0V</td></tr><tr><td>2</td><td>JCAN_P</td><td>5.0V</td></tr><tr><td>3</td><td>JCAN_N</td><td>5.0V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### USB - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>USB1_VBUS</td><td>5.0V</td></tr><tr><td>2</td><td>HUB_USB1_N</td><td>3.3V</td></tr><tr><td>3</td><td>HUB_USB1_P</td><td>3.3V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### USB - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>USB3_VBUS</td><td>5.0V</td></tr><tr><td>2</td><td>HUB_USB3_N</td><td>3.3V</td></tr><tr><td>3</td><td>HUB_USB3_P</td><td>3.3V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### PCIE - 16 Pin FFC 5051101692

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5V_PCIE_FFC</td><td>5.0V</td></tr><tr><td>2</td><td>5V_PCIE_FFC</td><td>5.0V</td></tr><tr><td>3</td><td>GND</td><td>GND</td></tr><tr><td>4</td><td>PCIE2_CLK_P</td><td>1.0V</td></tr><tr><td>5</td><td>PCIE2_CLK_N</td><td>1.0V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr><tr><td>7</td><td>PCIE2_RX0_P</td><td>1.0V</td></tr><tr><td>8</td><td>PCIE2_RX0_N</td><td>1.0V</td></tr><tr><td>9</td><td>GND</td><td>GND</td></tr><tr><td>10</td><td>PCIE2_TX0_P</td><td>1.0V</td></tr><tr><td>11</td><td>PCIE2_TX0_N</td><td>1.0V</td></tr><tr><td>12</td><td>GND</td><td>GND</td></tr><tr><td>13</td><td>PCIE2_PWR_EN_3V3</td><td>3.3V</td></tr><tr><td>14</td><td>PCIE_WAKE</td><td>3.3V</td></tr><tr><td>15</td><td>PCIE2_CLKREQ</td><td>3.3V</td></tr><tr><td>16</td><td>PCIE2_RST*</td><td>3.3V</td></tr></tbody></table>


# Ports and Serial

## USB C

The USB-C port supports dual role operation, functioning as both host and device. In device mode it provides networking, a serial console, and an `L4T-README` drive — see [Connect](/products/embedded-computers/ark-just-a-jetson/setup/connect) and [USB-C Console](/products/embedded-computers/ark-just-a-jetson/developer/usb-c-console).

## Serial Ports

<table><thead><tr><th width="101">Connector</th><th width="152">Port</th><th width="198">Available Signals</th><th>Function</th></tr></thead><tbody><tr><td>UART0</td><td>/dev/ttyTHS3</td><td>RX/TX/RTS/CTS</td><td>User Available</td></tr><tr><td>UART1</td><td>/dev/ttyTHS1</td><td>RX/TX/RTS/CTS</td><td>User Available</td></tr><tr><td>UART2</td><td>/dev/ttyTHS2</td><td>RX/TX</td><td>Linux Console (Reserved)</td></tr></tbody></table>


# IMU ICM-42688P Guide

The onboard ICM-42688P IMU is connected to SPI1 on the Just a Jetson and shows up in Linux as `/dev/spidev1.0`. See the [pinmux spreadsheet](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/products/JAJ/Jetson_Orin_NX_and_Orin_Nano_series_Pinmux_Config_Jetpack_6.xlsm) for the GPIO assignments.

To enable the SPI bus, enable **spi3** with the Jetson Expansion Header Tool and reboot:

```
sudo /opt/nvidia/jetson-io/jetson-io.py
```

```
Configure Jetson 40pin Header
Configure header pins manually
```

```
  =================== Jetson Expansion Header Tool ===================
 |                                                                    |
 |                                                                    |
 |                Select desired functions (for pins):                |
 |                                                                    |
 |                [ ] aud            (7)                              |
 |                [ ] extperiph3_clk (29)                             |
 |                [ ] extperiph4_clk (31)                             |
 |                [ ] i2s2           (12,35,38,40)                    |
 |                [ ] pwm1           (15)                             |
                  [ ] pwm5           (33)                             |
 |                [ ] pwm7           (32)                             |
 |                [ ] spi1           (19,21,23,24,26)                 |
 |                [*] spi3           (13,16,18,22,37)                 |
 |                [*] uarta-cts/rts  (11,36)                          |
 |                                                                    |
 |                                Back                                |
 |                                                                    |
  ====================================================================
```

To read the IMU, run the test script that ships with ARK-OS (on `PATH`):

```
icm42688p_test.py
```

Source: [icm42688p\_test.py](https://github.com/ARK-Electronics/ARK-OS/blob/main/platform/jetson/scripts/extras/icm42688p_test.py)


# INA238 Power Monitor Guide

The INA238 power monitor is connected to I2C bus 1, which is Linux bus 7, at address `0x45`:

```
sudo i2cdetect -y -r 7
```

Always pass `-r` — without it, `i2cdetect` skips the `0x40–0x4F` range on Tegra. See the [I2C bus map](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/i2c.md) for which connector maps to which Linux bus.

To read voltage, current, and power, run the test script that ships with ARK-OS (on `PATH`):

```
ina238_test.py
```

Source: [ina238\_test.py](https://github.com/ARK-Electronics/ARK-OS/blob/main/platform/jetson/scripts/extras/ina238_test.py)


# Block Diagram

<figure><img src="/files/7ABYIn3dihWvNj09xHTq" alt=""><figcaption><p>Block diagram</p></figcaption></figure>


# 3D Model

Step files can be found here\
<https://github.com/ARK-Electronics/just_a_jetson>


# GPIO Control

The I2S/GPIO connector pins come up as general-purpose GPIOs by default — no overlay or jetson-io step is needed. At idle the SoC drives none of them: the four output-capable pins sit hi-z, held HIGH by 604Ω pull-ups on the carrier, and DIN is a floating input. A pin wired to a relay or actuator never transitions at boot.

## I2S/GPIO Connector Pin Mapping

| ARK Pin | Signal              | 40-Pin Header | libgpiod Name | Idle at Boot  |
| ------- | ------------------- | ------------- | ------------- | ------------- |
| 1       | VDD\_5V\_JPERIPH\_2 | -             | -             | -             |
| 2       | I2S0\_DOUT\_3V3     | Pin 40        | `PI.00`       | HIGH (pulled) |
| 3       | I2S0\_DIN\_3V3      | Pin 38        | `PI.01`       | hi-z (input)  |
| 4       | I2S0\_LRCLK\_3V3    | Pin 35        | `PI.02`       | HIGH (pulled) |
| 5       | I2S0\_SCLK\_3V3     | Pin 12        | `PH.07`       | HIGH (pulled) |
| 6       | AUD\_MCLK\_3V3      | Pin 7         | `PAC.06`      | HIGH (pulled) |
| 7       | GND                 | -             | -             | -             |

Confirm the lines are exposed:

```bash
sudo gpioinfo | grep -E '"P(H\.07|I\.0[0-2]|AC\.06)"'
```

## Using the GPIOs

Drive and read the lines with `libgpiod` (`gpioset` / `gpioget`) or the Jetson.GPIO Python library. Jetson.GPIO addresses pins by their 40-pin header number and needs version 2.1.12 or newer:

```bash
sudo pip3 install 'Jetson.GPIO>=2.1.12'
```

The example below jumpers HDR40 pin 40 (DOUT) to pin 38 (DIN) and toggles HIGH/LOW, reading each transition back as a loopback test:

```python
import time
import Jetson.GPIO as GPIO

GPIO.setmode(GPIO.BOARD)
GPIO.setup(40, GPIO.OUT, initial=GPIO.LOW)  # I2S0_DOUT
GPIO.setup(38, GPIO.IN)                     # I2S0_DIN

try:
    for level in (GPIO.HIGH, GPIO.LOW, GPIO.HIGH, GPIO.LOW):
        GPIO.output(40, level)
        time.sleep(0.2)
        got = GPIO.input(38)
        print(f"wrote {level} read {got} {'PASS' if got == level else 'FAIL'}")
finally:
    GPIO.cleanup()
```

ARK-OS ships a complete version of this loopback as `i2s_gpio_example.py` (on `PATH`).

{% hint style="warning" %}
**GPIO state after your app exits**

While your app owns a line, the kernel guarantees its value. On release (clean exit, crash, or kill), **the pin retains its last-written value** until the next reboot re-asserts the pulled-HIGH idle state. If a line must be safe-off for an active-high load, add an external pull-down or keep a process owning the line (`gpioset --mode=signal`).
{% endhint %}

For the full pin reference, electrical details, and safe-state patterns, see the [ARK Jetson Kernel GPIO docs](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/gpio.md).


# Camera Overlays

The ARK Just A Jetson has **2× dual-lane CSI ports** on 22-pin FFC connectors. Camera configuration is managed through device tree overlays, and the image ships with the **IMX219 dual** overlay active — IMX219 cameras work on both ports out of the box.

## Supported Cameras

| Sensor | Resolution | Overlay            | Status            |
| ------ | ---------- | ------------------ | ----------------- |
| IMX219 | 3280x2464  | Camera IMX219 Dual | Working (default) |
| IMX477 | 4056x3040  | Camera IMX477 Dual | Working           |
| IMX708 | 4608x2592  | Camera IMX708 Dual | Working           |

See [cameras.md](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/cameras.md) in the kernel repo for sensor details, verification commands, and known issues.

## Switching Overlays

List the overlays available on your Jetson:

```bash
sudo /opt/nvidia/jetson-io/config-by-hardware.py -l
```

Apply one and reboot:

```bash
sudo /opt/nvidia/jetson-io/config-by-hardware.py -n 2="Camera IMX477 Dual"
sudo reboot
```

## Verifying a Camera

Check that the sensor is detected:

```bash
nvargus_nvraw --lps
```

ARK-OS also ships `check_cameras.sh` (on `PATH`) which stream-tests every connected CSI camera, and the [ARK-UI](http://jetson.local) **Video** page shows a live stream of the first camera.

## Custom Overlays

To build your own camera overlay — or install one on an already-flashed system — follow [camera\_overlays.md](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/camera_overlays.md) in the kernel repo.


# Power Cycling USB Ports

The hub-connected USB ports can be power cycled from the command line with [uhubctl](https://github.com/mvp/uhubctl).

List the hubs and ports that support power switching:

```
sudo uhubctl
```

Cycle power on a port:

```
sudo uhubctl -l <hub> -p <port> -a off
sudo uhubctl -l <hub> -p <port> -a on
```


# Developer Guide

* [Flashing Guide](/products/embedded-computers/ark-just-a-jetson/developer/flashing-guide) — flash a prebuilt release, or build from source
* [USB-C Console](/products/embedded-computers/ark-just-a-jetson/developer/usb-c-console) — serial login over the USB cable
* [USB Peripherals](/knowledge-base/knowledge-base/usb-peripherals) — tested Wi-Fi and Bluetooth adapters, USB camera EMI
* [Apt: Hold Back Risky Packages](/software/ark-os/apt-hold-back) — keep `apt upgrade` from overwriting the ARK kernel


# Flashing Guide

Bundles ship pre-flashed with the ARK Jetson image and ARK-OS. Follow this guide to update to a newer release or to flash a Jetson for the first time.

The image is built from the [ark\_jetson\_kernel](https://github.com/ARK-Electronics/ark_jetson_kernel) repository, which adds the carrier's device tree to NVIDIA's JetPack. One image covers every Orin Nano/NX module variant.

{% hint style="info" %}
A stock NVIDIA JetPack image will not enable all carrier hardware — use the ARK image, or build from source with the ARK device tree.
{% endhint %}

## Enter Recovery Mode

Connect the **USB-C** port to your host PC, then power on the Jetson while holding the **Force Recovery** button.

## Flash a Prebuilt Release (recommended)

On a Debian/Ubuntu host, download the flasher script and flash the latest JAJ release to the NVMe SSD:

```bash
curl -LO https://raw.githubusercontent.com/ARK-Electronics/ark_jetson_kernel/main/packaging/flash_from_package.sh
chmod +x flash_from_package.sh
./flash_from_package.sh jaj
```

The script downloads the release package from the [releases page](https://github.com/ARK-Electronics/ark_jetson_kernel/releases) (tags starting with `jaj-`), waits for the Jetson in recovery mode, and flashes the bootloader and root filesystem. No build tools needed. Pass a specific tag instead of `jaj` to flash a specific version.

## Build From Source

To customize the kernel, device tree, or preinstalled software, build and flash from source — see the [ark\_jetson\_kernel README](https://github.com/ARK-Electronics/ark_jetson_kernel#build--flash):

```bash
./setup.sh          # one-time download of BSP + rootfs + sources
./build.sh JAJ      # build and provision the image (installs ARK-OS)
./flash.sh JAJ      # flash to NVMe (--sdcard and --usb also available)
```

You can bake a WiFi profile into the image before flashing with `./scripts/add_wifi_network.sh JAJ <ssid> <password>`.


# USB-C Console

Plugged into a host PC, the Jetson enumerates as one USB composite device (`0955:7020`) providing four functions:

| Function                   | Host sees                                             |
| -------------------------- | ----------------------------------------------------- |
| RNDIS + CDC-NCM networking | Two USB Ethernet interfaces; Jetson at `192.168.55.1` |
| CDC-ACM serial             | Virtual COM port with a login console                 |
| Mass storage               | `L4T-README` drive                                    |

## Serial Console

Use the `by-id` path — the `ttyACM` number changes between sessions:

```bash
ls -l /dev/serial/by-id/
usb-NVIDIA_Linux_for_Tegra_1613223640377-if02 -> ../../ttyACM1
```

```bash
screen /dev/serial/by-id/usb-NVIDIA_Linux_for_Tegra_*-if02 115200
```

Log in with your username and password (default `jetson` / `jetson`). Your user must be in the `dialout` group.

On macOS the port is `/dev/tty.usbmodem*`; on Windows it is a `COMx` port in Device Manager.

{% hint style="info" %}
This is not a boot console. The gadget (`nv-l4t-usb-device-mode.service`) and login prompt (`serial-getty@ttyGS0.service`) start under `multi-user.target`, so there is no UEFI, bootloader, or early kernel output — and no port at all if boot hangs before that point. For boot-level debugging use UART2 (`/dev/ttyTHS2`), see [Connections](/products/embedded-computers/ark-just-a-jetson/hardware/connections).
{% endhint %}


# ARK Just a Pi

The ARK Just A Pi is a compact carrier board for the Raspberry Pi Compute Module 5. It provides essential connectivity including USB, Ethernet, CSI cameras, UART, PCIE, HDMI, and GPIO in a minimal form factor.

See the [Getting Started](/products/embedded-computers/ark-just-a-pi/getting-started) guide to begin using your ARK Just A Pi.


# Getting Started

The ARK Just A Pi is a compact carrier board for the Raspberry Pi Compute Module 5. This guide covers preparing the board and connecting to it for the first time.

## Flashing the Compute Module

If you are installing your own Compute Module, follow the [Flashing Guide](/products/embedded-computers/ark-just-a-pi/flashing-guide) to image the CM5 (micro SD for the CM5 Lite, or eMMC over USB-C) and prepare it for first boot.

If you set up the OS using the Raspberry Pi Imager customization options described in the flashing guide, the board comes up with:

* **Username**: `pi`
* **Password**: `pi`
* **Hostname**: `just-a-pi`

## Connecting

### Serial Debug Console

The **UART0 Debug** connector (6-pin JST-GH) exposes the Compute Module's serial console at 3.3V. Connect a 3.3V USB-to-serial adapter to reach the console before the network is configured. See the [Pinout](/products/embedded-computers/ark-just-a-pi/pinout) for the connector pin assignments.

### SSH over the network

Once Wi-Fi or Ethernet is configured (see [Wi-Fi Setup](/products/embedded-computers/ark-just-a-pi/flashing-guide/wi-fi-setup) and [SSH](/products/embedded-computers/ark-just-a-pi/flashing-guide/ssh)), connect over SSH:

```bash
ssh pi@just-a-pi.local
```

If mDNS is not available on your network, use the Pi's IP address instead.

## Next Steps

* [Flashing Guide](/products/embedded-computers/ark-just-a-pi/flashing-guide) – Image the Compute Module and prepare it for first boot
* [Pinout](/products/embedded-computers/ark-just-a-pi/pinout) – Connector and pin assignments
* [Block Diagram](/products/embedded-computers/ark-just-a-pi/block-diagram) – Board architecture overview
* [3D Model](/products/embedded-computers/ark-just-a-pi/3d-model) – STEP files


# Flashing Guide

If you purchased just the Just a Pi and are installing your own Pi:

{% content-ref url="/pages/zbZscLqO3bK3iiubqEtp" %}
[Pi CM5 Lite with Micro SD](/products/embedded-computers/ark-just-a-pi/flashing-guide/pi-cm5-lite-with-micro-sd)
{% endcontent-ref %}

{% content-ref url="/pages/MJINAbKNd4AgtMyufIsO" %}
[Pi CM5 with EMMC](/products/embedded-computers/ark-just-a-pi/flashing-guide/pi-cm5-with-emmc)
{% endcontent-ref %}


# Pi CM5 Lite with Micro SD

When using a Pi CM5 Lite without EMMC, a micro SD must be used for the OS. Follow the normal steps for flashing a micro SD using the Raspberry Pi Imager.

{% embed url="<https://www.raspberrypi.com/software/>" %}

If using Ubuntu:

```
wget -O pi_imager.deb https://downloads.raspberrypi.org/imager/imager_latest_amd64.deb && sudo dpkg -i pi_imager.deb && rm pi_imager.deb
```

{% hint style="warning" %}
Select **Raspberry Pi OS (Legacy, 64-bit)**, which is based on Debian Bookworm. Newer Raspberry Pi OS releases based on Debian Trixie are not yet verified on this board.
{% endhint %}

Apply OS customization to configure WiFi and enable SSH:

* Set the default hostname:

```
just-a-pi
```

* Set the Wifi:\
  It is recommended to add a Dummy Wifi to turn on the Wifi radio, it does not have to be a reachable/ functioning network.\
  Otherwise it can be turned on using the following command once you have ssh-d to the Pi using the debug port.

```
sudo nmcli radio wifi on
```

* Set the default **username (pi)** and **password (pi)**
* Enable SSH

<figure><img src="/files/FbhVfNfcfkHHNeapKaA0" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/apdAXEwy5wDJ0W2riuGj" alt=""><figcaption></figcaption></figure>

After flashing the SD card is complete, you will need to modify the **/boot/firmware/config.txt** file on the SD card before installing it into the Pi. See [**After Flashing, Before Installing**](/products/embedded-computers/ark-just-a-pi/flashing-guide/after-flashing-before-installing)**.**


# Pi CM5 with EMMC

When using Pi CM5 with EMMC, it must be flashed through the USB-C port on the board. Hold the BOOT button while powering on the board (you can release it a few seconds after power is applied), then follow the steps at the link below.

{% embed url="<https://www.raspberrypi.com/documentation/computers/compute-module.html#flashing-the-compute-module-emmc>" %}

Once complete follow the steps at [After Flashing, Before Installing](/products/embedded-computers/ark-just-a-pi/flashing-guide/after-flashing-before-installing)


# After Flashing, Before Installing

After flashing the SD/EMMC you must modify the config.txt in order for the ARK Just a Pi to function properly.

Edit **/boot/firmware/config.txt**

Comment out the following lines

```
# Automatically load overlays for detected cameras
# camera_auto_detect=1

# Automatically load overlays for detected DSI displays
# display_auto_detect=1
```

Add the following

```
# ---- Board power/enable lines (ARK PiCM5 Carrier) ----
# Enable KSZ8794 Ethernet switch 1.2V rail
gpio=27=op,dh
# Release Ethernet switch from reset
gpio=20=op,dh
# Enable 3.3V camera rail feeding both CSI connectors
gpio=22=op,dh

# CAM0 = J2 on MIPI0 (I2C0), CAM1 = J1 on MIPI1 (ID_SD/ID_SC). Swap imx219 for your sensor.
dtoverlay=imx219,cam0
dtoverlay=imx219,cam1

# ---- UARTs ----
enable_uart=1                 # UART0 debug console, J6 (GPIO14/15)
dtoverlay=uart2,ctsrts        # UART2/SPI3, flow control (GPIO4-7)
dtoverlay=uart3,ctsrts        # UART3/SPI4, flow control (GPIO8-11)
dtoverlay=uart4               # UART4, TX/RX only (GPIO12/13) doesn't work on cm5 needs rc.local on boot

# PCIe FFC — off by default on CM5
dtparam=pciex1
dtparam=pciex1_gen=3          # only if your endpoint is Gen3-clean

# USB2 host port VBUS — needed to power downstream devices
gpio=24=op,dh

# Enable the Fan
dtparam=cooling_fan=on
dtparam=fan_temp0=40000        # 40.0 °C, was 50000
dtparam=fan_temp0_speed=120    # 0-255, was 75
dtparam=fan_temp1=50000
dtparam=fan_temp2=60000
dtparam=fan_temp3=70000

# Drive the power LED on by default
dtparam=pwr_led_trigger=default-on
```


# Wi-Fi Setup

If WiFi was not setup via the OS Customization options in the Pi Imager UI you can follow these steps to setup your network.

Mount the SD card or EMMC on your computer and open the root filesystem directory.

## Bookworm

Create a new NeworkManager connection profile in **/etc/NetworkManager/system-connections/**

Name the file **YourNetworkSSID**.nmconnection and make sure to replace **YourNetworkSSID** and **YourNetworkPassword**.

```
[connection]
id=YourNetworkSSID
uuid=0e214bd8-4501-4394-9a46-123badc0ffee
type=wifi

[wifi]
mode=infrastructure
ssid=YourNetworkSSID

[wifi-security]
key-mgmt=wpa-psk
psk=YourNetworkPassword

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]
```

## Prior to Bookworm

Create a file called **wpa\_supplicant.conf**

Edit the file in a text editor.

Replace `<YOUR TWO LETTER COUNTRY CODE>` with your country code, ie `US`.

Replace `<YOUR NETWORK NAME>` and `<YOUR NETWORK PASSWORD>` with your network info.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=<YOUR TWO LETTER COUNTRY CODE>

network={
    ssid="<YOUR NETWORK NAME>"
    psk="<YOUR NETWORK PASSWORD>"
    key_mgmt=WPA-PSK
}

```

Save the file. On the next boot of the Pi, it will move the file to **/etc/wpa\_supplicant/**


# SSH

If SSH was not setup via the OS Customization options in the Pi Imager UI you can follow these steps to setup SSH.

To enable SSH, mount the SD card or EMMC on your computer and open the root directory.

Create a file named `ssh` on the root of the SD Card.


# Pinout

<figure><img src="/files/BTn2Qel82gjQa3CsH947" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/IvwlmK4QzIS2GB9RrAYw" alt=""><figcaption></figcaption></figure>

{% file src="/files/rEk5tGTkkooCudUB5EDI" %}

#### POWER - 6 Pin Molex CLIK-Mate

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V</td></tr><tr><td>2</td><td>VDD_5V_IN</td><td>5.0V</td></tr><tr><td>3</td><td>PI_SCL1_PWR_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>PI_SDA1_PWR_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>GND</td><td>GND</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### Fan - 4 Pin JST\_SH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V (500mA)</td></tr><tr><td>2</td><td>FAN_PWM</td><td>5.0V</td></tr><tr><td>3</td><td>GND</td><td>GND</td></tr><tr><td>4</td><td>FAN_TACHO</td><td>5.0V</td></tr></tbody></table>

#### UART0 DEBUG/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="304">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V (500mA)</td></tr><tr><td>2</td><td>UART0_TX/GPIO14</td><td>3.3V</td></tr><tr><td>3</td><td>UART0_RX/GPIO15</td><td>3.3V</td></tr><tr><td>4</td><td>UART0_CTS/GPIO16</td><td>3.3V</td></tr><tr><td>5</td><td>UART0_RTS/GPIO17</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### UART2/SPI3/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="302">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V (500mA)</td></tr><tr><td>2</td><td>UART2_TXD/SPI3_CSn/GPIO4</td><td>3.3V</td></tr><tr><td>3</td><td>UART2_RXD/SPI3_MISO/GPIO5</td><td>3.3V</td></tr><tr><td>4</td><td>UART2_CTS/SPI3_MOSI/GPIO6</td><td>3.3V</td></tr><tr><td>5</td><td>UART2_RTS/SPI3_SCLK/GPIO7</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### UART3/SPI4/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="296">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V (500mA)</td></tr><tr><td>2</td><td>UART3_TXD/SPI4_CSn/GPIO8</td><td>3.3V</td></tr><tr><td>3</td><td>UART3_RXD/SPI4_MISO/GPIO9</td><td>3.3V</td></tr><tr><td>4</td><td>UART3_CTS/SPI4_MOSI/GPIO10</td><td>3.3V</td></tr><tr><td>5</td><td>UART3_RTS/SPI4_SCLK/GPIO11</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### UART4/PWM/GPIO - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="296">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VDD_5V_IN</td><td>5.0V (500mA)</td></tr><tr><td>2</td><td>UART4_TXD/PWM0/GPIO12</td><td>3.3V</td></tr><tr><td>3</td><td>UART4_RXD/PWM1/GPIO13</td><td>3.3V</td></tr><tr><td>4</td><td>PWM2/GPIO18</td><td>3.3V</td></tr><tr><td>5</td><td>PWM3/GPIO19</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### CAM1/CSI0- 22 Pin 0.5mm FFC

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>GND</td><td>GND</td></tr><tr><td>2</td><td>MIPI0_D0_N</td><td>1.2V</td></tr><tr><td>3</td><td>MIPI0_D0_P</td><td>1.2V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr><tr><td>5</td><td>MIPI0_D1_N</td><td>1.2V</td></tr><tr><td>6</td><td>MIPI0_D1_P</td><td>1.2V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr><tr><td>8</td><td>MIPI0_C_N</td><td>1.2V</td></tr><tr><td>9</td><td>MIPI0_C_P</td><td>1.2V</td></tr><tr><td>10</td><td>GND</td><td>GND</td></tr><tr><td>11</td><td>MIPI0_D2_N</td><td>1.2V</td></tr><tr><td>12</td><td>MIPI0_D2_P</td><td>1.2V</td></tr><tr><td>13</td><td>GND</td><td>GND</td></tr><tr><td>14</td><td>MIPI0_D3_N</td><td>1.2V</td></tr><tr><td>15</td><td>MIPI0_D3_P</td><td>1.2V</td></tr><tr><td>16</td><td>GND</td><td>GND</td></tr><tr><td>17</td><td>CAM_GPIO0</td><td>3.3V</td></tr><tr><td>18</td><td>CAM_GPIO1</td><td>3.3V</td></tr><tr><td>19</td><td>GND</td><td>GND</td></tr><tr><td>20</td><td>SCL0</td><td>3.3V</td></tr><tr><td>21</td><td>SDA0</td><td>3.3V</td></tr><tr><td>22</td><td>VDD_3V3_CAMERA</td><td>3.3V (1A)</td></tr></tbody></table>

#### CAM2/CSI1- 22 Pin 0.5mm FFC

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>GND</td><td>GND</td></tr><tr><td>2</td><td>MIPI1_D0_N</td><td>1.2V</td></tr><tr><td>3</td><td>MIPI1_D0_P</td><td>1.2V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr><tr><td>5</td><td>MIPI1_D1_N</td><td>1.2V</td></tr><tr><td>6</td><td>MIPI1_D1_P</td><td>1.2V</td></tr><tr><td>7</td><td>GND</td><td>GND</td></tr><tr><td>8</td><td>MIPI1_C_N</td><td>1.2V</td></tr><tr><td>9</td><td>MIPI1_C_P</td><td>1.2V</td></tr><tr><td>10</td><td>GND</td><td>GND</td></tr><tr><td>11</td><td>MIPI1_D2_N</td><td>1.2V</td></tr><tr><td>12</td><td>MIPI1_D2_P</td><td>1.2V</td></tr><tr><td>13</td><td>GND</td><td>GND</td></tr><tr><td>14</td><td>MIPI1_D3_N</td><td>1.2V</td></tr><tr><td>15</td><td>MIPI1_D3_P</td><td>1.2V</td></tr><tr><td>16</td><td>GND</td><td>GND</td></tr><tr><td>17</td><td>Pulled up to 3.3V via 1.5k Ohm Resistor</td><td>3.3V</td></tr><tr><td>18</td><td>NC</td><td>NC</td></tr><tr><td>19</td><td>GND</td><td>GND</td></tr><tr><td>20</td><td>ID_SC</td><td>3.3V</td></tr><tr><td>21</td><td>ID_SD</td><td>3.3V</td></tr><tr><td>22</td><td>VDD_3V3_CAMERA</td><td>3.3V (1A)</td></tr></tbody></table>

#### USB - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>USB2_VBUS</td><td>5.0V (1A)</td></tr><tr><td>2</td><td>USB2_N</td><td>3.3V</td></tr><tr><td>3</td><td>USB2_P</td><td>3.3V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### ETH1 - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>EXT1_ETH_RX_N</td><td>Isolated</td></tr><tr><td>2</td><td>EXT1_ETH_RX_P</td><td>Isolated</td></tr><tr><td>3</td><td>EXT1_ETH_TX_N</td><td>Isolated</td></tr><tr><td>4</td><td>EXT1_ETH_TX_P</td><td>Isolated</td></tr></tbody></table>

#### ETH2 - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>EXT2_ETH_RX_N</td><td>Isolated</td></tr><tr><td>2</td><td>EXT2_ETH_RX_P</td><td>Isolated</td></tr><tr><td>3</td><td>EXT2_ETH_TX_N</td><td>Isolated</td></tr><tr><td>4</td><td>EXT2_ETH_TX_P</td><td>Isolated</td></tr></tbody></table>

#### PCIE - 16 Pin FFC CF20161V0R0-NH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5V_PCIE_FFC</td><td>5.0V (1.5A)</td></tr><tr><td>2</td><td>5V_PCIE_FFC</td><td>5.0V (1.5A)</td></tr><tr><td>3</td><td>GND</td><td>GND</td></tr><tr><td>4</td><td>PCIE_CLK_P</td><td>1.0V</td></tr><tr><td>5</td><td>PCIE_CLK_N</td><td>1.0V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr><tr><td>7</td><td>PCIE_RX_P</td><td>1.0V</td></tr><tr><td>8</td><td>PCIE_RX_N</td><td>1.0V</td></tr><tr><td>9</td><td>GND</td><td>GND</td></tr><tr><td>10</td><td>PCIE_TX_P</td><td>1.0V</td></tr><tr><td>11</td><td>PCIE_TX_N</td><td>1.0V</td></tr><tr><td>12</td><td>GND</td><td>GND</td></tr><tr><td>13</td><td>PCIE_PWR_EN</td><td>3.3V</td></tr><tr><td>14</td><td>PCIE_WAKEn</td><td>3.3V</td></tr><tr><td>15</td><td>PCIE2_CLKREQn</td><td>3.3V</td></tr><tr><td>16</td><td>PCIE2_RSTn</td><td>3.3V</td></tr></tbody></table>


# Block Diagram

<figure><img src="/files/uVMTuSVePtU7l2QB4M4I" alt=""><figcaption><p>ARK Just a Pi Block Diagram</p></figcaption></figure>


# 3D Model

Step files can be found here\
<https://github.com/ARK-Electronics/just_a_pi>


# Flight Controllers

ARK flight controllers and autopilot carrier boards for PX4, ArduPilot, and Betaflight.

{% content-ref url="/pages/6J6cWwEzre1Au5hIWae8" %}
[ARK FPV](/products/flight-controller/ark-fpv)
{% endcontent-ref %}

{% content-ref url="/pages/cC0fhOQeuUjhhp453uMD" %}
[ARKV6X](/products/flight-controller/arkv6x)
{% endcontent-ref %}

{% content-ref url="/pages/g6AeKjO11nQcU2wJWLsR" %}
[ARK Pixhawk Autopilot Bus Carrier](/products/flight-controller/ark-pixhawk-autopilot-bus-carrier)
{% endcontent-ref %}

{% content-ref url="/pages/5fmpxMUTz0ILwNZVhXDT" %}
[ARK Jetson PAB Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier)
{% endcontent-ref %}

{% content-ref url="/pages/UzgcAv6bqVlPHboUz3QG" %}
[ARK Jetson PAB Carrier V3](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3)
{% endcontent-ref %}

{% content-ref url="/pages/058wj5KxrgTfxEYFZT5t" %}
[ARK Pi6X Flow](/products/flight-controller/ark-pi6x-flow)
{% endcontent-ref %}

{% content-ref url="/pages/wDdCEscPz7NLUT6B7AGp" %}
[ARK VOXL2 RTK PAB Carrier](/products/flight-controller/ark-voxl2-rtk-pab-carrier)
{% endcontent-ref %}


# ARK FPV


# Pinout

<figure><img src="/files/lwOrDzm4XNY0Xj8i548g" alt=""><figcaption><p>ARK FPV Flight Controller Top</p></figcaption></figure>

<figure><img src="/files/83bxgX1MuiFBVOPCLfi8" alt=""><figcaption><p>ARK FPV Flight Controller Bottom</p></figcaption></figure>

#### UART Port Mapping

<table><thead><tr><th>UART</th><th width="187">Connector</th><th>PX4 name</th><th>Nuttx tty</th></tr></thead><tbody><tr><td>USART1</td><td>GPS</td><td>GPS1</td><td>/dev/ttyS0</td></tr><tr><td>USART2</td><td>VTX</td><td>Telem3</td><td>/dev/ttyS1</td></tr><tr><td>USART3</td><td>Debug</td><td>Debug</td><td>/dev/ttyS2</td></tr><tr><td>UART4</td><td>PWM</td><td>UART4</td><td>/dev/ttyS3</td></tr><tr><td>UART5</td><td>VTX</td><td>Telem2</td><td>/dev/ttyS4</td></tr><tr><td>USART6</td><td>RC</td><td>USART6</td><td>/dev/ttyS5</td></tr><tr><td>UART7</td><td>Telem</td><td>Telem1</td><td>/dev/ttyS6</td></tr></tbody></table>

#### PWM UART4 - 8 Pin JST-GH

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>VBAT IN</td><td>5.5V-54V</td></tr><tr><td>2</td><td>CURR_IN_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>UART4_RX_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>FMU_CH1_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>FMU_CH2_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>FMU_CH3_EXT</td><td>3.3V</td></tr><tr><td>7</td><td>FMU_CH4_EXT</td><td>3.3V</td></tr><tr><td>8</td><td>GND</td><td>GND</td></tr></tbody></table>

#### RC - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5.0V</td><td>5.0V</td></tr><tr><td>2</td><td>USART6_RX_IN_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>USART6_TX_OUTPUT_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### PWM EXTRA - 6 Pin JST-SH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>FMU_CH5_EXT</td><td>3.3V</td></tr><tr><td>2</td><td>FMU_CH6_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>FMU_CH7_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>FMU_CH8_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>FMU_CH9_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### POWER AUX - 3 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>12.0V</td><td>12.0V</td></tr><tr><td>2</td><td>GND</td><td>GND</td></tr><tr><td>3</td><td>VBAT IN/OUT</td><td>5.5V-54V</td></tr></tbody></table>

#### CAN - 4 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5.0V</td><td>5.0V</td></tr><tr><td>2</td><td>CAN1_P</td><td>5.0V</td></tr><tr><td>3</td><td>CAN1_N</td><td>5.0V</td></tr><tr><td>4</td><td>GND</td><td>GND</td></tr></tbody></table>

#### GPS - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5.0V</td><td>5.0V</td></tr><tr><td>2</td><td>USART1_TX_GPS1_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>USART1_RX_GPS1_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>I2C1_SCL_GPS1_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>I2C1_SDA_GPS1_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### TELEM - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5.0V</td><td>5.0V</td></tr><tr><td>2</td><td>UART7_TX_TELEM1_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>UART7_RX_TELEM1_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>UART7_CTS_TELEM1_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>UART7_RTS_TELEM1_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### VTX - 6 Pin JST-GH

<table><thead><tr><th width="134">Pin Number</th><th width="237">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>12.0V</td><td>12.0V</td></tr><tr><td>2</td><td>GND</td><td>GND</td></tr><tr><td>3</td><td>UART5_TX_TELEM2_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>UART5_RX_TELEM2_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>USART2_RX_TELEM3_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>

#### SPI (OSD or IMU) - 8 Pin JST-SH

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>5.0V</td><td>5.0V</td></tr><tr><td>2</td><td>SPI6_SCK_EXT</td><td>3.3V</td></tr><tr><td>3</td><td>SPI6_MISO_EXT</td><td>3.3V</td></tr><tr><td>4</td><td>SPI6_MOSI_EXT</td><td>3.3V</td></tr><tr><td>5</td><td>SPI6_nCS1_EXT</td><td>3.3V</td></tr><tr><td>6</td><td>SPI6_DRDY1_EXT</td><td>3.3V</td></tr><tr><td>7</td><td>SPI6_nRESET_EXT</td><td>3.3V</td></tr><tr><td>8</td><td>GND</td><td>GND</td></tr></tbody></table>

#### Flight Controller Debug - 6 Pin JST-SH

<table><thead><tr><th width="153">Pin Number</th><th width="210">Signal Name</th><th>Voltage</th></tr></thead><tbody><tr><td>1</td><td>3V3_FMU</td><td>3.3V</td></tr><tr><td>2</td><td>USART3_TX_DEBUG</td><td>3.3V</td></tr><tr><td>3</td><td>USART3_RX_DEBUG</td><td>3.3V</td></tr><tr><td>4</td><td>FMU_SWDIO</td><td>3.3V</td></tr><tr><td>5</td><td>FMU_SWCLK</td><td>3.3V</td></tr><tr><td>6</td><td>GND</td><td>GND</td></tr></tbody></table>


# PX4 Instructions

{% embed url="<https://docs.px4.io/main/en/flight_controller/ark_fpv.html>" %}
ARK FPV PX4 Documentation
{% endembed %}

### Flashing Firmware

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

### Building Firmware

```
make ark_fpv_default
```

and optionally upload

```
make ark_fpv_default upload
```


# ArduPilot Instructions

{% embed url="<https://ardupilot.org/copter/docs/common-ark-fpv.html>" %}
ARK FPV ArduPilot Documentation
{% endembed %}

### Flashing Firmware

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

### Building Firmware

```
./waf configure --board ARK_FPV
./waf copter
```

and optionally upload

```
./waf copter --upload
```

### UART Mapping

| Name    | Function                                   |
| ------- | ------------------------------------------ |
| SERIAL0 | USB                                        |
| SERIAL1 | UART7 (Telem)                              |
| SERIAL2 | UART5 (DisplayPort HD VTX)                 |
| SERIAL3 | USART1 (GPS1)                              |
| SERIAL4 | USART2 (User, SBUS pin on HD VTX, RX only) |
| SERIAL5 | UART4 (ESC Telem, RX only)                 |
| SERIAL6 | USART6 (RC Input)                          |
| SERIAL7 | OTG2 (SLCAN)                               |

All UARTS support DMA. Any UART may be re-tasked by changing its protocol parameter.

The hardware definition for Ardupilot can be found here:\
<https://github.com/ArduPilot/ardupilot/tree/master/libraries/AP_HAL_ChibiOS/hwdef/ARK_FPV>


# Betaflight Instructions

## Connection to the Flight Controller

If your FC is flashed with Betaflight:

1. Power your board
2. Open <https://app.betaflight.com/> in Chrome or Edge.
3. Click on Connect

<figure><img src="/files/Eyz2QGXiCprkQ2WBFOzJ" alt=""><figcaption></figcaption></figure>

## Building Firmware

See the official [Betaflight documentation](https://betaflight.com/docs/development/building/Building-in-Ubuntu) for setting up the development environment.\
\
Build the ARK FPV firmware:

If you flash your Flight controller using DFU via <https://app.betaflight.com/> , build the `.hex`

```
make hex CONFIG=ARK_FPV
```

If you flash your Flight controller using ST-Link, build the `.bin`

```
make binary CONFIG=ARK_FPV
```

## Flashing Firmware

#### Flash using DFU mode via web app

Betaflight can be flashed using DFU over USB C.

1. With the board unpowered, hold the button next to the USB C port while connecting the USB cable to your PC.
2. Open <https://app.betaflight.com/> in Chrome or Edge.
3. Select `Firmware Flasher`\
   Toggle the sliders `Enable Expert Mode` and `Show release candidates` and select:\
   \- `Development`\
   \- `ARK_FPV`\
   \- `4.6.0-dev [latest]`\
   ![](/files/mGIbeGz0isGjzdSdEf3W)
4. Now select the `Load Firmware [Online]`\
   ![](/files/krIUQYGjlVfksNElNWff)
5. You could also flash your own build\
   \- Select the `Load Firmware [Local]`\
   \- In this case you need a `.hex`\
   ![](/files/Y07qdF5Za82tITEWBYIP)<br>
6. Now select `Flash Firmware`

{% hint style="info" %}
Betaflight does not have a separate bootloader. If you want to re-flash back to PX4 or Ardupilot after flashing Betaflight, you will need to re-flash the PX4 bootloader.
{% endhint %}

#### Flash using ST-Link

For detailed instructions on ST-LINK setup, software installation, and usage, see the [ST-LINK Flashing Guide](/knowledge-base/knowledge-base/st-link-flashing-guide).

Connect to the 6-pin debug connector and flash:

```
st-flash write obj/ARK_FPV.bin 0x08000000
```


# Bootloader Flashing Using DFU

DFU can be used to flash or reflash the bootloader with the following steps.

1. With the board unpowered, hold the button next to the USB C port while connecting the USB cable to your PC.
2. Open <https://devanlai.github.io/webdfu/dfu-util/> in Chrome.
3. Select `Connect`, then select `DFU in FS Mode`.

   <figure><img src="/files/drSGVn4Mziblq9N8dASm" alt=""><figcaption><p>DFU Device Selection</p></figcaption></figure>
4. Now select the `@Internal Flash` option.

   <figure><img src="/files/sIr8NPLNYuDNC8I21tqP" alt=""><figcaption><p>Select the @Internal Flash Option</p></figcaption></figure>
5. Now choose the bootloader binary you wish to flash. In this case we are using the default ARK FPV PX4 bootloader which is compatible with PX4 and Ardupilot.

{% file src="/files/WKF1WXXNNsU0AZx6hyrK" %}
ARK FPV PX4 Bootloader Built on Commit [1043aebf5ddd8fd0f6825a27d9a060fa24b616eb](https://github.com/PX4/PX4-Autopilot/commit/1043aebf5ddd8fd0f6825a27d9a060fa24b616eb)
{% endfile %}

<figure><img src="/files/IRUo6Kk9sOF6ZFasgFyX" alt=""><figcaption><p>Firmware Selection</p></figcaption></figure>

6. Select `Download` to flash the firmware.

   <figure><img src="/files/mIysEx8jVZxccTkO9UKK" alt=""><figcaption><p>Start the Firmware Download</p></figcaption></figure>
7. The flash will finish and the firmware will start.


# 3D Models

Step files can be found here\
<https://github.com/ARK-Electronics/ARK_FPV>


# ARKV6X

{% hint style="info" %}
**Using the ARKV6X on an ARK PAB Carrier?** See the [ARK Pixhawk Autopilot Bus Carrier Pinout](/products/flight-controller/ark-pixhawk-autopilot-bus-carrier/pinout).
{% endhint %}

The USA-built ARKV6X flight controller is based on the [FMUV6X and Pixhawk Autopilot Bus open source standards](https://github.com/pixhawk/Pixhawk-Standards).

With triple synced IMUs, data averaging, voting, and filtering is possible. The Pixhawk Autopilot Bus (PAB) form factor enables the ARKV6X to be used on any [PAB-compatible carrier board](https://docs.px4.io/main/en/flight_controller/pixhawk_autopilot_bus.html), such as the [ARK Pixhawk Autopilot Bus Carrier](https://docs.px4.io/main/en/flight_controller/arkpab.html).

<figure><img src="/files/SVf83rjZC9lRCcbmap7N" alt=""><figcaption><p>ARK Electronics ARKV6X</p></figcaption></figure>

### Sensors

* [Dual Invensense ICM-42688-P IMUs](https://invensense.tdk.com/products/motion-tracking/6-axis/icm-42688-p/)
* [Invensense IIM-42652 Industrial IMU](https://invensense.tdk.com/products/smartindustrial/iim-42652/)
* [Bosch BMP390 Barometer](https://www.bosch-sensortec.com/en/products/environmental-sensors/pressure-sensors/bmp390)
* [Bosch BMM150 Magnetometer](https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmm150-ds001.pdf)

### Other Features

* FRAM
* [Pixhawk Autopilot Bus (PAB) Form Factor](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf)
* LED Indicators
* MicroSD Slot
* USA Built
* Designed with a 1W heater. Keeps sensors warm in extreme conditions

### Power Requirements

* 5V
* 500mA
  * 300mA for main system
  * 200mA for heater

### Additional Information

* Weight: 5.0 g
* Dimensions: 3.6 x 2.9 x 0.5 cm

### Pinout

For pinout of the ARKV6X board-to-board connectors see the [DS-10 Pixhawk Autopilot Bus Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf).

All wiring connectors — GPS, TELEM, CAN, PWM, and the rest — are broken out by the carrier board, not the ARKV6X itself. For the ARK PAB Carrier, see:

{% content-ref url="/pages/8FoCumpSHonz9iz7bpP3" %}
[Pinout](/products/flight-controller/ark-pixhawk-autopilot-bus-carrier/pinout)
{% endcontent-ref %}

### Serial Port Mapping

| UART   | Device     | Port          |
| ------ | ---------- | ------------- |
| USART1 | /dev/ttyS0 | GPS           |
| USART2 | /dev/ttyS1 | TELEM3        |
| USART3 | /dev/ttyS2 | Debug Console |
| UART4  | /dev/ttyS3 | UART4 & I2C   |
| UART5  | /dev/ttyS4 | TELEM2        |
| USART6 | /dev/ttyS5 | PX4IO/RC      |
| UART7  | /dev/ttyS6 | TELEM1        |
| UART8  | /dev/ttyS7 | GPS2          |


# PX4 Instructions

{% embed url="<https://docs.px4.io/main/en/flight_controller/arkv6x.html>" %}
Up to date PX4 Documentation
{% endembed %}

### Flashing Firmware

#### QGroundControl (USB-C)

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

#### px4\_uploader.py (USB or UART)

[`px4_uploader.py`](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/px4_uploader.py) can flash firmware over USB or UART. For UART flashing, only the **Telem1** port is supported.

Over USB:

```sh
python3 Tools/px4_uploader.py build/ark_fmu-v6x_default/ark_fmu-v6x_default.px4
```

Over UART (via Telem1):

```sh
python3 Tools/px4_uploader.py --port /dev/<your-uart> build/ark_fmu-v6x_default/ark_fmu-v6x_default.px4
```

### Building Firmware

```
make ark_fmu-v6x_default
```

and optionally upload

```
make ark_fmu-v6x_default upload
```


# ArduPilot Instructions

{% embed url="<https://ardupilot.org/copter/docs/common-ark-v6x-overview.html>" %}
ARKV6X ArduPilot Documentation
{% endembed %}

### Flashing Firmware

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

### Building Firmware

```
./waf configure --board ARKV6X
./waf copter
```

and optionally upload

```
./waf copter --upload
```

### Serial Port Mapping

{% hint style="info" %}
Serial Port Mapping for Default Firmware with No IOMCU
{% endhint %}

| **UART** | **Serial Number** | **Port**      |
| -------- | ----------------- | ------------- |
| UART7    | SERIAL1           | TELEM1        |
| UART5    | SERIAL2           | TELEM2        |
| USART1   | SERIAL3           | GPS           |
| UART8    | SERIAL4           | GPS2          |
| USART2   | SERIAL5           | TELEM3        |
| UART4    | SERIAL6           | UART4 & I2C   |
| USART3   | SERIAL7           | Debug Console |
| USART6   | SERIAL8           | PX4IO/RC      |

### hwdef modifications for use with an IOMCU

When using the ARKV6X on a carrier board with an IOMCU, the following modifications to the hwdef need to be made.

Swap the SERIAL\_ORDER line comments to remove USART6 from the available serial ports.

<https://github.com/ArduPilot/ardupilot/blob/Copter-4.6.0/libraries/AP_HAL_ChibiOS/hwdef/ARKV6X/hwdef.dat#L30-L34>

Uncomment the IOMCU\_UART line to use USART6 for the IOMCU.\
\
<https://github.com/ArduPilot/ardupilot/blob/Copter-4.6.0/libraries/AP_HAL_ChibiOS/hwdef/ARKV6X/hwdef.dat#L91>\
\
Build and flash the firmware using the steps above.


# 3D Models

Step files can be found here\
<https://github.com/ARK-Electronics/ARKV6X_Flight_Controller>


# ARKV6S

The USA-built ARKV6S flight controller is a low-cost, single-IMU variant of the [ARKV6X](/products/flight-controller/arkv6x), based on the [FMUV6X and Pixhawk Autopilot Bus open source standards](https://github.com/pixhawk/Pixhawk-Standards).

The Pixhawk Autopilot Bus (PAB) form factor enables the ARKV6S to be used on any [PAB-compatible carrier board](https://docs.px4.io/main/en/flight_controller/pixhawk_autopilot_bus.html), such as the [ARK Pixhawk Autopilot Bus Carrier](https://docs.px4.io/main/en/flight_controller/arkpab.html).

<figure><img src="/files/z279eVyiIB6eXq4k6JhG" alt=""><figcaption><p>ARK Electronics ARKV6S</p></figcaption></figure>

### Sensors

* [Invensense IIM-42653 Industrial IMU](https://invensense.tdk.com/products/smartindustrial/iim-42653/)
* [Bosch BMP390 Barometer](https://www.bosch-sensortec.com/products/environmental-sensors/pressure-sensors/bmp390/)
* [ST IIS2MDC Magnetometer](https://www.st.com/en/mems-and-sensors/iis2mdc.html)

### Other Features

* FRAM
* [Pixhawk Autopilot Bus (PAB) Form Factor](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf)
* LED Indicators
* MicroSD Slot
* USA Built
* Designed with a 1W heater. Keeps sensors warm in extreme conditions

### Power Requirements

* 5V
* 500mA
  * 300mA for main system
  * 200mA for heater

### Additional Information

* Weight: 5.0 g
* Dimensions: 3.6 x 2.9 x 0.5 cm

### Pinout

For pinout of the ARKV6S see the [DS-10 Pixhawk Autopilot Bus Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf)

### Serial Port Mapping

| UART   | Device     | Port          |
| ------ | ---------- | ------------- |
| USART1 | /dev/ttyS0 | GPS           |
| USART2 | /dev/ttyS1 | TELEM3        |
| USART3 | /dev/ttyS2 | Debug Console |
| UART4  | /dev/ttyS3 | UART4 & I2C   |
| UART5  | /dev/ttyS4 | TELEM2        |
| USART6 | /dev/ttyS5 | PX4IO/RC      |
| UART7  | /dev/ttyS6 | TELEM1        |
| UART8  | /dev/ttyS7 | GPS2          |


# PX4 Instructions

{% embed url="<https://docs.px4.io/main/en/flight_controller/ark_v6s.html>" %}
Up to date PX4 Documentation
{% endembed %}

### Flashing Firmware

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

### Building Firmware

```
make ark_fmu-v6s_default
```

and optionally upload

```
make ark_fmu-v6s_default upload
```


# ArduPilot Instructions

{% embed url="<https://ardupilot.org/copter/docs/common-ark-v6s-overview.html>" %}
ARKV6S ArduPilot Documentation
{% endembed %}

### Flashing Firmware

Firmware can be flashed over USB C using [QGroundControl](https://qgroundcontrol.com/).

### Building Firmware

```
./waf configure --board ARKV6S
./waf copter
```

and optionally upload

```
./waf copter --upload
```

### Serial Port Mapping

{% hint style="info" %}
Serial Port Mapping for Default Firmware with No IOMCU
{% endhint %}

| **UART** | **Serial Number** | **Port**      |
| -------- | ----------------- | ------------- |
| UART7    | SERIAL1           | TELEM1        |
| UART5    | SERIAL2           | TELEM2        |
| USART1   | SERIAL3           | GPS           |
| UART8    | SERIAL4           | GPS2          |
| USART2   | SERIAL5           | TELEM3        |
| UART4    | SERIAL6           | UART4 & I2C   |
| USART3   | SERIAL7           | Debug Console |
| USART6   | SERIAL8           | PX4IO/RC      |

### hwdef modifications for use with an IOMCU

When using the ARKV6S on a carrier board with an IOMCU, the following modifications to the hwdef need to be made.

Swap the SERIAL\_ORDER line comments to remove USART6 from the available serial ports.

Uncomment the IOMCU\_UART line to use USART6 for the IOMCU.

Build and flash the firmware using the steps above.


# 3D Models

Step files can be found here\
<https://github.com/ARK-Electronics/ARKV6S_Flight_Controller>


# ARK Pixhawk Autopilot Bus Carrier

The ARK Pixhawk Autopilot Bus (PAB) Carrier is a USA-built flight controller carrier board, based on the [Pixhawk Autopilot Bus open source standard](https://github.com/pixhawk/Pixhawk-Standards).

The PAB form factor enables the ARK PAB Carrier to be used with any [PAB-compatible flight controller](https://docs.px4.io/main/en/flight_controller/pixhawk_autopilot_bus.html), such as the [ARKV6X](https://docs.px4.io/main/en/flight_controller/arkv6x.html).

<figure><img src="/files/xrxIrYhOoBOcsW0JtA6r" alt=""><figcaption><p>ARK Pixhawk Autopilot Bus Carrier</p></figcaption></figure>

### Features <a href="#features" id="features"></a>

* [Pixhawk Autopilot Bus (PAB) Form Factor](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf?_ga=2.20605755.2081055420.1671562222-391294592.1671562222)
* USA Built

### Connectors <a href="#connectors" id="connectors"></a>

* PAB Board to Board Interface
  * 100 Pin Hirose DF40
  * 40 Pin Hirose DF40
* Dual Digital Power Module Inputs
  * 5V Input
  * I2C Power Monitor
  * 6 Pin Molex CLIK-Mate
* Ethernet
  * 100Mbps
  * Built in Magnetics
  * 4 Pin JST-GH
* Full GPS Plus Safety Switch Port
  * 10 Pin JST-GH
* Basic GPS Port
  * 6 Pin JST-GH
* Dual CAN Ports
  * 4 Pin JST-GH
* Triple Telemetry Ports with Flow - Control
  * 6 Pin JST-GH
* Eight PWM Outputs
  * 10 Pin JST-GH
* UART/I2C Port
  * 6 Pin JST-GH
* I2C Port
  * 4 Pin JST-GH
* PPM RC Port
  * 3 Pin JST-GH
* DSM RC Port
  * 3 Pin JST-ZH
* SPI Port
  * 11 Pin JST-GH
* ADIO Port
  * 8 Pin JST-GH
* Debug Port
  * 10 Pin JST-SH

### Dimensions <a href="#dimensions" id="dimensions"></a>

* Without Flight Controller Module
  * 74.0mm x 43.5mm x 12.0mm
  * 22g

### Power <a href="#power" id="power"></a>

* 5V input on `POWER1`, `POWER2`, `USB C`, and the `USB JST-GH` connector
  * Input is prioritized in the following order: POWER1 > POWER2 > USB
  * `USB C` and the `USB JST-GH` are in parallel
  * Overvoltage protection at 5.8V
  * Undervoltage protection at 3.9V
* `VDD_5V_HIPOWER` and `VDD_5V_PERIPH` can each provide a total of 1.5A across all the connectors

### LEDS <a href="#leds" id="leds"></a>

* There are two LEDs on the ARK PAB
  * `Red` is the ethernet power LED
  * `Green` is the ethernet activity LED

### Pinout <a href="#pinout" id="pinout"></a>

See the [Pinout](/products/flight-controller/ark-pixhawk-autopilot-bus-carrier/pinout) page for the connector pinouts.

{% content-ref url="/pages/8FoCumpSHonz9iz7bpP3" %}
[Pinout](/products/flight-controller/ark-pixhawk-autopilot-bus-carrier/pinout)
{% endcontent-ref %}


# 3D Models and Case Files

\
Step files can be found here:\
<https://github.com/ARK-Electronics/ARK_PAB_Carrier>


# Pinout

<figure><img src="/files/fktvgB0r3JvCy1Bn9zM3" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/QaiywFDYTxpktWaR41sp" alt=""><figcaption><p>ARK PAB Carrier connector locations</p></figcaption></figure>

### POWER1

| Pin     | Signal    | Volt  |
| ------- | --------- | ----- |
| 1 (red) | `VBRICK1` | +5.0V |
| 2 (blk) | `VBRICK1` | +5.0V |
| 3 (blk) | I2C1\_SCL | +3.3V |
| 4 (blk) | I2C1\_SDA | +3.3V |
| 5 (blk) | `GND`     | GND   |
| 6 (blk) | `GND`     | GND   |

### POWER2

| Pin     | Signal    | Volt  |
| ------- | --------- | ----- |
| 1 (red) | `VBRICK2` | +5.0V |
| 2 (blk) | `VBRICK2` | +5.0V |
| 3 (blk) | I2C2\_SCL | +3.3V |
| 4 (blk) | I2C2\_SDA | +3.3V |
| 5 (blk) | `GND`     | GND   |
| 6 (blk) | `GND`     | GND   |

### PWM

| Pin      | Signal                     | Volt  |
| -------- | -------------------------- | ----- |
| 1 (red)  | VDD\_SERVO (Not Connected) | +5.0V |
| 2 (blk)  | FMU\_CH1                   | +3.3V |
| 3 (blk)  | FMU\_CH2                   | +3.3V |
| 4 (blk)  | FMU\_CH3                   | +3.3V |
| 5 (blk)  | FMU\_CH4                   | +3.3V |
| 6 (blk)  | FMU\_CH5                   | +3.3V |
| 7 (blk)  | FMU\_CH6                   | +3.3V |
| 8 (blk)  | FMU\_CH7                   | +3.3V |
| 9 (blk)  | FMU\_CH8                   | +3.3V |
| 10 (blk) | `GND`                      | GND   |

### GPS1

| Pin      | Signal                    | Volt  |
| -------- | ------------------------- | ----- |
| 1 (red)  | `VDD_5V_PERIPH`           | +5.0V |
| 2 (blk)  | USART1\_TX\_GPS1          | +3.3V |
| 3 (blk)  | USART1\_RX\_GPS1          | +3.3V |
| 4 (blk)  | I2C1\_SCL                 | +3.3V |
| 5 (blk)  | I2C1\_SDA                 | +3.3V |
| 6 (blk)  | nSAFETY\_SWITCH\_IN       | +3.3V |
| 7 (blk)  | nSAFETY\_SWITCH\_LED\_OUT | +3.3V |
| 8 (blk)  | `3V3_FMU`                 | +3.3V |
| 9 (blk)  | BUZZER                    | +5.0V |
| 10 (blk) | `GND`                     | GND   |

### GPS2

| Pin     | Signal           | Volt  |
| ------- | ---------------- | ----- |
| 1 (red) | `VDD_5V_HIPOWER` | +5.0V |
| 2 (blk) | UART8\_TX\_GPS2  | +3.3V |
| 3 (blk) | UART8\_RX\_GPS2  | +3.3V |
| 4 (blk) | I2C2\_SCL        | +3.3V |
| 5 (blk) | I2C2\_SDA        | +3.3V |
| 6 (blk) | `GND`            | GND   |

### TELEM1

| Pin     | Signal           | Volt  |
| ------- | ---------------- | ----- |
| 1 (red) | `VDD_5V_HIPOWER` | +5.0V |
| 2 (blk) | UART7\_TX        | +3.3V |
| 3 (blk) | UART7\_RX        | +3.3V |
| 4 (blk) | UART7\_CTS       | +3.3V |
| 5 (blk) | UART7\_RTS       | +3.3V |
| 6 (blk) | `GND`            | GND   |

### TELEM2

| Pin     | Signal          | Volt  |
| ------- | --------------- | ----- |
| 1 (red) | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk) | UART5\_TX       | +3.3V |
| 3 (blk) | UART5\_RX       | +3.3V |
| 4 (blk) | UART5\_CTS      | +3.3V |
| 5 (blk) | UART5\_RTS      | +3.3V |
| 6 (blk) | `GND`           | GND   |

### TELEM3

| Pin     | Signal           | Volt  |
| ------- | ---------------- | ----- |
| 1 (red) | `VDD_5V_HIPOWER` | +5.0V |
| 2 (blk) | USART2\_TX       | +3.3V |
| 3 (blk) | USART2\_RX       | +3.3V |
| 4 (blk) | USART2\_CTS      | +3.3V |
| 5 (blk) | USART2\_RTS      | +3.3V |
| 6 (blk) | `GND`            | GND   |

### UART4/I2C3

| Pin     | Signal          | Volt  |
| ------- | --------------- | ----- |
| 1 (red) | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk) | UART4\_TX       | +3.3V |
| 3 (blk) | UART4\_RX       | +3.3V |
| 4 (blk) | I2C3\_SCL       | +3.3V |
| 5 (blk) | I2C3\_SDA       | +3.3V |
| 6 (blk) | `GND`           | GND   |

### I2C3

| Pin     | Signal          | Volt  |
| ------- | --------------- | ----- |
| 1 (red) | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk) | I2C3\_SCL       | +3.3V |
| 3 (blk) | I2C3\_SDA       | +3.3V |
| 4 (blk) | `GND`           | GND   |

### CAN1

| Pin     | Signal           | Volt  |
| ------- | ---------------- | ----- |
| 1 (red) | `VDD_5V_HIPOWER` | +5.0V |
| 2 (blk) | CAN1\_H          | +3.3V |
| 3 (blk) | CAN1\_L          | +3.3V |
| 4 (blk) | `GND`            | GND   |

### CAN2

| Pin     | Signal          | Volt  |
| ------- | --------------- | ----- |
| 1 (red) | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk) | CAN2\_H         | +3.3V |
| 3 (blk) | CAN2\_L         | +3.3V |
| 4 (blk) | `GND`           | GND   |

### USB

All signals in parallel with USB C connector

| Pin     | Signal    | Volt  |
| ------- | --------- | ----- |
| 1 (red) | `VBUS_IN` | +5.0V |
| 2 (blk) | USB\_N    | +3.3V |
| 3 (blk) | USB\_P    | +3.3V |
| 4 (blk) | `GND`     | GND   |

### ETH

| Pin     | Signal     | Volt            |
| ------- | ---------- | --------------- |
| 1 (red) | ETH\_RD\_N | +50.0V Tolerant |
| 2 (blk) | ETH\_RD\_P | +50.0V Tolerant |
| 3 (blk) | ETH\_TD\_N | +50.0V Tolerant |
| 4 (blk) | ETH\_TD\_P | +50.0V Tolerant |

### ADIO

| Pin     | Signal          | Volt  |
| ------- | --------------- | ----- |
| 1 (red) | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk) | FMU\_CAP        | +3.3V |
| 3 (blk) | BOOTLOADER      | +3.3V |
| 4 (blk) | FMU\_RST\_REQ   | +3.3V |
| 5 (blk) | nARMED          | +3.3V |
| 6 (blk) | ADC1\_3V3       | +3.3V |
| 7 (blk) | ADC1\_6V6       | +3.3V |
| 8 (blk) | `GND`           | GND   |

### RC/SBUS

| Pin     | Signal               | Volt  |
| ------- | -------------------- | ----- |
| 1 (red) | `VDD_5V_SBUS_RC`     | +5.0V |
| 2 (blk) | USART6\_RX\_SBUS\_IN | +3.3V |
| 3 (blk) | USART6\_TX           | +3.3V |
| 4 (blk) | `VDD_3V3_SPEKTRUM`   | +3.3V |
| 5 (blk) | `GND`                | GND   |

### PPM

| Pin     | Signal                     | Volt  |
| ------- | -------------------------- | ----- |
| 1 (red) | `VDD_5V_PPM_RC`            | +5.0V |
| 2 (blk) | DSM\_INPUT/FMU\_PPM\_INPUT | +3.3V |
| 3 (blk) | `GND`                      | GND   |

### DSM

| Pin     | Signal                     | Volt  |
| ------- | -------------------------- | ----- |
| 1 (red) | `VDD_3V3_SPEKTRUM`         | +3.3V |
| 2 (blk) | `GND`                      | GND   |
| 3 (blk) | DSM\_INPUT/FMU\_PPM\_INPUT | +3.3V |

### SPI6

| Pin      | Signal          | Volt  |
| -------- | --------------- | ----- |
| 1 (red)  | `VDD_5V_PERIPH` | +5.0V |
| 2 (blk)  | SPI6\_SCK       | +3.3V |
| 3 (blk)  | SPI6\_MISO      | +3.3V |
| 4 (blk)  | SPI6\_MOSI      | +3.3V |
| 5 (blk)  | SPI6\_nCS1      | +3.3V |
| 6 (blk)  | SPI6\_nCS2      | +3.3V |
| 7 (blk)  | SPIX\_nSYNC     | +3.3V |
| 8 (blk)  | SPI6\_DRDY1     | +3.3V |
| 9 (blk)  | SPI6\_DRDY2     | +3.3V |
| 10 (blk) | SPI6\_nRESET    | +3.3V |
| 11 (blk) | `GND`           | GND   |

### Debug Port

| Pin      | Signal           | Volt  |
| -------- | ---------------- | ----- |
| 1 (red)  | `Vtref`          | +3.3V |
| 2 (blk)  | Console TX (OUT) | +3.3V |
| 3 (blk)  | Console RX (IN)  | +3.3V |
| 4 (blk)  | `SWDIO`          | +3.3V |
| 5 (blk)  | `SWCLK`          | +3.3V |
| 6 (blk)  | `SWO`            | +3.3V |
| 7 (blk)  | NFC GPIO         | +3.3V |
| 8 (blk)  | PH11             | +3.3V |
| 9 (blk)  | nRST             | +3.3V |
| 10 (blk) | `GND`            | GND   |


# PX4 Instructions

{% embed url="<https://docs.px4.io/main/en/flight_controller/arkpab.html>" %}
Up to date PX4 Docs
{% endembed %}

### Debug Port <a href="#debug-port" id="debug-port"></a>

The [PX4 System Console](https://docs.px4.io/main/en/debug/system_console.html) and [SWD interface](https://docs.px4.io/main/en/debug/swd_debug.html) run on the **FMU Debug** port.

The pinouts and connector comply with the [Pixhawk Debug Full](https://docs.px4.io/main/en/debug/swd_debug.html#pixhawk-debug-full) interface defined in the [Pixhawk Connector Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf) interface (JST SM10B connector).

| Pin      | Signal           | Volt  |
| -------- | ---------------- | ----- |
| 1 (red)  | `Vtref`          | +3.3V |
| 2 (blk)  | Console TX (OUT) | +3.3V |
| 3 (blk)  | Console RX (IN)  | +3.3V |
| 4 (blk)  | `SWDIO`          | +3.3V |
| 5 (blk)  | `SWCLK`          | +3.3V |
| 6 (blk)  | `SWO`            | +3.3V |
| 7 (blk)  | NFC GPIO         | +3.3V |
| 8 (blk)  | PH11             | +3.3V |
| 9 (blk)  | nRST             | +3.3V |
| 10 (blk) | `GND`            | GND   |

For information about using this port see:

* [SWD Debug Port](https://docs.px4.io/main/en/debug/swd_debug.html)
* [PX4 System Console](https://docs.px4.io/main/en/debug/system_console.html) (Note, the FMU console maps to USART3).

![ARKPAB Top Down Photo](https://docs.px4.io/main/assets/ark_pab_top.C8on0kwA.jpg)

![ARKPAB Bottom Photo](https://docs.px4.io/main/assets/ark_pab_back.BMAKz_xS.jpg)


# Jetson PABs

{% content-ref url="/pages/5fmpxMUTz0ILwNZVhXDT" %}
[ARK Jetson PAB Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier)
{% endcontent-ref %}

{% content-ref url="/pages/UzgcAv6bqVlPHboUz3QG" %}
[ARK Jetson PAB Carrier V3](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3)
{% endcontent-ref %}

The ARK Jetson PAB Carrier and ARK Jetson PAB Carrier V3 are NVIDIA Jetson Orin Nano/NX carrier boards built around the ARKV6X flight controller and the Pixhawk Autopilot Bus. Both run PX4 and ship with ARK-OS pre-installed. The V3 is a re-architected revision that adds a dedicated I/O co-processor (doubling the PWM outputs to 16), consolidates wiring into two 40-pin avionics connectors, and adds a 30-pin Pixhawk Payload Bus.

## Comparison

| Feature                   | ARK Jetson PAB Carrier                                                        | ARK Jetson PAB Carrier V3                                          |
| ------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Compute module            | Jetson Orin Nano / NX                                                         | Jetson Orin Nano / NX                                              |
| Flight controller         | ARKV6X (Pixhawk Autopilot Bus)                                                | ARKV6X (Pixhawk Autopilot Bus)                                     |
| I/O co-processor          | None                                                                          | STM32F103C8T7 IOMCU                                                |
| PWM outputs               | 8 (FMU)                                                                       | 16 (8 FMU + 8 IO)                                                  |
| Avionics wiring           | Discrete JST-GH connectors per function (CAN, TELEM, GPS, RC, PWM, I2C, UART) | Two 40-pin Molex Pico-Clasp bundles (Primary + Secondary Avionics) |
| Pixhawk Payload Bus       | —                                                                             | 30-pin FFC (USB 2.0, Ethernet, CAN, I2C, UART, PWM, GPIO)          |
| CAN buses                 | 2× FC CAN + 1× Jetson CAN                                                     | 2× FC CAN + 1× Jetson CAN                                          |
| Power inputs              | 3× 5V / 6A, Molex Clik-Mate (6-pin)                                           | 3× 5V / 4A, Molex Micro-Lock PLUS (6-pin)                          |
| CSI camera inputs         | 4× 15-pin FFC (CSI0–CSI3)                                                     | 2× 22-pin dual-lane FFC (CSI0–CSI3)                                |
| Ethernet                  | Gigabit, RJ45                                                                 | 10/100, onboard switch → JST-GH (4-pin) + Payload Bus              |
| USB host                  | 3x USB 3.0 A Ports; 1x USB 2.0 A Port                                         | 2× USB 2.0 (JST-GH); USB 3.0 on USB-C                              |
| Display output            | Mini DisplayPort                                                              | Micro HDMI                                                         |
| Jetson console / recovery | Micro USB (muxed with FC USB)                                                 | USB-C                                                              |
| NVMe storage              | M.2 Key M 2242, PCIe ×4                                                       | M.2 Key M 2242, PCIe ×4                                            |
| M.2 Key E 2230 slot       | PCIe x2, USB, UART, I2S                                                       | PCIe x2, USB, UART, I2S                                            |


# ARK Jetson PAB Carrier

An NVIDIA Jetson Orin Nano/NX carrier board built around the ARKV6X flight controller and the Pixhawk Autopilot Bus. It runs PX4 and ships with ARK-OS pre-installed.

## Where to Start

**Your bundle arrived preflashed.** The Jetson already runs ARK-OS and the flight controller already has PX4. Go to [Set Up Your Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/setup), then manage it from the ARK-UI web interface.

**You have a bare board, or you want to flash it yourself.** Install a Jetson module and NVMe SSD, then start at the [Flashing Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer/flashing-guide).

## Sections

* [Set Up Your Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/setup) — connect to it and get it on your network
* [Using ARK-OS](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os) — services, web interface, autopilot connections
* [Hardware Reference](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware) — pinout, GPIO, cameras, display output
* [Developer Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer) — flashing, serial console, building from source


# Set Up Your Carrier

## What's Pre-Installed

Bundles ship ready to use — no flashing required:

* **Jetson**: Latest ARK Jetson image (JetPack 6 / L4T r36) on the NVMe SSD, with [ARK-OS](https://github.com/ARK-Electronics/ARK-OS) pre-installed
* **Flight Controller**: Latest PX4 stable firmware
* **Credentials**: Username `jetson`, password `jetson`, hostname `jetson`

{% hint style="info" %}
The default password is well known — change it (`passwd`) before putting the vehicle on a network you don't control.
{% endhint %}

A bare carrier board (no Jetson module or SSD) has no OS on it. Install your module and NVMe SSD, then follow the [Flashing Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer/flashing-guide).

## Steps

1. [Connect](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/setup/connect) — reach the Jetson over Micro USB, WiFi hotspot, or Ethernet.
2. [Get Online](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/setup/get-online) — join it to your WiFi network.
3. [ARK-OS](/software/ark-os) — the preinstalled services and the ARK-UI web interface.
4. [Autopilot Connections](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os/autopilot-connections) — connect QGroundControl or Mission Planner.


# Connect

## Micro USB

Connect the Micro USB port to your PC. The Jetson appears as a USB network device at `192.168.55.1`:

```bash
ssh jetson@192.168.55.1
```

The web UI is reachable the same way at <http://192.168.55.1>.

{% hint style="danger" %}
**Micro USB + Flight Controller Conflict**

The Micro USB port is muxed with the flight controller's USB connection. While a Micro USB cable is connected, the flight controller is disconnected from the Jetson and MAVLink routing will not work. After unplugging, **reboot the Jetson** to restore the flight controller connection.
{% endhint %}

The same cable also carries a serial login console — see [Micro USB Console](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer/micro-usb-console).

## WiFi Hotspot

On first boot, if no known WiFi network is available, the Jetson brings up a hotspot:

* **Network**: `jetson-<serial>`
* **Password**: `password`

Connect to it and open <http://jetson.local>.

{% hint style="info" %}
**MHF4 antenna cables are required for WiFi and are not included.** Compatible MHF4 to RP-SMA cables: [option 1](https://www.amazon.com/female-Pigtail-Antenna-Extension-wireless/dp/B07GTL2G69), [option 2](https://www.amazon.com/dp/B076SGTMFS). Some bundles ship without the WiFi card — the hotspot only appears when a WiFi card is installed.
{% endhint %}

## Ethernet

Plug the RJ45 port into your network — the Jetson requests an address over DHCP.

Once the Jetson is on your network:

```bash
ssh jetson@jetson.local
```


# Get Online

## From ARK-UI

Open <http://jetson.local> (or <http://192.168.55.1> over Micro USB) and join a network from the **Connections** page:

<figure><img src="/files/osyXWg6wonr7N6RblBS4" alt=""><figcaption><p>ARK-UI Connections page</p></figcaption></figure>

## From the Command Line

Scan for networks:

```bash
sudo nmcli device wifi
```

Connect to a network:

```bash
sudo nmcli device wifi connect 'SSID' password 'PASSWORD'
```

## Sharing Your PC's Internet over USB

The kernel repo ships a helper that NATs the Jetson's traffic out through your host PC's WiFi — see [share\_wifi.sh](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/scripts/share_wifi.sh).

You can also bake a WiFi profile into the image before flashing with `./scripts/add_wifi_network.sh PAB <ssid> <password>`.


# Using ARK-OS

[ARK-OS](/software/ark-os) is preinstalled on every bundle: MAVLink routing, video streaming, flight log management, firmware updates, and network RTK corrections, plus the ARK-UI web interface at <http://jetson.local>.

* [ARK-OS and ARK-UI](/software/ark-os)
* [Services](/software/ark-os/services) — what each service does, and which are enabled by default
* [Apt: Hold Back Risky Packages](/software/ark-os/apt-hold-back) — read before running `apt upgrade`

## On This Carrier

* [Autopilot Connections](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os/autopilot-connections) — connect QGroundControl or Mission Planner
* [Updating the Flight Controller Firmware](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/using-ark-os/updating-the-flight-controller-firmware)


# Autopilot Connections

There are two communication channels between the Jetson and the flight controller: USB and serial. Both are direct board-to-board connections tested up to 3 Mbps.

| Type   | Jetson device path | Flight Controller |
| ------ | ------------------ | ----------------- |
| USB    | /dev/ttyACM0       | USB               |
| Serial | /dev/ttyTHS1       | Telem2            |

{% hint style="info" %}
We recommend running MAVLink on USB and XRCE-DDS on serial. ARK-OS's defaults do exactly this — see [Services](/software/ark-os/services).
{% endhint %}

## USB

The flight controller's USB connection is muxed with the external Micro USB port. While a Micro USB cable is connected, the flight controller is disconnected from the Jetson. After unplugging, reboot the Jetson to restore the connection.

<figure><img src="/files/REbrbEaKCp8WtAz160wa" alt=""><figcaption></figcaption></figure>

For the flight controller's USB to enumerate, its VBUS\_SENSE pin must be driven high by the Jetson. This is set in the Jetson pinmux at boot, so it works out of the box.

## Serial

The serial connection is Jetson UART1 (`/dev/ttyTHS1`) to **Telem2** on the flight controller, tested to 3 Mbps. When running MAVLink on Telem2, set flow control to off: [MAV\_x\_FLOW\_CTRL](https://docs.px4.io/main/en/advanced_config/parameter_reference.html#MAV_1_FLOW_CTRL) = 0.

## Flight Controller Reset

The Jetson can hard-reset the flight controller via a GPIO reset line. The reset is gated by the nARMED signal — the Jetson cannot reset the flight controller while it is armed.

ARK-OS ships two reset helpers on `PATH`:

```bash
reset_fmu_fast.py       # reset and boot straight into the application
reset_fmu_wait_bl.py    # reset and wait in the bootloader (for firmware flashing)
```


# QGroundControl Connection

When using PX4 or ArduPilot on the ARKV6X, to connect to QGroundControl, use UDP as the connection type. Enter the IP address(or hostname ie jetson.local) of the Jetson with port 14550.

<figure><img src="/files/IUN9MBI6sr603V6sk3yk" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Asp0Kph4Q5oWpWh8dotF" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/wRijeKaTxjTtvZdmkGwB" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/0TAxG8ADwDtgBtqoGVZ8" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/K9vwnUcqVWdI9elfxDqp" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/LQB328gevusIfqYwtk5S" alt=""><figcaption></figcaption></figure>


# MissionPlanner ArduPilot Connection

When using ArduPilot on the ARKV6X, to connect to MissionPlanner, use UDPCI as the connection type. Enter the IP address of the Jetson with port 14550.

<figure><img src="/files/v2VSgGFS1jYluBUraVox" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/bh07kDwj4p7gGT4eGSHV" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/g98P6P2OFaSeDUdsKqEM" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/5OUO3MH2P4NVOEYcFEgk" alt=""><figcaption></figcaption></figure>


# Updating the Flight Controller Firmware

The ARKV6X Flight Controller can be flashed with PX4 or ArduPilot.

## From the Web UI

Open the [ARK-UI](http://jetson.local) **Autopilot** page, select the **Firmware** tab, and upload a `.px4` or `.apj` firmware file.

<figure><img src="/files/Zb85j85arfC2dlHoXmGl" alt=""><figcaption></figcaption></figure>

## From the Command Line

SSH into the Jetson and run the ARK-OS flashing tool (on `PATH`):

```bash
flash_firmware.sh <firmware.px4>
```

Run without an argument to flash the PX4 image bundled with ARK-OS.

## Firmware Binaries

* **PX4**: `ark_fmu-v6x` builds from the [PX4 releases page](https://github.com/PX4/PX4-Autopilot/releases/)
* **ArduPilot**: `ARK_FMU_V6X` builds from [firmware.ardupilot.org](https://firmware.ardupilot.org/)


# Hardware Reference

* [Pinout](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/pinout)
* [Block Diagram](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/block-diagram)
* [3D Models and Case Files](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/3d-models-and-case-files)
* [GPIO Control](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/gpio-control)
* [Camera Overlays](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/camera-overlays)
* [Mini DisplayPort](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/mini-displayport) — display output and adapter requirements
* [Power Cycling USB Ports](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/hardware/power-cycling-usb-ports)


# Pinout

{% file src="/files/2MI4TboRY7AjWDRf2B8z" %}
Pinout reference poster (PDF)
{% endfile %}

### **POWER1**

| Pin Number | Signal Name         | Voltage |
| ---------- | ------------------- | ------- |
| 1          | VBRICK1             | 5.0V    |
| 2          | VBRICK1             | 5.0V    |
| 3          | I2C1\_SCL\_PWR\_EXT | 3.3V    |
| 4          | I2C1\_SDA\_PWR\_EXT | 3.3V    |
| 5          | GND                 | GND     |
| 6          | GND                 | GND     |

### **POWER2**

| Pin Number | Signal Name               | Voltage |
| ---------- | ------------------------- | ------- |
| 1          | VBRICK2                   | 5.0V    |
| 2          | VBRICK2                   | 5.0V    |
| 3          | I2C2\_SCL\_BASE\_PWR\_EXT | 3.3V    |
| 4          | I2C2\_SDA\_BASE\_PWR\_EXT | 3.3V    |
| 5          | GND                       | GND     |
| 6          | GND                       | GND     |

### **POWER3**

| Pin Number | Signal Name         | Voltage |
| ---------- | ------------------- | ------- |
| 1          | VBRICK3             | 5.0V    |
| 2          | VBRICK3             | 5.0V    |
| 3          | I2C3\_SCL\_PWR\_EXT | 3.3V    |
| 4          | I2C3\_SDA\_PWR\_EXT | 3.3V    |
| 5          | GND                 | GND     |
| 6          | GND                 | GND     |

### **TELEM1**

| Pin Number | Signal Name             | Voltage |
| ---------- | ----------------------- | ------- |
| 1          | VDD\_5V\_HIPOWER        | 5.0V    |
| 2          | UART7\_TX\_TELEM1\_EXT  | 3.3V    |
| 3          | UART7\_RX\_TELEM1\_EXT  | 3.3V    |
| 4          | UART7\_CTS\_TELEM1\_EXT | 3.3V    |
| 5          | UART7\_RTS\_TELEM1\_EXT | 3.3V    |
| 6          | GND                     | GND     |

### **TELEM3**

| Pin Number | Signal Name              | Voltage |
| ---------- | ------------------------ | ------- |
| 1          | VDD\_5V\_HIPOWER         | 5.0V    |
| 2          | USART2\_TX\_TELEM3\_EXT  | 3.3V    |
| 3          | USART2\_RX\_TELEM3\_EXT  | 3.3V    |
| 4          | USART2\_CTS\_TELEM3\_EXT | 3.3V    |
| 5          | USART2\_RTS\_TELEM3\_EXT | 3.3V    |
| 6          | GND                      | GND     |

### **GPS1**

| Pin Number | Signal Name                    | Voltage           |
| ---------- | ------------------------------ | ----------------- |
| 1          | VDD\_5V\_PERIPH                | 5.0V              |
| 2          | USART1\_TX\_GPS1\_EXT          | 3.3V              |
| 3          | USART1\_RX\_GPS1\_EXT          | 3.3V              |
| 4          | I2C1\_SCL\_GPS1\_EXT           | 3.3V              |
| 5          | I2C1\_SDA\_GPS1\_EXT           | 3.3V              |
| 6          | NSAFETY\_SWITCH\_IN\_EXT       | 3.3V              |
| 7          | NSAFETY\_SWITCH\_LED\_OUT\_EXT | 3.3V              |
| 8          | 3V3\_FMU                       | 3.3V              |
| 9          | BUZZER\_EXT                    | 5.0V (open drain) |
| 10         | GND                            | GND               |

### **GPS2**

| Pin Number | Signal Name                | Voltage |
| ---------- | -------------------------- | ------- |
| 1          | VDD\_5V\_HIPOWER           | 5.0V    |
| 2          | UART8\_TX\_GPS2\_EXT       | 3.3V    |
| 3          | UART8\_RX\_GPS2\_EXT       | 3.3V    |
| 4          | I2C2\_SCL\_BASE\_GPS2\_EXT | 3.3V    |
| 5          | I2C2\_SDA\_BASE\_GPS2\_EXT | 3.3V    |
| 6          | GND                        | GND     |

### **CAN1**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | VDD\_5V\_HIPOWER | 5.0V    |
| 2          | CAN1\_H          | 3.3V    |
| 3          | CAN1\_L          | 3.3V    |
| 4          | GND              | GND     |

### **CAN2**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | VDD\_5V\_PERIPH | 5.0V    |
| 2          | CAN2\_H         | 3.3V    |
| 3          | CAN2\_L         | 3.3V    |
| 4          | GND             | GND     |

### **RC**

| Pin Number | Signal Name                 | Voltage |
| ---------- | --------------------------- | ------- |
| 1          | VDD\_5V\_SBUS\_RC           | 5.0V    |
| 2          | RX\_SBUS\_IN\_EXT           | 3.3V    |
| 3          | USART6\_TX\_RC\_OUTPUT\_EXT | 3.3V    |
| 4          | VDD\_3V3\_SPEKTRUM          | 3.3V    |
| 5          | GND                         | GND     |

### **PWM**

| Pin Number | Signal Name            | Voltage    |
| ---------- | ---------------------- | ---------- |
| 1          | VDD SERVO (NO CONNECT) | NO CONNECT |
| 2          | FMU\_CH1\_EXT          | 3.3V       |
| 3          | FMU\_CH2\_EXT          | 3.3V       |
| 4          | FMU\_CH3\_EXT          | 3.3V       |
| 5          | FMU\_CH4\_EXT          | 3.3V       |
| 6          | FMU\_CH5\_EXT          | 3.3V       |
| 7          | FMU\_CH6\_EXT          | 3.3V       |
| 8          | FMU\_CH7\_EXT          | 3.3V       |
| 9          | FMU\_CH8\_EXT          | 3.3V       |
| 10         | GND                    | GND        |

### **ADIO**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | VDD\_5V\_PERIPH | 5.0V    |
| 2          | FMU\_CAP\_EXT   | 3.3V    |
| 3          | NARMED\_EXT     | 3.3V    |
| 4          | ADC1\_3V3\_EXT  | 3.3V    |
| 5          | ADC1\_6V6\_EXT  | 6.6V    |
| 6          | GND             | GND     |

### **SPI6**

| Pin Number | Signal Name       | Voltage |
| ---------- | ----------------- | ------- |
| 1          | VDD\_5V\_PERIPH   | 5.0V    |
| 2          | SPI6\_SCK\_EXT    | 3.3V    |
| 3          | SPI6\_MISO\_EXT   | 3.3V    |
| 4          | SPI6\_MOSI\_EXT   | 3.3V    |
| 5          | SPI6\_NCS1\_EXT   | 3.3V    |
| 6          | SPI6\_NCS2\_EXT   | 3.3V    |
| 7          | SPIX\_NSYNC\_EXT  | 3.3V    |
| 8          | SPI6\_DRDY1\_EXT  | 3.3V    |
| 9          | SPI6\_DRDY2\_EXT  | 3.3V    |
| 10         | SPI6\_NRESET\_EXT | 3.3V    |
| 11         | GND               | GND     |

### **I2C3**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | VDD\_5V\_PERIPH | 5.0V    |
| 2          | I2C3\_SCL\_EXT  | 3.3V    |
| 3          | I2C3\_SDA\_EXT  | 3.3V    |
| 4          | GND             | GND     |

### **UART4/I2C3**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | VDD\_5V\_PERIPH | 5.0V    |
| 2          | UART4\_TX\_EXT  | 3.3V    |
| 3          | UART4\_RX\_EXT  | 3.3V    |
| 4          | I2C3\_SCL\_EXT  | 3.3V    |
| 5          | I2C3\_SDA\_EXT  | 3.3V    |
| 6          | GND             | GND     |

### **FC Debug**

| Pin Number | Signal Name            | Voltage |
| ---------- | ---------------------- | ------- |
| 1          | 3V3\_FMU               | 3.3V    |
| 2          | USART3\_TX\_DEBUG      | 3.3V    |
| 3          | USART3\_RX\_DEBUG\_EXT | 3.3V    |
| 4          | FMU\_SWDIO             | 3.3V    |
| 5          | FMU\_SWCLK             | 3.3V    |
| 6          | SPI6\_SCK\_EXTERNAL1   | 3.3V    |
| 7          | NFC\_GPIO              | 3.3V    |
| 8          | PD15                   | 3.3V    |
| 9          | FMU\_NRST              | 3.3V    |
| 10         | GND                    | GND     |

### **Jetson SPI0**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | VDD\_5V\_JPERIPH | 5.0V    |
| 2          | SPI0\_MOSI\_3V3  | 3.3V    |
| 3          | SPI0\_SCK\_3V3   | 3.3V    |
| 4          | SPI0\_MISO\_3V3  | 3.3V    |
| 5          | SPI0\_CS0N\_3V3  | 3.3V    |
| 6          | SPI0\_CS1N\_3V3  | 3.3V    |
| 7          | GND              | GND     |

### **Jetson SPI1**

| Pin Number | Signal Name      | Voltage    |
| ---------- | ---------------- | ---------- |
| 1          | VDD\_5V\_JPERIPH | 5.0V       |
| 2          | SPI1\_MOSI\_3V3  | 3.3V       |
| 3          | SPI1\_SCK\_3V3   | 3.3V       |
| 4          | SPI1\_MISO\_3V3  | 3.3V       |
| 5          | SPI1\_CS0N\_3V3  | 3.3V       |
| 6          | NO CONNECT       | NO CONNECT |
| 7          | GND              | GND        |

### **Jetson I2S0**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | VDD\_5V\_JPERIPH | 5.0V    |
| 2          | I2S0\_DOUT\_3V3  | 3.3V    |
| 3          | I2S0\_DIN\_3V3   | 3.3V    |
| 4          | I2S0\_LRCLK\_3V3 | 3.3V    |
| 5          | I2S0\_SCLK\_3V3  | 3.3V    |
| 6          | AUD\_MCLK\_3V3   | 3.3V    |
| 7          | GND              | GND     |

### **Jetson I2C0**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | VDD\_5V\_JPERIPH | 5.0V    |
| 2          | I2C0\_SCL\_EXT   | 3.3V    |
| 3          | I2C0\_SDA\_EXT   | 3.3V    |
| 4          | GND              | GND     |

### **Jetson CAN**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | VDD\_5V\_JPERIPH | 5.0V    |
| 2          | JCAN\_H          | 3.3V    |
| 3          | JCAN\_L          | 3.3V    |
| 4          | GND              | GND     |

### **Jetson Fan**

| Pin Number | Signal Name      | Voltage |
| ---------- | ---------------- | ------- |
| 1          | GND              | GND     |
| 2          | VDD\_5V\_JPERIPH | 5.0V    |
| 3          | FAN\_TACH\_CON   | 5.0V    |
| 4          | FAN\_PWM\_Q\*    | 5.0V    |

### **Jetson M.2 Key E**

| Pin Number   | Signal Name               | Voltage |
| ------------ | ------------------------- | ------- |
| 2, 4, 72, 74 | 3V3                       | 3.3V    |
| 3            | HUB\_USB4\_M2\_P          | 3.3V    |
| 5            | HUB\_USB4\_M2\_N          | 3.3V    |
| 8            | I2S1\_SCLK                | 1.8V    |
| 10           | I2S1\_LRCLK               | 1.8V    |
| 12           | I2S1\_DIN                 | 1.8V    |
| 14           | I2S1\_DOUT                | 1.8V    |
| 20           | BT\_M2\_WAKE\_AP (GPIO02) | 1.8V    |
| 22           | UART0\_RXD\_1V8           | 1.8V    |
| 32           | UART0\_TXD\_1V8           | 1.8V    |
| 34           | UART0\_CTS\_1V8           | 1.8V    |
| 36           | UART0\_RTS\_1V8           | 1.8V    |
| 58           | I2C\_M2\_DATA\_1V8        | 1.8V    |
| 60           | I2C\_M2\_CLK\_1V8         | 1.8V    |

### **Jetson Debug**

| Pin Number | Signal Name     | Voltage    |
| ---------- | --------------- | ---------- |
| 1          | 3V3             | 3.3V       |
| 2          | UART2\_TXD\_3V3 | 3.3V       |
| 3          | UART2\_RXD\_3V3 | 3.3V       |
| 4          | NO CONNECT      | NO CONNECT |
| 5          | NO CONNECT      | NO CONNECT |
| 6          | GND             | GND        |

### **Jetson CSI0**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | 3V3             | 3.3V    |
| 2          | CAM0\_SDA       | 3.3V    |
| 3          | CAM0\_SCL       | 3.3V    |
| 4          | CAM0\_MCLK      | 1.8V    |
| 5          | CAM0\_PWDN\_3V3 | 3.3V    |
| 6          | GND             | GND     |
| 7          | CSI0\_CLK\_P    | 1.2V    |
| 8          | CSI0\_CLK\_N    | 1.2V    |
| 9          | GND             | GND     |
| 10         | CSI0\_D1\_P     | 1.2V    |
| 11         | CSI0\_D1\_N     | 1.2V    |
| 12         | GND             | GND     |
| 13         | CSI0\_D0\_P     | 1.2V    |
| 14         | CSI0\_D0\_N     | 1.2V    |
| 15         | GND             | GND     |

### **Jetson CSI1**

| Pin Number | Signal Name     | Voltage |
| ---------- | --------------- | ------- |
| 1          | 3V3             | 3.3V    |
| 2          | CAM1\_SDA       | 3.3V    |
| 3          | CAM1\_SCL       | 3.3V    |
| 4          | CAM1\_MCLK      | 1.8V    |
| 5          | CAM1\_PWDN\_3V3 | 3.3V    |
| 6          | GND             | GND     |
| 7          | CSI1\_CLK\_P    | 1.2V    |
| 8          | CSI1\_CLK\_N    | 1.2V    |
| 9          | GND             | GND     |
| 10         | CSI1\_D1\_P     | 1.2V    |
| 11         | CSI1\_D1\_N     | 1.2V    |
| 12         | GND             | GND     |
| 13         | CSI1\_D0\_P     | 1.2V    |
| 14         | CSI1\_D0\_N     | 1.2V    |
| 15         | GND             | GND     |

### **Jetson CSI2**

| Pin Number | Signal Name                                   | Voltage |
| ---------- | --------------------------------------------- | ------- |
| 1          | 3V3                                           | 3.3V    |
| 2          | CAM2\_SDA                                     | 3.3V    |
| 3          | CAM2\_SCL                                     | 3.3V    |
| 4          | CAM2\_MCLK (GPIO01 GP65)                      | 1.8V    |
| 5          | CAM2\_PWDN\_3V3 (SPI1\_CS1\* GP40\_SPI3\_CS1) | 3.3V    |
| 6          | GND                                           | GND     |
| 7          | CSI2\_CLK\_P                                  | 1.2V    |
| 8          | CSI2\_CLK\_N                                  | 1.2V    |
| 9          | GND                                           | GND     |
| 10         | CSI2\_D1\_P                                   | 1.2V    |
| 11         | CSI2\_D1\_N                                   | 1.2V    |
| 12         | GND                                           | GND     |
| 13         | CSI2\_D0\_P                                   | 1.2V    |
| 14         | CSI2\_D0\_N                                   | 1.2V    |
| 15         | GND                                           | GND     |

### **Jetson CSI3**

| Pin Number | Signal Name              | Voltage |
| ---------- | ------------------------ | ------- |
| 1          | 3V3                      | 3.3V    |
| 2          | CAM3\_SDA                | 3.3V    |
| 3          | CAM3\_SCL                | 3.3V    |
| 4          | CAM3\_MCLK (GPIO11 GP66) | 1.8V    |
| 5          | CAM3\_PWDN\_3V3 (GPIO06) | 3.3V    |
| 6          | GND                      | GND     |
| 7          | CSI3\_CLK\_P             | 1.2V    |
| 8          | CSI3\_CLK\_N             | 1.2V    |
| 9          | GND                      | GND     |
| 10         | CSI3\_D1\_P              | 1.2V    |
| 11         | CSI3\_D1\_N              | 1.2V    |
| 12         | GND                      | GND     |
| 13         | CSI3\_D0\_P              | 1.2V    |
| 14         | CSI3\_D0\_N              | 1.2V    |
| 15         | GND                      | GND     |


# Mini DisplayPort

The Mini DisplayPort will work natively with a DisplayPort capable monitor.

In order to use HDMI, an active Mini DisplayPort to HDMI adapter is required. We recommend the [Plugable Mini DisplayPort/Thunderbolt™ 2 to HDMI 2.0 Active Adapter](https://plugable.com/products/mdp-hdmi).


# Block Diagram

<figure><img src="/files/UxWAJTPSqypZhkREH5EL" alt=""><figcaption><p>Block diagram</p></figcaption></figure>


# 3D Models and Case Files

Step files can be found here\
<https://github.com/ARK-Electronics/ark_jetson_hardware>


# GPIO Control

The I2S0 connector pins come up as general-purpose GPIOs by default — no overlay or jetson-io step is needed. At idle the SoC drives none of them: the four output-capable pins sit hi-z, held HIGH by 604Ω pull-ups on the carrier, and DIN is a floating input. A pin wired to a relay or actuator never transitions at boot.

## I2S0 Connector Pin Mapping

| ARK Pin | Signal           | 40-Pin Header | libgpiod Name | Idle at Boot  |
| ------- | ---------------- | ------------- | ------------- | ------------- |
| 1       | VDD\_5V\_JPERIPH | -             | -             | -             |
| 2       | I2S0\_DOUT\_3V3  | Pin 40        | `PI.00`       | HIGH (pulled) |
| 3       | I2S0\_DIN\_3V3   | Pin 38        | `PI.01`       | hi-z (input)  |
| 4       | I2S0\_LRCLK\_3V3 | Pin 35        | `PI.02`       | HIGH (pulled) |
| 5       | I2S0\_SCLK\_3V3  | Pin 12        | `PH.07`       | HIGH (pulled) |
| 6       | AUD\_MCLK\_3V3   | Pin 7         | `PAC.06`      | HIGH (pulled) |
| 7       | GND              | -             | -             | -             |

Confirm the lines are exposed:

```bash
sudo gpioinfo | grep -E '"P(H\.07|I\.0[0-2]|AC\.06)"'
```

## Using the GPIOs

Drive and read the lines with `libgpiod` (`gpioset` / `gpioget`) or the Jetson.GPIO Python library. Jetson.GPIO addresses pins by their 40-pin header number and needs version 2.1.12 or newer:

```bash
sudo pip3 install 'Jetson.GPIO>=2.1.12'
```

The example below jumpers HDR40 pin 40 (DOUT) to pin 38 (DIN) and toggles HIGH/LOW, reading each transition back as a loopback test:

```python
import time
import Jetson.GPIO as GPIO

GPIO.setmode(GPIO.BOARD)
GPIO.setup(40, GPIO.OUT, initial=GPIO.LOW)  # I2S0_DOUT
GPIO.setup(38, GPIO.IN)                     # I2S0_DIN

try:
    for level in (GPIO.HIGH, GPIO.LOW, GPIO.HIGH, GPIO.LOW):
        GPIO.output(40, level)
        time.sleep(0.2)
        got = GPIO.input(38)
        print(f"wrote {level} read {got} {'PASS' if got == level else 'FAIL'}")
finally:
    GPIO.cleanup()
```

ARK-OS ships a complete version of this loopback as `i2s_gpio_example.py` (on `PATH`).

{% hint style="warning" %}
**GPIO state after your app exits**

While your app owns a line, the kernel guarantees its value. On release (clean exit, crash, or kill), **the pin retains its last-written value** until the next reboot re-asserts the pulled-HIGH idle state. If a line must be safe-off for an active-high load, add an external pull-down or keep a process owning the line (`gpioset --mode=signal`).
{% endhint %}

For the full pin reference, electrical details, and safe-state patterns, see the [ARK Jetson Kernel GPIO docs](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/gpio.md).


# Camera Overlays

The ARK Jetson PAB Carrier has **4× 2-lane CSI ports**. Camera configuration is managed through device tree overlays, and the image ships with the **IMX219 quad** overlay active — IMX219 cameras work on all four ports out of the box.

## Supported Cameras

| Sensor | Resolution | Overlay            | Status            |
| ------ | ---------- | ------------------ | ----------------- |
| IMX219 | 3280x2464  | Camera IMX219 Quad | Working (default) |
| IMX477 | 4056x3040  | Camera IMX477 Quad | Working           |
| IMX708 | 4608x2592  | Camera IMX708 Quad | Working           |

4-lane CSI modes are not supported — 2-lane provides full resolution at 30 fps for the IMX477. See [cameras.md](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/cameras.md) in the kernel repo for sensor details, verification commands, and known issues.

## Switching Overlays

List the overlays available on your Jetson:

```bash
sudo /opt/nvidia/jetson-io/config-by-hardware.py -l
```

Apply one and reboot:

```bash
sudo /opt/nvidia/jetson-io/config-by-hardware.py -n 2="Camera IMX477 Quad"
sudo reboot
```

## Verifying a Camera

Check that the sensor is detected:

```bash
nvargus_nvraw --lps
```

ARK-OS also ships `check_cameras.sh` (on `PATH`) which stream-tests every connected CSI camera, and the [ARK-UI](http://jetson.local) **Video** page shows a live stream of the first camera.

## Custom Overlays

To build your own camera overlay — or install one on an already-flashed system — follow [camera\_overlays.md](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/docs/camera_overlays.md) in the kernel repo.


# Power Cycling USB Ports

The USB ports can be power cycled from the command line through using uhubctl for three of the ports and a GPIO for the fourth.

The single USB 2.0 port and the two USB 3 ports that are on the combined connector are controlled by the USB hub. Use uhubctl to cycle power on those ports. Ports 1 and 2 are the USB 3 connectors and port 3 is the USB 2.0 connector.

```
sudo uhubctl -l 1-2 -a off
sudo uhubctl -l 1-2 -a on
```

The standalone USB 3 port is controlled by GPIO12. Use the gpioset command as an open drain to drive low for a short amount of time. There is a pullup on the signal to 1.8V and it is also connected to the open drain FLG output of the current monitor to shut off the port in an over current event.

```
sudo gpioset --drive=open-drain --mode=time -s 1 gpiochip0 85=0
```


# Developer Guide

* [Flashing Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer/flashing-guide) — flash a prebuilt release, or build from source
* [Micro USB Console](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier/developer/micro-usb-console) — serial login over the USB cable
* [USB Peripherals](/knowledge-base/knowledge-base/usb-peripherals) — tested Wi-Fi and Bluetooth adapters, USB camera EMI
* [Apt: Hold Back Risky Packages](/software/ark-os/apt-hold-back) — keep `apt upgrade` from overwriting the ARK kernel


# Flashing Guide

Bundles ship pre-flashed with the ARK Jetson image and ARK-OS. Follow this guide to update to a newer release or to flash a Jetson for the first time.

The image is built from the [ark\_jetson\_kernel](https://github.com/ARK-Electronics/ark_jetson_kernel) repository, which adds the carrier's device tree to NVIDIA's JetPack. One image covers every Orin Nano/NX module variant.

{% hint style="info" %}
A stock NVIDIA JetPack image will not enable all carrier hardware — use the ARK image, or build from source with the ARK device tree.
{% endhint %}

## Enter Recovery Mode

Connect the **Micro USB** port to your host PC, then power on the Jetson while holding the **Force Recovery** button.

![](/files/O6Pk9WiqyDKpRuO5gDh9)

## Flash a Prebuilt Release (recommended)

On a Debian/Ubuntu host, download the flasher script and flash the latest PAB release to the NVMe SSD:

```bash
curl -LO https://raw.githubusercontent.com/ARK-Electronics/ark_jetson_kernel/main/packaging/flash_from_package.sh
chmod +x flash_from_package.sh
./flash_from_package.sh pab
```

The script downloads the release package from the [releases page](https://github.com/ARK-Electronics/ark_jetson_kernel/releases) (tags starting with `pab-`), waits for the Jetson in recovery mode, and flashes the bootloader and root filesystem. No build tools needed. Pass a specific tag instead of `pab` to flash a specific version.

{% hint style="warning" %}
Hardware revision 3 of this carrier (PAB Rev 3) still uses the `pab` image. `pab-v3` releases are for the [ARK Jetson PAB Carrier V3](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3), a different product.
{% endhint %}

## Build From Source

To customize the kernel, device tree, or preinstalled software, build and flash from source — see the [ark\_jetson\_kernel README](https://github.com/ARK-Electronics/ark_jetson_kernel#build--flash):

```bash
./setup.sh          # one-time download of BSP + rootfs + sources
./build.sh PAB      # build and provision the image (installs ARK-OS)
./flash.sh PAB      # flash to NVMe (--sdcard and --usb also available)
```

You can bake a WiFi profile into the image before flashing with `./scripts/add_wifi_network.sh PAB <ssid> <password>`.


# Micro USB Console

Plugging a Micro USB cable into the Jetson carrier disconnects the flight controller from the Jetson's USB and puts the Jetson in USB device mode. It enumerates as one USB composite device (`0955:7020`) providing four functions:

| Function                   | Host sees                                             |
| -------------------------- | ----------------------------------------------------- |
| RNDIS + CDC-NCM networking | Two USB Ethernet interfaces; Jetson at `192.168.55.1` |
| CDC-ACM serial             | Virtual COM port with a login console                 |
| Mass storage               | `L4T-README` drive                                    |

{% hint style="warning" %}
After disconnecting the Micro USB cable, reboot the Jetson to reconnect the flight controller USB.
{% endhint %}

## Serial Console

Use the `by-id` path — the `ttyACM` number changes between sessions:

```bash
ls -l /dev/serial/by-id/
usb-NVIDIA_Linux_for_Tegra_1613223640377-if02 -> ../../ttyACM1
```

```bash
screen /dev/serial/by-id/usb-NVIDIA_Linux_for_Tegra_*-if02 115200
```

Log in with your username and password (default `jetson` / `jetson`). Your user must be in the `dialout` group.

On macOS the port is `/dev/tty.usbmodem*`; on Windows it is a `COMx` port in Device Manager.

{% hint style="info" %}
This is not a boot console. The gadget (`nv-l4t-usb-device-mode.service`) and login prompt (`serial-getty@ttyGS0.service`) start under `multi-user.target`, so there is no UEFI, bootloader, or early kernel output — and no port at all if boot hangs before that point. For boot-level debugging use the physical UART console.
{% endhint %}


# ARK Jetson PAB Carrier V3

An NVIDIA Jetson Orin Nano/NX carrier board built around the ARKV6X flight controller and the Pixhawk Autopilot Bus. It runs PX4 and ships with ARK-OS pre-installed. The V3 adds a dedicated I/O co-processor (16 PWM outputs), consolidates wiring into two 40-pin avionics connectors, and adds a 30-pin Pixhawk Payload Bus — see the [comparison table](/products/flight-controller/jetson-pabs).

## Where to Start

**Your bundle arrived preflashed.** The Jetson already runs ARK-OS and the flight controller already has PX4. Go to [Set Up Your Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/setup), then manage it from the ARK-UI web interface.

**You have a bare board, or you want to flash it yourself.** Install a Jetson module and NVMe SSD, then start at the [Flashing Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/developer/flashing-guide).

## Sections

* [Set Up Your Carrier](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/setup) — connect to it and get it on your network
* [Using ARK-OS](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/using-ark-os) — services, web interface, autopilot connections
* [Hardware Reference](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/hardware) — pinout, GPIO, cameras
* [Developer Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/developer) — flashing, serial console, building from source


# Set Up Your Carrier

## What's Pre-Installed

Bundles ship ready to use — no flashing required:

* **Jetson**: Latest ARK Jetson image (JetPack 6 / L4T r36) on the NVMe SSD, with [ARK-OS](https://github.com/ARK-Electronics/ARK-OS) pre-installed
* **Flight Controller**: Latest PX4 stable firmware
* **Credentials**: Username `jetson`, password `jetson`, hostname `jetson`

{% hint style="info" %}
The default password is well known — change it (`passwd`) before putting the vehicle on a network you don't control.
{% endhint %}

A bare carrier board (no Jetson module or SSD) has no OS on it. Install your module and NVMe SSD, then follow the [Flashing Guide](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/developer/flashing-guide).

## Steps

1. [Connect](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/setup/connect) — reach the Jetson over USB-C, WiFi hotspot, or Ethernet.
2. [Get Online](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/setup/get-online) — join it to your WiFi network.
3. [ARK-OS](/software/ark-os) — the preinstalled services and the ARK-UI web interface.
4. [Autopilot Connections](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/using-ark-os/autopilot-connections) — connect QGroundControl or Mission Planner.


# Connect

## USB-C

Connect the USB-C port to your PC. The Jetson appears as a USB network device at `192.168.55.1`:

```bash
ssh jetson@192.168.55.1
```

The web UI is reachable the same way at <http://192.168.55.1>.

The same cable also carries a serial login console — see [USB-C Console](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/developer/micro-usb-console).

## WiFi Hotspot

On first boot, if no known WiFi network is available, the Jetson brings up a hotspot:

* **Network**: `jetson-<serial>`
* **Password**: `password`

Connect to it and open <http://jetson.local>.

{% hint style="info" %}
**MHF4 antenna cables are required for WiFi and are not included.** Compatible MHF4 to RP-SMA cables: [option 1](https://www.amazon.com/female-Pigtail-Antenna-Extension-wireless/dp/B07GTL2G69), [option 2](https://www.amazon.com/dp/B076SGTMFS). Some bundles ship without the WiFi card — the hotspot only appears when a WiFi card is installed.
{% endhint %}

## Ethernet

Connect the 4-pin JST-GH Ethernet port to your network — the Jetson requests an address over DHCP. The onboard switch also connects the flight controller and the Pixhawk Payload Bus, see [Autopilot Connections](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/using-ark-os/autopilot-connections).

Once the Jetson is on your network:

```bash
ssh jetson@jetson.local
```


# Get Online

## From ARK-UI

Open <http://jetson.local> (or <http://192.168.55.1> over USB-C) and join a network from the **Connections** page:

<figure><img src="/files/osyXWg6wonr7N6RblBS4" alt=""><figcaption><p>ARK-UI Connections page</p></figcaption></figure>

## From the Command Line

Scan for networks:

```bash
sudo nmcli device wifi
```

Connect to a network:

```bash
sudo nmcli device wifi connect 'SSID' password 'PASSWORD'
```

## Sharing Your PC's Internet over USB

The kernel repo ships a helper that NATs the Jetson's traffic out through your host PC's WiFi — see [share\_wifi.sh](https://github.com/ARK-Electronics/ark_jetson_kernel/blob/main/scripts/share_wifi.sh).

You can also bake a WiFi profile into the image before flashing with `./scripts/add_wifi_network.sh PAB_V3 <ssid> <password>`.


# Using ARK-OS

[ARK-OS](/software/ark-os) is preinstalled on every bundle: MAVLink routing, video streaming, flight log management, firmware updates, and network RTK corrections, plus the ARK-UI web interface at <http://jetson.local>.

* [ARK-OS and ARK-UI](/software/ark-os)
* [Services](/software/ark-os/services) — what each service does, and which are enabled by default
* [Apt: Hold Back Risky Packages](/software/ark-os/apt-hold-back) — read before running `apt upgrade`

## On This Carrier

* [Autopilot Connections](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/using-ark-os/autopilot-connections) — connect QGroundControl or Mission Planner
* [Updating the Flight Controller Firmware](/products/flight-controller/jetson-pabs/ark-jetson-pab-carrier-v3/using-ark-os/updating-the-flight-controller-firmware)


# Autopilot Connections

There are three communication channels between the Jetson and the flight controller: USB, serial, and Ethernet. USB and serial are direct board-to-board connections tested up to 3 Mbps; Ethernet runs through the onboard 100 Mbps switch.

| Type     | Jetson device path | Flight Controller |
| -------- | ------------------ | ----------------- |
| USB      | /dev/ttyACM0       | USB               |
| Serial   | /dev/ttyTHS1       | Telem2            |
| Ethernet | enP8p1s0           | eth0              |

{% hint style="info" %}
We recommend running MAVLink on USB and XRCE-DDS on serial. ARK-OS's defaults do exactly this — see [Services](/software/ark-os/services).
{% endhint %}

## USB

For the flight controller's USB to enumerate, its VBUS\_SENSE pin must be driven high by the Jetson. This is set in the Jetson pinmux at boot, so it works out of the box.

## Serial

The serial connection is Jetson UART1 (`/dev/ttyTHS1`) to **Telem2** on the flight controller, tested to 3 Mbps. When running MAVLink on Telem2, set flow control to off: [MAV\_x\_FLOW\_CTRL](https://docs.px4.io/main/en/advanced_config/parameter_reference.html#MAV_1_FLOW_CTRL) = 0.

## Ethernet

The flight controller and Jetson are connected through a 100 Mbps switch on the board, along with two external connections: the 4-pin JST-GH Ethernet connector and the Pixhawk Payload Bus FFC.

To set up the flight controller side, follow the [PX4 Ethernet guide](https://docs.px4.io/main/en/advanced_config/ethernet_setup) or the [ArduPilot network guide](https://ardupilot.org/copter/docs/common-network.html). If one of the external connections leads to a router running DHCP, both the Jetson and flight controller get addresses from it; otherwise configure static IPs on both ends.

## Flight Controller Reset

The Jetson can hard-reset the flight controller via a GPIO reset line. The reset is gated by the nARMED signal — the Jetson cannot reset the flight controller while it is armed.

ARK-OS ships two reset helpers on `PATH`:

```bash
reset_fmu_fast.py       # reset and boot straight into the application
reset_fmu_wait_bl.py    # reset and wait in the bootloader (for firmware flashing)
```


# QGroundControl Connection

When using PX4 or ArduPilot on the ARKV6X, to connect to QGroundControl, use UDP as the connection type. Enter the IP address(or hostname ie jetson.local) of the Jetson with port 14550.

<figure><img src="/files/Asp0Kph4Q5oWpWh8dotF" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/wRijeKaTxjTtvZdmkGwB" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/0TAxG8ADwDtgBtqoGVZ8" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/K9vwnUcqVWdI9elfxDqp" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/LQB328gevusIfqYwtk5S" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/eESK12wJPFXm0x18HEsK" alt=""><figcaption></figcaption></figure>


# MissionPlanner ArduPilot Connection

When using ArduPilot on the ARKV6X, to connect to MissionPlanner, use UDPCI as the connection type. Enter the IP address of the Jetson with port 14550.

<figure><img src="/files/bh07kDwj4p7gGT4eGSHV" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/g98P6P2OFaSeDUdsKqEM" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/IUN9MBI6sr603V6sk3yk" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/5OUO3MH2P4NVOEYcFEgk" alt=""><figcaption></figcaption></figure>




---

[Next Page](/llms-full.txt/1)