Prototyping and design reviews

A prototype is a question built in hardware or software. The most common capstone mistake is to build one big prototype at the end, which answers every question at once, too late to do anything about the answers. The TrailCount team built a sequence of prototypes, each designed to answer specific questions as cheaply as possible, and it used formal design reviews to decide, at each step, whether the evidence justified spending more time and money. This lesson covers both, with a detailed look at one analysis that every circuit board deserves before it is ordered: tolerance analysis.

Prototypes answer questions

Before building anything, the team wrote down the questions it needed to answer, ranked by risk. Could a low-power radar module distinguish walkers from cyclists at this site? Would the power budget hold in practice, not just on paper? Could the LoRa link reach the gateway through trees? Would the battery survive charging in the cold? Would the enclosure keep water out? Each question shaped a prototype, and each prototype was as crude as it could be while still answering its question.

• Proof of concept (weeks 3 to 6). Jonah mounted the radar evaluation kit on a camera tripod at the trail, connected to a laptop, and recorded detection lists for two afternoons while Keisha counted passages by hand. This answered the classification question well enough to choose concept B. Total cost: the borrowed kit and two afternoons.
• Breadboard (weeks 7 to 12). Development boards for the microcontroller and LoRa radio were wired to the radar kit and a bench supply with a current meter. Amira ported the tracker from Python to C and ran it on recorded detection files and then live. Lucas sent real uplinks to Northway's network from the trail. Keisha measured the actual current profile and found the radar's active power about 10 % higher than the datasheet's typical value, which she put into the power budget.
• Alpha (weeks 12 to 16). The first custom circuit board combined the microcontroller, radio module, power circuits and connectors on one board, in a 3D-printed case. Its purpose was to find layout, power and integration problems, not to look good. Three were built.
• Beta (weeks 16 to 20). The second board fixed the alpha's problems and went into the commercial enclosure with the real gland, vent, panel and mounting plate. Five were built: three for the field trial, one for environmental tests and one spare.
• Pilot (weeks 20 to 23). Three beta nodes on posts at the trail for the two-week field trial, with manual counts for comparison.

Software prototypes followed the same logic. Amira's first tracker was a Python notebook that replayed recordings and drew tracks on a plot. It answered whether the algorithm worked before anyone spent time on embedded code. Lucas's first dashboard feed was a script that printed decoded uplinks. Throwaway prototypes are fine, as long as everyone agrees in advance that they will be thrown away.

What went wrong on the alpha board, and why that was good

The alpha board had seven defects, which is typical. The radar module's inrush current, despite the ICD review, still caused a brownout on one of three boards, because that board's regulator came from a different batch with a lower current limit. The real-time clock's crystal footprint was mirrored. The fuel-gauge chip's address conflicted with the temperature sensor on the shared I2C bus. A test point was under the enclosure's mounting boss. The heater's MOSFET ran warm because the gate drive voltage was too low. The status LED was too dim to see in daylight. And the LoRa module's antenna connector was placed too close to the board edge for the enclosure's wall.

Each defect went into an issue tracker with a description, its cause, the fix and the board revision that would include it. Rework wires fixed four defects on the alpha boards so that firmware development could continue; the rest waited for beta. A sequence of prototypes makes defects like these cheap. Discovering a mirrored crystal footprint on the alpha costs a rework wire and a correction; discovering it on twenty production boards costs twenty boards.

Tolerance analysis

Several alpha defects came from treating component values as exact. Real resistors, references, regulators and crystals have tolerances, and their values drift with temperature and age. Tolerance analysis asks whether a circuit still meets its requirement when every component is somewhere within its tolerance band. There are three common methods, and engineers choose among them by the stakes.

• Worst-case analysis sets every tolerance to the extreme that pushes the output furthest in each direction. It is conservative: if the circuit passes worst case, it will always work. For a few components, the team simply evaluated every combination of extremes.
• Root-sum-square (RSS) analysis assumes independent random errors that partially cancel, and combines their effects as the square root of the sum of squares. It is less conservative and estimates the spread most units will see.
• Monte Carlo simulation draws random values for every component, thousands of times, and looks at the distribution of the output. It handles nonlinear circuits and any distribution, and it is easy to run in a short script.

Keisha applied all three to the battery-voltage measurement: a divider of 100 kΩ and 150 kΩ feeding the microcontroller's 12-bit analog-to-digital converter, with a 2.500 V reference. The firmware converts the reading back to battery voltage using the nominal values.

import random, math
# Battery-voltage divider into a 12-bit ADC: worst case, RSS and Monte Carlo
R1, R2 = 100e3, 150e3          # ohms; Vadc = Vbat * R2 / (R1 + R2)
tol_r = 0.01                   # 1 % resistors
vref, tol_ref = 2.500, 0.005   # reference 2.500 V, 0.5 %
vbat = 3.30
def reading(r1, r2, vr):
    vadc = vbat * r2 / (r1 + r2)
    code = round(vadc / vr * 4095)
    return code * (2.500 / 4095) * (R1 + R2) / R2      # firmware uses nominal values
nom = reading(R1, R2, vref)
corners = [reading(R1 * (1 + a * tol_r), R2 * (1 + b * tol_r), vref * (1 + c * tol_ref))
           for a in (-1, 1) for b in (-1, 1) for c in (-1, 1)]
print(f"Nominal reading {nom * 1000:.0f} mV")
print(f"Worst case: {min(corners) * 1000:.0f} to {max(corners) * 1000:.0f} mV "
      f"(+/-{(max(corners) - min(corners)) / 2 * 1000:.0f} mV)")
# sensitivity-based RSS: divider ratio error and reference error combine
k = R1 / (R1 + R2)                                  # ratio sensitivity to each resistor
rss = math.sqrt(2 * (k * tol_r) ** 2 + tol_ref ** 2) * vbat
print(f"RSS estimate: +/-{rss * 1000:.0f} mV")
random.seed(499)
sims = []
for _ in range(20000):   # tolerances treated as uniform across the band
    sims.append(reading(R1 * (1 + random.uniform(-tol_r, tol_r)),
                        R2 * (1 + random.uniform(-tol_r, tol_r)),
                        vref * (1 + random.uniform(-tol_ref, tol_ref))))
sims.sort()
lo, hi = sims[int(0.0013 * len(sims))], sims[int(0.9987 * len(sims)) - 1]
print(f"Monte Carlo 99.7 % band: {lo * 1000:.0f} to {hi * 1000:.0f} mV")
# LiFePO4 voltage is so flat that tens of millivolts span a large part of the charge range
print(f"Needed accuracy for state of charge: +/-25 mV; worst case meets it: {(max(corners) - min(corners)) / 2 <= 0.025}")

Nominal reading 3300 mV
Worst case: 3257 to 3344 mV (+/-43 mV)
RSS estimate: +/-25 mV
Monte Carlo 99.7 % band: 3263 to 3337 mV
Needed accuracy for state of charge: +/-25 mV; worst case meets it: False

At a true battery voltage of 3.300 V, the worst case reading ranges from 3,257 mV to 3,344 mV, an error of about ±43 mV. RSS predicts about ±25 mV, and the Monte Carlo 99.7 % band is 3,263 to 3,337 mV, about ±37 mV. The Monte Carlo band is wider than RSS here because the tolerances were modelled as uniform across their bands, which is a pessimistic assumption for resistors that are usually tightly clustered around nominal; the RSS formula treated each tolerance limit as if it were one standard deviation.

The important result is the comparison with the requirement. A LiFePO4 cell's voltage curve is very flat over most of its charge range, so tens of millivolts span a large part of the state of charge. A ±43 mV error makes the voltage nearly useless as a fuel gauge. This analysis is why the beta board added a dedicated fuel-gauge chip that counts charge in and out of the cell, with the divider kept only as a sanity check and for detecting a very low cell. It also led to a cheaper improvement for the divider itself: a one-point calibration during production test, which removes most of the fixed error.

Design reviews

A design review is a planned, structured examination of a design by people who did not create it, held at a point where the findings can still change the plan. Reviews are not presentations for marks, although capstone courses often grade them. Their purpose is to find problems while they are cheap and to decide whether to proceed. Professional practice, in fields from aerospace to medical devices, uses a sequence of reviews, and capstone courses borrow the names.

Each review has entry criteria (what must exist before it can be held), a set of reviewers, a structured agenda and exit criteria (what must be true to pass). The TrailCount PDR had three reviewers: Professor Osei, Ines from Northway, and a second faculty member with radio experience who had never seen the project. Each received the architecture document a week in advance and returned written comments before the meeting. The meeting itself spent most of its time on the comments, not on slides.

Running a review that finds problems

Reviews find problems only if the team makes it easy. Send material early. Present evidence, not adjectives: a measured current profile rather than a statement that power is fine. Invite challenge by stating the biggest open risks yourself. Record every comment as an action item with an owner, a due date and a disposition: accepted and fixed, accepted for later, or rejected with a reason. And close the loop: the next review starts by checking that every action from the last one was dispositioned.

The PDR generated 23 action items. Most were small: clarify a field in ICD-03, add the heater to the power budget. Three were significant. The radio reviewer asked for a measured range test at the actual site before committing to LoRaWAN, which Lucas did the following week. Ines asked for the over-the-air update requirement to be risk-assessed, which later led to its deferral. And Professor Osei asked how the team would verify SYS-01 with real trail users, which forced an early start on the field trial plan. The CDR, five weeks later, produced 17 action items and a conditional pass: the team could order beta boards once the heater gate-drive fix was confirmed on a reworked alpha.

Peer reviews of code and schematics are design reviews in miniature. The team required a second member's approval before any firmware change reached the main branch, and before any board was ordered. Schematic review used a checklist: every part's footprint checked against its datasheet, every I2C address listed, every power rail's maximum current computed, every connector's pin 1 marked, every test point reachable. The checklist grew after the alpha board; the mirrored crystal footprint and the address conflict both became new lines.