0
\$\begingroup\$

I am currently trying to measure the time it takes from [the moment a flag is set programmatically in software before rendering some graphics] to [[the moment the graphic is actually displayed on the screen]].

Though I have some programming experience, my experience in electrical engineering and its surrounding knowledge is close to nil so please bear with me. I've been told oscilloscopes are often used to measure latencies, and I've seen some examples in which the latency from user input to screen displays were measured. From my limited research, these were usually done by attaching pressure sensors on the user input devices and photodiodes on the screens, and then measuring each with oscilloscope probes. In my case however my starting point of measure is from within software, and even with my limited knowledge I don't think sticking a probe in the computer is the right move. With that in mind, I'm wondering if something like, a USB-based Oscilloscope that comes with its own SDK could help me send something like an impulse from my program, so that I could compare the timing with probe-measured signals (i.e. photodiode)? Is this possible? Or are there better ways to achieve what I want?

I'm aware that general computer operating systems introduce various lags from system scheduling and background tasks etc., because general purpose systems are not built with precision in mind, and because of that my hypothetical software trigger will not be precise. But for my needs a reasonable millisecond-level measurement will suffice, and I believe I can tolerate several milliseconds of error. I'm also willing to take steps to minimize background service/tasks etc. to lower jitters caused by the OS doing what it does.

If you have better setups or ideas that you'd like to point me to, I'd be most grateful. Thanks in advance!

\$\endgroup\$
11
  • \$\begingroup\$ Sounds very much as an XY-problem. What is the actual problem you are trying to solve? \$\endgroup\$
    – Eugene Sh.
    Apr 26, 2021 at 13:56
  • \$\begingroup\$ Your problem is that the scope will have no way to tell that a flag has been set in software. You could try to program some output on an I/O device to indicate that it has happened, but then you are changing the system under test, and there will be a lag between the flag being set and the I/O event, so the measurement you make won't be meaningful anyway. \$\endgroup\$
    – Simon B
    Apr 26, 2021 at 14:00
  • \$\begingroup\$ I am working on designing a cognitive experiment that unfortunately needs to use imprecise software tools running on general purpose PCs. I measure scalp EEG signals in conjunction with behavioral events undertaken by participants. You could see the problem gets worse here, as EEG is extremely time sensitive, and as such for analyses I need to match software events to signal as close to millisecond precision as possible. [continued..] \$\endgroup\$ Apr 26, 2021 at 14:01
  • \$\begingroup\$ [..continued] There are tools that let me log software events with physiological signals under a common clock, but I still need to account for delays such as the time it takes for the stimulus to render on screen etc. \$\endgroup\$ Apr 26, 2021 at 14:02
  • \$\begingroup\$ @inquisitiveck I would rather look at clock synchronization between the stimulus and measurement devices, then timestamping every event of interest. But ideally I would switch to a real-time system, and if must, use PC just for post-processing. \$\endgroup\$
    – Eugene Sh.
    Apr 26, 2021 at 14:04

1 Answer 1

1
\$\begingroup\$

From my limited research, these were usually done by attaching pressure sensors on the user input devices and photodiodes on the screens, and then measuring each with oscilloscope probes. In my case however my starting point of measure is from within software, and even with my limited knowledge I don't think sticking a probe in the computer is the right move

Hmm. If you're not willing to make this input-triggered, then either you have to stick a probe in the computer, or find or make a different output device to trigger the scope. Which will also incur a delay.

One low-tech possibility is to find the HDD LED and wire a probe to that. Set the flag in software and trigger a disk write. Cheap, low but unknown latency.

A second possibility is to use the audio output. The latency properties of these are fairly well documented, because they're important to musicians. This can be made predictable, so you could have a known, fixed 20ms latency. Put a "chirp" out and watch it on the scope.

Various other outputs exist - serial and parallel ports - but these are no longer directly connected to the bus and have an unpredictable latency. Same with things like the legacy PC joystick port (which was itself a latency-measuring device!).

The super deluxe option is to get one of the FPGAs which can represent itself in the PCI memory space. You can write to that memory space, which triggers a PCI transaction, and get close to microsecond accuracy.

The XY option is to GPS-sync your PC clock to as high a degree of accuracy as possible, then time against a GPS pulse-per-second output from a different GPS source.

Mind you, the "beam" matters; even in an LCD, the display is fundamentally serialised. You can tell which frame the output appears on, but even at 144Hz that's a whole 7ms per frame. So we shouldn't try to achieve sub-milisecond accuracy because it's meaningless.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks for the wicked fast replies, I'm barely catching up. I have also thought about sending it somehow to an LED and sticking a probe there. What's the expected magnitude of latencies for such a setup? My time-resolution needs (cognitive experiments) are rather more forgiving than typical EE application timescale, so if they are low in variance and less than several milliseconds I think they can work. \$\endgroup\$ Apr 26, 2021 at 14:13
  • \$\begingroup\$ [..continued] I have a love-hate relationship with parallel ports, as the newer PCs don't really have them anymore like you pointed out, but they're more reliable for event markers than say, USBs. I haven't even thought of an FPGA solution, I'll need to do some research on that. Your point on the LCD pixel position also stands, which I'm thinking multiple measurements with the diode in different positions of the screen. Each position with at least n>30 measurements of course :S \$\endgroup\$ Apr 26, 2021 at 14:15
  • \$\begingroup\$ Do you happen to have a good primer to read about the audio output latency suggestion? As in, is there a specific sound sample that's used, can you expect the latency to be predictable in general purpose PCs of different specs, etc.. Thanks in advance! \$\endgroup\$ Apr 26, 2021 at 14:24
  • \$\begingroup\$ You could try soundonsound.com/techniques/… or docs.microsoft.com/en-us/windows-hardware/drivers/audio/… ; you don't need a specific sample, just something you can identify on the scope like a "click". \$\endgroup\$
    – pjc50
    Apr 26, 2021 at 15:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.