Currently the error points for DIY2's code call the error function with a hard-coded integer i.e. error(2). It would be better to use an enum for this which could convey the name of the error.

If the RTC loses power (main and backup), it loses track of time. When powered, it will store a time at the beginning of the year 1900. This causes issues because it is out of range for some time operations which use Unix time (epoch = January 1st 1970). If we detect the time is out of range, we should reset it to a time in 2000.

Obviously if the RTC is out of date, there is an issue with the device. Hopefully, it is simply that the device lost power and/or the backup battery died. However, during testing and deployment this doesn't need to be a fatal error, and data could still be recorded so long as the RTC is functioning. This would be more desirable than throwing a fatal error.

The current library (https://github.com/rodan/ds3231) works, but misses some desirable functionality and quality of life improvements:

• The DS3231_init function should return a boolean signalling whether I2C was successful with the DS3231. If the DS3231 is missing or unresponsive, the program should enter an error state.
• The library has a function to convert a timestamp to epoch time, but not vice versa.
• The DS3231_set_a1 and DS3231_set_a2 functions require an array of values for the flags. This is clunky, and should instead use a bitmask.

So far it hasn't caused any (recorded) issues by keeping them on, but according to https://thecavepearlproject.org/2017/05/21/switching-off-sd-cards-for-low-power-data-logging/ and https://www.youtube.com/watch?v=2yFh7Vv0Paw, it might be worth looking into

Usually the buffer is set at 120 entries:

It would be more effective to write the buffer size (and perhaps even the entry size / format?) in the top of each .data file created by the script. We could write this using regular ASCII and then the rest of the data would remain in a binary format.

There are two reasons this could be useful

1. On the small chance that power is removed when an SD card write is in progress, it could result in data loss
2. Since the DS3231 RTC is being pin-powered and is normally battery powered, it will continue generating an alarm pulse on battery unless reconfigured not to. This seems to drain the coin cells I've been using within a year or two (sometimes less), rather than the supposed 10 year mark I've read about online

The device should create a log file whenever an error is encountered. Otherwise, if a logger stops working in the field, it's hard to diagnose the problem.

The user should be able to specify a start time in the config file on the SD card, and have the device sleep until this time. This would allow the device to be turned on and sealed in the housing before entering the field, without wasting power and storage space by sampling.

The LED on the FireBeetle board should flash as the device takes the first 5 to 10 samples to signify that the device is working properly.

All devices should be programmed to make at least one attempt to reboot / restart whenever an error is encountered. Especially with DIY4 and turning on/off the SD card, it seems that it is possible for fluke SD card communication failures that would probably be resolved by a reboot.

Although pin-powering the DS3231 (i.e. using a GPIO pin to power the DS3231) results in less current draw from the primary batteries, it ends up draining the DS3231's coin cell much more quickly. The coin cell backup is supposed to be able to keep time for ~10 years under normal circumstances, but we also make use of the DS3231's once-per-second alarm function to wake the device up to take pressure readings. This not only drains the battery faster during use, but unless it is disabled, it will continue to wastefully create these alarm pulses even when the device is unused. I've had a few coin cells die after ~1 year because of this.

The problem here is that now not only do we need to worry about checking the primary batteries before each deployment, but we also need to check (and replace) the coin cell frequently. There are two things I can think of to reduce this problem:

1. Always keep the DS3231 pin-powered. I'll need to compare the current draw from this approach, which I think I did at one point, but I don't remember how big the difference was. In this case, we would expect that ~10 year life span.
2. Have a way to disable the RTC once-per-second alarm pulses when the device isn't being used. This would at least prevent the battery from being wasted. The trouble is that the user would have to remember to do this, since there's no opportunity in the code to do anything before the device is powered down (it's a hard shutdown). Currently the best approach I can think of would be to disable the alarm whenever an error is encountered in the main program, so that if the user wanted to disable the alarm, they could simply remove the SD card, turn on the device (which would then error since it wouldn't detect an SD card) and then power down the device until they intend to use it. At least with this approach, the user wouldn't have to reprogram the device or use some other device to reprogram the DS3231 and disable its alarm.

I don't think these notes belong in the docs, so I'll move them to another repo or blog or something.

When data is downloaded from multiple sensors, currently they all create log files named "log.txt" which makes it hard to distinguish which log applies to which sensor.

Whenever a custom error is encountered (i.e. can't find SD card, can't find MS5803 pressure sensor), the device enters an endless loop of blinking an LED a certain number of times per second, which indicates the type of error. This error state uses lots of energy because the main ESP32 chip is awake. However, the same task could be executed by the ULP co-processor while the main chip is in deep sleep. This would increase the chance of the device lasting long enough to still be producing the error code upon collection, allowing the human operator to know what went wrong.

Perhaps the device should even just shut off after a certain amount of time. The problem here is that it could be confused with the device functioning properly :)

Lower sampling frequencies would be relatively easy to implement naively.

Higher sampling frequencies (i.e. 4Hz) might be more attractive for boat wake measurements, but would require some more thought to implement.

The alarm on the DS3231 only runs as fast as 1Hz, so we would have to either use the 32KHz generator or a clock in the ATmega328p / ESP32 to time wakeups at <1sec periods.

Currently, the program prints out some information during setup, but it would be nice to see more:

• When initializing each component, we currently print a related message if an error occurs, but we should also have a "success" message for each successful initialization.
• We should print more of what we are doing during each part of the setup e.g.

Initializing DS3231... Done
Reading time from DS3231...
    Time is yyyy-mm-dd HH:MM:SS
    Done

... and more

• After setup is complete, we currently print out the pressure readings and timestamp whenever the data is dumped to the SD card. It would be nice to have data printouts as they are being measured. This is tricky though, because data is collected using the ULP, so either we would have to modify the assembly code to print it (we would also need to bypass the default max ULP program size to do this), or have an interrupt wake up the main processor to print it. Might not be worth the effort.