Action 6 connection and live view
Hardware evidence collected 2026-09-21 with DJI Mimo 2.12.0 and camera firmware shown by the UI as V01.02.0521. The operator identified the starting mode as Video, Custom 4K, 1:1, 25fps. Those UI facts are separate from the wire interpretations below. This page records the initial closed Mimo take. Later settings, mode, and Bluetooth experiments extend it; the survey does not claim OpenPocketCine hardware verification.
Evidence and reproduction
Section titled “Evidence and reproduction”The source is the closed file 01-survey_00001_20260921104840.pcapng in the
private captures/action6-20260921/network/ directory. Frame numbers refer to
that file. Times in this document are UTC on 2026-09-21; the filename uses
local time. The last decoded DUML frame is 93395 at 08:53:39.926323.
An immutable working copy, the original decoded JSONL, a reproducible offline
analysis script, subscription inventories, and extracted video are retained in
captures/action6-20260921/analysis/startup/. Raw bodies, pairing material,
addresses, and device identifiers stay there, outside Git. Source SHA-256:
280bdb53a975d2aacda27f0285be1b9ce81d971653ae870b7077d120c7bc32a2The analysis re-scans the copied capture using
tools/duml_parse.py, checks DUML CRCs and transport
header checksums/lengths, and compares the resulting frame multiset against the
copied decoded JSONL. All 20,725 DUML frames agree. Subscription replies are
matched by sequence, reversed endpoints, and forward capture order; sequence
alone is insufficient when a sequence is reused.
The capture contains batches of packets with nearly identical timestamps and approximately one-second spacing between batches. These timestamps establish capture ordering and event locations; they are not measurements of network latency, display latency, or camera frame pacing.
Connection and first picture
Section titled “Connection and first picture”The camera uses the established UDP datalink on port 9004. There are 258 actual phone handshake requests, starting at frame 1367, 08:48:56.732847, and one actual camera handshake reply in this take. There are also 137 ICMP destination/port-unreachable messages. Their quoted inner UDP packets can look like reverse-direction handshake traffic in a naive export. The validated UDP export excludes ICMP; these quotes are not extra camera handshakes.
| Frame | UTC time | Observed event |
|---|---|---|
| 57639 | 08:51:12.577281 | Final 48-byte UDP handshake request. |
| 57642 | 08:51:12.577364 | Camera 15-byte pktType=0 handshake acknowledgement. |
| 57643 | 08:51:12.577388 | Camera 34-byte pktType=1 initial window; command cursors are 39936. |
| 57644 | 08:51:12.577412 | App first pktType=5 command, 00/2B, transport sequence 39944: initial cursor plus eight. |
| 57651 | 08:51:12.577718 | First captured app pktType=4 window acknowledgement. |
| 57700 | 08:51:12.579320 | First capability subscription. |
| 57868 | 08:51:12.585074 | First live-video access unit, with AVC parameter sets and an IDR picture. |
| 57930 | 08:51:12.587539 | TCP port 7001 carries the 17-byte 07/45 pairing-token poke. |
The short handshake acknowledgement does not supply a command cursor. The next telemetry packet does. Preserve this distinction when adapting the datalink transport.
Only one TCP DUML frame is decoded; the other captured TCP payloads are one-byte keepalives. The capture places UDP startup and initial video before the TCP poke. It therefore does not establish that a TCP poke must precede UDP startup, nor that either step may safely be omitted on a fresh connection.
The first picture-bearing unit precedes the first observed 09/A8 live enable
by about 32.259 seconds. This is an observation of an existing Mimo/camera
session, not proof that a new client can obtain video without enabling it.
There is also a roughly 31.24-second video gap between frames 58822 and 65444;
the cause is not established by this analysis.
Live enable and response behavior
Section titled “Live enable and response behavior”All nine app 09/A8 writes use sender 0x02, receiver 0x41, flags
0x40, and the same ten-byte body as the existing
Commands.liveViewEnable
template. This is direct Action 6 evidence for the receiver used by Nano,
rather than the Pocket receiver 0x08.
| Request frame | UTC time | Response frame | First response byte |
|---|---|---|---|
| 65334 | 08:51:44.844211 | 65339 | D6 |
| 65340 | 08:51:44.844358 | 65341 | D6 |
| 65375 | 08:51:44.845325 | 65379 | 00 |
| 65523 | 08:51:45.849483 | 65525 | 00 |
| 69579 | 08:52:04.019295 | 69583 | 00 |
| 70918 | 08:52:10.077695 | 70920 | 00 |
| 80803 | 08:52:53.500740 | 81209 | 00 |
| 81239 | 08:52:54.511691 | 81261 | 00 |
| 86631 | 08:53:13.688477 | 86637 | 00 |
Requests 80803 and 81239 reuse the same DUML sequence and body. There are eight
distinct request sequences, not nine independent transactions. The meaning of
D6 is unresolved; this take does not identify its cause as busy, playback, or
another state.
Neither the Nano 02/09 live gate nor the Pocket 02/68 command appears
anywhere in this closed take. Absence here does not prove absence in every
Action mode or connection path. Mimo’s repeated enables are observations, not
permission to change OpenPocketCine’s
enable-once/watchdog contract.
Validated live-video format
Section titled “Validated live-video format”The 3,871 camera pktType=2 video packets advance the transport sequence by
eight modulo 65536 throughout, with no sequence discontinuities. The
analysis reconstructs 2,899 complete access units, checking each against
its declared length. The largest encoded unit is 16,141 bytes.
Each unit contains the same private AVC SEI framing already associated with
Nano: NAL type 6, private payload type 0xF0, and a 25-byte private payload.
The reproducible extraction removes that exact metadata record, retains
picture and parameter-set data, and removes only the terminal access-unit
delimiter that has no following picture. FFmpeg then decodes 2,899 frames
with no reported errors. This avoids mistaking private SEI parser complaints
for corrupt picture data.
| Property | Validated elementary-stream result |
|---|---|
| Codec | AVC/H.264, High profile, level 3.1 |
| Coded picture size | 720 × 720 |
| Pixel format | yuv420p, 8-bit 4:2:0 |
| Nominal frame rate reported by FFprobe | 25/1 |
| Range/colour metadata reported by FFprobe | Limited range, BT.709 matrix, SMPTE 170M transfer |
| Parameter-set-bearing units, first packet frame | 57868, 65444, 65533, 69591, 70923, 81014, 81313, 86653 |
All eight parameter-set-bearing units use the same square 720-pixel dimensions. The nominal rate is not a capture-timestamp estimate. This evidence concerns the live feed in the starting Custom 4K mode. It does not establish the recording codec, recording bit depth, actual colour curve, or live dimensions in other modes. A square feed must not be forced into a 16:9 presentation.
Camera and component identity
Section titled “Camera and component identity”The 00/01 response at frame 58793, sender 0x01, contains model string
AC006. Responses from sender 0x48 at frames 59322, 59589, 59594, and
60707 contain component string AC206. AC206 is a component identifier in
these responses; it is not evidence for a separate marketed camera model.
00/51 replies carry private device identifiers, retained only with the raw
capture. No full camera firmware version was safely established from the
binary module responses. Use the UI version stated above rather than guessing
a version from unknown byte fields. BLE discovery, model ID, pairing, and
Wi-Fi credential acquisition were not captured by this network take.
Capability subscription inventory
Section titled “Capability subscription inventory”The camera uses the existing 00/99 subscription protocol: requests from
0x02 to 0x28, pushes from 0x28 to 0x02, and named values inside the
subscription envelope. All 35 camcap_ requests received status 00.
Thirty-one names produced values; four accepted subscriptions produced no
value during this take. Acceptance alone is not a populated capability table.
| First value frame | Names, with the common camcap_ prefix omitted |
|---|---|
| 57721 | mode_profile |
| 57749 | video_format, fov, iso, photo_storage_format, color_mode, wb, photo_size, video_codec, shutter, photo_timer_interval |
| 57783 | exposure_mode, zoom, antiflicker, sharpness, denoise, aperture, shutter_max, eis |
| 57827 | iso_auto_max, loop_video_duration, countdown, photo_time_limited_burst_param, custom_mode, aperture_ctrl_strategy, auto_aperture_range, capture_aspect_type, style_filter_density, style_filter_mode, steady_preferred_status |
| 57892 | common |
| No push | hyperlapse_ratio, slowmotion_ratio, timelapse_duration, portrait_mode |
The last four requests are at frames 57728, 57729, 57730, and 57737;
their success replies are at 57800, 57801, 57802, and 57812, respectively.
The non-capability subscription last_photo_subtype repeatedly receives
status 01, first at request 57793, reply 57888.
These tables are conditional on current camera state. They are not an all-modes union, and a field’s presence does not establish its SET command. Exact bodies and the complete per-request response mapping are retained in the private subscription files.
Initial aperture capability structure
Section titled “Initial aperture capability structure”| Field | Frame | Observed structure or value |
|---|---|---|
camcap_aperture |
57783 | Version 1; count 9; scalar candidates 200, 220, 240, 250, 280, 320, 340, 350, 400. |
camcap_auto_aperture_range |
57827 | Version 1; count 5; pairs 200–400, 220–400, 240–400, 260–400, 280–400. |
camcap_aperture_ctrl_strategy |
57827 | Version 1; six-byte body. A leading count of 3 would yield IDs 4, 2, 3, followed by unresolved values 3, 4. |
cam_aperture_ctrl_strategy |
57877 | Version 1, current field 4, unchanged in this take. |
cam_auto_aperture_range |
57877 | Version 1, current pair 200–400, unchanged in this take. |
Dividing the range endpoints by 100 agrees with the five automatic aperture ranges in the official reference. That is supporting correspondence, not an independently captured SET mapping. Do not flatten the nine scalar candidates into nine proven manual aperture choices. In particular, 260 is a range floor but is absent from the scalar table. The strategy body has additional data and must not be treated as a simple list without further validation. Later UI-correlated selections establish ID 4 as Auto; see the aperture SET and mechanical-readback mapping.
A candidate iris value exists in cam_expo_param: the little-endian 16-bit
field at value offset 13 changes from 300 at frame 57827 to 290 at
69704 and 280 at 69789, returning to 290 at 70899. Later synchronized aperture changes confirm hundredths of an f-number
for this field; the settings reference supplies that evidence.
The initial take alone did not establish its interpretation.
Other useful tables and current state
Section titled “Other useful tables and current state”The following are decoded numeric structures. Where existing enums supply a label, that correspondence is stated separately from the observation.
| Field | Observed values and interpretation limit |
|---|---|
camcap_video_format |
Six entries for resolution 0x7D, fps IDs 1–6. Existing enums map these to Custom 4K 1:1 and 24/25/30/48/50/60fps. UI confirms only the starting 25fps state here. |
cam_video_param_v2 |
First at 57877; current resolution 0x7D, fps ID 2. |
camcap_color_mode |
Two IDs: 0x3F, 0x3D. Existing Nano mappings suggest Normal 10-bit and D-Log M; Action UI changes and recording files are required to qualify those labels. |
cam_image_effect |
First at 57877; colour field 0x3F. Subsequent white-balance-related updates preserve that field. |
camcap_iso |
Ten IDs: 0, 3, 4, 5, 6, 7, 8, 9, 10, 11; existing mapping is Auto and ISO 100 through 25600. |
camcap_iso_auto_max |
Version 1, six IDs 4, 5, 6, 7, 8, 9; existing limit mapping is 800/1600/3200/6400/12800/25600. |
camcap_shutter |
26 reciprocal denominators: 8000, 6400, 5000, 4000, 3200, 2500, 2000, 1600, 1250, 1000, 800, 640, 500, 400, 320, 240, 200, 160, 120, 100, 80, 60, 50, 40, 30, 25. This is the current 25fps table, not photo shutter limits. |
camcap_fov |
Four IDs: 2, 1, 0, 5; labels need UI-correlated selection. |
camcap_eis |
Four stabilization IDs: 0, 1, 4, 2; labels need UI-correlated selection. |
camcap_sharpness |
Five signed candidates: −2, −1, 0, 1, 2. |
camcap_denoise |
Four signed candidates: −2, −1, 0, 1. No +2 in this current table. |
camcap_countdown |
Seven 32-bit values: 0, 500, 1000, 2000, 3000, 5000, 10000; milliseconds are a candidate interpretation. |
camcap_loop_video_duration |
Five 16-bit values: 0, 300, 1200, 3600, 65535; ordinary entries fit seconds, sentinel meanings unresolved. |
camcap_photo_time_limited_burst_param |
Five records, each a 32-bit value plus byte: (0,1), (1000,5), (1000,10), (3000,15), (3000,30). Candidate duration/count pairs, not exercised. |
camcap_capture_aspect_type |
Four IDs: 1, 2, 3, 4. Current cam_capture_aspect_type is 4, first at 57877. |
camcap_style_filter_density |
Four candidates: 30, 50, 70, 100. |
camcap_style_filter_mode |
Initial empty-like body at 57827; changes at 65295 to a body containing IDs 0 through 6. Structure and UI labels unresolved. |
camcap_mode_profile |
Eight fixed-size records beginning with IDs 5, 1, 0, 10, 2, 52, 40, 75. This is an inventory, not a complete verified mode-label mapping. |
cam_lens_type and cam_portrait_mode both push zero-valued state at frame
57877. A state push can exist even when its capability subscription supplies
no table. Neither key proves support for autofocus or a particular accessory.
The take also includes audio_status_v2; its 114-byte value is preserved for
later audio-specific analysis, without assigning meanings to unknown fields.
The operator subsequently confirmed manual exposure M with ISO Auto in UI
shot 035, with an Auto ISO MAX ceiling of 25600. This is separate,
later UI evidence, not a state transition decoded from this startup take. It
is important when adapting
CamCapIsoAutoMax: its current
version-1 shortcut treats that version as no-Auto data based on an older
D-Log 2 case. The Action 6 version-1 table and UI evidence show that version
alone cannot make that decision. Manual exposure must not be treated as
implying a fixed ISO.
Differences to preserve during implementation
Section titled “Differences to preserve during implementation”| Area | Action 6 evidence and resulting implementation requirement |
|---|---|
| Live enable routing | Receiver 0x41 is captured. Current CameraModel.usesCapturedLiveEnable excludes Action names and its receiver falls back to 0x08 outside Nano; both require explicit Action qualification. |
| Startup gates | No Nano 02/09 gate or Pocket 02/68 appears. Do not inherit those writes merely because one live receiver matches Nano. |
| First picture | Video exists before the first observed enable. This does not justify inheriting the Pocket 3 first-picture resolution poke. |
| Transport | Short handshake acknowledgement followed by a 34-byte cursor window uses the existing framing and plus-eight sequence convention. |
| Video | AVC and Nano-style private SEI are reusable findings; square 720 × 720 is an observed presentation requirement. |
| Capabilities | Named subscriptions are shared, including new aperture strategy/range fields. Interpret values by field structure and current mode, not a universal version rule. |
| Resolution | VideoResolution.p4K_1x1 already exists as 0x7D; a duplicate enum is unnecessary. |
| Iris | CameraStatus.irisLabel is presently a placeholder. Use the later verified aperture mapping to qualify an implementation. |
| Focus | Current supportsTapFocus/supportsFocusMode defaults for non-Nano bodies are not Action evidence. No autofocus support is established by this take. |
These are findings against
CameraModel,
CameraControl, and
CameraStatus, not changes
to production behavior. Preserve the existing
live-session and
connection-reliability contracts when implementing
support.
Evidence added after this take
Section titled “Evidence added after this take”The initial take is extended by independently timestamped captures:
- Settings: aperture strategies, Auto ranges, manual aperture, ISO/shutter, white balance, color, FOV and image adjustments.
- Shooting modes: mode-specific formats, timers, burst selections, filters, lapse controls, Portrait Mode, loop and custom presets.
- Device settings: explicit disconnect/rejoin and the remaining Video aspect/rate combinations.
- Bluetooth: advertising, two already-paired handshakes, GATT and the separate fresh-client authorization gap.
- Original media: completed sample files and independent decode.
- Advanced controls: conditional 8K limits, horizon modes, zoom and later exposure evidence.
Use the per-page confidence limits and the survey overview when deciding what still needs hardware proof. Do not extend this take’s conclusions to a later experiment without its corresponding evidence.