Introduction
StayLinked supports a huge range of mobile devices and scanners. Most of these devices will automatically detect the difference between scan and keyboard inputs. Differentiating input types allows StayLinked to apply scan input adjustments like automatic returns as well as making the Client-Server transactions more reliable and efficient (See Input Types, below).
The first step is to use the StayLinked Client scan test. StayLinked clients come in two general forms, customized and generic. The custom clients are developed with the hardware in mind. Support for the device keyboard, radio and scan engine are included in the client. Custom clients work through the operating system to communicate with the hardware, and natively support various features. Generic clients do not contain these specific features and have limited capabilities when attempting to interface with the device hardware. Some custom clients do not include scanner support or may be used with any number of attached external scanners.
General Overview:
- Install StayLinked client on your device.
- Test the scanner using the StayLinked Client Scan Test.
- If the scan data appears in the scan test, stop.
- If scan data does not appear, see below for configuration options.
- Enable the required Intents (Zebra/DataLogic), Scan Configuration scanner.ini (Honeywell), Scanner-as-Wedge, or AutoWedge settings on your device.
- Retest the scanner using the client scan test. Check your configuration if data still does not appear in the test. Be sure to test with multiple barcodes to make sure the issue is not specific to a barcode symbology or contents.
Additional configuration may also be required to see the symbology or barcode type.
Testing Scan Input
All StayLinked clients include a scanner and keyboard test. Using these tests, you can see what data appears as scanner or keyboard input. It is possible on some devices that scan input will appear in both the scan and keyboard tests. This makes the scan test the best confirmation that the data is recognized as a scan. Data appearing in both places will only be transmitted to the server as scan data.
StayLinked also offers a Server-side scan test. The test is available from the StayLinked Menu (see user experience guide for more details on the StayLinked Menu). This menu is executed during a session from the Tools Menu or using a keyboard map entry. The client-side scan test shows the exact data as it is provided by the device. The Server-side test shows the barcode data, length, type, and a trans field that shows the data after any server-side rules are applied.
Input Types
The primary feature in any StayLinked Client is to reliably transmit user inputs to the StayLinked Server in the order they are input. These inputs can be come from the keyboard, command, voice, scanner or touch screen. Each transaction is submitted to the StayLinked Server with a sequence number, and each client has a limit to the number of transactions it can buffer. This buffer defaults to 16 transactions on most devices.
Each tap or keyboard input is transmitted to the Server as a single transaction. Each barcode scan is one transaction, except when scanning is not configured and the data appears as high-speed keyboard input. This means that a 12-digit barcode is either a single 12-digit scan transaction or 12 one-digit keyboard transactions. This transaction buffer can be easily overflowed causing data to be lost when scanning long barcodes, providing input during weak network connectivity, or when scanning multiple barcodes in quick succession.
StayLinked iQ features and Statistics Logging can show information about how many transactions are being entered as keyboard input and scans. Individual log files for the ‘Session’ and ‘Handler‘ log files will show on a case-by case basis which entries are submitted as scan data or keyboard input. StayLinked iQ features are described in the iQ documentation, statistics logged is enabled from the Usage Tracking features and the session-specific logs are enabled in Server Settings but can be viewed from the Connections List.
The following are examples of the same barcode input, first as a proper scan transaction and then as it would appear if it was submitted as keyboard input. These log entries are pulled from the StayLinkedHandler.log file from a common mobile device.
Scan:
09/16/2016 10:47:25:218 - esp_ProcessDeviceInput() - RECV: (000C) 'AD~12~0~08~05244410~’~'
Wedge:
09/16/2016 10:47:56:027 - esp_ProcessDeviceInput() - RECV: (0005) 'AC~414101~Ú~' “A”
09/16/2016 10:47:56:138 - esp_ProcessDeviceInput() - RECV: (0006) 'AC~303000~˜~'
09/16/2016 10:47:56:298 - esp_ProcessDeviceInput() - RECV: (0007) 'AC~353500~E~'
09/16/2016 10:47:56:411 - esp_ProcessDeviceInput() - RECV: (0008) 'AC~323200~Ü~'
09/16/2016 10:47:56:472 - esp_ProcessDeviceInput() - RECV: (0009) 'AC~343400~S~'
09/16/2016 10:47:56:585 - esp_ProcessDeviceInput() - RECV: (000A) 'AC~343400~C~'
09/16/2016 10:47:56:749 - esp_ProcessDeviceInput() - RECV: (000B) 'AC~343400~Ö~'
09/16/2016 10:47:56:862 - esp_ProcessDeviceInput() - RECV: (000C) 'AC~313100~_~'
09/16/2016 10:47:56:918 - esp_ProcessDeviceInput() - RECV: (000D) 'AC~303000~”~'
The scan entry shows the input type as AD, while the keyboard inputs appear as AC. You can see that the keyboard transactions appear within milliseconds, though a high-latency connection could impact what the user sees at the device. In this case, the characters might appear one at a time or in short bursts of network communications.
While not obvious in this log, you would also see the first character transmitted is a capital A. This represents the symbology type that was included by the scan engine and is normally removed during the transaction to populate the symbology type in the StayLinked Client. ASCI character values are included in red to demonstrate the barcode data.
Requiring Scan Input
Once scan input can be differentiated from keyboard input, StayLinked can use IBM host field attributes or Screen Recognition features to restrict input based on input method. This can be used to prevent users from typing data that should be scanned. Other options are available, but the use of the barcode scanner is the most common goal of handheld mobile devices in most cases.
The entire set of Scan Configuration Guide features and functions are described in detail in the many article links listed below.
Making Adjustments to Scan Input
Scanner as Wedge
Autowedge
Scan Engine Settings
Android Devices by Honeywell
Android Devices by Zebra
Android Devices by DataLogic
Android Devices by Cipherlab
SPP BlueTooth Scanners
Appendix – Symbol – Motorola Scanner.ini
Share the post "Scan Configuration Guide"