A barcode demonstration proves only what was captured under that exact combination of label, scanner, configuration and application. It does not prove that every symbol used by the project is supported, enabled or accepted. Before choosing a handheld, identify the symbols that appear in the real workflow, the decoder settings that apply to them, and the value the application is expected to accept.
This guide is for integrators and procurement teams comparing mobile barcode configurations. It separates four questions that are often collapsed into “does it scan?”: can the selected capture device recognise the symbol family, is the decoder enabled in the active profile, do its parameters match the label, and does the receiving application accept the resulting value?
Start with the symbols in the work, not a generic capability list
Build a sample set from the actual receiving, picking, production or service process. Record the symbology for each sample, the expected value, the label size and condition, and the screen or field where it will be used. Include a known-good sample for every required symbol family and a deliberately out-of-scope symbol that should not be accepted.
A product statement such as “1D/2D barcode scanning” is a direction for evaluation, not a complete configuration contract. The selected engine, firmware, operating system and capture service can affect the available decoders and parameters. Zebra’s versioned DataWedge 15.0 Barcode Input documentation likewise separates scanner selection from the decoders applied to acquired data and warns that decoder-parameter support can vary with the selected scanning device. That vendor example explains the layers; it is not evidence that an AIDC GO model has the same options.
Ask for the exact model and scan-engine option, the applicable configuration guide and the list of supported decoder settings for that build. If the project cannot name its symbols, collect representative labels before trying to select a model.
Separate supported, enabled and correctly parameterised
“Supported” usually describes what a documented hardware and software combination can decode. “Enabled” describes what the active application profile is currently allowed to try. “Correctly parameterised” adds the length, check-digit, supplement, composite or other settings that may change whether a particular label is accepted or how its value is reported.
The distinction matters because an easy Code 128 demonstration can succeed while a required GS1 DataBar, postal or composite symbol remains disabled. Conversely, enabling a broad set of decoders does not prove that the application will receive the intended identifier. Zebra’s DataWedge 15.0 decoder documentation exposes decoder-specific parameters, while its profile guidance associates decoder selections with applications. Treat those details as evidence for DataWedge 15.0 only.
At API level, format selection can also be explicit. Google’s ML Kit barcode-scanning guide describes choosing all supported formats or restricting the detector to selected formats. That is a camera/API example, not an industrial scan-engine specification, but it demonstrates why “the library supports it” and “this application is configured to look for it” are different claims.
Follow one failed label through the four decision points
Consider an editorial receiving example. A supplier carton has a linear logistics symbol and a nearby QR code for a web page. The receiving application needs the logistics identifier only. The handheld reads the QR code in a test utility but does not populate the receiving field from the linear symbol.
First, identify both symbols from the supplier artwork or a verified label report rather than guessing from appearance. Second, confirm that the active capture device and software build document the required linear decoder. Third, inspect the application-linked profile and its decoder parameters. Fourth, capture the raw result and the receiving application’s acceptance response separately.
If the test utility works but the receiving screen does not, the difference may be profile association, output method, field focus or application validation. Continue with Barcode Scanner Integration: Wedge vs Intent vs SDK for the delivery path. If several nearby symbols compete for selection, use Several Barcodes on One Label to define the target. Neither investigation should be replaced by enabling every decoder and accepting whichever value appears first.
Use a comparison record that keeps evidence at the right layer
| Observation | What it supports | What it does not establish |
|---|---|---|
| A named sample decodes in the vendor test utility | What this supports: The tested device, build and utility produced a value for that sample | Limit: This does not establish that the project application uses the same profile, parameters or output path. |
| The required decoder is listed for the exact configuration | What this supports: The documentation includes that symbol family under stated conditions | Limit: This does not establish that the decoder is enabled in the deployed profile or that every parameter is suitable. |
| The active profile shows the decoder and agreed parameters | What this supports: The captured configuration is prepared to attempt the required symbol | Limit: This does not establish that the printed symbol has adequate quality or that the business value is correct. |
| The application accepts the expected value and rejects controls | What this supports: The tested end-to-end path enforced the recorded sample contract | Limit: This does not establish that other labels, builds, models or application versions will behave the same. |
Save the model and engine identifiers, OS and capture-service versions, profile export or screenshots, label sample ID, decoded raw value and application result together. A passing row without those identities is difficult to reproduce after a device replacement or application update.
Test positive, negative and boundary samples
For each required symbol, use at least one known-good sample and one controlled negative. A negative might be an intentionally disabled symbol, a value with the wrong length, or a neighbouring symbol that the workflow must ignore. The purpose is not to prove universal performance; it is to show that the active configuration distinguishes the project’s accepted and rejected inputs.
Keep label-quality assessment separate. A decoder can be enabled while a damaged or poorly printed symbol remains unsuitable. Use Barcode Scanning vs Verification when the project needs print-quality evidence, and Barcode Label and Scanner Selection Basics for label size, placement and working-condition inputs.
Run the same set in the real application, not only a diagnostic screen. Record whether the raw value arrived, whether transformations changed it, whether the field accepted it, and which message the operator saw. A beep or green light can represent decode feedback without proving that the business record was accepted.
Bring a reproducible decoder brief to the hardware discussion
Before requesting a handheld configuration, provide the label samples or shareable artwork, named symbologies, expected values, working distances and the target application screens. Add the current device and scan-engine option if known, the OS and capture-service versions, the output method and any existing profile export.
Ask AIDC GO to identify the product configuration and documentation relevant to those inputs. The Rugged Handheld Terminals page provides the current product direction; exact symbology, engine and software support still require confirmation for the proposed model and deployment country. Use Integration & Support to frame the versioned application question, then contact AIDC GO with the sample list and unresolved configuration points.
Approve the configuration only after the required symbols, decoder settings and application outcomes are tied to the same tested build. That creates a defensible purchasing record without turning one successful scan into a promise about every label or workflow.