Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assign bins: allow overlapped bins #179

Open
a1phaeeg opened this issue Oct 23, 2023 · 2 comments
Open

Assign bins: allow overlapped bins #179

a1phaeeg opened this issue Oct 23, 2023 · 2 comments

Comments

@a1phaeeg
Copy link

Description

The B3 and B4 overlapped when I tried to assign the event marker "S44" and the response marker "S123" to the B3(No.67 trial). It means that the response marker "S124" in the next trial(No.68) was assigned to the bins twice because the interval between the two trials was too short, and the participant responded very quickly in the second trial.
The issue is shown in the following figure:
1698069011387

Here is the BINLISTER file I wrote:
Bin 1
Impact_resp1
.{1-60}{t<300-4000>121}

Bin 2
Impact_resp2
.{1-60}{t<300-4000>122}

Bin 3
Impact_resp3
.{1-60}{t<300-4000>123}

Bin 4
Impact_resp4
.{1-60}{t<300-4000>124}

Bin 5
Impact_resp5
.{1-60}{t<300-4000>125}


#### Expected behavior:

The software "Analyzer" of BrainProducts has a function " □ allow overlapped segments" to avoid overlapping segments( i.e., assign bins).
**Can this function be implemented in EEGLAB or ERPLAB? Or how can I avoid it? **

1698066444818


#### Actual behavior: [*What actually happened*]
#### Versions
OS version [fill in]
Matlab version [2022b]
EEGLAB version [2022.1]
ERPLAB version [ERPLAB v9.00]
@davidg622
Copy link
Collaborator

Hello,

The most straight forward fix for this problem would be to implement a NOT (~) operator to your BDF. You can use this operator to prevent any instance of a second response marker from being binned with your first. It could look like the following:

Bin 2
Impact_resp2
.{1-60}{t<300-4000>123}{t<300-4000>~121,122,124,125}

The other alternative would be to shorten the time condition window to ensure the response markers cannot overlap.

You can use the BDF Analyzer to play around with either of these ideas to see which option works best.

Unfortunately, we do not use BrainProducts Analyzer, so I cannot attest to how that function might be implemented.

Hope this helps,

David

@a1phaeeg
Copy link
Author

a1phaeeg commented Oct 24, 2023

Hello,

The most straight forward fix for this problem would be to implement a NOT (~) operator to your BDF. You can use this operator to prevent any instance of a second response marker from being binned with your first. It could look like the following:

Bin 2 Impact_resp2 .{1-60}{t<300-4000>123}{t<300-4000>~121,122,124,125}

The other alternative would be to shorten the time condition window to ensure the response markers cannot overlap.

You can use the BDF Analyzer to play around with either of these ideas to see which option works best.

Unfortunately, we do not use BrainProducts Analyzer, so I cannot attest to how that function might be implemented.

Hope this helps,

David

Hi,

Thank you very much for your answer!

These two methods are very useful and have inspired me a lot.

I want the combination of "S44(event marker)-S123(response marker)" to be assigned to B3 and not to B4. However, the 67th trial (S44) was deleted directly when I used the first method. All overlapping trials were deleted.

I did not want to lose too many trials, so I tried to use the second method. This method can help, but I have to set up a BDF file for each subject due to the wide variation in response times for each subject. This is going to be very tedious.

Finally, I decided to ignore the time windows and use a form that uses the following:
Bin 1
consequence_resp1
.{1-60}{121}{~122;123;124;125}

Bin 2
consequence_resp2
.{1-60}{122}{~121;123;124;125}

Although it would lose the last trial, it worked!

Thanks again for your help.

Hope you enjoy your life,

Zhao

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants