darwiin-remote-developers

[DarwiinRemote-dev] not getting any events from Wii controller

[Samer A. <sam...@el...>]

Hi,
I just posted this question on Hiroaki's DarwiinRemote blog but then I
found this mailing list and figured it would be better to ask it  
here, so..

I'm getting to grips with using the WiiRemote framework and I'm
getting some weird behaviour, or rather lack of behaviour. I can  
discover
the controller successfully, connect to it, and even send commands to
it, eg switching the LEDs on and off, so clearly a lot is working  
properly.
However, even after I enable the motion sensors, I'm not getting any
accelerationChanged calls to my Wii delegate. In fact, there is no data
coming from the L2CAP channels whatsoever - l2capChannelData is
not being called at any time - so I'm not getting any status  
information,
battery levels etc. I've compared my code with that in DarwiinRemote's
AppController.m and it looks as if I'm doing everything properly, but  
still
no events coming back.

There isn't much code and the relevant bits are below. The only thing
I can think of (because I'm new to OS X system programming and
don't know much about the execution model) is that the problem is
something to with with the fact that my program is a command line
utilities with just one thread of execution, rather than graphical
application. It couldn't be that, could it?

Anyway, I'm at my wit's end so I hope it's some stupid obvious error
that I've made. I have another question about failures during
discovery/initialisation but I'll save it for another email.

cheers,
Samer


=========================================
@implementation WiiTool

- (void) startDiscovery:(int)timeout {
    disc = [WiiRemoteDiscovery discoveryWithDelegate: self];

    printf("starting inquiry...\n");
    [disc start];
    printf("inquiry in progress...\n");
    sleep(timeout);
    printf("stopping inquiry\n");
    [disc stop];
    printf("inquiry stopped\n");
}

// WiiRemoteDiscoveryDelegate interface
- (void) WiiRemoteDiscovered:(WiiRemote*)wii_ {
    wii=wii_;

    printf("*** wii %p discovered!\n",wii);
    [wii setDelegate: self];
    [wii setMotionSensorEnabled: YES];
    [disc stop];

    printf("*** address is %s\n",[[wii address] UTF8String]);
    printf("*** battery level is %lf\n",[wii batteryLevel]);
}

- (void) accelerationChanged:(WiiAccelerationSensorType)type
          accX:(unsigned char)accX
          accY:(unsigned char)accY
          accZ:(unsigned char)accZ
          wiiRemote:(WiiRemote*)wiiRemote {
    printf("acceleration changed\n");
}

@end
=============================================

Re: [DarwiinRemote-dev] not getting any events from Wii controller

[Samer A. <sam...@el...>]

Right, well I've sort of partially answered my own question. It seems
that the delivery of data to the l2cap channel callback is handled
as part of the NSApplication  event loop, so when I re-implemented
my program as GUI Cocoa application it worked.

However, I also got it to work as part a command line application
by explicitly passing control over to the event loop after doing all
the initialisation - the main function looks more or less like this:

int main (int argc, const char * argv[]) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    NSApplication     *app  = [NSApplication sharedApplication];
    WiiTool           *wiitool=[[WiiTool alloc] init];

    [wiitool startDiscovery];
    [NSApp run]; // pass control to event-handling loop

    // never gets here! don't know how to terminate main loop  
gracefully.
    [wiitool disconnect];
    [wiitool release];
    [pool release];
    return 0;
}

This is compiled as a command line application with no Nib files,
no windows, no menu, no GUI, no application bundle. (I imagine though,
that [NSApplication sharedApplication] will only succeed if the  
window server
is running and accessible to the current user.)

The only thing I haven't figured out yet is to get the main loop to  
terminate
gracefully. Maybe I should just write a signal handler to trap SIGINT
and clean up there?


samer.



On 25 Oct 2007, at 21:25, Samer Abdallah wrote:

> Hi,
> I just posted this question on Hiroaki's DarwiinRemote blog but then I
> found this mailing list and figured it would be better to ask it
> here, so..
>
> I'm getting to grips with using the WiiRemote framework and I'm
> getting some weird behaviour, or rather lack of behaviour. I can
> discover
> the controller successfully, connect to it, and even send commands to
> it, eg switching the LEDs on and off, so clearly a lot is working
> properly.
> However, even after I enable the motion sensors, I'm not getting any
> accelerationChanged calls to my Wii delegate. In fact, there is no  
> data
> coming from the L2CAP channels whatsoever - l2capChannelData is
> not being called at any time - so I'm not getting any status
> information,
> battery levels etc. I've compared my code with that in DarwiinRemote's
> AppController.m and it looks as if I'm doing everything properly, but
> still
> no events coming back.
>
> There isn't much code and the relevant bits are below. The only thing
> I can think of (because I'm new to OS X system programming and
> don't know much about the execution model) is that the problem is
> something to with with the fact that my program is a command line
> utilities with just one thread of execution, rather than graphical
> application. It couldn't be that, could it?
>
> Anyway, I'm at my wit's end so I hope it's some stupid obvious error
> that I've made. I have another question about failures during
> discovery/initialisation but I'll save it for another email.
>
> cheers,
> Samer
>
>
> =========================================
> @implementation WiiTool
>
> - (void) startDiscovery:(int)timeout {
>     disc = [WiiRemoteDiscovery discoveryWithDelegate: self];
>
>     printf("starting inquiry...\n");
>     [disc start];
>     printf("inquiry in progress...\n");
>     sleep(timeout);
>     printf("stopping inquiry\n");
>     [disc stop];
>     printf("inquiry stopped\n");
> }
>
> // WiiRemoteDiscoveryDelegate interface
> - (void) WiiRemoteDiscovered:(WiiRemote*)wii_ {
>     wii=wii_;
>
>     printf("*** wii %p discovered!\n",wii);
>     [wii setDelegate: self];
>     [wii setMotionSensorEnabled: YES];
>     [disc stop];
>
>     printf("*** address is %s\n",[[wii address] UTF8String]);
>     printf("*** battery level is %lf\n",[wii batteryLevel]);
> }
>
> - (void) accelerationChanged:(WiiAccelerationSensorType)type
>           accX:(unsigned char)accX
>           accY:(unsigned char)accY
>           accZ:(unsigned char)accZ
>           wiiRemote:(WiiRemote*)wiiRemote {
>     printf("acceleration changed\n");
> }
>
> @end
> =============================================
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Darwiin-remote-developers mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/darwiin-remote-developers

[DarwiinRemote-dev] Discovery/connection problem

[Samer A. <sam...@el...>]

Hi,
This is a question about a failure which happens during the
call to WiiRemote:connectTo while doing device discovery. I
am seeing fairly consistent behaviour depending on whether
or not the Wii device is listed in the Bluetooth preference pane
in System Preferences (on the 'Device' tab). If the device is
*not* listed, then a subsequent discovery/connection works
perfectly, almost every time.

If the Wii *is* listed on the preference pane, as connected or
disconnected, the the WiiRemoteDiscovery thing works fine
up until the point inside WiiRemote:connectTo where the
code attempts to switch off the LEDs. At this point I get
an IOReturn error code. I put some logging statements in
the code and I get the following:

16:55:59.102 wiicat[6024] WiiRemoteDiscovery> Checking device  
Nintendo RVL-CNT-01
16:55:59.103 wiicat[6024] WiiRemote> Trying to connect to 0x56e7f0
16:55:59.468 wiicat[6024] WiiRemote> Connection open
16:55:59.500 wiicat[6024] WiiRemote> SDP query completed
16:55:59.614 wiicat[6024] WiiRemote> Channels open
16:55:59.635 wiicat[6024] !!! IOReturn for command 17 = 0xE00002C1
16:55:59.645 wiicat[6024] !!! IOReturn for command 17 = 0x10000003
<repeats>
16:55:59.731 wiicat[6024] !!! IOReturn for command 17 = 0x10000003
16:55:59.731 wiicat[6024] WiiRemote> !!! Failed to switch of LEDs

As you can see, the l2cap channels are opened successfully, but
the LED changing command fails with E00002C1 and subsequent
retries fail with 10000003.

Jasen suggested I look at the Bluetooth packet logs, but before I
submit myself to that, I was wondering if anyone is having a similar
problem, or conversly, if people are generally able to connect to
a previously seen Wii without removing from the devices list.

cheers,
Samer.

Re: [DarwiinRemote-dev] Discovery/connection problem

[Josh W. <sin...@fu...>]

Samer Abdallah wrote:
> Jasen suggested I look at the Bluetooth packet logs, but before I
> submit myself to that, I was wondering if anyone is having a similar
> problem, or conversly, if people are generally able to connect to
> a previously seen Wii without removing from the devices list.

I see very similar behavior. I tried to debug this myself, but given
that my knowledge of Bluetooth and the Wii Remote are both nearly nil, I
got nowhere. It seems to be a pretty universal issue from what I've heard=
=2E

--=20
--------------------------------------------------
I've said it before, and I'll say it again: Copyright and patent laws
suck. I swear, if they're going to have IP laws like this, they should
teach us NOT to share in Kindergarten.
  -- gid13
--------------------------------------------------

I nearly always cryptographically sign my emails (PGP/gpg)... if it
isn't signed, it's probably not from me! If you have the capability,
please encrypt responses.

Re: [DarwiinRemote-dev] Discovery/connection problem

[Samer A. <sam...@el...>]

I've been staring at packet logs all day - I don't recommend it.
I do have a vague diagnosis of the connection problem though.

The sequence of events when you call WiiRemote:connectTo is
first to open an L2CAP channel with PSM 0x13 (the channel for
receiving events from the Wii) and then another on PSM 0x11
(for sending commands to the Wii). You can see the various
stages of this process in the packet log.

However, after the two channels are successfully opened,
something within the system initiates *another* request to open
a channel with PSM 0x13. The Wii returns an error because 0x13
is already open and apparently it can't be opened more than once.
Immediately after this, the packet log shows a request to disconnect
PSM 0x11 coming from the computer. By the time the WiiRemote code tries
to switch off the LEDs, the control connection is closed and
the sendCommand fails.

So, I tried commenting out the code that opens PSM 0x13 to
see what would happen. It turns out some mysterious entity
still tries to open PSM 0x13, and this time it succeeds, because
WiiRemote hasn't opened it already. But the disconnection
request still appears immediately afterwards (this time for both
channels), so WiiRemote: connectTo still fails when it tries to
switch off the LEDs.

I don't really know what to make of this - it appears that some
part of the OS X bluetooth system interferes with the connection
process by opening and closing connections to the Wii while
we are trying to connect, but it only does this if the Wii is
in the previously connected-to device list. Perhaps the system
is trying to update the information displayed by the bluetooth
GUI?


- Samer.



On 28 Oct 2007, at 17:14, Samer Abdallah wrote:

> Hi,
> This is a question about a failure which happens during the
> call to WiiRemote:connectTo while doing device discovery. I
> am seeing fairly consistent behaviour depending on whether
> or not the Wii device is listed in the Bluetooth preference pane
> in System Preferences (on the 'Device' tab). If the device is
> *not* listed, then a subsequent discovery/connection works
> perfectly, almost every time.
>
> If the Wii *is* listed on the preference pane, as connected or
> disconnected, the the WiiRemoteDiscovery thing works fine
> up until the point inside WiiRemote:connectTo where the
> code attempts to switch off the LEDs. At this point I get
> an IOReturn error code. I put some logging statements in
> the code and I get the following:
>
> 16:55:59.102 wiicat[6024] WiiRemoteDiscovery> Checking device
> Nintendo RVL-CNT-01
> 16:55:59.103 wiicat[6024] WiiRemote> Trying to connect to 0x56e7f0
> 16:55:59.468 wiicat[6024] WiiRemote> Connection open
> 16:55:59.500 wiicat[6024] WiiRemote> SDP query completed
> 16:55:59.614 wiicat[6024] WiiRemote> Channels open
> 16:55:59.635 wiicat[6024] !!! IOReturn for command 17 = 0xE00002C1
> 16:55:59.645 wiicat[6024] !!! IOReturn for command 17 = 0x10000003
> <repeats>
> 16:55:59.731 wiicat[6024] !!! IOReturn for command 17 = 0x10000003
> 16:55:59.731 wiicat[6024] WiiRemote> !!! Failed to switch of LEDs
>
> As you can see, the l2cap channels are opened successfully, but
> the LED changing command fails with E00002C1 and subsequent
> retries fail with 10000003.
>
> Jasen suggested I look at the Bluetooth packet logs, but before I
> submit myself to that, I was wondering if anyone is having a similar
> problem, or conversly, if people are generally able to connect to
> a previously seen Wii without removing from the devices list.
>
> cheers,
> Samer.
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Darwiin-remote-developers mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/darwiin-remote-developers

Re: [DarwiinRemote-dev] Discovery/connection problem

[Jasen J. <ja...@gm...>]

Good troubleshooting.  You've discovered the exact problem we found
back in the beginning of this year.

We even contacted Apple's Bluetooth dev list and it was confirmed by
Apple that there is a bug related to the discovery sequence.  I guess
I/we should add something to the DarwiinRemote site listing this bug.

I'm hoping that this problem is fixed in 10.5 and/or an update to 10.4.

- Jasen.

On Oct 30, 2007 9:39 PM, Samer Abdallah <sam...@el...> wrote:
> I've been staring at packet logs all day - I don't recommend it.
> I do have a vague diagnosis of the connection problem though.