This bug came up in analyzing #4. When jstim is run a second time, jrecord reports an event on the trig_in port with the previous stimulus's message and a status of stim_off. For example:
20131221T110444.963646 [jrecord] D: trigger on event: time=208355328
20131221T110444.978528 [jrecord] created entry: /jrecord_0002 (frame=208307328)
20131221T110444.978673 [jrecord] I: writing pretrigger data from 208307328--208355328
20131221T110444.978723 [jrecord] D: prebuf frame: t=208307200, on=128, id=stim, dtype=0
20131221T110444.978913 [jrecord] created dataset: /jrecord_0002/stim
20131221T110444.979764 [jrecord] created dataset: /jrecord_0002/trig_in
20131221T110444.979826 [jrecord] D: event: t=208347460 id=trig_in status=16 message=F9698B0C2CA2A2BDF417E8F4891EE5F0
20131221T110444.980446 [jrecord] D: event: t=208355328 id=trig_in status=0 message=07E250DFF0DEF4C41369A5506E2A1C85
This extra event may or may not get stored in the dataset for that entry. Interestingly, this problem can persist across multiple runs of jrecord, suggesting that the event is hanging around in the jack port buffer.
This bug came up in analyzing #4. When jstim is run a second time, jrecord reports an event on the trig_in port with the previous stimulus's message and a status of stim_off. For example:
This extra event may or may not get stored in the dataset for that entry. Interestingly, this problem can persist across multiple runs of jrecord, suggesting that the event is hanging around in the jack port buffer.