An interlock installed in a vehicle is an alcohol interlock that controls starting according to set criteria after the driver completes a breath test. The AF-i1 consists of a handset the driver uses and a control box connected to the vehicle, and it can store test results and vehicle-related operating events. If a breath error or a notice appears on the screen during a test, the driver should report the screen and the actions just before it accurately, rather than trying to determine the cause on the spot.
In particular, fleet managers and technical support staff find it hard to tell the stage at which an error occurred and the response needed from a remark like "the test didn't work." If the driver passes on the screen wording, when the error appeared, and the sequence they actually followed, the team can review separately whether action is needed according to the device's guidance and whether the vehicle's operating schedule needs adjusting. The key is to record verifiable facts without concluding that the error is a drinking result or a device fault.
Keep the screen wording exactly as shown
When you see a breath error, write down the wording, numbers, and icons shown on the screen as close to the original as possible. If you rephrase it from memory as "sensor error" or "cannot test," it may differ from what the screen actually said. If you can photograph the screen, take a photo in which the display content can be read rather than of the whole device. If photographing is difficult, writing down the wording and the shape of the symbols also helps.
Passing on only the error screen may not be enough. Also write down whether you were preparing for the test, blowing into the device, or waiting for the result. Even the same wording can call for different checks depending on the stage at which it appeared.
Include time and actions in the information you pass on
Information to send to technical support or fleet operations staff can be organized in the order "on which device, when, at which stage, and what I was doing." Write the device model name to the extent it can be confirmed from the markings on the handset or equipment, and if the device shows a time, record it separately from the phone's time. Vehicle numbers or driver identification can be added as needed according to the organization's internal practices.
| Item to organize | How to write it | Why it is needed |
|---|---|---|
| Device and time of occurrence | Device model name, date and time you saw the error, whether a time was shown on screen | Used to find which device's record from which point in time |
| Stage at which the error occurred | Write it in the actual on-screen order, such as preparing, blowing, or waiting for the result | Distinguishes at which part of the test procedure the wording appeared |
| Screen content and the action just before | The original wording, numbers, and icons, and the action you took just before following the on-screen guidance | Passes on reproducible facts instead of guesses |
| Whether it repeated and the current situation | How many times the same thing happened, whether the vehicle is waiting to depart or the schedule needs adjusting | Lets technical checks and fleet operations adjustments proceed separately |
For example, this is a hypothetical case. Suppose a driver started a test following the guidance on the handset screen before a morning departure, and a message appeared during the breath stage. The observation here is "what time in the morning, during the breath stage, the original wording on screen, and that the test was started following the guidance just before." Interpretations such as "it failed because the breath was weak" or "the device is broken" do not go in the observation.
Do not interpret a breath error as a test result
The official AF-i1 product information describes a tampering detection feature that checks whether a person is testing directly based on the temperature, humidity, speed, and strength of the breath. However, this feature description alone cannot establish why a breath error appeared on a particular screen or what a test result means. A screen error, a test result, and tampering detection can be different pieces of information, so it is important not to report one as the conclusion of another.
So, just because an error occurred, you must not keep testing until a lower reading appears, or have someone else take the test for you. Changing the device connections or tampering with settings on your own is also not a procedure for confirming the cause of an error. If the device screen or user guidance shows a next step, follow it within that scope, and if it is hard to continue, include that fact itself in the information you pass on.
A possible action in the hypothetical case is to record the original screen wording and the stage at which it occurred, and then send that information through the approved support channel. If a trip is scheduled, inform the fleet operations staff of a possible delayed departure separately from the request to solve the technical problem. It is clearer to set the completion criterion not as the driver getting through by some improvised method, but as whether use of the device can resume following the guided procedure, or whether an approved adjustment to the operating schedule has been made.
Separate technical checks from decisions about operating the vehicle
Technical checks of a breath error are based on the device screen, device information, time of occurrence, and the procedure followed. By contrast, whether the vehicle can be operated that day and whether a replacement vehicle or schedule change is needed are matters for the organization's fleet operations procedure. If the two issues are mixed into one sentence in a report, the technical staff will ask again for the screen information and the operations staff will ask again for the schedule information.
The AF-i1 is described as being able to store test results and interlock usage events, such as vehicle ACC, engine start, and tampering, along with date and time information, and as allowing log events to be managed and downloaded with dedicated software. So the staff may request the device records for further checking. The screen information the driver passes on serves as a clue for finding the stored events, but the log is not something the driver should delete or alter to match.
After reporting, leave a status so you can wait for an answer
After reporting, update only whether the same problem has appeared again and whether the vehicle is currently waiting to depart. If you rewrite the screen wording you already passed on based on guesses, or merge several attempts into a single situation, it becomes hard to review what happened first. If it repeated, it is better to record the time and screen content of each occurrence separately.
Even in conditions where device preparation time may feel different from usual, such as winter, the method of writing down the screen changes you saw while waiting and the actual times is the same. The official AF-i1 information says warm-up time can vary with temperature, but that is not grounds for concluding that temperature caused an individual error. With four pieces of information in place, the original screen wording, the stage, the actual actions, and the operating schedule, both technical support and fleet operations have a starting point for deciding the next step.
