HaLowLink ViewSense
Visual Sensor

The design collapses a conventional camera node — image sensor + ISP/host MCU + Wi-Fi module — into two active ICs. The Himax HM0360-MWA (the monochrome variant) "Always-on Sensing" (AoS) image sensor runs continuously in its AoS monitor mode at a datasheet-typical 240 µA, performing on-chip motion and zone detection at a low internal monitoring resolution. The Morse Micro MM8108 Wi-Fi HaLow SoC runs the entire application hostless on its on-chip CPU — there is no separate host microcontroller. Between events the MM8108 stays associated to the access point in a low-DTIM beacon-tracking standby, woken only when the HM0360 asserts its interrupt. note All MM8108 currents in this document are placeholders to be confirmed against the Morse Micro datasheet/SDK — no MM8108 datasheet was available at authoring time; the HM0360 figures are from its datasheet (Preliminary v04).

This yields the platform's core thesis in silicon: a single physical device that is a software-defined sensor — the same captured frame is analysed in the cloud/edge AI pipeline to produce counts, readings, statuses and detections, with new "sensors" added by software, not hardware.

The defining constraint is that the MM8108 has no parallel-DVP or MIPI-CSI-2 camera receiver. The frame is therefore moved from sensor to SoC over a serial path (the HM0360's 1-/4-bit serial output captured on the SoC's SPI), with an external line-buffer FIFO as the de-risking fallback. The second defining constraint is energy. The sensor is monochrome 8-bit, so an uncompressed active VGA frame is 640 × 480 × 1 byte = 307,200 B ≈ 300 KB (a colour RGB sensor would be ~3× that, ~900 KB — but this is the mono part). Per the planned data flow, that RAW frame is read into the MM8108 and then JPEG-encoded on the SoC before transmit, so both the serial read of the raw frame and the compressed transmit contribute to the per-event cost; resolution, the read interface width, and event rate are the primary levers on battery life.

How the image is serialised — I²C is not the data path

The HM0360 exposes the I²C/SCCB bus purely for register access — set mode, ROI, exposure, framing, read status (per the Himax datasheet). It is far too slow (≤1 Mbps) to carry pixels. The bulk image leaves the sensor on its dedicated output bus, and there are three candidate ways to clock it into a SoC that has no DVP/MIPI-CSI receiver:

• (A) Serial-over-SPI/SDIO, sensor-clocked. The HM0360 is the timing master: it drives PCLKO as the bit/byte clock and presents pixels on its data lines while FVLD/HVLD mark frame/line boundaries. The MM8108 must act as a clock-slave serial receiver with DMA — sampling the data bus on PCLKO edges straight into SRAM with no CPU per-byte. This is exactly the capability that gates the design (R-01): an SPI/SDIO peripheral that ingests an externally-clocked stream hostlessly. The HM0360 supports 1-/4-/8-bit serial output; the read time of the 300 KB mono VGA frame is set by this width and the PCLKO rate — ~307 ms at 1-bit/8 MHz, ~77 ms at 4-bit/8 MHz, ~26 ms at 4-bit/24 MHz — so 4-bit is strongly preferred. Note: the MM8108's SPI master interface (used to clock the frame in) has only been bring-up-tested to date — see R-01.
• (B) FIFO-decoupled (fallback). The sensor writes its 8-bit parallel output into an AL422B line FIFO at its own pixel rate; the SoC then clocks the FIFO read port (RCK/RE) at its convenience over SPI/SDIO. This removes the clock-slave requirement entirely — the SoC is always the master — at the cost of one IC and ~5 nets. Guaranteed to work; the safe production path if (A) fails.
• (C) JPEG-at-source camera (Plan-C). A module with on-sensor JPEG + SPI (e.g. ArduCAM) hands the SoC a small compressed buffer over plain SPI — trivial to ingest, but adds a redundant camera-side MCU and cost. Prototyping stepping-stone.

Note the MM8108's own hardware JPEG encoder (§7+) acts on the frame after it is in SRAM — so path (A)/(B) still pay the full raw read off the sensor; JPEG only shrinks the transmit. That is why the serial read, not the TX, dominates the VGA active time.

Energy budget. 4× AA Energizer L91 ≈ 3000 mAh/cell × 6 V (4-series) = 18 Wh nominal → ~16.2 Wh usable at ~90% buck efficiency ≈ 4,900 mAh referred to the 3.3 V rail. (A flat 3000 mAh-at-rail assumption — ignoring the boost from the 6 V stack — is more pessimistic and shortens every figure below by ~38%.)

What each term costs (explicit, datasheet where available):

• HM0360 AoS monitor: 240 µA continuous (datasheet typ., AoS monitor mode — internally a QQVGA/2 FPS class monitor, not VGA). VGA 60 FPS readout is 7.8 mA but only during the read window.
• MM8108 DTIM standby + JPEG-encode + TX: all TBC — no MM8108 datasheet was available, so these use placeholder values (DTIM ~100 µA, TX ~149 mA at MCS7/8 MHz, encode time small). Treat MM8108 numbers as estimates pending datasheet/SDK measurement.
• Serial read of the 300 KB mono frame is set by the interface width, not I²C: 1-bit @ 8 MHz PCLKO ≈ 307 ms; 4-bit ≈ 77 ms; 4-bit @ 24 MHz ≈ 26 ms. (I²C at its 1 MHz max would take 2.5 s — which is exactly why I²C is register-control only, never the pixel path; see §5.)
• HaLow TX of the JPEG (~35 KB @ MCS7, ~26 Mb/s usable) ≈ 11 ms; the uncompressed 300 KB RAW would be ~95 ms — the reason for encoding before transmit.

• Resolution sets the band; it costs twice. A higher resolution costs more to read off the sensor (serial time) and more to transmit. That is why VGA tops out near ~0.7 yr while QQVGA reaches ~1.5 yr — and why on-chip JPEG (transmit-only saving) helps VGA less than the raw-size gap suggests.
• JPEG is the within-resolution lever. At any resolution, on-chip JPEG roughly halves the transmit term — the single biggest win once read-out is paid for (Section 7+).
• Interval trades coverage for life. Doubling the interval ≈ doubles life but halves temporal coverage; shrinking the frame does not. Off-hours slow-down is "free" life.
• Event rate is the wildcard. A continuously-triggering scene collapses to the "busy" row of its tab. Scene-change gating (Section 7+) is the mitigation — it pulls a busy scene back toward the quiet budget.
• The floor caps every tab. All resolutions asymptote to the ~0.27 mA AoS+DTIM floor (~2.1 yr ceiling). Beating multi-year needs reducing that floor (periodic AoS sampling), not finer tuning of frame size.

① MM8108 native JPEG encode — capture VGA, ship ~35 KB

The MM8108 includes a hardware JPEG encoder. The data path becomes: HM0360 captures 300 KB VGA RAW → MM8108 JPEG-encodes on-chip → transmit ~35 KB. This is materially better than transmitting RAW, because transmit energy scales with bytes-on-air and a JPEG is ~8–9× smaller. Critically, it decouples image resolution from radio energy: you can keep full VGA detail and still pay a 35 KB transmit cost.

② Suppressing uninteresting frames — two layers, and how they fit a 1-frame/15 s cadence

The question "how does motion detection help if we only capture every 15 s?" resolves once you separate two distinct mechanisms operating at different layers:

• HM0360 AoS hardware monitor (continuous, ~0.24 mA): this is not tied to the 15 s capture cadence. It watches the scene continuously at low resolution in dedicated silicon and asserts INT the moment motion/zone activity occurs. Its job is to decide whether the 15 s "wake and capture" should happen at all — in a genuinely static scene (locked room at night), it simply never fires, and the expensive capture+encode+TX cycle is skipped entirely. The camera still parks at the AoS floor.
• MM8108 "meaningful scene change" gate (per captured frame): when a frame is captured, the SoC compares it to a retained reference frame (a small downscaled/feature signature of the last transmitted scene). If the new frame is substantially the same — same empty aisle, same parked car — it is encoded but not transmitted, or only a "no-change heartbeat" is sent. Only a frame that differs meaningfully spends the radio.

So at the platform's nominal cadence, a tick proceeds: AoS gate (is anything moving?) → capture → scene-change gate (is this frame different from the reference?) → encode + transmit only if yes. Each layer removes a different class of waste — AoS removes capturing a dead scene; the scene-change gate removes transmitting a captured-but-unchanged scene.

Energy guards in firmware: every active state is time-bounded — a failed capture or stalled TX must fall back to PARK rather than burn TX current indefinitely. Re-association is rate-limited. On repeated link failure the device backs off to a longer DTIM and retries, never busy-looping.

The device opens a HaLow socket and publishes each frame over MQTT to the topic site/{siteId}/camera/{deviceId}/frame — the same path real and simulated cameras use. The AI pipeline then analyses the frame into counts, readings, statuses and detections; the device itself ships only pixels, never runs AI.

Maintaining a secured MQTT connection to the cloud

The link to the platform must be mutually-authenticated and encrypted, and that has to survive the device sleeping for most of its life. The model:

• Transport: MQTT over TLS 1.3 (MQTTS, port 8883) to the broker. The device holds a per-device X.509 client certificate + private key (provisioned at the CM, stored in the QSPI flash under the SoC's flash-encryption — §4 U8, risk R-14); the broker authenticates the cert, the device pins the broker CA. No shared/global credential.
• Wi-Fi link: WPA3-SAE on the HaLow association, held across DTIM standby so the device stays joined without a full re-auth per wake.
• Session survival across sleep — the real design choice. A full TLS 1.3 handshake from cold is expensive (multiple RTTs + asymmetric crypto) and, on a battery device that wakes every 15 s, doing it per frame would dominate the energy budget. Two viable patterns, both TBC against the MM8108 stack: (a) keep the TCP+TLS session and MQTT keep-alive alive through DTIM standby (the SoC stays associated; the broker keep-alive must exceed the capture interval) — lowest per-frame cost, but the broker holds N sockets open; or (b) TLS session resumption (PSK / session tickets, 0-RTT) so each reconnect skips the asymmetric handshake. Whichever is chosen, the handshake/keep-alive energy must be measured and added to the per-event budget in §6 — it is currently folded into the "wake + re-assoc" placeholder and is one of the larger TBC unknowns.
• At-rest secrets: the cert/key never leave the encrypted flash region in plaintext; secure-boot prevents a tampered image from exfiltrating them (R-14).

Adaptive capture cadence

The platform's normal rate is 1 frame every 15 s per camera. The sensor mirrors the platform model: it speeds up when the HM0360 reports meaningful scene change (more frequent INT → shorter interval, the "busy" budget row) and slows down in off-hours (longer interval, the ~1.7 yr row). "Meaningful scene change" detection at the sensor — sending only when the scene actually changes — is the on-device complement to the platform's coalescing and keeps the average event rate, and therefore battery life, well inside the modelled band.

Recommended next steps — phased plan