PC timing problem

Embed a pattern into the video signal that would have an arbitrarily low probability of accidental triggering (enough contrast that it wouldn't occur naturally). Intercept the RGB directly and compare digitally.

What is "looking at" the still image?

I.e., the image never APPEARS "instantaneously" so what point in time do you use as a reference for your "accurate to a millisecond"?

And, you've specified the *accuracy* but not the magnitude of the delay/skew between that "image appearance reference point" and the "serial port pin". I.e., 47268.3ms later? (+- 500us)

Does the PC have to retain its functionality as a PC? Or, can it become a dedicated "image displayer with serial port stroker"?

Does it have to run on ANY PC, any version of windows, etc.?

Run the video into (or out of?) "sleep" mode?

So, what's the problem? Just put any old video out to a screen, with the backlight boogered so it only flashes on at the critical time.

All modern displays have slow-changing pixels, but the LED backlight can be altered faster than a millisecond.

Sure, but that's a serious project.

A person. And maybe my photodiode in the corner.

Let's say when the image is all on the screen. That suggests that the optical sensor wins. I guess the video signal sent to the LCD screen, and the screen refresh, are asynchronous. There is probably a way to synchronize video ram loads with screen refresh, but I'm not volunteering to write any device drivers.

How about 1 millisecond? That's their suggestion, but then they are not electronic guys, and their idea hasn't been tested yet, so nobody knows what really matters.

I suppose it can be dedicated for the duration of one experiment. So maybe just detecting non-black VGA signals could work. That would be fairly easy, Altoids box afternoon sort of stuff.

It only has to work. I assume that we'd use something that they have, or maybe they could buy a cheapish laptop.

That might work, if I can get into the backlight circuits somehow. A serial port pin could switch the backlight on and off and simultaneously trigger the external gear.

I suspect that's your only option, you're not going to get 1ms precision from the LCD part of the screen.

NT

turn the screen off load image turn screen on assert serial port DTR or some other control signal

If the PC does not have a serial port or parallel port (too many these days) you could probably trigger something on USB within some reasonable time frame. Isochronous endpoints do a transfer every 125 uS. I'm not a big windows guy so I'm not sure how you would send a message to a device that enumerates as a ISO endpoint. You could probably do it with one of the FTDI chips. I think they do ISO end points. Hack one of those usb to serial gadgets.

Maybe do a tone burst out the audio port. Do some level detector to manage the noise threshold, any signal above that triggers the device.

How about doing it the other way around?

Active TV goggles connected to the external hardware and the PC always showing the picture. Then the sync can be absolute and realtime.

You could do that and add a particular sequence of black white flashes to indicate arm/disarm the external gear eg Manchester code.

I'd still have an external big on/off switch though.

So let's say you use just 4 bits in your sequence, requiring 4 frame scans. Let's optimisticly imagine that all other system delays are zero. What frame scan rate do you need to get 1ms system response time? Where do you get such a screen?

NT

o:

what images? with what program? why? what they want to do exactly? does it has to be a Win PC or can be anything else? A raspberry pi for exam ple. Write down a Python program that will visualize an image on screen and togg le a GPIO pin is kind of easy, I bet that there is already some code out th ere that does the trick.

Bye Jack

You misunderstand the purpose of the encoding is to allow the screen to enable and disable the external hardware that is acting on the image appearing flash signal so that you can do it all in software.

Someone else suggested a RaspPi which seems ideally suited to the task.

This looks like some test for the reaction of a human (?) when presented the image.

No ideas, just some pitfalls.

As others have already pointed out, the picture on the monitor will not be anything like real time. First the update from the video generation circuitry to the monitor will have a jitter of at least the frame rate (16ms @60Hz). In addition the reaction time of the LCD comes on top of that. That will also vary with temperature.

But this timing jitter will also be valid for the test person. Anything where the picture is changed on the screen will have this jitter for the test person. Measuring in the 1ms range does not make any sense for me. The only possibility I see would be to manipulate the backlight. But then the reaction of the test person will be influenced by the change in brightness, too.

No I don't misunderstand that. It's rather clear it won't hit the required timing spec.

NT

It's not a sampling problem. Display of video data is, but a single event is a single sample anywhere in time, so does not need an obscene refresh rate, say. There was no mention of absolute timing of display-event or external-event, just that the two are close together.

It seems to me that should be fairly easy (esp. for you) to sample a pixel in the VGA raster, trigger off vertical sync.... might need some tuning to work reliably.

perhaps use an aux output (USB? serial?) to both blank both the RGB signal and trigger the hardware?

Why do you wanna sync one trigger to the other trigger? Sync both the laptop clock and the external gear trigger device (like say an R Pi running Linux with a GPIO pin) to an accurate external clock/timecode, like GPS.

Or use one device RTC as the master and the other as the slave:

Under Linux "vbetools dpms off" and "vbetools dpms on" will turn the display backlight on and off just about instantly. Just trigger the GPIO pin and a two-line script that turns the light on and off on one from the timecode from the synced clocks.

Ask them to bring along this person who can view an image in 1 millisecond, or who can see a skew of 1 millisecond between an image and the output.

Then ask them to bring along a screen that can show an image in 1 millisecond. Maybe ask them to show you a 1000 frames per second movie on it, and ask their test user to distinguish between a 1000 frames per second film and a 500 frames per second film.

Then explain to them that a good rule of thumb for "appears to be simultaneous" for a single event is a timing within 100 milliseconds, not 1 millisecond. For high-speed action (like a fast computer game),

Once they are in the land of reality, even a Windows PC should be able to set an output and show a picture with much less than 100 (or even 20) milliseconds skew.

It seems like they want to put the cart before the horse. Perhaps you'll get some mileage out of a description of how a typical Olympus endoscope "plops an image" into a patient's electronic medical record on a PC that runs Windows.

There's two cables between the endoscope and the PC. A 75 ohm cable carries the analog video signal. A null modem cable carries the shutter trigger signal.

The camera in the scope live streams an analog video signal to the physician's monitor. An auxiliary jack connects the video signal to a device similar to an AVerMedia C039 DVD EZMaker 7, which uses a USB port to live stream the video to the PC.

The handle of an endoscope typically contains several buttons. One of the available buttons is programmed to act as a shutter release. The null modem cable sends a button down/up event to the PC.

The physician pushes the shutter release button to capture the image on the live stream at that moment. The flow is "press button" then "capture image."

They seem to want to do the opposite. They want to "capture image" and then "trigger event."

Thank you,