Scope of This Case Study
This case study describes the design and build of an infrared eye-blink communication device developed for the Yarl Geek Challenge in 2017, where the project reached the finalist stage. It covers the problem, the design requirements, the system architecture, the blink-decoding scheme and the prototype. It makes no performance claims. Evaluation records from the build were not retained, so the study reports what the prototype was designed to do and how it was demonstrated, not measured accuracy, false-trigger rates or latency.
Abstract
People with partial paralysis often depend on carers to request basic needs, and scheduled care covers predictable needs such as meals and medication. Unscheduled needs, such as a drink between rounds, depend on attracting attention. This case study describes a low-cost device that lets a user with limited voluntary movement send a small set of pre-defined requests at any time, using deliberate eye blinks. An infrared emitter and receiver aimed at the eye detect eyelid closure, a microcontroller times the blinks, and a fixed mapping converts blink sequences into messages shown on a display and played as audio. The study sets out the design requirements, the architecture, the decoding scheme and the build. It identifies the known constraints of the optical approach and the work required before the device can be used with its intended users.
1. Introduction
Care routines for people with partial paralysis are usually organised around fixed times. A meal, a drink or a toilet break happens when the routine says so. This works for predictable needs but leaves a gap for requests that arise between rounds. A person who wants water at nine in the morning must wait, or must attract a carer by a means that may be unavailable to them.
Eye movements are among the few voluntary movements that remain for many people with limited motor function. Eye-tracking systems are effective but often expensive and calibration-heavy. This project explored a simpler route: detect deliberate blinks with a low-cost optical sensor and map blink patterns to a small vocabulary of messages. The design goal was a device that is cheap to build, quick to learn and able to send clear requests at any time.
2. Design Requirements
The device was designed against four requirements. It had to use a small number of inexpensive, widely available components. It had to recognise deliberate blinks and reject involuntary ones by their timing. It had to map a small vocabulary of needs that a carer could learn quickly, with the mapping kept fixed so that the user is not required to remember a changing code. And it had to present each message clearly, on a display and as an audio prompt, so that the carer does not need to watch the device continuously.
3. System Architecture
The system has three functional stages: sensing, decoding and output. Figure 1 shows the architecture.
In the sensing stage, an infrared emitter directs light at the eye, and a photodiode receiver measures the reflected signal. When the eyelid closes, more light is reflected back to the receiver, so the received signal rises. The sensing stage therefore converts eyelid position into an analogue signal that changes with each blink.
In the decoding stage, a microcontroller thresholds the signal against a baseline measured at start-up, records each blink that lasts within a valid duration range, and groups blinks into sequences. A sequence ends when no further blink arrives within a fixed window.
In the output stage, each decoded message is shown on a display and played as an audio prompt, so that a carer nearby can respond without checking the device.
4. Blink Detection and Decoding
A blink is recognised when the signal stays above the threshold for longer than a minimum duration and then returns below it. The minimum duration rejects very short disturbances, and a maximum duration rejects sustained closure, which is not a deliberate signal. The sequence window groups blinks into one message. Figure 2 shows the decoding flow.
The vocabulary designed for the prototype was deliberately small:
One blink: “I want water.”
Two blinks: “I want food.”
Three blinks with the right eye: “I need to go out.”
The fixed mapping is a design choice. A larger vocabulary would give more options but would increase the number of patterns a user must produce reliably and the chance of misreading. The right-eye code is the least straightforward element of the scheme, because it requires the device to distinguish the two eyes, and the method used for this is part of the build documentation that should be restated precisely in any future paper.
5. Build and Prototype
The prototype was assembled from low-cost components, with the optical sensing module, the microcontroller and the display and audio output connected on a single frame. The sensing module is mounted at a fixed distance from the eye so that its position is repeatable. The firmware implements the threshold, the blink timing, the sequence window and the mapping, and it can be run from a standard power source.
The prototype was demonstrated at the Yarl Geek Challenge, where the project reached the finalist stage. The demonstration showed the decoding of the three-message vocabulary during live use with volunteers. No quantitative records of those demonstrations were kept, and this case study does not report any accuracy, false-trigger or latency figures.
6. Known Constraints
The optical approach has constraints that a future evaluation must measure. Infrared sensing is sensitive to ambient light, so sunlight may change the baseline. The sensor’s position relative to the eye affects the reflected signal, so the mounting must be repeatable and comfortable. Spectacles, eye conditions and eyelid shape may alter reflectance. The fixed threshold may need recalibration between users. And the vocabulary has been designed but not tested with users who have paralysis, so the ease of learning it is unknown.
7. Future Work
The next stage is a structured evaluation with partially paralysed users. It requires formal ethics approval, a protocol agreed with carers and clinicians, and measurement of accuracy, false triggers and decoding latency under realistic conditions, including lighting changes and fatigue. The evaluation should also record how long it takes a new user to learn the vocabulary. Until that work is done, the device should be described as a prototype and a design, not as a validated assistive technology.
8. Conclusion
This case study describes the design and build of a low-cost optical eye-blink communication device, from the problem and design requirements through to the architecture, decoding scheme and prototype. The design is a credible starting point for assistive communication for people with limited voluntary movement. Its performance with those users has not been measured in this work, and the next step is a formal evaluation under ethics approval.
Sources
This case study cites no external sources. Statements about care routines reflect the author’s project brief and observations, and the device’s competition recognition is stated as it occurred.