Wireless Inertial Joystick

Joystick control interfaces have applications in both entertainment systems and in commercial and industrial processes, ranging from simulation games to camera pan-tilt control and machine operation. Being able to remove a physical connection to a central device improves freedom and usability, while also removing the danger of accidents or damage to the connection cables.

This document is a reference design to be used as a starting point in a product development stage. This design implements a joystick control interface transmitting real time inertial information over a 2.4GHz radio connection. It can be used as a component in a larger embedded system, or as a standalone human-machine interface.

• Easily integrated into embedded systems via serial interfaces
• UART and USB implemented in current firmware, SPI and I²C available in the hardware
• Transmitting side works from a single 1.2V – 3.7V battery
• Receiving side connects to a terminal in a computer, or proprietary software (not specified)

• Game controllers
• Entertainment venue systems
• Machine interfaces
• Vehicle monitoring
• Camera pan-tilt control

There are two devices in this application: a transmitter joystick and a receiver adapter. In the transmitter, data from a 3 axis accelerometer is collected and sent via radio in the 2.4GHz band. The receiver adapter decodes this data, and transmits a formatted text to a second CPU, via UART. The second CPU is simply a UART-USB bridge, transmitting the data transparently to a computer.

An accelerometer is a component capable of measuring inertial acceleration forces. When an object is not moving, it experiences a force caused by gravity, so an accelerometer at rest measures the approximate direction towards the centre of the Earth.

This information can be used to evaluate the device inclination. As examples, if the gravity vector is measured to be downwards, the device is pointing up. If gravity vector is pointing to the right, the device is tilted to the right side. If gravity is up, the device is upside down.

A 3-axis accelerometer provides independent measurement channels on three mutually orthogonal axes, usually labelled X, Y and Z – although the actual interpretation of those is completely arbitrary and application-dependent.

This document proposes the development of a radio joystick controller, satisfying the following specifications:

1. 3 orthogonal axes of acceleration force sensing
2. Radio transmission on 2.4GHz ISM (Industrial, Scientific & Medical) license-free spectrum band
3. Transmitter powered by a coin cell battery
4. Receiver powered by a USB cable
5. Data rate at least 10 packets/second (one packet contains all three axes)

There are two parts in this design: a transmitter and a receiver. The transmitter side needs a three-axis accelerometer, a processor and a radio transmitter. The receiver side requires a radio receiver, a processor, and means to send data to a computer via USB connection, which in this design is a second processor.

The n-BLE is a n-Block featuring a Nordic nRF52832 integrated Cortex-M4 ARM microcontroller and a 2.4GHz configurable radio transceiver with onboard antenna. The CPU runs from 1.8V to 3.7V, allowing an application to run directly from a single battery.

The n-MC3635 is a n-Block based on the mCube MC3635 3-Axis Accelerometer, built in the n-Sensor form factor. It is ultra-low power, low noise and allows up to 1300 samples per second.

The n-DAP is a processor n-Block, powered by a LPC11U35 Cortex-M0 microcontroller, having 64kB of Flash memory, 8 kB of RAM memory and 4kB of EEPROM. It features SPI, I²C and UART communication, as well as an internal USB device transceiver available via a USB-mini connector.

For each component (sensors, actuators, modules, etc) used in the design, one paragraph or item describing it's purpose, functionality, interface and relevant details.

Short introduction on techniques used to produce the parts (such as 3d printers, milling machines, laser cutting, or others), and a list of the required STL files.

If relevant, source files can also be provided.

If there are no mechanical parts in this design, remove this item.

A description of the software tools required to (when applicable):

1. develop/deploy the design
2. use the device

This section is about the development process. A short introduction on the actual system on a lower level is welcome.

This item describes the wiring and electrical connection of all modules, sensors and n-blocks. It should cover all the physical electrical layer.

This item describes the logic behind any firmware used in the design. Possible strategies are block diagrams, flux diagrams, state machine diagrams, or other methods if relevant to the particular design.

Avoid raw code as main source of information. Source code files should be presented to be downloaded, but should not be the information per se.

Depending on the particular design, this section describes one or more of:

1. How the final device should look like
2. Assembling instructions or diagrams/renders
3. Description of physical deployment or working locations
4. Other physical concerns

Short introduction on how this design is to be or was verified. Verification is to ensure the development was done the right way.

This section can describe a verification process which took place in Nimbus regarding the reference design itself, or it can describe a verification process to be used by developers reproducing this design, even if it was never conducted inside Nimbus.

Description of the test procedures used to verify the design.

Demonstration of test results and corresponding discussion. If this section is proposing a process not yet performed in Nimbus, this item should describe how to interpret the results found by the developers.

Optional section (if applicable) to explain the validation procedure, if any. Validation is to ensure this design is worth doing.

This section can describe a validation process which took place in Nimbus regarding the reference design itself, or it can describe a validation process to be used by developers reproducing this design, even if it was never conducted inside Nimbus.

If validation is not relevant for this design, remove this section entirely.

Description of how this design is to be validated by developers, or how it was validated in Nimbus.

Demonstration of results if internally validated, discussion on possible results if to be assessed by developers.