Skip to content

Latest commit

 

History

History
117 lines (84 loc) · 4.93 KB

File metadata and controls

117 lines (84 loc) · 4.93 KB

NiusCam documentation

Welcome to the NiusCam documentation. Start with the path that matches the work you are doing.

New user path

  1. Getting started — install Arduino-ESP32 and NiusCam, select the correct board, upload BasicCapture, and validate the sensor.
  2. Supported hardware — confirm the camera module, sensor, storage interface, and compatibility limits.
  3. Configuration and profiles — choose Eco, Balanced, or Turbo and tune resolution, JPEG quality, buffers, clocks, and controls.
  4. Open the public Arduino example closest to the intended application.
  5. Use Troubleshooting if a build, camera, card, or network step fails.

Guides by task

Task Read this Matching example
Install and capture the first image Getting started BasicCapture
Select a board or adapt another module Supported hardware BasicCapture
Tune image output and sensor behavior Configuration and profiles FullControl
Focus an OV5640 AF module OV5640 autofocus Autofocus
Configure OV2640 low-light timing OV2640 low-light timing Ov2640LowLight
Integrate lifecycle and controls API reference BasicCapture, FullControl, PowerModes
Save JPEGs and report progress Storage SaveToSD
Serve a browser viewer Streaming HttpStream
Build a low-latency UDP system Streaming, UDP protocol UdpStream
Compare verified behavior and limits Verified results
Diagnose a problem Troubleshooting Start with BasicCapture

Reference map

Arduino IDE package URL, ESP32 platform installation, ZIP/source installation, board menu values, upload notes, first capture, and installation validation.

Verified modules, OV2640/OV3660/OV5640 status, alternate lens variants, automatic profile selection, explicit/custom profiles, storage buses, and electrical compatibility boundaries.

Exact Eco/Balanced/Turbo defaults, every Config field, formats, frame-size names and dimensions, JPEG tuning, buffer ownership, live sensor controls, PSRAM DMA diagnostics, and native access.

Single-shot and continuous autofocus, status handling, firmware behavior, module electrical requirements, and the verified compatibility boundary.

OmniVision's automatic 50/60 Hz frame-rate sequences, object-style API, 24 MHz requirement, restoration, and reproduced dark-scene measurements.

Headers, errors, camera lifecycle, frame ownership, configuration, board profiles, capabilities, every portable sensor-control group, diagnostics, storage, HTTP, UDP, and concurrency rules.

Card preparation, board buses, mounting, capacity reporting, atomic JPEG files, progress callbacks, sequential names, bounded recording, and mount/write fault diagnosis.

Transport selection, SoftAP and station setup, HTTP routes, MJPEG ownership, UDP setup, receiver requirements, tuning, reconnects, and security boundaries.

Byte-level header layout, little-endian encoding, CRC32, receiver validation, frame ID wraparound, eviction, and protocol limitations.

Symptom-based checks for installation, upload, sensor detection, PSRAM, memory, lifecycle recovery, microSD, HTTP, and UDP.

Public test scope, compile matrix, three-board endurance, storage integrity, driver overhead, throughput, network transport, image equivalence, and bounded power claims.

Example-to-document relationship

Examples stay concise and contain no personal network credentials. The guides explain design choices, failure handling, and deployment concerns that would make a first sketch harder to read. Copy the smallest relevant example, then use the linked guide to expand it deliberately.

Terminology

  • Board profile: GPIO wiring, storage bus, expected sensor, and verification metadata for a module.
  • Sensor capabilities: Supported format/frame-size masks and optional sensor operations for a detected camera sensor.
  • Driver configuration: Values applied when frame buffers and the camera HAL are initialized.
  • Sensor control: A setting applied through the active sensor driver, often without reallocating buffers.
  • Native access: Direct Espressif structures or methods outside NiusCam's portable validation layer.

Hardware observations are reported only when reproduced; unverified support is labeled explicitly.