Reply
Logi Nu
MySeLfPT
Posts: 2
Registered: ‎01-31-2008

Re: I need help updating g500 firmware.

If you want my honest opinion i had some G5's and some Razer mouses over the years and i am very disappointed with this G500. The mouse DOES HAVE mouse acceleration on X axis but thats not because of the Sensor nor the software. It is because of the stupid laser sensor POSITION. The reason you can not recreate that in labs is because you are probably ignoring the fact that people do not move like robots and there is a wrist rotation associated with the X axis moving. Their hands do not move in a exact straight line. When the sensor is positioned in a central position (like the G5) the sensor is not that affected because it rotates over itself, but with the top sensor position of the laser of the G500 thats quite noticeable resulting in "pseudo-acceleration". This, IMO is only fixable by a refresh of the G500 hardware. Until then this mouse is garbage for me and i wish i could realize that before the 15 days after purchase. Now who will refund me or trade it for a proper decent mouse?

 

A not so happy customer,

 

MySeLf 

Logi Browser
h8m3
Posts: 5
Registered: ‎11-12-2009

Re: I need help updating g500 firmware.

[ Edited ]

i tested in QuakeLive with /in_mouse 2 aka RAW input which is lower level than windows pointer input so that doesnt really matter + also m_pitch 0 so that vertical coordinates dont matter ingame

anyway the settings were 6/11 notch and disabled enhanced pointer precision + so called cheese's accelfix which remove the miserable in-built negative windows accel.

The thing is that any other decent non-skippable optical mouse like mx518@400dpi or razer deathadder have ABSOLUTELY no positive or negative acceleration at the same settings. While all Avago9500 based ones do have this bug. Also im not able to measure if it's either:

1) simply positive acceleration

2) lower speed scaling when moving it slow(so it just registers less distance than there really is when movingf it slow)

Of course the accel is playable since it's very low (5-10%) but still it's kinda noticiable when switching from any other mouse and i'd like this to be fixed :smileytongue:

 

as for dpi and other settings - i havent checked this with really high values so it was 400, 450 and 800 then(at laptop atm, cant give screens) + angle snapping off

 

 

@MySeLf

well i agree that sensor position is weird(has advantages and disadvantages, and i cant say if it's worse or better than most mice do have, it's just different) but it's DEFINITELY not what causes this, i moved it exactly horizontally without rotating and there was accel.

Noy
Logi Browser
Noy
Posts: 7
Registered: ‎11-11-2009

Re: I need help updating g500 firmware.

h8m3 do what post 20 asks (bottom of page 2). Hopefully they'll fix it :smileyhappy:

Logi Visitor
SiberX
Posts: 25
Registered: ‎11-12-2009

Re: I need help updating g500 firmware.

[ Edited ]

 


MySeLfPT wrote:

The mouse DOES HAVE mouse acceleration on X axis but thats not because of the Sensor nor the software. It is because of the stupid laser sensor POSITION.


 

While the sensor position does have an effect on the mouse's response, it will have no effect on acceleration. Whether a sensor is positioned at the top, middle or bottom of a mouse, if the mouse is moved a certain distance/direction and then moved back to the original position at a *different* speed, it should always end up at exactly the same starting spot onscreen. Mouse sensor position does not change this part of mouse behaviour; what it *does* change, however, is the perceptive relationship between horizontal and vertical sensitivity. As a mouse is typically held from the back and pivoted somewhat at the wrist when moving horizontally, a sensor farther from the pivot point will produce a greater translation for a given degrees of wrist rotation. The vertical (or Y) axis is unaffected by this geometrical shift - pushing and pulling the mouse towards/away from you produces the same shift either way. From this perspective, the G500 will generally feel like it moves more horizontal inches onscreen than vertical inches for what you are accustomed to moving the same distance. This can easily be entirely compensated by using differing DPI levels for the X and Y axis. Setting the Y axis to 5700dpi and the X to say, 4000, would give a perceptive feel of a sensor much closer to the wrist.

 

If you don't believe/understand this, translating your mouse sideways with *no* rotation at all then moving it back quickly will demonstrate acceleration on the G500 - as no rotation is involved, the fact that the mouse still exhibits acceleration should prove that the sensor position has nothing to do with it. If you're *really* confused I can whip out MSpaint and illustrate it, but if you think it over for awhile you should be able to realise the situation here.

 

The acceleration exhibited on the G500, however, is very real (and unrelated to the sensor position, which affects only X/Y perceptive sensitivities overall). Testing methodology is very important here, as depending on how the acceleration is created certain testing methods that would otherwise normally be used to check for acceleration will *not* necessarily accurately reproduce the problem.

 

Take, for example, a theory that the increased acceleration only applies while the mouse is changing velocity (from, say, a standstill to a high movement rate) and during the speed increase the sensor tracks poorly; at slow speeds or once it reaches a high velocity it tracks correctly (I am not saying this is necessarily the behaviour with the G500, I am simply attempting to model a case that will produce perceptive mouse acceleration that would be difficult to quantitatively test for). If, during the acceleration period, the mouse misjudges how far it has moved and overestimates, the end result is that after a quick turn, the mouse position is farther than it should've been - felt as acceleration. Now, consider a hypothetical mouse testing station where a mouse sits on a conveyor belt - our intrepid mouse tester runs the conveyor at 1inch/second and sees the mouse picking up 5700 counts per second. He now speeds up the conveyor to 20 inches per second and sees 114,000 counts per second. As the mouse was only tested at steady-state speeds, the behaviour of the mouse while *changing* speeds was not accurately tested, and could therefore fool a tester into thinking the mouse tracks perfectly in all cases. Again, if this point is not clear, I can draw it up for you :smileywink:

 

As such, please make sure the testers use multiple methods for testing the acceleration CharlesB - the "mark a spot, move away slow, move back fast" method often used should, for example, display the acceleration reported on these forums, and is detailed below in accuracy as a suggested procedure. The first method tests the drift for a single move and return, which in the case of the G500 may be insufficient to clearly show the acceleration (especially at high DPI levels). The second, modified method should amplify the acceleration (while changing nothing for a mouse that tracks accurately), but is a bit harder to understand and exectute :smileywink:

 

METHOD 1:

Place the cursor at the left edge of the screen, and mark the left edge of the mouse's location on the mousepad (sticking a fingernail on the pad works well). Then, slowly move the mouse across the screen to the right edge, then quickly drag the cursor back to the left edge of the screen and stop (without overshooting - you can undershoot a bit and slowly move it to the very edge if you want, this won't affect too much if the undershoot is small). If the mouse has not returned all the way to the initial mark on the mousepad, it is exhibiting mouse acceleration.

 

METHOD 2:

Place the cursor somewhere onscreen near the left edge of the screen, but not touching any of the edges of the screen. Mark the mouse's left edge on the mousing surface. Slowly move the mouse to the right (about halfway or two-thirds of the way across the screen) without going far enough to touch the right edge with the cursor. Then, quickly snap the mouse back to nearly the initial position (getting it perfectly positioned is less important than moving the mouse quickly) without going far enough to touch either your mark or the left edge of the screen. Again move the mouse to the right slowly, and quickly move it back (the mouse basically just needs to go slowly one way and quickly the other way a bunch of times without touching any edges or leaving the pad, which will amplify the effect). Repeat this several times, and the mouse should slowly "drift" across the pad, ending up an inch or two to the right after a number of repetitions. If the mouse were tracking linearly at all times, this testing method should not result in any positional shift at all - you should, after repeating this a number of times, be able to move the mouse back to the mark and have it sitting onscreen exactly where you started. As a note, be sure to quickly get the mouse moving at high speed for the leftwards return translation, instead of gradually speeding it up; if the acceleration applies only during quick speed changes, this will make the effect easier to notice.

 

For completeness' sake, I have included a screenshot of my setpoint and windows mouse settings below; the fact is that the mouse exhibits the behaviour with any combination of settings and across multiple operating systems on different computers. For the record, this is Win7 RC 64-bit though.

 

Setpoint+Mouse settings

 

And, as an additional note, thank you for the input and updates on this issue CharlesB - it is greatly appreciated! When trying to contact the manufacturer of another recent high-DPI mouse I tested exhibiting a similar but much stronger effect (although using the Philips 3.5G sensor, not the Avago 9500) they hardly seemed to care. The fact that logitech is willing to investigate is very encouraging!

Moderator
CharlesB
Posts: 4,203
Registered: ‎07-06-2006

Re: I need help updating g500 firmware.

Thanks for the screenshot! Visually confirming the settings make my job easy :smileywink: Anyone else who can do the same, or confirm that they're using the same settings, would help greatly.

 

Quick favor: Could you try UNchecking "Use OS native drivers for speed and accel"? With the setpoint settings at "5" and "0", that's SetPoint's 1:1 movement without accel, and testing this could eliminate any oddities with the Windows drivers.

 

The engineers are aware of the reports from the customers and working on the best way to test and quantify this now (and since those engineers are in Europe, wont be shutting down for Thanksgiving :smileywink: )

Logi Visitor
SiberX
Posts: 25
Registered: ‎11-12-2009

Re: I need help updating g500 firmware.

Well, I have already done that, and like I said it changes nothing - if you *really* want a screenshot of that as well I've attached one.

 

Just to be ultra sure, I retested after applying the settings shown in this image just before taking the screenshot, and the acceleration was for sure still present.

 

Setpint+Mouse settings 2

Logi Visitor
excelx
Posts: 21
Registered: ‎10-10-2009

Re: I need help updating g500 firmware.

please tell the engineers to do the same job as they did with the G9 =)   the G9 has a solid feel when you are gaming/browsing/etc etc

i'm just waiting for logitech to fix the accel problem or else my G500 won't see day light hehe

Logi Rook
MONVMENTVM
Posts: 52
Registered: ‎07-12-2009

Re: I need help updating g500 firmware.

I can confirm the positive acceleration on the G9x. And even the SteelSeries Xai (that uses the same sensor) has this.

 

The strange thing about it is (and that's why I haven't discovered it myself first):It doesn't seem to be some kind of linear acceleration as you would expect. But first my testing procedure:

 

I set the DPI to something low (400 to 800dpi) and place the mouse on the left edge of my mousepad. At the same time the pointer should be on the left edge of the screen too. Then I move the mouse to the right at a high speed, stop and then move it slowly back to the edge of the mousepad, where the pointer should also arrive at the edge of the screen.

 

Now when I use this testing method I generally move the mouse as fast as possible in one direction, as this tests for both positive and negative acceleration or skipping. For the returning movement I use a moderate tempo (not fast nor very slow). And when I do it that way neither the G9x nor the Xai show any acceleration.

 

After reading these posts here and in the Steelseries Blog about the Xai I wanted to try it again and found out when it happens for me. When using the above method you have to move the mouse at a fast tempo in the one direction and _very_ slowly back. So it seems to me to be a problem with slow moves.

 

Maybe this is also related to this pixel skipping bug the G9x had at the beginning on the x-axis. I'll have to try later if there is acceleration on the y-axis too.

Logi Visitor
SiberX
Posts: 25
Registered: ‎11-12-2009

Re: I need help updating g500 firmware.

Excellent observations monvmentvm - I have done some further testing with what you mentioned and can confirm two things:

 

1) The acceleration behaviour is most exaggerated when comparing a *very* slow move with an average-speed move, instead of an average-speed move with a very fast snap turn. Something about the mouse's detection at very slow speeds seems to be the likely culprit

 

2) The acceleration appears with either X (horizontal) or Y (vertical) axis movement - it is not "x-axis only", and basically occurs no matter which way you're moving the mouse.

Logi Rook
MONVMENTVM
Posts: 52
Registered: ‎07-12-2009

Re: I need help updating g500 firmware.

Yep... both things happen to the G9x and Xai (and appearently your G500). Probably it is something Avago has to fix.

 

I guess both Logitech and SteelSeries users and devs are waiting for a fix.

 

At least now I know why I somehow always had a better feeling/precision with my Lachesis compared to the G9x and Xai. Let's hope they get that fixed. For Razer it seems not possible to fix their z-axis problem on the philips twin-eye sensor.