What is the "duration" in the parallel port trigger?

Comments

• absurd

  March 2015 edited March 2015

  Hi Grusha,

  A bit general information:

  The triggers sent to EEG-Amplifiers/Software are transmitted via a parallel port cable.
  The parallel port cable has a lot of pins/wires in it but only some of them can be freely used (pins 2-9), therefore, we can have 255 different binary codes as triggers (trigger 0 is reserved for reset).
  Triggers are "sent" (created) by switching the power on or off on each pin (0V or 5V).

  And now the answer to your question:

  The computer/amplifier that the triggers are sent to does not actually recognize the triggers as single events. It only recognizes a change in the voltage of the pins. Therefore in the early stages of OpenSesame (before we had the parallel port trigger plugin) it was like this: if you would send e.g. trigger "111" and immediately afterwards send another trigger "111" again, the second trigger would just not appear in the EEG recording as there is no change in voltage (even worse, the binary codes of the triggers get added up sometimes which produces triggers in the EEG recording that you never sent out, see my post in the discussion you cited). What you had to do in these times was to send out the trigger "0" that resets all pins to "0". Then the second "111" is again a voltage change and is recognized/appears in the EEG.

  The parallel port trigger plugin will do this reset automatically for you (i.e. no need to send out an additional "0" any more).

  The duration of a trigger is then the time between the "111" and the "0". In the EEG recording only the "111" at the beginning, i.e. at the time of the voltage change, will appear, so it will look like a single atomic event.

  Other experimental software like Presentation or EPrime does this internally exactly in the same way (actually, I found old posts in the official EPrime forum, that discussed the necessity to send out "zero-triggers", though this might have changed meanwhile). The only difference is that this is completely hidden from the user interface in these softwares (at least in Presentation).

  The fact that you can actually assign a duration to a trigger is handy/can be exploited for OpenSesame programming, as you can e.g. define a sketchpad with duration 0 followed by a trigger item with the duration 100. That way the sketchpad will be visible for 100ms and a trigger will be sent out initially.

  So 100ms means that the trigger, i.e. the voltage on the pins is active for 100ms and then switched of by a zero trigger.

  There is a lower limit of length of a trigger, though. With a recording at 1000Hz sampling rate it should be theoretically possible to send out triggers that are only 1ms long, however this also depends on your specific amplifier and/or parallel port card and/or parallel port cable (with my current equipment and with a sampling rate of 1000Hz, triggers have to be at least 4ms long. Otherwise some triggers are lost.)
  With 500Hz sampling rate you are at a theoretical minimum of 2ms, with 250Hz at 4ms.
  But this lower limit hardly plays a role in common EEG designs.

  Best,
  Johannes
• grushaprasad

  March 2015 edited 12:52AM

  Hey Johannes!

  Thank you for your response! Just to make sure I understand it correctly - setting the duration to a 100 ms means that once the trigger is sent, the next trigger cannot be sent for atleast a 100 ms because it is only after this duration that the pins get set back to zero and thus are "ready" in a sense to be able to send out a new trigger. So the duration doesn't affect when a particular trigger is sent, but it affects when the next trigger can be sent right? Is this why the lower limit usually does not play a role in common ERP design because one usually has stimuli up for atleast 30 ms (I am thinking priming studies) before one might want to send out the next trigger. So if that were the case then the duration would only have to be lower than the frequency at which I want to be sending the triggers right? In other words, if I want to send triggers every 30 ms, then the duration would have to be lower than 30 (maybe 25 to be on the safe side)? So theoretically, if for some study I wanted triggers to be sent out only every 1000 ms, then there shouldn't be any difference in setting the duration to 500 ms and setting it to 10 ms. Am I understanding this correctly?

  I have three more questions/clarifications:
  1. What would I have to do send a trigger when a response is made? I am thinking I would have to place the trigger right after the response item (like the keyboard for example) right?

  2. Also say I want the participant to be constantly seeing a blank screen, but hear a sound for 200 ms and then there is a 1800 ms gap before they hear the next sound. They can respond to the sound anytime between these 2000 ms. In this case, I would have to have:

  BlankScreen -> parallel_port_trig_stim -> stim -> parallel_port_trig_resp

  Where the durations would be as follows:
  BlankScreen : 0
  parallel_port_trig_stim : 200
  stim: 0
  parallel_port_trig_resp: 1800

  Would this work? However what if the Stim was an image (or a word) instead of a sound? Then would it be displayed only 200 ms after the parallel_port_trig_stim (because there isn't any change in the voltage until then?) Or am I misunderstanding it and will it work the same way?

  3. What are these other factors that need to be considered to figure out what the minimum duration is? I know at the lab I work in as an RA, we sample at 1000Hz. But what else specifically do I need to know about the amplifier, parallel_port card etc?

  Thank you so much!
  Grusha.
• absurd

  March 2015 edited March 2015

  If you want to send triggers every 30ms, you have to make sure that all Opensesame items between two triggers add up to 30ms. So, e.g. you want to send only triggers and present nothing, you could use only the parallel port trigger item, set it to 30ms duration and repeat this. Or you could set a parport trigger item that is 10ms long and add an advanced delay item of 20ms and then add the next trigger and so on.

  If you set only a bunch of trigger items and make them 25ms long, then nothing else than the trigger duration determines the distance between the triggers, i.e. you end up with triggers only 25ms apart.

  If the following events do not need to depend on your trigger item than you are right, just set it as short as it does not interfere with the following trigger. But this depends on your trial design.

  Your question 1:

  BlankScreen : 0 parallel_port_trig_stim : 200 stim: 0 parallel_port_trig_resp: 1800

  With this you would trigger the BlankScreen and set it to 200ms length. Then a sound of the length 0 is (not) presented and then you would send out a response trigger for 1800ms (at least I think this is what happens, but why don't you try it out?). That's not exactly what you want, I guess.

  I suppose you want to sent out a trigger at the beginning and the end of the sound and then one for the response (by this you also get to know how accurate your sound card really is):

  • start sound trigger (duration e.g. 4ms or 10ms, this would make the whole trial 4ms or 10ms longer but that's probably not critical anyway)
  • sketchpad/BlankScreen (duration 0ms)
  • sampler item (duration 200ms)
  • end sound trigger (duration again 4ms or whatever you want)
  • sketchpad (maybe a BlankScreen or some indication for the participant to give a response now, duration 0ms)
  • response item (timeout 1800ms)
  • correct response trigger (duration e.g. 4ms, Run if [response] = [correct_response], the latter you define in the surrounding sequence item)
  • false response trigger (duration e.g. 4ms, Run if [response] != [correct_response] and [response] != None)
  • no response trigger (duration e.g. 4ms, Run if [response] = None)

  Your question 2:

  If you want to use a visual stimulus you have to send out the trigger before the stimulus and set the trigger length to the desired stimulus length and the duration of the stimulus/sketchpad item to 0.

  What are these other factors ...

  Well, one just cannot tell this without testing the actual equipment (either by try and error or if you have a technician that knows about timing test/oscilloscopes). I already made some suggestions what might possibly interfere, but nobody can give you a complete list here.

  A good way to test your minimum duration is the script Sebastiaan created in the post you initially cited:

  #!/usr/bin/env python
  #-*- coding:utf-8 -*-
  
  import time
  # This requires the `parallelppdev.py` module included with the parallel-port
  # plug-in
  import parallelppdev
  # Open the parallel port
  pp = parallelppdev.Parallel()
  # Test durations 1 through 10 (ms)
  for dur in range(1, 11):
      print 'Testing %d ms duration' % dur
      # Test each duration 100 times
      for i in range(100):
          # First set the port to 255, then sleep for the specified duration,
          # then set the port back to 0. Afterwards, sleep for 50 ms before we
          # advance to the next test run.
          pp.setData(255)
          time.sleep(.001 * dur) # NB `time.sleep()` expects seconds
          pp.setData(0)
          time.sleep(0.05)
  

  This sends out 100 triggers each, starting with 1ms length up to 10ms length. Record this with your EEG recording software at 1000Hz sampling rate (no need to connect a participant, just do a "noise" recording) and count the triggers in the EEG recording. If you have 100 triggers that are 1ms apart already from the start, then your minimum trigger length is 1ms. If not, count the triggers that are 2ms apart, if they sum up to 100, your minimum length is 2ms and so on.
  At the end you will know the minimum length of a trigger you can use on your system. Theoretically it should be 1ms at 1000Hz sampling rate. If not, then something in your equipment creates a delay. What part of your equipment this is, you do not know, though. This could be only found out by replacing each possible part with another e.g. better parallel port card/cable/whatever and try the script again and see if it improved... Or you know somebody who has the technical knowledge and equipment to really test the accuracy of electronic parts.
  But mostly I think it is just enough to know what is the minimum value.

  Best, Johannes
• grushaprasad

  March 2015 edited 12:52AM

  Thank you for your prompt responses! I have two follow up questions after I tried setting both these trial experiments up:

  Firstly for the trial experiment with visual stimuli, I set up the sequence in the following order:

  Stim: 0ms

  stim_trig: 5000 ms

  blank: 0 ms

  response_item: 2000 ms

  correct_trig: 4ms

  wrong_trig: 4 ms

  logger

  (The screen shot of this sequence can be seen here https://drive.google.com/file/d/0B7hVnUw4qF2iV20yVUdEblJCc0E/view?usp=sharing
  because I wasn't able to upload the image)

  The basic idea was that the participant sees an image for 5000 ms and then a blank screen for 2000 ms. They should be allowed to respond to the stimulus at any point between this 7000 ms range (I used such big numbers because of its ease to visually see what was happening)

  While the above sequence makes the trigger for the stimulus onset, response triggers and the duration for which the stimulus is presented very accurate, it has two problems:

  1. It allows the participant to respond only after the 5000 ms and this makes sense because the response item is only after the stim. However I wasn't quite sure where else to place it (because placing it at the beginning would mean that it waits 2000 ms for a response and when it doesn't find one, it will present the stimulus right?)

  2. The moment the response is made, the next item starts. So if I did respond before 2000 ms, then the trigger is sent and the next image is displayed. However, for a lot of paradigms we run in the lab, we would need the duration for which the stimulus is presented and the inter-stimulus-interval (ISI) to be constant. So it should be unaffected by the keypress. However I was unsure about how to go about that..

  Secondly, for the trial experiment with the auditory stimuli, by sending the trigger before the sampler item, the trigger does not accurately represent the stimulus onset right, since it will always be 4ms (or whatever the duration is) sooner than the stimulus onset. So if one wanted very precise measures of stimulus onset one would just have to add the value of duration to the time? Or is there a better way of doing this? Also the question about how to record response while the stimulus is still being presented without affecting the presentation of the stimulus is still relevant here..

  (Also, I realize that some of these questions are more related to general timing than to the parallel_port_trigger plugin specifically.. Since I am new to this forum I am not sure if I need to post these questions elsewhere..)

  Thank you!
  Grusha.
• absurd

  March 2015 edited March 2015

  Hi Grusha,

  by sending the trigger before the sampler item, the trigger does not accurately represent the stimulus onset right, since it will always be 4ms (or whatever the duration is) sooner than the stimulus onset. So if one wanted very precise measures of stimulus onset one would just have to add the value of duration to the time?

  Yes, but you would need to subtract 4ms of the recorded time. And then the remaining time until the sound end trigger subtracted by the length of your wav file will be the delay (hopefully, i.e. always the same amount of time longer than the wav file) or jitter (worse, different additional times) of your soundcard.

  for a lot of paradigms we run in the lab, we would need the duration for which the stimulus is presented and the inter-stimulus-interval (ISI) to be constant. So it should be unaffected by the keypress.

  Well, constant ISIs are somewhat complicated. I have not done designs with this yet. If you want to make it possible, that participants can give a response at all time you are probably better off with using the parallel item (which runs two threads in parallel). One thread would listen for keypresses and the other one would present the stimuli. I haven't tried this out with trigger sending, though. Even with a non-EEG experiment that used this approach, I had numerous issues (e.g. OpenGL did not work when using the parallel item). I have also read that the performance and function of parallel item depends very much on your hardware and operating system. So I do not even know if it would be possible to achieve a ms accurate synchronization of the two threads at all, which would be needed to send out exact triggers.

  Or there might be a different solution via python inline scripts...

  But this is really something I'd like to know as well. Maybe someone else could give us a hint?
• grushaprasad

  March 2015 edited 12:52AM

  Hi Johannes!

  So the reason I thought adding 4ms would be sufficient was based on the implicit assmption that the stimulus would be presented 4ms after the trigger gets sent. Usually a trigger at x ms tells us that the stimulus was presented at x ms. However, since the trigger is presented 4 ms earlier, the stimulus is presented 4 ms after x+4 ms. So if the trigger gets sent at 100ms, we know that the stimulus was presented at 104 ms. But if I am understanding what you said correctly, it is not necessarily the case that the delay is just 4 ms because the delay could be caused by other hardware issues too right?

  Also, I was not aware of the parallel item. Thank you! I will look into that. I am hoping we might have a bit more luck because we use the xpyriment backend. Additionally, I think we care about the precision of when the stimulus trigger gets sent, but not so much about when the respose trigger gets sent (because the RT information could be used for that) So as long as the parallel thread contained just the response item and a logger that logged the RT and the accurate/inaccurate trigger got sent sometime before the trial ended, I think it might serve our purposes at the lab. I will try it out and post any updates here.

  Thank you so much for all your help!
  Grusha.
• absurd

  March 2015 edited March 2015

  Hi Grusha!

  The + - 4ms thing:

  Length of triggers are (to my knowledge) always ms accurate (that's why we use the parallel port). It is just that if you define a trigger length shorter than your minimal duration (which is 4ms in our example) it may sometimes be dropped by the EEG recording device.

  Opensesame has the feature that if you define an item to have a duration of 0 it will presented in parallel with the next item following and as long as the duration of the following item is set.

  So, if you define a sketchpad with the duration of 0 and a following trigger that is e.g. 100ms long, then you'll get a picture presented for 100ms with a trigger sent out at the beginning of the 100ms. Actually the stimulus may be presented somewhat longer, depending on the refresh rate of your monitor (see below).

  You could also define a sketchpad of 100ms preceded by a trigger of 4ms. Then the timing would be less accurate. The trigger would be 4ms, exactly, and would appear in the EEG recording 4ms prior to the initialization of the sketchpad.
  I use the term initialization and not displaying/showing because the sketchpad will be presented somewhat longer than 100ms depending on the refresh rate of your monitor (remember to activate vsync in your graphics card driver!). A normal 60Hz flatscreen will produce a jitter of 16,7ms. So the sketchpad will be from 100ms up to 116,7ms long. Your on the safe side if you have a +100Hz monitor as your jitter is only +-1 ms then.
  But the stimulus is not displayed longer than 116,7ms (so not + 4ms). Only in the EEG the trigger appears 4ms earlier (so here it is: stimulus onset = trigger onset + 4ms). Here, during the trigger sending no stimulus is sent out.

  With auditory stimuli you will have a delay or jitter depending on your sound card anyway. The expyriment website mentions that they measured an older soundblaster audigy card and this produced a jitter of 20ms. My actual onboard-soundcard only produces a constant delay of 6ms (I checked this with the following procedure).

  This means with auditory stimuli you cannot get that exact synchronization as with graphical stimuli because you always have an initial delay or jitter. Therefore I send out a trigger before the sound and one following the sound. If you know how long your wav file is you can then calculate:
  length between the two triggers - 4ms intial trigger duration - length of your wav file = delay (constant) or jitter (variable) of your soundcard.

  You also might take a look at Lotjes answers to my questions in this post.

  Let me know about your experience with the parallel item.

  Best,
  Johannes
• grushaprasad

  March 2015 edited 12:52AM

  Hey Johannes!

  Aah I see! So if I conducted the test you suggested (by sending the trigger before and after the the sound file) I would be able to determine what the delay caused by the sound card is. If it is (hopefully) constant, then I could just add that to the time the trigger was sent to determine in the EEG when the stimulus was actually presented. So with your sound card, since your delay is a constant of 6 ms, you would just add trig_onset+6 ms to get stim_onset. If it is a jitter, then I would have to calculate this for every trial for every experiment right?

  Thank you!
  Grusha.