That mouse doesn't mention its sensor, so its sensor is probably something extremely misleading and useless. You want something from this list: https://on-winning.com/flawless-sensor- ... t-perfect/spacediver wrote:I've spent too much time today trying to overclock my other mouse (the one with higher cpi) to 1000 hz, as it's currently stuck on 125hz. No success. I can pick up this mouse for about $15 down the street:
https://www.redragonzone.com/products/r ... ming-mouse
Or this one: https://sensor.fyi/list/
I just bought another G403 for $30 from amazon, since my current one is sporadically turning off. That's a mark against it, but I hope the next one works. None of the mice on the market are problem-free. (Competitive gamers will probably want a mouse with lower click latency.)
It's a mixture of snaps changing orthogonal acceleration and force pulses causing problems with parallel acceleration. But I think you should ignore the pulse concept; that is too advanced.spacediver wrote:I'm still not clear why the parallel and orthogonal "subcomponents" (with respect to XYVelocity) will show the "conceptually distinct parts of this [sweep] behaviour".
In my mind, the onset of the snap is associated with an abrupt change in regime of incoming force pulses.
Is the idea that if when this snap occurs, that the component-of-accel-and-jerk-that-show-the-greatest-change would be the component that is orthogonal to XYVelocity? And if so, is this primarily due to the rapid change in intensity of these pulses? Or the rapid change in direction of mouse movement?
The velocity direction won't change rapidly enough during a snap to be useful, if the mouse is already moving at a fast rate.
Note that the snap's acceleration won't necessarily be orthogonal to velocity the entire time: as the mouse starts to move left, it becomes parallel to the velocity between two timepoints, so the eventual snap detection will need an "overall downward direction" that considers a longer time period. But for the downward sweep alone, it's not necessary and velocities between timepoints are enough, given sufficient time and position resolution.
The reason why it's hard to assume that the person moves his mouse straight downward is that it's not really true; the mouse tends to have some error in angle. Maybe do0om's control over his mouse is good enough to make this negligible, but I don't know.
It's true that everything I've described is rotationally invariant, so that it will work on horizontal sweeps. You shouldn't put any horizontal sweeps in your test data, since those will have some different properties because of different muscles. But since you and do0om will be making the same downwards vertical movement, your code won't have to worry about this difference.spacediver wrote:Ok, so we're solely concerned with the kinematics of the movement, rather than the direction (i.e. a valid sweep could be a horizontal one).