PC timing problem

you can tell that something is happening with the backlight off. the picture is black on black, but some outlines are still visible.

yeah, that's why I suggested messing with the image data in the VGA cable (while leaving the framing signals alone)

For a one-off use a CRT monitor if you need those milliseconds.

You might be close if you call OnPaint then Set RTS on a hardware serial port. You might have to set the task priority if the time wobles around a bit.

If someone is willing to try Set RTS low, write display buffer, OnPaint, Set RTS high. One problem is Onpaint is called when a window is moved, but I don't think it matters in their case.

Linux?

Cheers

Oh, I saw the words "PC" and "laptop" and I guess I assumed we were talking about a laptop here. A PC basically means "x86 laptop" to me these days, I can't remember the last time I saw a desktop PC in someone's home. I guess they do use them in offices sometimes, but I see them less there, too.

So ah yeah, I guess it's not as simple if you're trying to control an old external display. Some monitors and adapters support "Data Display Channel" which likely would provide similar direct control over the backlight brightness without having to change the raster/route through the GPU hardware:

A 100Hz CRT takes 1/100th second to scan a raster. That's 10 millisecods.

NT

Sounds like a just a little CPLD, to me. The "seriousness" depends on the resolution. A 4K video signal is going to take a rather fast FPGA.

The pixels are delayed only a few microseconds from the VGA connector to the phosphor. the dead time during retrace is an unwanted feature however.

Back in the old daze (1980's), i wrote an interpreted BASIC program that would FDX communicate at 1200 baud AND print all at the same time; IBM said that 1200 baud one way was not possible, that 300baud would work. Above should give you a rough idea that 1mSec would be easy (under the proper conditions).

You said very little about the video conditions / requirements. Fer eggzampel, continual look at a video screen and create a trigger on some specified image movement/change? Source of video? web-based, file based, serial port, ??

Sympel-minded scheme: program looks at a serial port for (video) file input and generates trigger pulse at serial port. This is FDX and no PC is required; a one-shot looking at signal data line (the "video" signal) can generate the pulse in microseconds.

So, how KISS are the requirements?

the serial port USB or internal is fast enough, the issue is the video capture.. that is where the bottle neck is..

We have OR software we wrote many moons ago at work to monitor the motion of a few machine functions without making any connection to it the machine.. The camera sits at a high angle..

The pc has a internal video capture card with a direct memory video capture that is accessable via host application.. it allows the rest of the PC to function without lag..

Using direct X or or accessing the memory is the way to go for fast processing of a live image. Do not use any USB cams for this if near real time is needed.

Turning the IO's of a serial port on/off is simple, you need to have the port open at all times in exclusive mode.

Also, you can format the output data to form a serial stream of data using a shift register each time a bit is shifted in, this allows you to stream the bits in 8 bit format..

In a loop using a timer you can build a byte and send it to the port..

Jamie

...

...

Hi John

Frankly, I don't think that the various video latencies involved will give you a 1 ms total timing budget.

Modern LCD monitors are some complex beasts, they generate their own screen update timing. What you send on the VGA/DVI/HDMI port is no longer synchronous with the LCD "on the glass" drive signals. Especially if the input signal is analog (VGA), the monitor will, after digitizing it, store large chunks and run it through a lot of processing (resize, anti-alias, filters for various "enhancements" such as edge sharpness) before buffering the whole frame in order to be able to output it to the LCD at some potentially unrelated LCD-specific frame rate, which might not even be publicly documented anywhere.

So you have 2 areas of non-synchronous behavior:

1. in the graphics card (memory write by a driver vs. video output)
2. in the monitor (received video signal vs. LCD panel refresh)

At least Nr. 2 is not under your control, even if you decide to write drivers, plus as soon as different monitors are used, timing won't be repeatable any more.

You can use the photodiode trick, but this assumes that the image arrives at the monitor in whole rather than starting somewhere at a random line of the screen, progressing to the last line and then finishing the remaining part from the top. The starting position won't likely be under your control, as won't be the exact time that the LCD panel will take to refresh (plus the frame takes longer than 1 ms).

Additionally, the liquid crystals in the LCD itself typically have longer than 1 ms response times plus the response times are voltage-dependent (depend on the content of the picture) and asymmetric (relaxation can be considerably slower than electrostatic alignment), so going from dark to bright is not the same at going from bright to dark, and the actual levels (both absolute and relative) of "bright" and of "dark" also affect timing. The time constants involved are on the order of single digit ms, but this already eats the 1 ms budget.

Since quantity and series production are both presumably not an issue, a more likely approach to reach 1 ms timing may be a hardware hack of the monitor itself. Rather than controlling the content of the video stream with precision timing (thwarted by monitor buffering and LCD refresh) it should be much easier to control the LED back light.

LCD TVs, and presumably monitors too, tend to have circuit boards for power and for video. The power stuff has 2 or 4 layers and cheap PCB technology as it needs neither BGAs nor controlled impedances, while the video stuff is more complex and costly per PCB area, so they keep the area of the video board to the minimum. The drivers for the back light LEDs tend to be on the power board, not on the video board, and the connection, again for cost reasons, uses the fewest number of wires possible. Often, there is only one single wire that controls the LED state as well as their brightness by using PWM. Hacking a small board with an AND gate into this circuit as well as some ESD protection for good measure should be technically possible (as well as a mounting an SMA jack somewhere).

Whatever generates the timing, could then distribute the same signal to the new "light enable" port on the monitor and to the other gear.

Dimitrij

P.S. Just recently there was a thread on sci.electronics.repair that dealt with light-related issues in TVs and hacking them to get the maximum brightness reduced. Maybe somebody from there can suggest monitor-related info too.

Killing the backlight is definitely the way to go, but some PC graphics hardware and monitors have a a one-wire interface routed along with the display signal for the monitor to report its capabilities to the OS and for the OS to control the display brightness, independently of the GPU and display hardware. I'd try to get my hands on one of those and see if doing it all via software was fast enough before I started hacking into a monitor!

Really doubt you would get 1ms timing of any sort from a Windoze machine. USB latency is at best 1ms. Image load from a disk will be several msec or more.

But I would the thinking about doing it the other way.

Have a trigger, even a manual button, and drive the external circuit from the button. At the same time use that to send a 'next file' command to an image handler like Irfanview to put the next image from a batch onto the screen. A bit of juggling with delays between the signal going to the 'next image' system and the external device you want to trigger would probably help to get it synchronised.

Delays of the order of tens of msec are probably a bit out of the normal for you !

Hi,

Convert the images into video files with one of the audio channels in the video file used for the trigger signal.

Change the purpose of the original idea to instead be to provide a feedback signal to sync the audio and video, and then proceed to solving the original task.

cheers, Jamie

Yes, later posts (or at least, posts that I read later) seem to suggest that. Still, it is pointless to consider timing that is faster than the screen can actually handle, or to measure timings to a resolution that is just noise. So 100 millisecond timing would be too rough for measuring reactions, but 10 millisecond timing should be accurate enough and at the limit for a good gaming screen. Windows game engines should cope with that, combined with USB 2.0 peripherals for input/output.

No, they don't. The timings are large fractions of a millisecond rather than small numbers of microseconds, and they don't get those timings over long distances. The speed of light is only 300 m per microsecond - it imposes limits.

However, it is certainly true that you can reliably get much faster timing than a millisecond on PC-type hardware. But you don't use Windows for it, and you don't try to show pictures on a screen.

I *think* one of the "Freesync" type options together with a monitor that claims 1ms response (as some gamer monitors do) should guarantee that all the image is simultaneously updated. The symptom the former deals with is image 'tearing' which is partial update in the presence of fast motion, probably relevant to this application. AFAIUI, Freesync forces the monitor to sync to the graphics card frame update.

--sp

I'm not sure what you have read in this thread and what you *haven't* read. There are at least two viable ideas on the table. One is Larkin's initial idea of using a photocell to *measure* when the image appears (dependent on the monitor presenting an image all at once, so may still have an issue of partial image exposure) and the other idea is to modulate the back lighting which may be much more responsive, in particular if it is LED based. In a laptop the backlight modulation may work perfectly or may suffer from software delays. In a desktop monitor there may be a need for a hardware modification, but has the potential to be an otherwise perfect solution with

ATI all in wonder video cards have Hardware video display. What this means is, the PC is not doing any work at all displaying the image. When you activate the interface you have a choice of software or hardware rendering. The hardward display is totally done on the video card. The capture mode allows for the grab of the current image in a raw data stream to your app in dma pages. The only issue with this is, doing a PRINT screen will not capture the image.

ATI are not the only ones that make these things.

Jamie

I don't think this is viable, for millisecond timing, precisely because as far as I know monitors do not present the whole image at once.

Switching backlighting like this is much more realistic way to show a picture very rapidly, and getting 1 ms timing accuracy should not be a problem for the hardware. It could still be a challenge if you are trying to use the Windows PC in the timing, but not for external hardware (a microcontroller that turns on the backlight, then measures the time until someone presses a button, for example).

I still see it as pointless resolution if people are involved, but I am not the customer here, and the customer is always right!

It is not pointless if you are trying to *measure* the responsiveness of the eye or other aspects of perception. Neurons are capable of conveying images to the brain pretty quickly. Then there are many aspects of how the brain interprets the images. If you want to measure someone running the 100 meter sprint, you aren't going to use a watch that is only capable of 1 second accuracy even though it takes some 10 seconds to run.

If you don't know the range of what you are trying to measure, I don't think