Finding Out What an Instrument's Sensors Could Really Do

The problem

A laboratory automation company was building an instrument to check the fluid in every well of a 96-well microplate. Twelve ultrasonic distance sensors ride on a two-axis stage and sweep across the plate, one sensor per row, and the depth of the fluid in each well was meant to show whether it held enough.

They shipped us the entire apparatus. The sensors had been chosen before anyone had tested them for this job, and the whole design depended on them.

What we did

Built the full instrument software. At startup the instrument homes its stages and calibrates all twelve sensors against reference surfaces of known height, then recognizes which of three plate types is loaded without asking the user. A scan reads the plate’s barcode and sweeps the sensors across the plate, sampling each one more than 20,000 times a second. A custom algorithm separates the wells from the plate’s edges in each signal, compares each well with a manifest of acceptable limits, and shows the result as a color-coded 8 by 12 map. Every scan is saved with its measurements, barcode, plate type, and manifest for traceability.

Designed supporting electronics for the apparatus, helped select the control hardware, and wrote documentation for the client’s user manual.

Put the sensors to the test. Because everything depended on the sensors, we wrote code to characterize each one on the actual apparatus and adapt to how it really behaved, rather than trusting the datasheet. That testing produced the project’s most important finding: the wells were too narrow for these sensors. They could tell whether a well held fluid most of the time, but they could not measure how much with the precision the instrument needed.

The result

The client got a complete, working instrument platform, from calibration and scanning to results and traceable records, and a clear, evidence-based answer about its sensors: reliable enough to detect fluid in a well, not precise enough to measure its level in wells that narrow. That is the kind of answer that is far cheaper to learn on a prototype than after units reach customers.