GIDEI Purpose
The main purpose of the GIDEI Proposal is to provide developers of AAC and other alternate input devices with a viable approach that enables them to use their devices as replacements for the normal keyboard and mouse on general purpose computers. This allows people who are "unable" to effectively operate the normal keyboard and mouse, to access computer systems and software from their alternate input device.Keep in mind that the General Input Device Emulating Interface (GIDEI) Proposal defines a connection and data communication protocol only, between the alternate input devices and other emulating interfaces which emulate standard computer input devices, not to any software or hardware designed to do translation.
Background
A person who is unable to access a computer is at a
great disadvantage in today's society. Many schools
and jobs require the use of computers daily. The
person who is physically unable to use a computer
keyboard or mouse can not participate in certain
activities on an equal level with others.
Technology has evolved to the point where electronic
aids are available for many people with physical
disabilities to assist them in doing many of the same
things that others are doing on standard computer
systems. For example, several aids can perform word
processing features. Yet there still exists the need
to access the same computers and software that are used
by others. In schools and in the workplace, an
individual is often required to use the same software
programs that others are using.
Fortunately, many special electronic aids used by
people with disabilities can be used as alternate input
devices for standard computers. Any device which is
capable of connecting to a computer as described in
this GIDEI Proposal and also capable of transmitting
ASCII information arranged to conform with the GIDEI
data communication protocol, should be capable of
acting as a alternate input device.
The following figures should help you to better
understand the terminologies GIDEI, alternate input
device, and emulating interface. Each figure contains
a picture of a computer, showing the connection for the
standard keyboard and mouse input devices. Each figure
also contains a picture of a alternative input device
(e.g., AAC) device that is also connected in some
fashion to the computer. It is this AAC device-to-
computer connection that is the critical component you
need to understand, when determining if you need-to-
follow the GIDEI Proposal for connection and data
communication purposes between your AAC device and the
computer.
The detailed discussions which follow are designed to
assist you in better understanding the proper
application of the GIDEI Proposal, with or without the
figures as a reference.
Figure 1
The example in Figure 1 shows an AAC device connected
directly to the computer using a serial cable. The
serial cable from the AAC device connects directly to
the computer serial or "com" port, which is usually
located at the rear of the computer. The user in
Figure 1 wishes to make selections on their AAC device,
transmit the information across the serial cable to the
computer, and expects the computer to understand that
the information represents keyboard or mouse actions.
In Figure 1, the "connection" protocol as defined in
the GIDEI Proposal includes the serial cable, its
internal wiring or "pin-out" arrangement, and the
amount, speed, and characteristics of the information
the user sends from their AAC device to the computer.
The "data communication" protocol as defined in the
GIDEI Proposal concerns the contents of the information
or "data packets" themselves, that the user either
creates or which may be pre-stored on their AAC device.
You might expect that once the user sets up their AAC
device to conform to both the connection and data
communication protocol as defined in the GIDEI
Proposal, that their AAC device would be able to
communicate with and control the computer.
Unfortunately, without one additional missing piece,
the computer will not be able to understand what the
AAC device is transmitting.
Computers are very powerful tools. However from a user
input standpoint, most computers only understand the
user when given input or instructions from the keyboard
or the mouse. By design, keyboards and mice each use
their own language to communicate with the computer.
Therefore, once the AAC device is connected to the
computer as shown in Figure 1 (e.g., either directly
through the use of a serial cable or indirectly via
some kind of wireless link), something must act as a
"go-between" to translate the AAC device language into
the keyboard or mouse language understood by the
computer. Since the information transmitted from the
AAC device is well defined by the GIDEI Proposal data
communication protocol, a good portion of the
translation work is already completed. In Figure 1,
the missing "go-between" piece is the software that
functions as the "emulating interface" on the computer
receiving the alternate input device information.
Emulating interface software would do the translation
of the information sent from the AAC device into
keyboard and mouse language understood by the computer.
The emulation interface software is the missing "go-
between" piece that allows the AAC device which is
connected directly to the computer com port to
"emulate" these standard input devices. The
"SerialKeys" feature provided as part of the AccessDOS
software package is an example of "emulating interface"
software.
Figure 2
The AAC to computer connections shown in Figure 2 are
very similar to the example shown in Figure 1, except
the serial cable coming from the AAC device is now
connected to a "black box" outside the computer rather
than directly to the computer. (Again, please note
that the serial cable could also be a wireless serial
link). The black box has cables coming "from" the
keyboard and mouse, and cables "exiting" the black box
which connect to the computer at the same place the
keyboard and mouse cables would have been plugged into
the computer, had the black box not been used. The
black box also has a connection for the serial cable
used to connect to the AAC device. Again the
"connection" protocol as defined in the GIDEI Proposal
includes the serial cable, its internal wiring or "pin-
out" arrangement, and the amount, speed, and
characteristics of the information the user sends from
their AAC device to the black box. The "data
communication" protocol as defined in the GIDEI
Proposal concerns the contents of the information or
"data packets" themselves, that the user either creates
or which may be prestored on their AAC device.
In this example, information is sent from the AAC
device to the black box. Therefore, the black box
needs to perform the necessary translation of the AAC
device information prior to sending it to the computer
through the keyboard and mouse cables. The black box
becomes the missing "go-between" piece in this example.
Since the black box is connected between the standard
input devices and the computer, it understands the
language used by the keyboard and mouse when talking
with the computer, and is therefore capable of allowing
the AAC device to again "emulate" the standard input
devices. In this case, we would refer to the black box
as an "emulating interface device," since it is
actually a piece of hardware which a user could take
from computer-to-computer, as their needs might
dictate. The Trace Transparent Access Module (T-TAM)
is one example of an "emulating interface device."
Figure 3
Figure 3 shows one more example connection. However,
the example in Figure 3 shows how a non-GIDEI alternate
input device might connect to a computer. The AAC
device in Figure 3 is connected directly to the
computer using a keyboard cable. Since there is no
serial cable or wireless serial link involved, this
example does not use the GIDEI Proposal.
The AAC device in Figure 3 does not use any kind of
GIDEI connection, because this AAC device already has a
keyboard emulation interface built into it which
understands the keyboard language of the computer it is
connected to. In this example, we would say that the
AAC device is acting as both the "alternative input
device" and the "emulating interface device." Some
individuals may also call an AAC device with "direct
keyboard connection" capability a "keyboard emulating
interface," since the AAC device connects directly to a
keyboard cable and "emulates" or looks like another
keyboard to the computer. This terminology can be
confusing however, since it does not distinguish
between a device which is capable of connecting
directly to the keyboard port or a device which
emulates the keyboard using an external emulator.
Perhaps a preferred term for this type of device would
be to describe it as an alternative input device with
built-in keyboard emulation. However, as stated above,
this combination is still another example of keyboard
emulation.
As technology advances, we expect more and more AAC
devices to be designed capable of connecting directly
to the computer as substitute or additional keyboards,
mice, etc. These devices would not need to use the
GIDEI connection and data communication protocol.
However, until all alternative input devices are so
equipped, the GIDEI Proposal provides a consistent
method for users to connect with and operate a
computer.
Standardization
The reasons behind the effort to standardize the GIDEI
is based on several important and practical concerns:
Many people need access to two or more different types
of computers. If the only way they can obtain that
access is through a GIDEI connection, it would be
beneficial to the user if the GIDEI worked the same (at
the user level) for all computers, keyboards and
pointing devices. There is little enthusiasm on the
part of users, clinicians and developers to have to
deal with multiple GIDEI formats and protocols.
For schools and clinics it is important that a
emulating interface on a computer be compatible with a
variety of alternate input devices so that different
people can access or share the computer. For public
computer systems, such as computer based card
catalogues in public libraries, it is important that
the computer be accessible to everyone. Having a
single GIDEI connection and data communication protocol
that all alternate input devices can implement will
provide that access in the most advantageous solution.
The GIDEI Proposal defines the connection and data
communication protocol between alternate input devices
and an emulating interface. The alternate input
device, using this protocol, transmits information to
the computer. The emulating interface then processes
that information to determine which keystrokes to type
or what mouse actions to perform on the computer. If
it is a hardware emulating interface device, it may
need to mimic the electrical signals that the normal
keyboard and mouse exhibit. If it is a software
emulating interface, it will place the keystroke and
mouse information into locations within the computer or
its operating system, where application programs will
think it came from a user typing on the keyboard or
from a user operating the mouse.
Some confusion arises when software or hardware
developers state that they have a "general input device
emulating interface," either in software or hardware.
What they are referring to usually, is the fact that
their interface can handle "general" input, thus it
isn't limited to translating alternative input device
information into only keyboard or only mouse languages.
While reading this document, the General Input Device
Emulating Interface (GIDEI) refers only to the
connection and data communication protocol, not to any
software or hardware designed to do translation.
The GIDEI connection protocol is designed to allow both
wired and wireless links for GIDEI communication.
Specifications have been made to allow for some degree
of flexibility while taking into account the
limitations of most current alternate input devices.
Basic operation of the GIDEI is possible with virtually
any alternate input device with a serial port and
advanced options are included for alternate input
devices that have additional capabilities.
The GIDEI Proposal defines two modes of operation as
part of the data communication protocol for sending
keystroke and mouse information: Character Mode and
Escape Sequence Mode. In Character Mode, the emulating
interface would understand to convert ASCII characters
received from the alternate input device directly into
whatever keystrokes are necessary to produce those same
characters on the computer. The Escape Sequence Mode
is designed to provide a way for a person using an
alternate input device to type keys that have no ASCII
equivalent (e.g., Home, PageUp, etc) as well as to
allow the user to "hold" two or more keys down at the
same time, as is required by many computers (e.g.,
Ctrl-Alt-Del). Escape Sequence Mode also allows the
user to specify mouse actions such as clicking, double
clicking and moving. Finally, Escape Sequence Mode is
used to change certain operational features the GIDEI
Proposal supports.
The GIDEI Proposal was developed with thought given to
both hardware and software emulation interface
implementations. Features such as key repeat and
adjustable typing rate were deliberately removed from
this proposal to take into account the fact that some
emulating interface implementations could not guarantee
access to a timing mechanism. Memory requirements were
also considered when Commands and Key Names were
established as part of the GIDEI data communication
protocol. While the length of some of the Key Names
could be shortened, this would have made it much more
difficult for users to understand. Since many of the
alternate input devices today require the user to
program these escape sequence strings in "squares" or
"selections" on their alternate input device, user
readability was given greater priority than device
memory requirements.
Previous versions of the GIDEI were concerned with
maintaining a degree of compatibility with previous
versions of the Keyboard Emulating Interface (KEI v1.0)
standards. However, to provide better support for the
newer and more powerful communication aids, GIDEI2 no
longer guarantees such "backward" compatibility.
Keyboard Commands
Typing Specific Keys: each key is designated by a
name. To type the key, use the Key Name in an escape
sequence. An escape sequence is simply the ESCAPE
character (ASCII 27, represented as "<esc>" below),
followed by a sequence of other ASCII characters, and
ending with the PERIOD character (ASCII 46,".").
(Note: Some Many AAC devices can generate an ESCAPE
character using a combination of the control key plus a
left bracket (e.g., control+[), which may appear on the
AAC device display as "^[" or as a blank character.
Others have the ESCAPE character programmed on a
keyboard layout page.)
Other Key Actions: to perform other actions, use
escape sequences of the general form:
Valid keyboard commands are:
<esc> , combine , ctrl , alt , del .
<esc> , hold , shift .
<esc> , lock , ctrl .
<esc> , rel .
Button identifier now refers to a mouse button action,
such as pressing mouse button #1, rather than a
location, such as pressing the "left" mouse button.
This distinction is being made because many operating
systems now allow the user to reprogram the buttons on
the mouse to perform any desired action. Therefore,
users are encouraged to follow the new button
identifiers, rather than previous GIDEI conventions
which defined a "left" or "right" mouse button. If the
button identifier is not included, typically the
"default" button is activated with the mouse command.
Valid mouse commands are:
<esc> , click .
<esc> , dblclick .
<esc> , moulock , but1 .
<esc> , mourel .
<esc> , anchor .
(The next single lowercase letter "a" through "z"
following an "anchor" command becomes the "name" of the
current mouse cursor screen position, thus allowing 26
separate mouse cursor locations to be "anchored" or
saved.)
<esc> , move , 1 X direction , 1 Y direction .
<esc> , mougo , downleft , 5 .
A) It moves the mouse cursor to a specified absolute
screen location when both an X and Y position is
indicated.
<esc> , goto , X position , Y position .
B) It moves the mouse cursor to a specified screen
location, based upon that location having been
preassigned using the "anchor" command (see above).
<esc> , goto .
(The next single lowercase letter "a" through "z"
following this "goto" command is the "name" of the
mouse cursor screen position "anchor" the user wishes
to return to.)
<esc> , moustop .
<esc> , moureset .
<esc> , baudrate , XXXXX .
When the AAC user is communicating with the emulating
interface at a known rate, the baudrate command can be
used to change to another rate, should the user wish to
do so.
ASCII: ASCII is an acronym which stands for the
American Standard Code for Information Interchange.
What this means to the computer user is that usually
numeric values represent characters inside the
computer. For example, the ASCII code for the
uppercase "A" is "65." Table 1 provides a listing of
ASCII characters and their corresponding numeric or
decimal code.
Emulating Interface: A "system" that accepts
information from an alternate input device and
transforms it into keystrokes or other input
information in the computer.
Escape Character: The single character used to
indicate the beginning of a GIDEI Escape Sequence. It
is ASCII 27. In this document the escape character is
designated by "<esc>."
Escape Sequence: A character string that starts with
an escape character (ASCII 27) and ends with a period
character (ASCII 46). Escape Sequences are used to
send special commands and keystrokes.
Hardware emulating interface: Usually an "external"
device that attaches to the computer and provides
connection "ports" for AAC devices while simultaneously
interacting with the computer in such a way that the
computer is unaware that any external device is
attached.
Key Name: The ASCII string of characters assigned by
the GIDEI Proposal to designate each key on the normal
keyboard.
Neutral Keyboard: The state of the keyboard when all
"toggling" keys are in their "untoggled" position.
Secondary Key Function: One or more actions produced
by a key when it is typed in combination with other
keys. Secondary Key Functions are normally activated
by holding down, for example, a [Shift] key, an [Alt]
key, an [Option] key, a [Ctrl] key, etc., along with
the key.
Software emulating interface: Software which is
implemented as a co-process within the target computer.
Typically, it is a program resident in the computer
which uses the computer's serial port to communicate
with the alternate input device. It is activated when
the serial port receives characters. Once activated,
it interprets the keystroke and mouse information and
makes these keystrokes available to the operating
system in that computer.
Special Keys: Keys that do not produce ASCII
characters. An example is the "right arrow" key.
Transparent Interface: An interface that is invisible
to or undetectable by the computer system and the
software running on it. A emulating interface whose
implementation is not distinguishable from the way the
normal keyboard works. In other words, it is a
interface that operates with a computer and the
software running on it exactly the same way as the
normal keyboard would operate. Ideally, all interfaces
should be transparent to insure access to the same
programs that can be operated from the normal keyboard
or mouse.
XOFF Character: The character sent by the GIDEI to the
alternate input device to tell it to stop transmission.
The XOFF character is ASCII 19 (control-S).
XON Character: The character sent by the GIDEI to the
alternate input device to tell it to resume
transmission. The XON character is a ASCII 17
(control-Q).
The hardware interface is the component of the system
which the user's AAC device "directly connects to." It
handles the physical connection, signal interfacing,
communications protocol and data buffering.
The GIDEI Proposal data connection protocol uses the
RS-232C communication link for transferring information
from an external AAC device to the hardware interface.
The hardware interface itself might be under the
control of emulating interface "software" running on a
computer or a separate external "black box" connected
to the computer.
See also Appendix A, regarding "Plug-and-Play."
Serial Connection
The serial connection is based on EIA Standard
RS-232-C: Interface Between Data Terminal Equipment
and Data Communication Equipment Employing Serial
Binary Data Interchange, August 1969, Electronic
Industries Association, Washington, D. C. 20006.
Of the 25 lines defined, four are used for the GIDEI
Proposal.
The hardware interface plays the role of the DCE (data
communication equipment). The alternate input device
or "external device" would connect to the hardware
interface with a serial cable or wireless serial link,
as discussed earlier in Figures 1 and 2. The hardware
interface is usually the computer running emulating
interface software or a black box connected to the
computer.
Pin Assignments (for the AAC, or DTE, device)
(assuming the AAC device has a 25 pin D connector)
The user may change the baud rate via an escape
sequence command sent to the hardware interface. Valid
baud rates are 300, 1200, 2400, 4800, 9600, and 19200.
Handshaking
The descriptions below pertain to both devices during
normal operation after transmission has been establish.
There are some changes that must be noted when the
devices are initially connected, or when a baud rate
change takes place. These two cases are explained in
separate sections later in this document.
With hardware handshaking, the hardware interface
controls the signal on the Clear To Send line. It
asserts this line when it can receive data and lowers
it when it is not ready to receive more data.
The external AAC device, if using this handshaking
method, must check the status of this line before each
character is transmitted. It may only send data if the
line is asserted.
Software handshaking is a system where the hardware
interface, using ASCII characters, transmits its status
information to the external AAC device on the Received
Data line. The hardware interface sends an XON
character (ASCII 17) to signal that it is ready to
receive data and sends an XOFF character (ASCII 19) to
signal that it is not ready.
The external AAC device, if using this handshaking
method, must check its receive buffer before each
transmission to determine if an XOFF has been sent. If
so, it must wait until an XON is sent before sending
any more data.
Hardware Interface Handshaking
To suspend the transmission of characters by the
external device, the hardware interface puts the CTS
line into the OFF state (logic 1, -3 to -15 volts) and
sends one (1) XOFF character at the current baud rate
to the external device over the Received Data line.
If the hardware interface lowers the CTS line and sends
an XOFF while a character is being transmitted by the
external device, transmission will continue until the
current character has finished being transmitted.
It may turn out that the external AAC device, due to
the buffering capabilities of its serial hardware, may
not be able to stop the transmission of characters
immediately. In this case, one or more characters
might still be sent after the hardware interface has
signaled it to stop. To accommodate this, the hardware
interface will be required to be able to receive four
(4) more characters after the initial XOFF has been
sent to the external device. In addition, after each
of these "extra" characters is received, the hardware
interface will send another XOFF back to the external
device.
Once the external device has received the XOFF
character or has detected the lowering of the CTS line,
it must wait for an XON or an asserted CTS before any
additional data is sent to the hardware interface.
There are a few exceptions to this requirement. See
later.
If the external device is using the XON/XOFF
handshaking method, it is recommended that the external
device periodically interrogate the status of the
hardware interface while it is waiting for an XON.
(See next section)
There is no timing specification given to define what
"periodically" means. The intention is that the
external device checks at reasonable intervals. Not so
often that the hardware interface spends all its time
handling the serial transmission and therefore can't
get anything else accomplished, but often enough to
avoid an unreasonable delay for the user.
To do this, the external device is allowed to send a
NULL character (ASCII 0) at the current baud rate to
the hardware interface. If the hardware interface is
ready to receive keystroke data it will receive this
character and then send an XON back to the external
device. While the hardware interface must monitor the
character data for this character, it is still passed
on to its input buffer just like any other character.
If the hardware interface is not ready to receive
keystroke data, it will send nothing back.
No character is sent back in this case (instead of
sending an XOFF) to guard against potential problems.
First, if the external device missed the original XON
(which is why it is interrogating), chances are that it
could miss an XOFF when the hardware interface is
interrogated. In that case the external device is hung
up waiting for the XOFF response. Secondly, the
hardware interface may have sent the original XOFF
because it was too busy to handle any more serial data
for a while. If this is the case, the NULL character
would not be received or interpreted by the hardware
interface so it couldn't possibly send the additional
XOFF.
So no matter what the reason is that the hardware
interface is busy, the end result, as seen by the
external device, is that the hardware interface did not
send back an XON. The external device should try again
later.
This interrogation method is useful (and recommended)
for external devices using the software handshaking
system to insure that transmission does not hang up
because an XON character was missed.
Handling Framing Errors
If the hardware interface receives three (3)
consecutive characters with a framing error, it will:
2. Change to 300 baud (if not at this rate already)
3. Raise the CTS line and send out an XON at 300 baud
after the above steps are completed in order.
Besides the benefit of setting the hardware interface
to a known state, this requirement will also help to
insure the quality of the transmission by not allowing
baud rates which produce repeated erroneous characters.
Reset Signal to the User
Two methods are suggested:
Handshaking After Changing Baud Rate By Command
The hardware interface will then perform its baud
change to the specified baud rate. After changing the
baud rate, it will clear out any characters it may have
received since the baud rate change began. When
completed, it will signal the external device that it
is ready by raising the CTS line and sending an XON
character at the new baud rate.
Since the external device might not change baud rate as
fast as the hardware interface, it might not properly
receive the XON character. Because of this, it should
employ the Status Inquiry method, if it is using
XON/XOFF handshaking.
Table 1 shows all the ASCII characters from 0 through
127. Characters which exist above 127 (e.g., ASCII 128
through ASCII 255), sometimes referred to as "Extended
ASCII," may differ due to the computer or receiving
device's operating system.
If your alternate input device is capable of sending
the ASCII value for the character you need, most
hardware interfaces will understand how to generate the
character or key for your request. If some of the keys
on a particular keyboard have single character labels
which are ASCII characters in the Extended ASCII 128 to
ASCII 255 range, GIDEI2 supports transmission of these
characters and hopefully the hardware interface will
understand how to "create" the character or keyboard
"keys" via emulation on the receiving computer. For
example, if you require an "e" with a circumflex accent
"^" on a computer in the United States, GIDEI2 supports
transmission of the Extended ASCII character "234"(ISO
8859-1 Standard) direct from the alternate input device
to the hardware interface. (Note: remember the
hardware interface may be either an external "black
box" device connected to the receiving computer or
emulation interface software running directly on the
receiving computer.)
Two ASCII characters are reserved by the GIDEI for
special use. They are the NULL character (ASCII 0),
and the ESCAPE character (ASCII 27). See the Escape
Sequence Mode section to find how to type these
characters.
Based on the GIDEI Proposal, an emulating interface
will leave Character Mode and enter Escape Sequence
Mode upon receiving an Escape character. (see the next
section for information on Escape Sequence Mode)
Based on the GIDEI Proposal, after start up, after an
escape sequence, and after an error in an escape
sequence, the emulating interface will return to
Character mode.
Example: if an ASCII d is sent, the interface will type
a d on the computer. If an ASCII G is sent, the
interface will type a shift key and a g to produce a
capital G on the computer.
The actual keystrokes that the interface will type to
get the character is dependent on the keyboard that the
interface is emulating. The intention of the GIDEI is
to allow the external AAC device to send characters
that the hardware interface then translates into the
appropriate key presses or mouse actions.
Table 1: ASCII Characters With Their Corresponding Decimal Code
Often, different emulating interfaces must be designed
for each model of computer, keyboard and mouse, and
these interfaces may be designed by different
developers. Standardizing the language or "interface"
part of the emulating interface will make emulating
interfaces from different developers compatible.
Alternate input devices using the GIDEI connection and
data communication protocol will find a greater number
of computers that are accessible. This increases its
usefulness for users while at the same time expands the
market for manufacturers of alternate input devices.
In short, a standard as proposed by the GIDEI
connection and data communication protocol simplifies
development, makes it easier for people to connect
their augmentative or alternate communication devices
as alternate computer input devices, and provides
access to more computers for those people that are
unable to use the normal keyboard and mouse
effectively. GIDEI Overview
GIDEI Commands At A Glance
Typing Characters: simply send the character, which is
sometimes referred to as an "ASCII character" to the
emulating interface. Some examples of ASCII characters
are the lowercase letters "a-z", uppercase letters "A-
Z", most common punctuation characters like comma ",",
period ".", etc., and the numbers "0 through 9."
Mouse Commands<esc> Key Name .
For example: <esc> pageup . <esc> , command [ , Key Name 1 ] [ , Key Name 2 ]
[ , Key Name 3 ] [ , Key Name 4 ] [ , Key Name 5 ] .
Mouse button actions are performed using escape
sequences of the general form:
Miscellaneous Command(s)<esc> , command , button identifier .
Mouse movement actions are performed using the escape
sequence formats shown below:
- or -
<esc> , click , but1 .
Initialization and configuration of the GIDEI can be
performed with the following procedures and commands.
If a user attaches to a computer which has the
"emulating interface" already running, and which
conforms to the GIDEI Proposal, they need to first
establish a connection or get their AAC device to send
characters at the same "rate" at which the emulating
interface is accepting characters. The easiest and
quickest way to ensure this, is to cause the emulating
interface to reset to a "known" state. To accomplish
this, if the user can cause three "framing"
communication errors to occur, any emulating interface
which follows the GIDEI Proposal is supposed to perform
a reset. If the user transmits three consecutive NULL
characters (ASCII 0) at 300 baud, any GIDEI compliant
emulating interface, if not already at 300 baud, should
reset itself to 300 baud. This ensures a "known-data-
rate" communication connection between the user's AAC
device and the emulating interface. (See the section on
Hardware Connection for a more in-depth discussion of
this "Initial Connection Protocol.")
Definition of Terms
Alternate input device: Any device that can
electronically output ASCII characters and is used as
an alternative to the regular keyboard or other input
device on a general purpose computer system. An
alternate input device is used because a person finds
it more accessible and effective than the regular
keyboard (or other input device). Hardware Connection
This section defines specifications for the hardware
connection or hardware interface portion of a the
system.
Connector
The connector mounted on or associated with the
hardware interface may be either a female 25 pin D or
female 9 pin D connector. The AAC user should examine
the computer serial port connectors to determine the
necessary requirements for each system they intend to
connect to.
Pin 2 is Transmitted Data (EIA Interchange Circuit BA).
(Direction of data flow from the external AAC device to the hardware
interface)Pin 3 is Received Data (EIA Interchange Circuit BB).
(Direction of data flow from the hardware interface to the external
AAC
device)Pin 5 is Clear To Send (EIA Interchange Circuit CB).
(Direction of data flow controlled by the hardware interface, which
can be a
hardware "black box" device or emulation interface
software)Pin 7 is Signal Ground (EIA Interchange Circuit AB).
(Assuming the AAC device has a 9 pin D connector)Pin 2 is Received Data
Pin 3 is Transmitted Data
Pin 5 is Signal Ground
Pin 8 is Clear To Send
Transmission FormatEach character transmitted from the external AAC device
and the hardware interface will use RS-232C voltage and
logic levels. Transmissions follow standard
asynchronous communications protocol with the following
format:
Transmission Rate1 Start Bit
8 Data Bits:
0 Parity Bits
1 Stop Bit
The hardware interface is configured to initially run
at 300 baud. (Note: the hardware interface may provide
the capability to initially configure at a baudrate
other that 300 baud. This capability is a function of
the hardware interface, and is not part of the GIDEI
Proposal. The GIDEI Proposal does however, define an
"Initial Connection Protocol to handle situations where
the hardware interface does not initially configure
itself at 300 baud.)
In order to control the flow of characters being sent
to the hardware interface, both hardware and software
handshaking methods are employed. Either interface
will simultaneously support both methods thereby
allowing the external AAC device the option of
selecting the method most appropriate for its design.
Status InquiryWhen the hardware interface is ready to receive
characters from the external AAC device, it places the
CTS line into the ON state (logic 0, +3 to +15 volts)
and sends one (1) XON character at the current baud
rate to the external device over the Received Data
line.
External Device HandshakingThe external device must use at least one of the
handshaking methods supplied by the hardware interface:
either the hardware method or the software method. It
should check the status of the CTS line or check its
own receive buffer for an XOFF character before it
transmits each character. If either check indicates
that the hardware interface is not ready, the external
device should not send any more characters to its
transmitting circuitry.
There exists a way for the external device to
interrogate the status of the hardware interface to
guard against the case where the external device using
software handshaking "missed" the transmitted XON
character.
Characters received with framing errors, or any other
transmission errors will not be passed on to its input
buffer. However, the number of consecutive characters
received with framing errors is remembered.
1. Send an XOFF at its current baud rate and lower
the CTS line
Although it is not required, it is recommended that the
hardware interface give the user an indication whenever
it has initialized.
Audible Signal
After the hardware interface resets it generates an
audible signal. The signal sound should be a simple
tone lasting approximately 1.0 seconds and audible in
the presence of normal ambient sound by a person with
normal hearing up to four feet from the computer
screen.
Visual SignalAfter the hardware interface resets it sends a visual
signal to the user in the form of a flashing amber LED
or if possible, a warning message on the Computer
system's screen. The LED should be amber in color,
clearly visible to a person looking at the computer
screen, and should light for 10 seconds. The warning
message to the computer system's screen could indicate
that the hardware interface has been reset to 300 baud.
For example, it could read: "SerialKeys has reset the
com port to 300 baud and is now ready to continue
receiving characters."
The hardware interface will have the capability to
change to a user specified baud rate through an Escape
Sequence Command. Whenever the baud rate is to be
changed, the hardware interface will carry out the
following handshaking methods.
When the hardware interface is ready to change baud
rate, it will lower the CTS line and send an XOFF
character to the external device. If additional
characters are received by the hardware interface after
this point, they are ignored.
Character Mode
Character Mode is the most common mode in which an
alternative input device using GIDEI data communication
protocol will be running. In this mode, ASCII
characters sent from the alternate input device to the
computer will be converted to the keystrokes necessary
to produce that ASCII character on the computer.