3366 mice have different framerates: maximums are either ~8500 or ~11500
edit: original title was "g pro (3366) running at lower framerates?!? aging or are g pro's weird?"
this is not due to aging and not specific to g pro's because my wired g403 that i've barely used since 2016 behaves the same.
~8500 max framerate:
g pro 3366
g403 wired version
~11500 max framerate mice:
g502 (at least the firmwares before 2016 were ~11500. not sure about current firmware, if there is a newer firmware)
g900 (pretty sure i remember it was ~11500)
g903? probably identical to g900
@anyone with a 3366 mouse in the "not sure" list
could you reply to this thread a mousetester log (preferred) and/or plot of a reasonably fast swipe (like around 1-2m/s)?
i'll tell you what framerate yours is running at. set the dpi to 12000 or something high to make it easier for me
i dare anyone to try to find a post before this thread was created, claiming different tracking feel between mice in those two categories (e.g. between g pro and g303)
i certainly cannot tell a difference but maybe someone else was able to in the past
mousetester plots where i first found out about this:
different malfunction speeds:
8600 framerate g pro malfunctions around 7.5m/s. i'm sure this is a malfunction because it's outputting garbage toward the end.
11700 framerate g403 wireless malfunction speed is at least 9.5m/s (or did i just reach the end of the mousepad? idk.)
i can estimate the framerates by observing the ratio of the dots.
for example if there are 10 counts of motion per frame,
a framerate of 2500 with 1000hz usb would give output like 20,30,20,30,20,30
a framerate of 5700 with 1000hz usb would give output like 50,60,60,50,60,60,50,60,60,60
just think about bit a little and it will make sense
more details and worked out examples:
assume 1000hz polling
suppose in mousetester you see a region with roughly constant velocity but bouncing between two numbers
344, 387, 387, 344, 387, 344, 387, 387, 344, 387
387/344 = 1.125, which happens to be exactly 9/8
from this we can infer that the reports with 387 counts correspond to 9 frames of data and that the reports with 344 counts correspond to 8 frames of data.
here, there are 4 points with 344 and 6 points with 387. hence in this interval, which correspond to 10ms of motion, there were 4*8 + 6*9 = 86 frames. divide to get a framerate of 8600.
now in practice the velocity might not be constant and there is noise.
more realistic data might look like this:
304, 347, 357, 327, 381, 343, 397, 405, 370, 425
if you look at a plot, there are two distinct sets of data, each of which by itself forms a smooth line. the reports [304, 326, 343, 370] is one set and the reports [347, 357, 381, 397, 405, 425]
we will make the ansatz that the each point in the first set corresponds to X frames of data, and each point in the second set corresponds to X+1 frames of data.
to determine X, we can look at the ratio of the data. for instance, 3rd, 4th, and 5th points are 357, 327, 381. what would the 4th point be if it had X+1 frames of data? we can estimate by interpolating between the 3rd and 5th points: (357 + 381)/2=369
now 369/327 = 1.1284
this isn't exactly the ratio between two consecutive integers, but it is certainly closer to 9/8=1.125 than 8/7=1.143 or 10/9=1.111
the rest of the analysis and frame counting is as before, and we get a framerate of 8600 again.
a better way to determine the ratio is to take the image of the plot and scale it by 8/7, 9/8, 10/9, etc... and seeing which ratio gets the lower "line" of the scaled plot to align best with the upper line of the unscaled plot. here "line" means the points from one of the distinct sets of data as mentioned above.
too busy to check forums as regularly pm me if i forget to respond