[Feature Request] Check battery level about headsetcontrol HOT 7 CLOSED

This would be really nice! How often the G930 just turned off without any notice. With a tool which gives out a string of the battery life we could make a simple script to send a notify to warn.

from headsetcontrol.

*now possible

:P was confused for a second.

from headsetcontrol.

Hello,

this is possible, but could be difficult.
Does the gaming software display the percentage or another number, or only something roughly? As it could be difficult to find the right packet.

I will take a look into it as I have time.

from headsetcontrol.

It tells you how much time is left, as in "Approx. 5 hours left". When you're charging it, it tells you how much time is left before it's done charging.

from headsetcontrol.

I'm currently actively investigating it (however on corsair void, but the principle is the same on every device).

For that I've written a little software which just reads the USB interrupt: https://gist.github.com/Sapd/c92139fb9a29b4c4d5c025bfcc5d5c08

For my headset it reports: (it reports after a long random time or after plugging power out or in)

buf[0]: 100
buf[1]: 0
buf[2]: 65
buf[3]: 177
buf[4]: 5
buf[5]: 0

There are two values which change between runs:

• buf[2] it could be the value of how full the battery is.
• buf[4] I'm quite sure that it states wether the headset is loading, it is always 5 when plugged in and 1 otherwise

I need further information, so would be nice if you would run that code and post what it outputs and under which circumstances (plugged in, probably full battery probably empty etc.) and how the values change. Like I said it could take a long time until the software responds (try to plug power in and out).

from headsetcontrol.

I investigated it on the corsair void further:
There are two type of packets which are sent and received, both with a USB wValue of 0x02c9:

Packet 100 (0x64):

To send:

• 0xC9, 0x64

Response:

• When loading: 100, 0, 100, 177, 5

• When not loading: 100, 0, 56, 177, 1

The first number seems to be simply the packet number, the third number how full the battery is, and the last one wether it is loading. When loading, the state of the battery is always reported with 100. However, the packet also gets automatically send when the headset is plugged in, then the battery state is always correctly reported (not always 100).

Packet 102 (0x66)

To send:

• 0xC9, 0x66

Response:

• 102, 39, 2, 39, 2

The second and the fourth value is the battery state, regardless if it is loaded or not.

Basically I am now able to provide battery status support for void.

(Technical Note for interested readers):
What I need to do is to include a new dependancy (hidapi). The reason for that is Mac, on Mac I need to claim the device to issue a libusb_interrupt_transfer, but I can't claim it because it is already claimed by the kernel as it is a hidapi device (and mac doesn't allow to unclaim it). LibUSB doesn't directly support hidapi commands and hidapi doesn't support sending USB requests like SET_CONFIGURATION. So I have to mix both APIs. It is not neccesarily Apples fault. The producers of the USB hardware simply made it as hidapi device instead of making an own type, to ease programming on Windows.

Finding the packet for other headsets

If you want support for other headsets (like G930), install Wireshark and make sure to make a full install of wireshark (while installing, check the USB sniffing software).
Go to the USBPcap folder, normally C:\Program Files\USBPcap and start USBPcapCMD.exe. It will list all devices, type the number under which root hub the headset is (mine was on 3) and a desired filename. Start the Logitech software and stay in there a bit, also plug the headset out and in multiple times. After some while, stop the capturing with CTRL + C.

Go to wireshark and open the capture file, type usb.device_address != 1 in the filter text box to filter out other devices (There was a device with id 1 which spammed the capture file for me, could be another id for you).
Search for packets with a info of URB_INTERRUPT in, if you found some, check the leftover capture data field, this is the data field. Now you need to go through multiple of such packets and see if the values make sense as battery indicator (e.g. if there is a 32 in hex, that could mean that the battery is 50% full). Post me the full data of such a packet (the data and the headers!).

Now we need to find the data of the request packet. Before the URB_INTERRUPT in packet, there should be hopefully one SET CONFIGURATION and two URB_CONTROL out packets. Give me the data of both URB packets.

If you want you can also simply send me the capture data.

from headsetcontrol.

WIth e637ef5 it is not possible for checking battery status (currently only on void). For more headsets please use a new issue.

from headsetcontrol.