Techniques for interfacing a bar code scanner to a PC using...

Details Techniques for interfacing a bar code scanner to a PC using... Techniques for interfacing a bar code scanner to a PC using...

2000-07-14

2003-03-25

Tremblay, Mark (Department: 2876)

Registers

Coded record sensors

Particular sensor structure

Reexamination Certificate

active

06536666

ABSTRACT:

FIELD OF THE INVENTION
To The invention relates generally to bar code scanners, and more specifically, to techniques for interfacing bar code scanners with computers.
BACKGROUND OF THE INVENTION
For years, various bar code scanner manufacturers have been selling keyboard-wedge bar code scanners. With reference to
FIG. 1
, bar code scanner
108
is connected to a personal computer (PC)
100
keyboard controller port
104
and a computer keyboard
110
in an Y or wedge type configuration. Bar code scanner
108
may contain an on-board processor
109
. PC
100
also contains a processor
101
. The Y or wedge type configuration is implemented using interconnection cable
106
. A first section of interconnection cable connects keyboard controller port
104
to bar code scanner
108
, and a second section of interconnection cable connects bar code scanner
108
to computer keyboard
110
.
From a conceptual standpoint, imagine that a digital switch
105
(within bar code scanner
108
) is set up to selectively connect and disconnect the first section of interconnection cable
106
to the second section of interconnection cable
106
. When the digital switch
105
is in a closed state, the keyboard controller port
104
is connected to bar code scanner
108
and computer keyboard
110
via the first and second sections of interconnection cable
106
. When the digital switch
105
is in an open state, the keyboard controller port
104
is only connected to the bar code scanner
108
, and the keyboard
110
is isolated from the bar code scanner
108
as well as the keyboard controller port
104
.
When digital switch
105
is in the closed state, computer keyboard
110
and bar code scanner
108
are placed in parallel across controller port
104
. This parallel configuration is used because keyboard controller
102
circuitry within presently-existing PCs (personal computers)
100
and laptop computers attempts to detect the existence of a computer keyboard
110
connected to the keyboard controller port
104
. The controller port
104
needs to be connected to a computer keyboard
110
, even if the keyboard is not to be used for subsequent data entry, and even if the controller port
104
is also connected to an input device other than a computer keyboard. If the keyboard controller
102
circuitry does not detect a keyboard connected to the controller port
104
, the PC
100
and/or laptop may then disable the port, preventing any further inputting of data. In the operational environment of
FIG. 1
, this disablement poses a problem, because we desire to input further data as bar codes are detected and decoded.
In actuality, the use of a digital switch
105
to completely isolate the keyboard from the keyboard controller port is an over-simplification, presented for purposes of conceptual expediency. Real-world systems may isolate the keyboard using any of a variety of techniques. However, a common approach is to bring the keyboard clock line to a logic “low” state, while allowing the keyboard data line to float “high”. In practice, connections between the LED status indicator lamps (num-lock, caps-lock, and scroll-lock) and the keyboard controller port may remain in place, even while the keyboard is inhibited.
With the increasing use of laptop computers and keyless data entry, the keyboard controller port shows great potential as a convenient, somewhat standardized, and readily available data input channel. However, this potential could be advantageously exploited only if it were possible to find some way around the necessity of connecting this port to an actual computer keyboard. By way of clarification, there are a number of existing programs that do not require the use of a computer keyboard per se, but these programs have neglected to provide mechanisms by which a computer keyboard is emulated, so as to prevent the controller port from being disabled.
Assume that a conventional keyboard wedge bar code scanner is connected to a keyboard controller port of a PC or laptop, as shown in
FIG. 1
, while, at the same time, the keyboard that is connected in the parallel (Y) configuration is eliminated. Will the hardware configuration of
FIG. 1
still function as desired? It is important to realize that keyboard-to-PC communications is implemented by means of a 2-way channel. Other types of data must be communicated between the PC and the keyboard in addition to information specifying the key or keys that were pressed. When a PC is powered up, the PC is programmed to check for the existence of a primary data input device, which is typically a keyboard. The PC begins a data exchange with the keyboard, and this communication is called “power-on diagnostics”. If the keyboard is not present, or if the power-on diagnostics fail, the PC will not boot up. Accordingly, if a normal boot-up is desired, the keyboard shown in
FIG. 1
should not be eliminated. In the case of laptop computers, a similar situation exists. A communication protocol is used to sense the presence of an external keyboard that is connected to the laptop's external keyboard port. If the laptop computer fails to detect a keyboard at the external keyboard port, then the laptop computer may disable its external keyboard port.
Even if a technique were to be developed by which a bar code scanner could successfully emulate a computer keyboard during boot-up, another problem would then arise. Eleven (11)-bit transmission protocols are utilized almost universally to provide keyboard to PC data transfer. The transmission protocol begins with a Start bit (low), followed by 8 data bits (these bits represent a scan code which, in turn, could be used to represent a portion of a detected bar code or a key press), a Parity bit (odd parity) and finally a Stop bit (high). Three of these 11-bit “bytes” are used to represent a “character”. Problems arise because this protocol allows the PC (or laptop) to interrupt the transmitted sequence up through the 9
th
bit.
If the keyboard
110
or keyboard wedge scanner (i.e., bar code scanner
108
) begins transmitting a data byte, the PC can prevent the successful communication of that byte, up to and including the 9
th
th transmitted bit. To make matters worse, a typical bar code includes a sequence of several 3-byte characters. An interruption at any time during transmission of that sequence will result in loss or corruption of the entire bar code. This keyboard inhibit problem is described in greater detail in a reference book entitled, “PC KEYBOARD DESIGN”, by J. Konzak, and published by Annabook.
With the advent of multitasking operating systems, sophisticated network operating systems, and dual-keyboard port laptops and PC's, the problem worsens. Some of these operating systems interrupt keyboard port communications on a frequent and periodic basis, such as once every ten milliseconds. Of course, in operational environments where the keyboard controller port is not used with an auxiliary input devices, the computer keyboard will sense this stoppage of communications and retransmit the scan code after the PC releases its halt or inhibit of the keyboard. Existing bar code scanners are not so equipped. If a data transmission from a bar code scanner is interrupted, the scanner has no mechanism by which to ascertain whether or not a data entry error has occurred.
Existing scanners do not monitor for the existence of an inhibit signal, so the scanner cannot infer a data entry error based upon the existence of an inhibit. Pursuant to prior art techniques, bar code scanners had not monitored the inhibit signal because the decoded bar codes were wedged into the transmitted data for brief periods of time, relative to typed-in keyboard data. Also, as a practical matter, the keyboard BIOS virtually never inhibits the keyboard during scan code transmission. Any problems that may have been encountered were handled by changing certain programmable parameters such as inter-character delays or inter-scan-code delays.
In some existing wedge scanner systems, PC
100
maintains control over keyb

Affiliated with

Also associated with

Rating

Techniques for interfacing a bar code scanner to a PC using... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Techniques for interfacing a bar code scanner to a PC using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Techniques for interfacing a bar code scanner to a PC using... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3016832