-
Notifications
You must be signed in to change notification settings - Fork 3
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
Move Away From Bruker's DAQ for Voltage Recordings #121
Comments
Deryn has made some cool progress in using 'pyserial' to gather events/timestamps from the Arduino as things are running. Would be cool to incorporate to things so there's both an events file generated at runtime as well as a raw output of high/low signals could be nice. Autopilot does both if you want which I think is cool also. |
If we want to incorporate this into the library it should probably be done through multithreading, but I don't know how to properly do that for this use case. I'm going to try chatting with Joel Yancey who knows a fair bit about doing this in the context of GUI programming and also see if Jonny has an appetite for teaching me how they do it in Autopilot. |
Somewhat relevant threading discussion here |
Now that I have successfully (maybe) done some multiprocessing I need to see if I can get my little NIDAQ grabbing information and collecting data in the "long form" that Jonny recommends you do as it's own process or threading situation. Another thing that would be cool would be if there was both the longform and short form data collection that happened concurrently from the DAQ so there could be timestamps of events with trial numbers attached as well as the trial number associated with the longer form data stream. |
A low priority/probably won't have time to do successfully but something that should definitely be done is invoking a recording of file to disk of the voltage data using a NiDAQ or something similar. This would not only allow us to have more than just the 7 channels that Bruker gives us but also much more control over how data is written to disk. I have a little NiDAQ box that could be used for this purpose. One of the main issues that we could run into is that executing this in the background will require us to do several bits of additional work that would likely require a fair bit of testing to get right/reliable. Long term this is something that should be done regardless of what happens to this repository probably.
The text was updated successfully, but these errors were encountered: