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

Not Enough Airpuffs During Pre-Opto Sessions. #157

Closed
jmdelahanty opened this issue Apr 25, 2023 · 2 comments · Fixed by #158
Closed

Not Enough Airpuffs During Pre-Opto Sessions. #157

jmdelahanty opened this issue Apr 25, 2023 · 2 comments · Fixed by #158
Assignees
Labels
enhancement New feature or request

Comments

@jmdelahanty
Copy link
Contributor

While doing data analysis of the newest CMS Cohort, Jim has run into problems where a mean is being attempted upon just one datapoints. There is currently no check that the pre and post opto stages have adequate numbers of airpuff trials in particular. While there are checks to ensure that there are at least the appropriate amount of airpuffs overall and that enough are present in the opto stimulation trials themselves, there aren't checks in place ensuring that there's a certain amount scheduled before and after.

This can be solved by both increasing the amount of airpuff trials and, mostly, generating trials as described in #148 as Autopilot does.

@jmdelahanty jmdelahanty added the enhancement New feature or request label Apr 25, 2023
@jmdelahanty jmdelahanty self-assigned this Apr 25, 2023
@jmdelahanty
Copy link
Contributor Author

Code in develop appears to solve this issue. Doesn't do it well, but added new configurability for pre-post opto airpuff trial numbers.

@jmdelahanty
Copy link
Contributor Author

It looks like this might not have been an issue after all, which is lucky honestly, but rather due to errant triggers being sent for either LEDs or shutter triggers somehow. Having what's in develop will make sure it's never an issue.

It doesn't make any sense yet how these triggers were sent. The configuration files don't have any scheduled prematurely and the only way it could happen in the Arduino code would be if there are pins set high errantly as well for a certain trial type, but there doesn't yet appear to be a pattern in it that would indicate a bug like this is the problem.

The only guess I have is either prairie view settings were incorrectly set, which has happened before as fixed in #139 (but that was solved months before and these LED triggers are happening at strange times in the middle of the recording ) or there was some strange grounding issue that was causing triggers in strange places when something was moved or a nearby pin was triggered...

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

Successfully merging a pull request may close this issue.

1 participant