The Modular Sensor Array began with a frustration shared across the environmental research lab I was embedded in: every field deployment required a custom hardware build, and adding a new measurement type meant a new PCB spin and a new firmware compile. The whole pipeline was bottlenecked on hardware engineering for what were, fundamentally, configuration changes.

This article walks through the system-level decisions that shaped the platform — what we kept, what we threw out, and where the boundaries between modules ultimately landed.

Three constraints, ranked

Early on we settled on a strict priority order for design decisions. Whenever two requirements conflicted, the higher one won — no exceptions.

• Field reliability. A failed deployment can mean months of lost data and a multi-thousand-dollar helicopter trip.
• Configurability without recompilation. Field scientists should be able to swap sensors without touching code.
• Power efficiency. Most deployments run on a single 100Wh battery for six months.

The self-describing module pattern

The key insight that unlocked configurability was borrowing from Eurorack and USB: every module carries a small EEPROM that describes itself — sensor type, address, sample rate, calibration coefficients. On boot, the controller walks the bus, reads the EEPROMs, and constructs its scheduling table at runtime.

This meant firmware shipped once, and configuration happened by physically swapping modules. A research team in the field could literally pull out a humidity sensor and plug in a soil pH sensor, and the system would just work.

Tradeoffs we accepted

The EEPROM-per-module approach added cost (about $0.40 per module) and required a more disciplined bus protocol. We also gave up the ability to do certain compile-time optimizations. In exchange we got a system where the human in the loop — the field scientist — never had to touch a compiler. That was the right trade for this audience.

The backplane PCB went through four revisions before it stopped failing in the cold-chamber tests. This article documents the final schematic and the specific changes that got us there.

Power architecture

Each module receives both 3.3V and 5V rails, with a dedicated soft-start circuit per slot. Early revisions used a shared rail and saw cascading brownouts when high-current modules (the soil moisture probe in particular) were hot-swapped. Per-slot isolation solved this at the cost of a few extra components per slot.

Bus arbitration

The shared I²C bus uses a simple polling scheme — the controller is always master, and modules respond on their preconfigured address read from EEPROM. We considered moving to CAN for the obvious robustness benefits but the part count and current draw didn't justify it for sub-1Hz sample rates.

Components that mattered most

• LM73100 ideal diode + soft start — the single most important part change between rev 2 and rev 3
• TCA9548A I²C multiplexer — let us handle address collisions between identical modules in different slots
• TVS diodes on every bus line — added after a lightning-adjacent deployment fried a controller

The array was deployed at three sites across the Sierra Nevada from May through October. This article summarizes what we measured, what failed, and what the data eventually told us about the design.

Field performance

Across the three sites we hit 99.4% uptime over the full deployment period. The lost time was concentrated in two events: a single SD card failure at the highest-altitude site (since replaced with a higher-endurance industrial SKU) and a four-day stretch where snow blocked the solar panel before the battery could fully recover.

Cold-chamber findings

Before deployment we ran the units through a 72-hour soak at -25°C. Two failure modes emerged that drove rev-4 changes:

• Electrolytic capacitors on the controller board lost capacitance enough to cause occasional brownouts on radio transmit. We replaced them with polymer types rated for -40°C.
• The SD card's write latency rose unpredictably below -15°C. We added a small heater resistor under the card socket, gated by a thermistor.

What I'd do differently

Looking back, the biggest mistake was underestimating how much of the project would be packaging, cabling, and enclosure design. Roughly 40% of the rev-3-to-rev-4 changes were mechanical, not electrical. If I started this project again I'd bring in an ME on day one.

Replace this with your project's high-level design article. Cover the goals, the overall architecture, and the major design tradeoffs you made along the way.

This template is structured so each project has three companion articles. Use this slot for the conceptual narrative — the "why" behind the system.

Insert your control diagrams, block diagrams, or schematics here. Each figure can use the same article-figure pattern shown in Project 01's articles.

Use this section for plots, numerical results, and what they mean. The stat-grid component from Project 01 works well for headline numbers.

Use this slot to describe the design language, references, and human-factors thinking behind the artifact.

Drop in your CAD exports, exploded diagrams, and the rationale behind dimensional choices.

Summarize the methodology, sample size, key findings, and the limitations of your study.