Wes’s Status Report for 10/17/2026

Accomplishment

Fabricated PCB arrived at ECE receiving office, as well as all the other components (to be soldered on the PCB). Finalized design report, specifically these sections: use-case requirements, microphone array subsystem (design requirements, design tradeoffs, system implementation). Also filled in section for design and verification.

Did a rough hand sketch of the 3D print mount that holds all the components together. The microphone array PCB will be mounted in front, using four M2 mounting screws. The Ultra96-V2 FPGA will be mounted right behind the microphone array, also using four M2 mounting screws. The Valore powerbank will be mounted behind the FPGA, slotted into a 3D printed slot. The LCD screen will be mounted right behind the powerbank, using four M2 mounting screws.

Schedule

On track

Goals for next week

Solder all components onto the PCB. This will be done in the TechSpark PCB Lab. After PCB assembly, to individually test every microphone for a data signal, before handing it off to teammates for the RTL bringup.

Team’s Status Report for 10/17/2026

Accomplishment

Roshni: Roshni: Retargeted the beamforming RTL to the full 20 to 80 kHz band (384 kS/s, decimation 8, 127-tap filter, 128-sample delay buffers) and regenerated the steering tables for ±52° in 61 steps. All four modules (decimator, filter, fractional delay, scan controller) pass their testbenches against the golden model in both the 384 kS/s and 192 kS/s configurations. Fixed the 192 kS/s filter coefficients and added a clock enable to the filter. The scan controller now outputs a latched 61 × 32-bit energy snapshot with a sweep counter, saturation flag and configurable shift. Also completed a full pass on the Design Report, including verification tests for latency, size and weight, and detection probability.

Wes: The fabricated PCB and all the components to be soldered onto it arrived at the ECE receiving office. I finalized the use-case requirements, microphone array subsystem and design and verification sections of the design report, and sketched a 3D-printed mount that stacks the mic array PCB, Ultra96-V2, Valore powerbank (in a printed slot) and LCD, each on four M2 screws except the powerbank.

Essie: Rewrote the heatmap and capture software to match the final design report (61 angles over ±52°, 105° camera map), running at 30 fps on synthetic data. Added the real data reader and threshold calibration, and drafted a register map and steering ROMs for Roshni to check.

Risks

  • All the components have not arrived and most of work depends on the physical components.

Design changes

  • Normalization: the heatmap subtracts the sweep’s median noise floor before scaling, where the report says to scale by the peak of the full 61-bin sweep. A flat noise floor otherwise tints the whole image, so update the wording in the report.
  • Smoothing Window: The smoothing window is now 4 sweeps (was 3), updated only on new sweeps, and the heatmap subtracts the median noise floor before scaling.

Schedule

On track

Highlights

  • The software now matches the design report end to end on mock data: a 61-angle heatmap overlay at 30 fps, with render time cut from 45 ms to about 5 ms. The real-data path (overlay loader, tear-safe reader, threshold calibration) is ready, so integration only waits on Roshni’s bitstream and register map.

Part A Global Factors:

Pressurized-gas leaks occur in plants everywhere, not only in well-funded facilities, and the cost of commercial acoustic cameras is what keeps many smaller or older plants on manual walking inspections. SoundSight targets that gap with 30 low-cost PDM MEMS microphones and a single FPGA board, aiming to reproduce the core function of a commercial acoustic camera at a lower cost. It needs no network connection, cloud service or specialist setup, so it works in plants with poor connectivity. The output is a colored overlay on live video rather than an audio spectrum, so a technician needs no acoustics training to use it.

Part A was written by Wes.

Part B Cultural Factors:

Plant workplaces differ in safety rules and habits, and the device has to fit them. Many technicians are trained to find leaks by ear or with contact tools, so SoundSight is designed to support that judgment, not replace it. It points to a direction and the technician still confirms the leak by visual inspection or an optical gas imager. Because it is non-contact, a technician stays away from hot or pressurized equipment, which fits safety practices that restrict close contact. Technicians often wear hearing protection, and a visual display works when sound cannot be heard. The interface uses a color overlay and no text, so it does not depend on the user’s language.

Part B was written by Essie.

Part C Environmental Factors:

Leaks waste energy and can release harmful substances. The US Department of Energy reports that leaks sometimes waste 20 to 30% of a compressor’s output in poorly maintained systems, and that proactive detection and repair can bring this below 10%. A 1/4-inch leak at 100 psig costs about $8,400 a year in electricity at DOE’s reference rate. Our device aims to help these poorly maintained facilities find leaks earlier and at low cost, which means less wasted electricity and less release of chemicals, steam or process gas. We also considered the device’s own environmental impact. Our worst-case power estimate is 50 W, so one 2-hour inspection uses about 0.1 kWh, which is small compared with the energy a single leak wastes. The device is rechargeable and uses no disposable batteries.

Part C was written by Roshni.

Next week

Roshni:
Roshni: Build the top level and AXI-Lite register wrapper (including an ID register), then deliver the bitstream, .hwh and a written register map to Essie. Settle the mic clock structure with Wes and add the stored-block energy window to the scan controller. Check Essie’s drafted register map against the RTL.

Wes: Solder all components onto the PCB. After PCB assembly,  individually test every microphone for a data signal, before handing it off to teammates for the RTL bringup.

Essie: Agree the register map with Roshni and swap the mock source for real sweeps. Test the display, cable and camera on the Ultra96, then calibrate the camera and the false-alarm threshold.

Essie’s Status Report for 10/17/2026

Accomplishment:

  • Rewrote heatmap.py to match the final design report: 61 angle bins over ±52° (±50° drawn), the 105° camera with the angle-to-pixel map, and 4-sweep smoothing. Render time for a 1280×720 frame dropped from 45 ms to about 5 ms.
  • Rebuilt capture_with_heatmap.py: MJPG 1280×720 at 30 fps, only new sweeps go into the smoother, per-stage timing and a CSV log. It held 30 fps (about 33 ms per frame) on synthetic input. It also ran with display_output.py, tested against a stand-in for the PYNQ DisplayPort driver.
  • Added source.py (mock source, plus a real register reader that loads the overlay, checks an ID register and rejects torn reads) and calibrate_threshold.py (sets the false-alarm threshold from no-source sweeps; 0.50% observed on 17,897 mock updates). Tested the register reader against a fake PYNQ register block: 0 torn reads in about 100,000 reads.
  • Last week 10/10/2026: finialized all the design and drafted the design report

Schedule Status:

On track. Board integration depends on Roshni’s bitstream and register map.

Planned for next week

  • Agree the register map with Roshni, get the  .bit/.hwh, and start the mock-to-real data swap.
  • Test the Mini DisplayPort to HDMI cable against the actual LCD, and confirm the mode it supports.
  • Run the camera on the board at 30 fps, calibrate its field of view and offset, and calibrate the false-alarm threshold on real sweeps.

 

Team Status Report for 10/3/2026

Accomplishment

Roshni: Replaced the placeholder straight-line array with the real PCB geometry in the beamforming math, no aliasing issue at our target frequency. Got the fine delay interpolator and scan controller working and verified, with bugs fixed in both. Full 30-channel system passed an end-to-end direction test. Started the next pipeline stage.

Wes: Finished PCB placement/routing, added mounting holes, and submitted the JLCPCB order plus all components. Also wrote up the design-report math for the mic array (SPL, aperture sizing, mic noise, SNR).

Essie: Built scan_limits.py and display_output.py, fixed a heatmap FOV bug, added 19 passing tests, and presented at Wednesday’s design review.

Risks

  • Roshni still has an open bug in the decimation stage.
  • Clock frequency still isn’t locked in, and that affects a few other pieces (interpolator, decimation, lookup tables), so it needs to happen soon.
  • The FPGA-to-software interface is still undefined, but we’re closer now that the RTL side is mostly working.

Design changes

  • No changes

Schedule

On track overall. Roshni has one thing to finish next week, Wes is just waiting on parts now, and Essie’s work depends more on teammates’ answers than anything else.

Highlights

Got the full 30-channel system working end to end for the first time — it correctly picked out a known sound direction. PCB design is done and submitted to fab.

Next week

Roshni: find the decimation bug, add full-sweep output to the scan controller, lock the clock frequency, regenerate the lookup tables at full scale. Wes: once the PCB and parts show up, solder everything together in the TechSpark lab and test each mic individually before handing off for RTL bring-up. Essie: get answers on the data interface contract and start swapping in real data, test the DisplayPort-to-HDMI cable on the actual screen.

Essie’s Status Report for 10/3/2026

Accomplishment:

  • Built scan_limit.py (frequency-dependent alias-free steering-angle math) and display_output.py (a display-backend abstraction; for now using laptop cv2 today, pynq.DisplayPort once hardware arrives), both wired into the live pipeline.
  • Added 19 passing automated tests across 4 test files ( test_display_output.py, test_scan_limits.py, plus the two existing suites, still green).
  • heatmap.py : Fixed rendered detection to match the real view with 105 degrere FOV. Verified against existing test suites with no regressions, and visually confirmed in rendered output.
  • Presented for the design review on Wed.

Schedule Status:

on track

Planned for next week

  • Get answers on the data interface contract and start the mock-to-real data swap.
  • Test the Mini DisplayPort to HDMI cable against the actual LCD screen.
  • Start the Design Trade Studies section and BOM entries for the written report.

 

Team Status Report for 09/26/2026

Progress:

  • Wes: Designed the power subsystem (battery sizing, power connectors) and quantified the mic array’s design requirements (SNR, aperture, sound pressure math) in the Design Report. Finalized PCB schematic/layout in KiCad, passed DRC, got a fabrication quote (~$30/5 boards).
  • Roshni: Implemented the bandpass filter in SystemVerilog (previously Python-only), built automated tests comparing hardware vs. software output, found and fixed two bugs (scaling error, pipeline timing), now matches the Python model exactly.
  • Essie: Stress-tested the heatmap against noise/multiple leaks, found and fixed a false-positive bug, reduced the error rate from 12% to 1.5% (under the 10% requirement) via averaging.

Risks: Several teams’ numbers (array geometry, filter band, noise thresholds) are still placeholders pending real hardware — mitigated by developing independently against realistic assumptions now, syncing once hardware’s in hand.

Design changes: None.

Schedule: On track, all three members.

Highlights: Wes has a fabrication-ready PCB with a real quote; Roshni’s RTL now matches the software model sample-for-sample; Essie’s fix brought the false-positive rate from 12% to 1.5%.

Part A Public Health and Safety

SoundSight reduces physiological risk by letting technicians detect gas leaks, including hazardous or asphyxiating gases without needing prolonged close-range exposure to the leak source. The device is non-contact and passive, it localizes leaks acoustically from up to 10 feet away, so the technician doesn’t need to physically approach, touch, or probe potentially pressurized or hazardous equipment the way contact-based methods require. This directly removes a physical-harm pathway from the inspection process itself.

Part A was written by Essie.

Part B Social Factors:

Project SoundSight addresses the social barrier created by the high cost of existing ultrasonic acoustic cameras, which can run tens of thousands of dollars and are therefore accessible only to large corporations with dedicated reliability teams. By building on a low-cost FPGA platform and commodity MEMS microphones, the device lowers the economic threshold so that smaller manufacturers, municipal utilities, public school districts maintaining aging HVAC systems, and community-owned cooperatives can perform inspections that were previously out of reach. This broadens who gets to participate in proactive infrastructure maintenance rather than confining it to well-funded specialists.

Part B was written by Wes.

Part C Economic Factors:

Our product targets an economic problem for facilities that run compressed air or pressurized gas lines: leaks waste energy and money, and finding them takes time. The U.S. Department of Energy estimates that leaks can waste up to 20 to 30 percent of a compressed-air system’s output, which is a continuing operating cost for any plant that runs one. Routine leak surveys are how facilities control that cost, but the tools available sit at two extremes. Professional acoustic-imaging cameras (FLIR’s Si-series, Distran) are priced for large industrial budgets. Fixed camera systems like the one in Lee et al. (2024) need dedicated hardware at each monitored point, so covering a whole facility would take one unit per fitting. Smaller facilities and budget-limited maintenance teams often end up skipping routine surveys, and they absorb the wasted energy as a result.

Part C was written by Roshni.

Essie’s Status Report for 9/26/2026

Weekly Status Report — Camera Pipeline (Image Capture)

Accomplishments (with proof):
Built out multi-peak and noisy-data robustness testing for the heatmap rendering pipeline, since prior work only validated a single clean signal. Extended the mock data generator to simulate multiple simultaneous sources and configurable noise, then ran it through the existing overlay renderer to see what broke. Found and fixed a real bug: the renderer normalizes each frame to its own loudest bin, so pure sensor noise with no real leak present was still displayed as a confident-looking red detection blob. Added an absolute detection threshold to gate this out. Quantified the remaining false-alarm rate via 200 randomized trials of a weak signal in high noise: a single-sweep check gave a 12% false-alarm rate (above our ≤10% requirement); averaging 3 consecutive sweeps before thresholding dropped it to 1.5% while improving true-detection rate to 98.5%. Implemented this as an EnergySmoother and wired it into the live demo. Proof: saved test images showing the bug (solid red blobs on pure noise) vs. the fix (clean video), plus the trial-count numbers from the false-alarm simulation.

Status: On schedule. This work also surfaced a concrete, quantified item for the Testing/Metrics section of our requirements (false-positive rate), which we didn’t have real numbers for before.

Next week:

  • Build a live noisy-data demo (currently only tested via saved images, not on camera) to visually confirm the fix in real time
  • Revisit the closely-spaced-sources finding (sources ~4° apart merge into one blob, consistent with the array’s ~3.2° resolution estimate) and note it as a known limitation
  • Continue pushing on the data interface contract with Roshni, since all current numbers (noise floor, threshold, smoothing window) are placeholders pending real hardware measurements

Team Status Report for 09/20/2026

This Week’s Progress:

  • Roshni built a full software (Python/NumPy/SciPy) reference model of the delay-sum beamforming pipeline to verify the algorithm before committing to RTL. Validated against simulated sources at known angles, correctly resolving direction to within the test setup’s 2° resolution limit, and confirmed that a lower-precision (fixed-point-like) version performs just as accurately as full precision.
  • Wes researched 32-mic array geometries, produced the Fusion360 Electronics schematic (.scr) for the custom PCB, and updated the materials/peripherals list for components interfacing with the Ultra96-V2 (camera, LCD display, etc.).
  • Essie built and validated the camera capture pipeline, achieving stable ~30fps live capture with fps logging and automatic frame saving.

Risks & Mitigation:
The main risk is cross-subsystem dependency timing: the beamforming reference model, PCB array geometry, and camera/overlay work all make assumptions (angle count, mic spacing, steering range, output format) that need to converge before integration. We’re mitigating this by having each piece proceed independently against placeholder/mock values now (Roshni’s model uses a placeholder passband, Essie’s overlay work will use mock beamforming output) so no one is blocked waiting on another’s final numbers. We’ll reconcile assumptions once Wes’s PCB geometry is finalized. Secondary risk: hardware not yet in hand (camera, fpga, fabricated PCB), mitigated by validating all logic in software/on substitute hardware first.

Design Changes:
We narrowed the camera/array steering range from a full 180° sweep to a 60–70° forward cone. This was necessary because 180° coverage would require a fisheye lens (adding lens distortion calibration work) and would strain the per-angle cycle budget on the FPGA side. Cost: reduced single-position coverage, making the tool more of a “point-and-scan” device rather than a full-room scanner. This is mitigated by the fact that it matches how commercial acoustic cameras are actually used in the field, and it simplifies both camera selection (standard FOV) and the beamforming compute budget — a net simplification, not a scope loss.

Schedule: On track — no changes to the timeline this week.

Essie’s Status Report for 09/20/2026

Accomplishment

Set up and validated the initial camera capture pipeline for the software/imaging side of the project, using my laptop’s built-in webcam as a stand-in for the C922 (borrowed but not yet in hand — same UVC standard, so the code transfers directly with no changes once it arrives).

  • Set up a Python + OpenCV development environment
  • Wrote and debugged capture.py: opens a camera device, streams live video, and displays a real-time preview window
  • Implemented frame-rate logging (prints live fps to console every 2 seconds) to verify capture stability
  • Implemented automatic and manual frame-saving to disk for later inspection and testing
  • Verified stable capture performance: ~29–30 fps sustained after initial camera warm-up, confirmed via console logs and saved frame inspection
  • Structured the code with a single configurable camera source parameter so switching from the laptop webcam to the C922 next week requires no code changes

I am on schedule. While I wait for camera to come, I can start working on other things.

Next Week

  • Receive and test with the actual C922 camera, confirming capture parameters (resolution, fps) match or need adjustment
  • Build the heatmap-rendering logic using simulated/mock acoustic energy data (angle + intensity values standing in for the eventual FPGA output), including color-mapping and alpha-blended overlay onto live video frames
  • Combine the camera capture pipeline and mock heatmap overlay into a single end-to-end demo
  • Begin coordinating with the RTL/hardware team on the exact data interface format (value range, update rate, number of angle bins) the FPGA will send, so the mock data generator matches the real interface