Skip to content

Corsair HS35 v3 Wireless (receiver 1b1c:2a13, headset 1b1c:2a14) #594

Open

Description

@Dylan-G

Description

I tried to add support for the HS35 v3 Wireless, mainly for battery level. I could not find any battery (or other setting) read over the 2.4 GHz receiver. Here are my findings so nobody has to start from scratch, plus a warning about a command that puts the receiver into its bootloader.

Context

  • Corsair does not support this headset in iCUE, so there is no Windows traffic to capture.
  • The only official software is the web firmware updater (https://www.corsair.com/firmware-updater, v2.0.232, WebHID). Its device manifest lists the receiver with "proto": "sixpand" (pairing id-file-ver: v1-sixpand).
  • Receiver firmware: 2.0.4.

HID layout (single HID interface 0)

Report ID Usage page Direction Notes
0x06 0x000C Consumer in volume up/down (06 01 00 / 06 02 00)
0x07 0x000B Telephony in/out nothing seen on mic mute
0x55 0xFF90 vendor in/out, 63 B SiXpand command channel
0x41 0xFF82 vendor in/out, 63 B OTA firmware data chunks (from the updater code)

There is no Sidetone control in ALSA (only PCM and Mic).

What works

  • 55 71 00 03 (command used by Corsair's updater to read the firmware version) -> reply 55 71 02 00 04 = version 2.0.4. Replies echo the command byte.

What I tried, without result

  • Passive listening on hidraw while powering the headset off/on, plugging/unplugging the charger, muting the mic: only the volume reports (0x06) show up. No unsolicited vendor reports.
  • HIDIOCGFEATURE / HIDIOCGINPUT: the same junk comes back for any report ID (even nonexistent ones), so GET_REPORT does not seem to be implemented.
  • Known Corsair formats (Void C9 64, Wireless V2 / Bragi 02 09 02 0F, Virtuoso XT 02 00) on both 0x41 and 0x55: no reply.
  • Report 0x41, first byte 0x00-0xFF, rest zeros: no reply.
  • 55 71 00 xx for xx = 00-1F (except 03): empty reply (55 71 followed by zeros).

WARNING: do not send these on report 0x55

  • 55 00 ... makes the receiver disconnect and re-enumerate as 10d6:10d6 (Actions Semiconductor bootloader, vendor-specific interface). Unplugging and replugging the receiver brought back the normal firmware in my case.
  • 55 55 00 ... is the official OTA init in Corsair's updater.
  • As far as I can tell, the web updater has no recovery path for a receiver stuck in the 10d6 bootloader, so a bad command here could brick it.

Conclusion
Even Corsair's own updater only reads the firmware version, so the receiver may simply not expose battery to the host. If anyone has more information on the SiXpand protocol (or a capture from any software that shows the HS35 v3 battery), battery support would be easy to add.

Headset Name

Corsair HS35 v3 Wireless (receiver 1b1c:2a13, headset 1b1c:2a14)

Device information

Detailed Device Information
Device Found
  VendorID:  0x1b1c
  ProductID: 0x2a13
  Path: /dev/hidraw10
  Serial: 0123456789AB
  Manufacturer: Corsair
  Product: HS35 v3 WL
  Interface: 0
  Usage-Page: 0x000c  Usage-ID: 0x0001

Device Found
  VendorID:  0x1b1c
  ProductID: 0x2a13
  Path: /dev/hidraw10
  Serial: 0123456789AB
  Manufacturer: Corsair
  Product: HS35 v3 WL
  Interface: 0
  Usage-Page: 0x000b  Usage-ID: 0x0001

Device Found
  VendorID:  0x1b1c
  ProductID: 0x2a13
  Path: /dev/hidraw10
  Serial: 0123456789AB
  Manufacturer: Corsair
  Product: HS35 v3 WL
  Interface: 0
  Usage-Page: 0xff90  Usage-ID: 0x0001

Device Found
  VendorID:  0x1b1c
  ProductID: 0x2a13
  Path: /dev/hidraw10
  Serial: 0123456789AB
  Manufacturer: Corsair
  Product: HS35 v3 WL
  Interface: 0
  Usage-Page: 0xff82  Usage-ID: 0x0001

Report descriptor:

050c0901a10185061500250109e909ea09e209cd09b509b609b109b7750195088142750195088103c0050b0901a101850715002501092009977501950281237506950181030921092f09507501950381070906a10219b029bb1500250c750495018140c0090705097501950181020508150025010908091709180919091a091e091f092009210922092309240925092609097501950f9102750195019103c00690ff0901a10109038555150026ff007508953f8202010904150025017508953f9101c00682ff0901a10109038541150026ff007508953f81020904150026ff007508953f9102c0

New Device Implementation Checklist

  • I acknowledge that implementing a new device requires direct access to the device and familiarity with capturing and analyzing its communications. I have access to the device and am willing to contribute by capturing necessary data and/or attempting implementation.
  • I have already attempted to capture device communications using WireShark or similar tools and am including my findings (successful or not) with this issue to assist in implementation efforts.
  • I am seeking guidance on how to begin this process and am willing to collaborate with the community to add support for this device. I understand where to find resources (refer to the WIKI).

Activity

  1. github-actions commented on Oct 16, 2026

    @github-actions

    Thank you for requesting support for a new headset!

    To implement support for a specific headset, we need to reverse-engineer and test on that device. Only people who own the headset can implement support for it.

    Want to help?

    1. Check our Development Wiki to get started
    2. Use Wireshark to capture USB traffic from the official software
    3. Post your findings (screenshots, data) here - we're happy to help!

    See ADDING_A_DEVICE.md for detailed instructions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions