Im trying to get the output from a Wii Fit (balance board). I can find the device via the C++ Bluetooth enumerators but attempts to connect via a windows socket are failing.
Im wondering if anyone has had success in such a direction (C++, windows) I'd love to hear how you did it.
The Wii Balance Board is a HID device. To understand communications with the Balance Board, you need to know a little bit about Bluetooth HID. There's good information on WiiBrew about the Wiimote and the Wii Balance Board.
I don't think you can use Windows Sockets to connect to a HID device. The Windows Socket Bluetooth interface only allows you to connect to RFCOMM-based services. HID is based on L2CAP which is further down the Bluetooth protocol stack. There's some information at MSDN about that limitation.
If you're just looking to hack around with it, you can try Bluecove for Java. You may be able to do something using another stack (for example, Widcomm). If you're locked in to Windows and C++, you may have to look into writing an custom HID driver for the Balance Board.
As pwc said there is a limitation in the MS Bluetooth API, so with sockets you cannot have something else except RFCOMM, but this doesn't mean you cannot go down at L2CAP layer. What you have to do is to implement a client profile driver and you can use as starting point an article from MSDN: Creating a L2CAP Client Connection to a Remote Device and vice-versa: Accepting L2CAP Connections in a Bluetooth Profile Driver
Next of course as pwc said you have to study Bluetooth HID and WiiBrew for the communication protocol.
Also a good document to read is Bluetooth Wireless Technology FAQ - 2010 which states clear that it is possible to have L2CAP connections with Microsoft Bluetooth stack driver. Of course not with sockets.
When using HID on a Bluetooth device there is generally no need to create a L2CAP connection directly. All(???) of the Bluetooth stacks on Win32 have support for Bluetooth HID and provide access to the HID stream/control through the native Windows HID API. No (direct) L2CAP required! :-)
On WinCE there is built-in support for Bluetooth HID also, but I'm not sure there's a way to access a HID API.
That's how Brian Peek's wiimore library works -- it uses the HID API. The good thing about that is that one gets supports for all(?) the Bluetooth stacks that way -- they each support HID devices via the Windows HID API, whereas to use L2CAP directly one would have to support each of the stacks' APIs... (That's if they have one! BlueSoleil has no L2CAP API as far as I can see).
So, on Win32 one should just pair with the device and check that the HID checkbox is checked on its Bluetooth Service control panel tab (whichever Bluetooth stack is in use). In my 32feet.NET library one can discover the device and then ensure that HID is enabled for it with:
BluetoothDeviceInfo[] list = btCli.DiscoveryDevices();
var deviceInfo = list[n]; // Select the correct device
deviceInfo.SetServiceState(BluetoothService.HumanInterfaceDevice, true);
(That should work on MSFT and BlueSoleil; there's no API for that on Widcomm AFAIK -- although when paired it might be automatically enabled anyway).
The one possible exception case is that apparently some devices are not fully compliant with the Bluetooth/HID specs, I'm told the PS3 blu-ray controller is like that. Then one might want to try L2CAP connections directly -- however its likely that the stack's support for HID will interfere with third-party applications trying to provide the same service...
Related
I have a Wemos D1 Mini (ESP8266), flashed with WLED and I want to create an application like .exe and have control on turning it on/off and choose colors. Does anyone have any idea how I can do without to connect on wifi and just do everything via USB?
To control the WLED firmware over USB, you would use the firmware's ability to be controlled over a serial connection. It looks like you would open the virtual serial port that appears when you plug in the device, at a speed of 115200, and then you take the same JSON that you would POST to /json/state for controlling it over WiFi, and instead send it over the serial connection, and get your responses back over the serial connection.
You could also implement the TPM2 protocol, or the Adalight protocol (which doesn't really seem to be documented except in code), as those are also supposed to be supported.
If you want to do all this in C++ on Windows, you might start by reading the (very old) Windows tutorials for Win32 API serial port programming. If you only want to target Win10 or newer, you could learn C++/WinRT and then use the new WinRT serial APIs. Or you could consult the answers to this question about serial programming on Windows.
I'm trying to write a program that sends COM port information to devices that may get unplugged and end up with a different COM port number. Using SetupDi, I know it's possible to list all the COM ports on a computer by number, but given that the number might change I'm trying to find a better way to access the COM ports.
The COM devices I'm using are FTDI serial-to-com adapters that let me program the device model. I'd love to be able to choose a COM port based on the device model. I've tried (almost) all of the properties that I can get to using SetupDi, but no dice. It looks like there's a difference between the device list SetupDi lets me access, and the devices that show up under Devices and Printers (where the model name does show up). Is there any way to get devices in the Devices and Printers window programmatically and map them to COM port using Windows APIs?
The link below is a great (if not the only) comprehensive overview on how to enumerate COM ports on Windows and extract extra information in various ways:
http://www.naughter.com/enumser.html
What we use in our own software (Docklight) is according to what the "UsingSetupAPI1" way from the enumser.cpp file shows (SetupAPI - GUID_DEVINTERFACE_COMPORT). The UsingSetupAPI1 example demonstrates how to extract the device name as shown in the Windows Device Manager, along with the COM number. This is called "friendlyNames" in the enumser.cpp code.
Another way to identify and communicating to your device could be not asking Windows in the first place, but the FTDI D2XX API:
http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples.htm
We use the D2XX API for communication when we know it is always a FTDI device. Identification is simpler and we have much better performance / less latency than using Windows Communications API via "virtual COM port".
If we need to correlate between COM port numbers and a FTDI device ID, we use the FTDI D2XX API's ListDevices and GetComPortNumber functions.
I wanted to know if there is any stack independent C/C++ bluetooth api for windows (XP, Vista, 7, x86 and x64).
My target is to create a connection and send/receive some time critical data over bluetooth.
My researches gave me the following options and there disadvantage for this task:
Windows Sockets for BluetoothOnly works with microsoft bluetooth stack
Using the COM port (CreateFile/ReadFile/...)Slower than the socket option and the user has to connect to the device first.
Use stack dependent APIThis would require to detect the used stack and create read/write functions for every stack. Very time consuming and I don't know if it is even possible to support all stacks
Writing a KMDF driverI thought about writing a function driver to talk directly with the bluetooth HCI driver which should be stack independent. This would be very time consuming because I would have to read the whole bluetooth spec, or is there an API for the HCI commands?
I know that there is also a commercial sdk from btframework.com which supports most (or all) bluetooth stacks, but I need a freeware option.
Please tell me if there are any other options for this task.
If there aren't any, could you tell me which options you would prefer and why?
Is it okay to use Windows Sockets and ignore the other bluetooth stacks?
Thanks for your help :)
I guess one option would be to use C++/CLI to interface with my managed Bluetooth library 32feet.NET which supports most of the stacks on Windows. http://32feet.codeplex.com/
I've been successfully using this library it is called WCL but it is not free. With this you can connect through SPP without requiring to create a virtual COM port.
While their documentation is not very good, they provide some good demo code that you may want to try.
It supports the Microsoft, Toshiba, Widcomm and Bluesoleil stacks and there is a native C++ implementation (as well as a .NET one).
I would be using a USB hub to connect multiple devices. I want to fix a specific USB device to a particular slot. Then check if it is done properly.
The way I am planning to achieve this is to get the complete USB path like
PCIROOT(0)#PCI(1D00)#USBROOT(0)#USB(1)#USB(2)#USB(3)#USB(3)
I can get this particular string in w7 via device property but the same is not available in wXP.
You can build this path by using the SetupAPI.
The device manager is built with this.
You start with CM_Locate_DevNode and enumerate children with CM_Get_Child.
I strongly advise you against what you're planning to do. AFAIK a USB device MUST function regardless on the USB port it's plugged in. If you'll creating such a device, forget e.g. about the "Certified for Windows" logo.
Just handle WM_DEVICECHANGE message, then use e.g. WMI to search for the USB device you're interested in. Here's my article about it: that time I coded C# language, however WMI has C++ API as well.
I'm developing a device and writing the software for it under Windows (MFC with Visual Studio).
I would like to start a measurement with a remote. It would be nice if it worked over Bluetooth, but I don't have a clue where to start.
What book can recommended or is there a site where such things are described?
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a program then starts specific subroutines.
As Dan wrote in the comment when it comes to Microsoft the best place to start is with MSDN. For me his link didn't work, but I guess he wanted to point here.
MFC does not offer you support for Bluetooth, instead you have to work with a Bluetooth driver stack API. On Windows there are more stacks, but most widely used are: Microsoft Bluetooth driver stack and Widcomm/Broadcom. If you decide to use the Microsoft Bluetooth driver stack you might want to look on this thread. The stack that you choose it depends on the Bluetooth dongle attached/incorporated at your PC.
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
Yes, it is possible to make your own Bluetooth device. The fee depends from case to case, first if you want to be assigned your own IDs from SIG you have to pay them a fee, otherwise you can use the ones already bought by the chip manufacturer. Also if you want to re-write the firmware from the chip you could be forced to buy a software from the chip manufacturer. Usually it's enough with their firmware.
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a Software then starts specific subroutines.
Well, it seems you will have to take care of the device discovery aspect and second make the pairing. After this you could use Serial Port Profile to communicate with your device like any other RS-232 enabled device. If your device is dedicated you might want to modify the IAC - Inquiry Access Code so in discovery phase only you that you know the code, can see the device.