Most remote visual IoT projects default to 24/7 video streaming — and then struggle to keep their solar panels large enough. The better architecture starts with the output you actually need: structured event data, periodic images, or on-demand video. This guide walks through how to choose the right power budget, connectivity protocol, and CamThink hardware (NE101 or NE301) for off-grid deployments from ski resorts to oilfields to island water systems.
The most common mistake in off-grid visual IoT design is sizing the solar panel first. The correct sequence is the reverse: define the output your application actually needs, then calculate the power budget that supports it. Solar becomes a constraint that shapes everything else — capture frequency, connectivity choice, whether AI runs on-device or in the cloud, and how often you’ll need to visit the site.
There are four fundamentally different output types, and each has a different power profile:
| Output Type | Examples | Typical Avg. Power | Best Hardware |
|---|---|---|---|
| Structured event data | People/vehicle counts, intrusion alerts, meter readings via MQTT/HTTP JSON | <50 mW avg. | NE301 + Edge AI |
| Event-triggered image | PIR/radar wake, capture one JPEG, upload and sleep | 5–20 mW avg. | NE101 or NE301 |
| Periodic/timed image | Every 5–60 min snapshot, remote inspection, meter reading photo | 1–15 mW avg. | NE101 (best for low freq.) |
| Continuous video stream | RTMP/RTSP to cloud VMS, live construction monitoring | 2–5 W avg. | Requires independent power budget |
| Average power figures are indicative; actual values depend on resolution, transmission protocol, and environmental conditions. Source: CamThink field measurements. | |||
Don’t default to 24/7 video streaming for remote deployments. Most outdoor monitoring use cases — people counting, vehicle detection, intrusion alerts, meter reading — need only structured data or periodic images. Switching from RTMP to on-device AI + MQTT reduces average power draw by 40–100×, making solar viable without a 100W panel.
Figure 1 — Output types vs. power profiles
Solar power is not just a convenient alternative to mains electricity — it fundamentally changes the system design. At CamThink, we’ve tested a 10W solar panel + 7 Ah battery combination with the NE301 running Cat.1 LTE at 1-minute capture intervals. In good sunlight conditions, this configuration maintains a positive energy balance — the panel replenishes more than the device consumes across a full day.
However, solar introduces three engineering constraints that must be handled explicitly:
The NE101 running on 4×AA batteries at one capture per hour lasts 3+ years. Solar makes sense when capture frequency exceeds roughly once every 10–15 minutes (Cat.1) or once every 30 minutes (Wi-Fi), or when the deployment is in an area where battery replacement visits are expensive. Below those thresholds, AA is often the simpler and more cost-effective choice.
The canonical architecture for a solar-powered edge AI deployment has five layers. Each layer has options, and the correct choice depends on your output type (Section 1) and deployment environment.
For multi-node deployments on islands, farms, or mountain sites, the gateway layer is often replaced by a Wi-Fi HaLow access point that aggregates 10–30 NE101 or NE301 nodes within a 1 km+ radius, then backhauls via a single 4G/5G SIM — significantly reducing per-device data costs.
NE101 and NE301 serve different roles in off-grid deployments. The decision is not about price — it’s about whether the AI inference needs to run on the device, and how much compute the capture-to-output loop requires.
| Dimension | NE301 (On-Device AI) | NE101 (Low-Power Image) |
|---|---|---|
| Processor | STM32N6 + Neural-ART NPU · 0.6 TOPS | ESP32-S3 · 8 MB RAM · no NPU |
| Deep-sleep current | 6.1 µA | ~7 µA (similar) |
| AI inference on device | Yes — YOLOv8, person/vehicle/object | No — image capture only |
| Output format | MQTT JSON (counts, bounding boxes, events) | JPEG image upload (MQTT/HTTP) |
| Connectivity options | Wi-Fi 6, 4G Cat.1 (optional), PoE (optional), Wi-Fi HaLow (optional) | Wi-Fi, 4G Cat.1 (optional), Wi-Fi HaLow (optional) |
| Wi-Fi HaLow support | Yes — 868/915 MHz, 1 km+ range | Yes — 868/915 MHz, 1 km+ range |
| Image resolution | 4 MP | 5 MP |
| IP rating | IP67 | IP67 |
| Operating temperature | −20°C ~ 50°C | −20°C ~ 50°C |
| Price range | $199.90 – $258.00 | $69.90 – $112.00 |
| Best solar use case | People/vehicle counting, intrusion, meter AI reading | Periodic snapshot, event trigger, HaLow multi-node mesh |
| Source: CamThink product specifications. Connectivity modules are plug-in and interchangeable on both platforms. | ||
Figure 2 — NE301 and NE101 outdoor pole mounts
Connectivity choice is the second-most important design decision after output type. The wrong choice is the leading cause of solar system oversizing — a Cat.1 radio transmitting continuously can draw 10× more power than Wi-Fi HaLow at equivalent data rates.
| Dimension | Wi-Fi (2.4/5 GHz) | LTE Cat.1 / 4G | Wi-Fi HaLow (802.11ah) |
|---|---|---|---|
| Typical TX current | 150–300 mA peak | 400–700 mA peak | 50–100 mA peak |
| Range (outdoor LoS) | 50–150 m | Coverage-dependent | 500 m – 1 km+ |
| Recurring SIM cost | None | $0.50–$5/device/month | None (no SIM) |
| No infrastructure needed | Needs nearby AP | Yes — cellular coverage only | Needs HaLow AP (gateway) |
| Best for | Urban/campus sites with Wi-Fi coverage | Truly remote single-node deployments | Multi-node rural/island/farm |
| Available on NE101 | ✓ Standard | ✓ Optional module | ✓ Optional module (868/915 MHz) |
| Available on NE301 | ✓ Standard (Wi-Fi 6) | ✓ Optional module | ✓ Optional module |
| Wi-Fi HaLow field characterization at 915 MHz showing 1 km+ range at sub-100 mW TX power. Source: CamThink lab testing; see also arXiv: Wi-Fi HaLow field characterization (2026). | |||
The practical rule: use Wi-Fi where coverage exists, Cat.1 for truly isolated single nodes, and Wi-Fi HaLow where you’re deploying 5+ nodes in a campus, island, farm, or mountain cluster and want to avoid SIM fees and reduce battery/solar requirements simultaneously.
Deploying 10+ nodes on a remote site and want to cut SIM costs with Wi‑Fi HaLow? Wi‑Fi HaLow modules cover 1+ km and can run on the same solar/battery budget as the base unit.
Architecture decisions are clearer in context. The following seven scenarios cover the most common off-grid visual AI deployments and the recommended combination of hardware, connectivity, and data output for each.
NE301 + Cat.1 + solar. PIR/radar wake on motion, output JSON person/vehicle counts to NeoMind or IoT platform. Cold-weather battery: size for −20°C derating. No streaming needed — counts update every 1–5 min via MQTT.
NE301 + Cat.1 + solar + PIR/radar dual-trigger. Edge AI filters wildlife from human intrusion before sending alert. MQTT JSON payload to SCADA or security platform. Solar sizing: 10W panel + 30 Ah buffer for 5-day autonomy.
NE301 + Wi-Fi or Cat.1 + solar. No video stream required — only direction-aware counts over HTTP JSON or MQTT. Integrates directly with municipal IoT platforms via standard protocols. Suitable for bus stops, crosswalks, and arterial intersections.
NE101 × N nodes + Wi-Fi HaLow AP + single 4G gateway + solar on each node. Avoids per-device SIM fees. NE101 uploads images to gateway, which batches and forwards via 4G. Avoid continuous video — HaLow bandwidth is optimized for burst data, not streaming.
NE101 (timed capture, low-cost) or NE301 (on-device OCR AI) depending on whether reading accuracy needs to be computed at the edge or server-side. NE101 + solar: capture once per hour, upload JPEG, AA battery suffices for <6 captures/day.
NE301 + Cat.1 + solar for AI safety alerts (hard hat detection, zone intrusion). NE101 for periodic timelapse images. Video stream only when justified by independent solar + battery budget — RTMP at 720p draws ~3–4 W continuously.
NE101 + Wi-Fi HaLow + solar. Event-triggered by PIR/radar for wildlife detection or periodic capture for crop inspection. Images uploaded to server-side AI for species recognition or phenology tracking. 4×AA battery viable for <10 captures/day.
NE301 + Wi-Fi + solar for initial PoC. Deploy people-counting or object-detection model via Web UI in under 2 hours. Validate MQTT JSON output against target platform before scaling to Cat.1 or HaLow multi-node. NE301 price from $199.90.
Figure 3 — Deployment scenario collage
Never purchase solar hardware before completing this checklist. Undersizing causes system failures; oversizing wastes budget and adds mounting complexity.
| Checklist Item | Details / Why it matters |
|---|---|
| Capture frequency | How many times per hour the device wakes, processes, and transmits. Higher frequency increases energy use and requires a larger panel/battery. |
| Transmission mode | Wi‑Fi, Cat.1, or HaLow — Cat.1 peak current is typically 2–4× higher than HaLow; choose radio based on range vs. power tradeoffs. |
| Upload payload size | JSON event (≤1 KB) vs. JPEG (50–300 KB) vs. video (1–10 MB). Larger payloads mean longer TX time and more energy per capture. |
| Peak battery draw | Estimate peak current during transmission (e.g., Cat.1: 400–700 mA; Wi‑Fi: 150–300 mA). Verify battery discharge capability matches peaks. |
| Local solar irradiance | Use site-specific peak sun hours (PSH). Example: Europe 3–5 PSH/day; Middle East/Australia 5–7; high-latitude winters 1–2 PSH/day. |
| Consecutive overcast buffer | Size battery for a minimum of 3 days autonomy at average power draw to survive multi-day overcast periods. |
| Temperature derating | Derate lithium battery capacity by ~20–40% below 0°C; cold climates need larger buffer or LiFePO4 for better low-temp performance. |
| Panel angle and tilt | Tilt fixed panels near the site’s latitude to maximize yield; flat mounts can lose ~15–25% of rated output. |
| Shading analysis | Check for shadows at solar noon in winter — even 10% shading can cause disproportionate power loss due to cell-string effects. |
| Maintenance cycle target | For 12-month maintenance-free goals, size system for ~7-day autonomy to tolerate extended overcast and maintenance delays. |
| Safety margin | Apply a 1.25–1.5× safety factor to panel size for aging, dust, and connector losses. |
NE301 + Cat.1 at 1-minute capture intervals: 10W solar panel + 7 Ah LiFePO4 battery maintains positive energy balance at 4+ PSH/day. For 5-day autonomy buffer or winter at < 3 PSH, upgrade to 20W panel + 20 Ah battery. This is the minimum viable solar kit for always-on edge AI at Cat.1.
Hardware selection is step one. A successful deployment requires the right accessories, integration resources, and support structure. Here’s what the CamThink ecosystem provides at each stage.
Solar panel, LiFePO4 battery, charge controller, pole/wall mount bracket, cable glands. CamThink wiki provides a validated BOM for 10W and 20W configurations.
Deploy a YOLOv8 model via the NE301 Web UI in under 2 hours — no command line required. Custom model weights (PyTorch/ONNX) can be converted and uploaded directly. See the NE301 Verified Models.
NE301 outputs structured JSON via MQTT or HTTP webhook. The payload includes timestamp, device ID, detected object types, counts, and bounding box coordinates. Connect directly to AWS IoT, Azure IoT Hub, NeoMind, or any MQTT broker.
Both NE101 and NE301 support OTA firmware updates and remote configuration changes. For solar-deployed units with no local access, all configuration changes happen over-the-air — no site visit required for firmware or model updates.
CamThink supports OEM/ODM customization, custom model training, and hardware modification for production-scale deployments. Contact the team for pilot-to-production guidance on deployments of 50+ units.
Ready to start a pilot? Talk to our team about your site, output requirements, and solar budget.
Talk to an ExpertUse this table to make the final hardware and architecture decision before ordering. Each row maps a deployment requirement to the recommended configuration.
| If your primary need is… | Use this | Key config |
|---|---|---|
| People/vehicle/object counting with JSON output | NE301 + Cat.1 or Wi-Fi | YOLOv8 on-device → MQTT JSON → IoT platform |
| Intrusion detection with low false alarms | NE301 + Cat.1 + PIR/radar | Dual-trigger wake → edge AI filter → MQTT alert |
| Periodic image capture or meter reading (server-side AI) | NE101 + Wi-Fi or Cat.1 | Timed wake → JPEG upload → MQTT/HTTP |
| Multi-node (10–30 cameras) without per-device SIM fees | NE101 + Wi-Fi HaLow + gateway | HaLow mesh → single 4G backhaul gateway |
| On-device meter reading AI (OCR) | NE301 + Wi-Fi or Cat.1 | Custom OCR model → structured reading output |
| Continuous video stream (justified) | NE301 + dedicated solar kit | RTMP/RTSP → requires a dedicated solar budget; recommend 20W panel + 20Ah battery for extended autonomy (increase capacity for continuous high‑bitrate streaming) |
| Long-range single-node with no cellular signal | NE101 + Wi‑Fi HaLow + distant AP | Up to ~1 km+ LoS (actual range depends on region, antenna, and environment); no SIM required |
| All configurations assume solar + lithium battery power supply. AA battery remains viable for NE101 at <6 captures/day. | ||
Yes, with proper battery sizing. A 10W panel in a 3-PSH/day winter location (Northern Europe, Canada) generates roughly 30 Wh/day. If your NE301 at 1-minute capture draws an average operating current of 70 mA (≈0.35 W at 5 V), daily consumption is ~8.4 Wh — still within the solar budget. For continuous overcast periods of 3–5 days, you need a battery buffer of 36–60 Wh (roughly 20 Ah at 12V). For cold climates, use LiFePO4 chemistry, which derate less than Li-ion at low temperatures.
Yes. The NE101 with Wi-Fi HaLow can communicate with a gateway up to 1 km+ away over 868/915 MHz — no SIM or local Wi-Fi required. The gateway can then connect via a single 4G SIM. The NE301 also supports Wi-Fi HaLow with the same long-range, low-power module, so it can join the same multi-node off-grid architecture while still running inference locally.
CamThink’s validated configuration is a 10W solar panel + 7 Ah LiFePO4 battery for regions with 4+ PSH/day (Southern Europe, US South, Middle East, Australia). For Northern Europe or winter in high-latitude regions, upgrade to 20W + 20 Ah. For NE101 at 1-capture/hour via Wi-Fi, a 5W panel + 5 Ah battery is typically sufficient in most regions.
Yes — this is the primary use case for the NE301. The device runs a YOLO-based detection model locally, counts objects frame-by-frame, and outputs aggregated JSON results (person count, vehicle count, direction, timestamp) via MQTT or HTTP. No video is transmitted unless you explicitly enable an RTSP stream. This approach reduces bandwidth by 99%+ compared to video streaming and is fully compatible with solar/battery power budgets.
Use a dual-trigger strategy: a PIR or radar sensor wakes the device from deep sleep (6.1 µA), and the edge AI model runs a single-frame inference to confirm the detection before sending an alert. This filters out tree movement, animals, and lighting changes before any network transmission occurs. The NE301 supports 9 sensor types as trigger inputs. For oilfield or perimeter monitoring, the radar sensor is more reliable than PIR in hot environments where thermal contrast is low.
It depends on node count and infrastructure. 4G/Cat.1 is better for truly isolated single nodes where there’s no existing AP infrastructure — it works anywhere cellular coverage exists. Wi-Fi HaLow is better for multi-node deployments (5+ cameras) where a shared gateway can aggregate traffic — it eliminates per-device SIM fees, reduces peak TX current by 2–4×, and extends range to 1–3 km. For a 20-node island deployment, HaLow can save $50–$100/month in SIM costs alone, paying back the gateway hardware cost in 3–6 months.
Yes. Both NE101 and NE301 have fully open-source firmware and drivers available at github.com/CamThink-AI. CamThink supports OEM/ODM customization for production-scale projects — including hardware modifications, custom enclosures, pre-loaded models, and white-label firmware. Contact the team for projects involving 50+ units.
Because the NE301 runs AI inference on-device and outputs only structured data (counts, events, coordinates) — not video or images by default — it is well-positioned for GDPR-compliant people-counting deployments where image transmission would require consent. All processing happens locally; no video frame needs to leave the device. For deployments in public spaces, consult local regulations, but on-device-only inference significantly reduces the compliance surface area compared to cloud-streaming systems.
