How to Set Up a Repeatable Peripheral Test at Home

Two people test the same mouse at home and reach opposite conclusions, and the usual explanation is that one of them is wrong. More often both are right about what they measured and neither measured the same thing. The difference is not care or intelligence, it is whether the setup holds everything else still while one variable changes.

Repeatability is a property of the method rather than of the equipment, and it is achievable with ordinary things. Building a rig that changes nothing except the device under test is the whole project, and it takes an afternoon.

What does repeatable actually mean here?

It means that measuring the same device twice produces the same answer within a tolerance you have stated. That is a stronger claim than accuracy, and it is more useful, because comparisons only need repeatability. A rig that is consistently wrong in the same way still ranks devices correctly.

Stating the tolerance matters. Without it there is no way to tell whether a difference between two devices is real. Knowing your own spread is the single most valuable number a home rig can produce.

Repeatability also requires knowing what you are holding constant. Every uncontrolled variable adds to the spread, and the spread is what limits how small a difference you can detect.

Which variables matter most?

Surface, position, cable arrangement, host load, display mode and time of day. Each of those can move a measurement, and together they account for most of the disagreement between independent tests. None of them is difficult to control.

Host load is the largest and the most often ignored. A measurement taken while the machine is doing something else is measuring something else. Defining a load condition, even a simple one, removes a lot of noise.

Display mode matters more than people expect, because processing modes add delay to the visual endpoint. If your measurement ends at a pixel, the display is part of the instrument and it has to be fixed like any other setting.

What does a minimal rig look like?

A fixed surface, a mechanical guide for movement, a marker for the start point, and a camera that can see both the device and the screen. That is enough to compare two devices on the same day, and it fits on a normal desk without permanent changes.

The guide is the important part. A straightedge or a simple rail turns a hand movement into something closer to a machine movement, and that is the difference between a spread you can interpret and one you cannot.

Mark everything. Tape on the desk showing where the device starts and where the pad sits means the setup can be rebuilt later, which is what makes measurements comparable across weeks.

How many samples do you need?

Enough that the median is stable, which for most home setups means several dozen runs. Below that the spread dominates, and a difference you think you see is probably noise. Above a few hundred, returns diminish quickly.

A practical method is to run a block, compute the median and the spread, then run another block and check that both agree. If they do, you have enough. If they do not, you need more, or something is not being held constant.

Recording the raw values rather than just the summary makes this much easier later. A list of numbers can be re-analysed when you change your mind about what to compute, and a single average cannot.

How should you handle outliers?

Keep them, and report them separately. An outlier is often the most informative data point, because it represents the worst case a user will actually experience. Discarding them produces a flattering and misleading figure.

Separate genuine outliers from mistakes, though. A run where the guide slipped or the camera missed the start is not data, and it should be noted and excluded rather than silently dropped.

The clean way is to decide the rule before looking at the results. Deciding which points to remove after seeing them is how a rig quietly becomes an instrument for confirming what you already believed.

Does the order of testing matter?

Yes, because conditions drift. Testing device A entirely and then device B entirely confounds any drift with the difference between them. Alternating in small blocks cancels most of that drift out.

A simple pattern works well: a block of runs with A, then B, then A again, and so on. Comparing the two A blocks tells you how much drift occurred, and comparing A with B uses only nearby pairs.

This costs nothing extra and it removes one of the most common sources of false conclusions. It also makes the result robust to the machine warming up, which almost every rig experiences.

How do you keep the host condition fixed?

Decide what the machine is doing and make it the same every time. The simplest choice is as idle as you can make it, with the same applications closed and the same background tasks stopped. Write the list down.

Avoid running anything that touches storage or the network during a block, because both produce irregular load. A transfer or a sync in the background will show up in the tail of your distribution, and you will not know why.

Check that nothing scheduled fires during a session. Updates, backups and scans all run on timers, and a measurement taken during one is not comparable with anything else you have collected.

What should you write down?

The device identity including firmware version, the surface, the port, the display mode, the host load condition, the number of runs, and the date. Those seven items let you reproduce a measurement and they let someone else judge it.

Write them before you start rather than after. Recovering the conditions from memory later is unreliable, and a measurement without its conditions is not really a measurement at all.

A plain text file per session is enough. The value is in having it at all, not in the format, and a folder of these becomes genuinely useful after a few months.

How do you know the rig is working?

Measure the same device twice on different days and compare. If the medians agree within your stated tolerance, the rig works. If they do not, something is not being held constant, and that test tells you to find it.

This control run is worth doing regularly, particularly after changing anything on the desk. It is the cheapest way to catch a rig that has quietly stopped being repeatable.

Run it at the start and end of any long session as well. If the two controls disagree, everything measured in between is suspect, and knowing that is far better than finding out later.

Is a home rig accurate?

No, and it does not need to be. Absolute accuracy requires calibrated equipment and a controlled environment, and neither is available on a desk. What a home rig provides is a consistent way to compare, which is nearly always the actual question.

Stating this honestly in any result you share matters. A comparison from one rig is meaningful; an absolute figure from one rig is not, and presenting it as one invites exactly the confusion this method is meant to remove.

The exception is where a home measurement reproduces a known reference. Checking your rig against a published figure occasionally is a good way to confirm it is measuring what you think it is.

What mistakes are most common?

Changing more than one thing at a time, testing in one long block rather than alternating, and discarding inconvenient outliers. All three produce confident results that do not survive a second look, and all three are easy to avoid.

The second most common mistake is measuring something other than what you care about. Timing the report when you care about the screen, or the screen when you care about the device, produces a number that cannot answer your question.

Deciding what the endpoint should be before building the rig avoids this entirely. It is a five-minute decision at the start and it determines whether anything you measure afterwards is useful.

How should results be shared?

With the conditions attached and the spread included. A number without a spread invites people to compare it with other numbers that have no business being compared, which is how the confusion in this area keeps reproducing itself.

Say which rig produced it and whether the same rig produced the comparison. Single-rig comparisons are trustworthy; cross-rig arithmetic is not, and saying so saves a lot of argument.

Include the raw values if you can. Someone else may want to compute something different, and a table of numbers is far more useful than a summary you cannot check.

What is worth doing after the rig works?

Run every device you own through it once and keep the results. That set becomes a personal reference that makes every future comparison far easier, because you are comparing against your own baseline rather than someone else’s.

Then re-run it occasionally. Devices change with firmware, surfaces change with wear, and a reference that is years old is describing equipment you no longer have.

The habit matters more than any single result, and it is the thing that separates a measurement from an impression.