Embedded Systems

A sunflower follows the sun across the sky all day. Now picture a solar panel doing the same — not because it looks pretty, but because a panel pointed straight at the sun gathers roughly 40% more energy than one bolted flat to a roof. The question is how to make a £5 microcontroller do this without GPS, without an astronomical clock, and without knowing what time it is. The answer is wonderfully cheap: bolt two tiny light sensors to the panel, one on each side, and let them argue.

The sensors are LDRs — light-dependent resistors. Each one returns a number that grows when more light hits it. Mount one on the east edge of the panel and one on the west edge, and the brighter sensor tells you which way the sun is. If east reads higher, the sun is east of straight-ahead, so nudge the panel east. If west reads higher, nudge west. Repeat forever. That is the entire algorithm, and it does not care what hour it is or what latitude you are at.

Pick the Morning east preset. The east LDR reads 900, the west reads 200. Compute the difference: $\Delta =E-W=900-200=700$\Delta = E - W = 900 - 200 = 700. Positive and large, so step east. The servo rotates by a small fixed amount — the demo uses 2° per step. After one step the panel sits 2° closer to the sun, both sensor readings shift slightly, and the next iteration recomputes from there.

Run this loop many times and the panel walks toward the sun in tiny steps. Early on the difference is huge, the algorithm steps every iteration, and the panel sweeps quickly. As the panel aligns, the east and west readings converge — the difference shrinks toward zero. Eventually the sensors disagree so little that stepping further would overshoot. That is when the controller should stop, not because it ran out of power, but because there is nothing useful left to do.

That “stop when it is close enough” rule is the deadband. Concretely: $|\Delta |\le d\Rightarrow \text{hold}$|\Delta| \le d \;\Rightarrow\; \text{hold}. With deadband $d=5$d = 5, the Noon balanced preset (E=600, W=600, $\Delta =0$\Delta = 0) holds — obvious. But the Slightly east preset (E=505, W=500, $\Delta =5$\Delta = 5) also holds, because 5 is right at the threshold. Without a deadband the panel would jitter east-west all day chasing one-unit sensor noise, draining the battery and grinding the servo for no measurable energy gain.

The full decision rule is just three branches:

Two sensor reads, a subtraction, two comparisons, and a servo write. The whole microcontroller program is maybe twenty lines of C. No PID loop, no Kalman filter, no astronomical model — and yet a real garden-lamp tracker uses exactly this.

Two more knobs keep it well-behaved in the real world. The step size — 2° per iteration in the demo — sets how aggressively the panel chases the sun; smaller steps are smoother but slower, bigger steps overshoot and oscillate around the deadband. The angle is also clamped to $\pm 90°$\pm 90° so the panel cannot try to point at the ground when sunset confuses the sensors. The demo flags clamped steps in the angle history so you can see where the rule wanted to go versus where physics let it.

What makes this work is that the two sensors are a gradient estimate. The difference $E-W$E - W is a finite-difference approximation to the spatial derivative of brightness across the panel, and stepping in its direction is the cheapest possible gradient ascent. You are optimising without ever writing down a cost function. In control-theory language it is a bang-bang controller with a dead zone — the same family as a thermostat that clicks the boiler on at 18°C and off at 20°C.

Try it yourself.

So that is the tracker: two LDRs, a subtraction, a deadband, and a servo. The same bang-bang-with-deadband pattern recurs across the course — the traffic light FSM holds each phase until a timer or sensor fires, and the interrupt polling demo is the same “react when the signal crosses a threshold” idea pushed down into the CPU. Paired with the pwm visualiser, which is what actually drives the servo into motion, this demo is the front end of the embedded toolkit: turning a noisy analogue world into one of three discrete decisions.

You want to dim an LED, but your microcontroller pin can only output two voltages — fully on at 5 V or fully off at 0 V. There is no “2.5 V” setting in the silicon, no analogue dial, no in-between. So how do you make the LED look half as bright? The answer is one of the most useful tricks in embedded systems, and it shows up every time you set a servo angle, control a fan, or fade an indicator.

The trick is to cheat with time. Instead of trying to hold the pin at 2.5 V, flick it between 5 V and 0 V very quickly, spending half of every tick at 5 V and half at 0 V. Your eye cannot follow individual flickers above roughly 100 per second, so it sees the time-average instead. The LED looks as if it were sitting at half-brightness — even though the actual voltage is always either fully on or fully off.

Load the Motor preset: 5 V high, 0 V low, switching 1000 times a second, on for half of each cycle. The average voltage the LED feels is just $5\text{V}\times 0.5=2.5\text{V}$5\,\text{V} \times 0.5 = 2.5\,\text{V}. Drop the on-fraction to 0.25 and the average becomes $5\text{V}\times 0.25=1.25\text{V}$5\,\text{V} \times 0.25 = 1.25\,\text{V} — a dimmer LED, with no analogue circuitry anywhere. That on-fraction is the duty: the fraction of each cycle the pin is ON.

The whole thing only works because the load has inertia. An LED’s brightness, a motor’s shaft speed, a fan’s airflow — none of them can change as fast as the pin can flip. They smooth out the rapid pulses into a steady average, the same way your ear hears a tone instead of individual speaker-cone wiggles. Switch faster than the load can react, and physics does the averaging for you.

How many on/off pulses per second do you need? It depends on the load. An LED needs ~100 Hz or above so the eye stops seeing flicker. A small DC motor likes a few kHz, fast enough that the motor’s coil-inductance averages the current. A servo wants exactly 50 Hz — its electronics decode the on-time itself, not the average voltage. Go too slow and the load follows each pulse; go too fast and the switching transistor wastes energy in every transition.

For a brushed DC motor, torque is proportional to current, and current follows the average voltage across the coils. So 50% duty at 12 V gives roughly the same torque as a constant 6 V supply — but the H-bridge driver only ever sees ON or OFF, which is what a switching transistor is actually good at. That is why every cheap cordless drill, RC car, and laptop fan controls speed by PWM rather than by an analogue dimmer.

Resistive heaters break the average-voltage rule. A heater dissipates power as $V^2/R$V^2/R, which is non-linear in V, so you have to use the RMS (root-mean-square) voltage instead. For the Heater preset (12 V, 20% duty) the average is only 2.4 V, but the RMS works out to about 5.4 V — and it is the RMS that sets the heat output. Same waveform, two different “effective” voltages, picked by what the load cares about.

Try it yourself.

So that is PWM: a fake analogue output built from fast digital pulses, with the load’s own inertia doing the smoothing. The pattern recurs across the rest of the course — the solar tracker’s servo is driven by exactly the 50 Hz pulse train above, the rpm demo measures the output of a PWM-driven motor by counting encoder edges, and the interrupt vs polling demo is the same idea in reverse: reacting to a pulse train instead of generating one. Paired with the adc sampling visualiser, which turns analogue voltages back into digital numbers, PWM closes the loop between digital pin and physical world.