Adapting for HyperX Cloud Flight S Wireless

[StefanTraistaru]

Hi,

I've been looking for a while for something that can tell me the headset battery percentage on Linux. But my problem is that I have the Cloud Flight S Wireless and the script doesn't seem to be compatible with them. (or so I think)

I managed to hack my way around the PRODUCT_ID, but beyond that I don't know exactly what to do. Can you tell me how you know what usagePage and usage are in the devices list? As well as how to interpret the buffer and what each byte in it represent?

I got buffers printed in the terminal, but by now I think I only documented the volume up and volume down by pressing buttons on the headset and checking the output.

Any assistance is appreciated :). Thank you!

[srn]

Oh, nice. I guess the next step is to get the S model as well. Is it any good?

I believe the usagePage and usage was through a lookup in the device manager in Windows, otherwise just trial and error, but if you're already getting buffers from the volume changes, it should be fine.

For the battery, you need a tool to analyse the reads/writes through the USB interface, any USB analysing tool should work for this. For the non-S version, the interface would write a buffer that looks something like the following to "ask" for the current battery levels:

hyperx-cloud-flight-wireless/index.js

Lines 44 to 66 in a8b50ea

	const buffer = Buffer.from([
	0x21,
	0xff,
	0x05,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	0x00,
	])
	bootstrapDevice.write(buffer)

IIRC, it would ask every 5 minutes (which is actually draining the battery more than it should, so making it ask every 15m or hourly could get you significantly more battery life overall), so just wait until you see something that stands out in intervals, and that should be your write buffer.

You'll then get some new bytes in the data listener you can try to reverse engineer like I did (only an estimate), but it seems like @hede5562 found some more information on it: Sapd/HeadsetControl#163 (comment)

However, it's been a while since I've looked at this so I might not have remembered the entire process. Let me know how it works out, and feel free to create a PR that supports the S version as well!

[michaelgaultjr]

Has any progress been made on this? I'd be willing to help out, though I'm experiencing some issues getting it to read and write data

[StefanTraistaru]

Sadly there hasn't been any progress from my side on this issue and I won't be able to try further. I will leave here a log of my experience so that people can use it.

TLDR: I bricked my headset, I sent it in service to the store where I bought it from and as they could not repair it, they refunded me the price (6 months after I bought them). I guess it's something. I ended up buying a different wireless headset (Logitech G pro x wireless) as I think they are more popular so there might be a better chance of finding a Linux driver in the future.

My experience
I am not a professional, so don't take anything I say as good advice, it may very well be totally wrong

I tried using wireshark at first but I did not know how to interpret the USB packets so I ended up using another tool: https://freeusbanalyzer.com/. It is a freeware tool but it helped me better read the packets.

Now most of the stuff I discovered is through trial and error. The most progress I have done is for the volume change. But I really wanted to have a battery info indicator (being able to see the battery charge status was the only reason I started this in the first place). So I started Ngenuity app to see the current state of the headset while in parallel I sent different buffers to the headset using this script. I wanted to see to which buffers would the headset respond to. I also tried changing the headset state while sending the same buffer to see how the reponse would change.
By headset state I mean, for example:

• having the headset fully charged vs 70% vs 50% etc
• use headset on battery vs use headset while charging
• different options turned on or off (like mic or sidetone)

This is when I managed to brick it
I don't know how, so please be aware that this may happen to you. I am not trying to discourage you, but please be aware that such a thing can happen and I did not manage to unbrick them.

I don't know what I have done exactly, but I changed their state (don't know which) and then send a buffer (don't know which one) and the headset disconnected from the wireless dongle and shut down. Whenever I would try to turn them on, they would beep and then shutdown. If the wireless dongle was not connected, the headset will remain on (although they weren't connected to anything). My guess is that somehow the dongle would signal the headset to shutdown for some reason. I tried to re-pair them (as in reset wireless dongle to connect to the headset as it would have been the first time) using hyperx guidelines but it did not work (https://www.hyperxgaming.com/unitedstates/us/support/technical/products/hx-hscf).

After a few days of trying to solve this issue I decided to send them to warranty and they gave my money back (so I guess they could not solve it either). I got lucky on this one.

I will attach a markdown file with buffers, code and a log of things I tried. I hope it will be useful for someone. I wish you all good luck and I hope someone manages to make it work.

HyperX Cloud flight S - trial and error log.md