When breath alcohol test results move from a breathalyzer to a smartphone app and are then viewed on an admin screen or in a downloaded file, the last digits of the same result can look different. Safety managers and quality or technical staff need to tell whether this difference comes from the sensor measurement or from data processing. In particular, if there is a feature that compares results with a set threshold, you need to check whether shortening the number shown on screen also changed the comparison result.
The server here means the system that receives and stores results sent by the breathalyzer or smartphone and serves them again to the app, web screens, and files. Rounding is processing that shortens a long decimal to a set number of digits to make it easier for people to read. DATECH's AF-40BT is described as supporting test result storage and Bluetooth 5.0 LE smartphone integration, but the public product information alone does not tell you the number of digits or format of the numbers sent during integration. So the starting point is a structure that preserves the result the device actually sent and keeps the display numbers the service creates separate.
Keep the original unchanged on the server
To start with the conclusion, it is better not to round separately on each screen but to handle rounding through a single display rule managed by the server. However, the server must not overwrite the original test result it received with a rounded value. Keep the number representation, unit, and time of receipt sent by the device or connected app without alteration, and create the screen representation separately from that original.
If the device sent only results with a fixed number of digits, that value is the original the service has. For example, if the device sent the representation 0.100, the service can preserve it but cannot recover any digits hidden behind it. Conversely, if the trailing zero is dropped on screen so it appears as 0.10 and the original is also changed to 0.10, it becomes hard to explain later which processing changed the representation.
Separate the roles of test results and screen text
A test value is the combination of the number and unit provided by the device. A display value is text in which the number of digits, whether to show trailing zeros, and unit placement are set for people to read. If there is a feature that compares with a threshold, the value used for the comparison must also be kept separate. Even if all three look like the same number, they differ in storage purpose and in whether they may be changed.
The official AF-40BT information gives the display range in %BAC, ‰, and mg/L units, and states accuracy conditions for each unit. So storing the number alone weakens the meaning of the result. 0.050 %BAC and 0.050 are not the same information, and results in different units must not be displayed as if they were the same value just by matching decimal places.
| Category | What to keep on the server | What the screen or file does |
|---|---|---|
| Result sent by the device | Received number representation, unit, time received | Shows it as is when the original must be presented |
| Value used for threshold comparison | Value, unit, and rule applied at the time of comparison | Shows the comparison result separately from the display number |
| General display result | Display text created from the original and the rule version | Applies only the set number of digits and rounding method |
| Downloaded file | Separation of original and display columns | States in each column heading whether it is original or display |
This separation is not meant to make the data complicated. It is needed to find which number came from the breathalyzer and which the service created when the app shows two digits and the report shows three. If you divide responsibility between the original and the display value, sensor error, unit conversion, and screen formatting can be reviewed as separate problems.
Do not use display rounding for threshold comparisons
A service that must compare with a threshold should compare using the value and unit set by the comparison rule, not a number shortened for display. It is better to avoid multi-step processing such as first rounding to two digits for comparison and then shortening to one digit again in the report. Even with the same original, intermediate rounding can make the final representation and the comparison result hard to trace.
Applying rounding only once, and only for display purposes, is easier to manage. Even if there is a reason to change the comparison rule, it must not be handled together with a change to the display rule. Keep both the value used for comparison and the text shown on screen, so that redesigning a screen does not change comparison results.
You also must not assume that the comparison result can be recalculated from the number on screen. The moment the screen shortens the digits for readability, it holds less information than the original. If you must provide only display columns in a report or file, it is appropriate to state clearly that the column is not the original test result but a value with the display rule applied.
Find where processing happens using a hypothetical case
As a hypothetical example, suppose the same test result appears as 0.10 on the admin screen and 0.100 in the downloaded file. The first thing to observe is not which of the two is correct, but the original representation the server received and the rule used to build the screen and the file respectively. If the original is the same 0.100 and the value and unit are also the same, this can be interpreted as a difference in how trailing digits are displayed, not a measurement difference.
A possible action is to keep the display digits and rounding method as one rule on the server and have the admin screen and the file generation feature both use its output. If the file's purpose is to preserve originals, you can also keep the original result column and put the screen display value in a separate column. The completion criterion is that for the same original input, the screen, app, and file consistently output the predefined representation, and the stored original result does not change in the process.
Conversely, if the original stored on the server has itself been changed to look like the screen display value, the problem may lie in storage processing, not the screen. In that case, fixing the display rule alone will not solve it. Compare the value right after the original was received with the value stored afterward to find at which processing step the digits or unit changed.
Include inputs other than plain numbers when testing changes
Before changing rounding rules or report formats, testing only ordinary numbers is not enough. Include values with trailing zeros, values right at a rounding boundary, empty results, error representations that cannot be parsed as numbers, and cases where the unit is sent along with the value. These can be prepared as hypothetical values for verifying format handling, not as real people's test results.
In the test, pass the same input through server storage, threshold comparison, the app screen, the admin screen, and the downloaded file, then look at the results side by side. A trailing zero disappearing only on screen and the stored number itself changing need fixes in different places. The former calls for looking at the display rule; the latter calls for looking at receipt and storage processing.
It is also better to record the device's internal display rules separately from the service's rules. The format the breathalyzer shows on its screen, the format the smartphone sends, the original the server stores, and the display format the service creates may be the same or may differ. Only by preserving the original on the server and applying rounding once, as a display rule the server manages consistently, can you explain the same test result across multiple screens and files.
