+++ title = “Acme Camera” description = “” date = 2026-10-13

[extra] reveal_theme = “black” reveal_transition = “slide” +++

Acme Camera

A Proposal

Product Overview

A wireless security system architecture supporting long operational life

Hardware Design

SOC + MCU

–

MCU

ultra-low power attached to motion sensors, lighting, and power control

SOC

attached to camera/storage and spends most of its time in deep sleep

–

MCU Candidates

nRF54L
nRF52840

SOC Candidates

Rockchip RV1106
Ingenic T41
Ambarella CV7

Motion

Configurable

PIR

plus

MMWave

Note: Power Efficient Setup, PIR is used to wake the SOC and then mmwave is used to determine if people are present

LED Driver

to support Infrared and Visible Spots for lighting areas for improved visibility

Environmental

Temperature
Luminosity

Power Subsystem

Battery Charge Controller & Gauge

–

What about solar?

Let’s set the expectation that any input power source provides regulated 5V, solar included

–

Solar Charge Controller

TI bq25504
e-peas AEM10941 / AEM13920:

Note: nPM1300 does not provide the MPP support for the solar cells so we need an external IC to properly do it

Software Design

Note: mcuctl sets the motion and light mode on the embedded mcu powerctl controls the power domain for the battery charger and reads the fuel gauge portalctl provides the initial configuration UI and subsequent status web portals cameractl reads frames and dispatches them to whatever has been configured configctl is the source of truth that gets configuration requests broker: mqtt, likely mosquitto infctl: inference controller for on-chip npus to load models (bonus)

Boot Plan

Note: Uses an A+B boot that only changes the boot target once we’ve booted successfully and connected to the backend

Component : Broker

MQTT

Note: on unix socket for the ability to have granular security TODO: why a unix socket over TCP (file permissions / peer credentials per component) TODO: topic layout and which components publish/subscribe

Component : MCUctl

Owns the MCU link: motion sensing and lighting

Note: Talks to MCU and sets/gets the motion detection and light settings

–

Motion

Which sensors watch for motion

enum MotionDetectionMode {
    OnlyPIR,
    PIRWakesRadar,
    OnlyRadar,
    Off
}

–

Lighting

When the visible and IR spots come on

enum LightControlMode {
    DuskDawn,
    Motion{cooldown: u32},
    Off
}

Component: Powerctl

Power modes, schedules and PMIC telemetry

Note: Collects power usage data, rundown and fuel gauge from the PMIC

–

Power Modes

Awake on detection, or on a schedule

enum PowerCtlMode {
    Detection{cooldown: u32},
    Timer{configs: Vec<TimerConfig>},
}

struct TimerConfig {
    start_time: u64,
    end_time: u64,
    schedule_days: HashSet<Weekday>
}

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
enum Weekday { M, T, W, R, F, S, U }

–

Power Readings

One sample from the PMIC

enum PowerSource { Battery, External }

struct PowerReading {
    source: PowerSource,
    timestamp: u64,
    voltage_mv: u32,
    current_ma: i32,              // + charge / - drain
    state_of_charge: Option<u8>,  // fuel gauge, %
    time_to_empty_s: Option<u32>, // rundown estimate
}

Component: Portalctl

First-boot setup, then a status portal

Note: Interactive wireless authentication and cloud configuration

–

Modes

Which portal is up, and setup progress

enum PortalMode {
    Setup { ap_ssid: String, ap_psk: String },
    Status,
    Off,
}

enum ProvisioningState {
    AwaitingCredentials,
    JoiningNetwork,
    Claiming,
    Provisioned,
    Failed { reason: String },
}

Note: Setup is a soft-AP on first boot / factory reset, Status once on the home network, Off once cloud-managed

–

Credentials

What setup collects from the user

enum WifiSecurity { Open, Wpa2Psk, Wpa3Sae }

struct WifiCredentials {
    ssid: String,
    security: WifiSecurity,
    passphrase: Option<String>,
}

struct CloudClaim {
    claim_token: String, // QR / app
    display_name: String,
}

Note: claim_token comes from a QR code or the app and is exchanged for device certs

–

Config Requests

Changes sent to configctl via the broker

enum ConfigRequest {
    Network(WifiCredentials),
    Cloud(CloudClaim),
    DisplayName(String),
}

Note: portalctl publishes these over the broker; configctl validates and applies them

–

Status Portal

The status portal’s read-only view

enum BootSlot { A, B }

struct DeviceStatus {
    display_name: String,
    firmware_slot: BootSlot,          // A+B boot
    state_of_charge: Option<u8>,      // powerctl
    motion_mode: MotionDetectionMode, // mcuctl
    cloud_connected: bool,
}

Note: Read-only view assembled from the other components via the broker

Component: Cameractl

Note: Reads frames from the camera and decides to do further processing depending on config

Component: Configctl

Note: Source of truth for various configurations set from the portal

Network configuration
Display Name
Cloud Configuration
On-Device Processing Configuration

–

Component: Infctl

Note: This one is – because it’s a bonus one that we may not get into Configures on-device inference using NPU hardware available in modern camera SOCs

Metrics

Performance given envelope configuration

leading to insights for better

Battery Life across a fleet

Instrumentation

Collection of combined environmental, fuel gauge