The actual schematic inside this block — every part is explained below.
LED Color Sensor (three LEDs, zero sensor ICs)
Every LED is secretly a photodiode — and a wavelength-selective one. Reverse-biased,
light striking the junction generates a tiny photocurrent, and each LED responds most
strongly to light at or just below its own emission color: photons with less energy than
the bandgap simply can't excite it. Red sees red. Green sees green. Blue sees blue.
Three LEDs = a real (if humble) color fingerprint, for pennies.
D1/D2/D3 — the channels. Ordinary clear-lens LEDs, mounted backwards on purpose:
anodes to ground, cathodes toward the sense pins, so driving a pin HIGH reverse-biases
the junction. The lens that focuses light out in normal use focuses it in here.
R1/R2/R3 — 100 Ω of insurance. The sensing trick needs no resistance at all — these
exist so a firmware mistake (driving the pin low while the LED conducts) costs nothing.
No ADC, no amplifier — time is the measurement. The Mims technique: charge the
junction's few-tens-of-picofarads reverse capacitance through the pin, flip the pin to
input, and count how long the stored charge takes to leak away through photocurrent.
Bright light: microseconds to milliseconds. Darkness: whole seconds. A GPIO and a timer
do the whole job.
Honest limits. This is a fingerprint, not a colorimeter: decay times vary between
LED batches (calibrate on a white reference), ambient light adds to every channel
(difference an illuminated and a dark reading), and the spectral bands are broad. For
sorting red/green/blue objects it's surprisingly dependable; for paint-matching, buy
the sensor IC.
The checks see exactly what's real here: at DC the LEDs sit reverse-biased and dark — the
engine honestly shows no current and no glow, because the action is all in the timing
firmware on the other side of the sense pins.
Watch it explained
Exposed nets
●sense_rin · signal
●sense_gin · signal
●sense_bin · signal
●gndin · gnd
Inside this block
R1
100
protects the red LED (and your GPIO) if firmware ever drives the pin low while the LED conducts — sensing itself needs no resistance
D1
red
the red channel — reverse-biased it photo-detects red/orange light best, near its own emission wavelength. Clear-lens parts sense far better than diffused
R2
100
green channel protection, same job as R1
D2
green
the green channel — sees green and blue-green; mostly blind to red (photons below its bandgap energy can't excite it)
R3
100
blue channel protection, same job as R1
D3
blue
the blue channel — the highest bandgap, so it only responds to blue/violet; it's the pickiest and slowest-discharging of the three
Limits & gotchas
⚠physics.note 0 — An LED is a photodiode in disguise: reverse-biased, light generates a tiny photocurrent — and each LED is most sensitive to wavelengths AT OR BELOW its own emission color. Red sees red/orange, green sees green/blue-green, blue sees blue/violet. Three readings = a crude but real color fingerprint.
⚠timing.note 0 — No ADC needed: drive a sense pin HIGH to reverse-charge the LED's ~10-50 pF junction, switch the pin to input, and count how long until it reads LOW. Bright light ≈ microseconds-to-milliseconds; darkness ≈ seconds. Calibrate against a white reference — raw decay times vary wildly between LED batches.
⚠selectivity.note 0 — Clear-lens LEDs work far better than diffused (the lens is the optic). Shield from ambient or subtract an ambient-only reading; the cheap trick is to take all three readings twice — illuminated by a white LED, then dark — and difference them.
Use this block in a real design
Drop it on a canvas, wire it up, and watch the live checks — free, no card.