[qsxcv]

just grabbed a torq x5 from frys.

last year I posted this on esr
Quote:

about this whole smoothing thing: perhaps it is possible to measure.

i have been measuring input lag by colliding an unwired mouse into my g100s and recording videos at 1000fps. example: https://www.youtube.com/watch?v=IA0T_o9qQVc

if you look frame by frame, it's pretty evident that the g100s reaches its maximum speed essentially instantaneously (~1ms or less). this owes to the rigidity of the plastic shells of the mice; if i used a rubber ball or something soft to hit the g100s, the transfer of momentum would occur over a much longer timescale.

by looking at a mouse's raw output and plotting vs time, it may be possible to detect smoothing

see this diagram for what I mean:

here is a real plot with MouseTester. i held down mouse1 lightly while slamming another mouse onto the g100s' side.

it's not perfect though as the mouse could malfunction during the impact. for example, my logitech m100 (a serious piece of ****) shows the following in mousetester:

http://i.imgur.com/L2QSh6i.png

guess what?

evga torq x5 at 3150dpi

3200dpi

 

[MaximilianKohler]

Interesting!

 

[CorruptBE]

Hmmz...

Nice, I actually noticed something similar on some of my mice several months ago but headed no attention to it, assuming it was just something normal.

 

[iceskeleton]

Have you tested other mice?

 

[FreeElectron]

Can you please further explain.
And include a definitive definition of "smoothing"
Then logically explain how can we measure the defined smoothing.

 

[qsxcv]

idk how smoothing is implemented, but the plot of 3200dpi shows that the dsp is doing something like buffering the last 40 or so frames of motion and averaging

 

[FreeElectron]

Quote:

Originally Posted by qsxcv

idk how smoothing is implemented, but the plot of 3200dpi shows that the dsp is doing something like buffering the last 40 or so frames of motion and averaging

If you want to measure something you have to at least define it.
What i think is a proper definition for smoothing delay is a mouse movement delay that might be caused by excessive processing that may result in abnormal mouse movement.
But that definition is not definitive enough to be able to measure it.

 

[LegoFarmer]

Quote:

Originally Posted by FreeElectron

If you want to measure something you have to at least define it.
What i think is a proper definition for smoothing delay is a mouse movement delay that might be caused by excessive processing that may result in abnormal mouse movement.
But that definition is not definitive enough to be able to measure it.

The main consensus around OCN (Or so it seems) is that Smoothing is best defined as post-processing with noticeable delay in tracking. Common in modern sensors to push such high DPI settings.

 

[qsxcv]

Quote:

Originally Posted by FreeElectron

If you want to measure something you have to at least define it.
What i think is a proper definition for smoothing delay is a mouse movement delay that might be caused by excessive processing that may result in abnormal mouse movement.
But that definition is not definitive enough to be able to measure it.

maybe measuring is the wrong word... but what the graph shows is this: http://en.wikipedia.org/wiki/Moving_average#Simple_moving_average
Quote:

Originally Posted by iceskeleton

Have you tested other mice?

only other mice i have are g100s, wmo, ime3.0, g302, g303, and aurora. the aurora's shell is too soft to get meaningful results (flexes by ~1mm easily, which corresponds to ~2ms of contact time). the rest always respond instantaneous. logitech says g302 has 1ms smoothing above 2000dpi, but you can't really see that as usb polling is 1ms

 

[CorruptBE]

Basically what you mean is that we might be able to see on the graphs if a mouse has smoothing or not but not exactly how much.

 

[qsxcv]

well for that 3200dpi plot you can see that it's like averaging the last 5ms of data

 

[Gidra]

wow, clever.

Kana V2 500 Hz for anyone curious:
(sorry, my computer doesn't handle 1000 Hz well)

 

[qsxcv]

do you always see 20ms of low counts? it could be that the sensor is malfunctioning during that period... or that there's just straight up 20ms of input lag.

also it's easier to click using another mouse to active mousetester's data collection

 

[Gidra]

I didn't think about using another mouse.

To avoid accidental release of the mouse button during the bump, I pressed it very firmly.
That pressure caused a slight movement before the actual hit.

 

[qsxcv]

bbump

i've been looking at mousetester plots again for the evga torq x5 and always see these brief spikes at 0.2m/s and 0.8m/s on the accelerating part of a swipe. pretty sure they correspond to framerate transitions, but idk why it just shows up as a spike without any dips before it.

when i change dpi from 1550 to 1600, or 3150 to 3200, the length of the blips changes distinctly. see these images
http://i.imgur.com/AY9aD9L.png
http://i.imgur.com/aA03g7B.png
http://i.imgur.com/gbTQIdf.png
http://i.imgur.com/X8YiQ1h.png
http://i.imgur.com/s7O3us3.png
http://i.imgur.com/UQHdf6i.png
this change in behavior is pretty much 100% repeatable.

not completely sure what's going on... it looks like the smoothing is bumped up when dpi increases from 1550 to 1600 and from 3150 to 3200.

 

[VolsAndJezuz]

That's some good data in both the OP and your last post. I would guess the smoothing algorithm wasn't made to give continuous changes across the DPI spectrum and instead operates like a step function for your TORQ X5.

I performed the same DPI steps from your last post + 400DPI with my Mionix Naos 7000 and came up with some very interesting results. I had long noticed blips in my MouseTester graphs in the low end, and it always niggled me. I never realized how regular the blips occurred at particular speeds (slightly different for my Naos, at 0.2m/s and 0.6m/s) but the framerate transition makes wonderful sense to explain that.

http://i.imgur.com/GACs3y3.png
http://i.imgur.com/W1El1HZ.png
http://i.imgur.com/1jqwqWM.png
http://i.imgur.com/Jg0UC07.png
http://i.imgur.com/UzFWiLE.png
http://i.imgur.com/PufFsow.png
http://i.imgur.com/JrXqDyB.png

I didn't notice any distinct changes in the length of blips on my Naos, but I did see a very clear and peculiar phenomenon that increased in intensity with DPI. You can see as DPI increases, so does the distinctiveness of the polling pattern changes that occur after the blips. I'm guessing that since my mouse doesn't synchronize motion reads with USB polling, that this is creating some odd beat frequencies (might not be the right terminology) in the 0.2 - 0.6m/s range between the framerate transitions. Presumably this must mean that motion read rate is somehow effected by framerate (at least for my mouse), or else I really have no clue what is going on.

Perhaps the intensity of polling pattern changes is showing increased smoothing at higher DPI, due to the random variations being averaged out, which makes the higher DPIs adhere to the polling pattern much stronger.

 

[qsxcv]

thanks for the comparison. you may want to zoom in to make sure the blips aren't 2-3ms or something, since you can't really see those on that scale with mousetester plots.

yea they're definitely framerate transitions. i can estimate it to be ~2050, ~4100, and ~6500 from those pictures, which matches what i measured for the finalmouse
Quote:

You can see as DPI increases, so does the distinctiveness of the polling pattern changes that occur after the blips.

it's because of framerate/usb polling mismatch. lower dpi has more quantization noise of course, so these periodic spikes are kind of hidden.

see these for g303
http://www.overclock.net/t/1541751/logitech-g303-daedalus-apex-gaming-mouse/1490#post_23690684
http://www.overclock.net/t/1541751/logitech-g303-daedalus-apex-gaming-mouse/1510#post_23691033

 

[VolsAndJezuz]

Zoomed in on the blips at different DPI and they are almost always 1ms and very occasionally 2ms in a descending fashion, as in the first blip on your 800DPI graph.

At first I was confused at your comment about quantization noise at lower DPI, because qualitatively it would seem to present itself similarly in the MouseTester graphs. But if I am understanding it correctly now upon further contemplation, the difference is that smoothing is exhibited in the time domain due to averaging of frames while quantization noise is merely the random deviation at a given point in time that corresponds to level of precision in accordance with the DPI...? Smoothing is just more difficult to detect and quantify in the polling data because of its subtlety (except in extreme cases), hence why we can only observe it during more abrupt changes in polling behavior like the two methods in this thread...?

So, from my graphs, it wouldn't appear that any of the DPI would be preferable over the others for the Naos (not taking into account high-DPI effects like jitter)...? Other than 400 DPI, which would seem to have the scenario where quantization noise has become too prominent. In other words, the smoothing seems uniform across its DPI settings (insofar as this test can detect).

Also, we can expect to see blips at characteristic velocities for all sensors using variable framerates, I take it. Does the G303 not have that USB polling synchronization feature you discovered with your oscillator, or is that another mouse I'm thinking of? If I'm not mistaken and it does have that feature, then why would it have changes in polling patterns between framerate transitions?

 

[qsxcv]

Quote:

At first I was confused at your comment about quantization noise at lower DPI, because qualitatively it would seem to present itself similarly in the MouseTester graphs. But if I am understanding it correctly now upon further contemplation, the difference is that smoothing is exhibited in the time domain due to averaging of frames while quantization noise is merely the random deviation at a given point in time that corresponds to level of precision in accordance with the DPI...?

yea by quantization noise i mean like
if you're moving the mouse at a speed corresponding to an average of 2.34567 counts every usb report for 400dpi, (ideally) the mousetester plot would ideally show it bouncing between 2counts and 3counts.
if you increase the dpi to 1600, the expected speed would be 2.34567*4 counts every usb report, and ideally mousetester would show it bouncing between 9 and 10 counts.
then if you plot the velocity, that involves dividing by the dpi, so this bouncing is less pronounced for higher dpi

the thing with smoothing is that i'm not completely sure how it works/what it's doing
Quote:

Smoothing is just more difficult to detect and quantify in the polling data because of its subtlety (except in extreme cases), hence why we can only observe it during more abrupt changes in polling behavior like the two methods in this thread...?

yea and if the timescale is <1ms like for the am010 on g100s or g302/g402 @ >=2080dpi, it's pretty much invisible using these or similar methods.

maybe another way to see smoothing would be to put the sensor out of focus so that the sensor's data gets really noisy, and then compare mspaint lines

 

[VolsAndJezuz]

Quote:

Originally Posted by qsxcv

the thing with smoothing is that i'm not completely sure how it works/what it's doing

I don't think anyone on OCN really knows, we just all think it is some form of demonic witchcraft at work