Wii controller notes: Difference between revisions

From Helpful
Jump to navigation Jump to search
mNo edit summary
 
Line 1: Line 1:
{{#addbodyclass:tag_tech}}
{{stub}}
{{stub}}



Latest revision as of 23:23, 21 April 2024

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Some technical notes

On updates

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The controller can be configured to (at least?)

  • send state continuously
  • only sends you updates when things change

Notify-only-of-changes may sound obvious for buttons and such (though it does mean they won't repeat(verify)}}), but note that it also applies to acceleration, which means that if you put the wiimote still on a table, it will send acceleration updates irregularly or not at all.

It means that if you want to use recent history, you'll have to add timestamps as you can't count on the intervals being regular.

If the interaction (library) you have blocks waiting on new messages, you'll want that in a separate thread updating that state, or use the continuous mode, so that a main loop can't be blocked by wiimote inactivity.

On acceleration

The ADXL330 sensor has a range of +/-3G. The value you see for each dimenstion is a byte, centered at approximately 0x80, and these center (no-force) coordinates are not always in the same spot for each dimension, nor between remotes (also meaning there is not always equal space on both sides to report as much force on both sides of that center.).

You can however ask the remote for its zero-force calibration, which is stored in its EEPROM. You can ask for this to calculate values against that calibrated center.

On IR and the sensor bar

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The sensor bar only contains some infrared LEDs. It's the wiimote that senses the bar.


The Wii's sensor bar is ~20cm long, and has five IR LEDs at each side (the furthest pointed slightly inwards). Because of the distance, each cluster is seen as a fairly consistent single spot by the wiimote processing. The cluster, and the LED intensity, means the remote can see it up to about 5 meters - varying with environment light. People with the sun in the window have probably noticed misbehaviour.


The wiimote has a 128x96 monochrome camera (~33 degree horizontal and ~23 degree vertical field of view), with an IR-pass filter in front of it that seems to pass through 940nm infrared best. The sensor does all the image processing work and just reports (up to four) points, and has subpixel analysis which lets it report in a ~1024x768 coordinate resolution.

It will try to keep the same tracked points in the same report slots, but don't count on this for anything that has to work smoothly. When there are more than four detectable things, the slot consistency disappears anyway.

The remote can be configured to report

  • X,Y coordinates
  • X,Y coordinates, size
  • X,Y coordinates, size, subpixel bounding box

(The sensitivity can be set. High is probably better for coordinate resolution; lower settings will make the resolution approach the sensor's actual 128x96 resolution)(verify)

Under the assumption that two spots you see are the sensor bar - meaning you know the real distance between them (~20cm) - you can calculate how far you are from it.

You can add further assumptions.



See also



Bluetooth and library notes

Libraries

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Incomplete list:

  • wiiuse (C, win/lin)
    • Wiiuse Perl (wrapper)
  • wiiuseJ (java, win/lin)
  • CWiid (lin) (wrappers: python)
  • WiiYourself (C++, win)
  • Brian Peek's Managed Library for Nintendo's Wiimote [1]
  • WiiRemoteJ (java)
  • motej (java)


See also:

On synchronization

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

With the Wii console:

  • Standard Mode Synchronization
    • A remote stays paired with the console until you synch it with another console
    • Done via the synch buttons inside the console and inside the remote
    • (Can power off the console)
    • fixed player number (verify)}
  • One Time mode
    • Use a remote on a console for this powerup only
    • Doesn't clear/overwrite the pairing stored in the remote.
    • (Cannot power off the console)
    • connection order settles player number (verify)}

With PCs:

  • The PIN is the remote's MAC in binary instead of text(verify), which various bluetooth stacks may not even allow you to send, or may not allow via a basic library/API.(verify)


Bluetooth stacks also differ in how they can find remotes. For example, the linux stack can accept any that it sees, while the way windows deals with Bluetooth means you have to add it first.(verify)

See also

Perhaps:

Some usage notes

wminput