TOM
Super ModeratorOldschool OC.at'ler
|
K.... aber wenn ich zum Geburtstag verklagt werd schick ich euch die Rechnung :P
"Introduction
First of all I want to point out that this is a rather technical-oriented article, and for those of you who's only interest, when it comes to mice and hardware, is in making sure everything is optimally configured, and have no further interest in why certain occurrences regarding mice exists, I might as well tell you right away that this text isn't for you. Instead, those of you who feel that you fit in with this description might just skip right ahead to the end, and read my little conclusion. But, provided that you do have an interest in how hardware in general, and in this case that including your mice, works and why the thing now commonly referred to as "negative acceleration" occur, you will most likely find at least parts of this article enlightening.
In how the current mice setup/interface looks like it all comes down to two factors limiting how much information can be processed, and how many times a second mice and computer can do this. First of all the optical sensor of the mice has to process images, and after that the mouse has to send the information gathered by the sensor to your computer, in this case I will use USB as the interface for this throughout the article. Anyway, first out is the optical sensor.
For starters, let's look at an older logitech-sensor with 800 dpi (dots per inch, one dot = pixel, which is vital to remember). This one particular sensor scan a surface the size of 22x22 pixels, and this at the frequency of 2300. Regardless of what direction you're moving the mice, the technology works in the way that it always has to have 15 overlapping pixels from one "shot" of the surface to the next. To simplify this we assume that we only move in one direction, let's say sideways on your mousepad. In doing this our initial picture of the surface is 22x22 pixels, and since were only moving in one dimension/direction, we can say that the picture taken is 22 pixels, in sideway motion. The next picture taken by the sensor must have 15 pixels "in common", eg overlapping, with the picture it took before. Hence, every new picture can move as much as 7 pixels forward in our sideway motion, since 15 out of our original 22 always must be the same as in the previous picture. How many pixels can we cover in one second without "missing" anything? The optical sensor of this mouse had, as stated above, a frequency of 2300. This means it takes 2300 "pictures" of the surface every second, and since we were only moving in sideway direction, and already know that for every new picture we can leap 7 pixels forward, we get a maximum of 2300x7 pixels of movement, equaling 16100. In the beginning of this paragraph it was stated that this older logitech sensor had a "dpi" of 800, effectively meaning it can read 800 dots/counts/pixels per inch. So, what is the maximum distance we can travel during one second without our sensor skipping any of these 800 dots per inch? This we solve by dividing the maximum amount of pixels processable by the sensor with 800. 16100/800 equals 20.1", or roughly 0.5m/s. This speed isn't at all impossible to reach with fast mouse actions, so clearly the mouse will be subject to missed pixels if you move to fast. And, ladies and gentlemen, this is the reason for "negative acceleration" (the correct word would off course be retardation but that is not the issue here), since you expect to move your pointer proportional to the speed you are moving the mice you will feel like the mouse is slowing down when it just cannot read any more dots no matter how much faster you go. 0.5m/s is NOT fast enough for most people. With this in mind, let's skip ahead to a newer sensor, to see how this one fares.
The new MX sensor and USB
This sensor is the well-known MX-sensor, scanning an area of 30x30 pixels at 5250hz, and has the precision of 800dpi. If we ASSUME (yes that's right, I'm assuming a value in my article without any real facts for this, but since I'm assuming something which isn't even better than a previous sensor the only thing that could happen is that I'm wrong in a positive way, and that this sensor is even better than my calculations to come suggest.) that this sensor always need 15 overlapping pixels, we now get a maximum of 15 "new" pixels instead of only 7 as in the previous example. The scan rate has also inscreased from 2300 to 5250. Let's calculate the total amount of processable pixels for this sensor, using the same method as above; 15x5250 = 78750, a lot more than the older sensor (16100). Lets divide this number with 800, since it still has the dpi, and we'll get the maximum amount of inches we can move during one second without skipping any dots/pixels: 78750/800 = 98.4", or nearly 2.5m/s. This value is about 5 times bigger than with the older sensor, and 2.5m/s is a really FAST movement, something you really does not reach even if you move your mouse very fast. What conclusions can we draw from this? Well, first of all I believe nearly everyone has heard of the problem with "negative acceleration" with MX-mice, while these calculations show otherwise. Clearly, it really isn't the optical sensor of the MX-mice that causes this. This takes us to the next out of the two before-mentioned factors limiting mouse-information, namely the mouse sending information to your operatingsystem/hardware.
As I said in the beginning I choose a USB interface for mouse handling, I could as well have choosen ps/2; that really doesn't matter, as long as we're consistent. How does this "transfer mode" work, then?
First of all we have the frequency of the mouse sending information to the computer, which is set for 125 using USB. Everyone of these updates consists of 8 bits, and for those of you who doesn't know this, one bit is just one binary sign, e.g 1/0. With a binary system of 8 bits you can create 2^8 combinations. But, we will only use 7 bits for our calculations since one of these bits always tell the computer if we are moving vertical or horizontal. Hence we are left with "only" 7 bits of code that the mouse can tell movements to the computer with. Each packet therefore consists of 2^7 different combinations of "counts", which in this case is basically exactly the same as pixels. 2^7 = 128, so every one of these 125 updates per second can tell of movements up to 128 pixels. With these numbers we can translate how many pixels/counts we can send from mouse to computer during one second. 125x128 = 16000. If we use a similar way of thinking as we did when looking at the optical sensor, we can divide these 16000 pixels with out 800 dpi to get a maximum progressable number of inches per second; 16000/800 = 20", once again roughly 0.5m/s. This fits "perfectly" well with the older logitech sensor, which also maxed out at 0.5m/s. The problem is, off course, that we already drew the conclusion that 0.5m/s just isn't enough for fast moving gamers. With all this being said we are now able to see that the possible 2.5m/s that the MX mouse is able to handle will never be used since our limiting factor lies in the transfer of information between mouse and computer. Let's try a mouse with 400 dpi instead: Since this usb-interface has the same number of updates and the same packet size regardless of what mouse (except one, as you will see later) we can use the same numbers, and just change 800 dpi to 400. 16000/400 is double the amount of 16000/800, and as such we can move our mouse at an almost fully acceptable 1m/s, compared to 800 dpi and 0.5m/s. This is the SOLE reason why "negative acceleration" is so much more noticable with 800 dpi, and that is also off course why MX-mice used at 400 dpi works just as well as an microsoft mouse at 400 dpi. Negative acceleration has, as proven here, nothing to do with the optical engine of the MX-mice, and neither with drivers. One thing possible to do to amend this to at least some degree is to use ps/2 at 200hz, since that increases the maximum number of pixels being transferable every second by 60%.
Conclusion and final words
Now to my little "conclusion" that I recommend all of you who wasn't interested in this in the first place to read.
Logitech has presented us with a new mouse, Logitech 510, which, besides having even a bit better optical engine than the original MX (which, at 2.5m/s, is fully adequate anyway), a much more interesting feature. Instead of using an 8-bit interface it uses 12-bits, which changes things dramatically. First, reduce one bit for direction, which leaves us at 2^11 = 2048, a whooping 16 times more than the 128 of the older system. Instead of doing all the above mathemathics again, we can, since pixel transfering power is proportional to counts per update, see that for 800 dpi we will have 8m/s instead of 0.5m/s as maximum speeds, and 16m/s instead of 1m/s for 400 dpi. Now, at last, we will most likely be rid of all occurences of "negative acceleration" and problems with 800 dpi. With this new interface it will, at last, be the optical sensor that limits how fast we can move our mice, since the transfer interface now AT LEAST can handle movements at 8m/s for 800 dpi."
|
sonst fürs spielen ms intelli optical 
Anmeldung