A solar surveillance trailer ran three seasons at a materials yard without going dark once. Two panels on the roof, a 24V LiFePO4 bank in the box underneath, four fixed cameras on the mast.
Somebody swapped the four cameras for newer models with onboard AI detection. Same manufacturer, same PoE switch, same panels, same battery.
The trailer died on day four.
Nothing had failed. The bank was healthy, the panels were clean, the charge controller was doing exactly what it was built to do. The load had changed in a way the original sizing calculation had no way to see.
This is not an installation error. It is an arithmetic problem, and it shows up often enough to be worth walking through properly.
The numbers that stopped working
If you have specified off-grid camera systems before, you carry a few figures around.
A fixed 4MP camera running H.265 pulls 5 to 7 watts. Switch the IR illuminators on and it goes to 9 or 11. Add a small PoE switch and a cellular router and a four camera trailer sits near 35 watts by day, 50 by night.
Those numbers held up for a decade because the work behind them never moved. A traditional IP camera reads a sensor, pushes the image through a fixed function processor, and hands an encoded stream to the network. All three jobs run on dedicated silicon built to do one thing cheaply. The draw is close to flat.
A camera doing onboard detection is running a neural inference workload on top of all of that. Three properties of that workload matter for power:
It runs continuously. The camera is not waiting for a motion trigger and then thinking. It processes frames constantly, because that is how it decides whether something is a person, a vehicle, or a plastic bag.
It pulls the frame rate and resolution up with it. Detection degrades at low frame rates and small objects need pixels, so a camera that used to stream 10fps at 4MP now runs 20 or 30fps at 8MP. Sensor, encoder, and inference engine scale together.
Its draw tracks what is happening in the scene. A quiet lot at 3am and a windy lot full of moving branches produce different power numbers from the same camera on the same mount.
On the datasheet all of this shows up as one line. The camera moved from PoE Class 3 to Class 4.
Peak tells you nothing useful here
Class 3 delivers up to 12.95W at the powered device. Class 4 delivers up to 25.5W. So the number on the sheet doubled, and it is tempting to double the number in the spreadsheet and move on.
Solar sizing does not run on peak watts. It runs on watt hours per day, and the gap between peak and average is different for the two camera types.
A fixed camera with IR has a peak to average ratio around 1.2. It sits near its average nearly all the time.
A camera running continuous inference lands closer to 1.5 or 2.0, because the inference engine throttles with scene activity.
Which makes the nameplate wrong in both directions. Size from the Class 4 rating and you overbuild the array. Size from the old average and you underbuild the bank. Neither figure answers the only question that matters, which is how many watt hours the camera consumes over 24 hours in the scene it will actually live in.
The load moved into the dark
Off-grid design leans on a comfortable assumption: daytime generation covers the daytime load with surplus left over, and the battery only has to carry the night.
Now think about when a detection workload is busiest.
Security sites are quiet during business hours and active after them. Vehicles arrive at 2am. Wind, headlights, and animals trip the classifier between midnight and 5am. The IR illuminators are pulling full load through all of it.
So the heaviest consumption period sits inside the window with zero input. The night side of the budget grows faster than the day side, which means more strain per cycle even before you account for the higher daily total. A build can come out of an upgrade with a night load 30% above the day load, on a site where the two used to be nearly equal.
Weather raises demand and cuts supply at the same time
This is why trailers survive July and fail in November.
Rain, snow, fog, and blowing debris put motion into the frame. A classifier watching falling snow works considerably harder than one watching an empty gravel lot, so inference duty cycle climbs and draw climbs with it.
The same weather cuts your harvest to a fraction of clear sky output.
Demand and supply move in opposite directions, at the same time, for the same reason. Reserve calculations do not catch this because they treat load as a constant and generation as the variable. Once load correlates with cloud cover, the arithmetic under a five day autonomy figure stops holding.
Deeper cycles, shorter bank
Keep the existing battery and the system still works. It just cycles deeper every day.
LiFePO4 cycle life is tied closely to depth of discharge, and the penalty for going from 30% to 60% is not small. A bank sized for five years at shallow cycles can turn into a two or three year bank at deeper ones. The trailer keeps running, the customer stays happy, and the replacement invoice arrives years before anyone forecast it.
Same trailer, two camera generations
Same site, same 24V architecture. Only the cameras and the compute change. The figures below come from Coram’s Solar surveillance trailer builds and are a reference point rather than a spec, since every site prices out differently.
Legacy build
| Load | Day (W) | Night (W) |
|---|---|---|
| 4x fixed 4MP camera, H.265 | 24 (6 each) | 40 (10 each, IR on) |
| PoE switch | 5 | 5 |
| Cellular router | 7 | 7 |
| Total | 36 | 52 |
Twelve hours each way: 1,056 Wh per day
AI camera build
| Load | Day (W) | Night (W) |
|---|---|---|
| 4x AI camera, onboard inference | 50 (12.5 each avg) | 70 (17.5 each avg, IR on) |
| PoE+ switch | 8 | 8 |
| Cellular router | 7 | 7 |
| Total | 65 | 85 |
Twelve hours each way: 1,800 Wh per day
That is 1.7x, and it moves everything downstream. Sizing for four days of autonomy at 80% usable depth of discharge:
| Legacy | AI cameras | |
|---|---|---|
| Daily consumption | 1,056 Wh | 1,800 Wh |
| Four day reserve | 4.22 kWh | 7.20 kWh |
| Nominal bank at 80% DoD | 5.28 kWh | 9.00 kWh |
| Capacity at 24V | 220 Ah | 375 Ah |
| Array at 4.5 peak sun hours, 0.75 derate | 313 W | 533 W |
| Array at 2.5 peak sun hours, 0.75 derate | 563 W | 960 W |
The last row is the one that hurts. The winter array goes from two panels to five, on a towable chassis where you now have wind loading, mast clearance, and tongue weight to solve for. Plus a battery box that has to hold nearly twice the capacity.
The camera swap was a two hour job. The consequences reach the chassis.
The winter number is the design number
The annual average is useless here. Your system is defined by its worst month.
In the northern half of the United States that means late November into January, when peak sun hours drop to 2 or 2.5, overcast is persistent, and short days put the IR illuminators on for 15 hours instead of 12.
Run the calculation for that month, then run it again with a week of cloud on top. Survive both and the rest of the year takes care of itself.
The cold charging trap
Two things happen as temperature falls, and they work against each other.
Usable capacity drops. A LiFePO4 bank at 0C gives you noticeably less than its rating, so four days of reserve quietly becomes three.
More importantly, standard LiFePO4 cells should not be charged below freezing, and a properly built BMS will block charge current to protect them. Which means on a cold clear morning you can have a full array, bright sun, a working controller, and no charging at all. This one catches people because every indicator looks correct.
Two ways out. Add a heater, which spends watt hours from the budget you are already stretching, usually 10 to 15% of the daily total. Or specify cells rated for low temperature charging, which costs more up front and saves you the heater load and the extra failure point. On a build already carrying a much heavier load than its predecessor, the second option often works out cheaper across the deployment.
The third option nobody costs out
There is a way to add detection without touching the camera load at all: leave the low power cameras on the mast and run inference on one appliance downstream.
The trade is a fixed 24 hour load in place of a variable one spread across four cameras. Whether that wins depends entirely on what the appliance draws.
| Build | Daily Wh | Bank at 24V | Winter array |
|---|---|---|---|
| Legacy cameras, no detection | 1,056 | 220 Ah | 563 W |
| Existing cameras plus 15W appliance | 1,416 | 295 Ah | 755 W |
| Existing cameras plus 25W appliance | 1,656 | 345 Ah | 883 W |
| Four AI cameras | 1,800 | 375 Ah | 960 W |
Break even sits near 31W. An appliance drawing more than that on four channels gives back the entire advantage, so this is a calculation to run rather than an assumption to carry. On a four camera build the appliance route usually comes out ahead. The margin narrows as channel count climbs.
Four things to hold against it:
Decode cost scales with channels and resolution. The appliance has to decode every stream before it can look at it, so the advantage shrinks as the site grows. At eight or twelve cameras it can disappear.
It is a single point of failure. Lose a camera and you lose one view. Lose the appliance and you lose detection everywhere.
An older camera was not built to feed a model. Lower frame rate, weaker low light sensor, more compression artifacts. Detection quality off a five year old camera can be worse than off a purpose built one, and no amount of downstream compute fixes a noisy 10fps stream.
The appliance needs thermal headroom in a sealed enclosure. Sometimes that means a fan, which is more watts and another moving part.
Do not assume moving compute moves the power
Reasonable next question: why not send everything to the cloud and process it there?
Sometimes right, often not, and the reason is the modem.
An idle cellular modem draws very little. One sustaining a continuous uplink draws a great deal more, and the draw scales with how hard it works to hold the connection. On a remote site with two bars, transmit power alone can rival what the inference engine was consuming.
Edge processing exists partly so you can send metadata and short clips instead of a continuous stream. That is a bandwidth saving and on battery it is usually a power saving too.
Worth adding: a directional antenna aimed at the right tower is a power optimization, not just a connectivity one. Better signal means lower transmit power means fewer watt hours.
What to change
Measure, do not specify. Put the camera on a bench supply, point it at a scene with realistic activity, log watt hours across a full 24 hours. This one step catches most sizing errors.
Build two load profiles. Quiet site and busy site. Size on the busy one. The quiet one tells you your real headroom.
Model day and night as separate blocks. Do not average them, and use the hour split from your worst month.
Design depth of discharge against your service life target, not just your autonomy target. Five year bank means shallow cycles and more capacity.
Tune detection zones for power, not just for nuisance alerts. Masking a busy road at the edge of frame cuts inference duty cycle. Most people do this to reduce false alerts and never notice the power saving. It is the cheapest win available and the first thing to check on a site that is running tight.
Use MPPT. The harvest gap over PWM widens as load grows and matters most in the cold, low light conditions that define your worst month.
Budget the radio and the heater explicitly. Both get left off spreadsheets constantly, and together they can account for a fifth of daily consumption.
Two things not to do. Do not reuse the old bank because the trailer still works, since it is cycling twice as deep and will fail early. And do not add panels instead of capacity: more array helps on a sunny day and does nothing across a five day overcast stretch, because autonomy is a battery problem.
Cheat sheet
| Question | Working answer |
|---|---|
| Starting assumption for an AI camera build | 1.5x to 2x an equivalent non-AI build, then measure |
| Peak to average, fixed camera | About 1.2 |
| Peak to average, continuous inference | About 1.5 to 2.0 |
| Which month to design for | The worst one, plus a week of overcast |
| Design DoD for a five year bank | 50% or shallower |
| Cold climate heater allowance | 10 to 15% of daily watt hours |
| Centralized inference break even, four channels | Around 31W appliance draw |
| Charge controller | MPPT |
Bottom line
Going from fixed cameras to cameras with onboard detection looks like a swap. In power terms it is a different class of load: higher on average, variable with scene activity, weighted into the hours with no sun, and correlated with the weather that cuts your generation.
Somewhere between 1.5x and 2x the daily watt hours is a fair place to start. Then measure, because the multiplier for your camera in your scene is the only number that counts.
