The prototype works. What has actually been proven?

Success needs a specific question

The device starts, the application shows a temperature and the reading looks plausible. What have we established? Perhaps only that the sensor responds, the firmware, meaning the software running on the device, reads data and communication works on the developer’s desk. That is useful information, but it does not yet establish whether the product will be useful at its installation site for the required duration.

A prototype is most valuable when it enables a decision. Instead of “we will test the device”, write “we will determine whether this architecture permits a year of battery operation with a reading every 10 seconds”. That question identifies the data to collect, the conditions to reproduce and what could undermine the concept.

Not every experiment must establish readiness of the entire product. Sometimes eliminating one of two measurement methods is sufficient. What matters is not assigning the result a broader meaning than the investigation supports. The sensor and all numbers below are hypothetical examples, not a record of a BBest24 project.

PoCs, prototypes and MVPs ask different questions

Names are not evidence of maturity. A proof of concept (PoC) usually explores whether a principle is feasible. A prototype represents selected features of a future solution so they can be examined. An MVP (minimum viable product) has the smallest set of functions needed to evaluate its value in actual use. Agree on these meanings within the project instead of assuming everyone interprets the labels identically.

This is not a mandatory sequence of stages. A simple circuit for energy measurements, an enclosure model for thermal tests and an application mock-up can be developed in parallel. One impressive demonstrator integrating everything is not always the cheapest way to answer the most important question.

One sensor, three different kinds of evidence

Consider a temperature sensor transmitting data every 10 seconds. The first demonstrator runs on a USB-powered development board. A correct reading in the application establishes basic cooperation between components. USB power hides battery limitations, however, while the absence of an enclosure changes heat dissipation and antenna operating conditions.

A second experiment should address the complete energy cycle: wakeup, measurement, transmission, waiting for a response and sleep. A third can examine temperature error after enclosing the electronics. In both cases the radio still “works”, but the assessment criteria differ.

The diagram shows one pass from question to decision. In practice, the decision may lead to a new question and another experiment; that loop is not drawn. Revisiting the question makes sense when a result exposes a previously unknown constraint. Changing the definition of success after testing solely to accommodate the observed result does not.

Battery budget: a small detail changes the answer

Assume the entire device draws, at the battery terminals, 20 mA during 0.1 s of activity and 10 µA, or 0.01 mA, during the remaining 9.9 s. Calculate the average by multiplying each current by its duration, adding the products and dividing by the cycle length:

Average current = (20 mA · 0.1 s + 0.01 mA · 9.9 s) / 10 s = 0.2099 mA.

For a nominal 2000 mAh battery, simplified lifetime is 2000 mAh / 0.2099 mA ≈ 9528 hours, or about 397 days. At first glance, a one-year requirement looks achievable. That is only about 9% beyond 365 days, though, before accounting for battery limitations. It is not strong evidence of meeting the requirement with margin.

Now extend activity to 0.5 s because of retransmissions and waiting for acknowledgement. For simplicity, assign the same 20 mA draw to this entire interval. Sleep lasts 9.5 s, giving an average of 1.0095 mA and a theoretical lifetime of about 83 days. The measurement interval has not changed, but lifetime is almost five times shorter.

The principle of weighting current by duration is described by Texas Instruments. Here it is applied to an explicit whole-device model. Actual operating phases may draw different currents; calculate each separately or add up the charge consumed over the measured current trace (its time integral).

What to measure before trusting the calculation

Nominal capacity is not necessarily fully available. Temperature, ageing, self-discharge, load profile and the voltage at which the device stops working all matter. If current is measured after a power converter, battery capacity cannot simply be divided by that value: voltages, conversion efficiency and the converter’s own consumption must be accounted for. The battery terminals provide the clearest reference point for our example.

Average current also says little about brief voltage dips. In a simple model, increasing source resistance produces a larger voltage drop during a current pulse. The device may reset while transmitting despite having enough calculated capacity. Alongside the energy budget, observe voltage during load pulses, especially with a discharged or cold battery.

Measurements should cover many complete cycles, including poor connectivity, rejoining the network and restarting. A multimeter showing a calm average may miss short events. Select suitable instrument ranges and time resolution, and check whether inserting the instrument causes an additional voltage drop. Disconnecting a debugger and using the intended firmware configuration can matter more than another displayed digit.

The enclosure becomes part of the measurement

A sensor on an open board measures temperature under different conditions from the same component next to a processor and converter inside a small enclosure. Closing the enclosure can increase self-heating effects and slow the response to ambient temperature changes. A fixed offset and a slow response are different problems; one calibration correction will not solve both.

Place the sensor and reference under defined conditions, allow temperature to settle and then test a temperature change too. Compare different radio activity levels while holding other conditions constant. If longer radio activity coincides with increased error, that is a clue for another experiment, not yet proof of the sole cause.

Reference quality matters as well. With an allowed error of ±0.5°C, a reference thermometer whose uncertainty is comparable to that limit provides weak evidence for a pass decision. A complete metrology study is not always the starting point, but the method must distinguish acceptable from unacceptable results, especially near a boundary.

Criteria that lead to decisions

The following values are example requirements for this investigation, not universal standards. Record criteria before testing and evaluate energy, measurement and usefulness separately. Before running these tests, specify the temperature range, battery margin and participant selection method. The table alone is not a complete acceptance procedure.

Verification checks conformity to a requirement. Validation checks suitability for intended use. Displaying a measurement timestamp can be implemented correctly while still going unnoticed by the operator. This is a practical reason not to stop at checking that the interface contains a field. NASA Product Verification describes methods of gathering evidence.

An observation is not yet a general conclusion

One successful transmission does not establish link reliability. A thousand readings from the same unit on the same desk do not examine differences between units, installation sites or patterns of use either. Repetition is necessary, but its count cannot replace representative conditions. Likewise, one participant succeeding in an application test establishes that observation, not interface clarity for the entire user population.

Record failed attempts and manual interventions: a restart, repositioning the antenna or re-entering configuration. If the developer had to help, that belongs in the result. During diagnosis, change one significant factor at a time; later examine interactions, such as a weak battery combined with poor connectivity.

An inconclusive result also has meaning. If the instrument cannot capture a current pulse, or the temperature reference is insufficiently accurate, that establishes neither success nor failure of the prototype. The next decision should be to improve the method. Repeating demonstrations that leave the same uncertainty unresolved does not add useful evidence.

What to hand over after the experiment

Preserve the question, hardware and firmware versions, configuration, procedure, raw data, criteria, limitations and decision. Identify temporary elements: laboratory power, manual configuration or a function performed by the operator. The person receiving the prototype should be able to reproduce the investigation and understand which uses have not yet been tested.

For our example, an honest record would read: “The energy model gives about 397 days with a short transmission and about 83 days with extended activity. One-year operation is not yet established. Next, measure at the battery terminals using a realistic retry policy and check voltage margin.” This is an analytical decision, not a fabricated measurement report.

Such a record separates existing knowledge from the evidence still needed. A prototype does not have to prove everything to be valuable. It has to provide a sufficiently reliable answer to the question on which the next step depends.

Sources

• NASA: Product Verification - verification criteria, methods and records.
• NASA: Product Validation - suitability for intended use.
• Texas Instruments: Is Sleep Current or Active Current More Important for a Low-Power Sensor? - average consumption across active and sleep intervals.
• Example requirements and the battery budget are an original calculation model, not product test results.