Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

[open] Response Triggers and parallel_port_trigger plugin

edited January 2014 in OpenSesame

Thank you very much for developing that great parallel_port_trigger plugin. It really eases the setup of experimental scripts for EEG studies.

I have one question however, concerning the use of the plugin for sending triggers if a response key or button is pressed or not pressed.
Can I use this plugin for sending response triggers and if yes, how?

I already tried this by defining two parallel_port_trigger items, one for correct response, the other for incorrect response and then using the "run if" form field in a superordinated sequence item. This didn't work at all (maybe it's because I am unsure what to fill in the "run if" field. I tried [correct = 1] and [correct = 0].

However, the "run if" field will not work for conditions other than binary. I want to decide between correct, incorrect and timeout.

How can I achieve this? Do I still need an inline script for this?

All the best,
Johannes

Comments

  • 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!

  • edited January 2014

    Oops, this was a double post.

  • 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

  • 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?

  • 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

  • edited 4:51PM

    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

  • 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

  • edited 4:51PM

    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?

  • edited January 2014

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

  • 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

  • edited 4:51PM

    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

  • edited 4:51PM

    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

  • edited 4:51PM

    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

  • 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

  • edited 4:51PM

    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

  • BobBob
    edited 4:51PM

    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

Sign In or Register to comment.

agen judi bola , sportbook, casino, togel, number game, singapore, tangkas, basket, slot, poker, dominoqq, agen bola. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 50.000 ,- bonus cashback hingga 10% , diskon togel hingga 66% bisa bermain di android dan IOS kapanpun dan dimana pun. poker , bandarq , aduq, domino qq , dominobet. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 10.000 ,- bonus turnover 0.5% dan bonus referral 20%. Bonus - bonus yang dihadirkan bisa terbilang cukup tinggi dan memuaskan, anda hanya perlu memasang pada situs yang memberikan bursa pasaran terbaik yaitu http://45.77.173.118/ Bola168. Situs penyedia segala jenis permainan poker online kini semakin banyak ditemukan di Internet, salah satunya TahunQQ merupakan situs Agen Judi Domino66 Dan BandarQ Terpercaya yang mampu memberikan banyak provit bagi bettornya. Permainan Yang Di Sediakan Dewi365 Juga sangat banyak Dan menarik dan Peluang untuk memenangkan Taruhan Judi online ini juga sangat mudah . Mainkan Segera Taruhan Sportbook anda bersama Agen Judi Bola Bersama Dewi365 Kemenangan Anda Berapa pun akan Terbayarkan. Tersedia 9 macam permainan seru yang bisa kamu mainkan hanya di dalam 1 ID saja. Permainan seru yang tersedia seperti Poker, Domino QQ Dan juga BandarQ Online. Semuanya tersedia lengkap hanya di ABGQQ. Situs ABGQQ sangat mudah dimenangkan, kamu juga akan mendapatkan mega bonus dan setiap pemain berhak mendapatkan cashback mingguan. ABGQQ juga telah diakui sebagai Bandar Domino Online yang menjamin sistem FAIR PLAY disetiap permainan yang bisa dimainkan dengan deposit minimal hanya Rp.25.000. DEWI365 adalah Bandar Judi Bola Terpercaya & resmi dan terpercaya di indonesia. Situs judi bola ini menyediakan fasilitas bagi anda untuk dapat bermain memainkan permainan judi bola. Didalam situs ini memiliki berbagai permainan taruhan bola terlengkap seperti Sbobet, yang membuat DEWI365 menjadi situs judi bola terbaik dan terpercaya di Indonesia. Tentunya sebagai situs yang bertugas sebagai Bandar Poker Online pastinya akan berusaha untuk menjaga semua informasi dan keamanan yang terdapat di POKERQQ13. Kotakqq adalah situs Judi Poker Online Terpercayayang menyediakan 9 jenis permainan sakong online, dominoqq, domino99, bandarq, bandar ceme, aduq, poker online, bandar poker, balak66, perang baccarat, dan capsa susun. Dengan minimal deposit withdraw 15.000 Anda sudah bisa memainkan semua permaina pkv games di situs kami. Jackpot besar,Win rate tinggi, Fair play, PKV Games