Doc

Data Reporting

When designing your own application for Wiimote, many different approaches can be adopted. Still, it is important to understand what happens under the hood of the Wiimote data reporting mechanism, if you don't want to get in trouble. Here we provide you with some hints and tips about data reporting that we hope will help you. First of all: what is a data report? It is a message that the Wiimote transmits to your host, and it contains useful information about its status and sensors.

Data Reports

Below are listed the available data reports with their identification codes:

  • 0x30 - Core Buttons
  • 0x31 - Core Buttons and Accelerometers
  • 0x32 - Core Buttons and 8 Extension bytes
  • 0x33 - Core Buttons and Accelerometer with 12 IR bytes
  • 0x34 - Core Buttons with 19 Extension bytes
  • 0x35 - Core Buttons and Accelerometer with 16 Extension Bytes
  • 0x36 - Core Buttons with 10 IR bytes and 9 Extension Bytes
  • 0x37 - Core Buttons and Accelerometer with 10 IR bytes and 6 Extension Bytes
  • 0x3d - 21 Extension Bytes
  • 0x3e / 0x3f - Interleaved Core Buttons and Accelerometer with 36 IR bytes

You don't need to remember their codes nor their names, since WiiC provides you with utility functions to enable them, and sometimes they are automatically enabled according to the sensors you are using.

Polling Synchronization

Keep in mind that the Wiimote transmits data reports at a rate of 100Hz, that is every 10 milliseconds. You can call wiic_poll() (C) or CWii::Poll() (C++) to get these reports. Both are non-blocking, hence you will be guaranteed to return, either with new data or not. Using these functions can be quite tricky if you don't consider all the aspects under the hood of this mechanism. Here are some guidelines:

  1. Polling the device at rates higher than 100Hz is useless, and you will probably get multiple copies of the same report.
  2. When designing your application, you should take into account that the higher your polling rate is, the more your CPU will be overloaded. If you experience such a problem, one possible solution is to poll the device at a lower rate (e.g. 20Hz, that is every 50 milliseconds), but...
  3. ... since WiiC does not discard any report, polling at rates lower than 100Hz will cause buffer accumulation! How to avoid this? One possible approach is to empty the queue calling several times wiic_poll() or CWii::Poll() within the same iteration. Thus, instead of:
if(wii.Poll()) {
        // Some stuff
}
try something like this:
while(wii.Poll()) {
        // Some stuff
}

Data Report Processing

Processing every received report can overload the CPU. I would suggest you to discard some reports, but there is one big drawback in this. While discarding new accelerometer data is not so important, the risk is to lose a button trigger! A finer approach is to discard only continuous data measurements (e.g. gyroscopes, accelerometers, and so on), while keep analyzing every report about discrete events (e.g. buttons).

Introduction

Installation

Documentation

edit SideBar

Blix theme adapted by David Gilbert, powered by PmWiki