• Existing camera
• Existing display
• Existing speaker
• Existing microphone(s)
• Existing motors/body board if practical
• Existing sensors/encoders where possible
• Existing battery/charging system where safe

1. Head / brain board
   • Qualcomm APQ8009 Linux-class processor.
   • Likely handles camera, display, audio, Wi-Fi, higher-level behavior, and communication to the body board.
2. Body board
   • STM32F030C8T6TR microcontroller.
   • About 2.8 V logic.
   • Handles motors, encoders, charger, battery, proximity/IR sensors, and body real-time control.

• Avoids redesigning motor drivers and charging circuitry immediately.
• Keeps the dangerous/high-current control on known hardware.
• Lets the new brain focus on camera/audio/display/network/AI behavior.
• Lower risk than replacing every board.

• Head-to-body UART/protocol.
• Head-board connector pinout.
• Camera interface.
• Display interface.
• Audio/mic/speaker interface.
• Power rails available from battery/body board.

• Measure signals safely.
• Capture UART/I2C/SPI/MIPI/audio lines.
• Confirm voltages.
• Avoid destroying original boards.

• New motor drivers.
• Encoder inputs.
• Charger/power-path design.
• Battery safety design.
• Sensor interfaces.
• Linux compute module or high-end MCU/SBC.
• Mechanical board match.

• Linux-capable.
• Good camera/display/audio ecosystem.
• Claude Code can target Python/C++/ROS/Linux easily.
• Strong community support.

• Physically large.
• Power hungry.
• May be difficult to fit inside Vector.

• Small, Linux-capable.
• Easier than CM4/CM5.
• Wi-Fi built in.

• Limited camera/display lanes.
• Less powerful.
• May still struggle with real-time audio/video.

• Smaller SOM options may fit better.
• Some include camera/display interfaces.

• More integration risk.
• Less beginner-friendly.

• Better than ESP32-C3 for camera/audio experiments.
• Small and cheap.

• Still not a true Linux smart brain.
• Not ideal for reusing Vector’s existing display/camera if they are MIPI/parallel interfaces.

• Helper MCU
• UART bridge
• Wi-Fi telemetry/debug tool
• Not the main brain board

• Camera module part number.
• Connector pin count/pitch.
• Interface type: MIPI CSI-2, parallel DVP, USB, or proprietary.
• Required power rails.
• I2C control bus address.
• Clock requirements.

• If it is MIPI CSI-2, the replacement brain must support compatible CSI lanes and camera driver work.

• Display panel part number.
• Connector pin count/pitch.
• Interface: MIPI DSI, SPI, RGB parallel, or other.
• Backlight power requirements.
• Touch interface if any.

• Reusing the original display may require Linux kernel/display driver work.

• Number of microphones.
• Analog, PDM, I2S/TDM, or Qualcomm-specific codec path.
• Bias/power requirements.
• Whether microphones connect directly to APQ8009/codec/PMIC.

• Speaker impedance.
• Existing amplifier part number.
• Whether the amp is on the head board or separate.
• Interface to amp: analog, I2S, PWM, or codec output.

• Connector pinout between head and body.
• UART baud rate and voltage.
• Message protocol.
• Boot/reset/enable lines.
• Power-good or wake lines.

• BODY_TX
• BODY_RX
• TXD
• RXD
• SCL2
• SDA2
• VBAT
• BAT+
• BAT-
• GND
• USB D+
• USB D-

Text
You are helping me reverse engineer and potentially replace the brain board in an Anki / Digital Dream Labs Vector Robot 2.0.

I do NOT want an Ollama chatbot-only solution. I want a real hardware/software integration plan and codebase for using a smarter onboard brain board while reusing Vector's existing hardware where possible: camera, display, speaker, microphones, body board, motors, encoders, sensors, battery, and charger.

Known facts:
- Vector appears to have a Qualcomm APQ8009 head/brain board.
- Vector body board uses STM32F030C8T6TR at approximately 2.8 V logic.
- Body board likely handles motors, encoders, battery/charging, IR/proximity sensors, and low-level real-time control.
- The best first hardware strategy is probably to replace or emulate the head board while keeping the original body board.
- I have ESP32-C3 chips, but they are not powerful enough to be the main brain. They may be used only as bridge/debug/helper MCUs.

Your job:
1. Create a reverse-engineering plan for the existing head board interfaces.
2. Identify what evidence is needed to reuse the original camera, display, microphones, speaker, and body board.
3. Build software tools to capture and analyze the head-to-body protocol.
4. Build a Python parser for UART/logic-analyzer captures.
5. Define a candidate replacement-brain software architecture for a Linux SBC/SOM.
6. Define how the new brain would talk to the original STM32 body board.
7. Define how to validate camera/display/audio compatibility before designing a PCB.
8. Create a repository structure for this project.
9. Write code stubs for protocol decoding, robot command abstraction, and hardware diagnostics.
10. Do not assume the original camera/display/audio can be reused until their part numbers and electrical interfaces are confirmed.
11. Do not drive motors or transmit onto the body-board bus until passive captures are decoded.
12. Respect 2.8 V logic; do not connect 3.3 V GPIO directly without level shifting or verified tolerance.

Expected output:
- A staged reverse-engineering plan.
- A requirements list for camera/display/audio/body-board integration.
- A list of candidate replacement compute modules with pros/cons.
- A repo layout.
- Python code for parsing UART captures from CSV/Saleae exports.
- Python classes for representing body-board messages.
- A diagnostic CLI skeleton.
- A hardware test checklist.
- A list of measurements/photos needed from me.

Preferred architecture:
- New Linux-capable smart brain board or dev board.
- Original STM32 body board retained initially.
- Home server or cloud LLM API can be used for heavy AI, but the robot brain should handle local camera/audio/display/body communication.

Text
vector-brain-re/
  README.md
  docs/
    hardware-notes.md
    connector-map.md
    camera-display-audio.md
    body-protocol.md
    replacement-brain-options.md
  captures/
    uart/
    i2c/
    boot/
    movement/
    charging/
  tools/
    parse_saleae_uart.py
    detect_baud.py
    packet_cluster.py
    annotate_capture.py
  vector_body/
    __init__.py
    messages.py
    protocol.py
    transport.py
    commands.py
  diagnostics/
    body_cli.py
    camera_probe.py
    audio_probe.py
    display_probe.py
  hardware/
    interposer/
    level_shifter/
  tests/
    test_protocol.py

Python
#!/usr/bin/env python3
import argparse
import csv
from dataclasses import dataclass
from pathlib import Path

@dataclass
class UartByte:
    time_s: float
    direction: str
    value: int

@dataclass
class Packet:
    direction: str
    start_time_s: float
    data: bytes


def load_saleae_uart_csv(path: Path, direction: str) -> list[UartByte]:
    rows = []
    with path.open(newline="") as f:
        reader = csv.DictReader(f)
        for row in reader:
            # Saleae exports vary. Adjust these keys after seeing real files.
            time_key = "Time [s]" if "Time [s]" in row else "Time"
            data_key = "Data" if "Data" in row else "Value"
            raw = row[data_key].strip()
            if raw.startswith("0x"):
                value = int(raw, 16)
            else:
                value = int(raw)
            rows.append(UartByte(float(row[time_key]), direction, value))
    return rows


def split_packets(bytes_in: list[UartByte], gap_s: float = 0.01) -> list[Packet]:
    if not bytes_in:
        return []
    packets = []
    current = [bytes_in[0]]
    for b in bytes_in[1:]:
        if b.time_s - current[-1].time_s > gap_s or b.direction != current[-1].direction:
            packets.append(Packet(current[0].direction, current[0].time_s, bytes(x.value for x in current)))
            current = [b]
        else:
            current.append(b)
    packets.append(Packet(current[0].direction, current[0].time_s, bytes(x.value for x in current)))
    return packets


def main():
    ap = argparse.ArgumentParser(description="Parse Vector head/body UART captures")
    ap.add_argument("--tx", type=Path, help="CSV for head-to-body or TX line")
    ap.add_argument("--rx", type=Path, help="CSV for body-to-head or RX line")
    ap.add_argument("--gap-ms", type=float, default=10.0)
    args = ap.parse_args()

    all_bytes = []
    if args.tx:
        all_bytes += load_saleae_uart_csv(args.tx, "TX")
    if args.rx:
        all_bytes += load_saleae_uart_csv(args.rx, "RX")
    all_bytes.sort(key=lambda x: x.time_s)

    packets = split_packets(all_bytes, args.gap_ms / 1000.0)
    for p in packets:
        hexdata = " ".join(f"{b:02X}" for b in p.data)
        ascii_hint = "".join(chr(b) if 32 <= b <= 126 else "." for b in p.data)
        print(f"{p.start_time_s:012.6f} {p.direction:>2} len={len(p.data):03d} {hexdata} |{ascii_hint}|")

if __name__ == "__main__":
    main()

• Linux support.
• Wi-Fi.
• UART at 2.8 V-compatible levels or level shifting.
• I2C support.
• Audio input/output support.
• Camera interface compatible with the chosen camera.
• Display interface compatible with the chosen display.
• Enough CPU/RAM for audio/video handling and API calls.
• Low enough power for Vector’s battery.
• Small enough mechanical footprint.

• Raspberry Pi Zero 2 W if space and interfaces are enough.
• Raspberry Pi CM4/CM5 if camera/display interface compatibility matters more than size.
• Other small Linux SOM only after confirming camera/display requirements.

1. Macro photos of head board both sides.
2. Macro photos of camera module markings.
3. Macro photos of display connector and display flex markings.
4. Macro photos of microphone(s) and speaker amplifier area.
5. Connector pin counts and pitch measurements.
6. Any readable part numbers on the camera, display, codec, amp, PMIC, memory, and Wi-Fi chips.
7. Logic analyzer capture of BODY_TX/BODY_RX during boot and simple movement.
8. Voltage measurements on head/body connector pins.

1. Reverse engineer the head/body interface.
2. Identify camera/display/audio electrical interfaces.
3. Prototype with a Linux dev board before making a custom brain PCB.
4. Keep the STM32 body board at first.
5. Use Claude Code to build the protocol tools and replacement-brain software stack.