U.S. Pat. No. 8,117,364

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Reference will now be made in detail to embodiments of the present technology for enhanced protocol and architecture for low bandwidth force feedback game controller, examples of which are illustrated in the accompanying drawings. While the technology for enhanced protocol and architecture for low bandwidth force feedback game controller will be described in conjunction with various embodiments, it will be understood that they are not intended to limit the present technology for enhanced protocol and architecture for low bandwidth force feedback game controller to these embodiments. On the contrary, the presented technology for enhanced protocol and architecture for low bandwidth force feedback game controller is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope the various embodiments as defined by the appended claims. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present technology for enhanced protocol and architecture for low bandwidth force feedback game controller. However, the present technology for enhanced protocol and architecture for low bandwidth force feedback game controller may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present embodiments.

Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present detailed description, discussions utilizing terms such as “opening”, “determining”, “sequencing”, “reading”, “loading”, “overriding”, “writing”, “creating”, “including”, “comparing”, “receiving”, “providing”, “generating”, “associating”, and “arranging”, or the like, refer to the actions and processes of a computer system or similar electronic computing device. The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices. The present technology for enhanced protocol and architecture for low bandwidth force feedback game controller is also well suited to the use of other computer systems such as, for example, optical and mechanical computers. Additionally, it should be understood that in embodiments of the present technology for enhanced protocol and architecture for low bandwidth force feedback game controller, one or more of the steps can be performed manually.

Overview of Terminology

The following terms should be considered in light of the following overviews provided for them as well as the context in which they appear.

Haptic: Of or relating to the sense of touch; tactile.

Tactile: Perceptible to the sense of touch; tangible; of, relating to, or proceeding from the sense of touch.

Force Feedback: Simulated tactile sensation, e.g., applying a controllable torque to a steering wheel to inhibit or aid a user's ability to turn the wheel in order to simulate naturally occurring forces were the user actually steering a vehicle under the circumstances being simulated.

Payload: A message (e.g. instruction and/or data) in a communication packet.

Header: Identification, synchronization and/or other supplemental information (e.g., format or protocol of data) about a message in a payload portion of a communication packet.

FIG. 1is a simplified block diagram of an exemplary communication system between a host and a device, e.g., game controller, in which an enhanced protocol and architecture for low bandwidth force feedback game controller can be implemented. Communication system100comprises host105and device130. Numerous components in host105and device130have been simplified or omitted fromFIG. 1in order to focus on selected features of each. Host105may comprise, for example, a gaming console such as Microsoft's XBOX 360™ console or any other general or special purpose computing system capable of communicating with device130.FIGS. 4 and 5each illustrate an exemplary host105. Device130may comprise, for example, Microsoft's XBOX 360™ Wireless Racing Wheel or any other haptic device.FIG. 3illustrates an exemplary device130. It is understood that host105and device130must be compatible with one another in order for communication system100to operate properly. In some embodiments, host105may comprise an existing system having an existing underlying wired or wireless communication protocol that device130must comply with even though it may not provide sufficient support for implementation of haptic features. As such, the wired or wireless communication protocol implemented between host105and device130may be required to overcome deficiencies of an underlying communication protocol.

As shown inFIG. 1, Host105comprises hardware Input/Output (I/O) hub110and host radio115coupled together by bidirectional Universal Serial Bus (USB)120. USB120may comply with USB specification version 1.0, 2.0, 3.0 or any other version compatible with I/O hub110and host radio115. I/O hub110may comprise, for example, functionality well known as Southbridge functionality. Host radio115may comprise, for example, the wireless hub built into Microsoft's XBOX 360™ console capable of transmitting and receiving wireless communications, e.g., at a frequency of 2.4 GHz. I/O hub110may be configured to receive software instructions125from a processor (not shown) executing, for example, a game application. I/O hub110forwards instructions125to host radio115via USB120. Host radio115then transmits instructions125as commands175to device130, e.g., via wireless communication link180.

Device130comprises device radio/microcontroller135controlled by firmware165, force feedback (FFB) microcontroller140, motor145, transmission150, user interface155and sensor160. Device radio/microcontroller135comprises, for example, a wireless transceiver, operating at the same frequency as host radio115, coupled to an I/O interface of a microcontroller. As is well known, a microcontroller is a computer on a chip, integrating a microprocessor with volatile and nonvolatile memory and I/O interfaces, among other features of a computer. In addition to memory embedded in microcontroller135, device130may include additional volatile and/or non-volatile memory (not shown). Similarly, FFB microcontroller140comprises a microcontroller that may be connected to additional volatile and/or non-volatile memory (not shown).

User interface155comprises any one or more of the wide variety of ways that a human can interact with device130through human interface elements, such as buttons, pads, pedals and directional devices including, but not limited to, joysticks and wheels. It is understood that human interface elements are not limited to input elements and may include output elements. Both input and output elements may provide haptic feedback to a user. An example of an input element that may provide haptic feedback is a steering wheel. The wheel is used to provide positional input and may be used to provide haptic feedback, e.g., resistive torque and/or vibrations. An example of an output element that may provide haptic feedback is a seat or pad, which may not provide any input to a game application. A user may sit in a seat or on a pad that provides vibratory sensations to the user in accordance with simulated circumstances.

An exemplary device130having numerous human interface elements, i.e., Microsoft's XBOX 360™ Wireless Racing Wheel, is shown inFIG. 3. With reference toFIGS. 1 and 3, where device130comprises Microsoft's XBOX 360™ Wireless Racing Wheel300, for example, user interface155comprises numerous human interface elements, such as a steering wheel305, accelerator pedal (not shown), brake pedal (not shown), left and right paddles310,315(e.g. for simulated gear shifting), directional pad320, four multi-purpose buttons325, connect button330, power/guide button335, start button340and back button345. These human interface elements allow a user to interact with or control an interactive game played by host105. A game may react to user inputs made through the human interface elements, which is why device130is also referred to as a game controller. It is understood that device130may comprise one or more components, e.g., a racing wheel, pedal set, seat or pad, each of which may include input and/or output type human interface elements.

Sensor160, which may comprise one or more sensors, monitors, detects and provides to FFB microcontroller140the user inputs made through the human interface elements, e.g., in racing wheel300, wheel position, velocity and acceleration, button presses, paddle movement, accelerator and brake pedal positions. In some embodiments, FFB microcontroller140processes messages from host105that are received by device radio/microcontroller135. FFB microcontroller140may utilize user inputs in combination with commands received from host105through device radio/microcontroller135, as well as stored haptic features, to control motor145and/or transmission150to deliver haptic feedback to the user. Motor145comprises, for example, one or more electric motors that convert electric energy into mechanical energy, e.g., rotational or linear energy. Force feedback may be applied to any human interface element or any other portion of device130that can transmit a tactile sensation to the user. For example, low and high frequency vibratory rumblers (not shown) may be deployed inside hollow steering wheel305, motor145may be deployed in steering column350to impart torque on steering wheel305, etc. Transmission150variably transmits (e.g. via gear reduction) the controlled mechanical energy produced by motor145to one or more user interface elements in user interface155in accordance with one or more programmed haptic effects. For example, torque transmitted to steering wheel305by transmission150may vary depending on the simulated environment as well as user responsiveness to it.

Thus, FFB microcontroller140receives user input from sensor160and provides the user input to device radio/microcontroller135, which may then wirelessly transmit the user input, e.g., human interface element movements170, to host radio115. Host radio115transmits movements170to I/O hub110, which then provides movements170to a processor (not shown) that is executing, for example, a game application. Movements170may or may not result in new or modified software instructions125from the processor that is processing a game application. Nonetheless, software instructions125intended for device130are provided to I/O hub110, which forwards them to host radio115via USB120. Host radio115wirelessly transmits software instructions125as commands175to device radio/microcontroller135, which provides commands175to FFB microcontroller140. FFB microcontroller140controls motor145and/or transmission150to provide programmed haptic effects to user interface155in response to commands150and perhaps input from sensor160. It is understood that commands175is used in a very broad sense to refer to commands, requests, reports and other form of instruction that may or may not be accompanied by data.

As previously described, FFB microcontroller140may utilize user input from sensor160, in combination with stored haptic features and haptic control information received from host105, to control motor145and/or transmission150to provide haptic feedback to user. This architecture may allow FFB microcontroller140to sustain haptic feedback between communication packets provided by host105. This architecture is particularly useful when an underlying communication protocol does not have the bandwidth or latency requirements necessary to provide haptic feedback.

In order to convey realistic tactile sensations, haptic device130must be synchronized to the sights and sounds a user experiences from other sensory devices during game play. Therefore, device130requires relatively high bandwidth, low latency, bi-directional and an otherwise supportive communication protocol with host105executing a game application.

In order to improve the realism experienced using existing gaming systems, haptic devices, such as Microsoft's XBOX 360™ Wireless Racing Wheel, are being adapted to existing gaming systems, such as Microsoft's XBOX 360™ console, that have existing, i.e., underlying, communication protocols. However, underlying communication protocols, e.g., for Microsoft's XBOX 360™ console and game controllers, may place a restriction on force feedback protocol and architecture for haptic devices such as device130. Also, underlying wireless protocols, e.g., for Microsoft's XBOX 360™ console and game controllers, may place additional restrictions on force feedback protocol and architecture for haptic devices such as device130. Aspects of underlying communication protocols for existing gaming systems, such as header and payload definitions, frame rate, etc., contribute to limit system bandwidth and latency, which may be insufficient to deliver realistic haptic effects. There herein described haptic device works properly without redesigning existing gaming systems.

In an exemplary implementation, device130stores features. Haptic features are preloaded in device130or downloaded from host105to device130, by wire or wirelessly, before or during game play. Haptic features may be preloaded, for example, at the time device130is manufactured or at any other time. Features stored in non-volatile device memory may be referred to as native features that may produce native effects, e.g., a built-in return-to-center spring effect stored in non-volatile memory in device130. A game application can also download standard features for standard effects and users can create custom features for custom effects that may be loaded into device130in a variety of ways, including wirelessly from host105to device130. Native, standard and custom force feedback features are collectively referred to as haptic features or features while the haptic effects that each produces are collectively referred to as haptic effects or effects.

A Haptic feature defines the properties of a haptic effect, which is an implementation of the feature. Haptic features may be stored within volatile or non-volatile memory within FFB microcontroller140or any other volatile or nonvolatile memory that may be internally or externally connected to device130, including removable storage media. In some embodiments, each haptic feature may be specified by an effect block and one or more parameter blocks. Each effect block may set forth, for example, general or basic properties of a haptic effect such as duration, gain, start delay, loop count, etc., while one or more parameter blocks may set forth more specific parametric properties of a haptic effect such its magnitude. An example of a group of constant, ramp, periodic and conditional forces is shown in Table 1.

TABLE 1ParameterParameterParameterEffect BlockBlock 1Block 2Block 3Constant ForceMagnitudeEnvelopeN/ARampRampEnvelopeN/ASquarePeriodicEnvelopeN/ASinePeriodicEnvelopeN/ATrianglePeriodicEnvelopeN/ASawtooth UpPeriodicEnvelopeN/ASawtooth DownPeriodicEnvelopeN/ASpringCondition (X)Condition (Y)Condition (Z)DamperCondition (X)Condition (Y)Condition (Z)InertiaCondition (X)Condition (Y)Condition (Z)FrictionCondition (X)Condition (Y)Condition (Z)

Referring to Table 1, a constant force has a magnitude and duration, and may also have an envelope specifying force properties before (attack) and after (fade) implementation of the constant force. An effect block for a constant force may specify duration while parameter block1specifies magnitude and parameter block2specifies an optional envelope. A ramp force has a starting and ending magnitude, duration and may have an envelope. A ramp force may change during its duration and may be described in terms of segments. A periodic force, e.g., square, sine, triangle, sawtooth up, sawtooth down, is repetitive to provide a wave or vibratory effect. Periodic forces have defined shapes, magnitudes, periods, durations and may have envelopes. A conditional force, e.g., spring, damper, inertia, friction, is, for example, dependent on motion parameters such as position, velocity or acceleration, accounted for in parameter blocks1-3.

In some embodiments, host105, e.g. via a game application or driver executed by host105, may manage a portion of or all memory in or coupled to device130. Volatile and non-volatile memory in device130are collectively referred to as device memory. The amount of device memory managed by host105is collectively referred to as a block, pool or block pool. Device130may provide low level memory management for a block pool, but host105, e.g., via application or driver, could overwrite, reassign, clear and otherwise manage the block pool. Device130may provide a block pool for host105to download and/or manage haptic features, e.g., as represented by effect blocks and parameter blocks. For purposes of addressing each haptic feature stored in a block pool, a game application or driver may index (i.e. normalize) the address of each feature stored in device memory. Address indexing may help reduce the amount of information that must be communicated between host105and device130.

For purposes of indexing features, reference may be made to the 11 basic features in Table 1. In some embodiments these 11 features may be treated as only 11 features irrespective of how their specific parametric properties are defined. In other words, in some embodiments a feature is defined only by its type of effect. In other embodiments, these 11 basic features may be treated as more than 11 features based on how their specific parametric properties are defined. In other words, in some embodiments a feature is defined by the combined properties of its effect block and one or more parametric blocks.

In some embodiments, host105may load and store effect blocks and parameter blocks together. Before loading features, device130may provide a report, e.g., a Device Block Pool Report, to host105, which host105may use to determine the number of features that may be stored and how to organize their storage in block pool. A Device Block Pool Report may indicate, for example, the memory management mode of device130and the memory resources available to host105. A Device Block Pool Report may be provided upon request, e.g., a Device State Request, and/or automatically in some instances, e.g., following initialization or a reset command. Device130may also provide to host105, automatically and/or upon request, a Device Capabilities Report to indicate, for example, the capabilities and controls of device130and the range and resolution thereof. This may be useful to host105in determining which features may be implemented by device130, which could avoid downloading useless features. The Device Capabilities Report may include, for example, the type and possibly subtype of device130, assuming host105classifies type and subtype.

Like the Device Block Pool Report, the Device Capabilities Report and any other initial reports may be provided by device130, for example, during a binding/link/discovery process between host105and device130. In some embodiments, device130may begin interaction with host105by making a Device Link Request, which may alternatively provide device type and subtype information to host105. Upon receiving a Device Link Acknowledgment from host105, and perhaps after security handshakes, Device130may provide a Device Capabilities Report automatically or in response to a Device Capabilities Request message from Host105. Examples of device types may include game controllers and assorted other devices, or perhaps the device type may differentiate between wired game controllers, wireless game controllers, haptic devices and non-haptic devices. Since there would likely be more subtypes than types, a longer bit code may be assigned for subtypes than for types. Examples of subtypes of the generic type game controller include a standard game pad, steering wheel, arcade stick, flight stick, dance pad, FFB steering wheel, FFB flight stick, etc. The Device Capabilities Report may also indicate a version of device130, in addition to its type and subtype.

After host105becomes aware of device130and its capabilities and state, including device memory, it may proceed to load one or more features in device memory (e.g. block pool memory), whether managed by device130or host105, by sending to device130, for example, one or more Effect Block Reports, each comprising a Set Effect Block Command accompanied by effect block properties, and one or more Parameter Block Reports, each comprising a Set Parameter Block Command accompanied by parameter block properties. An example of effect and parameter block properties being stored in a block pool is shown inFIG. 2.

FIG. 2illustrates an exemplary organization of device memory. As shown inFIG. 2, stored in block pool memory200are numerous features stored in the form of indexed effect blocks and associated parameter blocks. In some embodiments, parameter blocks may be stored together with the effect block they relate to. For example, index1identifies a first feature comprising effect block1and accompanying parameter blocks1-3and index50identifies a 50thfeature comprising effect block50and accompanying parameter blocks1-2. As is further shown inFIG. 2, the properties of each indexed feature stored in block pool200may, in some embodiments, arrive at device130in the form of an effect report210and one or more parameter reports220. These reports210,220may be sent from host105to device130in wireless communication packets. In some embodiments, FFB microcontroller140processes reports210,220received by device radio/microcontroller135.

Effect report210comprises, for example, eight fields totaling eight bytes or one byte each for report type211, effect index212, block control213, effect type214, duration215, effect gain216, start delay217and loop count218. The first two bytes, i.e., report type211and effect index212, explain what information or data is being provided and where to store it. Report type211specifies, for example, that effect report205is a Set Effect Block Command directing device130to store the accompanying effect block data in fields213-218. Report type211, of course, may also specify a variety of other reports including parameter reports, e.g., constant, ramp, envelope, condition x, y, z. Report type211may be used for additional purposes, e.g., using the most significant bit as a toggle bit to turn packet filtering on and off in device130. Effect index212specifies where, i.e., at what index, the accompanying information, e.g., fields213-218, should be stored in block pool200. In this case, the index field indicates index1. The first two fields, i.e.,211-212, may, but need not be stored in block pool200. The remaining six fields213-218are stored in effect block1, which is identified by index1.

Block control213specifies, for example, the axes and directions to apply an effect. Each type of effect, e.g., constant, ramp, periodic, conditional, may use the settings in this field differently. Effect type214may identify, for example, one of the eleven types of effects listed in Table 1. Duration field215may identify a number of fixed time increments, or infinite duration stopped by an event such as an Effect Operation Command. Effect gain216may define a gain value to apply to the magnitude of an effect. For example, the gain value may be a normalized scaling factor applied to all magnitudes, including envelopes, of an effect. Start delay217may specify a number of time increments, including zero, to delay an effect upon loading it into an active play list. Loop count218specifies the number of times to repeat, for example, a periodic or ramp effect having a finite duration. The fields211-218specified for effect report210are merely exemplary and may vary from one embodiment to the next.

Parameter report220comprises, for example, eight fields totaling eight bytes as in the case of effect report205or may comprise any number of bytes necessary to convey parametric data for an index. As in the case of effect report205, the first two bytes, i.e., report type221and effect index222, explain what information or data is being provided and where to store it in block pool200. Report type221specifies a Set Parameter Block Command, commanding device130to store accompanying data fields collectively identified as specific parameter content223. Effect index222identifies index50in block pool200. Thus, the first two bytes need not be stored. Specific parameter content223is stored in parameter block1under effect block50identified by index50. As indicated by the embodiment in Table 1, there are several types of parameter blocks, i.e., constant, ramp, periodic, envelope, condition (x), condition (y) and condition (z). As such, there may be several independent set parameter block commands, which may be uniquely identified by different values in report type221.

Device130may have block pool memory200of any size allowing any number of features to be stored therein. Host105may arrange different pools of memory or subdivide block pool200for native, standard and custom features. Host105may control the amount of device memory allocated to each indexed feature. Host105may allocate a uniform or nonuniform amount of device memory for each indexed feature. Within each indexed feature, host105may allocate a uniform or nonuniform amount of memory for each effect block and accompanying parameter block(s). While block pool200may store any number of indexed features, host105may select some or all of them as an active play list of effects, which may leave some effects dormant until added to the active play list of effects.

In addition to providing features to device130, host105also makes requests for information and provides control information to control implementation of the features, to which device130may respond with acknowledgments and reports. Device130may also provide data input, e.g. movements165. As previously discussed, host105may send a Device State Request message and a Device Capabilities Request message to device130to which device130responds with reports. Details of these and other communication messages along with other communication messages will now be provided as an exemplary wired or wireless communication protocol between host105and device130. Some or all of the following exemplary list of commands, requests, reports and other messages between host105and device130may not be part of the underlying communication protocol, which may not provide sufficient support for haptic functionality. New messaging may be required to implement haptic functionality, perhaps more so in a wireless environment.

Device Block Pool Report. Device130may provide a Device Block Pool Report to host105. A Device Block Pool Report may indicate, for example, the memory management mode of device130and the memory resources available to host105. In some embodiments, device130may provide host105with a total number of memory block available, the number of bytes per memory block supported by device130, the minimum and maximum number of features indices supported, minimum and maximum number of simultaneous haptic effects supported in an active play list, types of native effects and axes supported and a toggle bit (toggled in every message) to evade message filtering by the underlying protocol. Host105may use the information provided in the Device Block Pool Report to determine the number of features that may be stored, how to organize their storage in block pool and what control information to provide to device130. A Device Block Pool Report may be provided upon request, e.g., Device State Request, and/or automatically in some instances, e.g., following initialization or a reset command. A Device Block Pool Report may be provided by device130, for example, during a binding/link/discovery process between host105and device130. In some embodiments, device130may begin interaction with host105by making a Device Link Request. Upon receiving a Device Link Acknowledgment from host105, and perhaps after security handshakes, Device130may provide a Device Block Pool Report automatically or in response to a request message from Host105.

Device State Request/Report. Upon receiving a Device State Request message from host105, or automatically after one or more selected events such as a state change, device130may provide a Device Block Pool Report message to host105. The Device State Report may initially be provided by device130, for example, during a binding/link/discovery process between host105and device130. In some embodiments, device130may begin interaction with host105by making a Device Link Request. Upon receiving a Device Link Acknowledgment from host105, and perhaps after security handshakes, Device130may provide a Device State Report automatically or in response to a Device State Request message from Host105. A Device State Report provides the current state of device130to host105. For example, a Device State Report may report the power state for implementation of haptic effects (e.g. DC adapter, battery), pause state for haptic effects, reset state for haptic effects, block pool (e.g. full, empty) state where an indication of full may place the block pool in overwrite mode, force feedback motor(s) enable state(s), native feature enable state and miscellaneous other states such as a toggle bit to prevent host105from filtering out report messages which may appear to be repetitious to the underlying communication protocol.

Device Capabilities Request/Report. Upon receiving a Device Capabilities Request from host105, or automatically after one or more selected events, device130may provide a Device Capabilities Report to host105. The Device Capabilities Report may be provided by device130, for example, during a binding/link/discovery process between host105and device130. In some embodiments, device130may begin interaction with host105by making a Device Link Request. Upon receiving a Device Link Acknowledgment from host105, and perhaps after security handshakes, Device130may provide a Device Capabilities Report automatically or in response to a Device Capabilities Request message from Host105.

A Device Capabilities Report may be useful to host105in determining which features may be implemented by device130, which could avoid downloading useless features or mishandling information provided by device130. The Device Capabilities Report may indicate, for example, the capabilities and controls of device130and the range and resolution thereof. For example, the Device Capabilities report may identify human interface elements on device130such as triggers, push buttons, thumb controls, motor controls, directional pad controls, joysticks, start button, back button, guide button, bind button, steering controls, etc. Each human interface element may have a control resolution. For example, one control may range from 0 to 255 while another control may have a much broader range such as 0 to 65,535. Thus, the Device Capabilities Report may identify control resolutions for one or more of the supported controls. The Device Capabilities Report may also identify miscellaneous or enhanced capabilities. For example, microphone, speaker, battery charger, a plug-in module and motor axes (x, y and/or z) supported.

The Device Capabilities Report may also include, for example, the type and possibly subtype of device130, assuming host105classifies type and subtype. If the type and subtype are known by host105then perhaps an enumeration of capabilities may be avoided. Host105may be manufactured with awareness of a list of device types and subtypes and may also periodically download updated lists of compatible device types and subtypes. Examples of device types may include game controllers and assorted other devices, or perhaps the device type may differentiate between wired game controllers, wireless game controllers, haptic devices and non-haptic devices. Since there would likely be more subtypes than types, a longer bit code may be assigned for subtypes than for types. Examples of subtypes of the generic type game controller include a standard game pad, steering wheel, arcade stick, flight stick, dance pad, FFB steering wheel, FFB flight stick, etc. The Device Capabilities Report may also indicate a version of device130, in addition to its type and subtype.

Feature Play list Status Request/Report. Upon receiving a Feature Play list Status Request message from host105, device130may provide a Feature Play list Status Report message to host105. A Feature Play list Status Request may inquire about a specific play list, the index numbers or other information about the features in the play list, whether the play list is active or inactive, paused or playing and whether the play list is empty, full or may support additional features. Device130may respond with a Feature Play list Status Report that provides the requested information.

In addition to the exemplary requests discussed herein, host105may, of course, make other or additional requests of device130. Additionally, host105may command device130. Exemplary commands are now provided. Two such commands discussed with reference toFIG. 2are the Set Effect Block Command and the Set Parameter Block Command. Device130may provide a Block Load Report in response to either type of command.

Block Load Report. Upon receiving a Set Effect Block Command, Effect Block Modification Command or one of several Set Parameter Block Command messages from host105, device130may provide a Block Load Report message to host105. A Block Load Report may serve to guarantee successful delivery and implementation of commands from host105by providing positive feedback. Device130may send the Block Load Report after receiving the command message from host105, computing a checksum and determining the success or failure status of the loading of the effect or parameter block into block pool200. The Block Load Report may comprise, for example, a command type received and executed (e.g. effect block, parameter block or modify parameter block), an indication of success or failure (perhaps elaborating on the reason for a failure with an error code), an indication whether block pool200is full and a checksum value (e.g. calculated by a cyclic redundancy check (CRC) or other error detection code for each byte of the command received from host105).

Set Effect Block Command. Host105may send a Set Effect Block Command message to device130in order to store a new standard or custom feature in block pool200. The Set Effect Block Command may comprise, for example as shown inFIG. 2, indicators for report type211, effect index212, block control213, effect type214, duration215, effect gain216, start delay215and loop count218. Report type211and effect index212explain what information or data is being provided and where to store it. Report type211specifies, for example, that effect report205is a Set Effect Block Command directing device130to store the accompanying effect block data in fields213-218. Report type211, of course, may also specify a variety of other reports including parameter reports, e.g., constant, ramp, envelope, condition x, y, z. Report type211may be used for additional purposes, e.g., using the most significant bit as a toggle bit to evade packet filtering. Effect index212specifies where, i.e., at what index, the accompanying information, e.g., fields213-218, should be stored in block pool200.

Block control213specifies, for example, the axes and directions to apply an effect. Each type of effect, e.g., constant, ramp, periodic, conditional, may use the settings in this field differently. Effect type214may identify, for example, one of the eleven types of effects listed in Table 1. Duration field215may identify a number of fixed time increments, or infinite duration stopped by an event such as an Effect Operation Command. Effect gain216may define a gain value to apply to the magnitude of an effect. For example, the gain value may be a normalized scaling factor applied to all magnitudes, including envelopes, of an effect. Start delay215may specify a number of time increments, including zero, to delay an effect upon loading it into an active play list. Loop count218specifies the number of times to repeat, for example, a periodic or ramp effect having a finite duration. The fields211-218specified for effect report210are merely exemplary and may vary from one embodiment to the next.

Effect Block Modification Command. Once a feature is loaded into block pool200, the Effect Block Modification Command is used to modify it without stopping and restarting implementation of the feature. Exemplary fields for the Effect Block Modification Command comprise some or all of the fields for the Set Effect Block Command.

Set Parameter Block Command. Host105may send a Set Parameter Block Command message to device130in order to store various properties of a new standard or custom feature in block pool200. The Set Parameter Block Command may comprise numerous commands. The various set parameter commands may be defined within a field of a generic Set Parameter Block Command, e.g., report type. Exemplary Set Parameter Block Commands may include, for example, Set Envelope Parameter Block, Set Condition (x axis) Parameter Block, Set Condition (y axis) Parameter Block, Set Condition (z axis) Parameter Block, Set Periodic Parameter Block, Set Constant/Ramp Parameter Block.

Set Envelope Parameter Block. The Set Envelope Parameter Block describes the envelope along one or more axes, if any, to be used when implementing a feature. Exemplary fields for the Set Envelope Parameter Block include report type, index, attack level start amplitude, fade level end amplitude, attack time in incremental steps, fade time in incremental steps. The report type field identifies the type of command as a Set Envelope Parameter Block command while the index identifies the index in block pool200where the accompanying properties in the various fields should be stored. The values for the attack start and fade end amplitudes may be based on a normalized baseline, such that they specify a value relative to the baseline. The attack time and fade time may be based on, for example, an incremental number of multiples of the frame rate of the communication protocol.

Set Condition (x/y/z axis) Parameter Block. Besides report type and index, exemplary fields for a Set Condition (x/y/z axis) Parameter Block include a center point offset, positive coefficient operator, a negative coefficient operator, positive saturation operator, negative saturation operator and center dead band operator. A center point offset may be used, for example, to specify an offset from the resting position of a spring or a velocity at which a damping force is zero in order to convey a point where the effect of a feature begins. A positive coefficient operator specifies a constant coefficient on the positive side of a force neutral position. A negative coefficient operator specifies a constant coefficient on the negative side of a force neutral position. A positive saturation operator specifies the maximum positive force on the positive side of a force neutral position. A negative saturation operator specifies the maximum negative force on the negative side of a force neutral position. A center dead band operator specifies the region around the centerpoint offset where the force is inactive. Force algorithms and other basic properties for conditional features may be specified by respective effect blocks. Since force algorithms may vary from one feature to the next, the parameter values may represent differing information depending on the feature.

Set Periodic Parameter Block. Besides report type and index, exemplary fields for Set Periodic Parameter Block include magnitude, offset, phase, period and sample rate. The magnitude of a periodic feature represents the maximum force to be applied. A high magnitude equates to, for example, a strong vibration. The offset field shifts a force to increase it in one direction while decreasing it in the other. The phase field specifies when a low frequency periodic effect begins along its wavelength. The period is utilized to specify the frequency of vibration. The sample rate specifies a special effect. For example, a sine wave effect played at a low frequency sample rate results in a rough texture sine wave effect.

Set Constant/Ramp Parameter Block. The Set Constant/Ramp Parameter Block may be shared by constant and ramp features because they have so few properties. Besides report type and index, exemplary fields for Set Periodic Parameter Block include a constant magnitude, ramp start level and ramp end level. The constant magnitude field specifies a constant positive or negative (directional) force. For a constant force, the ramp start and ramp end fields would be set to zero. The ramp start and end levels specify starting and ending magnitudes. For a ramp force, the constant magnitude would be set to zero. The effect block portion of the ramp feature specifies a linear ramp force between the starting and ending magnitudes.

Device Data Input Report. The Device Data Input Report is specifically identified as movements165inFIG. 1, although much more than movements165may be communicated by device130to host105. Exemplary fields for Device Data Input Report may include report type, buttons, left pedal position, right pedal position, axis position, etc. The report type field would of course indicate the type of report is a Device Data Input Report. The buttons field may indicate, e.g., an indication of on/off in subfields, human interaction with a selected group of on/off human interface elements including buttons, paddles, directional pads, etc. Right pedal position may indicate, for example, the position of an accelerator pedal. Left pedal position may indicate, for example, the position of a brake pedal. Axis position may indicate the x and y axis position of a stick or wheel. It would be expected that an underlying communication protocol would support, at least in part, input from device105to report interaction with human interface elements such as a steering wheel and buttons as shown inFIG. 4for example. The underlying communication protocol may have an established frame rate, e.g., every few milliseconds, for device130to send a Device Data Input Report to host105.

Device Control Command. A Device Control Command may be used to control overall effect operation of device130. Exemplary fields for Device Control Command may include, control field for standard and native features and, to avoid packet filtering, a toggle bit field. The value in the control field for standard features may indicate, for example, no change, enable motors, disable motors, stop effects, reset device, pause play list and continue play list. No change indicates that Device Control Command is not making any changes to the control of standard effects in the active play list. Enabling and disabling motor fields enables or disables force feedback motors. Stop effects indicates that all effects in the active play list should be stopped. Reset device may, for example, clear the active play list of effects, clear block pool200of all features and enable all motors. A Device Control Command indicating reset device may be sent to device130, for example, prior to downloading features into block pool200. Pause play list may pause all effects in the active play list, following which, device130may log but not execute all effect operation commands (e.g. start, stop) until the active play list is continued, e.g., by a continue play list command. Continue play list may restart effects in the active play list that were previously paused, allowing completion of accumulated effect operation commands in the order logged. The value in the control field for native features may indicate, for example, no change, stop native effect and start native effect. No change indicates that Device Control Command is not making any changes to the control of native effects in the active feature play list. Stop and start native feature may, for example, remove or add the native effect to the active feature play list. As with other messages, a toggle bit (toggled in every message) may be useful to evade packet filtering by host radio115executing an underlying communication protocol.

Device Gain Command. A Device Gain Command may, for example, be used to broadcast a normalized scaling factor to all effects in the active play list. The scaling factor may increase or decrease the magnitude of each effect in the active play list. A value of zero for the scaling factor may indicate that, while the features in the active play list should still be played, device130should not provide any force feedback effects. As with other messages, a toggle bit (toggled in every message) may be useful to evade packet filtering by host radio115executing an underlying communication protocol.

Effect Operation Command/Report. An Effect Operation Command may be used to simultaneously control numerous features stored in block pool200. Exemplary fields for Effect Operation Command may include, for example, report type, control, and index fields. The value in the report type field indicates an Effect Operation Command. The control field may indicate, for example, pool type and a specific control for each indexed feature. Pool type may differentiate, for example, active and inactive play lists, standard, custom and native features that may be stored as independent sets of features perhaps segregated in device memory. The specific control for each indexed feature may indicate, for example, no change, stop effect and start effect. Starting an effect may, for example, add a feature to an active play list while stopping it may remove it from an active play list.

In response to an Effect Operation Command, Device130may respond with an Effect Operation Report. An Effect Operation Report may serve to guarantee successful delivery and execution of commands from host105by providing positive feedback. Device130may send the Effect Operation Report after receiving the command message from host105, computing a checksum and determining the success or failure status of each control command. Exemplary fields for the Effect Operation Report may comprise, for example, report type, control status, play list pause, play list empty, pool type status and a toggle bit. Report type would indicate that the report is an Effect Operation Report. Control status may indicate, for example, the successful or failed execution of each of the commands to each indexed feature. Play list pause may indicate, for example, that a command may not have been completely carried out due to a pause in the active play list. If a command had been made to play a feature during a pause then the feature may be loaded into the active play list, but would not be played until the play list is continued. Likewise, a command to stop a feature during a pause may have to wait to be unloaded from the active play list until the play list is continued. Play list empty may indicate an empty play list, e.g., due to a stop command or load errors. Pool Type Status may indicate an error if, for example, the Effect Operation Command attempted to operate on the wrong pool type. As with other messages, a toggle bit (toggled in every message) may be useful to evade packet filtering by host radio115executing an underlying communication protocol that seeks to eliminate seemingly duplicative messages through packet filtering.

Of course the foregoing messages are merely exemplary. Messages may also be mode-specific. For example, debugging messages may be operational only in debugging mode and not during normal operation. An Effect State Report may be sent by device130to host105whenever an indexed feature changes state. Exemplary fields of an Effect State Report may include, for example, report type, index, state value, etc. Report type would indicate that the type of report is an Effect State Report. Index would indicate which feature is being reported. State value would indicate the prevailing state of the indexed feature.

Having described an example of what messages may be communicated between host105and device130, some or all of which may not exist in the underlying communication protocol, an example of how those messages are communicated will now be described. As previously described, an existing host105may not adequately support implementation of haptic features in device130. As previously discussed, one way to overcome this, at least in part, may be to store standard, custom and native features in device130. Another way to overcome this, at least in part, may be to provide additional communication messages absent from an underlying communication protocol. This additional messaging may necessitate, for example, evading certain aspects of the underlying communication protocol such as evading packet filtering using a toggle bit. Additional messaging to increase bandwidth and reduce latency may also necessitate non-compliance with header and payload definitions in the underlying protocol. The additional and/or existing communication messages may use header portions of communication packets as payload portions to increase communication bandwidth. Also, as shown inFIG. 1, there may be several underlying protocols to contend with, e.g., the protocol for USB120and the protocol for wireless communication of commands175and movements170.

A header is typically reserved for the provision of supplemental information about a message in a payload portion of a communication packet. The payload rather than the header provides the message, whether it be an instruction and/or data. It may be necessary to redeploy the header portions of communication packets defined by one or both underlying protocols for USB120and the wireless link180between host105and device130. This may vary from one embodiment to the next. In some embodiments, none, one or several redeployments may be necessary. In some embodiments, redeployment may only be unidirectional (i.e. up or downstream, but not both) while in others it may be bi-directional (i.e. up and downstream). The underlying communication protocols for USB120and wireless link180may have different protocols, each of which may define a header portion of a communication packet differently than the other. The underlying communication protocols for USB120and wireless180may even define the header and payload portions of communication packets differently for up and downstream communications. Therefore, the number of bits or bytes in a header that may be used may vary widely from one embodiment to the next. It is understood that there are numerous terms that may describe the use of a portion or all header bits to send messages, including but not limited to redeployment, reassignment, redefining, modifying, overriding, non-compliance as in not complying with the underlying protocol, etc.

In some embodiments, a header may be used in combination with payload while in other embodiments only a header portion or only a payload portion may be used for additional messaging absent from an underlying communication protocol. For example, a Device Link Request sent by device130to establish a wireless communication link with host105may provide device type and subtype in a 12 bit portion of the header portion that may be defined by the underlying communication protocol for wireless link180, e.g., 4 bits for type and 8 bits for subtype. As another example, five downstream messages from host105to device130may be transmitted to device130entirely in six to 12 header bits. The five downstream messages may include, for example, Device State Request, Feature Play Status Request, Device Capabilities Request, Device Control Command and Device Gain Command. These, and perhaps other messages, may each be assigned a unique six bit identifier. Command messages, e.g., Device Control Command and Device Gain Command, may use an additional six header bits for control fields to control, as previously described, standard and custom features, native features and haptic effect gain plus a one bit toggle field to evade packet filtering. Other downstream messages may be sent within, for example, an eight-byte payload defined by the underlying wireless communication protocol.

Upstream messages may have available more or less header and payload resources. For example, in a 40 bit message header and a 19 byte payload protocol, 16 header bits plus the payload may be used for new upstream messages to support haptic effects. For example, Device State Report, Block Load Report, Effect Operation Report, perhaps among other upstream messages, may be transmitted to host105entirely in a header portion of a communication packet. They may be assigned, for example, a unique four-bit identifier plus an additional 11 bits to provide the information requested by host105, as previously discussed, plus an additional bit to toggle to evade packet filtering. Other upstream messages may be sent within, for example, a 19-byte payload defined by the underlying wireless communication protocol.

As previously described, the integrity of communications may be maintained though a number of aspects of the wired or wireless overlay communication protocol over an underlying communication protocol. One such method is message pairing, e.g., pairing a particular request or command message from host105to a particular report from device130. Another is requiring positive feedback. Yet another is error checking, e.g., providing checksum values in reports. Yet another is requiring a status not only for receipt, but for the resulting execution of requests and commands. The use of toggle bits and packet counters further improve the integrity of communications. These various aspects of the protocol mitigate dropouts, lost packets and filtered packets to essentially guarantee delivery. As such, retries may occur less often. Further, device130may, in certain cases, be allowed to respond immediately or within several frames or time certain in accordance with the overlying communication protocol.

Exemplary Host System

An exemplary host system comprises, for example, a game console, such as an XBOX® game console, or general purpose computer.FIGS. 4 and 5provide block diagrams of exemplary host shown inFIG. 1.

FIG. 4is a block diagram of an exemplary host in which an enhanced protocol and architecture for low bandwidth force feedback game controller can be implemented.FIG. 4provides greater detail of host105shown inFIG. 1. Game console400comprises hardware, firmware and software. Game console400executes game applications (not shown). For purposes of simplicity, not all components or interconnectivity are shown and some components have been merged in exemplary game console400.

Game console400comprises central processing unit (CPU)401, which has level 1 (L1) cache402, level 2 (L2) cache404, and ROM (Read-Only Memory)406. Level 1 and Level 2 cache402,404temporarily store executable instructions and/or data, thereby improving processing speed and throughput. ROM406may store basic executable instructions (i.e. firmware) that are loaded during an initial phase of a boot process when the game console400is initially powered. Alternatively, the executable code that is loaded during the initial boot phase can be stored in another type of non-volatile memory. ROM406, or the alternative non-volatile memory need not be embedded within CPU401. Game console400may optionally be a multi-processor system. For example, game console400may have three processors401,403, and405, where processors403and405, which may be similar or dissimilar to processor401. CPU's401,403and403may share cache memory (not shown).

Game console400further comprises graphics processing unit (GPU)408, which is coupled to CPU401, and any additional processors such as CPUs403,405, by a bus. GPU408is also coupled by one or more busses each to memory controller410, I/O (input/output) hub418and video codec (coder/decoder)414. Memory controller410and video codec414may form part of GPU408. GPU408, in addition to video processing functionality, may comprise functionality commonly referred to as Northbridge. Northbridge functionality generally comprises a high speed memory and video hub having a memory controller and a video controller. In exemplary game console400, both CPU401and I/O hub (Southbridge)418access memory412through Northbridge functionality in GPU408. Memory controller410facilitates access to various types of memory412, which may be RAM (Random Access Memory) or other variety of memory.

GPU408and video codec414together form a video processing pipeline for high speed, high resolution graphics processing required by many game applications. Data is carried from GPU408to/from video codec414via a bi-directional bus. This video processing pipeline outputs data to A/V (audio/video) port440for transmission to a television or other video display device (not shown). Game console500may have its own integrated display. Not shown is a digital to analog converter (DAC) that may be coupled between video codec414and A/V port440.

Game console400further comprises I/O hub418, which may comprise, among other functionality, functionality commonly referred to as Southbridge. Southbridge functionality generally performs and controls functions that are relatively slow compared to functions performed and controlled by Northbridge. I/O hub418comprises I/O controller420, system management controller422, audio processing unit423, network interface controller424, USB host controllers426,428and front panel I/O subassembly430. USB controllers426,428serve as hosts for peripheral controllers442(1),442(2), wireless adapter448, and memory unit446(e.g., flash memory, CD/DVD ROM, hard drive, other removable media). Network interface424and/or wireless adapter448provide access to a network (e.g., local area network (LAN), Internet) and may be any of a wide variety of various wired or wireless interface components including an Ethernet card, modem, Bluetooth module, and the like.

System memory443may store application data that is loaded during the boot process. Media drive444may comprise, for example, a DVD/CD drive, hard drive or other fixed or removable media reader and/or writer. Game application data may be read from and/or written to media via media drive444for execution, playback, etc. by game console400. Media drive444is connected to I/O controller420via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 5394). Game console400may include hard disk452, which may be used, for example, to store an operating system, game applications, game data or other types of data.

System management controller422provides a variety of service functions for game console400. Audio processing unit423and audio codec432form a corresponding audio processing pipeline that may provide high fidelity, 5D, surround, and stereo audio processing of sounds produced by, for example, a game application. Audio data is carried between audio processing unit423and audio codec432via a communication link. The audio processing pipeline outputs audio data to A/V port440for implementation by a device having audio capabilities.

Front panel I/O subassembly430supports the functionality of various controls such as power button450and eject button452, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of game console400. System power supply module436provides power to components of game console400while fan438cools them.

CPU401, GPU408, memory controller410, and various other components within game console400are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. As previously noted, not all buses or other connections are shown inFIG. 4.

When game console400is powered on or rebooted, application data and/or instructions can be loaded from system memory443, media drive444, hard disc453or other memory into memory412and/or caches402,404and executed on the CPU401. The game application being executed may present a graphical user interface that provides a consistent user experience when navigating to different media types available on or to game console400. Instructions and/or data accessible via media drive444, system memory443, hard disk453or other memory may be launched, played or otherwise accessed from these various sources to provide additional functionality to game console400.

Game console400may be operated as a stand alone system by connecting the system to a television or other display. As previously noted, game console400may have an integrated display. In this stand alone mode, game console400may allow one or more users to interact with the system, watch movies, listen to music, play games and the like. Network interface424or wireless adapter448may allow game console400to be operated as a participant in a local or wide area network community.

FIG. 5and the following discussion provide a brief general description of a suitable computing environment in which enhanced protocol and architecture for low bandwidth force feedback game controller can be implemented. Although not required, various aspects of enhanced protocol and architecture for low bandwidth force feedback game controller can be described in the general context of computer executable instructions, such as program modules, being executed by a computer, such as a personal computer, client workstation or a server. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, implementation of enhanced protocol and architecture for low bandwidth force feedback game controller can be practiced with other computer system configurations, including hand held devices, multi processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Further, enhanced protocol and architecture for low bandwidth force feedback game controller also can be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

A computer system can be roughly divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component (also referred to as the “user component” or “software component”). In various embodiments of a computer system the hardware component may comprise central processing unit (CPU)521, memory (both ROM564and RAM525), basic input/output system (BIOS)566, and various input/output (I/O) devices such as keyboard540, mouse562, display545, and/or printer (not shown), among other components. The hardware component comprises the basic physical infrastructure for the computer system.

The application programs component comprises various software programs including but not limited to compilers, database systems, word processors, business programs, video games, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users). In an example embodiment, application programs perform the functions associated with enhanced protocol and architecture for low bandwidth force feedback game controller as described above.

The hardware/software interface system component comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel. An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system. A purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.

The hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system. The application programs interact with the hardware/software interface system by requesting services via an application program interface (API). Some application programs enable end-users to interact with the hardware/software interface system via a user interface such as a command language or a graphical user interface (GUI).

A hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.

A hardware/software interface system shell (referred to as a “shell”) is an interactive end-user interface to a hardware/software interface system. (A shell may also be referred to as a “command interpreter” or, in an operating system, as an “operating system shell”). A shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users. In contrast to a shell, a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.

As shown inFIG. 5, an exemplary general purpose computing system includes a conventional computing device560or the like, including a processing unit521, a system memory562, and a system bus523that couples various system components including the system memory to the processing unit521. Processing unit521may comprise, for example, a CPU, Northbridge and Southbridge chipset, among other components. The system bus523may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)564and random access memory (RAM)525. A basic input/output system566(BIOS), containing basic routines that help to transfer information between elements within the computing device560, such as during start up, is stored in ROM564. The computing device560may further include a hard disk drive525for reading from and writing to a hard disk (not shown), a magnetic disk drive528(e.g., floppy drive) for reading from or writing to a removable magnetic disk529(e.g., floppy disk), and an optical disk drive530for reading from or writing to a removable optical disk531such as a CD ROM or other optical media. The hard disk drive525, magnetic disk drive528, and optical disk drive530are connected to the system bus523by a hard disk drive interface532, a magnetic disk drive interface533, and an optical drive interface534, respectively. The drives and their associated computer readable media provide non volatile storage of computer executable instructions, data structures, program modules and other data for the computing device560. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk529, and a removable optical disk531, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in the exemplary operating environment. Likewise, the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.

A number of program modules comprising computer-executable instructions can be stored on any one or more computer-readable mediums such as the hard disk, magnetic disk529, optical disk531, ROM564, or RAM525, including an operating system535, one or more application programs536, other program modules535, and program data538. A user may enter commands and information into the computing device560through input devices such as a keyboard540and pointing device562(e.g., mouse). Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to the processing unit521through a serial port interface546that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). Aside from mouse542, keyboard540and modem554, serial port I/F546may also be connected to a wireless communications device (not shown). A display545or other type of display device is also connected to the system bus523via an interface, such as a video adapter548. In addition to display545, computing devices typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary environment ofFIG. 6also includes a host adapter555, Small Computer System Interface (SCSI) bus556, and an external storage device562connected to the SCSI bus556.

The computing device560may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer549. The remote computer549may be another computing device (e.g., personal computer), a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computing device560, although only a memory storage device550(floppy drive) has been illustrated inFIG. 6. The logical connections depicted inFIG. 6include a local area network (LAN)551and a wide area network (WAN)552. Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computing device560is connected to the LAN551through a network interface or adapter553. When used in a WAN networking environment, the computing device560can include a modem554or other means for establishing communications over the wide area network552, such as the Internet. The modem554, which may be internal or external, is connected to the system bus523via the serial port interface546. In a networked environment, program modules depicted relative to the computing device560, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

While it is envisioned that numerous embodiments of enhanced protocol and architecture for low bandwidth force feedback game controller are particularly well-suited for computerized systems, nothing in this document is intended to limit the enhanced protocol and architecture for low bandwidth force feedback game controller to such embodiments. On the contrary, as used herein the term “computer system” is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.

The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatuses for enhanced protocol and architecture for low bandwidth force feedback game controller, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for implementing enhanced protocol and architecture for low bandwidth force feedback game controller.

The program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations. The methods and apparatuses for implementing enhanced protocol and architecture for low bandwidth force feedback game controller also can be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of enhanced protocol and architecture for low bandwidth force feedback game controller. Additionally, any storage techniques used in connection with enhanced protocol and architecture for low bandwidth force feedback game controller can invariably be a combination of hardware and software.

While enhanced protocol and architecture for low bandwidth force feedback game controller has been described in connection with the example embodiments of the various figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same functions of enhanced protocol and architecture for low bandwidth force feedback game controller without deviating there from. Therefore, enhanced protocol and architecture for low bandwidth force feedback game controller as described herein should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.