When you evaluate breathalyzers, the hard case is when many people test at once, such as right before work starts or before a shift change. Purchasing staff often look at the "test time" in a spec sheet and try to calculate how many people can test within a short window, but that number may not describe the whole flow the product goes through for one person's test. If you set the number of units or the size of the setup from one short time figure, a gap opens between the actual queue and the purchase decision.
A breath alcohol test involves several stages: warm-up until the unit is ready after power-on, the user's breath input, analysis of the input and display of the result, and the unit getting ready again for the next person. The test time in product documents may cover only part of this. To judge throughput, you first need to pin down where the number starts and ends before looking at how large it is.
Why a short test time does not mean high throughput
The same phrase, "test time," can cover different ranges in different documents. One candidate may list the analysis time from breath input to result display, while another lists the flow from readiness to result display. If you compare those two values by which is smaller, you are comparing the length of the stated interval, not actual performance.
The flow of people on site is not set by analysis time alone either. Whether warm-up is needed before the first test, whether the next person can start as soon as a result appears, and whether the operator has to explain how to use the unit all play a part. Test time can be a spec for narrowing candidates, but on its own it does not fix how many people can be processed in a given period.
Write down the start and end points in the comparison table
When you transfer times from quotes or product materials, it is better to record the original wording and the measured interval along with the number. If the document does not explain the interval, do not interpret it as the whole process on your own; write "interval unconfirmed." Not filling blanks with estimates helps you avoid adding or subtracting times that measure different things.
| Time interval to compare | What to confirm in the document | Why it is hard to convert directly into throughput |
|---|---|---|
| Preparation at first use | From what state after power-on testing can begin | The conditions for the first use of the day may differ from those for consecutive tests. |
| Breath input | Up to the point when the user finishes which action | Both the usage guidance and the user's speed affect it. |
| Analysis and result display | Until which result screen appears after input | You cannot assume the result display is the same moment the next test can start. |
| Preparation for the next person | When testing can start again after the previous result | You need separate conditions to see the consecutive-use flow. |
The table does not mean every product document lists each of these items. The point of the comparison is that one document may give only analysis time while another gives a time covering a different range. Ask suppliers specific questions such as "Which action does this time start from, and at which screen or state does it end?" and "In consecutive testing, when can the next user start?" so you get answers you can compare.
Read the conditions attached to a time value on the same line
If a time spec comes with conditions such as operating mode, reference range, or temperature, record them with the number rather than separately. You cannot reinterpret a typical time given under specific conditions as the maximum time in every environment or as a guaranteed processing speed. A figure stripped of its conditions belongs in the "needs further confirmation" column, not as a basis for sizing a site.
It also matters whether the document applies to the model you are reviewing. DATECH's official download page posts materials with their applicable models identified, such as "The New AF-50 / AF-50AD Korean manual." If you apply materials for an earlier product with a similar name, or documents for a different configuration, to the current candidate, you may carry over the wrong meaning or conditions for the time items.
Differences revealed in a hypothetical shift-start case
The following is a hypothetical example. Suppose several employees test at one location right before a shift starts, and the person in charge tries to size the setup by looking only at the test times of candidate A and candidate B. If A lists the result analysis time and B lists the time from readiness to result display, then even if A's number is shorter, the two units' queue flows have not been compared.
What to observe here is not a single number but when the first person starts testing, when the result appears, and when the next person can start. If you confirm that A's short time covers only the analysis interval, interpret it as a value you cannot use as the total processing time when calculating headcount. Possible actions include asking both candidates to describe the same interval and, if a demo is possible, recording the observed times and the measuring method in a column separate from the official specs.
The completion criterion in this case is not choosing the shorter number. Each candidate's time item name, start point, end point, conditions, and applicable model must be visible in one comparison table. Only then can you review the setup size needed against the times when people crowd the site and the flow at the test location.
At the quote stage, separate confirmed facts from unconfirmed items
In requests for quotation and internal comparison tables, it is better to write the confirmed time interval as is rather than interpretive terms such as "fast" or "handles many people." A sentence that shows the range, such as "from breath input to result display," lets the people in purchasing, safety, and operations judge from the same conditions. By contrast, creating your own throughput figure by adding preparation times or next-test availability that are not in the documents can blur the basis.
If a supplier's reply still does not confirm the consecutive-use conditions, you can leave that candidate's processing capacity as unconfirmed. This does not mean dropping the candidate right away. It is a way to separate confirmed specs from unconfirmed ones and reduce the risk of under- or over-sizing. Test time is a useful comparison item, but if you calculate throughput only from numbers whose intervals and conditions do not match, a gap opens between the actual usage flow and the purchase decision.
