How to Integrate an Iris Recognition Module into Your Access Control System

Integration Overview

Adding iris recognition to an access control system follows the same general pattern as integrating any biometric reader: mount the hardware, wire it to the controller, install the SDK, configure enrollment, and test. The specifics vary depending on whether you are working with a USB module like the HOMSH MD31 or an embedded FPC module like the MI30. This guide covers both paths in detail.

The typical integration timeline is two to five days for an experienced access control technician — one day for hardware installation, one to two days for software integration and configuration, and one to two days for enrollment and testing.

Hardware Requirements

Common Requirements

• Access control panel: Any standard panel that accepts Wiegand (26/34-bit), RS485, OSDP, or TCP/IP input. Common brands include HID, Honeywell, Lenel, Gallagher, and ZKTeco.
• Mounting hardware: The module needs a rigid mounting surface at the correct height. For wall-mounted access points, the camera lens should be positioned at 120 to 160 cm from floor level (adjustable with tilt bracket to accommodate different user heights). Some integrators mount at a fixed height and rely on the module's vertical capture range.
• Power supply: Requirements differ by module. The MD31 draws power via USB (under 4W). The MI30 requires 3.3V DC at 3.2W maximum from the host PCB.
• Network connectivity (optional): For centralized enrollment management or remote template syncing, an Ethernet or Wi-Fi connection to the host controller is needed. The iris module itself does not require network access — all matching is performed on-device.

USB Integration (MD31)

The MD31 connects to any host system with a USB 2.0 port. This is the simplest integration path:

• Host system: Windows PC, Linux SBC (Raspberry Pi, Jetson Nano), or Android device with USB host support
• USB cable: Standard Type-A, up to 3 meters without a hub (5 meters with active extension)
• Mounting: M2 screw holes on the rear housing, compatible with standard VESA adapter plates or custom 3D-printed brackets

FPC Integration (MI30)

The MI30 connects directly to a host PCB via a 20-pin FPC ribbon cable. This path is designed for embedded products:

• Host PCB: Must provide a matching 20-pin FPC connector (0.5mm pitch, bottom-contact)
• Power: 3.3V regulated DC supply capable of 1A peak current
• Communication: UART TX/RX lines at 3.3V logic levels (115200 baud default)
• GPIO: Wake input, status output, and match-result lines for hardware-level integration

Wiegand Protocol Wiring

For integrators connecting to standard access control panels, the most common approach is to use the iris module as a reader that outputs Wiegand credentials upon successful identification.

Wiring Diagram (Textual)

The connection between the iris module host and the access control panel uses four wires:

• DATA0 (Green wire): Connects from the host controller's Wiegand output to the access panel's DATA0/D0 input terminal
• DATA1 (White wire): Connects from the host controller's Wiegand output to the access panel's DATA1/D1 input terminal
• GND (Black wire): Common ground between the host controller and access panel — this is critical for signal integrity
• Shield (Drain wire): If using shielded cable, connect the drain to ground at the panel end only to avoid ground loops

Maximum cable run for Wiegand is 150 meters (500 feet) using 22 AWG shielded cable. For runs over 75 meters, use twisted-pair cable with a dedicated ground conductor. The host controller software converts the iris template match result into a Wiegand card number that the access panel processes like any other credential.

USB Integration: MD31 Step-by-Step

1. Physical mounting: Secure the MD31 to the wall or kiosk panel using the M2 mounting holes. Ensure the lens window is unobstructed and positioned at the target user eye height. The capture distance is 20 to 35 cm from the lens.
2. USB connection: Connect the USB cable from the MD31 to the host controller. The module will enumerate as a composite USB device (camera + serial). Verify detection with lsusb on Linux or Device Manager on Windows.
3. Driver installation: On Windows, install the provided USB driver package. On Linux (kernel 4.15+), the module is recognized automatically using standard UVC and CDC-ACM drivers — no additional installation required.
4. SDK installation: Extract the SDK package to your development environment. The SDK includes libraries for C/C++ (.so/.dll), Java (.jar), and Python (wheel package). Install the appropriate library for your platform.
5. Initialize the module: Call the SDK initialization function with the USB device path. The module performs a self-test (LED blinks green on success) and reports its firmware version, serial number, and template database status.
6. Configure parameters: Set the identification threshold (recommended: 0.85 for standard security, 0.92 for high security), the maximum capture timeout (default: 5 seconds), and the Wiegand output format if applicable.

FPC Integration: MI30 Step-by-Step

1. PCB preparation: Ensure your host PCB has the 20-pin FPC connector populated and the UART, power, and GPIO lines routed according to the MI30 pinout specification. Verify 3.3V power rail stability under load — the MI30 draws up to 970mA during active capture.
2. FPC cable connection: Connect the 20-pin FPC ribbon cable between the MI30 and the host PCB. The cable locks with a flip-lock connector on both ends. Ensure the cable is not kinked or under tension, as FPC cables are fragile.
3. Power-on sequence: Apply power to the host PCB. The MI30 initializes in approximately 800ms. Monitor the UART for the ready status byte (0xAA) or check the STATUS GPIO line (high = ready).
4. UART communication: Send commands using the binary protocol documented in the SDK. Each command is a fixed-format packet: header (2 bytes) + command ID (1 byte) + payload length (2 bytes) + payload (variable) + CRC16 (2 bytes). The module responds with the same format.
5. Low-power mode: For battery-powered applications like smart locks, configure the wake-on-approach feature. The MI30 drops to under 50mW in standby and wakes via the WAKE GPIO line (triggered by a PIR sensor or proximity detector). Full wake-to-ready time is under 300ms.
6. GPIO integration: For MCU-based systems that cannot run the full SDK, use the hardware-level interface. Configure the MI30 to output a match result on the MATCH GPIO line (high = match, with configurable pulse duration). The enrolled user's ID is simultaneously output on UART for logging.

SDK Overview and API Basics

The HOMSH iris SDK provides a consistent API across all supported platforms. The core workflow involves five function groups:

• Device management: init(), getDeviceInfo(), setConfig(), reset()
• Enrollment: startEnrollment(), captureIris(), generateTemplate(), storeTemplate(userID)
• Identification: startIdentification(), identify() returns userID and confidence score
• Verification: verify(userID) returns match result and confidence score
• Template management: exportTemplate(userID), importTemplate(data), deleteTemplate(userID), getTemplateCount()

All functions are synchronous with configurable timeouts. Callback-based asynchronous variants are available for GUI applications that must not block the main thread.

Enrollment Process

Enrollment is the process of capturing a user's iris pattern and storing it as a mathematical template. A well-executed enrollment is critical — a poor-quality template causes ongoing false rejections.

1. Position the user: The subject should stand at the module's optimal capture distance (marked on the housing or indicated by the LED guide). Both eyes should be fully open and looking directly at the camera.
2. Capture sequence: The SDK automatically captures multiple frames (typically 3 to 5) and selects the best-quality image based on focus, iris visibility, and occlusion score. This takes 1 to 3 seconds.
3. Template generation: The on-device algorithm extracts the iris code — a 512-byte binary representation of the iris pattern. This template is not a photograph and cannot be reverse-engineered into an image.
4. Quality check: The SDK returns a quality score (0 to 100). Templates scoring below 60 should be rejected and recaptured. Scores above 80 are considered excellent.
5. Storage: The template is stored in the module's onboard flash memory (capacity: 10,000 templates on MD31, 5,000 on MI30) indexed by a user ID. Templates can also be exported to the host system's database for backup or multi-device synchronization.

For deployments with multiple access points, templates enrolled on one module can be exported and imported to other modules. The template format is proprietary but consistent across all HOMSH modules — an MD31-enrolled template works on an MI30 and vice versa.

Testing and Commissioning

Before going live, run these verification steps:

1. False rejection test: Have each enrolled user attempt identification 10 times under normal conditions. The success rate should be 98 percent or higher. If any user consistently fails, re-enroll them with attention to capture quality.
2. False acceptance test: Have 20 non-enrolled individuals attempt identification. The system should reject all of them. Even one false acceptance warrants investigation — check the threshold setting and template database for corruption.
3. Environmental test: Test under all lighting conditions the installation will experience. NIR-based iris modules are largely immune to ambient light variation, but direct sunlight on the lens can cause issues. Verify operation at the extremes.
4. Throughput test: Simulate peak traffic by having users queue and scan sequentially. Measure the average time from approach to door release. Target: under 2 seconds per user including door controller relay time.
5. Failover test: Verify the system behavior when the module loses power, USB connection, or communication with the access panel. Confirm that the fail-secure or fail-safe behavior matches the site security policy.

Common Integration Pitfalls and Solutions

Problem: High false rejection rate after deployment

Cause: Poor enrollment quality, often because enrollment was done in a rush with poor lighting or positioning. Solution: Re-enroll affected users with attention to the SDK quality score. Require a minimum score of 70 for all templates.

Problem: Module not detected on USB (MD31)

Cause: USB cable too long, using a charge-only cable (no data lines), or USB hub without sufficient power. Solution: Use a data-grade USB cable under 3 meters. If using a hub, ensure it is powered and USB 2.0 compliant.

Problem: Intermittent UART communication errors (MI30)

Cause: Ground bounce or insufficient decoupling on the 3.3V power rail. Solution: Add 100uF bulk and 100nF bypass capacitors close to the MI30 power pins. Ensure the UART ground is connected with a short, direct trace.

Problem: Slow identification with large template databases

Cause: Linear search through all templates. Solution: The module's built-in algorithm uses an optimized search with early termination. If identification time exceeds 1.5 seconds, check that the firmware is up to date and the template database is not fragmented. The SDK provides a defragmentDatabase() function for maintenance.

Problem: Wiegand output not recognized by access panel

Cause: Mismatched Wiegand format (26-bit vs 34-bit) or incorrect facility code. Solution: Configure the host software to output the same Wiegand format that the access panel expects. Verify with an oscilloscope or Wiegand test tool that DATA0 and DATA1 signals are clean and correctly timed.

Next Steps

Once the system is commissioned and tested, document the installation including module serial numbers, firmware versions, SDK version, threshold settings, and enrollment statistics. This documentation is invaluable for future maintenance and troubleshooting.

For technical support during integration, HOMSH provides direct engineering support via email and WhatsApp for all module purchasers. Custom firmware modifications and protocol adaptations are available for volume OEM customers.