PlayGround

This chapter presents the development of Maris Habitats from concept to prototype. It briefly covers the design, structure, smart system, software, and testing process.

Transitioning from a theoretical model to a functional underwater prototype involves a rigorous process of synthesis and troubleshooting. This chapter documents the technical execution of the project, detailing the mechanical assembly, electronic integration, and software architecture of the Maris Habitats system.

It serves as a technical log of the development lifecycle, highlighting how the theoretical foundations established in Chapter 2 were translated into physical components. From the challenges of ensuring watertight integrity for the sensor housing to the development of a reliable self-contained monitoring system with local data storage, this section provides a comprehensive look at the engineering challenges addressed during the fabrication and programming phases.

The goal of this project is to design artificial marine habitats that can help endangered fish species and corals thrive again. Climate change and the warming of the oceans are disturbing marine ecosystems and damaging the natural balance of life underwater. Because of this, many species are losing safe places to live, hide, feed, and grow. The design is therefore focused on supporting nature itself, especially fish, corals, and other marine organisms.

The structure had to meet several important requirements. It had to be modular, so that different units could be combined and adapted depending on the location and the needs of the ecosystem. It also had to be made from a material that would not harm the marine environment. Since corals need to grow on the structure, the material had to be suitable for marine life and preferably porous. At the same time, the habitat could not be excessively large or heavy, since this would complicate transport and installation. The design therefore had to balance practical deployment with sufficient weight and stability to remain in place and withstand sea currents.

To develop the concept, the team started with brainstorming sessions and research into similar existing projects. Different types of artificial reefs and marine restoration systems were researched, and also which materials could safely be used in the sea were studied. During this ideation phase, the creation of around six to seven different structural concepts was crucial. While the overall shapes of these concepts were quite similar, the main differences were in the materials and possible additional features such as sensors.

Several material options were explored, including basalt fabric-reinforced structures, polymer-clay, bacterial HSC, ECOncrete, recycled glass, and Biorock. Each material had its own advantages and disadvantages. Some were more expensive, while others were less suitable for coral growth or did not provide the level of porosity needed by marine organisms. Since fish and corals benefit from rough and porous surfaces, this became an important factor in the decision-making process.

After comparing the different options, basalt fabric-reinforced concrete was selected as the most suitable material for the project design. This material offered a strong balance between cost, weight, stability, and ecological suitability. It is not overly expensive, heavy enough to remain stable underwater, and easy to shape into modular forms. In addition, its porous surface makes it a good choice for encouraging coral growth and creating shelter for fish. The material can be formed by first making a mould in the desired shape and then placing the basalt fabric or mesh inside it. Depending on the required strength, the fabric can be arranged in one or several layers. Fine concrete or mortar is then poured, sprayed, or pressed around the reinforcement. After curing, the concrete becomes rigid while the basalt fabric remains embedded inside as reinforcement. For these reasons, basalt fabric-reinforced concrete was chosen as the best material for the final concept.

The final concept selected for Maris Habitats is a modular artificial marine habitat built from one repeated cone-shaped element, as shown in Figure 35. These modules can be connected side by side and stacked vertically, allowing the habitat to be expanded according to site conditions and ecological requirements. By using one repeated part, the system remains simple, scalable, and easy to reproduce, while still allowing a wide variety of structural arrangements.

The concept was selected because it provides a strong balance between ecological function and practical feasibility. Different configurations of the same module can create both smaller and larger shelter spaces, making the habitat suitable for a wide range of marine species. This adaptability is one of the main strengths of the concept, since different deployment sites may require different structural densities and sizes.

Another important aspect of the concept is the material choice. The habitat is intended to be made from basalt fabric-reinforced concrete, which combines structural weight and durability with a rough and porous surface suitable for marine colonization. This surface can support the attachment and growth of algae, corals, and other marine organisms, while the weight of the material helps the structure remain stable under underwater currents.

Compared to other design directions explored during the project, this concept proved to be the most suitable. Earlier ideas such as spherical, hexagonal, and dome-based structures (shown in Figure 36) were less effective because they were either not modular enough or too difficult to manufacture and combine efficiently. For this reason, the cone-based modular concept was defined as the final structural direction of the project.

This section presents how the selected concept was developed into a feasible structural solution for underwater deployment. The design process focused on translating the general concept into a habitat that is modular, manufacturable, stable, and ecologically suitable for marine colonization. The following subsections explain the main design decisions and the structural directions explored during the development process.

The design phase focused on transforming the selected concept into a structure that could function in an underwater environment while remaining feasible to produce and deploy. From the beginning, the most important design requirement was modularity. The habitat had to be based on one repeatable element that could be combined in multiple ways without becoming too complex to manufacture or assemble. This requirement guided the entire design process and strongly influenced the selection of the final form.

Several structural directions were explored during this phase, including spherical, hexagonal, and dome-like concepts. Although these ideas offered interesting spatial qualities, they were gradually rejected because they did not satisfy the design goals strongly enough. Some concepts were too difficult to produce in a simple and repeatable way, while others did not provide the level of modularity needed to expand the habitat efficiently. In contrast, the cone-based element provided a clearer and more practical solution. Because the same unit can be repeated throughout the structure, the habitat can grow both horizontally and vertically while maintaining a simple and consistent construction logic.

The chosen design also supports ecological performance. By connecting and stacking the modules in different arrangements, the habitat can generate openings and sheltered spaces of different sizes. This is important because smaller and larger marine organisms require different types of refuge. The repeated units also create a more complex three-dimensional environment, which improves habitat quality and increases the suitability of the structure for fish, algae, corals, and other marine species.

Material selection was another important part of the design phase. The final design is based on basalt fabric-reinforced concrete, chosen for its combination of strength, weight, and ecological suitability. The material is heavy enough to improve stability under underwater currents, while its rough and porous surface can encourage biological growth over time. In this way, the design responds not only to structural and manufacturing requirements, but also to the biological purpose of the habitat.

Overall, the design phase transformed the initial concept into a clear and buildable solution. Instead of developing a complex habitat composed of many different parts, the design process focused on a single repeated module capable of generating a wide range of spatial configurations. This decision improved the scalability, manufacturability, and ecological potential of the habitat, and formed the basis for the structural development presented in the following subsection.

The structural development of the habitat began with a series of exploratory concepts. These early ideas were useful for identifying the design characteristics that were most important for the project, such as modularity, ease of production, structural repetition, and the creation of different shelter sizes. The figures below illustrate the main structural directions considered during this process. Figure 37 shows an initial idea.

One of the first directions explored was a more enclosed structure, shown in the early sketch above. This concept helped define the importance of shelter, internal space, and protection for marine species. However, although it offered enclosed refuge areas, it was not considered the most suitable direction because it did not provide the same level of modular flexibility as later concepts. As the design process continued, greater importance was given to repeatability and scalability.

Figure 38 illustrates the proposed habitat modular design.

A second concept was based on a hexagonal module supported by pillars. This idea introduced a stronger modular logic and allowed several units to be connected into a larger structure. The concept was relevant because it explored how repeated modules could create a more adaptable habitat system. It also supported the study of elevated structures and the possibility of generating openings of different sizes. However, this direction was not selected as the final solution because the cone-based concept provided a simpler repeated form and clearer scalability (see Figure 39).

Further structural exploration focused on varying the dimensions and arrangement of the elements in order to create openings suitable for different marine species. This stage was important because it highlighted the ecological value of structural diversity. By studying how repeated parts could generate different internal spaces, the development process produced a clearer understanding of how geometry could influence habitat quality. These studies confirmed that the final design should allow variation in shelter size while still remaining based on one simple repeated part (See Figure 35 and Figure 40).

After comparing the different structural directions, a concept based on one repeated cone-shaped module was selected. This solution was considered the most appropriate because it combines modularity, manufacturability, and ecological functionality. The same unit can be repeated many times, allowing the structure to expand horizontally and vertically while maintaining a simple construction logic. As illustrated in Figure 41, the arrangement of these modules creates a more complex habitat geometry with multiple shelter opportunities for marine organisms.

When several modules are combined, the habitat can cover a larger area of the seabed and create a more complex three-dimensional structure. This makes the system adaptable to different sites and allows the scale of the habitat to be adjusted according to the intended application. For this reason, the final structure is not defined by a single fixed form, but by a repeatable modular logic that can be expanded according to ecological and practical needs.

After defining the final modular structure, a suitable method still had to be developed for inserting the smartlogger. The development process of this solution is explained below.

Design Process of Sensor Structure

Below you can see the first version of the smart block, in which the smartlogger was attached to the bottom of the modular structure. However, this solution was not aesthetically pleasing, so a new approach was explored in which the smartlogger could be integrated into the modular structure itself. It was also important to avoid changing the structure too much, since that would require separate moulds for these specific blocks, even though they would be produced in much smaller quantities than the standard blocks.

The first design iteration is shown in Figure 42, with a detailed view provided in Figure 43.

In the second variation of the smart block, the smartlogger was much more integrated into the structure. However, this version required many modifications to the standard block. Additional openings also had to be added to ensure that the sensors had sufficient exposure to the surrounding water. This made the solution inefficient and impractical. As a result, another approach was explored, with a stronger focus on modularity so that a completely new mould would not be required.

Consequently, an alternative solution was explored, with a stronger emphasis on modularity to avoid the need for a completely new mould. The second variation of the design is illustrated in Figure 44, while a front view highlighting the structural modifications is shown in Figure 45.

This led to the development of a modular sensor solution. The supporting structure is constructed from titanium alloy TC 4 and can be installed in any reef block as required. Its design allows for easy placement and removal, since the space provided for the smartlogger is slightly larger than the smartlogger itself. This extra clearance makes insertion and extraction easier during maintenance or replacement. In addition, the block intended to contain the smartlogger has a distinct shape compared to the standard blocks, making it easy to identify within the overall habitat structure. The sensor housing is positioned on two supporting tubes and secured with a chain attached to the host block, ensuring stability during operation (see Figure 46 and Figure 47).

To facilitate maintenance, a distinct block design is used for the sensor unit. Over time, biological growth such as algae is expected to accumulate on the reef structures, reducing visibility and making it difficult to distinguish individual components. By incorporating a visually and structurally identifiable block, the sensor unit can be reliably located and accessed, even after prolonged submersion.

In Figure 48 you can see the technical drawings of the Reef Block and the Smartlogger attachment.

To protect the smartlogger we designed a protecting roof so algea won't be growing on the smartlogger that much. In Figure 49 you see the roof attached to the Smartlogger.

Introduction

For the structural simulations, basalt fabric reinforced concrete was used as the material definition. This material was chosen because the structure is intended to be placed underwater and therefore needs to resist external water pressure while remaining strong, durable and relatively stiff. To define the material in SOLIDWORKS, several mechanical and thermal properties were entered. The most important values are an elastic modulus of 3.6 × 10¹⁰ N/m², a Poisson’s ratio of 0.20, a density of 2400 kg/m³, a tensile strength of 6.0 × 10⁶ N/m², and a compressive strength of 5.5 × 10⁷ N/m². These values are close to the expected behavior of a concrete-based material: the material is relatively stiff, has a high resistance to compression, but is much weaker in tension. This is important because concrete does not behave like a metal. It does not really “yield” plastically, but it is more likely to crack when the tensile stress becomes too high or crush when the compressive stress becomes too high. Therefore, the entered yield strength of 6.0 × 10⁶ N/m² should only be seen as an approximate reference value, mainly because SOLIDWORKS requires a yield strength for certain safety factor calculations. For this reason, the von Mises stress and standard factor of safety are not the most suitable failure criteria for this material. Instead, the first principal stress is used to evaluate tensile cracking, while the third principal stress is used to evaluate compressive failure. The simulation process was carried out in two stages. First, one separate module was analyzed to understand the basic behavior of a single part under underwater pressure and gravity. This helped to identify the main stress concentrations, displacement pattern and general stiffness of the geometry. Afterwards, a larger assembly of multiple connected modules was simulated to evaluate how the complete structure behaves when the load is distributed over the full system. The goal of these simulations is to check whether the stresses remain below the assumed tensile and compressive strength of the material, and whether the displacement and strain stay limited. Ideally, the results should show low deformation, acceptable principal stresses and no critical compression or tensile cracking zones. Special attention is given to the connections between the vertical supports and the beams, because these areas are expected to create the highest local stress concentrations.

Stress test concrete block

The simulation indicates that the basalt fabric reinforced concrete structure can withstand the applied underwater load case. With an external water pressure of approximately 300,128 N/m² on all sides and gravity included, the maximum von Mises stress is about 0.801 MPa, which is significantly lower than the assumed yield strength of 6.0 MPa. This gives an estimated factor of safety of approximately 7.5, meaning the structure remains well within the safe range. The highest stresses occur near the connection between the cone-shaped supports and the central beam, which is expected because these areas act as stress concentrations. However, the stresses remain below the material limit, so the design appears structurally safe for this simplified underwater pressure load case. Keep in mind that for concrete-based materials, it is also useful to check the maximum principal tensile stress, because cracking usually starts due to tensile stresses rather than yielding.

Displacement test concrete block

The displacement result shows that the structure deforms only very slightly under the applied underwater pressure and gravity. The maximum resultant displacement is approximately 2.706 × 10⁻³ mm, which is only 0.0027 mm. This is extremely small, meaning the structure remains very stiff under the simulated load case. The largest displacement occurs near the upper edges of the cone-shaped supports, especially around the openings, while the lower areas show almost no displacement. This deformation pattern is expected because the upper parts are less constrained and can move slightly more than the base regions. Overall, the displacement result confirms that the structure experiences negligible deformation at a depth of approximately 30 meters, so from a stiffness point of view the design appears safe for this simplified underwater loading condition.

Strain test concrete block

The strain result shows that the structure experiences very low deformation under the applied underwater pressure and gravity. The maximum strain is approximately 1.419 × 10⁻⁵, which is very small and indicates that the material is only slightly stretched or compressed. The highest strain occurs around the transition zones between the cone-shaped supports and the central beam, especially near the lower connection areas. This matches the stress result, where the same regions also showed the highest stress concentrations. However, the strain values remain low, meaning the structure is not deforming significantly and the material is behaving safely within the assumed load case. Overall, this strain plot supports the conclusion that the design is structurally stable under the simplified 30-meter underwater pressure condition.

Factor of safety concrete block

The factor of safety plot confirms that the structure remains safe under the applied underwater pressure and gravity load case. The minimum factor of safety is approximately 7.49, which is well above the usual minimum requirement of 1.5–2.0 for many static structural checks. This means that the maximum stress in the structure is still far below the assumed material strength. Although most of the model appears red, this does not mean failure; it only means these areas have the lowest safety factor within the selected color scale. Since the minimum value is still around 7.5, the structure has a large safety margin. The most critical region is again located near the connection between the cone-shaped support and the central beam, which matches the stress and strain results. Overall, the design appears structurally safe for this simplified 30-meter underwater loading condition.

Strength test full structure

The von Mises stress locally exceeds the assumed yield strength, but since the material is concrete-based, von Mises stress and yield strength are not the most appropriate failure criteria. This result should therefore not be interpreted directly as failure. Instead, the maximum principal tensile stress should be checked, because cracking in concrete usually starts due to tensile stress. In addition, the compressive strength should also be evaluated to verify whether the material remains safe under compression. The high von Mises value mainly indicates a local stress concentration, most likely near a connection or constrained area. If the maximum principal tensile stress stays below the tensile strength and the compressive stress stays below the compressive strength of the material, the structure can still be considered acceptable for this simplified load case.

Tensile strength test full structure

The maximum principal tensile stress is approximately 2.998 MPa, which is lower than the assumed tensile strength of 6.0 MPa. This gives an estimated safety factor of about 2.0 against tensile cracking. Since concrete-based materials are more likely to fail by cracking than by yielding, this result is more relevant than the von Mises stress. The result indicates that the structure remains acceptable in tension for this simplified load case. However, the compressive stress should also be checked separately by evaluating the third principal stress or compressive stress result.

Compressive strength test full structure

The third principal stress was evaluated to check the compressive behavior of the concrete-based material. The maximum compressive stress is approximately 6.404 MPa, which is significantly lower than the assumed compressive strength of 55 MPa. This gives an estimated safety factor of about 8.6 against compressive failure. Therefore, the structure appears safe under compression for this simplified load case. Combined with the first principal stress result, which remains below the tensile strength, the structure can be considered acceptable from both a tensile cracking and compressive strength point of view.

Displacement test full structure

The displacement plot shows that the maximum resultant displacement is approximately 5.141 × 10⁻² mm, or 0.0514 mm. This is a very small deformation, so the structure remains quite stiff under the applied load case. The largest displacement occurs locally near one of the upper support/connection areas, while most of the structure stays in the lower displacement range. This is expected because the connected structure can deform slightly more at the upper and less constrained regions, while the fixed lower supports remain almost stationary. Overall, the displacement result is acceptable and confirms that the structure does not experience significant deformation under the simulated underwater pressure and gravity loading.

Strain test full structure

The strain plot shows a maximum strain of approximately 6.962 × 10⁻⁵. This is still a very small strain value, meaning the structure only deforms slightly under the applied underwater pressure and gravity loading. The highest strain occurs locally near one of the beam-to-support connection zones, which is consistent with the previous stress and displacement results. Most of the structure remains in the blue region, indicating low strain levels overall. Together with the principal stress results, this suggests that the structure behaves in a stable way and does not experience excessive deformation in this simplified load case.

Factor of safety test full structure

This FOS plot gives a minimum factor of safety of approximately 0.78, which means that according to the standard SolidWorks FOS calculation, the local stress is higher than the assumed allowable/yield value. However, because this material is concrete-based, this result should not be interpreted in the same way as for a metal. The FOS plot is based on the selected strength criterion, often related to von Mises/yield strength, which is not the most suitable failure criterion for concrete. For this structure, the principal stress results are more relevant: the maximum principal tensile stress was about 2.998 MPa, which is below the assumed tensile strength of 6.0 MPa, and the maximum compressive stress was about 6.404 MPa, which is far below the assumed compressive strength of 55 MPa. Therefore, even though the standard FOS plot shows a local value below 1, the concrete-specific checks suggest that the structure remains acceptable for this simplified load case. The low FOS mainly indicates a local stress concentration and should be used as a warning point, especially near the beam-support connections, rather than as direct proof of failure.

General conclusion

The updated assembly simulations show that the structure behaves acceptably under the simplified underwater load case. Although the von Mises stress and the standard SolidWorks factor of safety indicate local critical areas, these results should not be interpreted directly as failure because the material is concrete-based. For this type of material, the principal stresses are more relevant. The maximum principal tensile stress is approximately 2.998 MPa, which remains below the assumed tensile strength of 6.0 MPa, meaning that the risk of tensile cracking is limited. The maximum compressive stress is approximately 6.404 MPa, which is far below the assumed compressive strength of 55 MPa, so the structure is also safe in compression. The maximum displacement is only 0.0514 mm, and the maximum strain is approximately 6.962 × 10⁻⁵, indicating that the overall deformation remains very small. The most critical zones are located around the beam-to-support connections, where local stress concentrations occur. Overall, the structure can be considered acceptable for this simplified 30-meter underwater pressure and gravity load case, but the connection zones should be monitored or improved if a higher safety margin is required.

This section presents the smart system developed for Maris Habitats. The smart system is designed to collect environmental data around the habitat and store it for later analysis. Instead of using real-time underwater communication, the final solution is based on local data logging, where the collected measurements are saved on an SD card inside a removable smartlogger.

The section explains the development of the system, including the selected hardware, electronics, software, and packaging concept. The purpose is to show how the monitoring system supports the final product while keeping the design robust, low-power, and easier to maintain.

This subsection describes the hardware design of the smart system. It presents the main physical and electronic components needed for data collection, power supply, and storage. This includes the microcontroller, battery, sensors, SD card module, and waterproof enclosure.

The hardware was selected with focus on low energy consumption, reliability, and suitability for underwater conditions. The subsection also explains why the final solution uses a removable smartlogger instead of a more complex buoy-connected system.

Throughout this project, various approaches to data collection were explored. Initially, Version 1 was developed, while this version enabled continuous data communication, it proved to be highly complex and more prone to potential failures. Based on these findings, Version 2 was selected as the preferred because it prioritises robustness, reduced complexity, and ease of deployment, while accepting compromises regarding limited operational duration and the lack of continuous data communication.

Figures 60 and 61 present the smart system black box diagram. The system corresponds to a living laboratory where the:

• Sun (top left corner) is the source of energy. A buoy equipped with solar panels on top will store power in a battery and provide power to the system.
• Sea water (bottom left corner) is the growth medium. Four sensors will monitor the water environmental conditions (diamond).
• Fish and sea life (bottom right corner) are under observation. Fish and algae will be monitored (presence and size) to determine biodiversity and measure photosynthetic effects and chlorophyll on surfaces.

All this data will be collected and combined and sent to the On Board Computer (OBC) while also getting a timestamp by a Real Time Clock (RTC). All this will be powered by the battery through a Power Management System (PMS) that received the power from the buoy.

Both the buoy and the structure will have a positioning module, that will count with an Inertial Measuring Unit (IMU), a Doppler velocity Log (DVL) and a Global Navigation Satellite System (GNSS) receiver, to have everything registered about the position of both elements and make sure nothing goes wrong due to external factors such as storms, currents or human factors.

From the structure to the buoy, there will be a chain and a cable, for both structural support and data and power connection between the two elements. Finally, all the data collected will be sent to a data center, this will be done through the standard Iridium Satellite Network.

The main output will be a report with all the obtained data.

Version 1.5 is presented in a more text‑based format instead of graphical form, as it is a more accurate representation of the system’s black‑box diagram. It is also a simplified.

In this configuration, the system is based on a “Smart Block” that houses all electronic components, including the power supply, sensors, and data storage, eliminating the need for external infrastructure such as surface buoys, solar panels, or cable connections.

The entire system is powered by a LiFePO4 battery. Environmental data is collected via sensors that measure pressure (depth), temperature, pH, and conductivity. All collected data is stored locally on a Secure Digital memory card (SD card); real-time transmission is not possible. Battery replacement and data retrieval are carried out through a scheduled maintenance procedure involving a diver. The estimated battery lifetime of the system is approximately 340 days, which limits the frequency of required maintenance operations to roughly once per 11 months. When battery replacement is necessary, a diver descends to the installation site and retrieves the Smartbox from the seabed. The enclosure must be brought to the surface in order to be opened safely. Battery replacement and cleaning of the sensors and electricalbox of corganic growth is performed aboard a boat, where the SD card is also replaced simultaneously to ensure secure and continuous data storage. After completion of the maintenance procedure, the Smartbox is redeployed and repositioned at its original location on the seabed. This integrated maintenance strategy allows both power supply and data storage components to be serviced during a single operation. After retrieval, the data is transferred to a research facility for analysis and evaluation, ultimately contributing to environmental monitoring and reporting.

Figure 62 shows the smart block systems black box diagram.

The ESP32 was selected as the microcontroller for this project due to its advanced power-management features and processing capabilities. A key requirement of the system is low energy consumption, and the ESP32 supports deep sleep modes with a current consumption of approximately 10 µA. During deep sleep, most of the chip is powered down while the built-in RTC remains active, allowing the microcontroller to wake up at predefined intervals without requiring external timing hardware.

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 27 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.

The system is powered by a 12 V 20 Ah LiFePO₄ battery. To prevent excessive battery degradation and to extend its service life, the battery is not discharged fully. A minimum state of charge of 20 % is enforced, meaning that only 80 % of the nominal battery capacity is used. The battery’s nominal voltage is 12.8 V. The total power consumption of the system during active operation is 1.505 W.

To minimize energy usage, measurements are performed once per hour. The system is designed to remain active for only 1 minute per hour, which is sufficient for sensor stabilization and for writing the collected data to the SD card.

Battery capacity: 12.8 V × 20 Ah × 0.8 = 204.8 Wh

Daily energy consumption (1 min/hour operation): 1.505 W/60 × 24 h = 0.602 Wh/day

Number of days: 204.8 Wh / 0.602 Wh/day = 340.199 days

Based on these calculations, the system can operate for approximately 340 days on a single battery charge. The power consumption during deep sleep mode was neglected in the battery life estimation because it is several orders of magnitude lower than the active current consumption. With a deep sleep current of approximately 10 µA, its contribution to the total energy consumption is negligible for this application

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 [142] 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²C (Inter-Integrated Circuit) interface. Therefore, no I²C level converter is required, simplifying the hardware design and reducing power consumption.

The pH sensor [143] is sourced from Atlas Scientific. It is used together with a pH module [144], which converts the signal into an analog signal that can be directly read by the microcontroller's analog inputs.

For the conductivity sensor, no similar ready-made solution was available. It outputs a current signal of 4 mA–20 mA, which must be converted into a voltage of 0 V–3.3 V to be read by the ESP32. This is done using a 160 Ω resistor, according to Ohm’s law (U=I×R).

0.004 A × 160 Ω = 0.64 V

0.020 A × 160 Ω = 3.2 V

The enclosure is one of the most critical and costly components of the system, as it must withstand high external pressure at the seabed. Suitable enclosures are therefore difficult to source.

Condensation is expected to form inside the enclosure as the air trapped inside is cooled by the surrounding seawater. This temperature difference can lead to moisture accumulation, increasing the risk of corrosion and electrical failures. To mitigate this risk, silica gel desiccant packets are placed inside the enclosure to absorb excess moisture.

The sensors from Atlas Scientific use ¾“ NPT (National Pipe Tapered) threads, while the enclosure is designed with M10 threads. This requires sealing the existing holes and machining new threaded openings in the enclosure.

However, the sensor from Blue Robotics is equipped with M10 threads, allowing direct installation into the enclosure without modification.

Table 28 presents a comprehensive overview of all sensors and components included in the system. The electrical schematics are shown in Figure 63.

The use of an imaging system was initially considered to monitor marine life development. However, this approach has been deprioritized, as the primary focus of the project has shifted toward the analysis of quantitative sensor data.

Sensor-based measurements provide continuous, objective, and scalable insights into environmental conditions, which are more closely aligned with the project’s core objectives.

The inclusion of a camera system is therefore limited to supporting species identification, specifically to document the presence of fish within the reef environment. In addition, visual documentation of the reef structure will be conducted during annual maintenance operations, during which images of the installation will be captured once per year.

Figure 64 shows what the enclosure will look like with all the electronics inside. The image on the left includes the sensors. The picture on the right is without the sensors to show how much space the rest of the electronics will use.

The final Maris Habitats product is designed without a mobile application or real-time underwater communication. Instead, the system uses local data logging. This means that all environmental data collected by the smartlogger is stored directly on an SD card inside the removable sensor unit. The data is retrieved during scheduled maintenance, when the smartlogger is taken to the surface.

The software runs on the microcontroller inside the smartlogger. Its main purpose is to control the measurement cycle, read data from the sensors, organize the collected values, and store them safely on the SD card. This approach reduces system complexity, lowers power consumption, and avoids the need for continuous underwater communication.

When the final product is activated, the software first initializes the microcontroller, sensors, real-time clock, and SD card module. The real-time clock is used to give each measurement a timestamp, so that the data can be analyzed later in the correct time order. If the SD card is detected correctly, the software creates or opens a data file for storing the measurements.

During operation, the system performs measurements at predefined time intervals, for example once per hour. In each measurement cycle, the microcontroller wakes up, powers or activates the sensors, waits briefly for the readings to stabilize, and then collects data such as temperature, pressure/depth, pH, and conductivity. After the values are collected, they are formatted into a structured data line and written to the SD card.

An example of the stored data format is shown below:

Timestamp;Temperature;Pressure;Depth;pH;Conductivity
2026-06-01 12:00;16.4;5.02;50.1;8.10;52.3
2026-06-01 13:00;16.5;5.01;50.0;8.09;52.1
2026-06-01 14:00;16.5;5.03;50.2;8.11;52.4

After writing the data, the file is closed to reduce the risk of data loss. The system then returns to a low-power state until the next scheduled measurement cycle. This is important because the final product is intended to operate for a long period on battery power.

The SD card is not accessed continuously by the user. Instead, the smartlogger is retrieved during planned maintenance. At this point, the SD card can be removed or replaced, and the stored data can be transferred to a computer for analysis. The same maintenance operation can also include battery replacement, sensor inspection, and sensor cleaning.

The packaging design was planned separately for the Smart Module and the Reef Block because these parts have different sizes, weights, and protection needs. The Smart Module includes the Smartlogger and the Smartlogger attachment. The Smartlogger contains the electronic components, battery, SD card, and sensors. Therefore, the Smart Module needs protection from shock, dust, moisture, and vibration during transport. On the other hand, the Reef Block is much heavier and does not require the same type of protective case, so its transport solution must focus more on stability, safe handling, and movement prevention.

Figure 65 shows the packaging concept for the Smart Module. The design is inspired by reusable waterproof hard cases, such as the NANUK 935 Pro Photo Kit. This type of case is suitable for sensitive equipment because it is designed to protect the contents from impact, dust, water, and vibration during transport [145]. The NANUK 935 case is made with a lightweight NK-7 resin shell and is described as impact-resistant and shock-absorbent, which makes it appropriate for transporting electronic monitoring equipment [146].

Inside the case, the Smart Module is placed in a custom EVA foam insert. EVA foam was selected because it is lightweight, durable, moisture-resistant, and able to absorb shock. Its closed-cell structure gives it low water absorption, and its cushioning properties make it suitable for protecting sensitive components during transport [147]. The foam insert is shaped around the Smart Module to reduce movement inside the case and to keep the Smart Module and assembly instruction card organized.

The sensors and electronic components are integrated inside the Smartlogger, which is part of the Smart Module. Therefore, no separate sensor set or external sensor cables are included in this packaging concept. An assembly instruction card is included to show how the Smartlogger is attached to the Smartlogger attachment and how the protective lid is added before deployment. The EVA foam insert is not considered a single-use material in this concept because it can be reused with the same hard case for storage, deployment, maintenance, and retrieval operations.

Figure 66 shows the transport concept for the Reef Block. Since this part is heavy and mainly made of concrete, it is transported separately on a wooden pallet instead of being placed inside the blue hard case. Wooden pallets are suitable for transporting heavy goods because they provide a stable load carrier and allow handling with forklifts [148]. The Reef Block is fixed to the pallet using straps to keep the load stable and reduce movement during transport [149]. This solution reduces unnecessary packaging material while keeping the concrete block stable during handling and transport.

The packaging also considers reuse. The waterproof hard case can be used repeatedly for storage, deployment, maintenance, and retrieval of the Smart Module. The pallet can also be reused for several transports if it remains in good condition. For the final version, the foam inserts should be replaced only when damaged. In this way, the packaging can protect the product while also reducing unnecessary waste.

These packaging images are concept visuals, so the final packaging may still change after testing. In the next stage, handling and transport tests should be carried out to check whether the hard case, EVA foam insert, pallet, and straps can properly protect the components under real transport conditions.

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.

Compared to the final designed solution, several modifications are made for the prototype. The structural block is downscaled to 1:3, resulting in a model size of about 26 cm. This allows the structural concept to be tested in a smaller and more practical format. In addition, alternative materials are considered for the prototype structure. The block may either be produced using 3D printing or cast in standard concrete, rather than using the final material and full-scale production method.

The smartlogger is also simplified compared to the final design. Instead of using a dedicated underwater enclosure, a waterproof plastic box is used as the prototype housing. Holes are drilled in the enclosure for the water-measuring sensors, which are installed through the openings and sealed with adhesive to prevent leakage.

The prototypes pressure sensors can be tested in the pool located in the robotics laboratory. As the prototypes enclosure can't withstand high external pressures, the pool depth of 5 m is considered sufficient for the proof of concept. An additional test setup involves using a controlled environment, such as a sink, where parameters like temperature and TDS values can be more easily manipulated. For example, the TDS level can be adjusted by adding salt to the water.

The enclosure will initially be tested without oil to determine whether it can withstand underwater pressure while protecting the internal electronic components. If the enclosure is not sufficiently pressure-resistant, it will be filled with oil as a pressure-compensation solution. This reduces the pressure difference between the inside and outside of the box while protecting the battery, sensors, and electronic components from direct contact with water.

These changes are made to simplify prototype construction and enable early testing of the system concept before developing the final full-scale solution.

The prototype is designed to measure parameters similar to those measured by a CTD system, Conductivity, Temperature, and Depth. However, instead of using a conductivity sensor to calculate salinity, the prototype uses a TDS, Total Dissolved Solids, sensor.

Conductivity measures water’s ability to carry an electrical current. This ability is directly related to the concentration of dissolved ions, such as salts, minerals, and other inorganic materials. TDS, on the other hand, represents the total amount of dissolved substances in the water, including inorganic salts such as calcium, magnesium, potassium, sodium, bicarbonates, chlorides, and sulfates, as well as small amounts of organic matter. TDS is typically measured in mg/L or ppm and is commonly used as an indicator of water quality.

Using a TDS sensor provides a significantly cheaper alternative to a conductivity sensor. For early-stage testing, this is sufficient because the main goal is to validate the overall system concept rather than achieve final measurement accuracy.

In addition to measuring TDS, pressure, turbidity, and temperature are also monitored. Pressure data can be used to calculate depth. Turbidity indicates the presence of suspended particles, while temperature affects the physical and chemical properties of the water. 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.

The selected sensors used in the prototype are presented in Table 29.

In the prototype, an Arduino Uno R3 is used as the microcontroller. Since the Arduino Uno lacks a built-in RTC, an external RTC module is required to enable accurate timekeeping. The system operates with a logic voltage of 5 V, whereas the SD card reader operates at 3.3 V logic level. Therefore, a logic level converter is necessary to ensure proper communication between components with different voltage requirements.

The prototype is powered by a 9 V, 640 mAh alkaline battery. Due to its limited capacity, the operational time of the prototype is significantly shorter than that of the final system, restricting testing and data collection to a period of only a few hours. Therefore, the prototype is intended primarily as a proof of concept. Since the battery voltage decreases gradually during discharge, the battery cannot be assumed to be fully depleted before the supply voltage falls below the minimum operating voltage required by the electronics. Therefore, only 70% of the nominal battery capacity is considered usable in the present calculations.

The estimated energy consumption is based on the system’s calculated power usage of 0.92 W.

Battery capacity: 9 V * 0.64 Ah * 0.7 = 4.03 Wh

Battery time: 4.03 Wh / 0.92 W ≈ 4 h

The other electronic components used in the prototype are listed in Table 30.

For prototype testing, a low-cost solution is used both for the enclosure and structural elements. A simple plastic lunchbox can serve as a temporary enclosure, where holes can be drilled for sensor placement, making it suitable for controlled testing before investing in the final underwater housing. In addition, standard cement is used for structural testing, as it provides sufficient strength at a very low cost. These materials are summarized in Table 11.

PLA filament can be used either as an alternative material for the blocks or to create moulds for casting concrete blocks, or as the structure for the prototype instead of concrete. This allows for greater flexibility and repeatability during the design and testing phase. However, PLA is not suitable for long-term structural use in harsh environments, and is therefore primarily intended for prototyping and tooling purposes.

The enclosure used for the prototype is a simplified version of the final system design. To minimize development costs and allow rapid iteration, a standard plastic food container is utilized as the enclosure. To ensure watertight cable penetrations, a silicone‑based sealant is applied at all cable entry points. Silicone sealant is chosen due to its flexibility, ease of application, and adequate waterproofing properties. In addition, the sealant may also be applied along the interface between the lid and the enclosure body if leakage is detected during initial testing

If the external hydrostatic pressure exceeds the enclosure’s mechanical limits at greater test depths, an oil‑filled enclosure may be used as a pressure‑compensation solution. Transformer oil would be the preferred choice due to its superior electrical insulation properties, however, it is difficult to obtain for small‑scale prototyping. Therefore, cooking oil is considered as a low‑cost and readily available alternative. Although it doesnt provide the same electrical insulation, it is expected to be sufficient for this low‑voltage prototype and suitable for short‑term experimental testing.

The final prototype may not utilize the exact components and materials specified in this study; however, functionally equivalent or closely comparable alternatives are expected to be used.

The electrical schematics for the prototype is presented in figure 67.

Overview

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.

Libraries

The code uses five libraries:

• SHT21.h — reads temperature from the SHT21 sensor over I²C
• SD.h and SPI.h — handles communication with the SD card
• Wire.h — enables I²C communication between the Arduino and sensors
• RTClib.h — reads the current date and time from the DS1307 real-time clock over I²C

Sensors & pins

The SHT21 and DS1307 share the same I²C bus (SDA/SCL) since each device has a unique address — 0x40 and 0x68 respectively.

Setup

When the Arduino powers on, setup() runs once and performs the following in order:

• Initializes I²C and Serial communication
• Initializes the SD card — halts with an error message if it fails
• Initializes the RTC — if the clock is not running, it sets the time to the compile time of the code
• Fills the TDS buffer with initial readings
• Creates log.csv with a header row if the file does not already exist

The SD card is initialized before the RTC to avoid conflicts on the shared bus during startup.

Main loop

The loop() function runs continuously and handles four tasks:

• Switch monitoring
  • The switch is read every loop iteration.
  • When flipped to the off position, logging is paused and a message is printed to Serial.
  • When flipped back, logging resumes.
  • This allows the system to be safely disconnected without risking data corruption, since the SD file is always closed after each write.
• Sensor readings
  • On every loop iteration the following are measured:
    • Turbidity — the analog value from A0 is averaged over 10 readings to reduce noise, then converted to voltage.
    • Pressure — the analog value from A2 is converted to voltage and then to kPa using the sensor's offset and scaling factor.
    • Temperature — read directly from the SHT21 via I²C.
• TDS sampling
  • The TDS sensor is sampled every 40 milliseconds and stored in a circular buffer of 30 values.
  • This continuous sampling ensures a stable reading is always available when it is time to log.
• Logging every 10 seconds
  • Every 10 seconds the following happens:
    • The TDS buffer is processed using a median filter to remove outliers.
    • The filtered TDS voltage is temperature-compensated using the formula: compVoltage = avgVoltage / (1.0 + 0.02 * (temp - 25.0))
    • The compensated voltage is converted to ppm using a third-degree polynomial calibration curve.
    • The current date and time are fetched from the RTC.
    • All values are printed to the Serial monitor.
    • A new row is appended to log.csv on the SD card in semicolon-separated format.
    • The file is closed immediately after writing to prevent data loss in case of power failure.

Median filter

The getMedianNum() function sorts a copy of the TDS buffer using bubble sort and returns the middle value. This effectively removes spike readings caused by electrical noise, giving a more accurate TDS measurement than a simple average would.

CSV output format

Each row in the log file contains:

Date ; Time ; Turbidity [V] ; Temperature [C] ; TDS [ppm] ; Voltage [V] ; Pressure [kPa]

The file begins with sep=; which tells Microsoft Excel to automatically use semicolon as the column separator when opening the file.

Flowchart software

The software flowchart illustrates the automatic data logging process used in the Maris Habitats prototype. The process starts by checking whether the SD card is available. If the SD card is not detected, the program stops. If the SD card is working, the system continues by checking whether the RTC module is running. If the RTC is not available, the program also stops.

When both the SD card and RTC module are ready, the software creates or opens the log.csv file. The program then checks the switch state. If the switch is off, logging is paused. If the switch is on, the system reads the connected sensors. The program then checks whether 10 seconds have passed since the last logging cycle. If not, the system continues reading sensor values.

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 68 shows the software flowchart of the Maris Habitats prototype.

The purpose of the prototype testing is to verify that the Maris Habitats prototype performs its basic functions under controlled surface conditions. The prototype is not intended for underwater deployment or long-term marine testing. Therefore, the tests focus on validating the electronic system, sensor response, data logging, power supply, removable smartlogger concept, and basic structural handling above the water surface.

Since the prototype cannot be tested underwater, all tests are carried out under controlled surface conditions. The sensor system is tested using air exposure, manual handling, and separate water samples where relevant. The complete prototype is not submerged. A test is marked as Pass when the function operates as expected during the controlled test. A test is marked as Fail if the component does not respond, gives unreasonable values, stops operating, or cannot be used as intended.

These tests are intended to validate the proof-of-concept prototype only. They do not verify long-term underwater durability, waterproofing, marine pressure resistance, or biological performance. These aspects must be tested in future development using a marine-grade final product.

The software data logging function was tested using the prototype hardware in order to validate the same basic principle used in the final product. During the test, the Arduino software was uploaded to the microcontroller and used to read values from the connected sensors. The measured values were then written to an SD card and checked afterwards on a computer.

The purpose of this test was to verify that the software could initialize the SD card module, create or open a data file, collect sensor values, write the values in a readable format, and store the file correctly. The same values were also displayed in the Serial Monitor during testing, allowing the team to compare the live readings with the stored data.

The test confirmed that the software is able to perform local data logging. This means that the system can collect sensor data and save it on an SD card without using real-time communication. This supports the final product concept, where the smartlogger stores environmental data locally until it is retrieved during scheduled maintenance.

Figure 69 shows how the data stored on the SD card is presented in Excel.

This chapter described the development of Maris Habitats from concept planning to prototype testing. The main focus of the development was to create a smart monitoring system that can read environmental data from a smartlogger and store the measurements locally. The physical reef structure was included as the supporting structure for the smartlogger, but the main technical purpose of the prototype was to validate the data collection and logging process.

The chapter presented the smart system, including the hardware, electronics, software and packaging. The smartlogger was designed as a separate unit containing the sensors, microcontroller, battery and SD card. This solution allows data collection and maintenance without removing the whole reef structure from the seabed. The software was developed to read sensor values and store the collected data locally on an SD card, making the system suitable for basic environmental monitoring without requiring continuous underwater communication.

The prototype was built as a simplified validation model rather than a final marine-grade product. It was used to test the basic structure, electronic integration, sensor readings and data logging process under controlled conditions. The prototype helped confirm that the main technical logic of the system works, while also showing which parts would need further development before real underwater deployment.

Chapter 7 shows how Maris Habitats was transformed from a theoretical concept into a physical and functional prototype. The development process confirmed the feasibility of combining a modular reef structure with a removable monitoring system. Further development should focus on marine-grade materials, waterproofing, long-term durability, sensor accuracy and real environmental testing.