Author Topic: Wiiscan - another wiimote connect utility with power control  (Read 16951 times)

Offline Carsten Frigaard

  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Hello,

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...

      http://mergeit.dk/uploads/media/wiiscan-0.7_04.zip

or read the related documentation below or at...

       http://mergeit.dk/de/open-it/projekter/egne/wii.html

Enjoy
       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,
       www.mergit.dk



wiiscan(1)                                                          wiiscan(1)

NAME

       wiiscan - a connection utility for wii console remotes


SYNOPSIS

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

OVERVIEW

       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" (http:wyxs.net/web/wiimote/digital_whiteboard.html).

               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‐
               SYS_20F117AA&REV_033&B1BfB6*"

                     devcon         disable          "@PCIN_8086&DEV_293*&SUB‐
               SYS_20F017AA&REV_033&B1BfB6*"

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

                     devcon          status          "@PCIN_8086&DEV_293*&SUB‐
               SYS_20F117AA&REV_033&B1BfB6*"

                     devcon          status          "@PCIN_8086&DEV_293*&SUB‐
               SYS_20F017AA&REV_033&B1BfB6*"

               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
               http:wyxs.net/web/wiimote/digital_whiteboard.html).

       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.

DESCRIPTION

       -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.

       -usbdown
               turn the USB hub off.

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

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

OPTIONS

       -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
FILES

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

       % Configfile_begin % config file for wiiscan
          all_usb_hubs="@PCIN_8086&DEV_293*&SUBSYS_20F017AA&REV_033&B1BfB6*"
       "@PCIN_8086&DEV_293*&SUBSYS_20F117AA&REV_033&B1BfB6*"
          active_usb_hub="@PCIN_8086&DEV_2934&SUBSYS_20F017AA&REV_033&B1BFB68&0&E8"
          allowed_wiimote_adr=00:00:00:00:00:00
          whiteboard_software="d:/WiimoteWhiteboard/WiimoteWhiteboard_v0.3.exe" % Config‐
       file_end

       with the following entries


       all_usb_hubs
               currently not used.


       active_usb_hub
               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="".


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


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

EXAMPLE

       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
       connection

            wiiscan -a nintendo -t 4000 -v -wb

       Cycle USB bus voltage

            wiiscan -usbdown

            wiiscan -usbup

COMPILING

       The   source   code   can  be  compiled  with  MS  Visual  C++  Express
       (http:www.Microsoft.com/express/vc/) or similar. It also  needs  wiiuse
       dlls  (http:www.wiiuse.net/). 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
       system.

BUGS

       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

          VERSION: 0.6 NDEBUG 32BIT LITENDIAN

          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

          Errors:

             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

                [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVer‐
               sion\Explorer1]
                "EnableBalloonTips"=dword:00000000

       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).

SEE ALSO

       wiiuse(?)
               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
               API.

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

               (http:www.wiiuse.net/)


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

               (http:www.cs.cmu.edu/~johnny/projects/wii/,
               http:www.wiimoteproject.com/)

       devcon(1)

               USB management software.

               (http:support.Microsoft.com/kb/311272)


VERSION

       Version 0.7 NDEBUG

AUTHOR

       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,
       www.mergit.dk

COPYRIGHT

       Copyright  © 2009 MergeIt, Aps. License LGPL3 : GNU lesser GPL, version
       3, <http:www.gnu.org/licenses/lgpl.txt>. 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)




Offline gmacleod

  • *
  • Posts: 5
  • Karma: +1/-0
    • View Profile
    • starteractivity.com
Reply #1 on: January 18, 2009, 07:12:36 PM
This is a very impressive little piece of code.  You are right, it could solve most of the real problems that make the wii solution impractical at the moment.

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? 

Reasons are:

1) Not speaking C++ I was planning to shell to your program from Visual Basic (yes I know).  I can do this fine, but I can't then tell if the connection was successful or not.  I just see the program terminate but I don't know what happened.  Is there any way of knowing - for example looking for a particular process that will only be present if the result was successful - or a flag file (that would be nice and easy ;-)

2) I'm trying to run some whiteboard software which is located in the c:\program files\... folder.  I've put the full path in the .ini file, but it can't get beyond the space after 'program' and therefore can't find the files.

This is a small problem, I can always move the software somewhere else if it presents a difficulty, but thought I'd ask.

Thank you very much indeed for this utility.  I'm going to try and get some interest going in it.
Graham



Offline Carsten Frigaard

  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Reply #2 on: January 19, 2009, 02:46:24 AM
Hi Graham,

Thanks for you reply, as for your questions:

Quote
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]

then:

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 ;-)

Regards
       Carsten Frigaard, Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C,
       www.mergit.dk



Offline Carsten Frigaard

  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Reply #3 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 mergeit.dk

Enjoy
   Carsten Frigaard,
   Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C, www.mergit.dk


INSTALLATION

   Procedure for wiiscan or wiitscanray:

   Prerequisites

      1: unzip the wiiscan-X.X.zip or wiiscantrayX.X.zip file.

      2: download free, but non-redistributable, device console program, devcon.exe, from http:support.microsoft.com/kb/311272

      3: unzip devcon.zip 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 http://www.microsoft.com/express/vc/ [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

         PCI\VEN_8086&DEV_27C8&SUBSYS_830F1043&REV_02\3&11583659&0&E8
         PCI\VEN_8086&DEV_27C9&SUBSYS_830F1043&REV_02\3&11583659&0&E9
         PCI\VEN_8086&DEV_27CA&SUBSYS_830F1043&REV_02\3&11583659&0&EA
         PCI\VEN_8086&DEV_27CB&SUBSYS_830F1043&REV_02\3&11583659&0&EB

      and one USB2 controller

         PCI\VEN_8086&DEV_27CC&SUBSYS_830F1043&REV_02\3&11583659&0&EF
      
      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
            all_usb_hubs="@PCI\VEN_8086&DEV_27C*&SUBSYS_830F1043&REV_02\3&11583659&0&E*"
            active_usb_hub="@PCI\VEN_8086&DEV_27C8&SUBSYS_830F1043&REV_02\3&11583659&0&E8"
            allowed_wiimote_adr=00:00:00:00:00:00
            whiteboard_software="d:/WiimoteWhiteboard/WiimoteWhiteboard_v0.3.exe"
         % 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 mergeit.dk

      with a copy of the output messages.

ENJOY
   January 27 2009

   Carsten Frigaard,
   Mergeit ApS, Kongsvang  Allé  37,  DK-8000  Ĺrhus  C, www.mergit.dk