1) My problem was missing connect attempts initiated by the Wiimote. So if I understand correctly, in that scenario the Wiimote is paging, and my local controller is page scanning. Does the page scan type used by the Wiimote (specifying how the Wiimote behaves when it is page scanning, i.e. when it is made discoverable by pushing the sync button under the battery cover) have implications on how iby ags000 - Hardware
My local BT controller was using default page scan settings. I modified the page scan window, doubling the default (from 11.25msec to 22.50msec) and no longer observe any "missed" wiimote connection attempts. Unfortunately, without being certain of the cause, this is an empirical solution only - until I see another missed connection. Still hoping someone else has seen this or can explain or poby ags000 - Hardware
I have confirmed that my host BT controller is never sending an event to my host when a wiimote connect attempt is missed. I put a scope on the HCI TX line to be sure there wasn't something wrong with my UART sampling that line. I don't have any way to monitor the actual radio, but this does indicate that my BT controller is never reporting any activity (which I extrapolate to mean it iby ags000 - Hardware
I have a basic Bluetooth stack that is able to interface pretty well with a wiimote. I've noted that (after pairing, that is the wiimote is bonded to my host controller), a connection is not established every time a wiimote button is pushed. Monitoring my host controller, it looks like the page scan is not "seeing" the wiimote paging to establish a connection (there is nothing at all sent fby ags000 - Hardware
I have implemented a specialized Bluetooth stack to connect a small microcontroller to a wiimote. After much trial-and-error, it seems that when first sending an output report to set the state of the wiimote user LEDs, a pause is needed or they will continue to blink? Has anyone else seen that? Here's what I've observed: 1) Once an HID connection is established, I originally attempteby ags000 - Hardware
Moved to a separate post ("Is a delay/wait required to stop LEDS from blinking after connecting a Wiimote?")by ags000 - Hardware
I thought that might be true. I looked at the documentation and didn't see anyway to make the LEDs blink - only turn them on or off. I concluded that since I'm not sending any output report to the wiimote to make the LEDs blink, it must be doing it on its own. Is there an output report to send to make them blink, or is it a mode that only the wiimote can put itself in (and can only be sby ags000 - Hardware
I'm working on a project intending to use the wiimote as a user input device controlling a small embedded controller. I have a basic stack that is able to connect. I have two modes that I'd like to support: First, a pairing mode: press the sync button under the wiimote battery cover, then command my local controller to inquire, connect, and finally pair with the wiimote. This seemby ags000 - Hardware
I have been successful in connecting to the wiimote with my "thin" BT stack. Thanks for all the help. I still don't understand why I cannot send an ACL packet with PB=02. But I'm past that obstacle.by ags000 - Hardware
Wow. Not what I expected. I tried setting the host buffer size to match the controller reported buffer sizes. This returned a success status. Then I tried issuing the same command to establish an L2CAP channel - and same symptoms: no response at all. In frustration (perhaps desperation) I decided to fiddle with the LLID bits. I'm still confused by the description in the spec, whichby ags000 - Hardware
I will try. It occurred to me that the parameters may be a problem, but the behavior was to just not respond at all - as if the command was never sent. Surely a reasonable expectation would be for a Command Complete event with a non-success result code. With nothing to guide me, I couldn't even attempt to guess at what would be "reasonable" parameter values. With controller to host flow cby ags000 - Hardware
You may be onto something with setting the host buffer size. As I read the spec, it says that if not set, the controller will assume that it can send an unlimited number of data packets of any size it wants. Also, if controller-to-host flow control is not enabled (which is the default, and I am not enabling it) the number of packets is not used anyway. However, I'm more interested in makingby ags000 - Hardware
I do not use any of these commands. As a matter of fact, I do nothing to initialize the local controller, other than issuing a Reset Command. If there are critical initialization steps please point me towards them. I note from the spec regarding the Read Buffer Size Command: QuoteThe Read_Buffer_Size command must be issued by the Host before it sends any data to the Controller. I can see thiby ags000 - Hardware
That's what I was testing when I started using the BT dongle instead of the wiimote. I was able to send ACL data (based on the "Number of Completed Packets Event" received) with the BT dongle. However, I never received any ACL data (there was never an acknowledgement of the connection request). This is how I got into the LLID and BT version issue. I observed that if I use the LLID (PB flaby ags000 - Hardware
I swapped out the troublesome wiimote for another one. I am now back to where I started: I am able to inquire and connect to the (different) wiimote - but it disconnects almost immediately. (Error code==0x16 "Connection Terminated by Local Host") I'm using the exact sequence to establish the L2CAP channel as in the log you provided (with the exception that the connection handle is differeby ags000 - Hardware
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 returnedby ags000 - Hardware
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)? L2CAby ags000 - Hardware
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 correcby ags000 - Hardware
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 thaby ags000 - Hardware
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.by ags000 - Hardware
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 appreciateby ags000 - Hardware
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. Iby ags000 - Hardware
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 wiby ags000 - Hardware
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 Wiimoteby ags000 - Hardware
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 illeby ags000 - Hardware
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 establby ags000 - Hardware