Millisecond Forums

Trial Port display milliseconds are off

https://www.millisecond.com/forums/Topic10698.aspx

By Lostcode - 6/20/2013

I have a trial that runs like so:

<trial wordy>
/ stimulustimes = [0=word, wordPort; 50=ZeroPort; 800=erase, breakPort; 850=ZeroPort]
/ trialduration = 1600
</trial>


Unfortunately the second zero port shows on my output that from the breakPort to the ZeroPort the duration is about 16ms instead of the 50ms it should be.


Is there something I am not understanding for the coding?

By Dave - 6/20/2013

Impossible to tell without actually seeing the data. However, note that what you see in the 'stimulusonset' column for the 2nd instance of ZeroPort may reflect the onset of the 1st instance. You should either (a) use separate <port> elements


/ stimulustimes = [0=word, wordPort; 50=ZeroPort1; 800=erase, breakPort; 850=ZeroPort2]


or (b) log the element's indexed stimulusonset property to the data file (via the <data> element:


/ columns = [..., port.ZeroPort.stimulusonset.1, port.ZeroPort.stimulusonset.2, ...]

By Lostcode - 6/20/2013


Here is my data. The pulse widths should be 50 for everything but the zeroPort2 even after changing it shows it as 16ms.

By Dave - 6/20/2013

That image unfortunately doesn't say much without proper scale information as well as any indication where an actual trial starts and ends. Also, what is the pulse highlighted in green?


By Lostcode - 6/20/2013

The yellow is a marker that is 5 to 0 with 50ms separation.
The green is a 100's marker ending in 0 after 50ms
The red is suppose to be another 5 to 0 marker with the same 50ms but is actually 16ms



The height is the marker number and the length between the elevated lines is the marker number to 0. So the gap in-between the two elevated lines is milliseconds.



After the yellow marker is the beginning of the trial I posted.

By Dave - 6/20/2013

The green is a 100's marker ending in 0 after 50ms


And where is that coming from in your <trial> definition? I only see two pulses there.

By Lostcode - 6/20/2013

The green and red is a trial and then another green and red is either the same trial or one that's similar reading from a different item list.

The block uses a ratio of two trials. The trials are the same as the one posted.

Is there something in the block that would screw with this?

By Dave - 6/20/2013

The green and red is a trial and then another green and red is either the same trial or one that's similar reading from a different item list.


Could you clarify that graphically, please?



The block uses a ratio of two trials. The trials are the same as the one posted.

Is there something in the block that would screw with this?


I cannot tell you that without seeing the actual code. Have you checked the two involved <trial> elements and their stimuli for errors? The data might well be consistent with an error in one of the involved elements.


Also, (a) what is the system's refresh rate and (b) are you running the latest Inquisit 4 release (4.0.3)?

By Lostcode - 6/20/2013

found the problem. I have my responsetime = 0 which is effecting the zeroPort showing for some reason.

Remember I want a response to be issued for both in the trial. Trying to figure out how to allow only one response for the trial but can be responded for both the word and the erase I have set. The erase is a black screen.

I remember reading the /responsetime attribute and the / responseinterrupt attribute. What would be needed here for what I require?

By Dave - 6/20/2013


Remember I want a response to be issued for both in the trial.


A <trial> collects a single response. There is no way to collect two or more. You'll have to daisy-chain separate <trial> elements if that's what you want.

By Lostcode - 6/20/2013

Any Recommendations for a daisy chain for it? The trial must always have the other trial occur after it because a block I have uses that trial and another one show up randomly.

By Dave - 6/20/2013

The /branch attribute fits the bill.

By Lostcode - 6/20/2013

/ branch I have experienced trialduration complications when using this method. Like it would apply the trial duration from the last thing used to the duration of the next.

By Dave - 6/20/2013

/ branch I have experienced trialduration complications when using this method. Like it would apply the trial duration from the last thing used to the duration of the next.


I am not aware of any such issue and don't see why that would be. /branch has nothing to do with a given <trial>'s /trialduration. If you have any code showcasing that issue, please feel free to share it.

By Lostcode - 6/20/2013

I'll check back through my versions after fixing this current problem and send it to you if I still have it.

By Lostcode - 6/20/2013

Real quick. If I do a / branch [if() trial.whatever] is there a command for to say like

if(trial.whatever1.runs) trial.whatever2? <--- meaning if trial whatever1 ran then run trial whatever2

Or do I need to setup a count or a generic value that it will reference that will always make it run the next trial?

By Dave - 6/20/2013

A /branch need not be conditional. Suppose you have <trial a1> and <trial a2>. You always want a2 to follow a1:


<trial a1>
[...]
/ branch = [trial.a2]
</trial>