In my opinion the Ninox Aurora has the best sensor, I'm not sure which one it is though, maybe someone who is more familiar with sensors can figure that one out, however I don't need to know which sensor the Ninox Aurora uses. All I need to know is that it is the perfect sensor in the perfect mouse.

- Skeletor

not sure if srs

I don't understand the velocity vs. time graph: how is it plotted?

I mean noone is hitting 5 m/s within under half a second, then deaccelerating in perfect shape...? I'm missing something here.

Something else struck me as odd, the graph in most plots goes below 0 m/sec at the end. Why might that be


But now I have to clarify, I do not want to attack the notion this could be a measurement for sensor performance in some way. I agree on the notion the MS mice are some of the best gaming mice still and feel truly responsive, more so than some newer mice. I can say so as I own about ten gaming mice and tested them thoroughly.

I can post some more also about my personal experiences in the next days

velocity = change in counts / change in time / CPI

As for the shape of the graph, it's easy to make. Download the software and try it yourself.

yes, but look at the graphs, why do they look like a perfect normal distribution, with 5 m/s at peak. As I said, a human can hardly hit that speed, let alone in such a perfect motion, so something else is in play

what do you mean by "raw counts", any mouse will always output the processed counts.

it's perfectly doable on a large mousepad unless you're seriously weak

raw counts means the raw data the computer receives i guess

the shape of the curve has nothing to do with any "distribution". it's merely a coincidence that it looks like a gaussian curve

OK I understand, "raw input" of the mouse to the PC, not altered in any way.

I am not convinced about the shape of the plots. It has to be some kind of crazy coincidence all measurements peak at 5 m/sec and decelerate in perfect symmetry, all in under a second...

Well technically it is a distribution... but it has nothing to do with statistics of corse, only the shape is very similar.

Look at comment #9, this is more like what I'd expect, or at least a difference in plots where none looks like the other.
I looks like the plots from the OP were made by some machine setup? Or as I said I don't get it

it's a function of time, not a distribution in any sense of the word distribution

the graphs are made by a swipe across a mousepad. there's absolutely nothing unusual and if you've ever played with mousetester you would know that the shape is the natural one formed when you swipe quickly to the right

Yeah I need to try the program myself, I think I will understand it then.

'Something else struck me as odd, the graph in most plots goes below 0 m/sec at the end. Why might that be'

Theory: Software takes the initial direction of displacement as positive, and the tester moved the mouse back in the opposite direction of travel briefly at the end of their sweep.

thats correct and i think it's pretty obvious that it's what happened

the graphs are interesting in their own right but there is no proof that differences in the mice's graphs explain the differences that you claim to perceive.

keep in mind that

1. bumpiness in the graph is significantly affected by the mismatch between the sensor framerate and the usb polling rate
see my post here: http://esreality.com/post/2704315/re-new-gami...pid2703355

lower usb polling rate will make the graph smoother. but this does not mean that motion in games or on desktop will be smoother, unless the mouse's firmware is shitty and can't handle 1000hz properly or something

2. as the game framerate is typically <500, the mouse motion in each frame corresponds to the sum of several mouse movement samples.

3. mousetester graphs say absolutely nothing about input lag

4. firmware that "smooths" the sensor's data can create some very nice looking graphs

And if anything, a smoother velocity graph would indicate greater smoothing.

We finally have a tool to indicate "smoothing". Nice.


So the graphs are useless in this regard. Only good for showing differences between mouse pads?

ya but not necessarily. e.g. if the smoothing occurs at the sensor level and the sensor framerate isnt a multiple of usb polling rate

I think a better example of a smooth graph NOT implying smoothing would be when the USB polling interval is a multiple of the sensor frame interval.

Your example illustrates why an not-smooth graph would does not imply a lack of smoothing.

There are a few things that can be inferred alone from these plots, but clearly smoothing isn't one of them.

Edit: I mean to say the graphs can't tell much about smoothing done at the sensor level i.e. effective smoothing intervals greater than the frame interval but less than the USB poll interval. I believe a regularly jagged graph, like the ones you point out indicate a beat frequency between USB polling and sensor framerate, also indicates no smoothing at the USB polling level. It's hard to believe any mouse would actually have smoothing at that level though.

comment on point 2:
if we consider 250fps and 1kHz polling rate, plotting the same graphs with a 3 samples LPF (1k/250 + signals unsynched) should show the real ingame effect, regardless of point 4.
if the resulting graph is accurate within the game engine bandwidth (250Hz in this case), everyone should be fine.

LOL?
You mean these graphs which give information only about MAX SPEED ? These graphs what I saw here.... are ok. LOL

this is bad thing http://i.imgur.com/6QZxvHp.png with g100s, hitted max speed and received negative acceleration.
But I dont hit max speed in game, so g100sw is fine, FOR ME.

But these graphs which you posted means that 3366 sensor got GREAT max speed.... and nothing more.


I dont know if I understand you well. But your 'proof' seems to be a bullshit.

Yeah, you didn't understand. We're not talking about max speed.

We're looking at how much the dots deviate from the curve.

and few tests is a proof for you? you need to check it a lot of times...

Also on lower speed dots are very close to the curve... so...

how about your super perfect wmo?
http://imgur.com/a/dKnxq

The problem is that you're hitting the malfunction speed with the WMO, which hinders what we're trying to look at in this thread.

Like I said in the OP, the test isn't perfect by any means, but it does at least give us some evidence of differences we can detect in game.

these graphs show you visually exactly the data sent from the mouse to the computer. you can infer much more from these than just the max speed

you got other options of mouse tester for that.

k find me another option that allows me to estimate the sensor's framerate

maximum tracking speed itself is a good indicator of sensor framerate for modern mice

i dont have an arm like a cnc to achieve such speeds so theyre all fine

This post has nothing to do with the speeds.

We're using the graphs to have some kind of evidence of tracking performance. And we can see it through the deviation from the curve.

the finalmouse curve in the OP is way too smooth for a ~6400fps sensor with 500hz polling

can you make some plots of long medium speed swipes (so that the graphs shows a plateau instead of a peak) for the finalmouse?

Sure. I'll do it in a few days when I get my replacement mouse.

this is what i mean:

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

if you look carefully you can see there are some dips every 6 samples

but the magnitude of the dips is only 3-5% off the curve traced by the adjacent points.

the 3310 sensor has a max framerate of 6500. let's suppose the finalmouse's 3310 actually runs at 6400fps. at 500hz usb polling rate, you'd expect some usb frames to have motion that represents the sum of 13 frames of motion, and some usb frames that represents the sum of 12 frames.... and those should show up as dips of ~7-8%

so it makes no sense to me how the dips are so much less

edit: just looked through a few more plots from the ocn thread

still makes no sense to me. sometimes the plot looks completely smooth (like the one in the op) and sometimes it looks crazy. probably due to the surfaces used. but i think, on any surface, the sensor should track reasonably well at medium speeds (~1m/s)

those dips are probably related not to the variable movement per usb frame but to the mouse speed related to the physical sensor size and frame rate i.e. variation starts to occur when sensor physical movement speed is so high that the movement derived from 2 sequential frames gives noticeable error.

idk about this mouse but for the other mice i tried (g100s,g302,aurora) the variations are pretty much perfectly accounted for by the model i have in mind

for instance g302:
http://i.imgur.com/LNjw1KC.png

but for the finalmouse's behavior in those mousetester plots from ocn, probably the crazy fluctuations are actually noise

so i was looking at g502 mousetester plots from ino's review on ocn:

http://cdn.overclock.net/6/6d/6de297cb_hn7g9Bd.png
http://cdn.overclock.net/7/79/7903a868_JEYQbVy.png

these are very clean and the ratio between the two sets of dots is exactly 13/12. which, given my simple analysis that assumes the microcontroller only adds data from the sensor, means that the 3366's framerate is ~12500! but i'm not so sure about this

now look at this plot, also from ino's review but for 800dpi at 500hz
http://cdn.overclock.net/f/fc/fc7dff51_Ffrlc9H.png
and look at the plot for the finalmouse
http://cdn.overclock.net/3/36/364dab07_Finalm...lent-1.png

they're ridiculously similar..... with the peak having groups of dots which look like / / /
and the right shoulder of the curve looking a little staggered
the left shoulder doesn't show the dips in the g502's plot but it could just be hard to see.
and the relative size of the fluctuations are more or less the same for the two mice in those plots.

so maybe both the g502's 3366 and finalmouse's 3310 run at ~12000-13000 fps? but the 3310's datasheet says that 6500 is the maximum.

Here: http://oi57.tinypic.com/dpffa0.jpg

But this one still looks defective on fast swipes: http://oi58.tinypic.com/2pqth1e.jpg

can you do at 1600dpi? at 400 it's mostly quantization noise

http://oi57.tinypic.com/m7gvw1.jpg

http://oi62.tinypic.com/2wd33b9.jpg

thanks... ya those have ~3-5% fluctuations
i have no idea......
either
1. the sensor actually runs at ~12000 fps
2. the sensor runs at ~6000 fps and does some non-trivial processing to reduce the fluctuations (which doesn't mean lag)
3. i'm missing something entirely

also has anyone else noticed that the wmo has a sleep mode? when you stop moving it, the led strobes at 600hz.

i think that's pretty solid proof that no one actually cares about ~1ms of input lag

I've noticed that when I stop moving my IME 3.0, an LED turns off.

for the wmo it doesn't turn off, it just gets darker as it's strobed at a low duty cycle
probably the same in your case

Yea, that could be the case too.

Not sure if that causes input lag. The dimmed LED probably provides enough illumination for initial movement to be registered normally, because we don't accelerate the device as fast where full brightness is needed to get properly interpretable frames.

That said, I always wondered what it'd do to mice performance if we had the option to lock framerate at maximum and overdrive the LED/use stronger LEDs as per lumen. Same goes for overclocking the microprocessor or disabling clocking mechanisms if there are any.

I agree with you though that the MouseTester graphs are very useful if interpreted correctly. Polling stability, speed response, count creation variance, malfunction and framerate behaviour, indications of smoothing etc. are things hardly derivable from other methods. And while the results are affected by the PC and not purely represent the mouse performance, I think it's worthwhile to come up with ways to properly utilise the software to evaluate mice in a comparable fashion.

it's not exactly dimmed. it becomes strobed at 600hz with a low duty cycle...

in a strict sense that adds something between 0 and 1.6ms of additional lag for the microcontroller to register initial movements.

but yea if you do a quick estimation to see how long it even takes for a human hand to move enough for a count to be registered at 400dpi, you'll see that it doesnt really matter... so nvm about what i wrote: "solid proof that no one actually..."

Oh, I see. What's the standard duty cycle and where did you derive that info from?

Strobing must be at least equal to framerate though? Or is there no strobing, i. e. continuous illumination in standard mode?

i took a 1/50 exposure image and moved the camera while it was being taken

ill take another picture tonight to show you

in standard mode, strobing, if there is any, should be matched with the sensor framerate (~6000 or 9000) which makes it pretty much impossible to see with a camera... maybe ill check with my photodiode later

Just did the same with a 1kfps camera. Does indeed flicker in low duty (turns off for 1 frame/1ms, could be less) and shows no detectable strobing in standard duty.

Read a few lines about pulse duration modulation. Constant current supply versus on/off cycled supply. So yeah, should be constant illumination in standard duty.

Finalmouse can't do 1k hz?

Not yet, but they might change that soon.

What makes you think they might?

They said so in the OC thread.

kinzu v1 http://imgur.com/dsnBi9H
and savu http://imgur.com/h3KMnoW

kinzu has nice curves :D

That's misleading, she is a lying bitch with no linear behavior which is hard to handle. Despite the looks, you should look elsewhere for a reliable gaming partner

Kinzu felt pretty controllable to me, just had to lower my sens...

Kinzu has both positive and negative acceleration. The pos. accel kicks in very early, maybe that's why "had to lower my sens".

kind of, I only felt positive accel, probably wasn't flicking hard enough.

Please elaborate on how a mouse can have both positive and negative acceleration. Is it situational or random or something else?

Situational, first pos. accel at moderate speeds, then neg. accel near the malfunction speed, which isn't that high

thx

i had one but then sold it, i kinda liked how it played on low sens but couldnt play on higher sens

most mice look pretty nice at speeds that low when you don't zoom into the graphs. also depends on 125/500/1000hz

this program shows mouse smoothing?

Bottom of this post: http://www.overclock.net/t/1535687/mouseteste...t_23400791

http://www.overclock.net/t/1481639/logitech-g...iew-by-ino
Look at the 800 dpi graph at 500hz. Mind you FinalMouse 2015 is locked at 500hz. The graph are both the same therefore your claims are just a rambling of a clueless idiot who can't read graphs.

http://www.overclock.net/t/1541751/logitech-g...t_23694822

It's true there are things that mousetester graphs don't show, but overall so far tighter graphs correlate with better ingame performance.