Skip to content

feat: drip-scan full-frame single-exposure image capture (SDK) - #168

Draft
boringethan wants to merge 15 commits into
nextfrom
feature/167-drip-scan-capture
Draft

feat: drip-scan full-frame single-exposure image capture (SDK)#168
boringethan wants to merge 15 commits into
nextfrom
feature/167-drip-scan-capture

Conversation

@boringethan

Copy link
Copy Markdown
Contributor

Draft — SDK side of the drip-scan feature (design spec 2026-07-19, camera-fpga#8). Opened as a draft: do not merge until the matched set validates on the rig.

What this adds

  • config.py: TYPE_IMAGE stream byte (0x03), OW_CAMERA_IMAGE_MODE=0x30, pinned sweep/production sensor-timing profiles, OX02C1B_I2C_ADDR.
  • StreamInterface: opt-in image queue; TYPE_IMAGE packets are routed to a dedicated queue so histogram consumers never see them. Histogram hot path is byte-identical when no image queue is attached (verified against the parent commit + the full tests/test_pipeline/ suite).
  • omotion/ImageCapture.py (new): CRC-verified line parser (util_crc16, byte-identical to sensor-fw utils.c, check value 0x29B1), vectorized RAW10 unpacker (pinned bit layout — proven to invert the FPGA packer's own test vector), FrameAssembler with frame_cnt single-exposure enforcement + overrun/wedge tracking, FpgaRegs (FPGA I2C map v2: sweep/overrun/wedge), atomic group-hold sensor retiming, and the capture_full_frames orchestrator (graduates camera-fpga tools/full_frame_capture/).
  • MotionSensor: set_camera_image_mode(enable, mask) (OW_CAMERA_IMAGE_MODE wire format).

Tests

33 new software-only unit tests (tests/test_image_capture.py + tests/test_stream_image_routing.py), all green, with independently-computed golden vectors (line CRC 0xA25E, RAW10 8-px hand vector). Full software suite (drip-scan + pipeline + shim): 271 passed, 30 skipped.

Cross-repo / matched set

Depends on the sensor-fw companion (OW_CAMERA_IMAGE_MODE + 2408-B line forwarding) and camera-fpga#8 (register map v2, already sim-complete + Diamond-built). Wire format, CRC, and register semantics were cross-checked against the FPGA RTL and the sensor-fw plan during review. HIL acceptance (bit-exact test-pattern sweep, laser-synced single-exposure frame, histogram-suite regression after a sweep session) runs once all three land on their next branches.

Refs #167

🤖 Generated with Claude Code

boringethan and others added 12 commits July 19, 2026 23:44
…4) (#167)

Review found the design spec's VTS-4 production tc_r differs from the shipped firmware value (0x0000). Restore profile pins the real value; sweep tc_r=VTS-4 flagged as a bench-validation item. Refs #167
…bleSyncOut, verified timing values (#167)

First HIL campaign findings: (1) console-fw validates TriggerFrequencyHz to 1.00-100.00 Hz and boots with EnableSyncOut=false - capture_full_frames now forces SyncOut on and SWEEP_FSIN_HZ=1.0, with HTS retuned 38400->36000 so the 0.987 s frame fits the 1.000 s period; (2) reverted the tc_r/0x3882 'sync point' writes - bench-disproven (0x3881-83 is max_expo_a per datasheet A-18; production runs auto-tc_r). Frame cadence at stretched timing remains open (documented in the profile docstring): trigger_mod streaming mode stops framing when VTS changes; datasheet 3.7 snapshot mode produces correct slow frames but gaps the MIPI clock, resetting the camera FPGA (PLL-loss observed on STATUS bit0) and disarming the sweep after one pushed line. Transport itself is hardware-proven (smoke test: 100+ CRC-clean lines; snapshot: 1 perfect line parsed+assembled end-to-end). Refs #167
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant