Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Carsten Frigaard

Pages: 1
Well, the trees does not grow into heaven: I encountered a problem regarding my solution in the previous post. One some PC's the pairing seems to be successful, but it is not persistent. This means that the PC and wiimote looses connection abilities again.

The reason for this behavior may be found in the Microsoft BT API, and I am currently investigating the issue. This also means, that the demo software may or may-not be able to create a permanent connection....please post you result here, if you try it out!


There have been a lot of activity regarding the permanent synchronization between a Windows PC and a wiimote. I made some test, and finally found a working solution!!!

Please see the "README_FIRST" text below, or just goto

to get the source files and binaries for a Windows XP PC. The code is able to permanently pair a wiimote and a PC. After a registration you only need to press "1-2" on the wiimote to reestablish the connection. It even stays connectable even after a PC shutdown/restart.

The code is still in demo phase, specifically I just encountered a problem, when there are more BT radio in close vicinity of the wiimote.

And if anyone know how to check for an established connection (like the one you see in the BT device list gui: "Connection established")  programatically, then I am all ears!!

Any comments or test results are naturally welcome...


README_FIRST text  (from the zip file):

Copyright © 2008 MergeIt, Aps.
License GPLv3+: GNU GPL version 3 or later <http:\/\/>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Permission to use, copy, modify, and distribute this software
and its documentation for any purpose and without fee is hereby granted, provided that
the above copyright notice appear in all copies and that both that copyright notice
and this permission notice appear in supporting documentation.

   a connection utility for wii console remotes - this version is rewritten to
   encompass permanent pairing of a wiimote and a Windows PC.

   1.0 demo, (note that the source is not "cleaned" up yet)

   Just run bin/Release/wiiscantray.

   Right-click on the trayicon to see menu; use register to pair a wiimote;
   use unregister to remove the pairing.

   Be sure to unregister all wiimotes, before doing a fresh paring.

   IMPORTANT: Modify the address in the Release/wiiscan.ini file to make the
   connection more robust: replace the line "allowed_wiimote_adr=00:00:00:00:00:00"
   with your specific address, like "allowed_wiimote_adr=00:22:D7:94:13:2B".

   The paring between a wiimote and a PC consist of:
      1: Hard-syncing the wiimote, to get it to know the PC bluetooth address.
      2: Establish a paring-key between the wiimote and the PC. This is initiated
         on the PC side, using the bluetooth adapters MAC address as key. The
         PC BT radio key could be something like "00:50:B6:A0:48:8C", such that
         the paring key gets to be:

            // adr of btadapter
            WCHAR pass[6];

         in c-code, and what is then needed is a simple call to the authentication
         procedure, like

            DWORD r=BluetoothAuthenticateDevice(0,hRadio,&bdi,pass,6);

         The problem of entering some hex values in a GUI paring window, is hence
         solved by programmatic doing the same thing. BT address entries of the
         form ":00:" is also only (and always) encountered in the end of the address.
         Notice also that the BT MAC address is read from the right to the left, that
         is from least-significant-byte to most-significant-byte (this explains some
         of the confusion regarding "reversing the MAC address byte order").
      3:   Once a pairing have been established, it persist! Check the pairing status
         by looking into the Bluetooth device properties.
      4:   Powering the wiimote down and up; that is pressing the power-button for a
         couple of seconds, and then pressing a soft-sync button, like "1-2",
         immediately reestablish   the connection. No software external software is
         involved in this process, but the wiiscantray will try to continuously
         monitor the connection.

      5:  And, voila...from here you can run all the Whiteboard software.

   Once paired, the wiimote and PC keeps the pairing information, and it as such
   persist through both a PC shutdown/restart and wiimote power-down (press the
   wiimote power button for a couple of second) and soft-resync, that is a "1-2"
   keypress or   likewise.

   A peculiarity in the pairing process, is that it only seems to work stable after
   a long period, say a minute. Hence the software wait a long time, such that the
   connection is stable. This may be attributed to some unknown "Windows-features",
   but the long wait is only necessary at a hard-sync, so its really a minor
   problem. This problem may be attributed to the BT caching mechanism in Windows.

   Do not hard-sync the wiimote after a successful pairing.

   Old pairing to other computers are lost, as they should be, when paring the
   wiimote   with a new computer.

   Two PC in close vicinity, with unique wiimote pairing, do not interfere with
   each other.   They pair individual to their respective wiimote, as expected.
   The hard-sync registering phase, may however require a setup of a single online
   PC and wiimote only (not tested).

   A severe problem, is however, that the wiimotemay try connect with the BT
   address, of the lowest order. A current observed defect is that an otherwise
   perfect paired wiimote and PC may not be able to reestablish the connection if
   another, secondary BT adapter is switch on.   The problem needs to be futher investegated.
   The wiiscantray continuously polls the BT connection, using the MS Bluetooth API,
   but this may sometimes cause interference with the pairing. A better solution is
   on its way. You can exit the wiiscantray software immediately after a successful
   pairing, if you experience problems.

   .NET framework 3.5
   Windows XP or above.
   Microsoft Bluetooth stack.
   Bluetooth radio compatible with the wii-remote.

   If you are running a non-Microsoft Bluetooth stack (like Widcomm),
   you must follow the procedure found in the document doc/CHANGEINGBTSTACK.rtf

   The software was tested under these three setups:
      1: Lenovo Thinkpad R500
         XP professional, version 2002, SP2
         Trendnet TBW-102UB bluetoohg dongle (=Broadcom Ultimate Low Cost Bluetooth 2.0+EDR USB), driver 5.1.2535.0
         Microsoft BT stack, driver 5.1.2600.2180

      2: "bambus" PC
         XP professional, SP3
         Trendnet TBW-102UB bluetoohg dongle (=Broadcom Ultimate Low Cost Bluetooth 2.0+EDR USB), driver 5.1.2535.0
         Microsoft BT stack, driver 5.1.2600.5512

      3: eeePC (does not work 100% stable)
         XP Home,version 2002, SP3
         Azware BT252 bluetooth dongle, driver  5.1.2600.5512
         Microsoft BT stack, driver 5.1.2600.5512

      (Not tested yet: "bambus" PC
         Vista Buissnes
         Trendnet TBW-102UB bluetoohg dongle (=Broadcom Ultimate Low Cost Bluetooth 2.0+EDR USB)
         Microsoft BT stack, driver ??

   Not tested: multiple simultaneous wiimote connections to the same computer.

...and the hardware does the following:
   1) powers the wiimote using the PC USB +5V voltage (cuts it to around +2.8V internally).
   2) cycles the power, that is turning it off and on in a sequence aimed to make the wiimote automatically connect.

The powering mode is controlled by the wiiscan software, and can be turned on and off by using the settings found in the inifile: three modes are currently supported:

   a) no hardware mode: press "1-2" youself!
   b) USB hub control: turn on and off the USB hub to control power (a troublesome solution).
   c) dedicated hardware (chip) solution: use a USB IO chip to do the power cycling - easy and robust, but more expensive.

 I currently support Delcom and USBm USB IO devices in the c) mode.


Hi benpaddlejones,

Well, I think you can get a good idea of how it works by looking through the documentation found in the zip file, look under Doc/*

But briefly, the package works like just "another" wiimote connection utility. It  continuously scans for wiimotes, and try to connect if any (known) motes is found.

Secondly it integrates with existing Whiteboard solutions software modules, so that these can automatically be started if a connection is established.

Third, it continuously monitor the health of the connection, restarting a connection attempt if the signal is lost.

Finally, the hardware serves to automatically power the wiimote up and down, so that a connection can be made fully automatic. The hardware is however not needed for "a handheld" solution, just press "sync" or "1-2" to make the connection. But the hardware makes it much easier to use!!

Hope this answered some of  you questions...


Hi benpaddlejones,

Please go ahead and add the stuff to the wiki at wiki ""...


I have updated wiiscan (CLI version) and wiiscantray (GUI version) to version 0.9.

Briefly, the wiiscan is "yet-another-connection" utility to make the bluetooth connection of a wiimote with the PC (running Windows and windows bluetooth stack) a little easier....

New/highlight features are

  • Fully automatic connection to a wiimote (only with hardware support, see below).
  • Semi-automatic connection to wiimotes, by just pressing "1-2" or the sync button.
  • Nice, simple GUI based on a tray icon.
  • Integrates into existing whiteboard software solution, full support for Johnny Lee's whiteboard software.
  • Automatic restart of whiteboard software..

Download the new source at:

Hardware support for fully automatic wiimote connections currently includes three different modes

  • USB hub powercontrol: needs a USB hub that can powerdown/up (like ICH9) and then you need to make an USB 5-to-3 volt power cable
  • Custom build USB board based on a USBm 471 device.
  • Custom build USB board based on a Delcom device.

If you need this hardware support, you can make it from our spec

or contact me if you want to buy a larger batch. Currently we fit the hardware inside the wiimote as seen here

and a detailed view of the electronic, here

This hardware together with a PC and a OH projector forms a complete solution for, say school teacher: a simple-to-use system. You can read more about our "integrated teaching bag" at (in danish)

and our general download page for wiimote stuff is found at (in english)

Carsten Frigaard, Mergeit ApS, Kongsvang Allé 37, DK-8000 Ĺrhus C,

Hi thex,

Or does it "press" the sync button over an usb io card?

Well, I was maybe a little unclear in the post, but what the "device" does is to automatically powering the wiimote on (and off). Yes, this will be like "pressing the sync button" using a software function call, so that the last part of the connection sequence can be made fully automatic.

The wiimote in my setup gets power from the computer USB line and currently I support two methods for autopowering on:

  • USB hub mode (turning the entire PC USB hub system off and on!)
  • using a USB io card for external powerswitching.

The first mode is not so nice, in the sense that all devices on the USB gets powered off and on---this includes the BT dongle, and leads to some Windows Plug-and-Play problems. Hence the need for the second solution.

But I guess you know all about the troublesome MS BT stack and the annoying interference from the MS "Plug-and-Play" system?


Hi benpaddlejones,

Will you intend to support widcomm & bluesoleil too?

Well, it could be interesting to support these stacks to, but I have no plan for it right now.

The MS stack was kind of tricky to get to work, and I had to use some not-so-nice hacks to get it up and running. There are also some nasty defect in the MS stack, that may cause "Blue Screen of Death".

Now, some of the other BT protocols also have serious problems as I can understand, but what is really annoying is the slowness and "non-robustness" of the MS Plug-and-Play system. These problems may be overcome by hacking in the "remembered" BT device info or using the BT pinned address, but I have not done this in the current software.

Whats important right now in my software is a robust working system---that do not need to be that fast!

I am working on the details of the hardware auto-power, and will release details late (some weeks from now)....


       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,

Hi thex,

Any change that you will publish the code under an open source license?

If not, we have a peace of hardware that would finalize the automatic connection...see The hardware here is currently in the final test phase, but as the source is open you could easily integrate it you self in you code later...but what I am suggesting is some sort of collaboration.


The wiiscan is "yet-another-connection" utility, that now comes in version 0.8. It enables fully automatic connection, but requires hardware support for doing so. Two modes are supported for this remote automation:

  • USB hub powercontrol: needs a USB hub that can powerdown/up (like ICH9) and then you need to make an USB 5-to-3 volt power cable
  • Use our dedicated hardware solution, base on a USB IO card.

New software features are mainly:

  • more robust, fixed some problems related to the MS bluetooth stack.
  • added a neat tray GUI.
  • added verbose installation guide and man page (as in version 0.71).

Download the new source at:

The hardware solution, that we uses will later be avalible as a free HW specification. Currently we are in the test phase with the HW...feel free to inquire us about the details.

       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,

Hi thex,

I just tested your wiiconnect version 0.5.9, but the problem persist. Even the "standard" windows way of using the bluetooth dialogs gives me the same buggy result, so it not really a problem in our part of the software...its somehow a Microsoft issue!

A good-old reboot did not cure the issure, so it seems that is my XP that is messed up!?

Which connection method are you using?

"learned" is the recomended one, although it doesn't start programms automatically at the moment. It is the most relyable way to connect the wiimotes and also the fastest.

If you are using the "old" way make sure you have checked the "clear wiimotes before connect" option checked.

eehh, how do i check these options? I see no information about "learned" or "old" anywhere?!


Hi Thex,

I've came across an error when trying to (re-) connect to the wiimote. I happens in both my tool (wiiscan v0.7 and yours (Wiimoteconnect, v0.5).

Now, I do not have the source file four your tool, but it seems that I found a "hacky" way of (re-) connect to the wiimote, by firste deleting the wiimote bluetooth HID unit, and reinstalling it.

This methods seems almost fine, but sometimes I hit a Windows message "Found new hardware, [...], Do you want to reboot now" (or something like it) and today I encountered a "Found new hardware" wizard message, that essentially stops the connection tools from working (see screendump below). Obviously we do not have any drivers that needs to be installed for the wiimote HID entry.

Disabling the hardware wizard, or disabling plug and pray do not to be a solution at all, since the HID hardware is not recognized properly.

Have you encountered such problems, and do you have any solutions to it???

My system setup: WinXP prof, MS bluetooth stack, .Net 3.5 SP1.

   Carsten Frigaard,
   Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,

Screen dump of error: see attachement "wiierror.gif"

Bluetooth & Connectivity Knowledge Center / Install procedure ...
« on: January 27, 2009, 03:35:16 AM »
I've compiled an install procedure for the code; it can be rather troublesome when using power-over-USB and automated, unattended remote reset of the wiimote via the internal USB controllers.

Some important issues came up this week

* Only some USB controllers can control power, possible only ICH9 like controllers.
* A MS console application written in C++ is not just a console application; it needs .NET framework 3.5 (at least the debug version). You can overcome this by recompiling yourself or installing .NET 3.5 (see below).
* Different bluetooth stacks need different ways of hacking it with this code (I only support MS stack for now), but
even different versions of the same stack may display different behaviour (I cannot get WIDCOMM 5.5 to work).

Put below is a copy of the INSTALL procedure found in the zip file (version 0.71). I will continue to work on the soft- and hardware so any criticism or questions will be welcome...just mail: carsten AT

   Carsten Frigaard,
   Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,


   Procedure for wiiscan or wiitscanray:


      1: unzip the or file.

      2: download free, but non-redistributable, device console program, devcon.exe, from

      3: unzip and copy devcon.exe (i386/devcon.exe) to path (say copy it into c:\WINDOWS\ directory)

   Testing the exe files

      4: cd wiiscan\release or debug, try to run wiiscan.exe --- if it terminates with an error indicating that it can not run the executable, you will need to recompile the .exe from the source code, or install .NET framework 3.5 SP1. Otherwise goto 8.

      Note: eventhough the executable is a primitive console app it apparently needs a .NET framework! You can install .NET framework 3.5 SP1 or just install the Visual Studio C++ Express compiler (that also installs the needed framework).

   Rebuilding the source code

      5: Install VS express form [version: Microsoft Visual C++ 2008 Express Edition with SP1 - ENU]

      6: Open the wiiscan.sln and rebuild the executables.

      7: Re-try to launch wiiscan.exe (as in 4).

   Finding and testing the +5V power in the USB controllers

      8:  [This step is only needed if you power the wiimote over the USB cable, otherwise put an active_usb_hub="" in the wiiscan.ini file and skip to ]

      Some USB controllers cannot do a powerdown; it seems that ICH7 controllers are not able to cut the power while ICH9 controllers can.

      On an ASUS eee PC the controller version reads

         "Intel(R) 82801G (ICH7 Family) USB Universal Host Controller"
         "Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller"

      On a Lenovo R599 the controller version reads

         "Intel(R) ICH9 Family USB Universal Host Controller"
         "Intel(R) ICH9 Family USB2 Enhanced Host Controller"

      where only the later (ICH9) is usable for the wiimote autopower procedure here. Check our system specification, before proceeding.

      9: Find the id of the USB hubs on the system, open "Control panel | System | Hardware |  Device management" and look for USB-controllers. Open the USB-controller tap and write down the address of all the USB Universal host controllers, and USB2 Enhanced host controllers.

      The id of the controllers are found by right-clicking on the device, selecting "Properties | Details"

      On my eee PC I have four Intel controllers


      and one USB2 controller

      Try to manually disable all the controllers bu

         >  devcon status "@PCI\VEN_8086&DEV_27C8&SUBSYS_830F1043&REV_02\3&11583659&0&E8"

      or, if possible, you could use a pattern match to select all the devices...for my particular system the following expression works
         > devcon status "@PCI\VEN_8086&DEV_27C*&SUBSYS_830F1043&REV_02\3&11583659&0&E*"

      Then diable all devices

         > devcon disable "@PCI\VEN_8086&DEV_27C*&SUBSYS_830F1043&REV_02\3&11583659&0&E*"
      and check the result in the windows device manager (or manually disable all the USB controllers here)

      Finally, pick an active controller and put its address into the wiiscan.ini file, for my particular setup the file then reads

         % Configfile_begin
         % config file for wiiscan
         % Configfile_end

      It is not that important to choose a particular USB controller as the active one, important is that power is only cut to the USB when ALL controllers are disabled, and on when just a single controller is enabled.

      Note: the use of other USB devices may be troublesome, when powering the wiimote over USB as here. It is not recommended to use USB devices together with this procedure!!

   Test an automated, unattended connection

      10; Re-run the wiiscan.exe in a console. If it still fails try to give it a -v option for verbose output, tune the timing parameters (-b,-t,-u,-w), or mail all the results to me

         carsten AT

      with a copy of the output messages.

   January 27 2009

   Carsten Frigaard,
   Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,

Hi Graham,

Thanks for you reply, as for your questions:

I'm going to play with it to find out more.  A couple of questions:
1) How can I get success/failure return codes from the application?
2) How can I shell to whiteboard software if there is a space in the path name? [\quote]


1) The console application should return zero on success, -1 or something like that on failure. You should be able to get these return code when calling the console app, but I have not specifically tested it.

2) I had the same problem, putting "cites" around the exefile in the .ini file did not help me, so I eventually replaced spaces with underscores in the whiteboard executable ;-)

       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,


I've made yet another wiimote connection utility, that tries to combat some of the dreaded connection problems one faces on a windows pc.

The new tool, 'wiiscan', is aimed at solving the "Ladder Problem", that is the problem of pressing "1-2" on the wiimote at the correct time to get the PC to connect to the mote. Several tools for connecting exist, but I found a way to make the connection automatic and unattended. It works by several no-so-nice hacks into the MS bluetooth API (that is very poorly documented) and by using power over an USB cable (with a proper 5 to 3 volt regulator).

The software problem of connection was solved by always removing the HID entry for a wiimote and then starting from a known state. On my test PC the connection will always fail after one connection attempt. Other PC may not have experienced this strange MS Bluetooth/HID feature, that puts a severe limitation of the usability of the wiimote (I traced through the discussion fora on this site and found evidence of my problem and also of "no-connection problem at all").

Secondly, I've found an way to restart the wiimote remotely, by cycling the power to it, so that the combined solution gives a "Ladder" free fix to the known problems.

You can check out the source code (C++) here...

or read the related documentation below or at...

       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,

wiiscan(1)                                                          wiiscan(1)


       wiiscan - a connection utility for wii console remotes


       wiiscan  <-a  <device> | -c <device> | -d <device> | -r | -s | -usbup |
       -usbdown> [-cf <file>] [-b  <sleep>]  [-t  <sleep>]  [-u  <sleep>]  [-w
       <sleep>] [-wb] [-v]


       wiiscan  is  a  canvas  function for a number of different scanning and
       connection utilities. It can detect build-in bluetooth radios, scan for
       nearby  bluetooth devices, connect to a specific device and remove that
       device again from the hardware.

       The main feature of wiiscan is to automatically connect to a wii remote
       (wiimote).  This  can  be quiet cumbersome on a Windows system, and the
       nesseccary steps for doing a robust, working connection is done by

       Delete wiimote hardware HID bluetooth entry:
               delete old entries of the wiimote in the bluetooth hardware. On
               some  windows system the wiimote is readily detected, after the
               first manually  installation.  Pressing  the  "1-2"  makes  the
               wiimote  discoverable.  On  other systems (including mine), any
               attempt to connect to the wiimote, after one successful or  un-
               successful  connection  attempt, will always fail! Removing the
               HID and wiimote registry entries before the next attempt  cures
               this feature.

       Cycle USB bus:
               the wiimote can be switched automatically to discoverable mode,
               if the power is briefly cut from the device. This can  be  done
               on  a wiimote powered by the USB +5 volt (with a proper voltage
               regulator to bring it under +3 volt). This step hence turns the
               USB  hub  off,  killing  the  power, and turns it on again. The
               "1-2" buttons on the wiimote must be pressed at all times, done
               by say some tape or gaffa!.

       Scan for wiimote:
               now  comes  the  main  part  of  the connection; scanning for a
               wiimote. This includes bringing up the bluetooth radio  device,
               initialize  seek parameters, scanning and matching for a device
               name or address, connecting to a matched device, installing the
               HID interface (that was removed in the first step), and finally
               trying to open the wiimote and reading some data from  it.  All
               steps  involve a time variable, meaning that say installing the
               HID causes some windows registry fiddling, that takes a  rather
               variable amount of time, and the next step is critically depen‐
               dent on the former step to be finished. Hence a number of  tun‐
               able waiting variable is introduced, Important is to being able
               to reach the final connection step before the wiimote goes  out
               of the discoverable mode and automatically turns off.

       A note on USB voltage cycling:
               This  software  solution is able to restart the wiimote in dis‐
               coverable mode automatically. But this require that the wiimote
               is  powered  by a USB cable to the PC and that the "1-2" button
               combination is permanently pressed. Cycling the power  for  the
               wiimote with the "1-2" buttons pressed enables the discoverable
               mode, and the continuously pressing "1-2"  does  not  interfere
               with wiimote operations hereafter.

               So  this  is a non-intrusive fix to the so called "Ladder prob‐
               lem" (

               Power control over USB hubs is dependent on the particular  hub
               devices, and disabling the power may not be possible for a sin‐
               gle USB port only. wiiscan uses a trick of  disabling  all  USB
               hubs and then only enable and disable a singe hub.

               Disabling  all hubs is a precondition to running wiiscan and it
               can be accomblised by either going into "Control Panel | System
               | Hardware | Device manager", and manually disable all USB hubs
               or by using "devcon", say (careful, these commands applies only
               to my system)

                     devcon          disable         "@PCIN_8086&DEV_293*&SUB‐

                     devcon         disable          "@PCIN_8086&DEV_293*&SUB‐

               being  careful that the pattern matches only our USB hubs!. You
               can test this by

                     devcon          status          "@PCIN_8086&DEV_293*&SUB‐

                     devcon          status          "@PCIN_8086&DEV_293*&SUB‐

               A single USB now may be enabled or disabled by

                     devcon disable @PCIN_8086*DEV_2934*SUBSYS_20F017AA*

               again with the particular address for your system as a variable
               you  need  to  lookup.  The  voltage  on the USB bus can now be
               checked    Using    a     voltmeter     (see     details     in

       NOTE:  The configuration file of wiiscan contains the particular system
       dependent USB hub pattern matches.

       NOTE:  be careful of connecting other devices to the USB bus, since the
       power cycle may cause severe interfere with the device.


       -a <device>
               auto-connect to a device.

       -c <device>
               connects to a device.

       -d <device>
               deletes a device, clears HID and bluetooth registry entries.

       -r      looks for active internal bluetooth radio devices.

       -s      scans for external bluetooth devices.

       -usbup  turn the USB hub on.

               turn the USB hub off.

       Default mode: wiiscan -a " Nintendo RVL-CNT-01"

       Note: "nintendo" is a shortcut for "Nintendo RVL-CNT-01"


       -cf <file>
               load a specific configuration file.

       -b <sleep>
               auto-mode bluetooth connection sleep in milliseconds.

       -t <sleep>
               bluetooth scanning interval in milliseconds.

       -u <sleep>
               auto-mode USB connection sleep in milliseconds.

       -w <sleep>
               timeout for wiimote in milliseconds.

       -wb     start whiteboard in auto-mode

       -v      enable extra debugging printouts

       wiiscan looks for a file names wiiscan.ini when executing in the automode. The ini
       file looks like

       % Configfile_begin % config file for wiiscan
          whiteboard_software="d:/WiimoteWhiteboard/WiimoteWhiteboard_v0.3.exe" % Config‐

       with the following entries

               currently not used.

               hub to enable and disable in power-switching mode. Note that all other hub
               may also be required to be turned of for the power cycling  to  work.  The
               USB power cycle will not be performed if active_usb_hub="".

               a list of allowed wiimote adresss. The adresss "00:00:00:00:00:00" matches

               a path to whiteboard software to launch  if  the  "-wb"  option  has  been


       Scanning for devices nearby:

            wiiscan -s

       Auto-connect  to  a  nintendo  device, scan bluetooth for four seconds,
       verbose on, and enable start of whiteboard software after a  successful

            wiiscan -a nintendo -t 4000 -v -wb

       Cycle USB bus voltage

            wiiscan -usbdown

            wiiscan -usbup


       The   source   code   can  be  compiled  with  MS  Visual  C++  Express
       ( or similar. It also  needs  wiiuse
       dlls  ( If wiiuse is to be compiled by it self it
       needs Windows SDK and DDK, but running wiiscan  with  just  the  wiiuse
       binaries is the easiest option.

       It does not work on Windows 2000, and has not been tried out on a Vista


       The wiiscan has been tested on a Lenovo Thinkpad R500, XP system (with‐
       out  build-in  bluetooth)  with  a Trendnet TBW-102UB bluetooth dongle.
       Test on a Asus eee is coming up soon.

       Only the MS bluetooth stack was tested.

       A burn-in test of auto-connect over approx. 3 days gives


          Started Fri Jan 9 16:16:39 2009
          Stopped Man Jan 12 09:XX:XX 2009

          Duration: 8+24+24+9=65 hours= approx 2.7 days


             6: Wiimote failed to find devices 189/6431 * 100 =2.9 %
             7: Failed to remove device 54/6431 * 100 =0.82 %
             4: Could not find radio device 53/6431 * 100 =0.82 %

          Non-fatals: case 1+2 = (189+54)/6431 * 100 = 3.8 %
          Fatal: case 3 = 0.82 %

       Second burn-in test: keep connection alive. When first established, the
       connection seems to be maintained over many hours and days.

       Known defects:

       1: restart pop-up (OPEN)
               Installing new hardware causes windows to require restart. Hap‐
               pens once in a while, balloon pop-ups  reports  hardware,  that
               where  installed  but  not  working  properly. A restart pop-up
               wants to reboot the PC. Small fix: just delete the  device  and
               re-run "wiiscan -c nintendo".

       2: discoverable mode fast shutdown (OPEN)
               Sometimes the wiimote goes quickly out of discoverable mode, it
               takes it only about 3 seconds from turn-on  to  turn-off.  This
               makes  it  hard  to obtain a connection to it. Both my wiimotes
               does this once in a while, after failed connection attempts.

               Pressing one button only "1" or "2" makes the wiimote blink for
               a short time, but it is not really discoverable.

       3: buttons not working (OPEN)
               Pressing  the 1-2 button combination sometimes fails to turn-on
               the wiimote, pressing sync or power makes it  work  again.  The
               the  "1-2  button  freeze"  happens  after  a failed connection
               attempt. See also bug-2.

       4: radio null (OPEN)
               Sometimes the BT  radio  fails  to  reinitialize  after  a  USB
               down/up     flip,     this    means    that    "RadioInfo(time‐
               out,true,dbg)"return NULL. Can be fixed by  placing  the  blue‐
               tooth radio device on another bus than the USB.

       5: keep blinking (OPEN)
               Sometimes  the  wiimote is found and connected OK, but the LEDs
               keeps blinking (normal connect mode:  LEDs  are  turned  perma‐
               nently  on).  This  does however not affect connectability, and
               the wiimote does not turn off again automatically.

       6: failed to find wiimote (OPEN)
               Wiimote failed to find devices. This may be a  non-fatal  error
               or   an   error   caused   by   an   undervolted  wiimote.  The
               "wiiuse_find(0x0,4,2/4/6)" keeps returning 0.

       7: remove failed (OPEN)
               Sometimes the remove steps fails, but this may be non-fatal

                Removing device <Nintendo RVL-CNT-01>
                ** error: failed to find device
                Done [FAILED]

       8; balloon-tips (FIXED)
               Balloon-tips are annoying when connecting new  hardware.  Small
               fix: do

                Windows Registry Editor Version 5.00


       9: double delete (FIXED)
               Double delete of nintendo device may cause  BluetoothFindFirst‐
               Device()  to return null Fixed by removing the throw, replacing
               it with a "if (hbf()==NULL) then return false"

       10: BSoD
               The "Blue Screen of Death" was encountered a number  of  times,
               indicating  a errorneous device driver. The cause may be in the
               MS bluetooth stack or  in  the  wiiuse  lib.  The  BSoD  mainly
               occured  in  the  first  phase of this project and haven't been
               seen for a while with the current version (v0.7).


               Wiiuse is a library written in C  that  connects  with  several
               Nintendo  Wii  remotes.  Supports  motion sensing, IR tracking,
               nunchuk, classic controller, and the Guitar Hero 3  controller.
               Single  threaded and nonblocking makes a light weight and clean

               Licensed under GNU GPLv3 and  GNU  LGPLv3  (non-commercial)  by
               Michael Laforest,


       Wiimote Whiteboard(?)
               Whiteboard software by Johnny Chung Lee.



               USB management software.



       Version 0.7 NDEBUG


       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,


       Copyright  © 2009 MergeIt, Aps. License LGPL3 : GNU lesser GPL, version
       3, <>. This is free software: you are
       free to change and redistribute it. There is NO WARRANTY, to the extent
       permitted by law.

wiiscan(1)                                  13 Jan 2009                       wiiscan(1)

Pages: 1