DEV Community: ZhengZhiCong

Embedded Camera Module Selection Handbook — From Basics to Purchasing Reference

ZhengZhiCong — Mon, 29 Jun 2026 23:07:58 +0000

About This Handbook

This handbook is a revised edition of my own "Embedded Camera Module Technical Manual" that I previously compiled and shared online. The original covered eight mainstream sensors: OV2640, OV5640, OV7725, GC0309, OV7670, OV3660, GC2053, and GC4653. This revision expands coverage with 12 additional sensors (OV9281, OV5647, IMX219, IMX273, IMX296, IMX307, IMX335, IMX415, IMX477, IMX678, IMX708, IMX766), for a total of 20. The content was comprehensive, but when I sat down to use it as a purchasing reference, I felt uneasy — a single wrong voltage parameter can fry a board, and I didn't want to ship mistakes I couldn't vouch for.

So I did one thing: verified every key parameter against official datasheets. Sources include OmniVision's official product pages, GalaxyCore datasheets, SparkFun / DigiKey / Mouser datasheet mirrors, and Espressif's official esp32-camera driver source code.

The result: most parameters were correct, but there were several critical errors, especially around voltage, frame rates, and some marketing terminology. This handbook is the corrected version — every error-prone parameter is annotated with reliability status and evidence. Use it as a purchasing checklist with confidence.

Reliability annotation legend

✅ Verified: Parameter matches official datasheet exactly

⚠️ Note: Original had errors or was misleading; corrected with evidence

🔍 Unconfirmed: Official datasheet unclear, or varies by module manufacturer

Quick Selection Guide

Start with this table to find your use case, then read the details below.

Use Case	Top Pick	Resolution	Interface	Key Advantage	Price Tier
Education (Arduino/STM32)	OV7670	0.3MP	DVP	Richest ecosystem, most tutorials	Very low
Wi-Fi streaming (ESP32-CAM)	OV2640	2MP	DVP	Built-in JPEG compression	Low-mid
High-res photo + autofocus	OV5640	5MP	DVP/MIPI	Only entry-level with AF	Mid-high
Night vision / machine vision	OV7725	0.3MP	DVP	6.0µm pixels, low-light king	Mid
Ultra low cost (access/POS)	GC0309	0.3MP	DVP	Lowest price	Very low
3MP upgrade (ESP32)	OV3660	3MP	DVP	BSI tech, drop-in for OV2640	Low-mid
Security / surveillance	GC2053	2MP	DVP/MIPI	1/2.9" sensor + 2.8µm pixels	Mid
High-end security / AI vision	GC4653	4MP	MIPI only	4MP + BSI high sensitivity	Mid-high
Raspberry Pi / Jetson entry	IMX219	8MP	MIPI 2L	Pi V2 standard, most mature driver	Low
4K security / NVR	IMX415	8MP	MIPI 2/4L	4K STARVIS, rich module ecosystem	Mid-high
High-end 4K security (2024)	IMX678	8MP	MIPI 2/4/8L	STARVIS 2 + Clear HDR	High
1080P night security	IMX307	2MP	MIPI 2/4L	2.9µm + STARVIS, strong night vision	Mid
Industrial FA / global shutter	IMX273	1.58MP	MIPI 1L	Pregius global shutter, 226fps	High

⚠️ ESP32 users note: ESP32 series only supports DVP-interface sensors. GC4653 is MIPI-only and cannot be used with ESP32. OV3660 also only supports DVP (claims of MIPI support in the original document are wrong — see below).

DVP Interface Basics

DVP (Digital Video Port) transmits uncompressed raw image data via parallel data lines with a sync clock. Understanding DVP signals and timing is prerequisite for wiring and debugging all DVP modules.

Signal Definitions

Signal	Direction	Description	Typical Level
XCLK	Input	External master clock, typically 6–24 MHz ✅	3.3V
PCLK	Output	Pixel clock for synchronous data sampling ✅	3.3V
VSYNC	Output	Frame sync signal ✅	3.3V
HREF / HSYNC	Output	Line sync signal ✅	3.3V
D[7:0]	Output	8-bit parallel pixel data bus ✅	3.3V
SIOC / SCL	Input	SCCB / I²C clock ✅	3.3V
SIOD / SDA	Bidirectional	SCCB / I²C data ✅	3.3V
PWDN	Input	Power-down control	3.3V
RESET	Input	Hardware reset (active low)	3.3V

Timing

A complete frame is bounded by VSYNC. Within a frame, multiple HREF pulses occur, each corresponding to one line of valid pixel data. When both VSYNC and HREF are active, D[7:0] data latched on PCLK rising edge is valid pixel data.

The red scan line sweeps left to right. When VSYNC + HREF are both HIGH, each PCLK rising edge latches one pixel byte (D0, D1, D2…).

SCCB Control Interface

SCCB (Serial Camera Control Bus) is OmniVision's I²C-compatible 2-wire serial protocol. SCL clock frequency supports up to 400 kHz ✅ (OV2640 datasheet Table 9 confirms). If your MCU lacks internal pull-ups, add 4.7 kΩ pull-up resistors on SCL and SDA to 3.3V ✅.

⚠️ I²C addresses are sensor-specific, NOT uniform 0x30/0x60!

Many online sources casually claim "OV series address is 0x30/0x60" — this is wrong. Verified 7-bit slave addresses per sensor:

Sensor 7-bit Address Evidence

OV2640 0x30 Datasheet: 8-bit write 0x60 / read 0x61

OV5640 0x3C Datasheet: 8-bit write 0x78 / read 0x79

OV7725 0x21 Datasheet: 8-bit write 0x42 / read 0x43

OV7670 0x21 Linux kernel driver ov7670.c

GC series Vendor-defined Check specific datasheet

If SCCB configuration fails, verify I²C address first, not just pull-ups.

Sensor	7-bit Address	Evidence
OV2640	0x30	Datasheet: 8-bit write 0x60 / read 0x61
OV5640	0x3C	Datasheet: 8-bit write 0x78 / read 0x79
OV7725	0x21	Datasheet: 8-bit write 0x42 / read 0x43
OV7670	0x21	Linux kernel driver ov7670.c
GC series	Vendor-defined	Check specific datasheet

MIPI CSI-2 Interface Basics

When resolution and frame rate go up (1080P@30fps+), DVP's 8-bit parallel bus can't keep up — too many wires, limited speed, poor noise immunity. All Sony IMX sensors below use MIPI CSI-2. Here's the foundation.

DVP vs MIPI CSI-2

Feature	DVP	MIPI CSI-2
Data lines	8–10 parallel + sync signals	1–4 differential pairs (lanes)
Clock	Single-ended XCLK / PCLK	Differential clock lane
Bandwidth	≤ ~200 MB/s	Up to ~2.5 GB/s (4-lane)
Noise immunity	Poor, long cables cause artifacts	Good, differential rejects common-mode noise
Controller complexity	Low (straight to FIFO)	High (needs D-PHY + CSI-2 controller)
Typical controllers	ESP32, STM32, RP2040	Raspberry Pi, Jetson, Hi3516, RV1106
Typical sensors	OV2640, OV5640, OV7670	IMX219, IMX415, IMX678

Lane Count and Bandwidth

Lanes	Total Bandwidth	Suitable For
1-lane	~500 MB/s	1080P@30fps RAW8
2-lane	~1 GB/s	1080P@60fps or 4K@15fps
4-lane	~2 GB/s	4K@30fps+

Purchasing note: More lanes isn't always better — your controller's MIPI receiver must support the lane count. For example, RV1106 supports 2-lane/4-lane MIPI input; connecting a 1-lane IMX273 may not work. Check controller specs before buying.

ESP32 users note: ESP32 (including ESP32-S3) has no MIPI CSI-2 receiver. None of the Sony IMX sensors below work with ESP32. You need a MIPI-capable controller like Raspberry Pi, Jetson, RV1106, Hi3516, etc.

Sensor Technology Principles

Shutter Types: Rolling vs Global

Most sensors in this handbook use rolling shutter — exposing rows sequentially with a time gap between rows. Fast-moving objects appear skewed/warped (jello effect). Only IMX273, OV9281, and IMX296 use global shutter — the entire frame is exposed simultaneously, zero motion distortion.

A blue ball moves left to right. Rolling shutter exposes row-by-row, capturing the ball at different positions per row → diagonal skew. Global shutter exposes all rows simultaneously → clean bar.

Backside Illumination (BSI) vs Frontside Illumination (FSI)

Traditional CMOS sensors (FSI) have metal wiring above the photodiode, blocking some light. BSI (Backside Illumination) flips the sensor so light enters from the back, reaching the photodiode directly — 30%–60% more light. STARVIS, Exmor R, and OmniBSI all use BSI technology.

Yellow dots are photons. FSI's wiring blocks ~50% of light. BSI flips the structure so all photons reach the sensor.

HDR Multi-Exposure Fusion

In backlit scenes, short exposure captures highlights (sky) but shadows are black; long exposure captures shadows but highlights are blown. HDR merges multiple exposures into one image, preserving both highlight and shadow detail. IMX307/IMX335/IMX678 all support hardware-level HDR.

Short exposure preserves highlights, long exposure preserves shadows — merged HDR significantly expands dynamic range. Frames appear sequentially to show the fusion process.

Quad Bayer Pixel Binning

High-resolution sensors (e.g., IMX766 50MP) have tiny pixels (1.0µm) with insufficient light per pixel. Quad Bayer groups 4 adjacent same-color pixels, reading them as 1 larger pixel — 4× area, effective pixel size doubles (1.0µm → 2.0µm), dramatically improving low-light performance. Full resolution by day, auto-binned by night.

4 pixels of 1.0µm merge into 1 pixel of 2.0µm. 4× area = 4× light = significantly better SNR.

OV2640 Module

OmniVision 1/4-inch, 2MP CMOS sensor with built-in JPEG compression engine. The standard choice for ESP32-CAM.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV2640	✅
Optical format	1/4 inch	✅
Effective pixels	2MP (1600 × 1200)	✅
Pixel size	2.2 µm × 2.2 µm	✅
Shutter	Electronic rolling	✅
Interface	DVP 8-bit parallel + SCCB	✅
Output formats	YUV422, YUV420, RGB565, RGB555, RAW RGB, JPEG	✅
Max frame rate	UXGA@15fps, SVGA@30fps, CIF@60fps	✅
Master clock XCLK	6 – 24 MHz (typical 24 MHz)	✅
Operating voltage	Analog 2.5–3.0V, I/O 1.7–3.3V, Core 1.2/1.3V	✅
Power	~125 mW (15fps UXGA YUV), ~140 mW (JPEG mode)	✅

Source: Official OmniVision OV2640 datasheet (uctronics.com/download/OV2640_DS.pdf)

Resolution & Frame Rate

Resolution	Size	Typical fps
UXGA	1600 × 1200	15 fps
SXGA	1280 × 1024	15 fps
SVGA	800 × 600	30 fps
VGA	640 × 480	30 fps
QVGA	320 × 240	60 fps

Typical Pinout (24-PIN FPC)

✅ Verified: OV2640 modules do use 24-pin 0.5mm pitch FPC (confirmed by OV2640FSL datasheet, Arducam module spec). However, pin order may vary by module manufacturer — always check your specific board's datasheet.

Pin	Function	Pin	Function
1	GND	13	D3
2	VCC (3.3V)	14	D4
3	GND	15	D5
4	PWDN	16	D6
5	RESET	17	D7
6	XCLK	18	NC
7	VSYNC	19	SIOC (SCL)
8	HREF	20	SIOD (SDA)
9	PCLK	21	NC
10	D0	22	NC
11	D1	23	NC
12	D2	24	NC

Purchasing tip: OV2640's built-in JPEG compression outputs compressed streams directly, significantly reducing MCU RAM and bus bandwidth requirements. Best price/performance for ESP32-CAM.

OV5640 Module

OmniVision 1/4-inch, 5MP CMOS sensor with integrated autofocus (AF) voice coil motor driver. The image quality ceiling for entry-level.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV5640	✅
Optical format	1/4 inch	✅
Effective pixels	5MP (2592 × 1944)	✅
Pixel size	1.4 µm × 1.4 µm	✅
Shutter	Electronic rolling	✅
Interface	DVP 8/10-bit OR MIPI CSI-2 (2-lane)	✅
Output formats	RAW RGB, RGB565/555/444, YCbCr422, JPEG	✅
Max frame rate	QSXGA@15fps, 1080P@30fps, 720P@60fps, VGA@90fps	✅
Master clock XCLK	6 – 27 MHz (typical 24 MHz)	✅
Autofocus	Integrated VCM driver, contrast-detect AF	✅
Features	OmniBSI, HDR, AE/AG/AWB, 2D NR, lens correction, anti-shake	✅
Current	~140 mA (active), 20 µA (standby)	✅

Source: OV5640 datasheet v2.03 (cdn.sparkfun.com), OV5640 Product Brief (media.digikey.com)

Interface note: OV5640 supports both DVP and MIPI CSI-2. Cheap modules typically use DVP 8-bit parallel. MIPI versions are usually for phone/tablet designs. For AF versions, verify AF_VCC supply — the VCM motor needs separate power.

OV7725 Module

OmniVision high-performance 1/4-inch VGA sensor using OmniPixel² technology, focused on high sensitivity, low noise, and low-light performance. At 6.0 µm pixel size, it's the strongest low-light performer in the 0.3MP class.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV7725	✅
Optical format	1/4 inch	✅
Effective pixels	0.3MP (640 × 480)	✅
Pixel size	6.0 µm × 6.0 µm	✅
Interface	DVP 8/10-bit parallel + SCCB	✅
Output formats	RAW RGB, RGB565/555/444, YCbCr422	✅
Max frame rate	VGA@60fps, QVGA@120fps	✅
Operating temp	-20°C to +70°C	✅
Sensitivity	3800 mV/Lux-sec (extremely high)	✅
Dynamic range	60 dB	✅
Features	OmniPixel², high sensitivity low-light, AE/AG/AWB, edge enhancement, noise suppression	✅

Source: OV7725 official product page (ovt.com/products/ov7725), OV7725 datasheet

⚠️ EOL notice: OV7725 is marked End-of-Life on OmniVision's website. For new production designs, evaluate alternatives. But surplus/secondhand stock remains plentiful.

Why is 6.0µm so big? Both OV7670 and OV7725 are 0.3MP, but OV7670 pixels are only 3.6µm while OV7725 reaches 6.0µm — nearly 3x the pixel area, meaning 3x the light gathering. This is why it crushes same-resolution competitors in low light. For night vision, license plate recognition, or industrial inspection, this is the one.

GC0309-8225N V2 Module

Based on GalaxyCore GC0309, a 0.3MP fixed-focus module with DVP interface, focused on ultra-high cost-effectiveness.

Core Specs

Parameter	Spec	Reliability
Sensor	GalaxyCore GC0309	✅
Optical format	1/9 inch	✅
Effective pixels	0.3MP (640 × 480, actual 648×488)	✅
Pixel size	2.5 µm × 2.5 µm	✅
Pixel structure	4-transistor (4T), low noise	✅
Shutter	Electronic rolling	✅
Interface	DVP 8-bit parallel	✅
Output formats	YCbCr422, RGB565, RAW Bayer	✅
Max frame rate	VGA@30fps (24MHz clock)	✅
Operating voltage	2.8V typical (2.7–3.3V range)	⚠️ see below
Lens	Fixed focus, typical 62° FOV	🔍 module-vendor defined
Features	On-chip 10-bit ADC, embedded ISP, AE, AWB	✅

Source: GC0309 official datasheet V1.0 (2009-12-28, GalaxyCore Inc.)

⚠️ Voltage correction: The original document's "3.3V single supply" is inaccurate. The official datasheet explicitly states "Single power supply requirement (2.8V)", typical 2.8V, range 2.7–3.3V. Recommended supply is 2.8V LDO — 3.3V is within range but not the optimal operating point.

Note: GC0309-8225N V2 is a complete module model customized by module vendors based on the GC0309 sensor. Pin definitions, lens parameters, and FPC interfaces may vary between vendors. Always refer to your specific module's datasheet.

OV7670 Module

OmniVision's classic 1/6-inch VGA sensor — the most historically significant and ecosystem-mature sensor in embedded vision. The de facto standard for Arduino, STM32, and FPGA education.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV7670	✅
Optical format	1/6 inch	✅
Effective pixels	0.3MP (640 × 480)	✅
Pixel size	3.6 µm × 3.6 µm	✅
Shutter	Electronic rolling	✅
Interface	DVP 8-bit parallel + SCCB	✅
Output formats	YUV422, RGB565, RGB555, RAW RGB, Processed Bayer	✅
Max frame rate	VGA@30fps, QVGA@60fps, CIF@60fps	✅
Master clock XCLK	10 – 24 MHz (typical 24 MHz)	✅
Power	~60 mW (15fps VGA YUV), standby <20 µA	✅

Source: OV7670 official datasheet (w2.electrodragon.com/Chip-dat/OmniVision-dat/OV7670-dat/OV7670-ds.pdf)

⚠️ Voltage correction (important): The original's "2.5–3.0V single voltage" is simplified and misleading. OV7670 actually requires three separate supply domains:

Supply Domain Voltage Range Notes

DVDD (digital core) 1.8V Requires dedicated LDO

AVDD (analog) 2.45–3.0V

DOVDD (I/O) 1.7–3.0V Can connect to 3.3V

Purchasing note: Cheap non-FIFO modules typically only expose DOVDD — DVDD and AVDD are stepped down via on-board LDOs. But bare minimum boards may require external regulation. Non-FIFO versions are extremely demanding on MCU real-time performance; with STM32, pair with AL422B FIFO buffer chip.

Supply Domain	Voltage Range	Notes
DVDD (digital core)	1.8V	Requires dedicated LDO
AVDD (analog)	2.45–3.0V
DOVDD (I/O)	1.7–3.0V	Can connect to 3.3V

OV3660 Module

OmniVision 3MP (2048×1536) sensor using OmniBSI backside-illumination technology. Natively supported by ESP32's esp32-camera library.

⚠️ Multiple corrections in this section — read carefully. My original version had errors in interface, frame rate, voltage, and current — all corrected against the official datasheet below.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV3660	✅
Optical format	1/5 inch	✅
Effective pixels	3MP (2048 × 1536)	✅
Pixel size	1.4 µm × 1.4 µm (OmniBSI)	✅
Shutter	Electronic rolling	✅
Interface	DVP 8-bit parallel ONLY	⚠️ see below
Output formats	RAW RGB, RGB565/555/444, YCbCr422, JPEG compression	✅
Max frame rate	QXGA@15fps, 1080P@20fps, 720P@45fps, VGA@60fps	⚠️ see below
Operating voltage	Core 1.5V, I/O 1.8V/2.8V, Analog 2.6–3.0V	⚠️ see below
Current	~98 mA (active), 20 µA (standby)	⚠️ see below
Sensitivity	670 mV/Lux-sec	✅
Dynamic range	70 dB @ 8x gain	✅
Operating temp	-20°C to 70°C	✅
XCLK	6 – 27 MHz	✅

Source: OV3660 official datasheet (download.kamami.pl/p1196945-OV3660%20Datasheet.pdf), ESP32 Camera Driver (github.com/espressif/esp32-camera)

⚠️ Correction 1 — No MIPI: The original claimed OV3660 supports "DVP 8-bit OR MIPI CSI-2 (1-lane)" — this is wrong. The official datasheet only mentions Digital Video Parallel Port with no MIPI interface description. ESP32 can use it precisely because it's DVP.

⚠️ Correction 2 — Frame rate: Original claimed 1080P@30fps, 720P@60fps; actual is 1080P@20fps, 720P@45fps. Original overstated by ~33%.

⚠️ Correction 3 — Voltage: Original "I/O 1.8–3.3V, core 1.2V, analog 2.8V" is wrong. Actual: core 1.5V, I/O 1.8V or 2.8V, analog 2.6–3.0V.

⚠️ Correction 4 — Current: Original "~130mA" is too high; datasheet specifies 98mA active.

Purchasing tip: OV3660 offers 50% higher resolution than OV2640 (3MP vs 2MP) with better low-light performance via BSI. If your project already uses OV2640 and you want to upgrade image quality while staying on ESP32, OV3660 is the best drop-in replacement (both DVP, directly supported by esp32-camera).

GC2053 Module

GalaxyCore 2MP (1920×1080) sensor with 1/2.9-inch large sensor and 2.8µm large pixels, supporting both MIPI and DVP interfaces. Standout low-light performance in its price tier.

Core Specs

Parameter	Spec	Reliability
Sensor	GalaxyCore GC2053	✅
Optical format	1/2.9 inch	✅
Effective pixels	2MP (1920 × 1080)	✅
Pixel size	2.8 µm × 2.8 µm	✅
Shutter	Electronic rolling	✅
Interface	MIPI CSI-2 (2-lane) or DVP	✅
Output formats	RAW Bayer 10-bit / 8-bit	✅
Max frame rate	1080P@30fps, 720P@60fps	✅
Operating voltage	AVDD 2.8V, DVDD 1.2V, IOVDD 1.8V	✅
Current	~57 mA total (analog 17.3 + digital 37.4 + I/O 2.5)	⚠️ see below
ADC	10-bit	✅

Source: GC2053 datasheet V1.1 (2018-11-29, GalaxyCore / CK Vision)

⚠️ Current correction: Original claimed "~95 mA"; datasheet measures approximately 57mA total (analog 17.3mA + digital 37.4mA + I/O 2.5mA). Actual power consumption is lower than original — thermal and power design can be more relaxed. MIPI 2-lane bandwidth of 1.5Gbps/lane 🔍 pending final datasheet confirmation.

Why choose GC2053: The 1/2.9-inch sensor is larger than both OV2640 (1/4") and OV5640 (1/4"), and 2.8µm pixels are also bigger. Bigger sensor + bigger pixels = more light per pixel = better low-light performance. It has a clear advantage over same-price OV solutions for security surveillance.

GC4653 Module

GalaxyCore's high-performance 4MP sensor using BSI backside-illumination technology for enhanced low-light sensitivity. A high-end choice for security cameras and intelligent vision applications.

⚠️ "STARVIS" terminology correction. The original claimed GC4653 uses "STARVIS architecture technology" — this is incorrect. STARVIS is Sony's registered trademark and exclusive technology; GalaxyCore does not use STARVIS. GC4653 actually uses in-house BSI (backside-illuminated) pixel technology for high sensitivity.

Core Specs

Parameter	Spec	Reliability
Sensor	GalaxyCore GC4653	✅
Optical format	1/3 inch	✅
Effective pixels	4MP (2560 × 1440)	✅
Pixel size	2.0 µm × 2.0 µm (BSI)	✅
Shutter	Electronic rolling	✅
Interface	MIPI CSI-2 ONLY (2-lane, RAW12/RAW10)	✅
Output formats	RAW Bayer 12-bit / 10-bit	✅
Max frame rate	4MP@30fps, 1080P@60fps	✅
Operating voltage	AVDD 2.8V, DVDD 1.2V, I/O 1.8V	✅
Current	~120 mA	🔍 pending datasheet
Features	BSI high-sensitivity low-light, HDR, PDAF phase AF, 2D/3D noise reduction	⚠️ see above

Source: GC4653 datasheet (Camemaker), Sipeed Wiki, Sony Semiconductor official site (STARVIS trademark confirmation)

⚠️ ESP32 incompatible: GC4653 is MIPI-only, incompatible with traditional DVP parallel interface. ESP32 series has no MIPI CSI-2 receiver capability and cannot use this sensor. Requires a controller with MIPI CSI-2, such as HiSilicon Hi3516, Ingenic T31, Rockchip RV1106, etc.

Purchasing tip: Confirm your controller has MIPI CSI-2 before choosing GC4653. If you're doing an ESP32 project, don't buy this sensor — you won't be able to light it up.

OV9281 Module

OmniVision 1/4-inch 1MP global shutter sensor using OmniPixel®3-GS technology. Like the IMX273, it's a global shutter sensor, but much cheaper with DVP+MIPI dual interface — the most affordable global shutter option for makers.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV9281	✅
Optical format	1/4 inch	✅
Effective pixels	1MP (1280 × 800)	✅
Pixel size	3.0 µm × 3.0 µm	✅
Shutter type	Global Shutter (OmniPixel®3-GS)	✅
Interface	MIPI CSI-2 (2-lane) + DVP	✅
Output format	RAW8 / RAW10	✅
Max frame rate	120 fps (1280×800), 180fps (VGA)	✅
Operating voltage	AVDD 2.8V, DVDD 1.2V, IOVDD 1.8V	✅
Power	156 mW (active), 150 µA (standby)	✅
S/N ratio	38 dB	✅
Dynamic range	68 dB	✅
Production status	In production	✅
Typical applications	Machine vision, drones, barcode scanning, AR/VR, 3D depth	✅

Source: OmniVision OV9281 Product Brief v1.4 (ovt.com/wp-content/uploads/2024/05/OV9281-PB-v1.4-WEB.pdf)

⚠️ ESP32 compatibility: OV9281 is NOT in the esp32-camera library (classic ESP32/S2/S3). ESP32-P4 has experimental support but unstable (esp-idf #17795). For global shutter on ESP32, there's currently no good option; use Raspberry Pi + Arducam OV9281 module instead.

Why OV9281 over IMX273: Both are global shutter, but OV9281 is much cheaper ($15-25 vs $50+) and supports both DVP and MIPI. Downsides: lower resolution (1MP vs 1.58MP) and monochrome only (no color version).

OV5647 Module

OmniVision 1/4-inch 5MP CMOS sensor with OmniBSI technology. The original Raspberry Pi Camera Module V1 (2013) sensor.

Core Specs

Parameter	Spec	Reliability
Sensor	OmniVision OV5647	✅
Optical format	1/4 inch	✅
Effective pixels	5MP (2592 × 1944)	✅
Pixel size	1.4 µm × 1.4 µm	✅
Shutter type	Rolling shutter	✅
Technology	OmniBSI backside illumination	✅
Interface	MIPI CSI-2 (2-lane) + DVP	✅
Output format	RAW8 / RAW10	✅
Max frame rate	5MP@15fps, 1080P@30fps, 720P@60fps, VGA@90fps	✅
Operating voltage	Analog 2.6–3.0V (typical 2.8V), Core 1.5V, I/O 1.7–3.0V	✅
Production status	❌ End-of-Life (EOL)	⚠️ see below
Typical applications	Raspberry Pi Camera V1, phones, notebooks	✅

Source: OmniVision OV5647 datasheet (v-visiontech.com/web/userfiles/download/OV5647DS.pdf), Raspberry Pi official documentation

⚠️ Discontinued (EOL): OV5647 is on OmniVision's discontinued product list. Surplus stock still available ($8-15), but not recommended for new designs.

Selection comparison: OV5647 vs OV5640 — both 5MP. OV5647 is the Pi V1 sensor; OV5640 is the ESP32 ecosystem 5MP option (with AF). Pins and drivers are incompatible. For Pi projects on a budget, OV5647 surplus still works; for ESP32, use OV5640.

NOT in esp32-camera support list. ESP32 users should use OV2640 or OV5640.

IMX219 Module

Sony 1/4-inch 8MP CMOS sensor with Exmor R backside-illumination technology. The standard sensor for Raspberry Pi Camera Module V2, and the most ubiquitous MIPI camera in the Raspberry Pi ecosystem.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX219	✅
Optical format	1/4 inch	✅
Effective pixels	8MP (3280 × 2464)	✅
Pixel size	1.12 µm × 1.12 µm	✅
Technology	Exmor R BSI (NOT STARVIS)	⚠️ see below
Interface	MIPI CSI-2 (2-lane)	✅
Output format	RAW10	✅
Max frame rate	1080P@30fps, 720P@60fps, VGA@90fps	✅
Operating voltage	AVDD 2.8V, DVDD 1.2V, IOVDD 1.8V	✅
Power	~38 mA @2.8V + ~160 mA @1.2V (≈ 0.26 W)	✅
Production status	In production (at least until Jan 2028)	✅

Source: Sony IMX219 datasheet (dlscorp.com), Raspberry Pi official documentation

⚠️ Exmor R is NOT STARVIS: Some online articles classify IMX219 as STARVIS — this is wrong. IMX219 uses Exmor R (BSI). STARVIS is Sony's later security-focused technology line with higher sensitivity and dynamic range.

Purchasing tip: The IMX219 module (Raspberry Pi Camera V2) is the lowest-cost entry to MIPI. Pi 4B/5 CSI connector works directly, driver is in mainline kernel, plug-and-play.

IMX273 Module

Sony Pregius series global shutter sensor, 1/2.9-inch, 1.58MP. Designed for industrial FA cameras and ITS (Intelligent Traffic Systems), 226fps at full resolution — a high-performance choice for high-speed machine vision.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX273	✅
Optical format	1/2.9 inch	✅
Effective pixels	1.58MP (1456 × 1088)	✅
Pixel size	3.45 µm × 3.45 µm	✅
Technology	Pregius Global Shutter (NOT STARVIS)	⚠️ see below
Interface	MIPI CSI-2 (1-lane) OR Sub LVDS (8-ch)	✅
Output format	RAW10 / RAW12	✅
Max frame rate	226 fps (full resolution, 10-bit)	✅
Operating voltage	3.3V / 1.8V / 1.2V	✅
Typical applications	Industrial FA cameras, ITS, barcode scanning, defect inspection	✅

Source: Sony IMX273 official Flyer (sony-semicon.com/files/62/flyer_industry/IMX273_287_296_297_Flyer.pdf)

⚠️ Global vs Rolling Shutter: Every other sensor in this handbook uses rolling shutter, which causes jello effect on fast-moving objects. IMX273 has a global shutter — the entire image is exposed simultaneously, zero jello effect on high-speed motion. This is the core reason to choose it for industrial vision.

Note: IMX273 comes in two variants — MIPI 1-lane and Sub LVDS 8-ch. Confirm which interface you need before buying.

IMX307 Module

Sony STARVIS 2MP security sensor, 1/2.8-inch, 2.9µm large pixels. HDR support, a mainstream choice for 1080P security cameras, commonly paired with HiSilicon Hi3516 series SoCs.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX307	✅
Optical format	1/2.8 inch	✅
Effective pixels	2.07MP (1920 × 1080)	✅
Pixel size	2.9 µm × 2.9 µm	✅
Technology	STARVIS (original)	✅
Interface	MIPI CSI-2 (2/4-lane) + LVDS	✅
Output format	RAW10 / RAW12	✅
Max frame rate	60 fps (1080P)	✅
HDR	Multi-exposure HDR + Digital overlap HDR	✅
Operating voltage	AVDD 2.9V, DVDD 1.2V, IOVDD 1.8V	✅
Typical applications	Security surveillance, FA cameras	✅

Source: Sony IMX307 official Flyer (sony-semicon.com/files/62/flyer_security/IMX307LQD_LQR_Flyer.pdf)

Highlight: 2.9µm large pixels + STARVIS = excellent night vision. Paired with Hi3516C V300 is the classic security combo.

IMX335 Module

Sony STARVIS 5MP security sensor, 1/2.8-inch. Steps up from IMX307's 2MP to 5MP while maintaining good day/night image quality. Commonly paired with Hi3516 / RV1106.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX335	✅
Optical format	1/2.8 inch	✅
Effective pixels	5.04MP (2592 × 1944)	✅
Pixel size	2.0 µm × 2.0 µm	✅
Technology	STARVIS (original)	✅
Interface	MIPI CSI-2 (2/4-lane)	✅
Output format	RAW10 / RAW12	✅
Max frame rate	60 fps (full resolution, 10-bit)	✅
HDR	Multi-exposure HDR + Digital overlap HDR	✅
Operating voltage	AVDD 2.9V, DVDD 1.2V, IOVDD 1.8V	✅
Common SoC pairing	Hi3516 series, RV1106	✅

Source: Sony IMX335 official Flyer (sony-semicon.com/files/62/flyer_security/IMX335LQN_Flyer.pdf)

Selection comparison: IMX335 vs IMX307 — same 1/2.8" sensor. IMX307 is 2MP/2.9µm (better low light), IMX335 is 5MP/2.0µm (more detail). Choose IMX335 if you need to see far details, IMX307 for night surveillance.

IMX415 Module

Sony STARVIS 4K (8MP) security sensor, 1/2.8-inch. The workhorse sensor for 4K security cameras, with the most mature module ecosystem — Jetson / Raspberry Pi / RV1106 all have ready drivers.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX415	✅
Optical format	1/2.8 inch	✅
Effective pixels	8.29MP (3840 × 2160, 4K UHD)	✅
Pixel size	1.45 µm × 1.45 µm	✅
Technology	STARVIS (original)	✅
Interface	MIPI CSI-2 (2/4-lane)	✅
Output format	RAW8 / RAW10	✅
Max frame rate	4K up to 90fps (typical 30–60fps)	✅
HDR	Multi-exposure HDR	✅
Operating voltage	AVDD 2.9V, DVDD 1.1V, IOVDD 1.8V	✅
Announced	June 2019	✅
Typical applications	4K security, NVR, industrial cameras	✅

Source: Sony IMX415 official Flyer (sony-semicon.com/files/62/pdf/p-12_IMX415-AAQR_AAMR_Flyer.pdf)

Purchasing tip: IMX415 has the best DIY/embedded module ecosystem of all Sony IMX sensors. LuckFox, Radxa, e-con Systems all offer ready-made modules with drivers for Jetson, Raspberry Pi, RV1106. The top pick for 4K MIPI projects.

IMX678 Module

Sony STARVIS 2 4K (8MP) security sensor, 1/1.8-inch large sensor. A 2024 new release that comprehensively upgrades the IMX415 — bigger sensor, newer STARVIS 2 technology, faster frame rate, stronger HDR.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX678	✅
Optical format	1/1.8 inch (much larger than IMX415's 1/2.8")	✅
Effective pixels	8.29MP (3840 × 2160, 4K UHD)	✅
Pixel size	2.0 µm × 2.0 µm	✅
Technology	STARVIS 2 (next-gen)	✅
Interface	MIPI CSI-2 (2/4/8-lane, 4-lane×2ch)	✅
Output format	RAW10 / RAW12	✅
Max frame rate	72 fps (4K, 10-bit) / 60fps (12-bit)	✅
HDR	Digital overlap HDR + Clear HDR	✅
Operating voltage	AVDD 3.3V, DVDD 1.1V, IOVDD 1.8V	⚠️ see below
Announced	2024	✅
Common SoC pairing	Hi3519DV500	✅

Source: Sony IMX678 official Flyer (sony-semicon.com/files/62/flyer_security/IMX678-AAQR_AAQR1_Flyer.pdf, © 2024)

⚠️ Power note: IMX678's AVDD is 3.3V, different from IMX335/IMX307/IMX415's 2.9V. Change the LDO output when migrating from other IMX designs.

IMX678 vs IMX415: Both are 4K 8MP, but IMX678 has a bigger sensor (1/1.8" vs 1/2.8"), bigger pixels (2.0µm vs 1.45µm), newer tech (STARVIS 2), and stronger HDR (Clear HDR). The trade-off is more complex power/lane requirements and higher module cost as a 2024 new release.

IMX766 Module

Sony 50MP smartphone sensor, 1/1.56-inch large sensor, Quad Bayer array. Used in OPPO Find X3 Pro, Reno7 Pro and other flagship phones.

⚠️ NOT recommended for DIY / embedded projects. The following is for reference only.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX766	✅
Optical format	1/1.56 inch	✅
Effective pixels	50MP (8192 × 6144)	✅
Pixel size	1.0 µm (4-in-1 binning → 2.0 µm)	✅
Pixel array	Quad Bayer	✅
Interface	MIPI CSI-2 (4-lane)	✅
Output format	RAW10 / RAW8	🔍
Max frame rate	Full res ~24fps; binned 30fps; 1080P 60–120fps	🔍
Operating voltage	AVDD 2.8V, DVDD 1.1V, IOVDD 1.8V	🔍
Phone implementations	OPPO Find X3 Pro, OnePlus, Realme	✅

Source: OPPO official specs, IADIY module page, DxOMark. ⚠️ Sony has not published an official IMX766 datasheet — some parameters are from phone manufacturers and module vendors.

⚠️ Why not recommended for DIY: No official datasheet (register config and power sequencing require reverse engineering), needs custom driver (no mainline Linux driver), non-standard FPC, 50MP Quad Bayer needs powerful ISP, many modules include OIS motors needing extra drivers. For high-res MIPI, choose IMX415 or IMX477 (Raspberry Pi HQ Camera) instead.

Sony IMX Series Key Parameters Comparison

All 15 sensors in one table would exceed mobile screen width. OV/GC comparison table above; Sony IMX series below.

Parameter	IMX219	IMX273	IMX307	IMX335	IMX415	IMX678	IMX766
Technology	Exmor R	Pregius GS	STARVIS	STARVIS	STARVIS	STARVIS 2	Quad Bayer
Resolution	8MP	1.58MP	2MP	5MP	8MP (4K)	8MP (4K)	50MP
Optical format	1/4"	1/2.9"	1/2.8"	1/2.8"	1/2.8"	1/1.8"	1/1.56"
Pixel size	1.12 µm	3.45 µm	2.9 µm	2.0 µm	1.45 µm	2.0 µm	1.0 µm
Interface	MIPI 2L	MIPI 1L/LVDS	MIPI 2/4L	MIPI 2/4L	MIPI 2/4L	MIPI 2/4/8L	MIPI 4L
Max fps	1080P@30fps	226fps	1080P@60fps	5MP@60fps	4K@90fps	4K@72fps	50MP@24fps
HDR	No	No	✅	✅	✅	✅ Clear	No
Global shutter	No	✅	No	No	No	No	No
AVDD	2.8V	3.3V	2.9V	2.9V	2.9V	3.3V	2.8V
Best use case	Raspberry Pi V2	Industrial FA	Security	Security	4K Security	High-end 4K	⚠️ Phone
DIY recommended	✅	⚠️ Industrial	✅	✅	✅ Top pick	⚠️ Pricey	❌ Not recommended

IMX477 Module

Sony 12.3MP sensor, 1/2.3-inch, with interchangeable C/CS-mount lens. The standard sensor for Raspberry Pi HQ Camera — ideal for projects needing high-quality imaging and interchangeable lenses: microscopy, astronomy, industrial inspection.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX477	✅
Optical format	1/2.3 inch	✅
Effective pixels	12.3MP (4056 × 3040)	✅
Pixel size	1.55 µm × 1.55 µm	✅
Technology	BSI stacked CMOS	✅
Interface	MIPI CSI-2 (2/4-lane)	✅
Output format	RAW12 / RAW10 / RAW8	✅
Max frame rate	Full res@60fps (10-bit), 4K@60fps, 1080P@240fps	✅
HDR	DOL-HDR (Digital Overlap HDR)	✅
Lens mount	C-mount / CS-mount (interchangeable)	✅
Production status	In production (at least until Jan 2030)	✅
Announced	April 2020	✅
Typical applications	Raspberry Pi HQ Camera, microscopy/astronomy, industrial	✅

Source: Sony IMX477 Flyer, Raspberry Pi HQ Camera product page

Purchasing tip: IMX477's biggest advantage is interchangeable lenses — C-mount and CS-mount cover wide-angle to telephoto to macro. Best image quality in the Pi ecosystem. $50-70.

IMX708 Module

Sony 12MP Quad Bayer sensor, 1/2.3-inch, with PDAF phase-detection autofocus and HDR. The standard sensor for Raspberry Pi Camera Module 3 — the first Pi camera with hardware autofocus.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX708	✅
Optical format	1/2.3 inch	✅
Effective pixels	12MP (4608 × 2592)	✅
Pixel size	1.4 µm × 1.4 µm	✅
Technology	BSI stacked CMOS, Quad Bayer	✅
Interface	MIPI CSI-2	✅
Output format	RAW10	✅
Max frame rate	1080P@50fps, 720P@100fps, 480P@120fps	✅
Autofocus	PDAF phase-detection autofocus	✅
HDR	Yes (up to 3MP output)	✅
Production status	In production (at least until Jan 2030)	✅
Announced	January 2023	✅
Typical applications	Raspberry Pi Camera Module 3 (standard/wide/telephoto)	✅

Source: Raspberry Pi Camera Module 3 product page and product brief

Highlight: IMX708 brings hardware autofocus (PDAF) to Raspberry Pi for the first time. Available in standard, wide, and telephoto versions. $25-30 — best price/performance for Pi MIPI cameras.

IMX296 Module

Sony Pregius global shutter sensor, 1/2.9-inch, 1.58MP. The standard sensor for Raspberry Pi Global Shutter Camera. Like the IMX273, it's a Pregius global shutter sensor, but with official Pi ecosystem module and driver support.

Core Specs

Parameter	Spec	Reliability
Sensor	Sony IMX296	✅
Optical format	1/2.9 inch	✅
Effective pixels	1.58MP (1456 × 1088)	✅
Pixel size	3.45 µm × 3.45 µm	✅
Technology	Pregius Global Shutter	✅
Interface	MIPI CSI-2 (1-lane)	✅
Output format	RAW10	✅
Max frame rate	60.3 fps (full resolution, 10-bit)	✅
Operating voltage	AVDD 3.3V, DVDD 1.2V, IOVDD 1.8V	✅
Lens mount	C-mount / CS-mount (interchangeable)	✅
Production status	In production (at least until Jan 2032)	✅
Announced	2023	✅
Typical applications	Raspberry Pi Global Shutter Camera, high-speed capture, industrial	✅

Source: Sony IMX296 Flyer, Raspberry Pi Global Shutter Camera product page

IMX296 vs IMX273: Both are Pregius global shutter, 3.45µm pixels. IMX296 is the official Pi Global Shutter Camera sensor with full driver/docs; IMX273 is more industrial FA focused. For Pi projects choose IMX296, for industrial FA choose IMX273.

Module Comparison Summary

Key Parameters Comparison

Table corrected per official datasheets. Bolded items had errors in the original or need special attention.

Parameter	OV2640	OV5640	OV7725	GC0309	OV7670	OV3660	GC2053	GC4653
Vendor	OmniVision	OmniVision	OmniVision	GalaxyCore	OmniVision	OmniVision	GalaxyCore	GalaxyCore
Resolution	2MP	5MP	0.3MP	0.3MP	0.3MP	3MP	2MP	4MP
Max size	1600×1200	2592×1944	640×480	640×480	640×480	2048×1536	1920×1080	2560×1440
Optical format	1/4"	1/4"	1/4"	1/9"	1/6"	1/5"	1/2.9"	1/3"
Pixel size	2.2 µm	1.4 µm	6.0 µm	2.5 µm	3.6 µm	1.4 µm	2.8 µm	2.0 µm
Interface	DVP	DVP/MIPI	DVP	DVP	DVP	DVP only	DVP/MIPI	MIPI only
Max fps	UXGA@15fps	QSXGA@15fps	VGA@60fps	VGA@30fps	VGA@30fps	1080P@20fps	1080P@30fps	4MP@30fps
Output formats	YUV/RGB/RAW/JPEG	YUV/RGB/RAW/JPEG	YUV/RGB/RAW	YUV/RGB/RAW	YUV/RGB/RAW	YUV/RGB/RAW/JPEG	RAW Bayer	RAW Bayer
Autofocus	No	Yes (VCM)	No	No	No	No	Optional	PDAF
Low-light	Average	Average	Excellent	Average	Average	Good	Excellent	Excellent
Voltage	1.7–3.3V (I/O)	1.7–3.3V (I/O)	3.3V	2.8V typical	1.8V/2.45-3V/1.7-3V	1.5V core multi-rail	1.8V (I/O)	1.8V (I/O)
Typical power	~125 mW	~140 mA	~80 mA	~60 mA	~60 mW	~98 mA	~57 mA	~120 mA
I²C address	0x30	0x3C	0x21	Vendor	0x21	See DS	Vendor	Vendor
Price tier	Low-mid	Mid-high	Mid	Very low	Low	Low-mid	Mid	Mid-high
ESP32 compatible	✅	✅	✅	✅	⚠️ needs FIFO	✅	⚠️ DVP mode only	❌

Selection Recommendations

Education (Arduino/STM32): OV7670 — Richest ecosystem, most tutorials. Note three-rail power.
Wi-Fi streaming (ESP32-CAM): OV2640 — Built-in JPEG, balanced power/quality, de facto standard.
High-res photo (ESP32/STM32): OV5640 — 5MP + autofocus, best entry-level quality. Power VCM on AF versions.
Night vision / machine vision (low-light): OV7725 — 6.0µm pixels, low-light king. ⚠️ EOL, surplus stock.
Ultra low cost (access/POS): GC0309-8225N — Lowest price, meets basic needs. Power at 2.8V.
3MP upgrade (ESP32): OV3660 — BSI, drop-in for OV2640. Note lower frame rate than OV2640.
Security surveillance (indoor/outdoor): GC2053 — Large sensor/pixels, MIPI high-speed, low power.
High-end security / AI vision: GC4653 — 4MP + BSI high sensitivity. ⚠️ MIPI only, not for ESP32.
Raspberry Pi / Jetson entry (MIPI): IMX219 — Pi Camera V2 standard, most mature driver, plug-and-play.
Industrial vision / high-speed capture: IMX273 — Global shutter, 226fps, zero jello effect.
Security (1080P nighttime): IMX307 — 2.9µm + STARVIS, strong night vision. Pair with Hi3516.
Security (high resolution): IMX335 — 5MP STARVIS, more detail. Pair with Hi3516/RV1106.
4K security / NVR: IMX415 — 4K STARVIS, best module ecosystem, top pick.
High-end 4K security (2024): IMX678 — STARVIS 2 + Clear HDR, best image quality. ⚠️ AVDD 3.3V.
⚠️ Don't buy for DIY: IMX766 — 50MP phone sensor, no official datasheet, needs custom driver.

Application & Wiring Guide

ESP32 Typical Wiring

⚠️ Important disclaimer: The pin mapping below is based on common AI-Thinker ESP32-CAM module configurations. There is no official unified pin standard for ESP32-CAM — the esp32-camera library examples explicitly state "pin configurations vary by board". Different vendors (AI-Thinker, Freenove, SunFounder, Espressif official EVB) may all differ. Always verify which board you have before wiring.

AI-Thinker ESP32-CAM common mapping (applies to OV2640 / OV5640 / OV7725):

Module Signal	ESP32 GPIO	Function
XCLK	GPIO 27	Master clock via LEDC PWM at 20 MHz
PCLK	GPIO 22	Pixel clock input
VSYNC	GPIO 25	Frame sync input
HREF	GPIO 23	Line sync input
D0	GPIO 32	Data bit 0
D1	GPIO 35	Data bit 1
D2	GPIO 34	Data bit 2
D3	GPIO 5	Data bit 3
D4	GPIO 39	Data bit 4
D5	GPIO 18	Data bit 5
D6	GPIO 36	Data bit 6
D7	GPIO 19	Data bit 7
SIOC	GPIO 26	SCCB clock
SIOD	GPIO 21	SCCB data
PWDN	GPIO 0	Power-down control (optional)
RESET	GPIO 15	Reset control (optional)

Verification: esp32-camera repo examples/camera_example/main/camera_pinout.h (PCLK/VSYNC/HREF confirmed line-by-line against source).

STM32 Wiring

STM32F4/F7/H7 series feature DCMI (Digital Camera Memory Interface) peripheral for direct hardware reception of DVP data streams:

Connect D0–D7 to DCMI_D0–DCMI_D7 corresponding GPIOs
PCLK → DCMI_PIXCK
HSYNC → DCMI_HSYNC
VSYNC → DCMI_VSYNC
I²C_SCL/SDA → any I²C peripheral
Enable DCMI + DMA transfer, target buffer in SRAM or SDRAM

Power Design

Dedicated regulation: Camera modules can draw 100–150 mA 🔍 during capture (varies significantly by sensor — OV5640/GC4653 higher, GC2053/OV7670 lower). Use a dedicated LDO (e.g., AMS1117-3.3) to avoid voltage sag from sharing MCU regulator.
Decoupling caps: Place 10 µF + 100 nF parallel decoupling caps near the module VCC pin, as close to the FPC connector as possible. Standard practice.
Signal integrity: Keep DVP trace length within 10 cm; for longer runs, add 22–33 Ω series termination resistors on PCLK and data lines. ⚠️ Low-speed DVP (PCLK < 30MHz) may not need termination — depends on actual PCB layout.

Troubleshooting

Symptom	Likely Cause	Fix
No image, no PCLK waveform	XCLK missing or wrong frequency	Measure XCLK with scope, confirm 6–24 MHz
Wrong colors / color cast	Output format mismatch with MCU decoder	Check register config, confirm RGB565 or YUV422
Image banding / jitter	Power ripple or PCLK interference	Improve power filtering, shorten data lines
SCCB config failure	Wrong I²C address or no pull-ups	Check address table in this doc, add 4.7kΩ pull-ups
Low frame rate	Low XCLK or resolution too high	Raise XCLK to 24 MHz, reduce resolution
Blurry image (OV5640 AF)	VCM unpowered or AF registers unconfigured	Verify AF_VCC supply, initialize AF firmware
OV7670 garbled	DVDD not separately powered	Confirm on-board 1.8V LDO output

Practical Purchasing Advice

Lessons learned from my own mistakes:

Choose controller first, camera second. ESP32 only does DVP — choose OV2640/OV5640/OV7725/OV3660. Only MIPI-capable controllers (RV1106, Hi3516) can use 4MP sensors like GC4653. Your controller's interface defines your options.
Check if the module has FIFO. OV7670 comes in versions with and without AL422B FIFO. Running non-FIFO on bare STM32 is nearly impossible for normal imaging. The cheap tier is usually non-FIFO.
AF versions need AF_VCC pin. OV5640 AF modules need separate VCM motor power. Some cheap modules merge AF power with main supply, some don't expose it. Check pinout before buying.
Voltage mismatch is the most common board-frying cause. Don't just connect 3.3V blindly. GC0309's optimal point is 2.8V, OV7670 core needs 1.8V. When unsure, check the voltage table in this doc or read the datasheet.
EOL parts (OV7725) carry inventory risk. Officially discontinued; still available on Taobao/LCSC now, but not recommended for new mass production. Fine for prototyping.
GalaxyCore datasheets are harder to find than OmniVision. If Chinese channels don't have GC-series datasheets, try galaxycore.com.cn official site, or module vendor pages like MuchVision, Camemaker. Sipeed Wiki is also a good supplemental source.

Sony IMX Series Purchasing Supplement

The purchasing advice above focuses on OV/GC series (DVP ecosystem). Here are tips specific to Sony IMX series (MIPI ecosystem):

Where to buy IMX modules: IMX219 is widely available on Taobao/LCSC (Pi V2 compatibles). IMX415 modules from LuckFox, Radxa, Camemaker are recommended. IMX335/IMX307 are mostly found through security solution providers. IMX678 is a 2024 new release, modules are still scarce.
Don't buy phone salvage parts for embedded use. Phone sensors like IMX766 are cheap on Taobao (50-300 RMB), but have no datasheet, no driver, and non-standard FPC. You'll most likely waste time trying to light them up.
Watch the STARVIS generation. Sony officially defines three generations: STARVIS (original, 2014), STARVIS 2 (2021, wider dynamic range), STARVIS 3 (latest, LOFIC structure). Confirm which generation you're getting.
Global shutter is only in the Pregius line. If your project involves high-speed motion capture (conveyor belts, sports analysis, 3D scanning), only Pregius global shutter sensors like IMX273 can avoid jello effect. All other IMX and OV/GC sensors are rolling shutter.

References

All parameters in this article verified against the following official datasheets and authoritative sources:

OmniVision official product pages — OV2640 / OV5640 / OV7725 / OV7670 / OV3660 (ovt.com)
OV2640 datasheet — uctronics.com/download/OV2640_DS.pdf
OV5640 datasheet v2.03 — cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf
OV5640 Product Brief — media.digikey.com/pdf/Data%20Sheets/OmniVision%20PDFs/OV5640_PB_3-4-11.pdf
OV7725 datasheet — pdf.datasheet.live/10e069da/ovt.com/OV07725-V28A.pdf
OV7670 datasheet — w2.electrodragon.com/Chip-dat/OmniVision-dat/OV7670-dat/OV7670-ds.pdf
OV3660 datasheet — download.kamami.pl/p1196945-OV3660%20Datasheet.pdf
GC0309 datasheet V1.0 (2009-12-28) — GalaxyCore Inc.
GC2053 datasheet V1.1 (2018-11-29) — GalaxyCore / CK Vision
GC4653 datasheet — Camemaker; Sipeed Wiki
Espressif esp32-camera driver source — github.com/espressif/esp32-camera
Sony Semiconductor Solutions — STARVIS trademark confirmation (STARVIS is Sony-exclusive tech)
Linux Kernel ov7670.c — I²C address definition (android.googlesource.com)
SCCB Functional Specification v2.2 — protocol spec
Sony IMX219 datasheet — dlscorp.com/wp-content/uploads/2018/04/Sony-IMX219-Datasheet.pdf
Sony IMX273 official Flyer — sony-semicon.com/files/62/flyer_industry/IMX273_287_296_297_Flyer.pdf
Sony IMX307 official Flyer — sony-semicon.com/files/62/flyer_security/IMX307LQD_LQR_Flyer.pdf
Sony IMX335 official Flyer — sony-semicon.com/files/62/flyer_security/IMX335LQN_Flyer.pdf
Sony IMX415 official Flyer — sony-semicon.com/files/62/pdf/p-12_IMX415-AAQR_AAMR_Flyer.pdf
Sony IMX678 official Flyer — sony-semicon.com/files/62/flyer_security/IMX678-AAQR_AAQR1_Flyer.pdf (© 2024)
Sony IMX766 — OPPO official specs / IADIY module page / DxOMark
Sony STARVIS technology — sony-semicon.com/en/technology/security/
Raspberry Pi Camera documentation — raspberrypi.com/documentation/accessories/camera.html

Building a Privacy-First Open Source ESP32-S3 Camera with RTSP for MiBee NVR

ZhengZhiCong — Sat, 13 Jun 2026 12:12:57 +0000

Introduction

Like many self-hosted enthusiasts, I've been frustrated with the state of affordable IP cameras for years. Most cheap cameras:

Phone home to unknown servers
Require cloud subscriptions for basic features
Don't support standard RTSP streams
Run closed-source firmware you can't audit

So I built seeed-esp32s3-cam - a 100% open source, privacy-first camera firmware that works natively with MiBeeNvr, Blue Iris, and every self-hosted NVR system.

The Hardware

This firmware is optimized for the Seeed Studio ESP32-S3 Sense board - an incredibly capable camera module for around $15 USD.

Specs:

ESP32-S3 dual-core processor
OV2640 2MP camera sensor
Built-in WiFi
Microphone support
SD card slot

Perfect for monitoring garages, sheds, entrances, or anywhere you want an inexpensive camera without sacrificing privacy.

✨ Key Features

Feature	Status
📹 Native RTSP Server	✅ Works with MiBeeNvr / Blue Iris / VLC
🌐 HTTP MJPEG Streaming	✅ Low latency browser preview
🔍 On-device Motion Detection	✅ Configurable sensitivity
🌙 Night Mode	✅ Auto exposure adjustment
⚙️ Web Configuration UI	✅ Full settings via browser
⚡ Pre-built Binaries	✅ Flash in 2 minutes, no compiling
🔒 100% Local Only	✅ No cloud, no phone home
📄 MIT Licensed	✅ Open source forever

🚀 Getting Started in 5 Minutes

1. Flash the Firmware

No compiling needed! Use the pre-built binaries:

Download the latest release from GitHub
Flash using esptool.py or your favorite flasher:

esptool.py --chip esp32s3 write_flash 0x0 firmware.bin

2. Configure WiFi

Connect to the WiFi hotspot ESP32-CAM-XXXX
Open 192.168.4.1 in your browser
Enter your WiFi credentials
The camera will reboot and connect to your network

3. Access the Web UI

Find your camera's IP address in your router, then open it in a browser. You'll see:

Live video preview
Stream quality settings
Motion detection configuration
Network settings

🎯 MiBeeNvr Integration (The Good Stuff)

This is why I built this - native MiBeeNvr compatibility.

Add this to your MiBeeNvr configuration:

cameras:
  esp32_cam:
    url: rtsp://your-camera-ip:8554/stream
    name: Garage Camera
    record: true
    detect_motion: true

That's it! No hacks, no custom scripts, just standard RTSP. Your camera will show up instantly in the MiBeeNvr web UI.

MiBeeNvr GitHub: https://github.com/Mi-Bee-Studio/MiBeeNvr

🔧 Technical Details

Built with ESP-IDF v5.x using:

Hardware-accelerated JPEG encoding
Optimized memory management for 24/7 operation
Lightweight RTSP server implementation
Non-blocking WiFi handling

The firmware is designed to run stable indefinitely - I've had cameras running for months without a single reboot.

📖 Full Documentation

For a complete step-by-step guide including:

Advanced MiBeeNvr configuration
Performance tuning
Troubleshooting common issues
Motion detection optimization

Check out the full tutorial:
👉 https://blog.mickeyzzc.tech/en/posts/iot/esp32s3-cam-monitor/

💻 Both Projects Are Open Source

Camera Firmware: https://github.com/Mi-Bee-Studio/seeed-esp32s3-cam

MiBeeNvr NVR Server: https://github.com/Mi-Bee-Studio/MiBeeNvr

PRs, feature requests, and bug reports are all welcome! This is a community project - let's build the best open source camera + NVR ecosystem together.

Why This Matters

In an era where every IoT device seems to want your data, having fully open, local-only options is more important than ever. This camera + NVR stack:

✅ Never sends data anywhere
✅ You can audit every line of code
✅ You control all configuration
✅ Works with your existing self-hosted tools

No subscriptions, no accounts, no tracking. Just a complete surveillance system that works.

What's Next?

I'm actively working on:

Auto-discovery between cameras and MiBeeNvr
MQTT support for Home Assistant
SD card recording on cameras
Two-way audio
ONVIF support

Let me know what features you'd like to see!

VictoriaMetrics Stream Aggregation: A Three-Year Retrospective (2026)

ZhengZhiCong — Sun, 07 Jun 2026 22:56:28 +0000

It's been exactly three years since the first article in this series was published in March 2023. The VictoriaMetrics ecosystem has changed dramatically since then. Let's revisit the problems we laid out, see what the official project has resolved, and assess where our custom stream-metrics-route gateway stands today.

I. The Problems We Identified in 2023

Here's a quick recap of the core issues from the original post:

#	Problem	2023 Status
P1	Collection gap inflation	Network jitter or performance issues cause time gaps that inflate stream aggregation deltas
P2	Single-node compute limits	Stream aggregation has no historical state, fast but single-instance bottlenecked
P3	Distributed task allocation	Which compute node should each sample be assigned to?
P4	Out-of-order discarding for same-dimension metrics	Multiple nodes computing the same dimension with different time windows causes later values to be discarded
P5	Resource balancing	Uneven load across distributed compute nodes
P6	Task ID dimension explosion	Stream aggregation inserts node IDs into aggregated time series — the label cardinality grows with every node you add

To address these, we built stream-metrics-route, a Go-based distributed stream aggregation gateway.

II. Three Years Later — What the Official Project Has Done

I reviewed VictoriaMetrics changelogs from v1.86 through v1.138.0 and the official documentation. Here's the scorecard.

✅ Perfectly Resolved

Issues P3, P5: Distributed Task Allocation & Resource Balancing

Official solution: vmagent now natively supports -remoteWrite.shardByURL with consistent hashing sharding.

Starting from v1.86, basic shardByURL was introduced. v1.138.0 (March 2026) was the real milestone — it upgraded the data distribution algorithm from round-robin to consistent hashing, which significantly reduces data redistribution ratios during node changes.

The architecture evolution looks like this:

┌─────────────────┐     ┌─────────────────┐
│ Prometheus      │     │ Prometheus      │
│ Agent 1         │     │ Agent 2         │
└────────┬────────┘     └────────┬────────┘
         │ remote write          │ remote write
         ▼                       ▼
┌─────────────────────────────────────────┐
│           vmagent Cluster               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐│
│  │vmagent-0 │  │vmagent-1 │  │vmagent-2 ││
│  └─────┬────┘  └─────┬────┘  └─────┬────┘│
│        │             │             │     │
│        └─────────────┼─────────────┘     │
│                      ▼                   │
│           ┌──────────────────┐           │
│           │ Consistent Hash │           │
│           └────────┬─────────┘           │
└────────────────────┼─────────────────────┘
                     │ shard by hash
         ┌───────────┼───────────┐
         ▼           ▼           ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │vmstorage │ │vmstorage │ │vmstorage │
   │    -0    │ │    -1    │ │    -2    │
   └──────────┘ └──────────┘ └──────────┘

The VictoriaMetrics blog provides specific algorithm recommendations. Combined with VictoriaMetrics Operator, you can manage shards via shardCount.

Issue P2: Single-Node Compute Scaling

vmagent now supports horizontal scaling natively with replicas + shardCount, including HA support — see Issue #5573.

Out-of-Order / Delayed Data Accuracy (P1 — Partial Mitigation)

v1.112.0 (February 2025) was a key release, adding Aggregation Windows — dual-window buffering for histogram and rate calculations. Instead of flushing immediately, the output is delayed by a samples_lag window, which significantly improves accuracy for late-arriving data. The tradeoff: roughly doubled memory usage (maintaining two aggregation windows simultaneously).

How it works:

Collector          vmagent           VictoriaMetrics
   │                  │                    │
   │  sample1 @T0    │                    │
   ├─────────────────►│  Write to          │
   │                  │  Window A (current)│
   │                  │                    │
   │  sample2 @T1    │                    │
   │  (delayed)      │                    │
   ├─────────────────►│  Write to          │
   │                  │  Window B (previous)│
   │                  │                    │
   │                  │  Aggr result A @T2 │
   │                  ├────────────────────►│
   │                  │  Aggr result B @T3 │
   │                  ├────────────────────►│

See the official docs on streaming aggregation windows.

❌ Still Unresolved

True Distributed Stream Aggregation Coordination

vmagent's stream aggregation is single-instance. There is no coordination mechanism between instances — if two vmagent instances aggregate the same metric, you get duplicate or conflicting output. The official recommendation is to use without/by label clauses to divide responsibility between instances, rather than providing a cross-instance coordination protocol.

Task ID Dimension Explosion (P6)

Official vmagent still inserts internal labels (such as _aggr-related labels) into aggregated time series, but lacks a stream_task_id pre-marking plus dimension control design.

III. stream-metrics-route: Current Status and Value

Core Code Architecture

File	Role
`router.go`	Routing core — filters metrics based on relabel rules
`remotecluster.go`	Dual hashmod scheduling core
`remotewrite.go`	Remote write HTTP client
`kafka.go`	Kafka producer

The Core Algorithm (from `remotecluster.go`)

// Dual hashmod scheduling
hash := sortLabelsHashKey(ts.Labels)
dime := hashMod(r.dimension, hash) // First hashmod → task partition ID

ts.Labels = append(ts.Labels, prompb.Label{
    Name:  "stream_task_id",
    Value: strconv.Itoa(dime), // Insert stream_task_id label
})

hashnode = sortLabelsHashKey(filterLabels) // Second hashmod → node selection
tmpch := hashMod(r.uplen, hashnode)       // Which backend writer to send to

Is It Still Needed in 2026?

Yes — but with an adjusted role. The positioning should shift from "full stream aggregation gateway" to "metric distribution routing gateway + Kafka integration layer." The core differentiated value:

Dual hashmod scheduling + stream_task_id pre-injection — tags metrics at the gateway layer, so all downstream nodes route consistently by this ID. This solves dimension control earlier in the pipeline than the official approach.
Multi-backend async distribution — supports async distribution to both Kafka and remote write, solving the "synchronous forwarding blocks the time window" problem from the original post.
Native Prometheus relabeling integration — works with standard Prometheus relabel configs, no custom syntax to learn.

IV. Recommended 2026 Hybrid Architecture

┌─────────────────┐   ┌──────────────────┐
│  Prometheus     │   │  Business System │
│  Agent Cluster  │   │  Metrics (Kafka) │
└────────┬────────┘   └────────┬─────────┘
         │                     │
         ▼                     ▼
    ┌──────────────────────────────┐
    │   stream-metrics-route       │
    │   (Routing Layer)            │
    │   - Dual hashmod scheduling  │
    │   - stream_task_id injection │
    │   - Relabeling               │
    └──────┬──────┬──────┬─────────┘
           │      │      │
    task=0 │ task=1│task=2│
           ▼      ▼      ▼
    ┌─────────────────────────┐
    │   vmagent Cluster       │
    │  (v1.112.0+ with        │
    │   aggregation windows)  │
    └──────────┬──────────────┘
               │
               ▼
    ┌──────────────────┐      ┌────────────┐
    │  VictoriaMetrics │      │   Kafka    │
    │  (Storage)       │      │   (Topic)  │
    └──────────┬───────┘      └────────────┘
               │
               ▼
    ┌──────────────────┐
    │  vmalert         │
    │  Grafana         │
    └──────────────────┘

Key Configuration

vmagent version requirement: >= v1.112.0, with aggregation windows enabled:

# stream aggregation config
- match: 'http_request_duration_seconds_bucket'
  interval: 5m
  without: [instance]
  enable_windows: true   # Critical! Enables dual-window buffering
  outputs: [rate_sum]

V. Evolution Recommendations

Short-term

Action	Description
Upgrade vmagent to >= v1.112.0	Enable `enable_windows: true` to improve histogram aggregation accuracy
Evaluate stream-metrics-route necessity	If you have no Kafka requirement or high-cardinality `stream_task_id` control need, consider migrating away

Medium-term

Action	Description
Retain stream-metrics-route as front-end routing only	Keep hashmod task allocation + Kafka distribution; remove aggregation responsibility
Disable raw metric persistence	Write only stream-aggregated results to storage to reduce volume
Add metadata management module	The `ruler-handle-process` from the original post (dynamic Record Rule by dimension) is worth building or contributing

Long-term

Action	Description
Contribute `stream_task_id` dimension control upstream	If the dual hashmod design proves out in production
Improve monitoring metrics	Add business-level metrics — queue depth per routing rule, distribution latency, etc.

Putting It All Together

Dimension	Assessment
Problem resolution rate	~50% — 2 of 4 core problems resolved via official upgrades; 2 still need custom solutions
Is stream-metrics-route still needed?	Yes — repositioned as "metric distribution routing gateway + Kafka integration layer"
Recommended architecture	Prometheus → stream-metrics-route → vmagent v1.112.0+ → VictoriaMetrics Storage

Three years is a long time in the observability space. The VictoriaMetrics ecosystem has matured significantly — consistent hashing, aggregation windows, and native sharding all address problems that required custom tooling in 2023. But the hard problems around true distributed stream aggregation coordination and dimension control at the gateway layer remain open.

If you're running a similar stack, the hybrid approach — letting the official project handle what it's good at (single-node aggregation, storage) while keeping custom routing for what it isn't (distributed coordination, dimension pre-injection, Kafka bridging) — has proven to be the right call for us.

Originally published on my blog

Scaling VictoriaMetrics Stream Aggregation: A Deep Dive into Distributed Design（2023）

ZhengZhiCong — Sun, 07 Jun 2026 22:50:31 +0000

VictoriaMetrics' stream aggregation is a powerful feature for reducing metric cardinality in real time. But when you push it to millions of time series across a distributed fleet, the native implementation starts to show cracks.

This post walks through what I found analyzing the stream aggregation source code, the real-world problems that emerged at scale, and the distributed gateway we built to solve them.

Community VM Stream Aggregation — Capability Analysis

Stream aggregation was integrated into vmagent starting from version 1.86 (GitHub issue #3460). Let's look at what it actually does under the hood.

Core Computation: The `pushSample` Function

The heart of stream aggregation lives in the pushSample function. Here's the simplified logic:

func (as *totalAggrState) pushSample(inputKey, outputKey string, value float64) {
    currentTime := fasttime.UnixTimestamp()
    deleteDeadline := currentTime + as.intervalSecs + (as.intervalSecs >> 1)

again:
    v, ok := as.m.Load(outputKey)
    if !ok {
        v = &totalStateValue{
            lastValues: make(map[string]*lastValueState),
        }
        vNew, loaded := as.m.LoadOrStore(outputKey, v)
        if loaded {
            v = vNew
        }
    }
    sv := v.(*totalStateValue)
    sv.mu.Lock()
    deleted := sv.deleted
    if !deleted {
        lv, ok := sv.lastValues[inputKey]
        if !ok {
            lv = &lastValueState{}
            sv.lastValues[inputKey] = lv
        }
        d := value
        if ok && lv.value <= value {
            d = value - lv.value
        }
        if ok || currentTime > as.ignoreInputDeadline {
            sv.total += d
        }
        lv.value = value
        lv.deleteDeadline = deleteDeadline
        sv.deleteDeadline = deleteDeadline
    }
    sv.mu.Unlock()
    if deleted {
        goto again
    }
}

The core idea: each incoming sample's value is compared against the last seen value for that time series. The delta is accumulated into a running total. This works well for counters that monotonically increase, but there's a critical detail — the time window logic is simple periodic checking with no sophisticated handling for delayed or out-of-order arrivals.

What Stream Aggregation Looks Like in Practice

In theory, stream aggregation should cleanly reduce high-cardinality metrics down to manageable summaries. In practice, the picture is messier:

Ideal model: every sample arrives on time, windows align perfectly, aggregation is lossless
Reality: samples arrive late, retries flood old data, gaps appear from network or service issues

Common Issues with Native Stream Aggregation

The Collection Gap Problem

Collection gaps are inevitable. Network blips, service restarts, GC pauses — any of these can cause a gap in metric collection. For high-precision stream aggregation, gaps create a specific failure mode:

When a counter's last tracked value is 1000, and a gap causes the next received value to be 5000, the delta is 4000 — which may span an unknown number of actual increments. If the gap occurred within a single aggregation window, the inflated value corrupts that window's result. If the gap crosses window boundaries, you get compounding errors in downstream calculations.

Distributed Computing Challenges

Stream aggregation doesn't persist historical data, so it's fast — but even the fastest service has single-node limits. When you need to scale horizontally, a cascade of new problems appears:

Is vmagent's built-in collection viable at scale?

In testing, enabling vmagent shard + replica collection with real-time stream aggregation caused significant resource spikes. At very large scales, collection gaps became more frequent, which amplified the calculation errors from gaps rather than mitigating them.

Which compute node should each sample be assigned to?

Without a consistent routing strategy, the same metric dimension gets split across nodes, producing partial results that can't be safely combined.

How do you handle the same dimension set being computed by multiple nodes with different values?

When multiple nodes produce results for the same dimension within the same time window, VictoriaMetrics triggers its out-of-order handling logic — which discards later values. You lose data silently.

How do you balance resources in distributed computation?

Uneven distribution means some nodes are overloaded while others sit idle.

What about the new dimensions introduced by routing?

If you insert a task ID to differentiate compute nodes, you've just added a new dimension that grows with every node you add — defeating part of the purpose of aggregation.

Design and Implementation: A Distributed Stream Aggregation Gateway

After analyzing these problems, it became clear that a frontend module was needed to address them at the entry point. Since vmgateway is an enterprise component, we built our own: vm-receive-route, a distributed stream aggregation gateway.

Key Insight from Source Code

Two aspects of the native implementation are particularly relevant:

Time window range:

currentTime := fasttime.UnixTimestamp()
deleteDeadline := currentTime + as.intervalSecs + (as.intervalSecs >> 1)

The window has a 50% grace period (intervalSecs >> 1) beyond the configured interval. This is the only protection against late-arriving data — and it's quite generous, which means stale data can still influence results within that extended window.

Calculation logic:

lv, ok := sv.lastValues[inputKey]
if !ok {
    lv = &lastValueState{}
    sv.lastValues[inputKey] = lv
}
d := value
if ok && lv.value <= value {
    d = value - lv.value
}
if ok || currentTime > as.ignoreInputDeadline {
    sv.total += d
}

The aggregation only checks if a previous value exists and is smaller — it doesn't handle the case where a late-arriving sample with a lower value (after a restart, for example) creates a negative delta that's simply ignored. There's no deduplication, no gap detection, no intelligent merging.

What the Gateway Solves

1. Asynchronous Processing

Most remote write adapters (like prometheus-kafka-adapter) do synchronous forwarding — they wait for the downstream (Kafka, etc.) to acknowledge before accepting the next batch. Stream aggregation has window constraints: if the write pipeline blocks and samples arrive late, they miss their window and calculations drift.

The gateway decouples ingestion from forwarding using an internal buffer. The remote write endpoint returns immediately, and samples are forwarded asynchronously to the stream aggregation backend. This prevents back-pressure from creating cascading delays.

2. Time Window Filtering

Since stream aggregation already computes deltas between successive values, there's no need for complex out-of-order handling at this layer. The gateway simply cooperates with the aggregation window:

Samples arriving within the window → forward normally
Samples arriving outside the window → discard

This solves two problems at once:

Prometheus retries that send large backlogs of old samples no longer corrupt real-time results
The resource overhead of processing those retries is eliminated at the gateway level — the aggregation backend never sees them

3. Dimension Control

The stream aggregation component inserts a node ID into each aggregated time series to distinguish labels across compute nodes. But as nodes scale horizontally, the cardinality of that label scales too. You need a way to:

Control dimension growth from node identities
Route time series by dimension to the correct node

We designed a dual hashmod scheduling algorithm:

The gateway assigns a hash-based task ID to each time series based on its stable dimensions (not the node identity)
The same series always routes to the same compute node, regardless of which gateway instance processed it
The task ID dimension is bounded by the number of unique dimension combinations, not the number of gateway nodes

By moving the task ID labeling to the gateway layer, we eliminated the unbounded dimension growth that horizontal scaling would otherwise cause.

4. Backend Service Migration for Failures

When a compute node fails, its in-memory aggregation state is lost. The gateway detects failures via health checks and reroutes traffic to healthy nodes. Since the dual hashmod ensures consistent routing, the remaining nodes can immediately pick up the work, though there will be a brief period of incomplete aggregation until the state rebuilds.

Record Rule Dimension Task Generator

Stream aggregation is great for reducing cardinality of single metrics. But real-world monitoring scenarios require combining multiple metrics with functions — which is where Prometheus Record Rule comes in.

The Problem with Record Rules at Scale

Consider an HTTP request metric with a req_path dimension:

Before stream aggregation:

a_http_req_total{zone="bj", src_svr="192.168.1.2", src_port="30021", dis_svr="192.168.2.3", code="202", req_path="/api/foo?abc=xyz"}
a_http_req_total{zone="bj", src_svr="192.168.1.2", src_port="30023", dis_svr="192.168.2.3", code="202", req_path="/api/bar?abc=def"}
a_http_req_total{zone="bj", src_svr="192.168.1.2", src_port="10021", dis_svr="192.168.2.3", code="202", req_path="/api/baz?abc=ghi"}
...

After stream aggregation (dropping req_path and src_port):

agg_a_http_req_total{zone="bj", src_svr="192.168.1.2", dis_svr="192.168.2.3", code="202"}
agg_a_http_req_total{zone="bj", src_svr="192.168.1.2", dis_svr="192.168.2.3", code="500"}
agg_a_http_req_total{zone="bj", src_svr="192.168.1.2", dis_svr="192.168.2.3", code="400"}

But what you actually want to display is the success rate per target:

sum by (dis_svr) (
    rate(a_http_req_total{code=~"2.*"}[5m])
)
/
sum by (dis_svr) (
    rate(a_http_req_total{}[5m])
)

You can use Record Rule to precompute this:

groups:
  - name: a_http_req_total:sum:rate:5m
    rules:
      - expr: sum by (src_svr, dis_svr, code) (rate(a_http_req_total{}[5m]))
        record: a_http_req_total:sum:rate:5m

The problem? Record Rule loads all dimensions of the metric into memory. When dimension counts reach critical thresholds, it triggers OOM. Even below that threshold, higher cardinality means slower computation.

In production, istio_requests_total QPS could be delayed by 20 minutes at high dimension counts. After applying stream aggregation to reduce from tens of millions of time series down to tens of thousands, the delay dropped to 1-2 minutes — better, but still far from real-time.

Dynamic Dimension-Split Record Rules

The issue is that Record Rule evaluates one query per group, loading everything into memory. But if you split the query by specific dimension values, you can process them concurrently.

The static approach after stream aggregation:

groups:
  - name: agg_a_http_req_total:sum:rate:5m-2xx
    rules:
      - expr: sum by (src_svr, dis_svr, code) (rate(agg_a_http_req_total{code=~"2.*"}[5m]))
        record: agg_a_http_req_total:sum:rate:5m
  - name: agg_a_http_req_total:sum:rate:5m-4xx
    rules:
      - expr: sum by (src_svr, dis_svr, code) (rate(agg_a_http_req_total{code=~"4.*"}[5m]))
        record: agg_a_http_req_total:sum:rate:5m
  - name: agg_a_http_req_total:sum:rate:5m-5xx
    rules:
      - expr: sum by (src_svr, dis_svr, code) (rate(agg_a_http_req_total{code=~"5.*"}[5m]))
        record: agg_a_http_req_total:sum:rate:5m

But the problem is that in production, dimension labels are dynamic. You can't hardcode splits for every dimension value. You need a label metadata management system that watches dimension combinations and dynamically generates split queries.

The `ruler-handle-process` Component

We built a small metadata watch and rule builder that automates this. Its configuration looks like:

recode_rules:
  - interval: 5m
    recode_to: istio_requests_total:sum:rate:5m
    metric_name: istio_requests_total
    aggr_type: sum
    vector_type: rate
    vector_range: 5m
    group_by_and_filter:
      - source_workload
      - destination_workload
      - cluster
      - namespace
    group_by:
      - response_code
      - namespace
      - source_workload_namespace
      - destination_workload_namespace
      - destination_service_name
      - cluster
      - reporter
    filter_by:
      cluster: "k8s-hw-bj-xxxxxx"
    with_out:
      source_workload: "ingressgateway-workflows"

The component watches the actual dimension combinations under the metric name istio_requests_total and generates a set of Record Rule configurations — one per unique dimension combination. Combined with Prometheus's Rule component for concurrent evaluation, this reduced computation latency from minutes to seconds.

The generated rules look like:

groups:
  - name: istio_requests_total:sum:rate:5m-7218756fe8a0bc327e818812cefb02f7
    rules:
      - expr: sum by (...) (rate(istio_requests_total{cluster="k8s-hw-bj-1-prod", destination_workload="skyaxe-778-flink", ...}[5m]))
        record: istio_requests_total:sum:rate:5m
  - name: istio_requests_total:sum:rate:5m-8e30244048f8d5519a6332f309578ed4
    rules:
      - expr: sum by (...) (rate(istio_requests_total{cluster="k8s-hw-bj-1-prod", destination_workload="t-bean-portal", ...}[5m]))
        record: istio_requests_total:sum:rate:5m

Each unique dimension combination gets its own rule group, enabling true concurrent computation.

Architecture Combinations for Different Scales

Using community open-source components alongside our custom gateway and rule builder, we assembled a tiered architecture that handles everything from small deployments to massive fleets.

Small Scale: Tens of Thousands of Single Metrics

Minimal setup — vmagent with built-in stream aggregation. No gateway needed. The single-node limits aren't reached yet.

Medium Scale: Tens of Thousands of Multi-Metrics

Add Record Rules for computed metrics. Use the dimension-split approach to keep computation fast. Stream aggregation reduces cardinality before Record Rule evaluation.

Large Scale: Millions+ of Single Metrics

This is where the distributed gateway comes in:

Multiple vmagent instances behind the gateway for horizontal ingestion
Dual hashmod scheduling ensures consistent routing
Time window filtering at the gateway prevents retries from polluting results
Asynchronous forwarding prevents back-pressure from creating cascading delays

Large Scale: Scenario-Based Computational Aggregation for Millions of Metrics

The full stack:

Stream aggregation — first pass cardinality reduction at ingestion
Distributed gateway — routing, filtering, and load distribution
Dynamic rule builder — watches dimension metadata and generates concurrent Record Rule groups
Rule engine — evaluates split queries in parallel

Summary

VictoriaMetrics' stream aggregation is a solid foundation, but it was designed for single-node operation. When you need to scale horizontally, you encounter a series of interconnected problems — collection gaps, dimension explosion, record rule performance bottlenecks — that the native implementation doesn't address.

The solutions aren't particularly complex individually (async processing, time window filtering, hash-based routing, dimension-aware rule generation), but they need to work together as a coherent system. The gateway pattern — intercepting the remote write path before it reaches the aggregation layer — proved to be the right abstraction point for injecting these capabilities without modifying upstream code.

The ruler-handle-process component was the second key insight: rather than fighting Prometheus Record Rule's single-query-per-group limitation, we embraced it by dynamically splitting queries by dimension and running them concurrently. This turned a 20-minute computation into a seconds-level operation.

If you're running VictoriaMetrics at scale and hitting these issues, the patterns described here should be applicable regardless of your specific stack. The gateway approach is generic enough to work with any Prometheus-compatible remote write backend.

Originally published on my blog

MiBeeNvr: A Lightweight Home NVR System I Built

ZhengZhiCong — Sun, 07 Jun 2026 09:27:47 +0000

I have several cameras at home — a few Xiaomi cameras, some DIY ESP32 cameras, and multiple Raspberry Pi CSI cameras. I'd been using cloud storage solutions, but I was never comfortable with them: vendor lock-in, network dependency, and the costs add up. So I decided to build my own NVR system, called MiBeeNvr.

Why Build MiBeeNvr

To be honest, I was never satisfied with existing cloud storage solutions. Take Xiaomi cameras, for example. By default, you can only view them through the Mi Home app. Recordings are either stored on an SD card (limited capacity, frequent plugging/unplugging) or in the cloud. Cloud storage costs tens of dollars per month, and there's the privacy concern — you never know when the manufacturer might use your video data for AI training or sell it to third parties. Not to mention vendor lock-in — switching platforms is nearly impossible.

ESP32 cameras have a similar problem. I built several ESP32 cameras, storing recordings on SD cards, but viewing and playback were inconvenient. I needed a unified management platform.

I also tried other open-source solutions: ZoneMinder requires a LAMP stack — installing and deploying it is more complex than my entire project; Shinobi's configuration is a nightmare; and some smaller projects are basically unmaintained. Frigate is nice but primarily focused on AI detection and depends on Docker — too heavy.

In short, I wanted something that is:

A single binary file — download and run
Lightweight enough to run on a Raspberry Pi
Supports multiple camera types, especially Xiaomi's proprietary protocol
Clean Web interface without frontend complexity
Auto-cleanup of old recordings, won't fill up the disk

After searching around, none of the existing solutions fit. So I wrote my own.

What is MiBeeNvr

MiBeeNvr is a lightweight NVR system written in Go, designed to solve local storage for home cameras.

Overall Architecture

The system has three layers:

Camera End — multiple camera types connect through different protocols:

Xiaomi cameras use the proprietary "miss" protocol (encrypted, multi-layer)
ESP32 cameras send HTTP JPEG/MJPEG streams directly
Raspberry Pi CSI cameras output standard RTSP H.264 via MediaMTX

Protocol Bridge Layer — proprietary protocols get converted to standard RTSP:

go2rtc handles Xiaomi's miss protocol decryption and transcodes it to RTSP
MediaMTX converts Raspberry Pi CSI interface video to RTSP

MiBeeNvr Core — handles the recording logic:

REST API receives all video streams
Recording engine segments incoming video into MP4 files
SQLite stores metadata (pure Go, no CGO, no separate DB installation)
Auto-cleanup daemon removes old recordings per retention policy
HLS live streaming for real-time viewing (up to 4 concurrent)

Access Methods — users interact through:

Built-in Web UI (Svelte 5 SPA, embedded in the single binary)
WebDAV (read-write) and FTP for file-level access
Prometheus metrics for system monitoring

Result: cameras → protocol bridge → MiBeeNvr core → user access, all in a single binary.

Recording Pipeline

Video processing follows a straightforward pipeline:

Input — RTSP streams are handled via gortsplib, HTTP JPEG streams are periodically grabbed as frames
Decode & Mux — RTP packets are depacketized via pion/rtp, then muxed into MP4 via go-mp4
Storage — video is segmented into files (configurable: 30s or 10m intervals), SQLite tracks metadata, files go to disk

The frontend uses Svelte 5 — the entire SPA is compiled to static assets and embedded into the Go binary. Deployment is a single file, no separate Web server needed.

Backend tech stack:

Go 1.26 + modernc.org/sqlite (pure Go, no CGO dependency)
chi routing library, clean and efficient
gortsplib for RTSP/RTP protocol
pion/rtp for real-time streaming

SQLite was chosen because it's single-file, pure Go, performs well enough for home use, supports concurrent access, and most importantly, doesn't require a separate database installation.

Design Philosophy

The entire project's design philosophy is "simple and straightforward:"

Single binary file, no external dependencies
Supports cross-compilation, runs on AMD64/ARM64
YAML configuration, intuitive
Built-in Web interface, open browser to use
Minimal resource usage, runs smoothly on Raspberry Pi 4

Key Features

Supports multiple camera protocols: RTSP (H.264/H.265), HTTP JPEG
Built-in Web interface with dark/light theme switching
Chinese/English bilingual support
WebDAV (read-write), FTP, REST API
MQTT-triggered recording, ideal for smart home integration
Prometheus monitoring metrics
Per-camera independent retention policies
MP4 segmented recording, auto-cleanup of old files
Supports HLS live streaming (up to 4 concurrent)

My Actual Deployment

I run it on an ARM64 mini host with 512MB RAM and 2GB storage. The system runs very stably — basically set it and forget it.

Connected 4 cameras, each with its own characteristics:

Raspberry Pi CSI Camera — RTSP bridge via MediaMTX, converting CSI interface video to standard RTSP. Configured as rtsp_h264.
ESP32-S3 Camera — DIY, running MJPEG stream via HTTP protocol. Configured as http_jpeg.
Xiaomi Camera (Balcony) — Protocol conversion via go2rtc (Xiaomi proprietary → RTSP), 2K resolution, configured as rtsp_h265.
Xiaomi Camera (Living Room) — Same as above, 1080P.

Configuration is 30-second segment recording with 1-day retention. This interval is a trade-off: too short creates too many files, too long makes it inconvenient to look up incidents. WebDAV (read-write) and FTP are enabled for convenient phone viewing and backup.

The Web interface is clean — camera management and recording lists are straightforward.

Settings page:

Configuration File

The complete configuration file looks like this — YAML format, clear at a glance:

server:
  listen: ":9090"

storage:
  root_dir: "/mnt/data/nvr"
  segment_duration: "30s"

cameras:
  - id: "rpi-csi-cam"
    name: "RPi CSI Camera"
    protocol: "rtsp_h264"
    url: "rtsp://10.0.1.100:8554/stream"
    enabled: true

  - id: "esp32-cam"
    name: "ESP32-S3 Camera"
    protocol: "http_jpeg"
    url: "http://10.0.1.101/capture"
    enabled: true

  - id: "xiaomi-balcony"
    name: "Xiaomi Camera"
    protocol: "rtsp_h265"
    url: "rtsp://10.0.1.102:8554/xiaomi_stream"
    enabled: true

cleanup:
  retention_days: 30
  disk_threshold_percent: 95

auth:
  username: "admin"
  password_hash: "Use mibee-nvr hash-password command to generate"

webdav:
  enabled: true
  path_prefix: "/dav"
  read_write: true

ftp:
  enabled: true
  port: 2121

Xiaomi Camera Integration

Xiaomi camera protocol is a major headache. It uses its proprietary "miss" (Mi Secure Streaming) protocol with multi-layer encryption, without a standard RTSP interface. Even if you know the camera's IP, you can't pull a stream with VLC.

Fortunately, there's go2rtc, a lifesaver. The integration works in four steps:

Account auth & key exchange — go2rtc logs into your Xiaomi account, retrieves device lists and encryption keys from Xiaomi Cloud
Establish P2P connection — go2rtc initiates a miss protocol handshake with the camera, establishing a peer-to-peer link
Video stream relay — the camera sends its encrypted miss stream to go2rtc continuously; go2rtc decrypts and transcodes it into a standard RTSP stream (H.265); MiBeeNvr receives this as a normal RTSP camera and records segmented MP4 files
Independent access — once set up, you no longer need the Mi Home app or Xiaomi cloud subscription; all recordings are accessible via MiBeeNvr's Web UI, WebDAV, or FTP

The entire process requires no firmware flashing, no camera disassembly, and no Xiaomi cloud storage subscription. go2rtc handles all the protocol conversion.

go2rtc Deployment

The easiest way to deploy go2rtc is with Docker:

# Create configuration file
cat > go2rtc.yaml << EOF
streams:
  xiaomi_balcony:
    - xiaomi://your_account:cn@10.0.1.100?did=your_camera_did&model=isa.camera.hlc7
  xiaomi_living_room:
    - xiaomi://your_account:cn@10.0.1.101?did=your_camera_did&model=isa.camera.mj200

rtsp:
  listen: ":8554"
EOF

# Run container
docker run -d --name go2rtc \
  -p 8554:8554 \
  -p 1984:1984 \
  -v $(pwd)/go2rtc.yaml:/config.yaml \
  alexxit/go2rtc

Key points:

The xiaomi:// protocol requires Xiaomi account and password authentication
did is the device's unique identifier, model is the device model (can be found in the Mi Home app)
go2rtc automatically handles P2P connection and miss protocol decryption
The final standard RTSP stream is exposed on port 8554, and MiBeeNvr connects to it like any normal camera

Then point to go2rtc in MiBeeNvr's config:

cameras:
  - id: "xiaomi-balcony"
    name: "Xiaomi Camera"
    protocol: "rtsp_h265"
    url: "rtsp://localhost:8554/xiaomi_balcony"
    enabled: true

Pitfalls Encountered

Xiaomi camera integration has several pitfalls:

First-time network connection: Xiaomi cameras must be able to reach the internet for key exchange with Xiaomi servers. After connection is established, subsequent transmission is over LAN.
Device ID acquisition: Each camera's did is unique. Use go2rtc's WebUI (port 1984) for auto-discovery, or dig through the Mi Home app.
Not all models are supported: go2rtc maintains a compatibility list — check before buying a camera.
H.265 vs H.264: Newer Xiaomi cameras mostly use H.265. MiBeeNvr supports both codecs, but H.265 saves storage space.

ESP32 Camera Projects

While working on MiBeeNvr, I also built several ESP32 camera firmware projects. ESP32 cameras had their share of pitfalls, but were also quite interesting.

I built three firmware projects with different positioning, all designed as upstream capture endpoints for MiBeeNvr — cameras handle video capture, MiBeeNvr handles unified storage and management.

MiBeeCam — ESP32-S3-A10 Solution

GitHub · MIT License

This is the most successful solution. ESP32-S3-A10 dev board + OV2640 camera (8225N module), 16MB Flash, ESP-IDF v5.4.3 development. Features include MJPEG stream, frame-differencing motion detection, Web config interface, Prometheus metrics. Having an LCD screen makes debugging much easier.

AI Thinker ESP32-CAM — Classic Solution

GitHub · MIT License

Entry-level choice, AI Thinker ESP32-CAM dev boards are widely available for around $10-15. 4MB Flash + 4MB PSRAM, runs MJPEG stream without issues. Highlights include SD card storage and NAS upload (WebDAV/HTTP), plus adaptive dark scene detection — automatically switches to infrared mode at night. Downside: no screen, 4MB Flash is limited.

MiBeeHomeCam — XIAO ESP32-S3 Sense

GitHub · GPL v3.0

The most advanced solution. XIAO ESP32-S3 Sense board is compact and refined, with dual camera support (OV2640/OV3660), 8MB Octal PSRAM. Highlights include AVI segmented recording (real video recording, not just snapshots), FTP/WebDAV dual-protocol upload, watchdog anti-freeze, chip temperature monitoring, batch file management. Suitable for long-term stable operation.

Selection Guide

Beginners: Choose AI Thinker ESP32-CAM — cheap with plenty of resources
Daily use: Choose MiBeeCam — LCD screen makes debugging convenient
Maximum features: Choose XIAO ESP32-S3 Sense — most powerful

System Service Configuration

For stable operation, I use systemd to manage MiBeeNvr:

[Unit]
Description=MiBee NVR
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=nvr
ExecStart=/mnt/data/nvr/bin/mibee-nvr -config /mnt/data/nvr/mibee-nvr.yaml
WorkingDirectory=/mnt/data/nvr
Restart=on-failure
RestartSec=5

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/mnt/data/nvr
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Save to /etc/systemd/system/mibee-nvr.service, then systemctl enable --now mibee-nvr. Auto-start on boot, auto-restart on failure.

Open Source

MiBeeNvr is open source, stars and contributions welcome:

MiBeeNvr: https://github.com/Mi-Bee-Studio/MiBeeNvr (MIT License)
MiBeeCam: https://github.com/Mi-Bee-Studio/luatos-esp32s3-a10-camera (MIT)
AI Thinker ESP32-CAM: https://github.com/Mi-Bee-Studio/ai-thinker-esp32-cam (MIT)
MiBeeHomeCam: https://github.com/Mi-Bee-Studio/seeed-esp32s3-cam (GPL v3.0)

Documentation is comprehensive, with detailed deployment and configuration instructions.

Closing Thoughts

To be honest, I built this project mainly because I was dissatisfied with all the existing solutions. Cloud storage is too expensive, open-source solutions are too heavy, and commercial products are too closed. Building my own was just right: lightweight, free, and fully under my control.

Oh, about the name MiBeeNvr — "Mi" stands for me (Mickey), "Bee" stands for... let's keep that a secret, and "Nvr" is naturally Network Video Recorder. Simple, memorable, and a bit meaningful.

If you also have home camera needs or ideas about NVR systems, feel free to reach out. Issues are welcome on GitHub.

Originally published on my blog.

DEV Community: ZhengZhiCong

Embedded Camera Module Selection Handbook — From Basics to Purchasing Reference

About This Handbook

Quick Selection Guide

DVP Interface Basics

Signal Definitions

Timing

SCCB Control Interface

MIPI CSI-2 Interface Basics

DVP vs MIPI CSI-2

Lane Count and Bandwidth

Sensor Technology Principles

Shutter Types: Rolling vs Global

Backside Illumination (BSI) vs Frontside Illumination (FSI)

HDR Multi-Exposure Fusion

Quad Bayer Pixel Binning

OV2640 Module

Core Specs

Resolution & Frame Rate

Typical Pinout (24-PIN FPC)

OV5640 Module

Core Specs

OV7725 Module

Core Specs

GC0309-8225N V2 Module

Core Specs

OV7670 Module

Core Specs

OV3660 Module

Core Specs

GC2053 Module

Core Specs

GC4653 Module

Core Specs

OV9281 Module

Core Specs

OV5647 Module

Core Specs

NOT in esp32-camera support list. ESP32 users should use OV2640 or OV5640.

IMX219 Module

Core Specs

IMX273 Module

Core Specs

IMX307 Module

Core Specs

IMX335 Module

Core Specs

IMX415 Module

Core Specs

IMX678 Module

Core Specs

IMX766 Module

Core Specs

Sony IMX Series Key Parameters Comparison

IMX477 Module

Core Specs

IMX708 Module

Core Specs

IMX296 Module

Core Specs

IMX296 vs IMX273: Both are Pregius global shutter, 3.45µm pixels. IMX296 is the official Pi Global Shutter Camera sensor with full driver/docs; IMX273 is more industrial FA focused. For Pi projects choose IMX296, for industrial FA choose IMX273.

Module Comparison Summary

Key Parameters Comparison

Selection Recommendations

Application & Wiring Guide

ESP32 Typical Wiring

STM32 Wiring

Power Design

Troubleshooting

Practical Purchasing Advice

Sony IMX Series Purchasing Supplement

References

Building a Privacy-First Open Source ESP32-S3 Camera with RTSP for MiBee NVR

Introduction

The Hardware

✨ Key Features

🚀 Getting Started in 5 Minutes

1. Flash the Firmware

2. Configure WiFi

3. Access the Web UI

The Core Algorithm (from `remotecluster.go`)

Core Computation: The `pushSample` Function

The `ruler-handle-process` Component