This disclosure is directed to techniques for enabling platform independent bidirectional communications between a mobile controller device and a host device over a communication protocol.
Mobile devices, such as a mobile phone may no longer be seen as simply a communications device providing voice call functionality. Mobile devices may be implemented as a computing platform that can be used to run a variety of applications, including text messaging, address book, calendar, other productivity applications, mapping applications, gaming applications and many others.
The Bluetooth 2.0 standard can specify a variety of “profiles” designed to enable a limited number of devices, such as a mouse, a keyboard, a wireless headset, and a hands free car kit to communicate with the mobile phone. These profiles are typically implemented in firmware on mobile phones—for example, a mobile phone that supports the Human Interface Device (“HID”) profile would have the HID protocol embedded in firmware. In addition, to take advantage of a Bluetooth 2.0 profile, both the mobile phone and the input, output, or input/output device that the mobile phone wishes to communicate with are required to have the same profile supported in firmware or software.
Implementations of the human interface and input system and techniques for enabling platform independent communications between a mobile controller device and a host device described here may include various combinations of the following features.
In one aspect, providing platform independent bidirectional communications between a mobile controller device and a host device over a communication protocol includes delivering an array of bytes from the mobile controller device to the host device. The array of bytes delivered describes one or more data packets of the mobile controller device. When detected that the host device includes a native device driver, the native device driver is used to parse the delivered array of bytes. Alternatively, when detected that the host device does not include a native device driver, a device driver is provided to parse the delivered array of bytes.
Implementations may optionally include one or more of the following features. Providing the device driver can include providing a customized human interface device driver based on the delivered array of bytes. Also, to provide the platform independent bidirectional communications, bidirectional communications compatible with Java platform can be provided. To deliver the array of bytes, a fixed number of bytes from the array of bytes can be used to generate one or more device specific descriptors that support one or more sensors not supported by a native human interface device descriptor. Further, generating the one or more device specific descriptors that support one or more sensors can include generating one or more device specific descriptors that support at least one selected from a group of a joystick, a linear potentiometer, a trackball, an encoder, a force sensitive resistor, a strain gauge, a series of digital switches, an accelerometer, a gyro, an inertial sensor, and an electromagnetic sensor. Also, providing the platform independent bidirectional communications can include providing at least two communication channels that are accessible by a Java platform driver. In addition, delivering the array of bytes can include delivering a variable sequence of bytes customized for the mobile controller device. Delivering a variable sequence of bytes can further include mapping each byte in the sequence of bytes to one or more input elements on the mobile controller device; and changing a value assigned to each byte based on a state of the input element.
In another aspect, the techniques described in this specification can be implemented as a computer program product, embodied on a computer-readable medium and designed to cause a data processing apparatus to perform various operations. For example, the computer program product is designed to provide platform independent bidirectional communications between a mobile controller device and a host device over a communication protocol. Providing the platform independent bidirectional communication includes delivering an array of bytes from the mobile controller device to the host device, with the array of bytes describing one or more data packets of the mobile controller device. When detected that the host device includes a native device driver, the computer program product is designed to use the native device driver to parse the delivered array of bytes. Alternatively, when detected that the host device does not include a native device driver, the computer program product is designed to provide a device driver to parse the delivered array of bytes.
Implementations can optionally include one or more of the following features. The computer program product can be designed to cause the data processing apparatus to perform operations further comprising providing a customized human interface device driver based on the delivered array of bytes. The computer program product can be designed to cause the data processing apparatus to perform operations that includes providing platform independent bidirectional communications by at least providing bidirectional communications compatible with Java platform. The computer program product can be designed to cause the data processing apparatus to perform operations that includes delivering an array of bytes by at least using a fixed number of bytes from the array of bytes to generate one or more device specific descriptors that support one or more sensors not supported by a native human interface device descriptor. Also, the computer program product can be designed to cause the data processing apparatus to perform operations that includes generating one or more device specific descriptors that support one or more sensors by at least generating one or more device specific descriptors that support at least one selected from a group of a joystick, a linear potentiometer, a trackball, an encoder, a force sensitive resistor, a strain gauge, a series of digital switches, an accelerometer, a gyro, an inertial sensor, and an electromagnetic sensor. The computer program product can be designed to cause the data processing apparatus to perform operations that includes providing platform independent bidirectional communication having at least two communication channels that are accessible by a Java platform driver. The computer program product can be designed to cause the data processing apparatus to perform operations that includes delivering an array of bytes having a variable sequence of bytes customized for the mobile controller device. Further, the computer program product can be designed to cause the data processing apparatus to perform operations that includes delivering a variable sequence of bytes that includes mapping each byte in the sequence of bytes to one or more input elements on the mobile controller device; and changing a value assigned to each byte based on a state of the input element.
In yet another aspect, the techniques described in this specification can be implemented as a mobile controller device that includes a communication mechanism designed to operate a communication stack including a baseband protocol designed to connect the mobile controller device to a host device. The mobile controller device also includes a bidirectional serial communication protocol designed to operate over the baseband protocol to send one or more messages to the host device. Each sent message includes a sequence of bytes. The controller device also includes a controller firmware designed to monitor input signals provided by various input mechanisms available to the mobile controller device, and generate the one or more messages. The bidirectional serial communication protocol enables platform independent bidirectional communications between the mobile controller device and a host device over the baseband protocol.
Implementations can optionally include one or more of the following features. The bidirectional serial communication protocol that enables platform independent bidirectional communications can include a bidirectional communication compatible with Java platform. The controller firmware can be designed to take a fixed number of bytes from the sequence of bytes to generate one or more device specific descriptors that support one or more sensors not supported by a native human interface device descriptor. The controller firmware can also be designed to generate one or more device specific descriptors that support at least one selected from a group of a joystick, a linear potentiometer, a trackball, an encoder, a force sensitive resistor, a strain gauge, a series of digital switches, an accelerometer, a gyro, an inertial sensor, and an electromagnetic sensor. The controller firmware can be designed to generate the one or more messages, with each generated message including a variable sequence of bytes customized for the mobile controller device. The controller firmware can be designed to map each byte in the sequence of bytes to one or more input elements of the various input mechanisms available to the mobile controller device and change a value assigned to each byte based on a state of the mapped one or more input elements.
Techniques for enabling platform independent bidirectional communications between a mobile controller device and a host device over a communication protocol described herein potentially may provide one or more of the following advantages. The systems and techniques described in this specification may provide an efficient, lightweight mechanism for a mobile controller device and a host device to exchange sensor data, state information and any other types of data that can be serialized and sent in a small footprint. The mechanism can be fast and efficient, take up a small footprint in firmware and/or software, and incur a minimum amount of timing overhead in the process of sending and receiving the pertinent data. The mechanism can be specifically defined to support a wide variety of sensors commonly used in gaming, including analog signals from potentiometers or multiple-degrees-of-freedom analog joysticks; digital encoders such as what might be found in optical mice, or in higher end robotic devices; force sensitive resistors which provide a proportional signal in response to varying pressures applied; accelerometer and gyroscope signals; signals from trackballs; signals from force sensing devices such as strain gauge based navigation sticks; proportional or digital signals from optical sensors, signals from electromagnetic sensors and the like. The mechanism can be implemented as a communication protocol that can also be extended to enable the mobile controller device and the host device to exchange other types of data that can be serialized, such as game state information, car diagnostic information, GPS fixes and the like.
The systems, and techniques described in this specification may be implemented as an Application Program Interface (API) that can operate across a variety of transport protocols, such as the Bluetooth logical link control and adaptation protocol (L2CAP) or the Bluetooth serial port profile (SPP), or over other wired or wireless transport protocols. For example, the same API can be designed to support communications over USB, Firewire, IrDA or other wired and wireless communication protocols.
The communication protocol can furthermore be implemented in a variety of mechanisms, including an HID based mechanism, a fixed-length serial mechanism involving a fixed number of bytes with a predefined syntax that is sent from the mobile controller device to the host device, and a bidirectional communication protocol mechanism allowing queries and data to be sent from the mobile controller device to the host device and vise versa.
The HID based mechanism can provide a lightweight Java implementation of a subset of the HID profile on the host device, and optionally include custom HID descriptors to support common sensors appropriate for mobile controller devices. The fixed-length serial mechanism can reflect a byte structure with a fixed number of bytes that is largely universal to sensors appropriate for mobile controller devices. The bidirectional serial communication protocol mechanism can involve a custom byte sequence structure can be implemented to provide support for common sensors appropriate for mobile controller devices
Regardless of whether the HID based mechanism or a serial communication protocol is implemented, the systems and techniques described in this specification may furthermore be incorporated in an API implemented on a programming platform running on the host device, such as Java. Such API can be incorporated into applications running on the host device.
The subject matter described in this specification can be implemented as a method, a system or computer program products tangibly embodied in information carriers, such as a CD-ROM, a DVD-ROM, a semiconductor memory, or a hard disk. Such computer program products may cause a data processing apparatus to conduct one or more operations described in this specification.
In addition, the subject matter described in this specification can also be implemented as a system including a processor and a memory coupled to the processor. The memory may encode one or more programs that cause the processor to perform one or more of the method acts described in this specification. Further the subject matter described in this specification can be implemented using various data processing machines.
Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
a and 1b are block diagrams illustrating a system for enabling communications between a controller device and a host device.
Like reference symbols in the various drawings indicate like elements.
Overview
a and 1b are block diagrams illustrating a system 100 for enabling platform independent (i.e., independent of communication protocol, such as Bluetooth, USB, Firewire, IrDA, etc.) communications between a controller device 110 and a host device 120. The controller device 110 communicates with the host device 120 using a communications protocol 130.
The host device 120 includes devices with one or more embedded processors such as a mobile phone, a personal digital assistant (PDA), a smart phone, a personal navigation systems, a digital video recorder (DVR) device, a car with technology upgrades that provides information (e.g., GPS navigation, wireless communication) and/or entertainment (e.g., digital video disk drive), a pedometer, a glucose meter, a blood pressure sensor, a bathroom scale and the like. The input controller device 110 is designed to communicate with the host device 120 and provide intuitive interface elements for controlling the host device 120. By providing intuitive interface elements, the controller device 110 can facilitate control and execution of complex applications such as gaming and mapping applications, for example. The controller device 110 includes mobile accessory devices that provide various intuitive control interface elements. Examples of such controller devices 110 are described in co-pending U.S. patent application entitled “Human Interface Input Acceleration System” (U.S. Patent Application Publication No. 20070080934) and U.S. patent application entitled “Human Interface Input Acceleration System” (U.S. Patent Application Publication No. 20070080931.) The contents of these co-pending applications (U.S. Patent Application Publication Nos. 20070080934 and 20070080931) are incorporated by reference.
The communications protocol stack 130 enables bidirectional exchange of communication signals between the controller device 110 and the host device 120. The communications protocol stack 130 includes a platform independent transport protocol 134 operating on top of a transport mechanism 132. The transport mechanism 132 includes one or more wired or wireless transport/communications protocols such as Bluetooth, Universal Serial Bus (USB), Firewire, IrDA, etc. The platform independent transport protocol 134 is designed to operate over one or more of the various transport mechanisms. The platform independent transport protocol 134 can be implemented using an application programming interface (API) that resides on top of the transport mechanism 132. An API is a source code interface that a computer system or program library provides to support requests for services.
The platform independent transport protocol 134 as described in this specification can be implemented under various mechanisms to enable communications between a mobile controller device and a host device or among multiple mobile controller devices and host devices. For example, the platform independent transport protocol can be implemented under an HID based mechanism, a fixed-length serial mechanism, or a bidirectional serial communication protocol mechanism.
HID Based Mechanism
The platform independent transport protocol 134 can be implemented under an HID based mechanism to enable communications between a mobile controller device and a host device. The HID based communication protocol is built upon the existing HID specifications for standard HID devices. (see, e.g., Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.11 (www.usb.org) and the Universal Serial Bus (USB) HID Usage Tables, Version 1.12 (www.usb.org), which are incorporated in full herein by reference.). A lightweight Java 2 Micro Edition (J2ME) implementation for a HID profile can be implemented to run on mobile devices such as mobile phones and other mobile device that serve as a host device. The firmware on one or more mobile controller devices also contain a lightweight implementation of the HID profile. Custom descriptors can be implemented to support common and specialty sensors appropriate for use in the one or more mobile controller devices.
In addition to the byte layout of a report, a report descriptor can also include some semantics to the various fields. For example, the X-axis field for the joystick can be defined to be an 8 bit signed value that ranges from −127 to 127, representing the position of the joystick along the X-axis. In some implementations, a second descriptor can be provided in which the X- and Y-axis readings provide 16-bit resolution instead of the 8-bit resolution in the first descriptor.
These two pipes are implemented in the HID protocol as two L2CAP connections on channels 0x11 and 0x13. To provide support for Java (e.g., J2ME) implementations as a gaming and application development platform, a lightweight Java implementation of a subset of the HID profile is provided Thus, in addition to the two L2CAP channels 0x11 and 0x13 for HIDP compliance , two additional L2CAP channels 0x1011 and 0x1013 are implemented to provide access from a Java driver (e.g., J2ME implementation.)
In an alternative implementation, a custom serial transport protocol is implemented to operate over the Serial Port Profile (SPP). Instead of using an L2CAP implementation as in the HID protocol, other transport mechanisms are employed to provide a transport channel over the Bluetooth stack. The SPP allows various devices to set up an emulated serial cable connection using Radio Frequency Communication (RFCOMM) (See, Serial Port Profile Specification, Version 1.1 (www.bluetooth.org), which is incorporated in full herein by reference.) RFCOMM is a simple transport protocol that provides emulation of the nine circuits of RS-232 serial ports over the L2CAP protocol (See, RFCOMM Specification, Version 1.1 (www.bluetooth.org), which is incorporated in full herein by reference.) This implementation is different from the HID protocol, which uses L2CAP directly and does not use the additional functionality afforded by SPP.
Fixed-Length Serial Protocol Based Mechanism
In an alternative embodiment, a fixed length serial sequence may be employed to allow the mobile controller device to pass information to the host device. This byte sequence may be sent from the mobile controller device to the host device using the Bluetooth SPP (Serial Port Profile) as a transport mechanism.
The controller firmware 712 monitors the analog and digital signals provided by the various input mechanisms available to the controller device 710 (e.g., buttons, joysticks, trackballs). Whenever a signal event occurs (e.g., a button is pressed, a joystick is moved), the controller firmware generates a message using the fixed-length protocol 713 and sends the message to the host device 720.
The fixed length byte sequence would have a predetermined number of bytes. Each byte within this sequence would have a specific purpose. In one embodiment, the last byte in the sequence may be designated as the “termination byte” and may always represent a fixed value—for example, 0xFF—that the data is constrained not to reach. In an alternative embodiment, the first byte in the sequence may encode the number of bytes in the byte stream.
The controller driver 723, running on the host device 720 and linked to the host application, receives the fixed-length serial sequence protocol message and translates the message into one or more application-level events. These events are then sent to the host application.
In one implementation, the fixed-length serial sequence protocol 713 is unidirectional 730 from the controller device 710 to the host device 720. While the controller device 710 can send messages to the host device 720, the host device cannot send messages back to the controller device 730. In alternative implementations, the fixed-length protocol 713 may be bidirectional (not shown), enabling the host device to send commands to the mobile controller device using a similarly predetermined, fixed-byte sequence.
The fixed-length serial sequence protocol 713 is an exemplary protocol that can implement a custom, fixed byte sequence to support a wide variety of sensors commonly used in gaming, including (1) analog signals from potentiometers or multiple-degrees-of-freedom analog joysticks; (2) digital encoders such as those found in an optical mouse or in higher end robotic devices; (3) force sensitive resistors that provide a proportional signal in response to varying pressures applied; (4) accelerometer and gyroscope signals; (5) signals from trackballs; (6) signals from force sensing devices such as strain gauge based navigation sticks; (7) proportional or digital signals from optical sensors; (8) signals from electromagnetic sensors; and the like.
In one embodiment, the frequency of the repeat events is fixed in the controller's firmware. The frequency is not configurable by the client application. In another embodiment, the frequency of the repeat events may be specified by the host using a fixed-byte serial sequence from the host device to the mobile controller device.
The second and third bytes represent the X and Y values of a joystick, a trackball, an accelerometer or other input elements, each represented as an 8 bit unsigned number (truncated to range from 1 to 254). The last byte is the termination byte, represented by 0xFF. Since the data values are constrained never to reach 255, (which is 0xFF in hexadecimal notation), we ensure that the framing byte value of 0xFF will reliably signify the end of a data stream.
Bidirection Serial Communication Protocol Based Mechanism
The platform independent communication protocol 134 can be implemented as a bidirectional serial communication protocol operating over a transport mechanism such as the Bluetooth Serial Port Profile (SPP). The byte sequence can be variable in length and flexible and extensible in design. While the Bluetooth Special Interest Group has specified a Human Interface Device Profile (HIDP), the Java 2 Micro Edition (J2ME) implementation of Bluetooth (JSR-82) does not necessarily support HIDP. J2ME also does not necessarily support the two simultaneous L2CAP connections required by HIDP. Thus, the bidirectional serial communication protocol, as described in this specification, is designed to mimic HIDP and to provide an HIDP-like data to flow over an SPP connection (or other connections, such as L2CAP) while supporting J2ME.
In some implementations of the bidirectional serial communication protocol 900, 1100, a fixed number of pre-defined byte sequences, or report formats, are implemented to allow the host device 1020 and mobile controller device 1010 to exchange a variety of data, including sensor information, state information and other types of data. The structure of the byte sequence is designed to be fully extensible so that a set of standard sensor types can be supported initially, and more sensor types can be supported over time as they become developed.
Any data that is reasonably compact in footprint and serializable such that the binary format fits within a 255-byte envelope may be easily transferred using the bidirectional serial communication protocol as described in this specification. Larger packets of data may be serialized and discretized into a number of smaller consecutive packets, with each packet designed to fit within the 255-byte envelope. By dividing the larger data packets into discrete number of smaller packets, any serializable data stream can be transmitted using the bidirectional serial communication protocol.
A paired set of parsers/serializers can be provided on both the mobile controller device side 710, 1010 and the host device side 720, 1020 that understand how to interpret those reports. For best compatibility, the parsers and serializers for the bidirectional serial communication protocol are version-matched on both sides. However, any version of the parser on either the mobile controller device side 710, 1010 or the host device side 720, 1020 can be designed to be able to receive a new serial communication based on the byte length encoded in the first byte, and examine the second byte to determine whether the parser recognizes the report type identifier. Depending on whether the report type identifier is recognized, the parser may elect to act upon the report type identifier, or ignore the received serial report based on a detection of an unknown report type identifier.
The following paragraphs describe in detail an exemplary implementation of a bidirectional serial communication protocol for mobile controller devices to transfer data to and from host devices. The examples are provided for illustrative purposes only, and other specific implementations of the byte sequences are possible. In addition, the types of sensors supported and the types of data transferred are also examples only. Implementations can enable support for other sensor types and data types under the platform independent communication protocol 134 implemented under the bidirectional communication protocol mechanism described in this specification.
An SPP data stream on the host device 1020 is viewed as an uninterrupted stream of data. The bidirectional serial communication protocol as described in this specification is packet-oriented, where each message is encapsulated in a packet. Since the host device's SPP implementation hides the notion of a packet, an “envelope scheme” is provided. In particular, each message is preceded by a byte count. For example, when the host device 1020 wants to send a SET_IDLE message to the controller device 1010 with a value of 12, the SET_IDLE message is formatted as shown in
The first byte (0x02) represents the number of bytes (i.e., byte count) in the next message. The next two bytes, 0x90 (the SET_IDLE message header) and 0x0C (the SET_IDLE value) are interpreted to be the SET_IDLE message.
In some implementations, to maintain forward compatibility, unrecognized DATA packets (i.e., input and output reports) are ignored.
A one-byte Handshake message is sent as acknowledgement of any SET_IDLE or DATA_OUTPUT messages. A list of valid Handshake values includes the following:
By default, the controller device 1010 sends input (e.g., button) events whenever the button state changes (i.e., when a button is pressed or released). The controller device 1010 supports the sending of button repeat events at a fixed period. This fixed period is identified in the SET_IDLE message by setting the idle rate (i.e., the repeat rate) of the controller.
An idle rate of zero (0) is interpreted as having no button repeat events emitted. This is the default behavior of the controller device 110, 710, 1010 whenever a new connection is established. The host device 120, 720, 1020 can send a SET_IDLE message to the controller device 110, 710, 1010 to specify a new repeat rate. The repeat rate is set to be the value sent in the SET_IDLE message, multiplied by a set amount of time (e.g., 4 ms). For example, sending a SET_IDLE message with a value of 12 has the controller device 110, 710, 1010 emit button repeat events every 48 ms.
The SET_IDLE message is responded to by using various applicable values. For example, a response to a valid SET_IDLE message is a HANDSHAKE_SUCCESSFUL value of 0x00. Alternatively, when detected that the length of the SET_IDLE message is not 2 bytes long, then a HANDSHAKE_ERR_INVALID_PARAMETER value of 0x04 is sent as a response. Also, when detected that the specified idle rate is less than the latency of the connection (assumed to be 50 ms), the controller device 110, 710, 1010 sets the idle rate to be equal to the latency.
When a connection is established between a controller device 110, 710, 1010, various standard reports are sent to the host device 120, 720, 1020. The standard reports sent includes (1) a Version Report; (2) a Configuration Data Report showing the Button Count; (3) zero or more Button Metadata Reports; (4) zero or more Configuration Data Reports; and (5) a Configuration Data report with a type of 0xFF and a value of 0x00000000. In addition, other custom reports can be sent.
A standard report represents the input and output available to be used in an API. For example, “input” is considered to be data flowing from the controller device 110, 710, 1010 to the host device 120, 720, 1020. “Output” is considered to be data flowing from the host device 120, 720, 1020 to the controller device 110, 710, 1010. All multi-byte values are sent in network byte order (big Endian). All strings are sent in UTF-8 (8-bit UCS/Unicode Transformation Format). While this is a standard convention, multi-byte values and strings can also be sent in other byte orders and other string formats as well.
The Value field (byte 3) contains the value corresponding to the type specified by the Type field (byte 2). Only those data that pertains to the controller device 110, 710, 1010 are be sent to the host device 120, 720, 1020. In other words, if the controller device 110, 710, 1010 has no accelerometers, no accelerometer count is sent.
The number of bits per sample, b, is greater than 2 and less than or equal to 32. The range of values allowed in the associated reports is represented as a range from (−2b−1) to (2b−1−1). For example, in one embodiment, the range of values for an 8-bit joystick can include −128 to 127 (representing a signed 8 bit value, with 0 being the middle of the range of motion). For a 12-bit joystick, the range of values includes −2048 to 2047. In some implementations, the range of values for an 8-bit joystick can range from 0 to 255 (representing an unsigned 8 bit value with 128 being the middle of the range of motion). For a 12-bit joystick, the range of values can include 0-4095, representing an unsigned 12-bit number, with 2048 being the middle of the range of motion.
Given the number of bits per sample for the various analog controls (e.g., joystick, accelerometer, paddle), the controller device 110, 710, 1010 emits input reports of the smallest size that fits that number of bits per sample. In other words, a 2-axis joystick with 10 bits per sample are sent in a 16-bit 2-axis joystick report.
Bit 1 of byte 3 in the Enable/Disable Report specifies whether the reports should be conditioned. When bit 1 of byte 3 is detected to be set, reports of the specified type are not conditioned. When the bit is detected to be cleared, reports of the specified type are optionally conditioned with a signal conditioning software algorithm on the controller device. Signal conditioning may involve implementation of a “dead zone” around the center of the joystick, truncation at the limits of the data range, scaling the raw data to generate resulting data in a given range, or other operations. When detected that the specified report ID is not an analog report, or is an analog report that does not use scaling, bit 1 of byte 3 is ignored (since no scaling can occur). When detected that specified Report ID cannot be enabled or disabled, or the specified Report ID is unrecognized, a HANDSHAKE_ERR_INVALID_PARAMETER is returned. Otherwise, a HANDSHAKE_SUCCESSFUL is returned.
The key codes are listed in the report in increasing order. If the nth key is not pressed down, the key code for the non-actuated button is reported as KEYCODE_NO_EVENT (0xFE). When detected that more than six keys (buttons) are pressed down, all six key codes are reported as KEYCODE_ERROR_ROLL_OVER (0xFF).
When an idle rate is not specified, or when the idle rate is set to “0”, Button Reports are sent each time the button state changes. Alternatively, when detected that a non-zero idle rate is specified, Button Reports are sent repeatedly whenever one or more buttons are pressed down at the specified idle rate. SET_IDLE is described further below.
The center position is reported as (0, 0). The X-Axis reading increases as the joystick moves to the right. The Y-Axis reading increases as the joystick moves down. When detected that the raw bit (byte 2, bit 7) is set, the reading is not conditioned. Alternatively, when the raw bit is cleared, the reading is conditioned.
While similarly designed as the 8-bit report, 16-bits are allocated for each Axis reading. The center position is reported as (0, 0). The X-Axis reading increases as the joystick moves to the right. The Y-Axis reading increases as the joystick moves down. When detected that the raw bit (byte 2, bit 7) is set, the reading is not conditioned. When detected that the raw bit is cleared, the reading is conditioned.
While similarly designed as the 8-bit report, 32-bits are allocated for each Axis reading. The center position is reported as (0, 0). The X-Axis reading increases as the joystick moves to the right. The Y-Axis reading increases as the joystick moves down. When detected that the raw bit (byte 2, bit 7) is set, the reading is not conditioned. When detected that the raw bit is cleared, the reading is conditioned.
As described above, Analog reports can be delivered raw (not conditioned). In general, conditioned reports are designed to send signed readings centered at 0 and scaled to fill a predetermined range (as specified in the bits-per-sample configuration data report). Raw reports are reports with values that not been processed. The raw reports represent the unprocessed sensor readings. As such, the raw reports are unsigned and the center reading is specified by the configuration data report specified above. For example, when detected that a report is raw, the readings are unsigned. Alternatively, when a report is conditioned, the readings are signed.
Various output reports can also be provided.
Further, the Run Loop test report is valid when detected that the desired report ID (byte 2) is a report that is supported by the device. For example, when the controller device 110, 710, 1010 does not have an accelerometer, the desired report ID cannot specify an accelerometer report. Alternatively the Run Loop test report is valid when detected that the desired report ID specifies an analog report type.
Receipt of a Run Loop Test report with zero iterations specified (e.g., bytes 4-7 are all equal to 0x00) cancels any currently executing loop test. The control device responds with a HANDSHAKE_SUCCESSFUL, even if there is no test currently running.
Transferring Data Between a Mobile Controller Device and a Host Device
In one aspect, a platform independent communication protocol, as described in this specification, is designed to transfer control data (enable communications) from a human interface device (e.g., a controller device 1010) to a host device 1020. The platform independent communication protocol 134 provides support for various controller devices having various input mechanisms (e.g., joystick and button state) to transfer data to a host device running an application, such as a game, that can be controlled by the various controller devices. In addition, the platform independent communication protocol as described in this specification is extensible in that further reports can be added to support transport of other types of data. While the platform independent communication protocol may be described with respect to a Bluetooth Human Interface Profile (HID) or Bluetooth Serial Port Profile (SPP) connection, other baseband connections are equally applicable. The bidirectional serial communication protocol 1017, 1027 is independent of the connection type. However, using another transport protocol (e.g. L2CAP) may make the byte sequence length unnecessary, or impose other “overhead” in the transmission.
The message is generated 3830 by the controller firmware based on the detected signal event. The message consists of a number of bytes designed to support a wide variety of sensors, including those commonly used in gaming, such as analog signals from potentiometers, or multiple-degrees-of-freedom analog joysticks; digital encoders such as what might be found in optical mice, or in higher end robotic devices; force sensitive resistors which provide a proportional signal in response to varying pressures applied; accelerometer and gyroscope signals; signals from trackballs; signals from force sensing devices such as strain gauge based navigation sticks; proportional or digital signals from optical sensors; signals from electromagnetic sensors and the like. In the case of an HID based approach, the byte sequence is defined in a custom descriptor. In the case of a fixed-length serial approach, the best match is found between the signals from the sensors and the preset byte syntax. In the case of a bidirectional serial communication protocol, the byte sequence is variable and perfectly matched to the actual output of the sensors and/or any other data output from the mobile controller device.
At least one of the sequences of bytes are mapped to one or more input elements on the input mechanisms available to the mobile control device. For example, when the mobile controller device includes a keypad, at least one of the bytes can be mapped to one or more of the buttons on the keypad. Similarly, for a joystick, at least one of the bytes can be mapped to the various movements of the joystick and/or buttons on the joystick. Additionally, each sensor type may be represented by a distinct report type identifier so that a variety of sensors may be supported by the same firmware and host software.
The generated message is sent 3840 to the host device. The controller driver running on the host device and linked to the host application, receives 3850 the message and translates 3860 the message into one or more application level events. These translated events are then sent 3870 to the host application. The host application processes 3880 the translated events. For example, when the host application is a game, the translated events are processed to execute a game function corresponding to a button press, joystick movement, etc.
Bluetooth Implementation
To establish a connection between a controller device and a host device, a controller device 1010 waits for another device to take initiative to connect. A host device 1020 (e.g., a cell phone, a PC, a mobile device, etc.) takes initiative to form a connection to the controller device 1010. The controller device 1010 provides an SPP Server (or L2CAP server, etc.) for the host device 1020 to connect. That Server can be identified, via the Service Discovery Profile (SDP), using a universally unique identifier (UUID). In one embodiment, this UUID can be selected to be associated with the platform independent communication protocol. All future implementations of the platform independent communication protocol can use the same UUID to provide backwards-compatibility. When a different UUID is used, backwards-compatibility is not guaranteed. A host device 1020 looking to connect to a controller device can identify the UUID. In an alternative embodiment, the UUID may be changed to reflect upgrades to the platform independent communication protocol.
Example Applications
The data transferred across the platform independent communication protocol may or may not be directly related to sensor output. For example, timestamp data may be retrieved. In another example, the mobile controller device may be used as a data transfer and storage device for other platforms.
In a similar example (not shown), the controller may retrieve GPS information from a navigation device, whether portable or integrated into a vehicle, and store it for future upload to a PC for review.
In another example (not shown), the controller device may retrieve game state information from a host device (e.g. a mobile phone), and transfer the information to a PC either for backup, or for platform independent game play for games which are also supported on the PC. Conversely, the controller device may retrieve game state information from a PC and transfer it to a mobile phone. Other platforms may be supported as well. The mobile controller device may therefore become a vehicle by which the gaming experience may be carried from one platform across another. For example, the platform independent communication protocol as described in this specification can be implemented to enable communications in a co-pending patent application entitled “Universal Controller for Toy and Games” (U.S. patent application Ser. No. 11/519,455).
Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus. The tangible program carrier can be a propagated signal or a computer readable medium. The propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a computer. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them.
The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device.
Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, input from the user can be received in any form, including acoustic, speech, or tactile input.
Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
While this specification contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.
Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this application.
Moreover, the methods to provide data input, device control or game control may be performed in a different order and still achieve desirable results. Accordingly, other implementations are within the scope of the following claims.