What causes a 500Hz mouse to sometimes report at 250Hz or 125 Hz?

[Chief Blur Buster]

I just quickly checked my Arduino program (which I haven't touched in over a month) and I think I see the problem...

You can busyloop on the monotonically increasing microsecond counter. The micros() can do microsecond-accurate sleeps that way on some Arduinos that are performant enough.

It's accurate to 1 microsecond on Teensy 4.0. It's delightfully accurate when nothing is running in background.

Keep in mind that USB HID has processing overhead that can jitter that slightly, so remember to finish (and maybe flush USB packet-sending; something Teensy 4.0 supports an API call for) right after a busywait, so the next busywait isn't jittered by your Teensy's USB software stack, or slows down the USB, etc. Also, incoming packets may cause issues, so your busyloop needs to have interrupts enabled (to keep USB stack working), but they will generally jitter the busyloop exit by less than 10 microseconds.

Teensy 4.0 is an Arduino clone running a 600 Mhz ARM Cortex M7, and is easily capable of realtiming events to 1 microsecond in many situations if your code is written decent enough.

Many Arduino clones exist, but Teensy 4.0 is the most delightful realtime-accurate inexpensive "prefab out of box" one I've used recently.
It even supports 8000Hz USB.

[TooManyPixels]

So, I think I have something... but there's enough weird anomalies going on that I'll probably prove myself wrong in a few weeks after investigating each...

So here's what I've got to show to you all so-far:

Good vs Bad comparison.png (169.26 KiB) Viewed 3855 times

I was able to do my traces on a friend's unaffected machine over the weekend and I believe I now have actual proof of anomalous behaviour (but not enough to attribute to imprecise mouse pointers yet) - so while this is something I can definitely take to Microsoft and ask them to investigate, I doubt they'd do anything with it... yet.

• The "Bob X" and "Me X" columns show the raw USB HID reports relative mouse movement in the X axis (all Y-axis data is hidden in that spreadsheet) - as you can see, the raw inputs are identical. Also, both computers had identical Windows mouse settings (speed, acceleration, acceleration curve, etc).
• The "Bob dQPC" and "Me dQPC" columns show the time delta (in QueryPerformanceCounter) between each Win32 Raw Input WM_INPUT message (a value of 10,000 means 1ms; I re-played mouse movement with a fixed 1000Hz reporting rate for this scenario)
• The "Bob vs Me dQPC" column shows any difference in the time-between-reports on Bob's machine vs. My machine. So it's interesting that Bob's machine actually had more jitter than my machine, even though my machine is the one worst affected by this floaty/imprecise mouse issue. (I did record a full USB trace here, but I haven't yet examined the low-level packet timing data yet)
• My main take-aways here, are that:
• 1: for some unknown reason, Windows is accelerating my mouse cursor more (per-unit-of-relative-input) which isn't explained by the report timing.
• 2: When the mouse starts to decelerate (see around row 422, where the Report X drops from 10units to 6units) My computer decelerates my on-screen cursor faster than on his machine (i.e. my mouse pointer spent more time closer to 1590px than his did)

Of course, the weird delay on Bob's machine (around row 437) is anomalous - but it's curious, because you'd think Windows would interpret a long gap between reports as a sign the mouse had suddenly stopped - yet the Bob PhysX column shows Windows kept the pointer's intertia up and maintained its effective on-screen speed - so that's curious.

Also, I'm unsure exactly what to make of the ~+10px difference seen on my computer compared to his: observe how Bob's computer always eventually catches-up with mine within 1 or 2 WM_INPUT events (well, that's exactly how acceleration works) - so I'll need to annotate this to show the actual cursor pos used by the GPU when rendering the frame (which happens every 16ms, whereas these WM_INPUT events are every 1ms).

I'm open to suggestions for how to proceed, ofc.

[TooManyPixels]

You can busyloop on the monotonically increasing microsecond counter. The micros() can do microsecond-accurate sleeps that way on some Arduinos that are performant enough.

Right - I switched to using `micros()` (though I didn't do a blocking loop, I wrote a state-machine so the program can cooperatively yield control). I was able to validate my approach using my Beagle USB profiler: I want 1ms between reports (for 1KHz reporting), and the Beagle's own hardware clock says my reports have an error of about +80 to +170 nanoseconds (i.e. sub-microsecond level), which is fine-by-me.

Beagle time between reports.png (287.59 KiB) Viewed 3838 times

Teensy 4.0 is an Arduino clone running a 600 Mhz ARM Cortex M7, and is easily capable of realtiming events to 1 microsecond in many situations if your code is written decent enough.

Many Arduino clones exist, but Teensy 4.0 is the most delightful realtime-accurate inexpensive "prefab out of box" one I've used recently.
It even supports 8000Hz USB.

I can't say I'm familiar with Teensy, but I'll take a look - sounds interesting.

[Chief Blur Buster]

I can't say I'm familiar with Teensy, but I'll take a look - sounds interesting.

It's pretty easy to transition between Arduino clones/compatibles nowadays because the same Arduino IDE is used;

The same code I had on my Arduino compiled fine in the same Arduino IDE for my Teensy, once I used the Teensy plugin.

You may have to #ifdef to disable features that aren't supported such as USB packet flushing API calls (e.g. "USBflush()" style stuff), since it's good hygeine to flush for lower-latency, especially if you're doing USB-packet-relaying (box-in-middle stuff, ala software-defined USB hub that just happens to be monitoring performance). Some Arduinos do not support that, but Teensy does. Maybe you're already doing that sort of thing, if you've essentially written a USB-sniffing USB hub in Arduino code, in order to monitor the timing accuracy of these packets.

I can even compile to different targets by selecting a different model, much like targetting two different Arduino-brand devices, the Teensy plugin simply added more compile targets.

But, your error margins are still fantastic, you might not even need it, unless you want to do 8000 Hz monitoring. That's going to eat some background CPU time in the USB stack, interfering with your "do many tasks at same time" microcontroller challenges.

[TooManyPixels]

But, your error margins are still fantastic, you might not even need it

bg,f8f8f8-flat,750x,075,f-pad,750x1000,f8f8f8.jpg (30.78 KiB) Viewed 3801 times

[Bobo]

if you ever have the chance, try something like the ifi iDefender+, it`s a device that blocks the power coming from the usb port and provides power from an external power supply.

[F1zus]

I would like to know what happens after switching the mouse dpi via a button.

Great idea!

I'm currently having trouble getting my (brand new...) Logitech G502 X to consistently switch between its DPI settings, and when using the Logitech OMM (Onboard Memory Manager) program it doesn't seem to have any effect (as-in, my mouse pointer movement felt roughly the same even when I set it to 400dpi vs. 3200dpi).

But even-so, I did do a software-only (ETW) trace of kernel and user-mode events and looked at the data in-detail and again, saw no difference when I moved my mouse sufficiently fast over my mousepad (just moving it back-and-forth rapidly about 3-4cm total displacement)

I conducted tests on different operating systems: win7, win8, win10, win server 22, win11, linux ubuntu and everywhere a strange effect was observed when switching the mouse dpi. Even on an Android TV set-top box with an arm processor, this strange effect was observed. After switching from 1600dpi to 3200 and then back to 1600, my mouse became more responsive, and the sensitivity in the game was slightly higher.
I think this is related to the mouse itself, perhaps the power saving functions are disabled in it, but I tested Razer, Logi and Zowie mice, the behavior is the same. This may be due to the energy saving of the CPU processor. But definitely not with the operating system.
I also connected the mouse to an asus rog 6 mobile phone and there was no effect from switching dpi on it (maybe I didn’t notice this because of the small screen).

[Vocaleyes]

Do all the mice you used have on-board memory and could this be a conflict issue if so?

[F1zus]

Do all the mice you used have on-board memory and could this be a conflict issue if so?

Yes, all mice. Razer V3 Pro, Logi Super Light, Zowie and others. All of these mice had built-in memory. I tried deleting all dpi profiles in the mouse memory settings and leaving only 800 or 1600. But even in this case, after pressing the switch dpi button, the mouse becomes more responsive.

[issawm]

Do all the mice you used have on-board memory and could this be a conflict issue if so?

Yes, all mice. Razer V3 Pro, Logi Super Light, Zowie and others. All of these mice had built-in memory. I tried deleting all dpi profiles in the mouse memory settings and leaving only 800 or 1600. But even in this case, after pressing the switch dpi button, the mouse becomes more responsive.

YES SAME HERE OMG I BEEN HAVING THIS ISSUE FOR A GOOD HALF A YEAR AND WHEN I PRESS THE DPI BUTTON IT FEELS WAY MORE RESPONSIVE!! but only for a few seconds until it messes up again .