The Most Important Part of Our Solar Tracker Wasn’t the Code

If two LDRs sit together under nearly identical illumination, their readings may tell the controller that light exists, but they provide little evidence about which side it comes from. Adding a second sensor creates another value; it does not guarantee a useful difference between the values.

This was where the physical divider between our sensors mattered. When light arrived more strongly from one side, the divider shaded one LDR differently from the other. The geometry converted direction into contrast that the Arduino could observe as unequal readings.

I began to think of the divider as physical preprocessing. Before the program executed a comparison, the structure had already transformed an environmental property into information suitable for that comparison. Part of what I had casually called the algorithm existed in the hardware arrangement.

The Arduino could subtract or compare the two readings perfectly and still make a weak decision if both sensors responded almost identically. More conditions in the code would not create directional evidence that the physical arrangement had failed to produce.

That made sensor position, orientation, and the barrier part of the information path rather than mechanical details added after the electronics. A small physical change could alter the contrast reaching the controller and therefore change the behavior of the entire tracking loop.

The broader lesson was not that hardware is more important than software. It was that their responsibilities cannot always be separated cleanly. The structure shaped the signal, the sensors translated illumination into electrical readings, the code interpreted their difference, and the servo changed the orientation.

Our comparison included a threshold, or deadband, so small differences would not trigger unnecessary servo movement. That decision helped the system hold its position when the two readings were close instead of reacting continuously to every minor variation.

The threshold was useful only because the sensor geometry could produce meaningful differences when the light was directional. If the arrangement produced almost no contrast, a wide deadband could hide the direction completely. If ordinary variation dominated the readings, a narrow deadband could encourage repeated correction.

This connected a software parameter to a physical design choice. The threshold was not an isolated number that could be tuned without context. Its meaning depended on the input distribution created by the sensors, divider, lighting, and assembly.

It was convenient to describe mechanics, sensing, code, and actuation as separate subsystems, but the tracker exposed their dependence. The divider influenced the readings; the readings influenced the comparison; the comparison influenced the servo; and the servo changed the physical relationship between the sensors and the light.

That loop also explained why a correct line of code was not enough to guarantee useful behavior. Decision quality depended on input-information quality, and the information quality depended partly on mechanical geometry. The prototype worked because those relationships supported one another.

What stayed with me extends beyond a Solar Tracker. Whenever software must decide from physical measurements, I now want to ask what property the sensor arrangement makes observable, what ambiguity remains, and whether the inputs contain the information the algorithm assumes they contain.