Overclock.net › Forums › Components › Mice › Mouse from Steelseries - Rival 100
New Posts  All Forums:Forum Nav:

Mouse from Steelseries - Rival 100 - Page 44

post #431 of 1498
Surface-dependent or not, the malfunction inherently is not 1.5m/s. Stuff like not being optimized for a variety of surfaces (or CPI, etc.) is actually what makes the MLT04 so raw/puristic I have to assume.

I said lower end is buffer limitation, which does scale with polling rate. Upper limit should be data path clipping, i. e. the USB descriptors were set not with the maximum capabilities of the sensor in mind and so it simply can't transfer as many counts per report (at < report/2ms) as it can interpret.
post #432 of 1498
assuming a reasonable tracking surface and reasonable image focus, perfect control speed depends on
1. framerate
2. base dpi (i.e. physical resolution of the pixel array * lens magnification)
3. how far the dsp searches for correlations. and this is limited by the size of the pixel array. e.g. if you have a 30x30 array you can't search for correlations separated by 40 pixels since there's no overlap if you shift a frame by that much.

example: 6500 frames per second / 800pixel per inch * 0.0254 inch/meter * 30pixel max search distance = 6.19125 meters/second

malfunction speed is different and can be pretty much anything. for instance you can have a sensor, for which, if it doesn't know what's going on, just outputs the last previous valid data. then you'd have infinite malfunction speed. not that that's very useful though...
and then of course, 8bit integer problems can limit things further, which is what happens to mlt04 at 125hz. but for mlt04 at 1000hz, there's no such limitation or any similar bottleneck.

<--below is my speculation-->

for avago/pixart sensors however, it seems that the dsp is especially eager to output something even if the correlations are weak. so we get all sorts of crazy data when swiping faster than the perfect control speed.
for mlt04, the reason its pcs is so low is because of 3.

as for the recovery speed which HAGGARD mentioned, i'm pretty sure it's because modern sensors are a lot more predictive. if the previous frame had 20 counts of movement, it's not going to search for correlations corresponding to 5 counts of movement in the current frame. thus when it's malfunctioning it returns to the default search domain around 0 motion. so that's why it doesn't start tracking again until you slow down significantly. since computational power is so limited on these dsps, this sort of thing is necessary to achieve high tracking speeds
for the mlt04 presumably it doesn't do this and the correlation search is the same for every new frame.
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #433 of 1498
I was hitting some sort of malfunction or neg accel speed in game with the Kana, so would probably have to change the whole way I aim to use the WMO. Unless I could overclock usb in win 8.1
post #434 of 1498
>I said lower end is buffer limitation, which does scale with polling rate.

can you explain where that would lie in the sensor -> mcu -> cable chain

because i'm pretty sure that if some "buffer" were capping out, then either 125hz and 500hz would be the same, or 500hz would have more like 4x the malfunction speed, or the true malfunction speed of the mouse would be hit (which it is).

the real reason that it's hitting a cap at 1.5m/s instead of, like, 4m/s, is probably because it uses a binary sensor array instead of an 8-bit one. you say a binary array is why it feels so responsive. I know that's wrong because I understand how signal processing works. Literally all having a binary array does is introduce posterization -- quantization -- which eliminates information that can be useful when other dimensions are scarce (correlation overlap area) in return for possibly (and I really mean that: the following statement is speculation) being excessively responsive to initial movements.

We already know that the MLT04 has weird correlation properties (i.e. diagonals). There's no reason to believe that some strange buffering bug is the reason that it malfunctions easily. That would not be surface-dependent. The much easier explanation is that -- and guess what, this is compatible with the information that the malfunction properties depend on the surface -- the binary sensor array becomes harmful at high speeds, which it obviously does if you have any idea how ICS math works. You can even see it cause jitter on soft pads like the QCK and less on glass ones like the G-Pad.

Indeed, look at what the DTP Soft does. Oh my god.

3TeKLP1.png
Edited by wareya - 9/25/15 at 8:50pm
post #435 of 1498
Quote:
Originally Posted by wareya View Post

the real reason that it's hitting a cap at 1.5m/s instead of, like, 4m/s, is probably because it uses a binary sensor array instead of an 8-bit one. you say a binary array is why it feels so responsive.
i think that would just make it less accurate and not any more responsive...

blah i wish someone who from pixart/avago/agilent/stm would come here and clear everything up
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #436 of 1498
>i think that would just make it less accurate and not any more responsive...

It might make it more responsive, but it would always make it less accurate yes

It might make it more responsive because small movements show up as full pixel changes instead of possibly being masked out by noise for that frame

Either way I'm just referencing another post of his about the MLT04 from a while ago
post #437 of 1498
well to shift an entire pixel, a lot of pixels flip so it doesn't really matter if a small movement causes an entire pixel to change. just means that a lot of other small movements result in no change at all, whereas with a grayscale sensor you would always have some small shift in every pixel's level for small movements.

it would make things much simpler computationally though

also i'm fairly sure that the diagonal line thing is because it uses an algorithm similar to the cross deadzone thing we discussed last time. i can't think of any other way to achieve that... plus i think single pixel movements feel funny with mlt04.
Edited by qsxcv - 9/25/15 at 9:03pm
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #438 of 1498
Quote:
>also i'm fairly sure that the diagonal line thing is because it uses an algorithm similar to the cross deadzone thing we discussed last time. i can't think of any other way to achieve that...

it could theoretically do diagonal correlation and cancel it out with the axial correlation to get this kind of smoothed diagonal axial correlation

you just need more counters and a bit of math
Quote:
>plus i think single pixel movements feel funny with mlt04.

interesting

but it should still loose out by a count in count countings, even when latency is eliminated as a factor, if it's using a deadzone
Edited by wareya - 9/26/15 at 8:56am
post #439 of 1498
just get one of these
http://www.amazon.com/Custom-X-Y-Linear-Translation-Stage/dp/B00QXEDQP8/ref=sr_1_6?ie=UTF8&qid=1443240877&sr=8-6&keywords=xy+translation+stage

and we'll know for sure tongue.gif

maybe the deadzone recenters if the motion exceeds 2 pixels or something
Edited by qsxcv - 9/25/15 at 9:20pm
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
main
(15 items)
 
old
(14 items)
 
 
CPUMotherboardGraphicsRAM
4770k maximus vii impact nvidia gtx 970 crucial ballistix tactical 16gb 
Hard DriveCoolingOSMonitor
crucial mx100 noctua nh-c14 windows 7 ultimate sony cpd-g520 
KeyboardPowerCaseMouse
kbp v80 matias quiet silverstone sx500-lg ncase m1 v3 logitech g100s with mcu replaced by teensy2.0 
Mouse PadAudioAudio
allsop raindrop xl chord mojo hifiman re-600 
CPUMotherboardGraphicsRAM
i7 920 evga x58 sli le galaxy gtx 460 crucial something 3x1gb 
Hard DriveCoolingOSMonitor
intel 330 180gb scythe kotetsu windows 8.1 pro sony cpd-g520 
KeyboardPowerCaseMouse
logitech k120 silverstone st75f-gs nxzt h440 evga torq x5 
Mouse PadAudio
allsop raindrop mobo 
  hide details  
Reply
post #440 of 1498
Quote:
Originally Posted by wareya View Post

>I said lower end is buffer limitation, which does scale with polling rate.

can you explain where that would lie in the sensor -> mcu -> cable chain

because i'm pretty sure that if some "buffer" were capping out, then either 125hz and 500hz would be the same, or 500hz would have more like 4x the malfunction speed, or the true malfunction speed of the mouse would be hit (which it is).
The internal memory buffer used to store count data to be periodically called by the host. At 125Hz (i. e. 8ms buffer flushing interval) the PCS caps out at 1m/s. That's the "lower limit" I was talking about introduced by buffer overflow. 500Hz and beyond you hit the 1.5m/s cap which then obviously must have its root somewhere else (because increasing polling rate then does not also increase PCS). And again, I am talking about perfect control speed, not malfunction speed.
Quote:
the real reason that it's hitting a cap at 1.5m/s instead of, like, 4m/s, is probably because it uses a binary sensor array instead of an 8-bit one. you say a binary array is why it feels so responsive. I know that's wrong because I understand how signal processing works. Literally all having a binary array does is introduce posterization -- quantization -- which eliminates information that can be useful when other dimensions are scarce (correlation overlap area) in return for possibly (and I really mean that: the following statement is speculation) being excessively responsive to initial movements.

[...]
Look, I'm not trying to challenge your understanding of these matters, all I am saying is that it's a fact that the MLT04 does not malfunction at 1.5m/s but somewhere at around 3m/s. That's on most surfaces I have tried them on btw. It knows a maximum amount of counts it transfers per report (32 at 1kHz) but doesn't malfunction until speeds beyond that, so from there the conclusion has to be that the perfect control cap is introduced somewhere else, likely in the transfer specs. And apart from the mathematical nature of the correlation method, not optimizing a sensor for a variety of tasks/surfaces/CPIs also means you don't have to compromise (i. e. anti-jitter, normalization, increased angle error correction, illumination properties, what qsx speculates about modern implementations being more predictive etc.), which is what I as a layman think makes the tracking feel so unaltered. Whether the MLT04 "makes sense" or measures up to modern sensors technologically is another question; I'd agree the fact that manufacturers stray away from whatever made the MLT04 what it is means there's something inherently incompatible with what they are trying to create (be it high PCS, CPI, maybe even the diagonal tracking).
Just your critique is wrong. Malfunction properties with the MLT04 are not inferior to modern sensors, I'd argue the opposite. The PCS cap is unfortunate, but 1.5m/s is still perfectly sufficient for even low sensitivity FPS.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mice
Overclock.net › Forums › Components › Mice › Mouse from Steelseries - Rival 100