Hi Taylor,
I double-checked the recordings with the problematic reward on and the problem is that it didn’t send the success event code at all. I tried to find all the success event codes but none was sent with the reward on.
OK. I suggested that it might be a data analysis issue, because I was remembering a previous question from your lab that involved an incorrect expectation about where e_reward_off could appear in the data stream. But it sounds like that isn’t the problem here.
I kept the maximum_time at 500 ms and the success event codes were sent if the reward_duration_target_acquired was >= 60 ms. The success event codes were still failed to be sent even if I increased the maximum_time to 2000 ms and kept the reward_duration_target_acquired at 50 ms. So it seems like the problem is the reward_duration_target_acquired being too short which is confusing.
That is indeed confusing. I guess we have to assume that when reward_duration_target_acquired is 60ms, e_stimulus_success is sent before e_reward_off, whereas at 50ms, they overlap and interfere with each other somehow. (Again, I don’t see how.) I wonder what would happen if you decreased reward_duration_target_acquired to 30 or 40ms. If an overlap is the issue, it seems like that should resolve it, too.
Also, out of curiosity, what is the value of fixation_requirement_stimulus?
Our solenoid of the reward system should open for a 50 ms reward and it shouldn’t affect the event code even if the solenoid doesn’t open?
Yes, whether or not the solenoid actually opens has no bearing on the data sent to the Blackrock. From MWorks’ perspective, opening and closing the solenoid means nothing more than toggling a digital output line on the VIEWPixx. Even if there were no solenoid connected to the output line, the experiment would proceed normally.
Chris