Först av allt vill jag säga att det här är en rätt teknisk artikel, och för dig som endast är intresserad av att göra allt så bra som möjligt för dig utan något vidare intresse om varför du gör det skulle jag inte rekommendera den här artikeln alls, du kan i princip hoppa till min korta slutsats i slutet på artikeln, det är i korthet allt du behöver veta. Men, för dig som är intresserad av hur hårdvara, och i det här fallet din mus, fungerar och framförallt varför negativ acceleration uppstår med olika möss faller förmodligen den här lilla artikeln i smaken :). Vidare vill jag även påpeka att det i den här artikeln finns framförallt ett antagande som jag egentligen inte har några belägg för, men som ni kommer att se spelar det ingen större roll. Det gäller pixelöverlappning, och jag påpekar även i det avsnittet att det handlar om ett antagande.



Det finns egentligen två olika "steg" som limiterar hur mycket yta du kan läsa av, och hur snabbt/ofta du kan göra detta. Det första steget är själva optiken i din mus, det andra steget är när musen skall skicka information till din dator, i det här fallet använder jag USB-interfacet som exempel. Vi börjar med att analysera själva optiken i ett antal möss för att se hur själva sensorn fungerar.



Först ut är en äldre logitechsensor med 800 dpi (dots per inch, en dot = pixel genomgående i artikeln). Den här sensorn scannar av en yta motsvarande 22x22 pixlar, och den gör detta med frekvensen 2300. Oavsett riktning du rör musen så behövs det för varje ny bild som sensorn scannar hela tiden överlappas 15 punkter med den tidigare. Om vi för enkelhetens skull endast använder en riktning, låt oss säga sidled på din musmatta (det spelar ingen roll vilket håll egentligen), innebär detta att sensorn först tar en bild som täcker 22 pixlar i sidled, och nästa bild kan som max flytta sig 7 "egentliga" pixlar i samma riktning, då denna nya bild måste överlappa 15 pixlar av den tidigare. Således kan vi täcka 7 nya pixlar för varje avscanning, och som nämnt ovan görs det 2300 avscanningar per sekund. 15 pixlar är egentligen endast en uppskattning, men då detta är en jämförelse spelar det ingen större roll eftersom det viktiga är att vi använder samma värden hela tiden. Hursomhelst, totalt leder det till att vi kan täcka 2300x7 pixlar per sekund, alltså en summa av 16100 pixlar per sekund. Eftersom sensorn vi tittar på använder 800 dpi (cpi om man så vill) räknar vi med 800 pixlar/punkter per inch. Hur många "inch":ar kan vi då täcka per sekund om varje inch är 800 pixlar? Jo, 16100 delat med 800, 20.1 inch. En inch är 2.54 centimeter, alltså kan vi täcka drygt 50cm per sekund, eller 0.5m per sekund. Detta är en hastighet som man utan några större problem kan uppnå över en musmatta, så redan här ser vi att ifall vi skulle dra musen för fort så skulle sensorn inte klara av att läsa alla punkter.



Om vi nu tittar på mx-sensorn då: Här har vi att göra med en sensor som täcker 30x30 pixlar, och scannar ytan 5250 ggr i sekunden, samt med en "dpi" på 800.Om vi antar att även den här sensorn behöver 15 överlappande pixlar, och att vi fortfarande endast rör oss i en riktning, så får vi fram med ovanstående exemplets formel fram att varje scanning här istället kan förflytta oss 15 pixlar framåt (30-15 eftersom 15 hela tiden är gemensamma pixlar). Hur många pixlar kan vi sammanlagt scanna med den här sensorn per sekund då? Jo, 5250x15, 78750 pixlar per sekund, mycket mer än ovanstående exempels 16100. Om vi nu delar 78750 med 800 får vi totalt antal "inch":ar vi kan tillryggalägga under en sekund utan att förlora ens en enda punkts avläsning. Svaret blir 98.4 inch, eller närmare 2.5 meter per sekund. Detta är en rätt avsevärd hastighet, och något man med rimliga musrörelser inte kommer kunna överskrida. Vad kan vi dra för slutsats av det här? Jo, att fenomenet "negativ acceleration", som uppstår av att musen inte klarar av att läsa sina "fulla" dpi varje inch, och till följd av det helt enkelt saktar ner eftersom den tror att den tillryggalagt en kortare sträcka än vad du rört musen, INTE beror på optiken i MX-musen. Detta för oss till nästa del, överföring av information från mus till dator.



Som jag nämnde ovan har jag valt att använda ett usb-interface för musen som exempel. Hur fungerar då överföringen? Jo, först och främst har vi konstaterat att USB har en frekvens på 125hz, och sålunda sker 125 stycken överföringar per sekund från mus till datorn genom USB-porten. Varje sådan uppdatering består av 8-bitar, och för den som inte vet är en bit ett tecken, och med ett binärt system med 8 tecken existerar det 2^8 olika kombinationer. Innan jag räknar ut detta skall jag nämna att en av dessa bitar alltid bestämmer riktning, så således har vi egentligen endast 7 bitars kod som kan berätta för datorn hur mycket och hur musen rört sig. Följaktligen kan varje paket innehålla 2^7 olika kombationer av "counts", vilket i det här fallet blir exakt samma sak som pixlar. 2^7 = 128, således kan varje uppdatering innehålla 128 pixlar. Hur många pixlars rörelse kan vi då överföra från musen till datorn under en sekund? Jo, 125 uppdateringer per sekund eftersom vi pratar om usb, och 128 pixlar per uppdatering ger oss en sammanlagd maximal överföring av 125x128 = 16000 pixlar per sekund. Om vi använder en liknande logik från ovanstående uträkningar runt sensorn/optiken, kan vi härleda att vi skall dela dessa 16000 pixlar med 800, om vi nu förutsätter att vi har en mus med 800 dpi, för att få fram det antal "inch":ar vi maximalt kan täcka med den här överföringshastigheten. Detta blir 20, alltså klarar överföringen ett maximalt antal på 20 inch per sekund, eller drygt 50cm/s, 0.5m/s, vilket stämmer bra överens med den gamla logitechmusens optiks maximala fart. För de äldre mössen passade alltså överföringshastigheten mellan mus och dator rätt perfekt med musens optik, och ingendera av de två faktorerna som påverkar hur snabbt musen kan röras limiterar den andra. Problemet här var ju att 0.5m/s redan var för lite för att klara av de allra snabbaste rörelserna, och eftersom överföringshastigheten mellan mus och dator inte påverkas av musens optik i det här fallet kan vi sålunda dra slutsatsen att med det här USB-interfacet kan vi aldrig få ut de teoretiska 2.5m/s som MX-teknologin är kapabel att klara av. Med 400 dpi på oavsett mus klarar USB 1m/s, eftersom vi fortfarande 16000 pixlar från 125x128, men istället för att dela med 800 delar vi förstås med 400, och får då fram ett inch-värde som motsvarar 1m/s. Det är därför vi inte upplever negativ acceleration i samma utsträckning med 400 dpi som med 800 dpi, och till skillnad från vad även jag trott är det alltså inte MX-mössens optik det är fel på, det är istället interfacet mellan dator och mus som inte klarar av att hantera tillräckligt mycket information. Med ps/2 på 200hz får vi självklart ännu lite högre kapacitet, det är b. la en faktor som talar för att det är bättre i nuläget, förutom det jag skrivit i en tidigare artikel, nämligen synkningen.



Varför skriver jag då den här artikeln? Jo, det är nämligen så att Logitech har presenterat en ny mus, Logitech MX 510, som, förutom en aningen bättre optik (som i sig redan är bra vilket ovanstående text visar; det är ju inte musens optik som i dagsläget limiterar, det är överföringen som är problemet) även för med sig ett helt nytt överföringsystem, där 12-bitar nyttjas per överföring, istället för tidigare 8. En bit går återigen bort för riktning, vi har med andra ord 11 bitar kvar. 2^11 är 2048, jämför det med de tidigare 128. Istället för att gå hela omvägen och sätta in de här 11 bitarna i ekvationen i stycket ovanför kan vi nöja oss med att säga att 2048 är 16 ggr större än 128, och eftersom antalet bitar i det här fallet är proportionellt mot maximal hastighet kommer vi fram till att överföringen kommer klara av 8m/s istället för tidigare 0.5m/s för 800 dpi, och 16m/s istället för 1/ms för 400 dpi.



Slutsats: Logitechs nya mus, MX 510, kommer med all sannolikhet eliminera alla problem med negativ acceleration, och göra det möjligt att spela med 800 dpi utan problem.



Jag vill även passa på att tacka Level52 som hjälpt mig med en hel del tekniska frågor runt detta.