This is just a formal reminder to @lkfink and I that we need to implement a simple constant parsing routine in python so that the GUI uses the correct constants (some assumptions might be necessary, but see below).

Just a thought, but we could potentially save ourselves even more trouble by defining a magic number that we increment each time GEMConstants.h is changed, that way the GUI can query the master Ardunio for the version that its code was compiled with and check that against the file that it parses (throwing an error on mismatch). Of course we'd still have to remember to update the magic number...

We need to be able to send and log timestamped events from the Master Arduino to the Experiment Control Computer (ECC) via the serial (USB) connection. Communication needs to happen at a high baud rate, e.g. 115200. The messages need to be structured in order to identify the data that is being transmitted: they need timestamps and identifiers.

Timestamps are obtained using the millis() command
Event codes should be defined in GEMconstants.h

This is a very far off enhancement but just wanted to start a discussion about the eventual data visualization in the data viewer.

Initially I imagined an electrophysiology-like viewer with lines for each of the slave channels displaying a tick any time anyone tapped and then vertical full screen lines for windows (gray) and metronome (black), with slaves all having their own color.

However, yesterday Petr mentioned wanting to know the stdev in real time and it occurred to me that we could use something like visual python to have a pulsing circle or 3D ball that would get narrower or wider depending on error. I came across this (really in depth) arduino and Vptyon tutorial while searching for something else yesterday and wanted to archive it here before I lose it.

Arduino + Visual python: http://www.toptechboy.com/using-python-with-arduino-lessons/

Vpython: http://vpython.org/

Petr & Scottie, What do you think would be the best type of visualization? We can use this thread for brainstorming and keeping track of resources.

I'm opening an issue on this for discussion purposes, it's not really an issue per se, as I wanted to highlight the direction I'm going in order to 1) provide a note to @lkfink so she can get a sense of what needs to happen in the GUI system to set parameters on the master Arduino (and have it actually start a run etc.) and 2) so that the design can be looked at by all. Note that this is experimental (thus i moved it to a new branch: dev-stateful). Changes are summarized below:

1. Constants system

   • Each family of constants has their own (small) range, see GEMConstants.h for details
   • Added constants for state logic found in Master_Adaptive.ino

2. Master Arduino state system

   • the loop() function now simply checks the global GEM_CURRENT_STATE and calls the corresponding state function (either run() or idle() etc.)
   • each state function is responsible for transitioning based on messages from the ECC
   • the run() function is essentially just a copy of the old loop() function
   • the idle() function allows for setting parameters (so far just met.alpha and met.bmp/ met.ioi), as well as more verbose communication (that is currently a TODO)

In short: the master Arduino boots in the IDLE state, runs the setup() function etc., then waits for messages from the ECC and parses them (setting parameters as requested etc.). Once the ECC requests a transition to the RUN state (by sending the constant GEM_STATE_RUN) loop() will begin calling the run() function instead; however, the metronome will not start until GEM_START is received (i.e. after the transition to the RUN state). Stopping the metronome immediately returns us to the IDLE state, requiring the ECC to send GEM_STATE_RUN followed by GEM_START to restart the metronome etc. This prevents state transitions while the metronome is playing. As it stands the system is a little clunky, but as stated above it's experimental.

General / design related comments are welcome. All implementation details should be considered as preliminary / alpha versions. Ultimately, a robust stateful design is what was/is planed for the lkfink-patch-1 branch, so that will, time permitting, function as a version 2.0 of this system in the future.

We need to update/fix the existing wiring diagram and annotate it with resistor values, etc. The current diagram appears to have errors in it, insofar as resistors between ground and FSR that should be the same are not, in fact, the same. They should be 10 kOhm. Not quite sure what the value is or should be for the pullup resistors on the interrupts because I can't find any circuit documentation in the Google Drive folders. (Because circuit.io appears to have been bought by Autodesk, the designs we created and linked to in our Google Doc are lost forever - a reminder that external links are rarely stable.)

Also, the resistors populating the actual GEM rig are not the same as what is on the diagram. The actual values being used are:

• for connections to ground: 47k (yellow, violet, orange)
• for interrupt pullups: 3.1k (orange, brown, red)