Headset found but not active

[RodneyMcKay715]

The Headset is detected and working but shown as "found but not active"

The Headset is a Cloud II Wireless from HyperX but the HP version.

Is the Problem related to the manufacture?

[auto94]

Kind of, yes. The app still functions with my Kingston headset.

I assumed (well... hoped) that they wouldn't change the actual data being sent and received by the headset and without an actual HP headset I couldn't check.

I have one thing in mind that I can try, but if that doesn't work out, would you be willing to make a wireshark recording of the USB data transfers when you open the official NGENUITY app? I would prepare a step by step guide for you but it would probably still take roughly 15 minutes of your time, and you'd need to install wireshark + USBPcap.

[RodneyMcKay715]

Hey there, no trouble at all. Once i found which USBPcap was working i tried capturing as you wanted. I hope it gives you the information needed. Thanks for the effort. If you need anything feel free to contact me.

HyperXCloud2Wireless_HP.zip

[auto94]

Hello again,

I think I've successfully reverse engineered the write/reads for the HP headset and have prepared a build for you to try. Please give it a try when you have the chance and let me know if works. Fingers crossed!

Pre-release of the hp-fix branch download here.

[RodneyMcKay715]

I just tested the build ,sadly the same message remains, shall i do another capture? Maybe i did something wrong on my end.

[auto94]

Yes, please do another capture and write your battery level at the time of recording. Also, if possible make a recording of you pressing the "Refresh" button in the battery monitor app. Thanks.

[auto94]

Hey, any chance you could take a look? I'm about to add support for the HP Cloud II Core headset and it'd be great if I could bundle both together. Thanks!

[asynchronous98]

Hi, any chance to implement support for Cloud Stinger Core Wireless 7.1? I captured it when opening ngenuity, then I closed ngenuity and connected the charger.

cloudstingercore.zip

[RodneyMcKay715]

Hey, any chance you could take a look? I'm about to add support for the HP Cloud II Core headset and it'd be great if I could bundle both together. Thanks!

Hey there, sorry for the long time of no reply. Life got in the way, as it always does. I started a capture, then opened Ngenuity and then checked the battery percentage. I can see activity in the capture. Maybe you can do something with this infomation. Just reply if you need anything further.

Capture_HYPERXCLOUDII_WIRELESS.zip

The Battey percentage is 85% at the moment of testing. Here is the capture when i click on refresh in the app you are developing:

Capture_HYPERXCLOUDII_WIRELESS_BatteryMonitor.zip

[auto94]

Thanks, @RodneyMcKay715. Totally understandable and I appreciate your help.

I've made another pre-release (Release v1.4-beta), please try it when you get the chance. Going to be honest, I kinda feel the last one should've worked but I did make some small changes in this one.

If it still doesn't work, please make another recording of you pressing the refresh button a couple of times in the battery monitor, along with a screenshot of the app.

---

@edimarpeterlini as for the Stinger, I've checked and I am not even sure it's possible. Does ngenuity show you the exact battery level? If it does I'll create a separate issue with some extra questions.

[RodneyMcKay715]

Hi, sadly it still tells me that the Headset has been found but is not active. Here is the capture:

Capture_Ngenuity_App.zip

I first clicked refresh in your app 3 times and then switched over to ngenuity and watched the battery percentage which is 84%.

[auto94]

Well I'm a bit stumped. In the recording, you can see in packet #32, the request gets made, in #33 the response is that it was successful and then in #38 the 7th byte of the return data is 0x54 which equals 84%.

Judging from the screenshot, I believe you're on Windows 11? Can you try and run it in Win10 compatibility mode? Right click on the exe, properties, compatibility tab, run the program in compatibility mode for windows 10.

Maybe I need to wait for the second incoming packet. I'll try that.

[auto94]

Try this now, added some extra reads. I'm optimistic. Release_v1.4-beta2

Thanks for your help and patience!

[asynchronous98]

@auto94 It doesn't just show loaded, medium level and low level. I thought that in alternative software this could be resolved.

[RodneyMcKay715]

Try this now, added some extra reads. I'm optimistic. Release_v1.4-beta2

Thanks for your help and patience!

Hi, sadly it did not work and i only got the option to run in compatibility with Windows 7 and 8, which both did not work. Ill try on a Windows 10 machine if that makes a difference and let you know. Thank you for your help with this.

EDIT: nope WIn10 did not make a difference. Its detected since the text is changing but the battery level cant be read for some reason.

[auto94]

Hello, I've got my hands on another headset and I've figured out the problem. Please try the new pre-release.

The problem was that the HID API returns multiple devices with the specified vendor id and product id. I thought that the easiest way to determine which device was the one that will respond with the battery level would be the one with the high usage_page. This was the case with the Kingston Cloud II Wireless and the HP Cloud II Core Wireless which both return the following devices:	Kingston/HP Core	Usage page	Usage
HID Device 1	12	1
HID Device 2	65299	1

But the HP Cloud II Wireless returns 4 devices and it isn't the one with the highest usage page that responds but the one with the highest usage.

HP Wireless	Usage page	Usage
HID Device 1	12	1
HID Device 2	65472	1
HID Device 3	65424	771
HID Device 4	65280	1

Unfortunately there isn't any property that would otherwise indicate which device is the one that actually responds so I had to make do with what I had available. If I had a better understanding of the USB/HID protocol maybe this could've been avoided but I think these are some vendor-specific usages/usage pages and are not publicly known (at least I didn't find much).

Either way, it should actually work now so give it a try :).

---

@asynchronous98 I'm sorry I doubt that it's possible and if it is it's beyond my expertise. Sorry.

[RodneyMcKay715]

Hello, I've got my hands on another headset and I've figured out the problem. Please try the new pre-release.

The problem was that the HID API returns multiple devices with the specified vendor id and product id. I thought that the easiest way to determine which device was the one that will respond with the battery level would be the one with the high usage_page. This was the case with the Kingston Cloud II Wireless and the HP Cloud II Core Wireless which both return the following devices: Kingston/HP Core Usage page Usage HID Device 1 12 1 HID Device 2 65299 1

But the HP Cloud II Wireless returns 4 devices and it isn't the one with the highest usage page that responds but the one with the highest usage. HP Wireless Usage page Usage HID Device 1 12 1 HID Device 2 65472 1 HID Device 3 65424 771 HID Device 4 65280 1

Unfortunately there isn't any property that would otherwise indicate which device is the one that actually responds so I had to make do with what I had available. If I had a better understanding of the USB/HID protocol maybe this could've been avoided but I think these are some vendor-specific usages/usage pages and are not publicly known (at least I didn't find much).

Either way, it should actually work now so give it a try :).

@asynchronous98 I'm sorry I doubt that it's possible and if it is it's beyond my expertise. Sorry.

That's awesome. I just tested and it works perfectly. Sorry that you had to get another headset and that the Captures were not enough.

[auto94]

Glad to hear and thank you for your help anyway! Closing this issue now.