|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 103K
|
Hmm, if the trial doesn't move on, that would indicate it's still waiting to receive the specified /posttrialsignal. The problem here likely is that /posttrialsignal only recognizes lpt, not lptdata (as per the documentation -- I don't have a suitable device for testing around at this very moment).
What's the device's status register state when the respective pins are low?
|
|
|
|
|
DrLand
|
|
|
Group: Forum Members
Posts: 14,
Visits: 38
|
I think the issue is that the /posttrialsignal doesn't work with reading from lptdata. Even though I can't control the pins that are "watched" by the lpt status register, it holds a value of (127). If I use /posttrialsignal = (lpt3, 127), then this works to stop the trial. However, this doesn't fix my orignal problem with cycling through my trials. So it appears that this is a limitation with the software. I'm not sure how to fix the problem at the moment.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 103K
|
For how long does your device keep the pins high? Can you configure that duration?
|
|
|
|
|
DrLand
|
|
|
Group: Forum Members
Posts: 14,
Visits: 38
|
This isn't something that I can control. I am tracking the trajectory of a ball toss. When the ball crosses a start line, my motion analysis system will turn pin 2 to high. When the ball rolls past the finish line, the system turns pin 2 back to low.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 103K
|
Here's an idea. Simply have another <trial> check for the 'low' state instead of using /posttrialsignal. I.e., do
<trial checkportsignal> / stimulusframes = [1=button] / inputdevice = lptdata3 / validresponse = (241) / branch = [trial.checkportstatuschange]</trial>
<trial checkportstatuschange> / inputdevice = lptdata3
/ validresponse = (242) </trial>
That should do the trick (provided I'm not missing anything).
|
|
|
|
|
DrLand
|
|
|
Group: Forum Members
Posts: 14,
Visits: 38
|
Bingo! That's it! The level of support on this site is unmatched. Thanks for all the help.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 103K
|
Great! And thank you for the kind words, too!
|
|
|
|
|
DrLand
|
|
|
Group: Forum Members
Posts: 14,
Visits: 38
|
Ok, to follow up on the previous script, I have run into another problem when reading inputs from the parallel port. I am wanting a sound stimulus to be played when a correctresponse occurs from the parallel port. Here is the code:
<trial lowtones> / stimulusframes = [1=lowtrials] / inputdevice = lptdata3 / validresponse = (241, 244) /correctresponse = (241) /correctmessage = true(lowtone, 1000) / branch = [trial.trialendcheck] </trial>
<trial trialendcheck> / inputdevice = lptdata3 / validresponse = (244) </trial>
The trial starts and stops fine, but no tone is played. However, if for instance I don't use the parallel port for the input, but base it on a keyboard command...the tone plays when the correct response is given. It's only when I'm using the parallel port input that I'm not getting the sound feedback.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 103K
|
What happens when you use /responsemessage instead of /correctmessage?
/ responsemessage = (241, lowtone, 1000)
Also, what do the 'response' and 'correct' columns in the data file actually indicate for the given trial? Are the values recorded there '241' and '1', respectively?
|
|
|
|
|
DrLand
|
|
|
Group: Forum Members
Posts: 14,
Visits: 38
|
Hi Dave, Thanks for your quick response. Your reply cued me in to the problem. I have it working now. It works with both the /responsemessage and /correctresponse. Basically what was happening was...at the start of the trial, one pin I had set to go high, and another set to go low. At the end of the trial, the pins would switch in preparation for the next trial. Even though I was switching both pins at the "same" time, one pin was switching first and thus throwing a different value for a split second. So my data output file wasn't showing the correct value. I was able to fix this on the device side of things.
One final quick question: My trials are based on input from the parallel port, but it would be nice if I could /stop a block early with input from a keyboard. I believe I read in the documentation that you couldn't mix parallel port inputs with a keyboard input. I wasn't sure if there was any work around for this.
|
|
|
|