A Bluetooth scanner appearing in a host's paired-device list proves only that an association was established. It does not prove that the scanner is connected now, that both sides selected the same Bluetooth profile, that decoded data reached the host, or that the target application accepted the input. Trace those stages in order before replacing hardware or repeatedly pairing the device.
Consider an Android tablet and a cordless scanner used at a receiving desk. The scanner name appears under paired devices and a decode beep sounds, but the receiving form stays empty. This is an editorial troubleshooting example, not an AIDC GO model demonstration. The next useful action depends on the last stage that can be evidenced.
Separate discovery, pairing and connection
Discovery is how a host finds a nearby device that is advertising or otherwise discoverable. Pairing or bonding creates an association and may store keys or trust information. Connection is the active communication session used by a particular profile or application interface.
Android's Companion Device Pairing documentation makes one boundary explicit: pairing does not create a connection by itself. An application must use the relevant Bluetooth or Wi-Fi APIs to establish communication. The documented API and permissions vary by Android version and implementation. Source: Android Developers, Companion device pairing
Record four observations separately:
- Does the scanner appear during discovery under its expected name or identifier?
- Does the host show it as paired or bonded?
- Does the host or scanner show an active connection for the intended profile?
- Does a complete scan arrive at the intended application input?
Removing and pairing again may change the second observation while leaving the third or fourth problem untouched.
Confirm the profile on both sides
“Bluetooth scanner” is not one data path. A scanner may offer a keyboard-like HID profile, a serial profile, or a vendor interface. The host and scanner must be configured for the same supported path.
Zebra's DS2278 Product Reference Guide is a device-specific example. It documents HID Bluetooth Classic and HID Bluetooth Low Energy for keyboard emulation, SSI modes for supported Zebra SDK applications, and Serial Port Profile modes. It also distinguishes discoverable peripheral modes from central modes that require a pairing barcode containing the host address. These are DS2278 conditions from that guide, not AIDC GO capabilities or universal Bluetooth behavior. Source: Zebra DS2278 Product Reference Guide, radio communications chapter
Ask for the exact scanner model, firmware, configured host type, host operating-system version and receiving application version. Keep the programming barcode or configuration file used for the profile with the test record. A paired entry left from an earlier HID setup does not prove that a later SSI or serial configuration is connected.
Find whether data reaches the host
For a keyboard-emulation path, open a permitted plain text field and scan a known short barcode. Record the characters, prefix, suffix and terminator. If nothing appears, check active connection state, the selected profile and whether the scanner is sending to a different host. If text appears in the plain field but not in the business form, the radio path may be working while the target application's focus or field behavior is not.
For a vendor application interface, use the documented status or diagnostic view for that specific product and software version. Do not treat a successful decode beep as evidence that an application callback or business event arrived. The device can decode while the profile, service or application receiver is inactive.
Zebra's TC22/TC27 Product Reference Guide documents a scan-to-text workflow in which the DS2278 is paired with the device, a scan-enabled app is open and a text field is in focus before captured data appears in that field. This is a documented scan-to-text workflow for the named Zebra environment; the appearance of data in a text field does not by itself identify the Bluetooth profile. It should not be generalized into a promise for another scanner or application. Source: Zebra TC22/TC27 Product Reference Guide, Scanning with the DS2278, printed pages 87–88
Check the application's selected input and state
The application may have an input profile that selects an internal imager, an external scanner or an automatic choice. It may also require a particular activity, field, receiver or service to be active.
Zebra DataWedge, for example, documents a scanner-selection list and states that a Bluetooth scanner may remain enabled in a profile even while disconnected. It also documents conditions for supported scanner models and minimum firmware in some external-scanner arrangements. Those details apply to the listed Zebra devices and DataWedge versions, not to AIDC GO hardware or an arbitrary Android application. Source: Zebra TechDocs, DataWedge Barcode Input
For the receiving form, verify:
- the intended screen and input field are active;
- the application selected the intended scanner or profile;
- the received value is not being routed to another field or background component;
- prefixes, suffixes and terminators match the application's parsing rule;
- the application reports whether the value was accepted, rejected or ignored.
The Wedge vs Intent vs SDK guide compares these application delivery paths. Use it after confirming which Bluetooth profile is carrying the data.
Follow one complete host-and-scanner example
Use this sequence for the editorial Android tablet and cordless-scanner example. Substitute the real manufacturer's instructions and supported versions for the actual project.
| Stage | Evidence to retain | If it fails, inspect next |
|---|---|---|
| Discovery | Host scan showing the expected scanner identity; scanner in the documented discoverable mode. | Power, range, discoverable/central mode and whether the scanner is already connected elsewhere. |
| Pairing or bond | Host entry with the expected identity and time; any required confirmation completed. | Remove only the identified stale association, then follow the model's pairing procedure. |
| Active profile connection | Host or vendor status naming HID, serial or vendor interface; scanner indicator if documented. | Confirm both endpoints use the same profile and required service or application is running. |
| Host receives a known scan | Exact characters in an approved diagnostic or plain input, including terminator. | Check profile output, connected host, configuration and complete transmission. |
| Target application receives it | Expected field or event contains the same value once. | Check focus, scanner selection, receiver registration, parsing and lifecycle state. |
| Business workflow accepts it | Application shows the intended item and authoritative outcome. | Check validation, mapping, permissions, backend response and exception handling. |
Do not mix evidence from different profile configurations. If the scanner is reprogrammed during diagnosis, start a new observation set and record the new configuration.
Diagnose reconnection without assuming it is automatic
After a power cycle, suspend or out-of-range event, verify whether the active connection returns and whether the application selects the scanner again. Reconnection behavior depends on scanner mode, host stack, profile, application and software versions.
The DS2278 guide documents auto-reconnect settings for that scanner, while DataWedge documents cases where it does not automatically switch back to a Bluetooth scanner. These are precisely why a project should not assume that “paired” means “will always reconnect.” Confirm the required behavior for the actual combination and test the events the workflow must survive.
If a scan was decoded during a disconnect, do not assume it will later reach the application unless the exact scanner mode and application path document and demonstrate that behavior. The offline capture and unconfirmed transaction guide covers the separate question of whether the backend may have processed a transaction when confirmation is missing.
Turn the last proven stage into a supplier question
Send the scanner model and firmware, host model and OS build, chosen profile, pairing method, application version and a timestamped stage record. Include a representative barcode value and what the application should display. State whether the failure occurs after initial setup, restart, suspend, leaving range or an application update.
If the project still needs to choose between an external scanner and an integrated device, use the mobile computer versus barcode scanner guide and review the handheld terminal category. For an interface-specific review, send the required profile and application behavior through Integration Support or Contact AIDC GO.
AIDC GO can discuss a hardware direction and the documentation needed for the selected model. This article does not claim that an AIDC GO model supports every Bluetooth profile, automatically reconnects, pairs with every host or delivers data to every application.
The useful diagnosis is the last stage that succeeded and the first stage that did not. “Paired” is one observation in that chain, not the end of the investigation.