DOCSEARCHbyAlgolia
Submit Docs

Onion Omega Documentation

website·Indexed 32 days ago

https://documentation.onioniot.com

Technical documentation for Onion IoT hardware, including the Omega4 and Omega2 legacy series (Omega2, Omega2 Pro, Omega2 S/S+, Omega2 LTE, and Omega2 Dash). Covers hardware overviews, networking configurations like Wi-Fi AP and Bluetooth GATT provisioning, and software libraries for C, Python, and Node.js to control expansion docks, PWM, relays, and OLED displays.

Tokens
115.4K
Snippets
672
Records
1.1K
Agent score
57%

What's inside Onion Omega

  1. Overview of Omega4 Hardware RTC

    The Omega4 features a hardware real-time clock (RTC) that maintains time when the main system is powered off, provided RTC power is present. On the Omega4 EVB, the RTC backup battery holder uses a CR1220 coin cell. The system is configured to update the RTC after an NTP sync to ensure time persists across reboots.

  2. Overview of the pivot-overlay procedure for Omega2

    The pivot-overlay process extends the Omega2's storage capacity by moving the writable portion of the firmware (/overlay) to an external storage device (USB drive or MicroSD card). The Omega's filesystem consists of a read-only base (/rom) and a writable layer (/overlay); pivot-overlay redirects the writable layer to external media, allowing the user to install more packages and store more data.

  4. Overview of Omega2 Package Repositories

    A package repo is an HTTP file server that stores compiled packages and a package index. Omega2 devices use this repository as a source for the OPKG package manager to install and track software versions. To function correctly, the repository must be accessible via HTTP and include a package index (created during the production compilation process).

  7. Overview of the Omega2 Expansion Dock hardware

    The Expansion Dock simplifies the use of the Omega2 by providing power management, serial communication, and easy access to GPIOs. It features a 30-pin Expansion Header for Onion Expansions, a Micro-USB port for 5V power (stepped down to 3.3V for the Omega), and a USB-to-Serial chip for terminal access via a computer. It also includes a USB 2.0 Type-A port for external storage and an RGB LED for status indication.

  8. Overview of the Omega4 Camera and Video Stack

    The Omega4 supports camera capture via the RV1103B MIPI CSI-2, CIF, and ISP pipeline. The hardware path flows from the SC3336 camera sensor through the MIPI CSI-2 receiver, Rockchip CIF bridge, and Rockchip ISP, eventually exposing a V4L2 capture node (commonly /dev/video7).

    There are three primary workflows for consuming these frames:

    1. Still frame: /dev/video7 $\rightarrow$ v4l2-ctl or mfg-camera-test $\rightarrow$ NV12 raw frame.
    2. Video: /dev/video7 $\rightarrow$ omega4-vencd $\rightarrow$ hardware VENC $\rightarrow$ H.264 file or stream.
    3. Inference: /dev/video7 $\rightarrow$ omega4-rknn-yolo-live $\rightarrow$ NPU $\rightarrow$ JSON detection output.
    SC3336 camera sensor
  -> MIPI CSI-2 receiver
  -> Rockchip CIF bridge
  -> Rockchip ISP
  -> V4L2 capture node, commonly /dev/video7

  9. Overview of Custom Firmware for Omega2

    Custom firmware for the Omega2 allows developers to create a firmware image tailored to a specific application use case. This includes integrating default and custom software packages, as well as pre-configuring device features like networking and WiFi.

    Key benefits include:

    • Reduced Production Time: A single image can be flashed during manufacture.
    • Persistent Customizations: After a factory reset, the device reverts to the custom firmware's default state rather than the generic Onion firmware, ensuring the application remains functional.

  10. Overview of Omega4 Hardware H.264 Encoding (VENC)

    Omega4 firmware v0.0.14 and newer supports hardware H.264 encoding using the RV1103B RKVENC block. The omega4-vencd command captures NV12 frames from the camera, processes them through the Rockchip MPP encoder, and outputs an Annex-B H.264 stream. This hardware-accelerated path avoids the need to copy raw frames to a host computer for encoding.

    The typical data pipeline is: SC3336 camera sensor $\rightarrow$ MIPI CSI-2 / CIF / ISP $\rightarrow$ /dev/video7 (V4L2 NV12 frames) $\rightarrow$ omega4-vencd $\rightarrow$ Rockchip MPP / RKVENC $\rightarrow$ H.264 output.

  11. Overview of the Omega4 NPU and Camera Stack

    The Omega4 (firmware v0.0.14+) supports the RV1103B NPU via the Rockchip RKNPU driver and RKNN runtime. The NPU pipeline flows from the camera sensor through the Rockchip ISP/RKAIQ, into a V4L2 capture node (typically /dev/video7), through userspace frame preparation, and finally into the RKNN runtime and /dev/rknpu for classification or object detection output.

    Note: The NPU inference path is separate from the video encoder path. Because current CLI tools open the camera capture node directly, only one camera-owning process (e.g., either the encoder or the detector) can run at a time unless a shared capture pipeline is implemented.

  12. Overview of the OpenWRT package build pipeline

    The process of creating a deployable package for Omega2 follows these stages:

    1. Package Source Code: A collection of source files and a package makefile (the blueprint specifying name, version, and compilation instructions).
    2. Package Feed: A repository of package sources used as input for the OpenWRT SDK or build system.
    3. Compilation: The build system retrieves files from the feed, resolves dependencies, and compiles the code.
    4. IPK Binary: The result of compilation is an .ipk file containing the binaries and metadata.
    5. Package Repo: The .ipk files are hosted in an online repository, allowing users to install them via OPKG.