A kiosk integrator usually orders one QR scanner module, wires it to a USB port, waves a phone in front of it, and calls it validated when the beep comes. Three weeks later the unit is in a housing with a 3 mm acrylic window, the phone is a different model at 30% brightness, and the same code reads once out of five tries.
The module did not get worse. The test was never representative of the final assembly.
This is the sequence we recommend to anyone evaluating an embedded QR module for a kiosk, locker, vending machine, or access terminal — and the record to keep so the result means something after the sample is returned.
1. Define the test before powering up the sample
Pick codes from your own application instead of a supplier's demonstration QR. Record symbology, expected data, physical size, and operating conditions. A QR with less data has fewer modules; two codes of identical outer dimensions are not equally easy to read.
Write down four things first:
- Application and mounting: where the user presents the phone or label, space behind the panel, expected distance and angle.
- Codes: QR, Data Matrix, or others, including the small and dense examples your project actually uses.
- Sample version: model, interface, firmware, cable, configuration, supply voltage.
- Acceptance criteria: allowed time for a correct read, attempts per condition, how duplicates are handled.
Use one procedure for every candidate so the comparison stays honest. A first trial of 100 presentations under one defined condition is a working example, not a sample size that certifies reliability — production approval needs a validation plan sized to the risk.
2. Test screens and printed labels separately
A good read from paper proves nothing about a phone screen. Test several devices that represent your users, and change one variable at a time: keep the code fixed while you vary brightness or distance, then increase data density or shrink the displayed size.
| Variable | What to compare | What to record |
|---|---|---|
| Screen | Several phones, low/medium/high brightness, common screen protectors | Device, brightness, displayed QR size, result |
| Presentation | Distance, tilt, centering, hand movement | Position, orientation, time to correct read |
| Paper | Real labels, contrast, wrinkles, finishes from your process | Symbology, size, material, label condition |
| Lighting | Normal illumination and reflections at the installation | Light position, whether glare falls on the code |
| Configuration | Trigger mode and enabled symbologies | Config profile, so the test is repeatable |
Sample codes help here: ours encode plain test text and open no website, so you can verify data output without touching production data. They are not certified targets and do not replace codes from your application.
Example test codes. The expected data is printed below each one; in the second example the payload is a single string and the line break is display only.
3. Repeat the test with the front window installed
Compare the bare sample with the final glass or acrylic window, bracket, and seals in place. A window adds reflections, cuts light transmission, and can clip the field of view. No single panel thickness or mounting distance works for every module.
- Check the reading area from positions where users actually present a code, not only dead centre.
- Inspect edges, screws and seals that could obstruct the optical path; leave clearance for the connector and cable bend radius.
- Repeat the relevant conditions with a clean surface and with contamination typical of your maintenance interval.
- If it reads without the window and fails behind it, review material, angle, shielding and mounting before changing modules.
4. Check the data your application receives
A beep is not an approval. Compare received text with expected data, watch for truncated characters, unexpected suffixes and duplicate reads, and separate decode time from the time your application takes to validate and respond.
USB HID and virtual COM. For HID, confirm keyboard layout and test the characters your software actually uses. For VCP, verify the driver where needed, the data format, and recovery after unplug/replug — on the final operating system and hardware.
TTL and RS-232. Never wire a TTL signal straight into an RS-232 port; the levels differ. Confirm interface variant, pinout, logic level, supply voltage and serial settings. If conversion is needed, use a circuit designed for it.
Power and the complete system. Repeat with the intended supply, wiring and peripherals. Watch startup, idle, wake-up and behaviour under terminal activity, always inside datasheet limits. A voltage sag when another load switches on can break reads even when the code is perfect.
If you plan RS-485, Ethernet or wireless, confirm protocol, addressing and reconnect behaviour as well. An interface existing on the module does not mean your application can talk to it without configuration.
5. Record comparable results before ordering a batch
Define what counts as an attempt and what counts as correct. A useful metric is the first-attempt correct-read rate: attempts returning the exact data inside the agreed time window, divided by total attempts, times 100. Record wrong data, duplicates and timing too — do not collapse everything into "reads" or "does not read".
97 correct first attempts out of 100 presentations is 97% under that condition. It does not establish 97% across all phones or assemblies. If a critical condition fails, log it and agree the correction before approving the sample.
| Field | Keep |
|---|---|
| Sample | Model, unit ID, interface, firmware, configuration |
| Condition | Code, size, phone or paper, distance, angle, lighting, panel |
| Result | Attempts, exact first-attempt reads, errors, duplicates, timing |
| Decision | Approved for defined condition / correction pending / rejected, owner, date |
Keep the approved configuration with the record. Before volume production, add the endurance, environmental and unit-to-unit variation tests your equipment requires.
Which module should you request as a sample?
Shortlist by space, interface and codes, then validate. For shallow front panels the E600 is the usual starting point; for vending integration the F4100; for compact panels with optional NFC, the XL-F24MINI-NFC. These are evaluation starting points, not a guarantee that a version fits your design.
FAQ
Is one phone enough? No. Pick phones and conditions that represent your users, document what you tested, and widen the set if results split by screen, brightness or protector.
Can I approve the reader before the final window exists? You can shortlist on the bench, but repeat the optical tests with the real panel and mounting position before finishing the integration.
Does a module that reads payment QR codes process the payment? No. Reading captures data; authorisation and settlement belong to the payment system. Do not infer payment capability from a successful decode.
Full guide with the test tables and the sample-code download: How to Test a QR Scanner Module Before Kiosk Integration
