Designing Reproducible Lighting Recipes for Research Chambers

A reproducible lighting recipe is a complete, versioned description of every light parameter a plant experienced, plus the environment around it, such that another lab could repeat it. Reproducibility fails when recipes are口头 (verbal) or when only the dial settings are recorded. This article gives a structure for recipes that travel. It builds on the spectrum and measurement articles.

Document every parameter

A recipe should capture spectrum (band peaks and flux), total measured PPFD, photoperiod, dimming level, fixture model and drive current, and the measured uniformity. Anything left implicit — "we used the usual settings" — is exactly what breaks replication years later.

Control the environment around the light

Light does not act alone. Temperature, humidity, CO2 and airflow change how plants use photons, so a recipe that omits them is incomplete. At minimum, record the environmental setpoints and the actual ranges measured during the run.

Make it machine- and human-readable

Store recipes in a structured form (a table or file) that both a person and a controller can read, so the description cannot drift from what was run. The same discipline scales from a single chamber to a commercial operation logging its batches.

• Capture spectrum, PPFD, photoperiod, dimming, fixture details.
• Record environmental setpoints and measured ranges.
• Version and date every recipe change.
• Store in structured, recoverable form.
• Map dimming to measured PPFD, not assumed.

What a reproducible lighting recipe contains

A reproducible recipe is a document another lab could run and get the same light conditions. Most published methods sections say less than that. The difference is usually not effort but template: once a lab adopts a standard recipe format, writing it down costs minutes per run.

• Fixture identity: manufacturer, model, serial number and firmware or driver version where relevant.
• Spectral power distribution per channel at the working output, measured or supplied by the manufacturer at that drive level.
• Electrical settings: drive current or dimming percentage, measured power draw, and stated PPE under those settings.
• Geometry: fixture-to-canopy distance, chamber dimensions, reflective surfaces and tray positions.
• Delivered PPFD map: grid, sensor, calibration date, average, minimum and min-to-avg ratio.
• Photoperiod and any ramping, plus the control system that enforces it.
• Environmental context: air temperature at canopy, CO2 concentration and humidity during the run, since light-use efficiency depends on them.

Replication across chambers without fooling yourself

Chamber identity is a variable

Two chambers built and programmed identically still differ: sensor offsets, air circulation patterns, and wall reflectance drift over time. The practical disciplines are to randomise treatments across chambers, rotate trays between positions on a schedule, and periodically run a null comparison (identical settings in every chamber) to quantify the between-chamber difference. A recorded null comparison also catches controller drift that would otherwise hide inside treatment effects.

Change control for the light environment

Lighting recipes change: fixtures age, firmware updates alter dimming curves, and a moved tray rack rewrites the PPFD map. Give the light environment the same change control as instrument calibration: log every change with date, reason and the re-measurement that followed. When a result from last spring is questioned in review this autumn, the change log is what connects the published recipe to what actually illuminated the plants.

Questions to ask before you buy

• Can fixture and channel settings be exported, versioned and re-imported exactly, recipe by recipe?
• Is control scriptable through a documented API for scheduled and randomised protocols?
• Does the supplier commit to long-term availability of the same model and optics for multi-year studies?
• Are per-unit photometric reports provided so between-fixture variation is known before chamber assignment?
• What is the documented output drift over the fixture lifetime at your operating temperature?

Common mistakes in lighting recipe documentation

Documentation errors are invisible until reproduction is attempted. The recurring ones:

• Recipes recorded as controller screen settings, which no other lab (or controller model) can interpret.
• Spectral information reduced to a marketing label such as full spectrum, with no distribution behind it.
• Geometry omitted: fixture-to-canopy distance and chamber finish are half the PPFD map and often absent from methods sections.
• Photoperiod stated as a single number while ramping, interruptions and maintenance overrides go unrecorded.
• No version control, so two cycles with the same recipe name ran under different settings after an undocumented change.
• Environmental co-variables missing, so the recipe claims effects that temperature or CO2 actually produced.

Making recipes portable between labs and generations of fixtures

The distribution is the recipe

The portable form of a lighting recipe is its spectral power distribution plus its geometry and photoperiod, not the settings of one controller. A lab replicating a study needs to know what photons arrived, when, and in what spatial pattern; from that, it can derive its own settings on its own hardware. Internally, the same discipline protects against fixture obsolescence: when the discontinued model is replaced, the archived distributions define what the replacement must match, and the acceptance test writes itself.

Versioned recipes and the change log

Treat lighting recipes like code: version numbers, a change log with reasons, and a rule that no cycle runs under an unversioned recipe. The overhead is minutes per change, and the payoff arrives with the first review comment, audit question or inter-site comparison. Labs that adopt this habit early find that the documentation becomes the institutional memory that survives staff turnover and equipment generations alike.

Auditing an existing chamber against its recipe

Recipes claim; chambers deliver. A periodic audit closes the gap, and it is shorter than most expect:

• Re-measure the PPFD map on the standard grid and compare with the filed map; drift beyond the stated uncertainty triggers investigation.
• Verify the photoperiod log for the last cycles against the recipe, including overrides and power events.
• Sweep the dimming curve and compare with the acceptance record.
• Cross-check all working sensors against the transfer standard under current fixtures.
• Review the change log for undocumented alterations (moved racks, swapped sensors, firmware updates).
• Confirm the environment co-variables (temperature, CO2, humidity) logged during cycles match the recipe assumptions.

An annual audit of this kind takes a day for a small chamber suite and keeps every published number defensible. More importantly, it catches the slow failures (drifting sensors, dimming curve changes after firmware updates, reflective surfaces painted over) that no single cycle ever notices. The audit report belongs with the recipe record, closing the loop between what the recipe says and what the chamber did.

References you can verify

• Cornell University - controlled environment plant science research
• DesignLights Consortium - horticultural lighting testing and requirements
• e-GRO - research methodology summaries for CEA lighting

Frequently asked questions