| Both sides previous revision Previous revision Next revision | Previous revision |
| report:dvp [2026/06/19 13:42] – [7.4.3 Structure] team4 | report:dvp [2026/06/22 19:10] (current) – [7.6.3 Software] team4 |
|---|
| This capability makes the ESP32 particularly suitable for applications that spend most of their time in a low-power state and only wake periodically to perform measurements or other tasks. By minimizing the active time and remaining in deep sleep for the majority of the operating cycle, the overall energy consumption of the system can be significantly reduced, resulting in longer battery life. | This capability makes the ESP32 particularly suitable for applications that spend most of their time in a low-power state and only wake periodically to perform measurements or other tasks. By minimizing the active time and remaining in deep sleep for the majority of the operating cycle, the overall energy consumption of the system can be significantly reduced, resulting in longer battery life. |
| |
| Compared to the other evaluated alternatives, presented in {{ref>tab:McComparions}} the ESP32 was the only platform that combined deep sleep support with an integrated RTC and extremely low sleep current. These characteristics made it the most suitable choice for an energy-efficient embedded system. | Compared to the other evaluated alternatives, presented in Table {{ref>tab:McComparions}} the ESP32 was the only platform that combined deep sleep support with an integrated RTC and extremely low sleep current. These characteristics made it the most suitable choice for an energy-efficient embedded system. |
| |
| <WRAP> | <WRAP> |
| Selecting sensors was quite challenging, as most sensors such as pH and conductivity probes are designed for temporary measurements and not for long term submersion. Additionally, the sensors must withstand the high pressure at the seabed, and many are not suitable for seawater. This resulted in expensive sensors, mainly sourced from suppliers in the United States. | Selecting sensors was quite challenging, as most sensors such as pH and conductivity probes are designed for temporary measurements and not for long term submersion. Additionally, the sensors must withstand the high pressure at the seabed, and many are not suitable for seawater. This resulted in expensive sensors, mainly sourced from suppliers in the United States. |
| |
| The BarXT sensor [(BarXT)] measures both pressure and temperature. The pressure measurements can be used to calculate depth. Unlike systems based on 5 V microcontrollers, the ESP32 operates with 3.3 V logic levels, which are compatible with the sensor's I<sup>2</sup>C (Inter-Integrated Circuit) interface. Therefore, no I<sup>2</sup>C level converter is required, simplifying the hardware design and reducing power consumption. | The BarXT sensor [(BarXT)] measures both pressure and temperature. The pressure measurements can be used to calculate depth. Unlike systems based on 5 V microcontrollers, the ESP32 operates with 3.3 V logic levels, which are compatible with the sensor's Inter-Integrated Circuit (I<sup>2</sup>C) interface. Therefore, no I<sup>2</sup>C level converter is required, simplifying the hardware design and reducing power consumption. |
| |
| The pH sensor [(PhProbe)] is sourced from Atlas Scientific. It is used together with a pH module [(PhModule)], which converts the signal into an analog signal that can be directly read by the microcontroller's analog inputs. | The pH sensor [(PhProbe)] is sourced from Atlas Scientific. It is used together with a pH module [(PhModule)], which converts the signal into an analog signal that can be directly read by the microcontroller's analog inputs. |
| ==== 7.6 Prototype ==== | ==== 7.6 Prototype ==== |
| |
| The prototype is designed to measure similar parameters to a CTD (Conductivity, temperature and Depth) system, but instead of using a conductivity sensor to estimate salinity, it uses a TDS sensor. This is a significantly cheaper alternative and is sufficient for early-stage testing, where the main goal is to validate the system concept rather than achieve final measurement accuracy. The pH sensor is also excluded from the prototype in order to reduce cost, since it is not essential for testing the basic functionality of the system. Apart from the sensor selection and reduced measurement precision, the prototype follows the same general system design as the final product. For the enclosure, a simple airtight plastic container (e.g. from IKEA) is used as a temporary solution. This significantly reduces costs compared to waterproof enclosures and is sufficient for controlled testing environments. To ensure watertight cable penetrations in the prototype, a silicone‑based sealant will be used. The same sealant may also be applied around the enclosure lid if leakage is detected during testing. | The prototype is designed to measure similar parameters to a Conductivity, temperature and Depth (CTD) system, but instead of using a conductivity sensor to estimate salinity, it uses a TDS sensor. This is a significantly cheaper alternative and is sufficient for early-stage testing, where the main goal is to validate the system concept rather than achieve final measurement accuracy. The pH sensor is also excluded from the prototype in order to reduce cost, since it is not essential for testing the basic functionality of the system. Apart from the sensor selection and reduced measurement precision, the prototype follows the same general system design as the final product. For the enclosure, a simple airtight plastic container (e.g. from IKEA) is used as a temporary solution. This significantly reduces costs compared to waterproof enclosures and is sufficient for controlled testing environments. To ensure watertight cable penetrations in the prototype, a silicone‑based sealant will be used. The same sealant may also be applied around the enclosure lid if leakage is detected during testing. |
| |
| |
| |
| |
| The system is an automatic water quality logger built on an Arduino Uno. It continuously reads data from several sensors and writes the measurements to a CSV file on an SD card every 10 seconds. The system is controlled by a switch that pauses and resumes logging without requiring a restart. | The system is an automatic water quality logger built on an Arduino Uno. It continuously reads data from several sensors and writes the measurements to a Comma-separated values (CSV) file on an SD card every 10 seconds. The system is controlled by a switch that pauses and resumes logging without requiring a restart. |
| |
| **Libraries** | **Libraries** |
| |
| When the logging interval has passed, the software retrieves the current time from the RTC module and writes the timestamped sensor data to the SD card. After the data is saved, the program returns to the switch check and repeats the process continuously. This flow ensures that the prototype automatically collects and stores environmental data in a structured way. Figure {{ref>fig:flowchart}} shows the software flowchart of the Maris Habitats prototype. | When the logging interval has passed, the software retrieves the current time from the RTC module and writes the timestamped sensor data to the SD card. After the data is saved, the program returns to the switch check and repeats the process continuously. This flow ensures that the prototype automatically collects and stores environmental data in a structured way. Figure {{ref>fig:flowchart}} shows the software flowchart of the Maris Habitats prototype. |
| | |
| | |
| |
| |
| <WRAP centeralign> | <WRAP centeralign> |
| <figure fig:flowchart> | <figure fig:flowchart> |
| {{ :report:maris_habitats_flowchart.png?nolink&600 |}} | {{ :0:flowchart_prototype.png?600 |}} |
| <caption>Software flow chart</caption> | <caption>Software flow chart</caption> |
| </figure> | </figure> |