Differences

This shows you the differences between two versions of the page.

--- report:dvp [2026/05/21 12:06] – [Software] team3
+++ report:dvp [2026/06/01 15:19] (current) – [Structure] team3
@@ Line 47: / Line 47: @@
 </figure>
 </WRAP>
+{{:report:flyerversion5.png?400|}}
 === Choice of the subject ===
 Immediately following the initial presentation, the group gathered to evaluate the proposed project tracks and reach a consensus. Our approach was rooted in an open brainstorming session where we weighed our individual strengths against the potential of each topic. It quickly became clear that the "Smartification of Objects" was the path that generated the most genuine enthusiasm among us.
@@ Line 109: / Line 110: @@
-The bottle will be prices at approximately 330 €. For mass production the team could look to reduce the production price up to 100 € per bottle. Meaning the end price of the bottle would  be around 250 €.
+The bottle will be prices at approximately 330 €. For mass production the team could look to reduce the production price up to 140 € per bottle. Meaning the end price of the bottle would  be around 160 - 220 €.
 ==== Design ====
-MATERIAL SELECTION : "The materials for each component of the smart water bottle were selected based on both functional requirements and aesthetic considerations, ensuring a balance between performance and visual appeal.
+=== Material selection ===
+The materials for each component of the smart water bottle were selected based on both functional requirements and aesthetic considerations, ensuring a balance between performance and visual appeal.
 Polypropylene (PP) is used for the cap due to its durability and ability to withstand repeated use, while also providing a clean and smooth finish that contributes to a modern appearance.
 The bottle body is made from polished aluminum, chosen not only for its lightweight structure and corrosion resistance, but also for its sleek, reflective surface, which enhances the overall aesthetic and gives the product a premium look.
 For the compartment containing the electronic components, a plastic material such as polycarbonate is used. This ensures proper electrical insulation and waterproof protection, while also allowing for a precise and refined design that integrates seamlessly with the rest of the bottle.
-Overall, the combination of these materials supports a design that is durable, safe, and visually appealing for everyday use."
+Overall, the combination of these materials supports a design that is durable, safe, and visually appealing for everyday use.
 === Structure ===
@@ Line 215: / Line 218: @@
 </figure>
 </WRAP>
+<WRAP centeralign>
+<figure fig:model8>
+{{ :report:StressSim.png?600 |}}
+<caption>Stress Simulation</caption>
+</figure>
+</WRAP>
+<WRAP centeralign>
+<figure fig:model8>
+{{ :report:assembly-drop_test_1-image-1.jpg?600 |}}
+<caption>Drop Simulation</caption>
+</figure>
+</WRAP>
+Finite Element Analysis (FEA) was carried out in SolidWorks to evaluate the bottle's mechanical behavior under two specific scenarios. First, a lateral static load of 100 N was applied to simulate a firm physical grip. The resulting maximum von Mises stress was only 0.203 MPa, showing that daily handling forces are mechanically negligible.
+Next, a 1.5-meter drop test was simulated. In this dynamic scenario, the maximum stress peaked at 133.7 MPa, with the impact forces heavily concentrated along the bottom edge of the bottle. To properly protect the internal electronics, two variations for the 0.8–1.0 mm aluminum body were analyzed. When using standard Aluminum the Factor of Safety (FoS) is 1.08. This prevents catastrophic structural failure but leaves a very tight margin against plastic deformation like cosmetic denting. Upgrading the main body to Aluminum (yield strength of approx. 276 MPa) increases the FoS to 2.06, providing a much safer margin.
 <color #ed1c24>Add here detailed drawings (with precise dimensions); and 3D model with load and stress analysis of the TRAQUA bottle.</color>
@@ Line 442: / Line 463: @@
 <WRAP centeralign>
 <figure fig:packaging>
-{{:packaging_solution_v2.png?400|}}
+{{:report:packaging_solution_v3.png?800|}}
 <caption>Packging solution sales poster</color></caption>
 </figure>
@@ Line 465: / Line 486: @@
 Refer main changes in relation to the designed solution.
-=== Structure ===
-Detail and explain any changes made in relation to the designed solution, including structural downscaling, different materials, parts, etc.
-=== Hardware ===
+===Structure===
-Detail and explain any change made in relation to the designed solution.
+During the prototype phase, several modifications were made compared to the original design in order to simplify the construction process, reduce complexity, and make the product more practical for testing and development. The initial concept was based on a custom ergonomic bottle design, but for the prototype we instead used a Stanley Cup–style gym flask. This differed from the original idea because it provided a ready-made and durable structure that could easily house the components without the need to manufacture a completely custom bottle body. Using an existing flask also reduced production time and allowed the team to focus more on testing the electronic functions of the system.
-In case there are changes regarding the hardware, present the detailed schematics of the prototype.
+Another major change concerned the bottle base and sensor mounting. In the original design, the system included a separate base structure intended to contain some of the hardware and provide mounting points for the sensors. In the prototype version, this structure was simplified by attaching the sensors directly to the bottom section of the bottle instead of using a detachable or independent base. Although the base structure was removed, the electronic hardware is still protected inside a custom 3D-printed plastic casing. This downscaled the mechanical design and reduced the number of structural parts required for assembly. To secure and seal the components, superglue and silicone were used during assembly. Superglue was mainly used for mounting and fixing components in place, while silicone was applied to improve sealing and provide protection against water and moisture.
+An additional modification was the inclusion of an OLED display. The original design did not include a display screen, but during development an OLED module was added because it was supplied as an extra component by the manufacturer. The display improved the functionality of the prototype by allowing real-time system information and sensor readings to be shown directly to the user. Compared to the initial design, this provided a more interactive and user-friendly experience while also making testing and debugging easier during development.
+===Hardware===
+During the prototype development, several hardware changes were made due to mismatches between the original design and the components that were received.
+The main issue concerned the battery system. The original design specified a 3S lithium-ion battery pack with a matching 3S BMS. However, 4 18650 batteries and a 4S BMS were received instead. This created a compatibility problem, since a 4S BMS is designed to monitor and balance four cells and cannot be properly used with a 3-cell configuration. It would also result in incorrect voltage levels compared to the intended system design.
+After evaluating the available options, the decision was made to use all 4 batteries in series together with the 4S BMS, effectively changing the system to a 4S configuration. Due to this change, the original charging setup was no longer compatible with the new voltage system, and the charging function was therefore omitted from the prototype implementation.
+Another modification involved the system fuse. The original design specified a 5A fuse to handle normal operating current and short peaks from components such as the ESP32, sensors, and UV-C LED module. However, a 3A fuse was used instead due to availability. This lowers the maximum current threshold and increases the sensitivity of the protection system, meaning the fuse is more likely to blow during peak load conditions.
+Overall, these changes were necessary to adapt to available components, but they also introduced deviations from the original electrical design, particularly in terms of voltage configuration and power system robustness.
+<WRAP centeralign>
+<figure fig:schematics-v5>
+{{:report:schematics-v5.png?800|}}
+<caption>schematics-v5</caption>
+</figure>
+</WRAP>
+=== Functional Testing Results ===
+To verify the reliability and functionality of the TRAQUA smart bottle prototype, all major electronic and sensing components were tested individually and as part of the integrated system. The table below summarizes the performed tests, expected behavior, obtained results, and final status of each subsystem.
+^ Component / System ^ Function Tested ^ Expected Result ^ Actual Result ^ Status ^
+| TDS Water Quality Sensor | Water quality measurement | Detect changes in TDS values accurately | Stable ppm measurements for different water samples | PASS |
+| Accelerometer (LIS3DHTR) | Motion and orientation detection | Correctly detect bottle tilt and movement | Accurate orientation measurements with stable readings | PASS |
+| Battery Pack (4S Li-ion) | Power delivery | Supply stable voltage to system | Stable voltage supplied during operation | PASS |
+| BMS Protection Module | Voltage regulation and protection | Stable input/output operation | Correct voltage regulation observed | PASS |
+| Buck Converter (16 V → 5 V) | Voltage step-down conversion | Regulated 5 V output | Stable 5.01 V output achieved | PASS |
+| Charger System | Battery charging | Proper charging of 4S battery pack | Charging failed due to configuration mismatch | FAIL |
+| UV-C Sterilization Module | UV-C activation and control | Safe activation/deactivation through ESP32 | Correct switching behavior observed | PASS |
+| Temperature & Humidity Sensor | Environmental monitoring | Stable temperature and humidity readings | Accurate and stable measurements obtained | PASS |
+| Force Sensitive Resistor (FSR) | Water level estimation | Detect weight and fill level changes | Sensor values increased correctly with weight | PASS |
+| ESP32 DevKit V1 | System control and communication | Stable operation and Wi-Fi communication | Reliable communication and stable operation | PASS |
+== Review and Validation Process ==
+Each subsystem of the TRAQUA prototype was tested under practical operating conditions using serial monitoring, voltage measurements, sensor calibration, and repeated functional verification. The tests were designed to evaluate sensor accuracy, communication stability, electrical reliability, and overall system integration.
+The obtained results were compared against the expected functionality of each subsystem. Stable measurements, successful communication, and correct component behavior were considered indicators of successful operation. Any abnormal behavior or instability was recorded and evaluated for possible future improvements.
+== Overall Conclusion ==
+The functional testing confirmed that the TRAQUA smart bottle prototype operates reliably and that all major subsystems function as intended. The sensors, ESP32 microcontroller, UV-C sterilization system, and power management system all produced stable and consistent results during testing.
+The only major issue identified during testing was the incompatibility between the charger and the selected 4S battery configuration, which prevented proper charging functionality. Despite this limitation, the prototype successfully met the primary functional requirements and provides a strong foundation for future optimization and development.
 === Software ===
+** Implementation Changes and Prototype Code**
+Changes Made in Relation to the Designed Solution
+Temperature sensing — sensor and library change. The initial design used a DS18B20 digital probe driven by the OneWire and DallasTemperature libraries. This was replaced with an SHT21/Si7021-class sensor on the I²C bus, driven by the Adafruit Si7021 library. The change removed the dedicated OneWire data line and its pull-up resistor, simplified wiring to the shared I²C bus, and added relative-humidity measurement at no extra hardware cost. The temperature value is also reused downstream for temperature-compensating the TDS reading.
+Additional sensing and output components. Several components were integrated beyond the original sensor set: an analog pressure sensor (used to estimate the water volume in the bottle and, from that, detect drink events), a Gravity TDS meter (replacing the placeholder TDS value with a real, temperature-compensated reading in ppm), a magnetic reed switch (acting as a safety interlock), a UVC light control output, an SSD1306 OLED display, and two status LEDs (green/red) indicating drinking-water quality. The pH value remains a placeholder pending a calibrated pH probe.
+Safety architecture. Because the prototype includes a UVC light, a reed-switch interlock was added: the firmware forces the UVC output off at every boot and continuously verifies that a magnet is detected before the device operates. The interlock is fail-safe — an open or broken switch reads as "unsafe" and keeps the UVC off.
+Development tools and platforms. The Arduino IDE was upgraded from version 1.8.x to 2.x after the older version produced a package-manager fault and slow, un-cached compiles; version 2.x provides working build caching and noticeably faster recompilation. Firmware is built on the Espressif ESP32 Arduino core. Libraries added during development: Adafruit Si7021, Adafruit GFX, Adafruit SSD1306, and Adafruit BusIO; the BLE stack uses the ESP32 BLE Arduino library bundled with the core. Flashing is performed with esptool; because the development board's automatic reset was unreliable, a manual BOOT/EN download-mode procedure was used.
+Mobile application platform. The app is built with React Native and Expo (expo-router, TypeScript) and uses react-native-ble-plx for Bluetooth Low Energy. A significant platform change was moving from the Expo Go client to a custom Expo development build, because BLE is a native module that cannot run inside Expo Go. Testing was carried out on a physical Android device, since emulators have no Bluetooth radio.
+Application-level code changes. Three notable changes were made to the app's BLE layer. First, the connection now negotiates an enlarged MTU (247 bytes); the default 23-byte MTU truncated the JSON sensor payload. Second, device scanning was changed to filter by the service UUID rather than by device name, which proved more reliable on recent Android (Samsung) devices. Third, the data model was extended: the SensorReading type gained humidity and bottleVolumeMl fields, the BLE parser was updated to read them, and the global state provider (BottleProvider) gained logic that automatically logs a drink when the measured bottle volume drops.charts.
+** Prototype Code Flowcharts**
+Smart device firmware — initialisation (setup)
+<WRAP centeralign>
+<figure fig:setupchart>
+{{:report:setupflow.png?200 |}}
+<caption>Setup flow chart</caption>
+</figure>
+</WRAP>
+Smart device firmware — main loop (loop)
+<WRAP centeralign>
+<figure fig:mainLoopApp>
+{{:report:mainloop.png?200 |}}
+<caption>Main loop functions</caption>
+</figure>
+</WRAP>
+Mobile application — BLE connection and data flow
+<WRAP centeralign>
+<figure fig:bleConnection>
+{{:report:bleconnection.png?200 |}}
+<caption>Ble connection function</caption>
+</figure>
+</WRAP>
 === Tests & Results ===
@@ Line 481: / Line 596: @@
 == Software tests ==
+Our software testing framework directly addresses functionality, performance benchmarks, and user experience using the specific strategies and tools from our workflow:Functional Testing: We validate our identified use cases and user stories by verifying the system's core behavior. This includes unit testing our individual JavaScript/TypeScript code modules within Webstorm using Node.js , as well as executing API endpoint tests via Postman. We also conduct integration testing across the ESP32 firmware and the React Native mobile application to ensure these components function correctly as a combined entity.  Performance Testing: To evaluate speed, responsiveness, and stability under a workload, we run performance tests focused on data volume, system load, and runtime. These benchmark tests are repeated 10 times to determine precise average results and standard deviations, ensuring the BLE communication link and backend data transmission remain stable over time.  Usability Testing: To ensure the system is intuitive and accessible, we conduct usability testing according to the System Usability Scale (SUS). This allows our frontend team to validate interface feedback , evaluate how easily a user can understand their water safety status (Safe, Warning, Unsafe, Unknown) , and confirm that the mobile application provides clear, responsive alerts
 Software tests comprise:
 (i) functional tests regarding the identified use cases / user stories;