How to tell a breath flow error from an alcohol detection result

5 min read

A breath analyzer first takes in a person's exhaled breath as a sample, decides whether that sample meets the conditions for analysis, and only then displays an alcohol detection result. In this process, a breath flow error means the device could not obtain the breath sample it needs or could not complete sampling. It does not mean the alcohol concentration is low or zero. Conversely, an alcohol detection result can only come after the device has analyzed a sample it accepted.

This distinction matters especially when a safety manager reviews test history or a quality or engineering lead designs integrated data. If a screen showing that not enough breath was received is saved as a concentration of 0 or a negative result, a test that was never analyzed turns into what looks like a normal result. From the perspective of OIML R 126-1:2021, which covers quantitative analyzers that sample breath through a mouthpiece, the sampling stage and the analysis result should also be viewed separately.

A failed sample is not an analysis result

Breath flow errors usually occur at the sampling stage. The breath may not have continued in the way the device requires, or the device may not have accepted it as a sample usable for analysis. Even if an error message appears on the screen at that point, it does not mean the alcohol concentration was analyzed.

The alcohol detection result is a separate stage. A number, a negative indication, or another result display defined by the device can appear only when the sample is accepted as valid and the analysis is complete. So a flow error and a reading of "0" must not be put in the same category. The former is information about an incomplete test or a rejected sample, while the latter must be the result of analyzing a valid sample.

Error wording, error codes, and retry instructions differ from device to device. Even if the screen shows wording such as "insufficient flow" or "breath error," do not stretch that wording into an official definition for other models. The safe order is to check what the device's manual and on-screen guidance refer to, and then classify whether it is a sampling failure or a result after completed analysis.

What to keep separately from the screen and the data

In an integrated system or a test log, it is better to record how far the process got, rather than keeping only one result value. That way you can later tell whether a blank result is a communication gap, a sampling failure, or an interrupted analysis. In particular, if the device screen showed an error but the exported file only has a blank result field, the difference between the screen and the file is itself something to review.

Stage to separate Facts to keep Basis for interpretation
Breath sampling Whether sampling started and ended, and the on-screen guidance Decide whether the full breath sample was received
Sample acceptance Whether the device accepted the sample or showed a rejection message Determine whether the sample moved on to analysis
Analysis and display Whether analysis finished, and the number or result text shown Confirm whether an actual alcohol detection result was provided
Transmission and storage Whether the device screen and the saved file match Do not confuse a lost result with a failed test

"Sample acceptance" in the table is not the name of an internal function shared by all devices. It simply means recording, for operational purposes, whether sampling finished and whether the sample was processed as one that can be analyzed. For example, if a missing result is written only as "not tested," the cause is unknown. If it is recorded as "error message during breath sampling, no analysis result shown," the record can later be compared with screen images and the device's guidance.

Decision order in a hypothetical case

Take a hypothetical case. A worker starts a test, and a breath-related error appears on the device screen. The saved file has a blank alcohol result field, and the note entered by the person in charge records only the test time. The observable facts here are two: there was a breath-related message, and there is no numerical result.

These facts alone do not support the interpretation that the worker deliberately avoided the test or that no alcohol was present. The first possible interpretation is that sampling was not completed, so the process could not proceed to analysis. However, until you check the exact on-screen wording and the manual for that model, do not conclude a specific cause such as insufficient flow or a timeout.

A possible action is to follow the next steps set out in the on-screen guidance and the device manual. If repeated errors need to be reviewed, gather together the test date and time, the model name, the software version where it can be confirmed, the actual screen wording or a photo, and the blank result in the saved file. The completion criterion in this case is not reaching an arbitrary conclusion about alcohol concentration, but classifying, with verifiable records, whether the attempt was "no analysis result due to sampling error" or some other status.

Why 0, blanks, and errors should not become the same value

If errors are converted to 0 during data processing, "analyzed but not detected" and "could not be analyzed" get mixed. When you later calculate negative rates, error rates, or retest counts, there will appear to be more normal tests than there really were. Automatically filling blanks with negative results causes the same problem.

On the other hand, treating every blank as a flow error is not right either. The transmission may have been cut off midway, or the screen message may have been lost during storage. Only by storing the confirmed facts separately, such as no result value, error message present, or analysis completion unknown, can you avoid overstating the cause.

When counting tests, you also need to distinguish tests actually started on the device from transmissions in which the server received the same record again. If retransmissions are counted as separate tests, a particular error may look like it repeated. The purpose of reviewing error frequency is not to rush to blame a person or a device, but to find at which stage information disappears or a test fails to finish.

When breath flow errors continue, it is not appropriate to tell the person on your own judgment to blow harder or longer. The sampling conditions the device requires and the next action should be based on the model's manual and on-screen guidance. If the person has difficulty continuing to blow, it is better not to turn the repeated attempts themselves into a result, and instead to record that the test was not completed along with the guidance shown at the time.

In technical review materials, it helps to link the model name, the software version where it can be confirmed, the original text shown on screen, the test time, and the corresponding record in the saved file. In particular, if the device's on-screen error message is not included in the file, keep a screen photo or a separate record with it. Separating sampling, analysis, display, and transmission this way keeps you from misreading a breath flow error as an alcohol detection result, and lets you decide the next step based on what was actually confirmed.

References

#breath flow error
#breath sampling
#test result data
#error status
Considering our products?
We'll help you decide.