Not OP but > I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers. From my POV as a software developer, C has

Not OP but > I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers. From my POV as a software developer, C has so many pitfalls that it is incomprehensible to me that things will Just Work, especially in the context of something that is meant to run for a very long time and not be "restarted." You aren't meant to make no mistakes, just only make recoverable mistakes. In a lot of cases you can rely on your hardware for this. Watchdog Timers are specifically intended for this. You set up a watchdog when you deploy the device and your software has to periodically "pet" the watchdog or the system triggers some action. In practice this is used to verify that the software never gets stuck or else it triggers a recovery/restart sequence and maybe sends out an alert. The end goal shouldn't be bug free but "even with bugs it eventually recovers and keeps working unless the hardware physically dies". > Why do sensor things at all? What is the ROI for the person who needs that stuff? I mean this in no derogatory sense, I really admire this work. Once again not the OP but I could see this being useful. They are recording wave patterns on or around a reef. That could be used for modelling how reefs can buffer water conditions (ex: for the purpose of constructing man made analogues) or as part of a greater sensor suite for documenting how "weather" impacts reef ecosystems. And you would want a system you can deploy and leave unattended for long periods of time since every trip out costs money and depending on what you are specifically researching, simply returning to the site could interfere with/disrupt the experiment.