Empirisoft Support

    Welcome to Empirisoft Support
Results 1 to 5 of 5

Thread: Flushing serial TTL buffer

  1. #1
    Join Date
    Sep 2006
    Posts
    14

    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

  2. #2
    Join Date
    Sep 2006
    Posts
    14

    followup

    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

  3. #3
    Join Date
    Nov 2005
    Posts
    3,328
    Can you post a copy of your input file?

  4. #4
    Join Date
    Sep 2006
    Posts
    14
    Here it is.

    Thanks for taking a look!
    Aaron
    Attached Files Attached Files

  5. #5
    Join Date
    Nov 2005
    Posts
    3,328
    Have you tried sending a signal at the end of each trial to set it to 0?

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

Similar Threads

  1. TTL unsolved problems
    By mugur65 in forum MediaLab Older Versions: Troubleshooting
    Replies: 2
    Last Post: 06-22-2023, 03:27 AM
  2. Sending responses via TTL (case 5907)
    By AaronNewman in forum DirectRT Older Versions: How Do I...
    Replies: 5
    Last Post: 03-13-2013, 09:41 AM
  3. My Computer Has No Parallel or Serial Ports
    By JEC in forum Hardware: How Do I...
    Replies: 3
    Last Post: 08-28-2007, 09:41 AM
  4. Problems with TTL
    By mugur65 in forum MediaLab Older Versions: Troubleshooting
    Replies: 2
    Last Post: 04-27-2007, 12:49 PM
  5. TTL signal to Biopac
    By XeniasD in forum MediaLab Older Versions: Troubleshooting
    Replies: 1
    Last Post: 12-15-2006, 02:26 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •