Flushing serial TTL buffer

Hi

We are using DirectRT in an fMRI experiment and would like to have the MRI scanner trigger the stim program to start. The apparatus we are working with takes a TTL pulse from the MRI and sends it through a box (Cedrus Lumina 400B) which in turn sends TTL signals to the PC that's running DirectRT.

We actually have no trouble receiving the triggers (or the codes from the response button boxes), but we are having a problem NOT receiving the triggers when we don't want to. Specifically, it seems that whatever code was sent last persists, so that if a "53" (the code from the scanner triggering the program to start) is sent, and then we start the DirectRT program again, it starts automatically without waiting for another trigger code to come in - the previous one is "still there". This can be confirmed by running DirectRT's TTL I/O program, which shows the port (serial port 1016) sittingat whatever the last received code was until a new code comes in.

This appears to be occurring on the PC side of things, in that we get the same behavior even when we turn off or disconnect the interface box that's sending the codes to the PC - the port still shows the last received code.

In practice this is not typically a huge problem, as typically subjects make button press responses during the experiment so these triggers (which occur only at the very start of each block of trials) get flushed by subsequent button presses. But, sometimes we have to abort a run, or other things happen.

So my question (finally! :)) is whether there is a way to flush the input serial buffer from within DirectRT after a TTL code is received?

Thanks
Aaron

Turns out this is a bigger problem than I initially realized. Since the button presses are treated exactly the same way, we are unable to collect subject responses accurately. Looking at the log files, all RTs are 0 or 1 msec, indicating that the button response from the preceding trial is being taken as the response for the current trial.

So, contra my previous post, this is a HUGE problem!

thanks in advance for any help,
Aaron

Can you post a copy of your input file?

Here it is.

Thanks for taking a look!
Aaron

Have you tried sending a signal at the end of each trial to set it to 0?

e.g., adding [I]ttl:0, 1016, 0[/I] to the end of each trial?