How to synchronize presentation on the front panel to the start of a 75Hz monitor's retrace cycle?

[Vinci HK]

How to synchronize front panel presentation with the start of a retrace cycle of a 75Hz Monitor, so when a bitmap is presented 100ms, its duration is indeed 100ms on the monitor?

[Robert M]

Hello Vinci,

You pose an interesting question. If your monitor is cycling 75 frames per second, and you want to display the current front panel for 100 ms, does that mean you want it to last for 13.33 frames? I am not too familiar with how monitors time their update frequency. Even if you were able to know exactly when it is refreshing, getting LabVIEW to synchronize with that would be tricky at best. LabVIEW is at the mercy of Windows for processor time. Because of this, you never know exactly when something is going to happen.

If none of these suggestions help, or if I�m not correctly understanding your issue, please reply with comments or answers to the discussion above and any additional information that may help, and I�ll be happy to look further i
nto it.

Have a nice day!

Robert M
Applications Engineer
National Instruments

[Vinci HK]

Hi Robert,
I am so excited to have received a response! Sorry that I didn't reply earlier as I have been out of town. You are understanding the problem, so good!

I just want to know the exact duration a stimuli in the front panel is presented. I can make it to last for 13 frames, but the problem is to ask LabView to synchronize with the start of a frame.

The crucial thing is that I want a trial of presenting 700ms blank screen + 1300ms bitmap will add up to 2000ms on the front panel. And in the next 2000ms, a different bitmap will be used for the 1300ms. The start of a trial is initiated by a pulse from the parallel port. I need the 2000ms on the front panel to be really 2000ms+/-5ms.

My worry is that even if I buy the external clock and the Real
Time system of LabView, I won't be able to get the front panel to synchronise with the refresh cycle of the monitor, so that the trial length as it appears on the front panel is 2000ms +/- 5ms.

What do u think?

I am using LabView for my fMRI experiment, and I wonder if you know anyone from the fMRI community who are using LabView for stimulus presentation and synchronization with MRI data acquisition?

Thanks,
Vinci

[Wiebe@CARYA]

Hi,

In the old days (late 90's), we used in port and out port to wait for
vertical retraces (or even horizontal retraces).

I searched the web (vertical retrace), and there seem to be lots of
infromation and tools, like

http://www.compuphase.com/vretrace.htm

It uses a simple routine:

mov dx, 3dah ; VGA input status register
vretrace_loop:
in al, dx
test al, 8 ; bit 3 set?
jz vretrace_loop ; no, continue waiting

But to get it working, you need a VxD. Good news is you can download it.

The also suggest you use WaitForVerticalBlank(), but dx could be hard to get
working under LabVIEW.

Please let us know how (and if) you got it working with LabVIEW!

Regards,

Wiebe.



"Vinci HK" wrote in message
news:50650000000500000021B80100-1079395200000@exchange.ni.com...
> Hi Robert,
> I am so excited to have received a response! Sorry that I didn't reply
> earlier as I have been out of town. You are understanding the problem,
> so good!
>
> I just want to know the exact duration a stimuli in the front panel is
> presented. I can make it to last for 13 frames, but the problem is to
> ask LabView to synchronize with the start of a frame.
>
> The crucial thing is that I want a trial of presenting 700ms blank
> screen + 1300ms bitmap will add up to 2000ms on the front panel. And
> in the next 2000ms, a different bitmap will be used for the 1300ms.
> The start of a trial is initiated by a pulse from the parallel port. I
> need the 2000ms on the front panel to be really 2000ms+/-5ms.
>
> My worry is that even if I buy the external clock and the RealTime
> system of LabView, I won't be able to get the front panel to
> synchronise with the refresh cycle of the monitor, so that the trial
> length as it appears on the front panel is 2000ms +/- 5ms.
>
> What do u think?
>
> I am using LabView for my fMRI experiment, and I wonder if you know
> anyone from the fMRI community who are using LabView for stimulus
> presentation and synchronization with MRI data acquisition?
>
> Thanks,
> Vinci

[jdigiova]

You pose a very interesting question. In terms of a realtime application it appears you want to deterministically control the timing of an image on a screen. Using the 75Hz refresh rate of the monitor to control the picture timing may work, but raises a couple of questions.

1) Do you have access to the 75Hz signal. If so what type of signal is it?

2) How accurate is this signal. All crystal oscillators will have some jitter. I wonder how much there is in a video driver card.

The way I see it, even if you have access to the 75Hz clock and it was accurate, how can we use it to time a picture update. In LabVIEW we could create a timed-loop that is looking at the 75Hz clock to determine which picture gets displayed, but the nature in which you display it may be flawed. For example, do you already have LabVIEW code that uses a picture window to display a bitmap on its front panel? Doing this in windows we can not guarantee that windows will not disturb this process. However doing this in LabVIEW RT will also cause problems because LabVIEW RT updates the host computers front panel through tcp/ip and therefore is not deterministic either.

Therefore we have to provide another solution. I have some untested theories about using a LabVIEW RT controller with some of our Vision/IMAQ software. The vision software will allow you to send a signal to the VGA output of the controller directly. This image is limited in resolution, so what resolution were these bitmaps? We can use the 1MHz clock of the RT controller to time a loop that determines which image is displayed on the monitor. And also perhaps a digital board to trigger the fMRI acquistion. Now as I mentioned this is an untested theory and I am not exactly sure how the timing will work once the signal is sent out the vga port.

In short, we can get a great timing source resolution with an RT controller and be able to control the software, however the hardware is still questionable. The only way to truly test such an application would be to get a high frame rate camera and capture the images from the monitor to make sure the hardware is keeping realtime.

I highly recommend contacting your sales representative to discuss more about your application and what solutions we may have.

Regards,
Joseph D.

[Fritz_Reitz]

about this -

"The also suggest you use WaitForVerticalBlank(), but dx could be hard to get
working under LabVIEW."

labview seems to have the capability to insert directx objects, and has some related methods, though I haven't found that particular method among the drop-down menus.  how hard is "hard"?

labview would be great for eeg studies if we could tell when the refresh was happening

[bjorn1985]

Could you tell me more about Vision/IMAQ? I have a Real-Time system running and I am also facing the problem of timed stimulus presentation.

[shoneill]

What kind or error in the timing can you tolerate?

Basing the software on Windows will introduce some errors on it's own, as others have indicated.

The refresh rate of the monitor could introduce further errors.  On this point, I would like to ask if the monitor has to be LCD-basis.  If not, then why not move to a suitable display with a higher refresh rate, meaning that +- one frame will simply fall less heavily into your error budget.

Surely there are CRT monitors out there with 200Hz refresh rate......  This makes a single frame +- 0.5% of a 1 second display period.

I don't think Windows will allow tighter tolerances to be honest....

Hoping to be able to help

Shane.