Overview Link to section: Overview

I designed this solar cellular wildlife-camera prototype around occasional motion events and limited energy. Motion should wake the camera, trigger a photograph, preserve the original locally, and send a smaller preview to a private gallery.

The system spans embedded firmware (software running on the camera’s electronics), a server, a browser interface, power calculations, and a printable enclosure.

The Rev E carrier and Revision A enclosure are engineering prototypes. The software and computer-aided design (CAD) exports have been checked, but a complete physical camera has not yet been assembled or field-tested.

Capture and upload lifecycle Link to section: Capture and upload lifecycle

The firmware targets the LilyGO T-SIM7080G-S3 PMU (power-management unit) board, combining an ESP32-S3 processor with a SIM7080G cellular modem, which connects to the mobile network.

  1. A motion event wakes the device.
  2. The camera captures a JPEG image and writes the original and preview to an SD memory card.
  3. The preview enters an upload queue, a list of images waiting to be sent.
  4. The device attempts an HTTPS upload (an encrypted web transfer) and checks the server’s receipt.
  5. Failed transfers remain queued for retry with backoff (waiting between attempts).
  6. Battery-aware scheduling and shutdown of unused power domains (groups of powered components) reduce activity between events.

Signed firmware updates can be delivered over the cellular connection during scheduled check-ins, with rollback to the previous valid version if the new version fails confirmation.

The local original is retained after upload. Cellular coverage should affect when the gallery receives an image, rather than whether the image survives at all.

The backend (server software) uses FastAPI, a web framework, and SQLite, a database. It stores:

  • Per-camera image histories.
  • Telemetry (device status readings).
  • Configuration versions (revisions of the camera settings).
  • Requests for full-resolution originals.

Per-camera credentials separate devices.

The Field Station browser gallery is designed for phones as well as larger screens.

Testing coverage gaps Link to section: Testing coverage gaps

A simulator exercises the event path, including periods without coverage and later reconnection. It makes queue and gallery behavior testable before taking hardware outside.

Browser notifications currently depend on leaving the gallery open. Closed-browser mobile push is outside the implemented scope.

Power estimates and cellular connection Link to section: Power estimates and cellular connection

The power model calculates how event count, upload cost, solar input, and battery capacity affect runtime.

Its default scenario estimates 0.95 Wh (watt-hours, a measure of energy) per day at 100 events. It estimates about eight days of reserve without sun, adjusted for reduced battery capacity in cold conditions.

What still needs measurement Link to section: What still needs measurement

Those figures are model outputs, not measured runtime. Weak cellular signal, frequent activity, shade, and charging being inhibited in cold conditions can change the balance substantially. Actual sleep, capture, and transmission energy still need to be measured on the assembled hardware.

LTE-M service (a cellular connection intended for low-power devices), compatible camera operation, charge-temperature protection (preventing charging at unsuitable temperatures), and night illumination also need controlled hardware checks on the workbench.

Rev E carrier Link to section: Rev E carrier

The custom Rev E printed circuit board (PCB) carries the LilyGO board on a 95 × 95 mm, two-layer carrier. A passive infrared (PIR) motion sensor and three 940 nm infrared emitters sit on the front of the board.

The carrier includes panel protection, reverse-pack blocking, and a hardware cold-charge guard that operates independently of firmware. CAD and fabrication exports have been validated, but the board has not been populated or physically fit-tested. PCBWay sponsors the project; that sponsorship does not establish hardware performance, order affordability, or readiness for deployment.

Enclosure and service access Link to section: Enclosure and service access

The mechanical design separates ten printable parts. Editable STEP geometry (a format for exchanging CAD models) and STL exports (3D-printable mesh files) are accompanied by assembly views and geometry reports.

The enclosure provides:

  • Separate camera and infrared openings (infrared is light outside the visible range).
  • A replaceable electronics carrier.
  • A battery hatch.
  • Independent tree and adjustable solar mounts.

Fitting parts and checking weather sealing Link to section: Fitting parts and checking weather sealing

Purchased components appear as dimensioned envelopes (shapes representing their size) in the CAD; module-specific supports still need to be matched to the actual parts.

The enclosure images show the Revision A CAD design. Weather sealing still needs to be tested on a physical enclosure.

Validation and next milestone Link to section: Validation and next milestone

The local backend and simulator run, the embedded firmware compiles (builds successfully into device software), and the CAD exports have been validated.

The next physical milestone is a complete bench path from motion to photograph to local storage to cellular upload to viewing.

After that, I need to measure power use, check battery and charging behavior, and test the optics and enclosure outdoors. Field reliability and actual runtime are still open questions.

The source repository is private.

FAQ

Has the camera been assembled and field-tested?

No complete physical camera has been assembled or field-tested. Software and CAD exports have been checked, and physical validation is pending.

What happens when cellular coverage is unavailable?

The firmware saves the original and preview to an SD card. Failed preview uploads remain queued for retry with backoff, and the local original is retained after upload.

Are the runtime figures measured?

No. They are power-model outputs. Actual sleep, capture, and transmission energy still need measurement on assembled hardware.

Does the gallery notify me when the browser is closed?

Current browser notifications depend on leaving the gallery open. Closed-browser mobile push is outside the implemented scope.