Operation

Highlights:

• Operating the unit is very straightforward; you turn the power on and wait a few seconds (~10 sec.). Once the initial bootstrap is finished, the unit is ready to send its data to the host PC.
• The tracker control box is fairly noisy. This could be improved.
• Out-of-the-box, positional information was surprisingly accurate, without requiring any position calibration. It was off by about 3 cm in worse cases. In normal use conditions, the user should not have to recalibrate the unit at each power on.

Operating the tracker unit is easy. Simply turn on the main unit and wait a few seconds for the bootstrap sequence to complete (typically under 25 seconds). Once this process is complete, the unit is ready to send 6DOF data to the host computer. The unit does not send data by default. Specific commands must be sent to the tracker unit to tell it to begin sending data or perform other specific functions it supports.

One thing you will note the first time you turn on the main unit is the noise it produces. It is indeed quite noisy compared to today's computers standards. The unit uses a wide range universal power supply than can function with voltages from 90 to 264 Volts, with frequencies ranging from 44 to 440 Hz. The small fan found on that power supply seems to be the main source of that higher than normal noise. Unfortunately, we did not dispose of a decibel meter at the time of this review to take measurements, so it is impossible for us to put a value on the noise level. This is surely an area that can be improved, especially if it is targeted at the home consumer market. Speaking of which, the Wintracker unit passed FCC and CE normalization process. More information on this was not available as to what level of FCC specification the unit passed. For instance, an FCC class B device is certified to function in a domestic home environment without causing RF (radio-frequency) interference levels that would be considered over the accepted limits. Here is a typical label found on FCC class B equipments:

Note: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. [.]

From what we have seen in our tests, the unit seemed to operate fine in a residential-like environment. No notable interference could be observed during our tests.

Out-of-the-box, the 6DOF information that the unit returns was surprisingly accurate, without requiring any position calibration. It was off by about 3 cm in worse cases. In normal operating conditions, the user will not have to recalibrate the unit at each power on. In order to get the maximum from this tracking system, a function is provided with the Wintracker API to recalibrate the coordinate system of the tracker unit. Alternatively, the user can send a recalibrate command to the main unit using the test & control application previously discussed. As you will see in more details in the following sections, the positions returned by the unit are quite acceptable, even without filtering it using calibrated look-up tables. The Wintracker system, like any other such systems, does allow the programmer to add filtering into its program to compensate for potential distortions of the electro-magnetic field. As it is always the case, these filtering operations will add latencies to the overall system. As we will see later on in that review, the main unit itself does implement basic hardware filtering of data to the expense of lower update rates.

During the course of our tests, we noted a small but visible problem with the angles returned by the unit. The unit returns angles in radians, following a range from -pi to +pi (-180 to +180 degrees). The problem we found was occurring in the sign transition region, when the receiver was turned from -179 to +179 degrees. We noted a gap where the unit would never return any values around the -+180 point. This gap, about 0.2 degrees wide, would be sufficient to produce a visual glitch when tracking head rotations for example. We informed the engineers at VR-Space Inc. of the existence of that problem and they were fast to fix it and send us a firmware update.

Interfacing with your C code

Highlights:

• Integrating Wintracker support inside your C/C++ application is as simple as it can get. In a matter of a few minutes, we were able to use 6DOF data coming from the Wintracker unit into our C/C++ VR test programs.
• All that is required is to add an include file (.H) inside your source that will call the Wintracker API. A static library file (.LIB) and a dynamically linked library file (.DLL) are also provided for compilation and run-time operation.
• The "Tracker test & control application" that is provided on the distribution CD-ROM allows the developer to see the raw incoming data for the 3 receivers while running the developer's own application concurrently. This utility even allows the developer to change working parameter of the device on the fly like, for example, switching on or off any of the 3 receivers.

Using the tracker 6DOF data inside your own C/C++ application is very simple. The API provided on the CD-ROM disk consists of an include file (.H) and its static library (.LIB). Using these two files, it is easy to recompile your application and access the various commands that the tracker unit supports. Here is a list of the commands that are included in the API:

• Ask the unit to process a single frame of data (a 6 degree of freedom position).
• Put the unit in continuous output mode: Once in that mode, the unit continuously processes data.
• Stop continuous output mode.
• Read the current 6DOF data from the unit.
• Turn on or off any of the 3 receivers.
• Calibrate positional information.
• Change positional and attitude data filtering parameters.
• Reinitialize the tracker unit.
• Specify the hemisphere of operation: can be the front or upper hemisphere of the emitter.
• Change the emitter mounting frame: This can be used to rotate the coordinate system so that the unit sends coordinates following the user's need. For example, if the emitter is mounted upside-down on a ceiling like in a CAVE(TM) environment, you could use this function to rotate the coordinate system so that positions and angles are aligned with the room floor and positive values going up. Note that using this function, the emitter can be placed following any attitude, at uncommon angles, and still give 6DOF perfectly aligned with the environment of the user.
• Specify a boresight reference: A receiver can be used to define the origin of the unit coordinate system.

At run-time, the application that linked with the provided static library will connect to the dynamically linked library (.DLL) to access and transfer data over the USB cable to the host computer. The DLL library uses its own independent thread to read and store each data frame. This means that the calls to the Wintracker API are not blocking. This is very useful since the programmer does not have to worry about freezing his own application when pooling for new tracker data. Moreover, the host application and the tracker DLL thread run independently, using update rates that may be different. The latest 6DOF data is stored inside the DLL until the main unit processes a new 6DOF data. The user application acts independently, requesting a 6DOF data read to the DLL. The DLL then returns the latest 6DOF data to the application. If the application does not ask for new data, the main unit overwrites it as new 6DOF data becomes available. This means that only the latest tracker data frame is cached. All past data frames are lost if they are not read in time by the host application. We will see in the next sections the actual data update rate performances of the tracker system.