Sony WF-1000XM6 Pitch and Roll not working correctly.

[GuikiPT]

So as I move my head up and down, the app tracks like if I was doing it with roll, even tried to change the axys but both pitch and roll start changing drastically with only head movement up and down.

Yaw works good.

[GuikiPT]

Does have anyone have the same problem or is there any alternative fix for it?

[Jackabm]

Yes same issue on xm5.
Seems as if they’re getting mapped on the wrong axis curve depending if they’re positive or negative.

Tried all axis variants and inversions and depending on the setup I could change how the errors were mapped but no config fully fixed it so all 3 were correct at once.

[GuikiPT]

I also have tried some configurations as well, but due the fact that is calculation error of the axys, or some short of internal mapping issue, I could not properly see if it was only mine issue, this email saying that you also had the same issue on XM5 surprised me.

I have tried to debug it with help of AI since I honestly don't mess with C++, and it warned me because the XM6 has using the same mapping configuration of the XM5, that was the only finding I could find.

Something I noticed, recently, I formatted my computer and I have tried to install Sony Head Tracking again, after the app install, the first run, executed with no problems, the movement was working without any head deviation, as it was fully following my head movement. But after a restart, it start doing that even when trying to use "Repair Tracker", it started to not track correctly my head as it started to pitch and roll improperly.

[GuikiPT]

Anyways I also received now the notification regarding to a open PR linked to this issue, #19, when I arrive at home in the next few hours I'm going to reinstall the VS Studio and install the necessary windows build tools to build the app from that PR to see if it's fixes this issue. (update, is not going to fix but I will see what I can archive with)

[dkxmercury]

The restart detail is the tell. Clean on a cold start, then a nod smears into pitch and roll after a restart, which a fixed axis mapping literally can't cause. The euler conversion is ZYX against the reference pose the filter grabs at startup (orientation = conjugate(center) * filtered), so once that captured zero is tilted, a straight nod bleeds across pitch and roll and no axis combo undoes it. My money's on the headset reporting a different zero after a reconnect than on a cold start.

[GuikiPT]

So, I got home, read through the discussion, and tried building the project with Visual Studio. With some help from AI, since I’m not a C++ developer, I investigated the issue and attempted to implement a fix.

Based on my restart observation and @dkxmercury suggestion that the headset may report a different reference orientation after reconnecting, I looked into how the application handles the tracker’s reference frame.

I now have a build working correctly with my Sony WF-1000XM6.
Pitch, roll, and yaw move independently, including after recentering.

The issue was that axis mapping was applied to the headset’s absolute orientation before calculating movement relative to the centered pose. Since the headset’s reference frame can change after restarting or reconnecting, this caused pitch and roll to become coupled.
The fix calculates relative movement first and applies the configured axis mapping afterward. It also handles the protocol’s reset counter by resetting the center, smoothing, and drift state whenever the headset changes its reference frame.

My Changes:
GuikiPT@2f09458
GuikiPT@287cbf9
GuikiPT@5f896cc

I physically tested the resulting build with my WF-1000XM6, and it is now working correctly. I’ll also test it in some games, especially DCS, which is the main reason I wanted to use this app.

Testing on other supported headphones, particularly the WH/WF-1000XM5, would still be useful to confirm there are no device-specific differences, since I only own the 1000XM6, I cannot really test it out in other devices. Also I'm not going to PR it for now since I'm unsure about the code (again, AI helped me, I'm not a C++ Dev).

[GuikiPT]

Gived it a try in DCS, and, it's a lot better (https://youtu.be/DTiZ7Yu4qFQ with my changes).

It's correctly mapping now, the rolling is not being affected anymore or at least not at the same way or not to noticiable as before.

[dkxmercury]

The approach is right. Mapping the relative motion instead of the absolute orientation is the actual fix, and re-capturing the center on the protocol reset counter is what makes it survive a reconnect. Worth sending as a PR. It's AI-assisted, but you tested it on real hardware and added tests, which is what a reviewer needs. The maintainer can take it from there. In a branch it only helps you.

@Jackabm, you have the XM5 and tried every config, so building this branch and confirming it fixes yours too would show it's not device-specific.

[Jackabm]

Built the fix last night and it all worked well. So XM5 works with this fix too

[dkxmercury]

That's the confirmation you were missing. Fix works on XM5 and XM6, so it isn't device-specific. Worth opening the PR now.

[crismer101]

Hola, puedes exponer el archivo fuente o compilado con las modificaciones. Puedes exponer el ejecutable?.
Gracias

[GuikiPT]

Hola, puedes exponer el archivo fuente o compilado con las modificaciones. Puedes exponer el ejecutable?. Gracias

Hey, and sorry for disappearing for so long.
I completely forgot about this issue.

Regarding the fix, I’ve been cleaning up my fork because after initially implementing it, I experimented with several other changes and honestly ended up making quite a mess of the fork.

What I’ve done now is reset my fork against the current upstream code and re-apply only the fix I originally mentioned here:
#10 (comment)

So, at the moment, my main branch should basically be the current official code plus only that tracking/reference-frame fix, without the unrelated experiments I made afterwards.

I still want to properly test this clean version before pr anything at here. My workstation at work runs Linux, while the application is currently windows and mac, so I’m planning to set up a Windows VM there and test the new build properly with my WF-1000XM6 today.

Once I’ve confirmed that the cleaned up fork still fixes the issue and that I didn’t accidentally introduce anything else, I’ll prepare a proper PR for NicholasSlattery to review and, if the implementation looks good, potentially merge into the official repository.

For anyone wanting to test it in the meantime, I’m also rebuilding releases from my fork with the cleaned-up code. Just keep in mind that these are unofficial builds from my fork and I wouldn’t recommend treating them as stable releases yet. Some of my older releases were made while I was experimenting with other changes and were pretty broken, which is why I’m cleaning those up as well.

Hopefully this time I can keep the fork clean and actually get the fix into a proper PR.