PC timing problem

On consideration yes. The idea of getting the PC to do the syncing is back to front. Use a bit of hardware to sync the PC. EG use an Arduino Leonardo (nay sayers remember it is a small project. The Leonardo can emulate a PC keyboard. Have the Leonardo monitor one of it's own digital input pins. Press the button, the Leonardo sends a series of key presses down the USB to some software in your fav version of turbo basic, the program sends back a caps lock or num lock signal (thats optional for better syncing)and the Leonardo fires off it's outputs to do what ever you want.

A modern LCD monitor will digitize the analog VGA signal, pack that into ram, and scan the ram into active matrix pixels at some different density and speed. That will be pretty asynchronous. I gave no idea what a high-speed film of a screen update might look like; it may be a mess. A little experimanting with a couple of photodiodes, placed here and there, would be interesting.

I wonder if playing a movie would be different from throwing up a single jpeg image. The drivers might try to sync a movie better somehow. This could well be very different on different PCs.

Now, when they don't have a lot of money and depend on free engineering, they may have to live with 10s of milliseconds of trigger jitter.

Switching a display backlight would work, if the supply is fast and I can figure out how to get into the backlight supply, or even replace the backlight supply. Lot of work.

ugggh you don't have to get into the backlight circuits, on laptops it's an ACPI DMA device, you can flip it on and off near instantly by flipping a bit in the memory-mapped IO

I don't believe there is much that can be done internally to a computer to sync the display to a control signal to such a short time frame. First, there is the issue that frames (in a standard display) are only changed every 16.7 ms. The display itself is scanned during an update and internally the display has buffers and the interface has delays (the interface delays many not be significant). The point is there are too many variables that can impact the timing of the display an order of magnitude beyond the goal.

Some type of display sensor is the only way to coordinate a display with a trigger signal without digging into the display electronics or having details of the display that generally aren't available.

Maybe they are exploring human perception at this level and need equipment faster than human perception in order to measure it accurately?

Not talking about updating the display through the GPU hardware or altering the raster. Just flipping the LED backlight and off. It's usually an ACPI system device or some kind of hardware register that doesn't at all involve the graphics driver in any way.

If there's some small latency through doing it from software it's likely measurable and consistent.

It's an ACPI device that sits in memory-mapped I/O, from a shell that has root privileges you can probably flip it on and off with a program consisting of like four x86 assembly instructions.

Can't you just watch the HDMI. VGA, or whatever signal? ...Jim Thompson

the you just have jump through a whole lot of hoops to get around the tens if not hundreds of millisecond jitter from when you get a time slice...

That's been considered, but I suspect what goes into the VGA signals is rescanned/reprocessed a lot before it gets to the pixels on the LCD.

Milliseconds may not be feasible on the current engineering budget.

Does anybody want to do that for us? It's for a good cause.

Is there anything like giveio/totalio for modern Windows?

idk much about Windows, on Ubuntu Linux testing it would be something like:

sudo apt-get install vbetools sudo apt-get install at

echo "vbetools dpms on" | at now + 1 minute vbetools dpms off

I'm pretty sure the "at" time index can be expressed in elapsed ticks since the Posix Epoch or something, if the display PC and the trigger PC/R Pi/whatever have their clocks synced using Precision Time Control to fire their respective scripts at a particular epoch I bet it will get close to the required 1ms precision (whatever the need for that arbitrary figure is)

I get what you are saying, but in a desktop PC is there a communications channel other than the HDMI or VGA connector? Any idea of how a backlight control would operate over these two interfaces? I don't think I've seen anything to indicate if they are using a desktop or a laptop. I do see where John mentioned tapping into the VGA signal which would imply desktop.

Yeah, Ethernet or WiFi. Why bother trying to hack your own interface when you can use PTC to phase lock loop two local clocks over the network with sub-microsecond accuracy

Really? High frequency trading algorithms live or die by microseconds over entire city blocks sometimes and for real we can't flip a display on and off and trigger a pin reliably in a millisecond in the same room?

Den fredag den 23. juni 2017 kl. 04.15.09 UTC+2 skrev John Larkin:

the photodiode sounds the safest bet to get synchronicity. get an usb serial adapter, ftdi or the likes, use on of the control signals to gate the trigger it also give you a 5V supply for the photodiode

Not sure where you are going with this. The problem is controlling when the image on the screen is visible and/or knowing when it is visible. To do that you suggested using the backlight as a shutter to turn off the image while it is being updated (since the update rate is 16 ms), then turning the backlight on using ACPI comamnds to allow it to be seen. In a desktop the PC this requires a communications channel to the monitor. I'm pretty sure the VGA interface provides no millisecond control over the backlight. I don't know what HDMI provides.

Yes, really. Just tell us how to do it.

There's a way around that, with a half-silvered mirror and two monitors, driven with complementary backlight enable signals. Or, two projectors (the lamps in those aren't quick to turn on) with some LCD shutters; probably that could do the deed with mainly COTS equipment behind a rear-projection screen.