Writing BT stack to connect with Wiimote - problems connecting

I'm working on a project which intends to connect an embedded microprocessor (the host/master) to a Wiimote. I only have the Bluetooth HCI interface to work with (no L2CAP, HID). I'm able to successfully complete an inquiry returning a Wiimote BD_ADDR (and other information). I am in effect compressing the L2CAP and HID protocols into a thin embedded implementation. I am stuck at establishing a connection (using only HCI calls). The reply (BT event) that is returned provides an error code indicating a page timeout. I've checked to ensure my local controller (BT master) has authentication disabled. I have checked to be sure I have the correct BD_ADDR for my Wiimote. Any ideas about what additional setup is required before I attempt establishing a (raw - HCI level) connection to the Wiimote?

Thanks.

[edit] I tried connecting with the Wiimote in discoverable mode (pressing sync button under the back cover). I was able to establish a connection (Connection Complete event returns status 0x00), but it was immediately terminated (received a Disconnection Complete event).



Edited 1 time(s). Last edit at 06/06/2013 08:21AM by ags000.

What are the link control parameters (packet types, psrm, psm, role switch allowed...) being used to establish the connection?

I'm using the HCI_Create_Connection command. The parameters are:

BD_ADDR, Packet_Type, Page_Scan_Repetition_Mode, Reserved, Clock_Offset, Allow_Role_Switch

The BD_ADDR was returned in the inquiry result.
I tried packet types NULL (should default to DM1 per the spec), DM1, all legal (per EDR 2.1+ spec) types (DM1,3,5 and DH1,3,5) and even 0xFF just for kicks (it was rejected as an illegal parameter).
I used page scan repetition mode "R1"
I tried using the clock offset returned in the inquiry result, as well as NULL (so the clock_offset_valid_flag bit was cleared).
I do not enable role switching.

At this level, I'm not aware of any way to specify the PSM, as that is L2CAP, above HCI.

I presume either I am using wrong values (for the Wiimote) or there is some other setup that has to happen before I attempt to connect. I have checked the host controller configuration and verified that authorization is not required. I have not taken any other steps for configuration other than the inquiry to get the Wiimote BD_ADDR.

Thanks for any info you can share.



Edited 1 time(s). Last edit at 06/06/2013 11:45PM by ags000.

By "psm" I meant page scan mode, which has been deprecated in later versions of the specification (replaced by the "reserved" parameter).

From experience 0x0018 (DM1+DH1) definitely works for the packet type, R1 should be used as the page scan repetition mode, clock offset can be copied from the inquiry result with clock_offset_valid set or just leave it unset (that's what nintendo does). Role switching should be enabled, although the wiimote won't request a role switch in this situation.

The wiimote definitely must be in discoverable mode otherwise it won't respond to pages, preventing any incoming connections. Once you get the connection complete event it should just wait for L2CAP comms (the LEDs stay flashing until told to do something else).

I want to be sure I understand correctly: I fully agree that the Wiimote must be discoverable if it is to respond to inquiries from the master. However, my understanding is that once the inquiry is complete, a connection can be established without the Wiimote being discoverable (since the inquiry response provides the Wiimote's BD_ADDR). I think you are saying the opposite - that the Wiimote must be discoverable when the connection request is sent from the master. Is that correct?

I did try connecting with the Wiimote discoverable, and a connection was established, but immediately terminated (by the Wiimote).



Edited 1 time(s). Last edit at 06/07/2013 06:22PM by ags000.

Yes the wiimote must be discoverable - that's the only time it will have page scanning enabled (which is how a device "hears" incoming connections) since the normal behavior is for the wiimote to initiate the connection rather than the wii.
What was the disconnection reason given by the wiimote?

I will have to get to another machine to read the log including the reason for the disconnection.

I may need to rethink my project/design. I did not realize that even if I know the BD_ADDR of the wiimote it still needs to be discoverable before a connection can be established. I've read and re-read the WiiBrew/Wiimote page many times and didn't understand that. Is this true if the wiimote is bonded to the host?

Is there an alternative design that you can explain? Such as have the wiimote initiate the connection (how? does it first need to be bonded with the BT host before that will work?) and then (presumably) the wiimote requests a role change so the host acts as master?

Thanks for following up on this.

Once you get the wiimote connected (by activating discovery mode using the sync button) you can do an authentication request. The wiimote will send a link key request, answer with a negative reply and it will request a pin (note that you should set the pin type to variable before this), send the wiimote's BD_ADDR as the pin code and authentication should complete. Then open the wiimote's control and data L2CAP channels and it will be permanently linked, pressing any button when it is "off" will cause it to initiate a connection to your host device.

I was able to look at the log including the reason code for the disconnect, when I was able (briefly) to connect to the wiimote when in discovery mode. The reason code is 0x16, "Connection terminated by local host". I didn't issue any command other than the connect command, so I'm stumped as to why the wiimote reports this. I've been able to reproduce this behavior consistently. I observe a delay between the time the Connection Complete Event returns Success Status and the Disconnection Complete Event - as though there is some further acknowledgement expected from the local controller (not the wiimote) to finalize the connection.



Edited 1 time(s). Last edit at 06/08/2013 07:51PM by ags000.

More results: Using the same BT controller I was able to use the same sequence of HCI commands and establish a BT connection to a laptop, without having the connection terminated. So it seems there is some next step after establishing the initial connection (ACL link) that the wiimote requires to prevent the connection from being dropped. Any ideas about what this might be would be are appreciated.

The next step is connecting the HID L2CAP channels but you said it disconnects immediately... maybe you waited too long to connect after putting the wiimote into discoverable mode.

I've been experimenting with a connection to a BT dongle on a desktop (using Bluesoleil stack) in an attempt to isolate mistakes I may be making misusing the HCI interface from any specific differences present when attempting to interface to the wiimote.

Once I get a sequence of commands that work on the desktop I'll code it to run without delay and see how it works with the wiimote.

I'm currently stuck trying to open PSM 11 and 13 for the HID interface (using the connection to the desktop). There is probably something basic I'm missing. I'm able to connect, and verify the that link quality is good (0xFF) - but cannot open channels for the HID interface. I'm sending ACL data to the L2CAP signal channel (0x0001) and instead of receiving a Connection Response, I am just getting a Number of Completed Packets event. It is as though the ACL data is being accepted, but is not recognized and/or interpreted as a valid L2CAP packet by the remote controller.

Specifically, here's the byte sequence I'm sending for an Echo Request after establishing a connection to the remote controller:

02 2A30 0800 0400 0100 08 01 0000

Which is:

02: UART HCI transport header - ACL data
2A30: connection handle 02A (bits 0-11) - little endian order) of the ACL-U link (returned by the HCI connect command) and PB flag==0b11 (bits 12,13), BC flag == 0b00 (bits 14,15).
0800: length of ACL payload (little endian representation of 0008)
0400: L2CAP header length (little endian representation of 0004)
0100: L2CAP CID for the signaling channel (little endian representation of 0001)
08: L2CAP code - Echo Request
01: L2CAP Identifier
0000: Data Length

Can anyone see what I'm doing wrong here?



Edited 1 time(s). Last edit at 06/10/2013 02:39PM by ags000.

0b11 is an invalid value for the packet boundary flag. The first packet in a segment should use 0b10 and any following packets should use 0b01.

[I suspect that I am missing some fundamental understanding of the packet structure here - perhaps the distinction between PB flag and LLID?]

I had (am having) trouble understanding this flag. When I read the spec I took note of what I found to be conflicting information (BT Core Spec v4, Volume 2 Part E section 5.4.2: "HCI ACL Data Packets"). My plan is to implement a very rudimentary, purpose-built stack to support the wiimote (only). Since the reports from the wiimote maximum size is 21 bytes, I plan to have all packets less than the minimum allowable MTU size of 48 bytes. With this in mind, there would be no L2CAP fragmented packets - every packet would be complete. This is what I thought the "0b11" value was to represent.

However, I found a small L2CAP embedded implementation (remote/client side, not host side) that appeared to use the "0b10" value for all packets. Inline comments explicitly stated that fragmented packets would not be supported.

Finally, the NOTE in the specification (see below) seems to be in complete conflict with the information in the table immediately above it (table does not render here so I've included the relevant columns/rows below also). Perhaps I'm confusing the LLID with the PB? Where is the LLID if not in the PB flag?

I tried modifying the byte stream to use the "0b10" PB value, but then instead of getting a "Number of Completed Packets" event, there was no response at all. Do I need to follow the "0b10" packet with another empty packet with PB==0b01?

--- From the spec ----

Packet_Boundary_Flag: Size: 2 Bits

Value: 00
Parameter Description: First non-automatically-flushable packet of Higher Layer Message (start of a non-automatically-flushable L2CAP PDU) from Host to Controller.
Host to Controller: Allowed
Controller to Host: Not allowed (except during loop-back)

Value: 01
Parameter Description: Continuing fragment of Higher Layer Message
Host to Controller: Allowed
Controller to Host: Allowed

Value: 10
Parameter Description: First automatically-flushable packet of Higher Layer Message (start of an automatically-flushable L2CAP PDU).
Host to Controller: Allowed
Controller to Host: Allowed

Value: 11
Parameter Description: A complete L2CAP PDU. Automatically flushable.
Host to Controller: Allowed
Controller to Host: Not Allowed

NOTE: The start of a non-flushable packet of a Higher Layer Message (start of a non-automatically-flushable L2CAP PDU) with the PBF of 00 shall be transmitted with an LLID of 10. All continuing fragment packets of a Higher Layer Message shall be transmitted with an LLID of 01.



Edited 2 time(s). Last edit at 06/10/2013 06:56PM by ags000.

I should probably also point out that based on my reading and understanding of the BT full specification, I'm assuming that I can assign any channel ID (CID) I want which is >0x3F (the top of the fixed/reserved CID space). I picked CID==0x40 when I setup a new connection. (I see there is a "Create Channel" command, but that appears to only be valid with AMP controllers. I hope I am correct here.) I'm not doing anything to setup this channel, other than specifying that numeric value as the source CID when I establish a connection (for PSM == 0x11 in my testing).

In other words, my understanding is that basically a channel (identified by the CID) must declare a PSM. Only one PSM is associated with any channel. The ACL data packet (for BR/EDR controllers) always contains an L2CAP packet; an L2CAP packet header specifies the length and CID, which in turn is associated with exactly one PSM, which enables the appropriate interpretation/routing of the contents to the proper protocol at the destination.

Is this basically correct?

The wiimote only supports BT Core Spec 1.2 (Read Remote Version Information returns LMP v2) which defines 0b11 as "Reserved for future use". As I said, use 0b10 for the first packet and 0b01 for any additional packets if they're needed (which won't happen if all your packets are smaller than the MTU).
It might help to view logs of bluetooth data between a wii and a wiimote. Here's a log from a game performing device discovery, connection, authentication, HID connection establishment and traffic etc.:
[www.tueidj.net]
CTRL_* corresponds to HCI commands, DATA_* is HCI ACL data. Flow direction is from the host's (the wii) point of view. Note that all the "Read Remote Version", "Read Remote Clock Offset" commands and SDP queries aren't necessary, the wii only does them to be sure it's talking to a wiimote.

Thanks for the log. That will probably get me back on track.

1) This is the 3rd time I've noticed someone using local CID=0x43 when opening the first L2CAP channel. Am I mistaken that the first dynamic (non-fixed, non-assigned) CID available is 0x40? (or is it just a coincidence?)

2) Just checking: is there a typo in the text description for the line below (the MTU=256, not 1)?

L2CAP config request: DCID 0x0044, 0, in MTU=1, out flushto=65535
DATA_OUT(18): 0b 20 14 00 10 00 01 00 04 02 0c 00 44 00 00 00 01 02 00 01 02 02 ff ff

Thanks again - I'll report back on progress.

The CIDs aren't important, the wii's software just counts upwards and this was the second time a wiimote had been synched since the game started.
Both of "in MTU" values are translated wrong, there's another one further down (0xB900).

No joy today. I thought the log would help. I was unable to even connect to the wiimote. Using the same BT module and interface that I'm using to attempt connecting to the wiimote (but failing), I was able to connect to a USB BT dongle on my desktop. The only differences I can see are that the USB BT dongle reports LMP v4 (EDR2.1+) but the wiimote is LMP v2 (v1.2). The error status returned with the failed connection attempt to the wiimote is 0x04 - "Page Timeout". I set the BT module page timeout to 0x8000 (~20 seconds) but that did not help. I am putting the wiimote into discoverable mode (the leds flashing) using the sync button underneath the battery cover.

I am able to inquire and find the wiimote (reports back the BD_ADDR)
I am not able to read the wiimote (remote) name (returns error code 0x04 - "Page Timeout")

Is there something I need to do to make a v4 radio talk to a v2 radio?

The versions don't matter.
The only thing I can think of that might help is to set the page scan type (HCI_Write_Page_Scan_Type) to 1.