G102/G203 Acceleration - Page 3 - Overclock.net - An Overclocking Community

Forum Jump: 

G102/G203 Acceleration

Reply
 
Thread Tools
post #21 of 165 (permalink) Old 12-26-2017, 09:37 PM
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Quote:
Originally Posted by dontspamme View Post

I was able to replicate the issue in Quake Live [raw input], using my G102 with updated firmware.

Can you do right-to-left swipes as well and see if the issue is the same. I have a hunch that it might not be accel but slightly misaligned lens.
M1st is offline  
Sponsored Links
Advertisement
 
post #22 of 165 (permalink) Old 12-26-2017, 10:16 PM
New to Overclock.net
 
SmashTV's Avatar
 
Join Date: Sep 2014
Location: Innovation
Posts: 1,678
Rep: 55 (Unique: 43)
Quote:
Originally Posted by 2shellbonus View Post

Made a video. 8000 dpi firmware on a g102

Rep for this.

MX518 Legendary
Logitech G603 (91g)
Allsop Raindrop XL
SmashTV is offline  
post #23 of 165 (permalink) Old 12-27-2017, 12:42 AM
New to Overclock.net
 
Lurrie's Avatar
 
Join Date: Dec 2017
Posts: 47
Rep: 1 (Unique: 1)
Quote:
Originally Posted by M1st View Post

Can you do right-to-left swipes as well and see if the issue is the same. I have a hunch that it might not be accel but slightly misaligned lens.

I just got home from my trip. It's almost midnight, I'm pretty pooped, and I have a bunch of things I have to do before hitting the sack (mainly to do with unpacking and getting stuff ready for tomorrow), but I checked real quick. Acceleration is still there when moving from right to left. Pretty much the same amount, identical to left-right movement. Haven't tested vertical accel yet, but I imagine it'll probably be the same. I'll try mousetester tomorrow or the day after depending on how busy/tired I am. I have no idea how to use mousetester, though, or how to interpret the graphs(?) it produces, so if someone could give me a quick ELI5/TLDR of what I should do to get readable results, that'd be awesome. If not, I guess I'll just figure it out myself. ¯\_(ツ)_/¯

EDIT: Okay, never mind. Damn. Guess I'm on my own for this one. tongue.gif
Lurrie is offline  
Sponsored Links
Advertisement
 
post #24 of 165 (permalink) Old 12-27-2017, 03:13 PM
New to Overclock.net
 
wareya's Avatar
 
Join Date: Jun 2015
Posts: 1,699
Rep: 74 (Unique: 43)
oh man... redface.gif
wareya is offline  
post #25 of 165 (permalink) Old 12-27-2017, 05:41 PM
New to Overclock.net
 
Lurrie's Avatar
 
Join Date: Dec 2017
Posts: 47
Rep: 1 (Unique: 1)
UPDATE: Not to throw more **** into the garbage fire, but I just tried it with my G900 and it displays exactly the same behavior. What the **** is going on? What am I doing wrong?

UPDATE 2: HOLY **** I REBOOTED MY PC AND NOW THE GRAPHS ARE NORMAL. *****. GUYS. DO YOU KNOW HOW MUCH I GOT YELLED AT OVER THESE STUPID CRAZY WONKY GRAPHS??? People sayin I don't know *** I'm doing... lmao. I mean, they're not wrong, but... That weird-ass bug totally wasn't my fault. How was I supposed to know it was just glitching out for no reason, and that a simple reboot would fix it? >:'(

Anyways, now that the issue is fixed, I have some actual graphs for you... Not that I have any idea what they actually mean, but. Here they are.












I have no idea if these graphs show any acceleration, since, again, I've no idea what the **** I'm doing with this software, but there you go. biggrin.gif
Lurrie is offline  
post #26 of 165 (permalink) Old 12-27-2017, 09:35 PM
New to Overclock.net
 
Manak1n's Avatar
 
Join Date: Apr 2016
Posts: 32
Rep: 7 (Unique: 5)
First, what we're looking for:
This plot shows the X vs Y count of mouse input. This means it's basically just tracking your mouse movement. This is essentially a graphed version of the fast-swipe slow-return test for acceleration (like if our sensor was a pen on paper). If we see the the returning line overshoot the origin and go into the negative region, we have negative acceleration. If we see it not reach all the way to the origin, we're experiencing positive acceleration. Of course, there's a margin of error due to imperfect horizontal movement (Ey dude with the cool mouse rig, mind doing some mousetester plots? It'd look great and eliminate this variable!). My plots are 7,000 counts long and we see -4 count net difference and +20 count difference (explained below), meaning a max acceleration of 0.3%. That, to me, sounds like it's within the margin of error.

These are some plots I just took with my G203, I'll explain them a bit. All are at 600 DPI 1000Hz.
Here's a plot of the x/y of a G203, fast swipe right, slow return. If you look at the first image, it looks like there's a HUGE amount of acceleration present (look at where the other line leaves off, roughly 400 counts on the X axis).

If, however, you enable lines on the graph, you see more detail. Mousetester truncates the points to a lower resolution, so the last large dot isn't always the last sample. Showing lines includes the more fine details. I have no idea what the details of this behavior are, but I do know if you zoom, you can see more detail.

Zooming in (click and drag a region with the mouse wheel), we can see we horizontally overshoot the start point on the X axis (due to experimental error; it's a negligible -4 counts).


Second test, same sequence. First with the dots only, we see what looks like acceleration (albeit much more subtle).

Enabling lines shows we're much closer to the origin.

Zooming in, we see a difference of roughly +20 counts. This is within margin of error considering a total 7,000 counts each way.


So two things I'd like to test: one, let's enable lines on the graphs so we can better see what's happening, and two, let's zoom in a bit so we can see the actual count difference. It's clear that my G203 is fine, but there might be a few things to explain what's happening. A preemptive guess I have; occasionally the G203 stutters and doesn't sample correctly. I'm not sure when this occurs (i.e. what movement speed/settings), but I recall seeing it before. I think I have evidence to support this theory, but unfortunately my sister is using my G203 right now so I can't check. Rather than acceleration, I think this might be some sort of polling stability issue? We'll have to use a different graph type to check that. This would be a much better explanation though, as it would explain why some people experience it and some don't. Additionally, such a thing could very possibly be affected by the max CPI bump from 6k->8k.

Edit: whoops, images in the wrong order.
Manak1n is offline  
post #27 of 165 (permalink) Old 12-27-2017, 10:11 PM
New to Overclock.net
 
Lurrie's Avatar
 
Join Date: Dec 2017
Posts: 47
Rep: 1 (Unique: 1)
Wow, this is incredible! Thanks a ton, man! Really helps a lot for helping me figure out how I can test this stuff better ^^"

Well, anyways, now that I know what I'm looking at, I can conclusively say that there IS acceleration on the G203.

G203 tests (with lines enabled and zoom-ins on each one):












And now, to once again check the accuracy of the methodology, here are some G900 tests with the same methodology:













I did exactly five tests with the G203, absolutely no cherry-picking here. On the other hand, I did six tests with the G900, had to throw out one because I swiped crooked and the line was too diagonal for me to stomach. (For the record, though, final xcount was only off by one, so no acceleration or deceleration on that test - as expected.)

Some notes of interest: The G203 has a consistent acceleration of between 100 and 150 counts. Assuming an average swipe length of 4000 counts, this is between 2.5% and 3.75% acceleration. So not that far off from my original estimate of 3%-5%. The G900 is awe-inspiring in its consistency and accuracy. According to mousetester, xcount on the first four tests (five if you count the one I threw out) was off by between 0 and 3. This degree of precision on a swipe and track-back over 4000 counts in length is simply incredible. The fifth (sixth tongue.gif) test shows xcount being off by 21, but that's well within margin of error for a 4200-count swipe (0.5%).

Honestly, the most surprising thing out of all of this, for me, was how startlingly accurate this seemingly very sloppy and prone-to-human-error testing methodology was. For five out of six swipes to be within 2 or 3 pixels of the origin point - with two being pixel-perfect (xcount off by 0) and one being within 1 pixel - is simply incredible. I would have assumed at least a 10-20ish count standard deviation considering the sloppiness of the testing methodology, but no. Apparently it's accurate to within a hundredth of an inch or so. That's very surprising.

Anyways, there you go. G203 8000 DPI firmware acceleration confirmed.

P.S. @SmashTV, thanks for suggesting I use mousetester, even if you were a little aggressive about it. This is honestly wayyyyyyyy better than Paint when it's working properly and isn't glitching the fukc out at least. Like, by miles. Damn.
Lurrie is offline  
post #28 of 165 (permalink) Old 12-27-2017, 10:32 PM
New to Overclock.net
 
2shellbonus's Avatar
 
Join Date: Jun 2011
Location: Moscow, Russia
Posts: 694
Rep: 41 (Unique: 33)
Erm, my video above shows no acceleration on a g102 with 8000 dpi fw.

"It's all fun n games till someone looses an eye. Then it's just fun you can't see" - James Hetfield, Metallica

2shellbonus is offline  
post #29 of 165 (permalink) Old 12-27-2017, 10:55 PM
Overclocker
 
JackCY's Avatar
 
Join Date: Jun 2014
Posts: 10,077
Rep: 340 (Unique: 241)
That's good to hear, hard to see from video when we don't see the stop on left end. Acceleration is not so hard to check anyway, set a start point, swipe fast away, then slowly move back if it doesn't arrive at the same spot then there is either acceleration or some tracking issues. The rig you have helps for sure with keeping it accurate and repeatable.

Meanwhile it will take some time to others to realize that counts are not the thing to look at. Especially with this mercury sensor if I remember right. Most modern sensors adapt dynamically based on speed of movement at how fast they poll, report and so on and so forth. What really matters is what you get when using it, not some counts and such.
JackCY is offline  
post #30 of 165 (permalink) Old 12-27-2017, 11:21 PM
New to Overclock.net
 
M1st's Avatar
 
Join Date: Jun 2015
Posts: 809
Rep: 35 (Unique: 27)
Plotting ycounts vs xcounts can only tell than you're not moving the mouse in a straight horizontal line. If you did, ycounts would be at zero at all points. These graphs just show that the method is flawed.

If you wanna measure accel correctly, you'd need xcounts (or xvelocity) vs time, and turntable setup where you can set the speeds.

I've no clue why you've been asked for mousetester plots in first place. Imo without precise speed and angle control they're useless in this case. Well maybe they're useful for troubleshooting purposes to check if there is something else wrong.
M1st is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off