Differences

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

--- report:dvp [2026/06/09 12:51] – [7.5 Prototype] team5
+++ report:dvp [2026/06/14 15:45] (current) – team5
@@ Line 3: / Line 3: @@
 ==== 7.1 Introduction ====
-This chapter details the technical and conceptual evolution of the Connect project, from its initial ideation to the final tested prototype. It outlines the design choices, system architecture, and iterative development required to transform a standard metro carriage into an interactive, collaborative canvas that challenges digital isolation.
+This chapter details the technical and conceptual evolution of the CONNECT and share project, from its initial ideation to the final tested prototype. It outlines the design choices, system architecture, and iterative development required to transform a standard metro carriage into an interactive, collaborative canvas that challenges digital isolation.
 It covers:
-- Ideation & Concept: The transition from identifying the core problem of digital passivity to defining the metaphors and the two-phase interactive solution (real-time ambient light tracking and delayed asynchronous voice messaging).
+- Ideation & Concept: The transition from identifying the core problem of digital passivity to defining the metaphors and the two-phase interactive solution (real-time ambient light tracking and delayed asynchronous messaging).
 - Design: The visual and experiential design principles, focusing on invisible technology, dynamic color-blending algorithms, and the minimalist user interface of the web platform.
@@ Line 86: / Line 86: @@
- The web interface, accessible via QR code, is designed in a minimalist style. After scanning the QR code, users are redirected to the web application's landing page. The CONNECT logo takes center stage here, accompanied by two clickable buttons that lead to the subsequent sections. Within the app, users can choose between composing a message for others or viewing messages written by the community. Our primary focus was to keep the application as simple as possible; we wanted to ensure that both young and old users can navigate it effortlessly. By eliminating the need for logins or complex navigation, we’ve made the experience accessible and time-efficient for everyone.
+ The web interface, accessible via QR code, is designed in a minimalist style. After scanning the QR code, users are redirected to the web application's landing page. The CONNECT and share logo takes center stage here, accompanied by two clickable buttons that lead to the subsequent sections. Within the app, users can choose between composing a message for others or viewing messages written by the community. Our primary focus was to keep the application as simple as possible; we wanted to ensure that both young and old users can navigate it effortlessly. By eliminating the need for logins or complex navigation, we’ve made the experience accessible and time-efficient for everyone.
 == 7.4.1 Structure ==
@@ Line 117: / Line 117: @@
 <WRAP centeralign>
 <figure fig:3d_model_idealVersion>
-{{ :report:3dmodel_metrocarriage.jpeg?direct&800 | Final drawing}}
+{{ :report:whatsapp_image_2026-06-03_at_14.48.56_2_.jpeg?nolink&800 |}}
-<caption>3D spatial visualization of the fully integrated Connect system within the standard Porto Metro carriage architecture</caption>
+<caption>3D spatial visualization of the fully integrated CONNECT and share system within the standard Porto Metro carriage architecture</caption>
 </figure>
 </WRAP>
@@ Line 237: / Line 237: @@
 | ESP32-C3 central node |  1 |  5.0 V|  5 |  0.150 |  0.150 |  0.750 |
 | CAN transceiver MCP2551 |  10 |  5.0 V|  5 |  0.010 |  0.100 |  0.500 |
-| LED strips WS2812B (2 m, 120 LEDs each) |  3 |  12.0 V |  12 |  2.400 |  7.200 |  86.400 |
+| LED strips WS2812 (2 m, 120 LEDs each) |  3 |  12.0 V |  12 |  2.400 |  7.200 |  86.400 |
 | Velostat pressure sensors |  15 |  3.3 V |  3.3 |  0.001 |  0.015 |  0.050 |
 | **Total** | | | | | |  **93.700** |
@@ Line 251: / Line 251: @@
 | ESP32-C3 central node |  1 |  5.0 V |  5 |  0.300 |  0.300 |  1.500 |
 | CAN transceiver MCP2551 |  10 |  5.0 V |  5 |  0.010 |  0.100 |  0.500 |
-| LED strips WS2812B (2 m, 120 LEDs each) |  3 |  12 V |  12 |  7.200 |  21.600 |  259.200 |
+| LED strips WS2812 (2 m, 120 LEDs each) |  3 |  12 V |  12 |  7.200 |  21.600 |  259.200 |
 | Velostat pressure sensors |  15 |  3.3 V |  3.3 |  0.001 |  0.015 |  0.050 |
 | **Total** | | | | | |  **276.250** |
@@ Line 293: / Line 293: @@
 </WRAP>
-As shown in Figure {{ref>fig:ledpcb_v3}}, this PCB consolidates communication and actuation. It features a dedicated WS2812B LED Control port with a 330Ω resistor (R1) in series to protect the data line and ensure signal integrity.
+As shown in Figure {{ref>fig:ledpcb_v3}}, this PCB consolidates communication and actuation. It features a dedicated WS2812 LED Control port with a 330Ω resistor (R1) in series to protect the data line and ensure signal integrity.
 <WRAP centeralign>
@@ Line 316: / Line 316: @@
 **Software**
-The software architecture of the Connect and Share project facilitates real-time interaction and asynchronous digital connection across two distinct modes of use.
+The software architecture of the CONNECT and share project facilitates real-time interaction and asynchronous digital connection across two distinct modes of use.
 I. Use Cases and User Stories
@@ Line 322: / Line 322: @@
 Real-time Ambient Interaction operates through the smart device installed in the carriage. When passengers grip the handrail, sensors detect resistance changes via Velostat and the ESP32 triggers a corresponding color trail on the ceiling LED matrix. When data streams from multiple users intersect, the software executes color-blending algorithms to merge the inputs into a shared visual response.
-Asynchronous Connection is mediated through a web application. Passengers scan a QR code to access a web interface, where the application fetches audio files from a cloud database for playback. The same interface allows users to record microphone input, which is then compressed and uploaded to a central repository for others to access.
+Asynchronous Connection is mediated through a web application. Passengers scan a QR code to access a web interface, where the application fetches messages from a database to read. The same interface allows users to send a message, which is then filtered through an LLM API and uploaded to a database for others to access.
 II. Selection of Development Platforms
@@ Line 341: / Line 341: @@
 III. Component Diagram
-Figure {{ref>fig:frontend_flowchart}} depicts the frontend flow of the Connect web interface. Starting from a QR code scan, the browser fetches and renders the website. The user is then presented with two interaction options: writing a message, which is transmitted to the backend, or reading a message, which triggers a random message fetch and displays it on screen.
+Figure {{ref>fig:frontend_flowchart}} depicts the frontend flow of the CONNECT and share web interface. Starting from a QR code scan, the browser fetches and renders the website. The user is then presented with two interaction options: writing a message, which is transmitted to the backend, or reading a message, which triggers a random message fetch and displays it on screen.
 <WRAP centeralign>
@@ Line 437: / Line 437: @@
 ==== 7.5 Prototype ====
-The prototype constitutes a deliberate functional reduction of the full designed solution. Rather than replicating the complete metro-carriage installation, it validates the core interaction loop — pressure sensing, CAN bus communication, and LED feedback — on a single handrail segment with two nodes. Total prototype cost is 97.92 €, within the 100 € budget constraint.
+The prototype constitutes a deliberate functional reduction of the full designed solution. Rather than replicating the complete metro-carriage installation, it validates the core interaction loop — pressure sensing, CAN bus communication, and LED feedback — on a single handrail segment with two nodes. Total prototype cost is 97.92 €, within the 100 € budget constraint. The cost rose from the planned 97,37 € to 97,92 € after the planned MCP2551 transceivers were replaced by Joy-It MCP2515/MCP2562 CAN modules.
 == 7.5.1 Structure ==
-The designed solution specifies eleven ESP32-C3 nodes distributed across a full carriage, housed in PA Rail enclosures rated for EN 45545-2 fire compliance. This is reduced in the prototype to two nodes covering one handrail segment. The two-node configuration is sufficient to verify bidirectional CAN bus communication and the shared LED response behaviour without requiring the full network topology.
+The complex industrial dual power rail (12 V and 5 V lines) anchored by six decentralized step-down switching converters is replaced by a single, centralized 5 V / 20 W switching power supply module. This single rail directly supplies the standard ESP32 development boards and satisfies the peak current demands of the 1-meter Seeed LED strip, eliminating the high-voltage conversion chain.
-The PA Rail enclosures are replaced entirely. Sourcing a fire-rated enclosure from a non-Portuguese supplier (Nanovia, FR) was impractical within the budget at 69.30 € per unit. The prototype housing is instead 3D-printed in PLA using university facilities. PLA is biodegradable and structurally adequate for a lab context, but is not fire-rated and would not meet EN 45545-2 requirements in a deployed installation. The enclosure geometry follows the structural draft.
+The table below summarizes the structural and component differences between the ideal deployment and the implemented benchtop prototype:
-The sensor array is scaled proportionally. The designed solution uses fifteen Velostat sheets and fifteen copper tape rolls, one per handrail grip position. The prototype uses two Velostat sheets and a single copper tape roll, covering both nodes. The LED strip is reduced from three 2-metre addressable strips to one 1-metre WS2813 strip with a diffuser profile, sufficient to demonstrate the full colour-gradient feedback mechanic.
-The dual power rail (12 V and 5 V) with six step-down converters is replaced by a single 5 V / 4 A bench supply, eliminating the 12 V distribution chain. This is compatible with the WS2813 strip, which is rated for 5 V operation, and with the ESP32-C3 and MCP2551 supply requirements.
-The table below summarises the structural differences:
 <table>
 <caption>Comparison of components for ideal version and the prototype</caption>
 <WRAP center box round 600px>
-^ Parameter              ^ Designed Solution         ^ Prototype                        ^
+^ Parameter              ^ Designed Solution                  ^ Prototype                                  ^
-| Nodes                  | 11                        | 2                                |
+| Core Microcontroller   | ESP32-C3 (XIAO Form Factor)       | Standard ESP32 (NodeMCU DevKit)            |
-| Handrail segments      | Full carriage             | Single segment                   |
+| Handrail Node Network  | 11 Nodes                           | 2 Nodes                                    |
-| Enclosure              | PA Rail (EN 45545-2)      | 3D-printed PLA                   |
+| Handrail Coverage      | Full Carriage Assemblies           | Single Standalone Segment                  |
-| Velostat sensors       | 15                        | 2                                |
+| Enclosure Material     | PA Rail Polymer (EN 45545-2)       | 3D-printed PLA                             |
-| LED strip length       | 3 × 2 m                   | 1 × 1 m                          |
+| Active Pressure Inputs | 15 Velostat Sensor Grips           | 2 Custom Air-Gap Velostat Sensors          |
-| Power architecture     | Dual rail (12 V + 5 V)    | Single 5 V / 4 A supply          |
+| LED Strip Infrastructure| 3 × 2 m Addressable Strips         | 1 × 1 m Seeed WS2813 IP65 Strip            |
-| CAN transceivers       | 10                        | 2                                |
+| Power Architecture     | Dual Rail (12 V + 5 V)             | Single Regulated 5 V / 20 W Power Supply    |
-| Total cost             | 767.01 €                  | 97.92 €                          |
+| CAN Network Interface  | 10 Transceiver ICs                 | 2 Joy-It SPI Modules (MCP2515/MCP2562)     |
+| Total Segment Cost     | 767.01 €                           | 97.92 €                                    |
 </WRAP>
 </table>
-The following Figure {{ref>fig:prototype_design}} shows the design for the planned physical prototype.
+To conduct the laboratory evaluations safely and systematically without deploying a multi-metre carriage frame, a modular testbench architecture was modeled and assembled. The structural framework is anchored by a rigid, non-conductive MDF Base Plate, serving as the mechanical foundation for the subsystem groups. Two independent PLA handles mimic the geometric diameter of the physical metro handrails, each fitted with its respective custom-built Velostat sensing sheet to enable real-time dual-input interaction testing.
+Centrally, two open-top 3D-Printed PLA Component Storage Boxes isolate the prototyping breadboards, the standard ESP32 microcontrollers, and the Joy-It CAN modules from the mechanical interaction elements, minimizing the risk of wire displacement during multi-cycle touch experiments. The visual feedback infrastructure is aggregated along the upper border, where an PLA LED Holding Rail secures the 1-meter Seeed WS2813 strip and its matching sliding diffuser profile. This structural design bridges the gap between digital modeling and raw hardware assembly, ensuring an organized workspace for the validation logs.
+The overall layout of this physical bench setup is illustrated in Figure {{ref>fig:prototype_design}}.
 <WRAP centeralign>
 <figure fig:prototype_design>
-{{ :report:whatsapp_image_2026-05-20_at_11.32.08.jpeg?direct&800 | Velostat Iteration Process}}
+{{ :report:whatsapp_image_2026-05-20_at_11.32.08.jpeg?direct&800 | Benchtop Prototype Structure Layout}}
-<caption>Planned design for the final prototype</caption>
+<caption>Planned physical design, component routing, and node placement for the final validation prototype assembly</caption>
 </figure>
 </WRAP>
@@ Line 493: / Line 493: @@
 The assembly process followed these practical steps:
 * **Electrical Isolation:** A base layer of electrical insulation tape was wrapped around the metal handrail to prevent short circuits between the sensor and the vehicle framework.
 * **Electrode Matrix:** Multiple thin, long strips of conductive adhesive copper tape were applied to uniformly cover the handrail interaction area.
 * **Lateral Insulation Gap:** To stop the electrodes from touching the Velostat when the handrail is idle, thin strips of double-sided adhesive tape were placed strictly along the lateral edges. This created a small physical air-gap. When a passenger squeezes the handrail, the air-gap collapses, making the copper establish contact with the Velostat. This mechanical cushion stabilized the idle baseline.
 * **Vertical Orientation:** The active Velostat sheets were placed vertically along the longitudinal axis of the pole. This orientation minimized mechanical wrinkles and maximized the resistance reading range.
 * **Parallel Bus Connection:** Another copper tape was placed vertically on top of the Velostat sheet and then, all vertical copper strips were tied together in parallel using two horizontal copper tracks run at the top and bottom circumferences, forming two distinct electrical poles.
 * **Thermal Protection:** Because Velostat melts easily around 300 °C, the 26 AWG signal wires were soldered directly onto the top and bottom horizontal copper tracks away from the polymer, preventing thermal damage.
@@ Line 531: / Line 537: @@
 == 7.6.1 Hardware tests ==
-The physical validation of the Connect prototype was executed in a controlled laboratory environment using the benchtop assembly. Each requirement specified during the initial design stage was systematically evaluated. Table {{ref>tab_test_results}} details the comprehensive log of this validation phase, highlighting whether the criteria achieved a Pass (P), a Fail (F), or were deemed Not Applicable (N/A) due to the reduced scope of the laboratory prototype.
+The physical validation of the CONNECT and share prototype was executed in a controlled laboratory environment using the benchtop assembly. Each requirement specified during the initial design stage was systematically evaluated. Table {{ref>tab_test_results}} details the comprehensive log of this validation phase, highlighting whether the criteria achieved a Pass (P), a Fail (F), or were deemed Not Applicable (N/A) due to the reduced scope of the laboratory prototype.
 <table tab_test_results>
@@ Line 563: / Line 569: @@
 </table>
-=== Analysis and Discussion of Physical Hardware Tests ===
+== Analysis and Discussion of Physical Hardware Tests ==
 **Sensor Subsystem and Calibration (FT-01, FT-04)**\\
@@ Line 574: / Line 580: @@
 The visual response test resulted in a technical **Fail** due to predictable high-frequency signal artifacts. The prototype utilized a **Seeed 1-meter addressable WS2813 IP65 strip (18W, 5VDC)** connected via its integrated Grove interface. While the strip displayed the programmed color-blending animations accurately under active states, noticeable flickering was captured when the LEDs were idle. Specifically, the first pixel intermittently flashed bright white or random colors, and random color flickers propagated down the line.
-A thorough electrical diagnosis isolated this issue to a **logic-level mismatch**: the standard ESP32 transmits digital data streams using a $3.3\text{ V}$ CMOS logic level, whereas the WS2813 protocol dictates a high-level input threshold ($V_{IH}$) of at least $0.7 \times V_{DD}$. Powered at $5.0\text{ V}$, the Seeed strip requires a minimum data signal amplitude of $3.5\text{ V}$. Operating at the absolute edge of the noise margin, the $3.3\text{ V}$ data pulses caused the internal shift registers of the first pixels to misinterpret high/low states, causing erratic behaviors. This limitation provides a crucial baseline for future hardware revisions.
+A thorough electrical diagnosis isolated this issue to a **logic-level mismatch**: the standard ESP32 transmits digital data streams using a $3.3\text{ V}$ CMOS logic level, whereas the WS2813 protocol dictates a high-level input threshold ($V_{IH}$) of at least $0.7 \times V_{DD}$ [(worldsemiWS2813)]. Powered at $5.0\text{ V}$, the Seeed strip requires a minimum data signal amplitude of $3.5\text{ V}$. Operating at the absolute edge of the noise margin, the $3.3\text{ V}$ data pulses caused the internal shift registers of the first pixels to misinterpret high/low states, causing erratic behaviors. This limitation provides a crucial baseline for future hardware revisions.
 **Power and Electrical Distribution (FT-05, PT-04)**\\
@@ Line 648: / Line 654: @@
 **Unit testing**\\
-The API route handler for /api/messages was tested using Jest. The test suite covers both the GET and POST endpoints, with five test cases: returning a random message when data exists, returning null when no messages are stored, returning HTTP 500 on a Supabase error, returning the AI filter response on a successful POST, and returning HTTP 500 when the fetch call throws an error. All five tests passed in 0.277 seconds, as shown in Figure 33, which confirms that the route logic handles both normal use and error conditions as expected.
+The API route handler for /api/messages was tested using Jest. The test suite covers both the GET and POST endpoints, with five test cases: returning a random message when data exists, returning null when no messages are stored, returning HTTP 500 on a Supabase error, returning the AI filter response on a successful POST, and returning HTTP 500 when the fetch call throws an error. All five tests passed in 0.277 seconds, as shown in Figure {{ref>fig:jest-rest}}, which confirms that the route logic handles both normal use and error conditions as expected.
 <WRAP centeralign>
 <figure fig:jest-test>
-{{ :report:jest-test.png?800 | Figure 33: test results in terminal}}
+{{ :report:jest-test.png?800 | Test results in terminal}}
 <caption>Test results in terminal</caption>
 </figure>
 </WRAP>
 ==== 7.7 Summary ====
-This chapter documents the comprehensive lifecycle of the Connect project, tracing its evolution from initial conceptualization to a fully realized and validated prototype. The development process was driven by the goal of transforming a standard metro carriage into a collaborative, interactive canvas designed to counteract digital isolation.
+This chapter documented the complete lifecycle of the Connect project, tracing its evolution from initial concept to a validated physical prototype. The development was driven by a clear objective: transforming a passive metro carriage into an interactive space that counteracts commuter digital isolation.
-The phase began with Ideation and Design, where the core problem of digital passivity was translated into a two-phase interactive solution: real-time ambient light tracking and asynchronous voice messaging. This conceptual foundation was supported by a Smart System architecture, integrating touch-sensitive hardware with custom color-blending algorithms.
-To move from theory to reality, the Structure stage utilized detailed 3D modeling and analysis to ensure physical viability. Iterative adjustments were made to hardware schematics and software flowcharts to optimize performance.
+The process began with Ideation and Design, where passenger passivity was addressed through a two-phase solution: real-time ambient light tracking via handrail grips and asynchronous text messaging via a web application. This concept was supported by a Smart System architecture that integrated custom air-gap Velostat sensors, differential CAN bus communication, and color-blending LED algorithms.
-Having detailed the technical execution and rigorous testing of the system, the following section synthesizes these results to provide final reflections on the project's impact and future potential.
+To validate the design safely and cost-effectively, the Structure and Packaging stages utilized 3D modeling, sustainable cork packaging modules, and Finite Element Analysis (FEA). Finally, the system's operational logic, backend performance, and user experience were verified through benchtop laboratory testing and standardized usability metrics (SUS). The following section synthesizes these results to provide final reflections on the project's long-term deployment impact and future scalability.