Live Pressure Mapping — System Description and Requirements 1) Purpose and operating context The system is a live pressure-mapping solution intended to measure and visualize pressure distribution during induction-welding of thermoplastic composites. The intended operating envelope is a high-EMI induction environment (approximately 300–500 kHz field present) and a process context that can involve high temperatures (on the order of ~400 °C near the tool) and typical bonding pressures in the ~5–8 bar range. The software and filtering must be designed for robust performance under electrical noise and transient interference. 2) Sensor hardware Sensor type: Force Sensitive Resistors (FSR). Active sensing diameter: 26 mm (circular active area). Maximum force reference: 450 N. Truth constraint for scaling/normalization: The measurement system must uphold the calibration truth that the sensor output corresponds to ~3.00 V at 450 N (you sometimes accept 2.99 V, but the target is 3.00 V @ 450 N). Number of sensors: 16 FSRs, sampled as a set to produce a live “frame” of pressure values. 3) Signal conditioning and resistor network Voltage divider configuration: The FSR is used in a divider powered from the Pico’s 3.3 V rail. Fixed resistor value: 94 kΩ to ground (0 V) (this replaces the earlier 100 kΩ note). Measured node: The divider midpoint (FSR–resistor junction) is routed through a multiplexer into the Pico ADC. 4) Multiplexing topology Multiplexer: 16-channel analog multiplexer/demultiplexer, controlled by 4 select lines (typical CD74HC4067-style behavior). Enable behavior: The MUX EN pin is wired to “-” (ground), meaning the multiplexer is permanently enabled (active-low enable held low). Channel scanning: All 16 channels (commonly referred to as C0–C15) must be scanned cyclically to form each complete 16-sensor frame. 5) Microcontroller and pin mapping (fixed) MCU: Raspberry Pi Pico W, running MicroPython. ADC input (fixed): GP28 / ADC2 is used as the single analog measurement input. MUX select pins (fixed wiring): S0 → Pico physical pin 4 → GP2 S1 → Pico physical pin 5 → GP3 S2 → Pico physical pin 6 → GP4 S3 → Pico physical pin 7 → GP5 These select lines must be driven to address channels consistently and repeatably, and the mapping must remain stable so that pressing a specific sensor (e.g., “C3”) always affects the expected cell in the visual map. 6) Sampling, stability, and frame-rate requirements Target output rate: Approximately 20 Hz for a full 16-sensor frame (i.e., ~20 complete frames per second, not 20 samples on a single channel). Noise robustness: Because of the induction environment, the firmware must include stability measures such as: ADC averaging per channel read (and optionally median-based rejection of spikes). Smoothing that reduces jitter while remaining responsive to real pressure changes. The software must avoid “dead” channels and include a way to confirm channel responsiveness (especially to prevent recurrence of the issue where applying pressure to C3 does not change the output). 7) Required computations and units For each of the 16 channels, the system must produce values in multiple representations: Raw ADC reading (Pico ADC units). Voltage derived from ADC conversion. Force (N) derived from calibration. Pressure (bar) derived from force and sensor area. Pressure conversion must use the known FSR active area: Radius: 26 mm diameter → radius 13 mm = 0.013 m Area: A=π⋅(0.013)2 A=π⋅(0.013) 2 m² Pressure (Pa): P=F/A P=F/A Pressure (bar): Pbar=P/100000 P bar =P/100000 The visualization and analysis focus should prioritize 4–8 bar, but the conversion pipeline should remain valid across the usable range, including the upper force reference. 8) Calibration requirements (critical) The system must not fabricate calibration data. It must support per-sensor calibration (each of the 16 FSRs may have its own curve/coefficients). The system must support both: A measured interpretation (direct calibrated output). A scaled/normalized interpretation to correct for known recording inconsistencies, explicitly enforcing the constraint 3.00 V @ 450 N when normalization is applied. Calibration alignment must be based on meaningful ramp detection/behavior rather than naive timestamp matching when runs were recorded at different times (consistent with your earlier requirement that “it should fit based on where it sees significant change in the ramp up”). 9) Data output and interface requirements Pico-to-PC streaming: The Pico must stream the complete 16-channel frame in a structured, machine-readable format suitable for real-time parsing (CSV-line or compact JSON). No terminal spam: Output should not be verbose human debug text during operation; it should be structured data suitable for plotting/logging. Diagnostics mode: A clear diagnostic procedure must exist to validate: MUX selection is correct. Each channel responds when pressed. Example: a mode that isolates one channel (like C3) or reports min/max activity per channel over time. 10) PC-side live visualization and logging requirements The PC application must: Read the Pico’s stream from USB serial. Display a live 4×4 pressure heatmap representing the 16 sensors. Provide both views: Measured and Scaled/Normalized. Be visually clean and stable (not “messy”), with clear labeling/indexing so channel mapping is unambiguous. Logging: Save time-stamped data (time in seconds) and all 16 channels (at least pressure, and preferably also voltage and force) to CSV. Produce an Excel (.xlsx) output after a run or on demand containing raw logs and computed columns. 11) Success criteria The solution is considered correct when: A full 16-sensor frame updates at ~20 Hz reliably. Pressing any sensor (including C3) produces a clear, immediate, and correctly mapped response in the live heatmap. The conversion chain produces sensible values with a clear operating focus around 4–8 bar. Calibration handling includes both measured and scaled outputs and respects the 3.00 V @ 450 N constraint when normalization is enabled. The system remains stable and usable in a noisy induction-welding environment through averaging/filtering and diagnostic validation.