Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 

Repository files navigation

obsbot-tiny3-protocol

Community reverse-engineering notes for the OBSBOT Tiny 3 — what you can and cannot control over plain USB, which vendor commands the firmware actually honours, and the traps that will waste your afternoon. Unofficial; measured against a real Tiny 3 on Windows 11.

The short version, for anyone who lands here from a search:

  • Pan / tilt / zoom / presets / sleep / image settings — all controllable over standard USB. ✅
  • AI tracking on/off and AI mode (single, group, voice, desk, hand, whiteboard) — controllable. ✅
  • Auto Zoom framing (Full Body, Upper Body, Close-up, Headless, Lower Body) — not controllable by anything, OSC included. OBSBOT Center only. ❌
  • The Tiny 2 command set is a trap. The Tiny 3 renumbered its AI modes and silently ignores most Tiny 2 AI commands instead of erroring. ⚠️

Why this exists

Every existing reverse-engineering write-up targets the Tiny 2. If you point that command table at a Tiny 3, roughly half of it appears to work — the camera ACKs every frame — while doing nothing at all. There is no error, no NAK, no clue. This repo is the result of testing each command against the camera's own reported state instead of trusting the ACK.

The two control paths

Path What it is Needs Center running?
UVC + vendor XU over USB What this repo documents. Direct, no OBSBOT software. No
OSC Official, documented, but it talks to OBSBOT Center, which then drives the camera. Yes

The Tiny 3 has no network stack — unlike the Tail Air / Tail 2 / Talent, it is not an OSC device itself. See docs/osc.md for the official OSC table and what it implies.

Documentation

  • docs/verified-commands.md — the measured results: every command, whether the camera acts on it, and how that was proven
  • docs/protocol.md — the V3 frame format, CRC, XU addressing on Windows
  • docs/ai-modes.md — the Tiny 3 AI-mode enum and why Tiny 2 values misfire
  • docs/uvc-controls.md — every UVC property the Tiny 3 exposes, with its real firmware defaults (including two undocumented ones)
  • docs/gotchas.md — the traps: zoom that reverts, a "default" that blacks out the image, ACK-but-ignore, and more
  • docs/osc.md — the official OSC command table (Tiny 3 rows highlighted)

Tools

  • tools/probe.py — dump every UVC property with ranges and defaults
  • tools/ai_status.py — read the camera's live AI state (the oracle that makes all of this verifiable)
  • tools/sweep.py — fire a list of vendor opcodes and report which ones actually changed the camera's state

Hardware

  • USB VID/PID: 0x3564 / 0xFEF8 (composite: UVC video + UAC audio + MTP)
  • XU descriptor GUID: {9A1E7291-6843-4683-6D92-39BC7906EE49} (same as Tiny 2)
  • Vendor control selector: 0x02 on the extension unit
  • Pan ±130°, tilt ±90°, zoom 0–100 (≈1.0–2.0×), FOV 86° / 78° / 65°

Built on this

Credit

The V3 frame format, CRC-16/USB scheme and the Tiny 2 opcode table come from lxman/obsbot-mcp — excellent work, and the starting point for all of this. Everything here about Tiny 3 divergence is new and measured independently.

Official OSC spec: https://www.obsbot.com/explore/obsbot-center/osc

License

MIT — see LICENSE. Not affiliated with or endorsed by Remo Tech Co., Ltd. (OBSBOT).

About

Community reverse-engineering notes for the OBSBOT Tiny 3: which USB vendor commands the firmware actually honours, the renumbered AI mode enum, and the gotchas. Measured, not assumed.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages