[open] Response Triggers and parallel_port_trigger plugin

Comments

• Edwin

  January 2014 edited January 2014

  Hi Johannes,

  You were almost there: use [correct] = 0 instead.

  If you use the correct variable, this will indeed be a binary approach. However, you could also employ the same approach, but with a different variable. You could use the response variable instead. Then the Run if for a correct response would be [response] = [goodresp] (replace "goodresp" with the variable in which you define the correct response). After a timeout, the response will be None, so use the following in as a Run if statement: [response] = None. Finally, for an incorrect response, use [response] != [goodresp] and [response] != None (the term '!=' means "does not equal").

  Does this solve your problem?

  Good luck!

  Edwin

  PS: I'll pass on your compliments to the main developer of the parallel_port_trigger plug-in. I'm sure he'd be delighted that it proves useful to you!
• absurd

  January 2014 edited January 2014

  Oops, this was a double post.
• absurd

  January 2014 edited January 2014

  Hi Edwin,

  Thanks for your quick reply. Especially, your suggestion using the response variable did the trick for me. As regards what should be typed into Run if I always mix up the python syntax with the OpenSesame gui syntax (e.g. == instead of =) and that often gives me a hard time figuring out where the error is ;-)

  I have a follow up question/problem:
  In the respective sequence I have placed the three parallel_port_trigger items (correct, false, timeout) after a keyboard response item that defines a timeout of 2000 ms. Each parallel_port_trigger item then defines duration as keypress or 2 ms in the case of timeout.
  This does not work correctly: I always have to press the allowed keys twice to see the trigger appearing in the ongoing EEG recording.

  I guess the problem lies in the duration/timeout definitions. But what does the right job here?

  Thanks for your help.

  Johannes
• Edwin

  January 2014 edited January 2014

  Excellent, very good to hear that you've fixed the conditional statements.

  Concerning the keyboard_response and the parallel_port_plugin: The timeout of the former should be the response timeout that you wish to use, and the Duration of the latter should simply be a value in milliseconds. The logic of this is that the keyboard_response will take care of the keyboard (registering either a response or a timeout), whereas the trigger should simply be a short signal (if you set the Duration to 'keypress', the parallel_port_trigger will actually wait for a keypress as well, on top of that of the keyboard_response).

  By no means should you use 'keypress' as the Duration of the parallel_port_trigger. We added that option during debugging and we forgot to take it out, I'm afraid. We've fixed that very recently, though, so if you download the newest version of the plug-in from GitHub (go to this page, and click on the button labelled Download ZIP on the right), you should be fine. Also, note that the fact that the keyboard response option was still in there, only made that you could set the Duration to 'keypress', and that the trigger duration could be interupted by a keypress (but with the short durations that these triggers usually have, this is very unlikely to be a problem). Sorry for the confusion!

  Did that do the job?
• absurd

  January 2014 edited January 2014

  Hi Edwin,

  Thanks, that does the job. I have (git) pulled the most recent version of the plugin (the keypress option is still mentioned in the inline help) and used keypress only in the keyboard response item (defining also a timeout of 2000ms) and set the duration of the parallel_port_trigger item to 2 ms (as I plan to record EEG with a sampling rate of 500Hz).

  Now everything works as expected but still there are two issues:

  A small issue:

  The Debug Window tells me "The local version of pyparallel could not be loaded. Check if the file is present and if the file permissions are correct."

  And a bigger one:

  If I simulate a participant pressing the response key too early, I get unexpected triggers sent out: 46 for too early correct answers and 56 for too early wrong answers. I have never defined nor used these numbers as trigger codes anywhere, though.

  Cheers,

  Johannes
• Edwin

  January 2014 edited 3:39PM

  Hi Johannes,

  The small issue you mention is simply a warning that no local version of pyparallel could be found. To compensate for this, the onboard version will automatically be used.

  The bigger issue is quite an interesting one, that I can't quite figure out remotely. Could you maybe upload a screenshot of your keyboard_response and your parallel_port_trigger? Also, could you define what you mean by 'pressing too early'? Is this before the keyboard_response's onset?

  Cheers!

  Edwin
• absurd

  January 2014 edited January 2014

  Hi Edwin,

  The relevant part of the trial is as follows:

  1. a sketchpad item with a question mark
  2. a keyboard response item
  3. the response trigger items (here's just one example, the other two are the same just with code 120 for wrong answers or 100 for timeout.

  I can replicate the thing exactly. It takes me a while to get into the exact timing, but after a while I can thoroughly produce it:

  It occurs when I press a response key twice with the second key press immediately following the first one (like a double key press) and shortly before the question mark (maybe the first is before and the second right behind the sketchpad item). The first key press is immediately before the question mark becomes visible (the sketchpad just flashes shortly). Under these circumstances I get 46 or 56 as triggers. Any following responses within that trial are blocked. That's weird.

  I'm using a Neuroscan Nuamps amplifier with SCAN 4.5/Acquire as recording software.

  OpenSesame is run under Xubuntu 13.10 here.

  Hope we'll find a solution soon.
  Cheers,
  Johannes
• Edwin

  January 2014 edited 3:39PM

  Seems perfectly fine. And you have the latest version from here?

  I'll ask the main developer if maybe he can shed some light on this. Also, @sebastiaan, any tips?
• absurd

  January 2014 edited January 2014

  Yes, it's the most recent version. git pull says: Already up to date.
• absurd

  January 2014 edited January 2014

  Update:

  I think I'm getting closer:

  It seems that the first final (leftmost) bits are missed.

  correct trigger:

  decimal 110 -- binary 01101110

  correct trigger when pressing early:

  decimal 46 -- binary 00101110

  incorrect trigger:

  decimal 120 -- binary 01111000

  incorrect trigger when pressing early:

  decimal 56 -- binary 00111000

  ...and indeed if I change the correct trigger to 111 (binary 01101111), I get:

  decimal 47 -- binary 00101111

  It's always the first 1 that misses.

  To be clear: It's hard to get the exact timing for this. It occurs only when I press the answer button twice immediately before the question mark appears.

  However, this can happen every once in a while during an experiment. So one should at least be aware of that certain triggers might better be left out and not be used for any other coding.

  Of course another solution would be more satisfactory :-(

  Cheers,

  Johannes
• sebastiaan

  January 2014 edited 3:39PM

  Hi Johannes (and Edwin),

  I think the problem is related to the binary-or ghost triggers that we discussed a year-or-so ago. Basically, my guess is that the following happens.

  Problem

  First you send a trigger, say 110 (or binary 01101110), followed by another trigger of value 0 (00000000). When these two triggers follow each other too rapidly, they get intermixed, and the final bits of the first trigger get replaced by the final bits of the second trigger (final meaning 'highest', so on the left). In your case, this results in the final two bits of 110 (i.e. 01) being replaced by the final two bits of 0 (00), resulting in 46 (00101110).

  The duration of your trigger (i,e. the interval between trigger 110 and trigger 0) is very short (2 ms) and is probably pushing the limits of what your setup can handle. My guess is that when you rapidly press keys beforehand, this interferes just the tiniest bit with the timing, thus causing the mixups to occur more frequently. Note that the plug-in actually polls the keyboard while sleeping, which may be why this happens (incidentally, this polling may not be a terribly good idea, at least for short intervals).

  So I doubt that the problem is related to the key presses per se. They just make it more visible.

  Solution

  Practically speaking, your problem will likely go away if you a) set the trigger duration to a higher value, or b) set the duration to zero (i.e. infinite) and simply reset the trigger by sending a 0-value trigger at the start of each trial.

  Testing

  I think it might be worthwhile to test this issue in a bit more detail. This could be done very easily. In a script, simply send a 255 trigger, sleep for a variable delay, and have it followed by a 0 trigger. I suspect that at short delays, you should start to lose progressively more bits, resulting first in a 127 (01111111), then a 63 (00111111), and maybe even a 31 (00011111) at extremely short delays.

  You can also do the converse, sending very brief 0 triggers, followed by a sustained 255. This is also important, because based on your previous issue there appears to be an asymmetry between turning bits on and off.

  Once we get to the bottom of this, we could see (maybe Bob could do a few quick tests?) whether it's specific to your set up, or whether the same happens on other set ups as well. If this is the case, we should inform people about the risk.

  Cheers!
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• absurd

  January 2014 edited 3:39PM

  Thank you for your quick reply, Sebastiaan.

  Indeed, the ghost-trigger thing was what put me on the right track. :-?

  I have tested the whole thing now with a minimum trigger length of 4ms (I didn't test 3ms, though) and it seems that I cannot produce these unwanted triggers any more.

  I have more triggers defined than just the mentioned response triggers. At a first try I just set the response triggers up to 4ms while leaving other triggers at 2ms. This was even worse because now my "hammering" on the keyboard resulted in some of the 2ms triggers beeing skipped -- This might be an indicator that you are right in assuming that the problem is more related to trigger length. However, as I said before, if all triggers are at 4ms and above, everything seems fine.

  Regarding your proposed script, I would need some further advice on how to program this for a Linux machine (I switched to Xubuntu on the presentation PC recently). The scripts I have at hand will only work for Windows as they use dlportio. For sending triggers on Linux, I entirely rely on the plugin by now. But if someone could tell me how to "talk" to the parallel port on Linux, I would be willing to run these tests.

  On the shortness of the trigger:

  I remember when we were investigating that ghost-trigger problem, I also talked to a support technician from BrainProducts (as I used a BrainAmp in Marburg). And he told me, that the trigger length would be related to the sampling rate at which you record your EEG: for a recording at 500Hz sampling rate (one data point every 2ms) the minimum trigger length should be 2ms, for a recording at 1000Hz (one data point every 1ms) the minimum trigger length should be 1ms.

  Well, maybe that's not valid for the NuAmps I am working with here in Calgary. It is capable of recording at a sampling rate up to 1000Hz and that's what I am currently testing with. So normally, 1ms should be fine and I used 2ms, but even that seems to be too short???

  I do not know though, how the parallel_port plugin works internally. Obviously it sends out the 0 triggers to avoid the ghost triggers automatically. Or am I wrong here? Maybe there is some issue with the delay with which these 0 triggers are sent out after the actual event trigger?

  Or is it related to the NuAmps recording with 24bit? There is also an option for recording with 32bit... Well, I am currently digging myself through the NeuroScan documentation...

  Cheers,
  Johannes
• sebastiaan

  January 2014 edited 3:39PM

  I have tested the whole thing now with a minimum trigger length of 4ms (I didn't test 3ms, though) and it seems that I cannot produce these unwanted triggers any more.

  Good.

  Regarding your proposed script, I would need some further advice on how to program this for a Linux machine (I switched to Xubuntu on the presentation PC recently).

  I cannot test it here, because I don't have a parallel port on my machine, but something like the script below should do the trick. See the code comments for details.

  #!/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)
  

  It is capable of recording at a sampling rate up to 1000Hz and that's what I am currently testing with. So normally, 1ms should be fine and I used 2ms, but even that seems to be too short???

  Yes, so apparently some part of the chain is not fast enough. This could be the script, the rate at which the triggers are sent, or the rate at which the triggers are received and processed. But what exactly is causing the problem is difficult to say.

  Or is it related to the NuAmps recording with 24bit? There is also an option for recording with 32bit... Well, I am currently digging myself through the NeuroScan documentation...

  The parallel port is, as far as I know, always 8 bits, with each bit actually corresponding to a physical pin in the connector. So the bitrate of the device probably refers to something else, maybe the resolution with which the voltages are recorded.

  Cheers!
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• absurd

  January 2014 edited January 2014

  Hi Sebastiaan and Edwin,

  I have tested out the minimal trigger length with Sebastiaan's script (thank you very much for providing it!).
  To make the import parallelppdev work, I had to add the following lines before it:

  import sys
  sys.path.append('/path/to/opensesame_plugin_parallel-port-trigger/parallel_port_trigger')
  

  I tested with 24bit and 32bit recording and then imported the .cnt-files to EEGLAB/ERPLAB and created event list files. I put them on Google Drive (triggerdist.txt for 32bit and triggerdist24.txt for 24bit recording). Here's the link. The relevant column is ecode (event code).

  Bitrate seems to be a minor issue (though it seems that the 32bit recording is a little better/shows less distorted triggers).

  Here are the results:

  Throughout the first 100 cycles there are 63 triggers appearing, i.e. a 1ms trigger duration is too short. However, after these 100 cycles only correct 255 triggers appear.

  I constantly loose the last two bits, since only 63 triggers appear.

  So this only explains part of the problem, as I originally used a minimum trigger length of 2ms which should be fine according to this test.

  Cheers!
  Johannes
• sebastiaan

  January 2014 edited 3:39PM

  Hi Johannes,

  Well, the most important thing is that you got it working for your experiment. But apparently the problem is not simply due to the short delay then. I'll pass this on to Bob, the developer of the parallel port plug-in, to see what he thinks.

  Cheers!
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• Bob

  January 2014 edited 3:39PM

  Hi Johannes, Sebastiaan and Edwin,

  I did not test the minimal duration for a trigger to be fully processed. For our experiments sending triggers with a duration of 100 ms is adequate enough. According to your data it seems the individual bits are processed in a serial way. Gonna check this next week with a 2000 Hz Biopac.

  I am wondering why you need the duration to be 1 or 2 ms if you are working with human responses. Would a duration of 100 ms not be good enough?

  Cheers! Bob