Blur Busters Forums

First off, I'd like to apologize if this idea is not new or if this exact device is already in use somewhere and has been shown off on this forum. I don't spend a lot of time combing this forum, but I have done a decent amount of research on this website in the past. The idea for it is very simple and I have been very surprised I have not seen it before, especially with YouTube channels like Battle(non)sense having 100,000+ subscribers and using such manual methods involving LEDs wired to input devices and high-speed cameras.

I have created a USB device and paired software and discovered today that the entire idea of "external input latency testing" is already patented(https://patents.google.com/patent/US20150097803A1), and I do not believe I will be able to license my idea or sell my own hardware.

The system I created sends a signal via USB, and when my software receives it, it changes the color of a black rectangle from black to white for a short duration, allowing the light sensor on the USB device to detect the change. The USB device then displays the amount of time that process took on the attached LCD display. It is a very neat gadget that I was hoping to be able to manufacture very inexpensively and give people a new way to tell whether their system was up to snuff or not. The exact method for this test is nowhere near perfect(lots of reason I'm sure we'll discuss), but I think it would be great to get it in consumer's hands.

Here is a quick demo: https://photos.app.goo.gl/25B13NpJUjgxEzuk9

The delay(in milliseconds) is shown in the bottom left corner of the LCD. I have since made the flashing white box in the middle of the command console much smaller and moveable to any corner of any monitor. I can also run it in 32 bit DirectX9 games(only Fallout:NV so far...), but the drawText function I'm currently using makes it act as a lightsource in and it is hilarious.

Sorry for the video and explanation quality, but I have been working on this project during every spare second I can find for 3 weeks and after discovering it's already patented I am feeling a bit crushed and irritated. If you guys want to see more videos of it in action just let me know.

I believe the patent linked above could be defended against with the claim that it is too abstract, but I do not have the financial backing or competency to do so. I am contemplating making this project open-source, but I have not decided yet. If you guys have any advice on what you believe I should do, please share.

Well, that patent date is after the leo bodnar tester came out, and mostly seems to deal with touchscreens. Is there a specific part of it that you're worried about?

There are also a couple implementations similar to your device on this forum:
viewtopic.php?f=10&t=3005&start=50#p22634
viewtopic.php?f=10&t=1381&start=310#p23272


In any case, yes the patent system needs an overhaul, with a sane standard for obviousness.

Hey Sparky, thanks for the reply.

There's a European patent that looks to have prior art that is more similar to mine, and yesterday I saw where the patent holder for the patent I linked had claimed priority over it(but I can't find it now of course...).

Here's the other patent:https://patents.google.com/patent/WO2017067874A1/en

I actually just found the Chief's post of a project in one of those threads, and it looks to be almost exactly the same as my project and is 6 years older. Maybe I can get in on their project.

Chief Blur Buster wrote:In 2012, I developed an input lag tester under the same principles (Photodiode connected to an Arduino connected to a computer).



It uses the same photodiode, connected to an Arduino, and then connected to the computer by USB cable.

I put it on the back burner while doing other projects, but I was able to achieve incredibly accurate results in a superior way than Leo Bodnar, top/center/bottom, at all possible refresh rates. Also, since then, I was able to reduce USB cable lag error margin to less than 0.2ms via a better Arduino-compatible microcontroller that had buffer-flush support for small packets. The big challenge is using DirectX full screen mode, to bypass windows compositing buffer delay.

I have been wanting to bring this to completion. While my device purpose is somewhat different (display focussed, rather than the whole input chain) -- maybe we can pool efforts. Share code, etc, help complete each other's products faster. I'd love to have BlurBustersSCOPE a complete project in the Blur Busters repertoire. Send me a PM.

Skew, please send me a PM or email [email protected] first.

Thanks!