2D Barcode Scan Engines

2D barcode scan engine modules for embedded designers

An EDOO scan engine is an imager and a decoder on one board: you get the module, the command set and an SDK, and you design the window, the bezel and the cable around it. Choose on three numbers - the depth you can give it, the interface your main board exposes and the smallest bar code you must resolve. The tables below only carry figures we publish on that model's own page or datasheet; where we have no number we say so instead of inventing one.

Four questions that pick the model

• How much depth do you have? The 3.3 V micro engines fit into 7 - 10.6 mm; E5-32 is the exception at 19.5 mm because its interface board is separate. The 5 V window modules need 10.8 - 30 mm and are built for a flush opening in a panel.
• USB or serial? Every model here runs USB and TTL-232. RS-232 is an option or a custom build on E5-32, MF20-23P, MF21-23Z, MF22, MF26 and MF27; PS/2 appears only in the MF27 interface list.
• How small a code must it read? 3.3 mil on S70P-F, 3 mil on M1V2, M1W and M2A V2, 5 mil on M0V2, MF22, MF26 and MF27.
• Battery or mains? Standby current goes from 3.2 mA (E5-32) and 11 mA (M1V2 and M1W on USB) up to 40 - 60 mA (S70P-F, M0V2). The 5 V window modules draw 140 - 600 mA while scanning.

Micro engines: 3.3 V boards from 7 mm deep

Window and kiosk engines: 5 V, flush or recessed openings

Reading the table. Every figure comes from the linked product page or from that model's datasheet. † means the number is in our datasheet and not yet on the product page - we can add it. * means the datasheet and the product page use different names for the same engine - M2A V2 is listed as M2, M0V2 as M0, MF26 as MF26P, and MF27 as MF27-23Z in the datasheet - so quote the marking on the module itself when you order. "Not published - ask us" means we do not have a verified figure to print; we will send the measured value with the datasheet instead of guessing.

The M1 family: same housing, four different jobs

M1V2, M1W and M0V2 are the same 21.5 × 8.5 × 7.1 mm module with the same 13-pin FPC pinout, so you can change how the scanner behaves without redrawing the housing or the cable. What differs is the light thrown on the code, how wide an area the imager sees, and how much decoding sits behind the sensor. M1-R is the industrial take on the same idea in a 21 × 9 × 7.1 mm body.

White light versus red light is the choice people get wrong. Red illumination gives more contrast on a printed paper label and is cheaper to filter against ambient light; white illumination reads colour and glossy media, and is the safer default when the same terminal must read both a paper label and a phone screen. Field of view is the other trade: a wide field catches an unaimed code but puts fewer pixels on each bar, which is why the 3 mil models are the ones you specify for small symbols.

Screen codes, DPM marks and passports

Phone-screen reading is where most embedded projects fail, so the models above are tuned for it in different ways: M1V2, M1W, M2A V2 and M0V2 are calibrated for low-brightness screens behind protective film; MF22 publishes a 30 - 330 mm window on a payment code; MF26 and MF27 are built for e-payment QR in a kiosk faceplate. For direct-part marking on metal, use M1-R (red backlight, industrial algorithms, DPM QR) or S70P-F, which resolves 3.3 mil on paper, screen and DPM at a 10% print contrast. If you must read a passport MRZ line, look at E5 passport MRZ and MF31 long distance.

Integration: connector, SDK and firmware

• Connector. Micro engines terminate on a 0.5 mm-pitch FPC - 12-pin on S70P-F and MF26, 13-pin on M1V2, M1W and M0V2, with a pin map that keeps the common 12-pin bottom-contact footprint compatible, so an existing housing can be swapped.
• Host interface. USB comes up either as an HID keyboard (no driver, types the result) or as a virtual serial port (your application reads the frames); TTL-232 is 3.3 V logic on the same FPC, and RS-232 is optional or customised per model.
• Trigger and indication. Key (level or pulse) trigger, external nTrig input and command trigger; dedicated Beep and LED pins drive the buzzer and the decode indicator without a host GPIO.
• Firmware and images. Real-time snapshot with the decode result, and in-application (IAP) firmware upgrade through the command set.
• Bringing-up kit. Development board with trigger button and buzzer, USB cable and RS-232 cable are available per model, so you can validate the codes before opening the housing.
• Terms. 1-year warranty with remote technical support, SDK and datasheet provided, OEM and ODM orders welcome, minimum order quantity 1 piece on listed models.

Questions engineers ask us before they commit

Can I swap an existing engine without redrawing the housing?

Usually yes on the 12-pin side: M1V2, M1W, M0V2 and MF26 keep a 12-pin compatible pin order and 0.5 mm pitch, and MF26 and MF27 are explicitly designed to replace mainstream embedded engines in the same opening. Send us the connector of the engine you are replacing and we will map it pin by pin.

Which module should I choose for a phone-screen payment code?

MF22 for a deep window with a published 30 - 330 mm reading range, MF26 or MF27 for a flush kiosk faceplate, and S70P-F or M2A V2 when only 10 mm of depth is available. Screen brightness, film and window tint change the result, so we test your own screen before recommending.

Do you supply the SDK and a sample before a batch order?

Yes - SDK, command set and datasheet with the quote, and sample units (1 piece minimum order on listed models) so you can integrate first. Tell us the host system (Windows, Android or Linux), the interface your board exposes and the opening size, and we confirm the fit.

Tell us the device you are building and the codes it must read - send an inquiry or reach us on WhatsApp +86-18050089566.