Battery-Powered Construction Site Security
with Edge AI: NE301 Deployment Guide

Why Construction Sites Break Standard Security Cameras

A typical construction site runs 6–18 months, relocates equipment monthly, and has no mains power at the perimeter. Standard IP cameras need power runs and Ethernet drops — both require civil works and become obstacles when the site layout changes. Solar-powered 4G cameras exist, but most consumer models run fixed cloud AI that cannot be customised. When your client's security platform uses a proprietary intrusion model trained to filter out site workers and distinguish authorised vehicles from trespassers, "fixed cloud AI" is a non-starter.

Three hard requirements define this deployment class:

• No mains power — battery or solar only, with multi-month autonomy between maintenance visits
• No fixed network — cellular (4G LTE) is the only viable uplink for remote perimeter positions
• Custom model required — the AI must be trainable on your specific intrusion classes (worker vs trespasser, authorised vehicle vs unknown)

The NE301 is the only camera in CamThink's line that handles all three simultaneously: on-device edge AI inference (0.6 TOPS STM32N6 NPU), battery operation with 6.1 µA deep sleep, and fully open firmware that accepts any YOLOv8-based TFLite INT8 model without vendor lock-in.

Hardware Specifications — What the Numbers Mean for This Scenario

The NE301 battery life figures published by CamThink are lab-measured at 25°C with standard signal strength. Construction sites are colder, windier, and often in partial cellular coverage. Here is what the official data means in practice.

The critical insight from the official battery data: at 10 PIR-triggered captures per day via LTE, battery life is approximately 1.08 years (GL912 global module). At 5 captures/day, it reaches ~2.09 years. For a 12-month construction project, 10 captures/day on LTE clears the project duration without a battery swap — if signal quality is adequate.

System Architecture

The NE301 processes each PIR-triggered event entirely on-device. The intrusion model runs inference locally, and only confirmed detections (above your configured confidence threshold) are transmitted over LTE to your alarm platform. This two-stage filter — PIR hardware gate then AI software gate — is what eliminates the false alarm volume that plagues conventional motion-triggered cameras.

The MQTT payload contains the device ID, timestamp, battery percentage, detection class, confidence score, and the captured JPEG — everything your alarm platform needs to make a dispatch decision. Because inference runs on-device before transmission, you receive structured alert data rather than raw video streams, which keeps data costs low on LTE SIM plans.

Custom Model: What "Open Firmware" Actually Means for Security Integrators

Most commercial IP cameras ship with a fixed AI model from the vendor. You can tune sensitivity, but you cannot retrain the model on your specific intrusion classes or replace the inference engine. The NE301's firmware is fully open source on GitHub, and the model slot accepts any YOLOv8-family model exported to TFLite INT8 format via the standard Ultralytics export pipeline.

What you can train and deploy

• Person detection with worker / trespasser classification — train on images of workers in hi-vis gear vs generic pedestrians. The camera distinguishes your staff from intruders based on visual features you define.
• Vehicle authorisation — train on plates or vehicle types present on your site. Unknown vehicle entering after hours triggers an alert; known delivery truck does not.
• Zone crossing — bounding box crossing a defined perimeter line (configured in the Web UI inference parameters).
• Tool / equipment presence — detect scaffolding being moved or machinery activated outside authorised hours.

Model format and constraints

The STM32N6 NPU runs TFLite INT8 quantised models at 256×256 input resolution. Larger inputs are not supported at this compute level. YOLOv8n is the recommended architecture — it fits within the memory and compute envelope and achieves 2–3 s inference per frame on-device. The official Model Training and Deployment guide covers the complete pipeline: Ultralytics training → TFLite export → STM32 quantisation → Web UI deployment. CamThink also provides an AI Tool Stack that wraps the pipeline for teams without deep ML infrastructure.

Deployment Walkthrough

Connectivity Options: When to Use LTE vs WiFi

The NE301 ships with WiFi standard. LTE Cat.1 is an add-on module. For construction sites, the choice is usually straightforward — but some edge cases exist.

MQTT Payload Reference

When configured for AI detection trigger, the NE301 publishes the following JSON payload on confirmed detection events only. Your alarm platform subscribes to the configured topic and receives this message each time the on-device model fires above the confidence threshold.

{
  "ts": 1745510400000,          // Unix timestamp, ms
  "values": {
    "devName":     "NE301-SITE-A-G01",  // Configurable device name
    "devMac":      "D8:3B:DA:5C:11:2A",
    "battery":     91,                 // Remaining battery %
    "snapType":    "AIDetect",         // PIR | AIDetect | Scheduled | Button
    "localtime":   "2026-04-24 02:17:30",
    "imageSize":   68420,              // bytes
    "image":       "data:image/jpeg;base64,..."
  }
}

The "snapType": "AIDetect" value is set when the capture was triggered by an on-device AI inference result crossing your configured threshold. This distinguishes confirmed detections from scheduled captures or manual button triggers in your platform's event log. Configure your alarm platform to dispatch only on AIDetect events — ignore PIR-only events if you want the AI to be the final gate.

Frequently Asked Questions