← Block library

LED Color Sensor

@electrace/led-color-sensor@1.0.0 · CC-BY-4.0
channels 3method vsense 3–5.5 V
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.

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 0An 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 0No 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 0Clear-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.
Start designing →
This page is generated from the block's source — the same content powers the editor's explanations and live checks.