Day 10: Late update!

Last Friday

At the end of the day, we hit a snag. My agenda for the day was simple enough:

* pick a new scalar for the PSI to cm conversion based on water density by temperature
* Turn program into several programs, one for each function
* Comment the code
* Shorten the loop to 1 sec if possible

In terms of modifying the code, all of these tasks were complete by 11 AM. Even further, with the help of Dr. Stonedahl, I simplified parts of the code that are expected to be modified in the future in a way that anyone could manage to make small changes without breaking the program.

//CHANGE THESE NUMBERS FOR DIFFERENT SINE FUNCTIONS
float amplitude = 5; // cm
int period = 120; // sec
float shift_up = 2; // cm
//STOP CHANGING

//CHANGE THESE NUMBERS FOR DIFFERENT MEASUREMENT CONSTANTS
double water_density = 997.608; // kg / m^3 at 22 celcius
double gravity = 9.8061579; // m / sec^2 at 177 m altitude
float sensor_shift_up = 0; // cm
//STOP CHANGING

We wanted the code to be tested and debugged before running tests on Monday, so we loaded up the sinewave program, removed the delay at the end of the code, and let it run. Without the delay, the code is iterated through quickly, as a result the outlet for the water pumps rapidly switch on and off to follow the curve. Along with the rapid switching, the Arduino eventually stops printing to the console we're running, and corrupts data on the SD card.

Both printing to the console and writing to the SD card use the Serial class. My best guess is that something is happening with the Serial class, causing the both problems. Our list of possible sources of this issue are as follows:

* There may be too many computations between iterations, so reduce computations where possible.
* The delay might be required for proper functioning, so play around with different delay values.
* The rapid state change on the output pin to the power outlet might be changing too rapidly, so also play around with larger margins of error if adding a delay isn't enough

Continuing the debugging, we stuck a 2 second delay back in the code, however, eventually we'd run into the same issue. We were left to revert to the code for the Trujillo presentation. That ran without issues, but it still had a 2 second delay. I don't recall if removing the delay led to any issues, so I currently have the Trujillo demonstration code running without delays now.

Unlike the sinewave program, the Trujillo demonstration uses constants as thresholds for changing the on-off states of the outlet. If the water level is at 10 cm or below, turn on the pump, else if the water level is at 20 cm or higher, turn off the pump. So, if it runs without issue, without any delay, that may strengthen the hypothesis that the rapid state change of the output pin is related to the issue, and not simply iterating through the program without delays.

Both the sinewave and the Trujillo demonstration programs access the SD Card to open a file, write a few data points to the file, then close the file with every iteration. Perhaps accessing the SD card so frequently in a short period of time is what's corrupting the SD Card. The only way I can think to rule that out is to run the Trujillo demonstration for a moderately long period of time, then checking the SD card.