Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

[Mouse Mod HOWTO] Input lag test setup for Rocket League

Everything about input lag. Tips, testing methods, mouse lag, display lag, game engine lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more!

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby HalfwayDead » 28 Jul 2017, 15:26

We did it :D Did the soldering an hour or so ago. When the mouse isn't plugged in the LED also lights up very dimly when the button isn't pressed. This is not expected, right?

Anyway, it works great when plugged in. I forgot to take a picture of the board after soldering but I don't think it's necessary since the unsoldered board + the colouring explains everything. Here is a small imgur album: http://imgur.com/a/oEbkH

Don't try to open up a 19 button mouse :lol: I didn't even try to put the mousewheel back in since I don't really need the mouse and it allowed me to easily get the cables out of the mouse.
HalfwayDead
 
Posts: 20
Joined: 18 Jul 2017, 07:27

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Sparky » 28 Jul 2017, 16:33

HalfwayDead wrote:We did it :D Did the soldering an hour or so ago. When the mouse isn't plugged in the LED also lights up very dimly when the button isn't pressed. This is not expected, right?
That means some of the battery current is flowing through the microcontroller.
Sparky
 
Posts: 529
Joined: 15 Jan 2014, 02:29

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby HalfwayDead » 28 Jul 2017, 17:34

Sparky wrote:That means some of the battery current is flowing through the microcontroller.
Ahh, but I don't have to worry about it? Since the battery has the same voltage as the microcontroller uses.
HalfwayDead
 
Posts: 20
Joined: 18 Jul 2017, 07:27

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Sparky » 28 Jul 2017, 19:52

HalfwayDead wrote:
Sparky wrote:That means some of the battery current is flowing through the microcontroller.
Ahh, but I don't have to worry about it? Since the battery has the same voltage as the microcontroller uses.

I can't really answer that. It depends on how much current is flowing and on the circuitry inside the microcontroller. Safest to turn the mouse on before connecting the battery, but you can look at the microcontroller's datasheet to see how much current the inputs can safely sink/source.
Sparky
 
Posts: 529
Joined: 15 Jan 2014, 02:29

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Chief Blur Buster » 29 Jul 2017, 09:04

Sparky wrote:
HalfwayDead wrote:We did it :D Did the soldering an hour or so ago. When the mouse isn't plugged in the LED also lights up very dimly when the button isn't pressed. This is not expected, right?
That means some of the battery current is flowing through the microcontroller.

If extremely dim (e.g. a few microamps), it's nothing to worry about. It's normal for some mice.

This didn't happen on all my mice, but on some of them, this very occasionally happens at the microamperes league (or sub-microamp level). Sometimes the LED chip barely illuminates; can't see it in a bright/sunny room, need to close window drapes to see. And my multimeter reads zero or almost zero milliamps (numbers resembling 0.00X).

If this is what is happening to your mouse, this effect is generally nothing to worry about. Just leave the battery removed while your mouse is not in use -- only do so for testing, making sure that the circuit works when connected to the mouse.

When I plugged in the mouse, this stopped happening -- zero illumination occured in mouseup situation.

You are ready to plug in the mouse. Does the dim illumination disappear when the mouse is powered?

It's also why I advocate a resistor too for safety's sake despite the use of a coin cell (Bigger the better, I used 330 ohm) as additional guard for unexpected leakage current.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3590
Joined: 05 Dec 2013, 15:44

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby HalfwayDead » 29 Jul 2017, 13:05

Chief Blur Buster wrote:If extremely dim (e.g. a few microamps), it's nothing to worry about. It's normal for some mice.

I'd say it's about 20% of the normal brightness. I tried with 330 Ohms initially but I don't like how dim it is. I'm just gonna only use it when it's plugged in. Yes, absolutely no light when it's plugged in ;)

So I've done a test run and stumbled upon a small problem. The LED seems to take like 1.5 ms to turn on. I am of course aware that the camera is exposing for 1/1250th of a second and therefore if the LED turns on halfway into that exposure time it's going to be half as bright. However, I'm getting a lot of situations where the LED is at (estimated) 20% brightness in 1 frame then 80% in the next one and 100% in the third etc. According to everything online, LEDs should be able to turn on way faster. And I know for sure that it's not the LED because when I press the button on the breadboard then the LED turns on instantly. It's only slow when I press the Razer Naga button.

This, along with some noise made it pretty hard to see when the LED was already on in some situations. Sometimes, there is a long patch of red noise exactly where the LED is. The light seems to be dot shaped so I made myself a rule that any long shape is ignored but sometimes I'm really not sure if it's just noise. I will be trying out the yellow LEDs and probably just getting the LED closer to the camera to fix this.
HalfwayDead
 
Posts: 20
Joined: 18 Jul 2017, 07:27

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Chief Blur Buster » 29 Jul 2017, 13:28

HalfwayDead wrote:I am of course aware that the camera is exposing for 1/1250th of a second and therefore if the LED turns on halfway into that exposure time it's going to be half as bright.

Correct, you figured that out.

HalfwayDead wrote:However, I'm getting a lot of situations where the LED is at (estimated) 20% brightness in 1 frame then 80% in the next one and 100% in the third etc.

That would likely be the mouse button's fault, there are many mouse buttons that have a more gradual resistance increase than others. Time when you see the first LED illumination. It may add a slight error margin as you say.

You can measure this by connecting an oscilloscope to the mouse, and you'll witness a "curve" instead of a "squarewave", this is just a characteristic of some kinds of buttons. It can be quite annoying, and possibly a problem with some of them. This happens very often with old mice, and a lot less often with newer mice.

Is your mouse old?

Old mice often have has button contacts that create a more gradual resistance increase (even over a few milliseconds) because of things like residue and fine metal dust (caused by grounded contacts), or other films of corrosion, or other poor contact. If you ever opened up a very old gamepad, and opened up the contacts, you can notice how dirty it gets inside the button contacts from wear-and-tear, even sealed ones, because of fine-metal-dust-grinding of repeated button-mashing (slamming two pieces of metal together millions of times).

This turns buttons into what behaves as fast-potentiometers sometimes, like a pressure sensitive button, where there's a gradual resistance-decrease (say, over 1ms) rather than a darn near-instantaneous resistance-decrease (say, microseconds). Connecting an old, super-worn clicker-dome button to an oscilloscope, shows more of a curve instead of a squarewave, upon the trigger. If you press slow enough, it may even exhibit pressure-sensitivity too. Or it might click from infinite-resistance to a non-zero-resistance that behaves pressure-sensitively after the click occurs.

In the real world -- once it becomes bad enough, button response becomes erratic (slight press before clicking can cause erratic mouse clicks). But even one year before that happens, your mouse button already is likely slowing down dozens of microseconds from the repeated grinding. The microcontroller within tries to react quickly (debounce filtering can make an old mouse last longer before it begins to malfunction...) but is always imperfect.

(If you're a paid championship player "milliseconds matter" type person -- then it is best to replace eSports computer mice long before the buttons begin malfunctioning, because it may be unwittingly adding a few hundred microseconds of input lag.... But for 99% of people, that insignificant lag of a slightly worn button, doesn't matter)

Anyway, weird behaviors can still happen to certain types of button mechanisms of new buttons too -- but such button mechanisms are kind of unwanted in eSports-quality mice. So I'm assuming -- I'm hoping -- your modified mouse was already at least a few months old (minimum).

For fastest mouse button response, it is better to use a fresher/newer mouse. But if you are testing a heavily-used, press the mouse button harder/faster to minimize this "1.5ms lag" effect you're seeing.

If you're testing a newer mouse, with a fresh mouse button, you are less likely to see this sort of behaviour, and the button click will be more in unity with the LED illumination, vastly reducing error margin to simply your high speed camera's shutter speed.

For even better accuracy, be familiar with rolling shutters.

Most of the time, an accuracy factor of 1 shutter cycle (e.g. 1/1250sec error margin) is plenty enough for input lag tests.

But if that's not enough accuracy, it's possible to work on the error margins:

(1) Fresh/new mouse with fast reacting button. That keeps LED timing with mouse microcontroller timing, as tight as possible.
See above for why old mouse buttons sometimes sort of behave "pressure sensitive" like fast potentiometers

(2) LED on same 'scanline' as screen response you're paying attention to (eliminates camera rolling scan error margin)
Rolling shutter during 1250fps means top edge of camera image is 1/1250sec less lag than bottom edge, so aligning the LED on the same scanline as the screen response you're trying to measure, can improve accuracy even further.

(3) LED brightness calculation (50% brightness = 0.5 frame) -- this is incredibly tough to do, but extrapolatable.
Works best with very squarewave mouse buttons, doublechecked with an oscillscope. You could also illuminate "reference LEDs" on a breadboard (10 LEDs at 10% brightness steps) along bottom edge, as a brightness compare. That can allow you to get 100 microsecond precision out of 1/1000sec (1ms) shutter. However, an LCD display's GtG generates MORE error margin than this, especially considering GtG of a specific color pair can be several milliseconds different than the GtG of a different color pair -- more input lag for specific LCD color transitions, for example.

If you're unsure how to trust it, connect oscilloscope to the mouse button too (which can simultaneously be done with the LED), see how the button looks under an oscilloscope (you want to measure resistance change at approximately 100KSPS (Kilo Samples Per Second) or 1MSPS (Million Samples Per Second) or so -- and scale the display graph to a scale over roughly ~5 milliseconds to show the button curve. Though sometimes you may need different range settings to see the curve more clearly -- depends on quality of your oscilloscope.

It's shocking how a lot of buttons don't behave like square wave!

What error margin are you trying to aim for? 1ms is often good enough error margin for lag benchmarking with 1ms GtG LCD's. 1.5ms button lag from a worn button is a tad high, but you should get far less than that by pressing the button quicker/harder -- and push it within the 1ms error margin typically targeted for in these types of high-speed-video lag tests.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3590
Joined: 05 Dec 2013, 15:44

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby HalfwayDead » 29 Jul 2017, 14:44

Hmm, thanks for the in depth answer. 1ms margin is around what I would be aiming for.

My mouse is kinda old. It's a Razer Naga original edition which was in use for at least 3 years. And I haven't used it in a couple of years. It uses some Razer Omron switch.
I'm not really looking to spend too much money on this so I'd rather not buy an oscilloscope or a new mouse that I might not use. I'd have to find one that I want anyway and then mod it in a way that I can use it perfectly for gaming.
For now I'll definitely try smashing the mouse button harder and see what results I get with that. 1.5ms was just an estimate. Since the amount of pictures it takes to get a full brightness LED is also tied to exposure time it's kinda hard to calculate.

Chief Blur Buster wrote:(2) LED on same 'scanline' as screen response you're paying attention to (eliminates camera rolling scan error margin)
Rolling shutter during 1250fps means top edge of camera image is 1/1250sec less lag than bottom edge, so aligning the LED on the same scanline as the screen response you're trying to measure, can improve accuracy even further.

This got me thinking. I've got a Casio Exilim FH-20 and as it is a consumer grade camera you'd usually expect a rolling shutter for video but I assumed that 1000 FPS cameras would have global shutters anyway.
In my first test I tried 1000 FPS in game, V-Sync off. And I used any response on screen as a reaction. That would, with a rolling shutter, already introduce almost 1 ms of random variance depending on where the reaction happens on screen. And when I use V-Sync then it will always show at first at the top of the image which means, if the rolling shutter starts reading at the top, the results would be on average 0.5 ms worse than random placement. I know it's <1 ms but if I have multiple sources of error adding up then I might end up a lot more wrong than I expect. If I end up with 3 ms of error it wouldn't be that bad but I want to make sure that I know my errors so I don't draw any wrong conclusions from my data.

The result I got in my first test was 14.8 ms with values between 13ms and 16ms which seems incredibly low considering my monitor Acer GN246HLBbid has 10ms of signal processing when used at 144Hz according to prad.de. I don't know if they're perfectly accurate but they seem to know what they're doing. Edit: I forgot to say I repeated it 50 times.
HalfwayDead
 
Posts: 20
Joined: 18 Jul 2017, 07:27

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Sparky » 29 Jul 2017, 15:08

Speaking of worn switches, I did characterize and compare a new switch with one that was worn enough to start malfunctioning when trying to drag stuff. The difference in bounce duration was only a couple hundred milliseconds, but the flight time from the top contact to the bottom contact was 1ms slower on the worn switch.

https://docs.google.com/spreadsheets/d/ ... q8/pubhtml

As for debouncing, I'm still convinced the right answer is using the normally closed contact for latched debouncing. No delays, and you can reliably debounce even heavily worn switches. If you know any mice that use this method, let me know. The problem with basically any other method is that you get a really nasty edge when you release the button(tens to hundreds of milliseconds), way more than when you press it, so you have to add in a whole bunch of delay to avoid an extra click on release.
Sparky
 
Posts: 529
Joined: 15 Jan 2014, 02:29

Re: [Mouse Mod HOWTO] Input lag test setup for Rocket League

Postby Chief Blur Buster » 30 Jul 2017, 20:11

HalfwayDead wrote:This got me thinking. I've got a Casio Exilim FH-20 and as it is a consumer grade camera you'd usually expect a rolling shutter for video but I assumed that 1000 FPS cameras would have global shutters anyway.

Unfortunately not. Sadly, turns out to be a false assumption :(

Rolling shutter effect (1/1000sec camera sensor readout) is why sometimes the high speed video of strobe backlight (at 0:45 into video) have the bottom edge illiminating before the top edge. I believe my high speed camera was doing a bottom-to-top rolling scan, which is why a global-flash strobe backlight had camera rolling-scan interruptions.

Acer GN246HLBbid has 10ms of signal processing when used at 144Hz according to prad.de. I don't know if they're perfectly accurate but they seem to know what they're doing.

They're probably measuring screen centre, VSYNC ON.
The input lag dynamics of VSYNC OFF is very different.

Also, remember, top/center/bottom input lag of VSYNC ON during normal scanout situations (CRT, rolling scan OLED, or non-strobed LCD), the bottom edge is almost one refresh cycle extra input lag than top edge. Centre is half a refresh cycle input lag. That's why Leo Bodnar has tests for both top/center/bottom. Top is good for testing minimum case, center is good for testing average lag (crosshairs).

However, during VSYNC OFF, the top edge can have the same input lag as bottom edge. That is because new frames keep interrupting the scanout.

So prad.de "10ms" screen center may actually be "3ms top edge", for example, depending on lag testing methods. That's why TFTCentral numbers are different from DisplayLag.com -- because SMTT differential resesemble Leo Bodnar top-edge, but DisplayLag is targetting screen centre (average input lag) as that's what the reviewer test standard has been.

Different lag test methods can produce accurate-but-different results. Considering the varied mechanics of GtG lag, measure to GtG10%, or measure to GtG50% or measure to GtG90%, different colors having more lag (e.g. slow GtG pairs, especially dark colors on VA LCDs), the cable scanout lag, the top/center/bottom lag, the lag from strobing, frame delivery (VSYNC ON vs VSYNC OFF), and scanout vs global refresh (e.g. top-to-bottom scan versus global-flash displays like LightBoost).

TL;DR It's hard to compare between different lag testing methods, high speed video versus Leo Bodnar versus SMTT.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3590
Joined: 05 Dec 2013, 15:44

PreviousNext

Return to Input Lag

Who is online

Users browsing this forum: No registered users and 3 guests