Posted on

Roshni’s Status Report for 09/26/2026

This week I took the bandpass filter piece from last week’s Python reference model and implemented it in SystemVerilog, then built a way to prove the hardware version actually matches the software version.

I wrote the filter as a pipelined chain of small multiply-add stages rather than one big calculation, since that structure runs much faster on real hardware. I also set up an automatic export from the Python model that generates matching test files — the same filter settings, a test signal, and the expected correct output — so both versions could be fed identical inputs and compared directly. First run surfaced two real bugs: a scaling error from how the lower-precision hardware numbers get converted back to normal values, and a timing offset where the hardware’s early outputs (before its internal pipeline fully “warms up”) were being compared against the wrong reference samples. After fixing both, the hardware version matched the software version exactly, sample for sample.

For later reference, here’s what I used/researched this week:

  • Icarus Verilog for simulating and running the hardware version
  • SystemVerilog, using a pipelined “transposed” filter structure suited for FPGAs
  • Fixed-point number formatting (converting between normal numbers and the limited-precision format hardware uses)

I am scheduled on track relative to our project roadmap.

For next week, I plan to:

  1. Implement the fractional delay stage in SystemVerilog, verified the same way against the Python reference
  2. Replace the placeholder ultrasonic passband with a real measured leak recording once available
  3. Update mic spacing/count to match Wes’s finalized PCB geometry
  4. Coordinate with Wes to confirm the final array geometry matches the delay-table assumptions
Posted on

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
Posted on

Wes’ Status Report for 09/20/2026

20 September 2026

I primarily worked on researching the geometries required for the 32-microphone array. I then produced the .scr file for Fusion360 Electronics (the PCB design), which took into account PCB routing constraints (such as the placement of the solder pads). I consolidated the “Materials” excel sheet for peripherals that interface with the Ultra96-V2 (camera, LCD display etc.), which included information such as:

  1. Cost
  2. Quantity
  3. Purchase Link
  4. Justification for order

Goals for next week

Place required components onto the schematic in Fusion360, then run all wire routing across all layers of the PCB (including 5V, ground planes). Run DRC and LVS checks across entire PCB board.

Then, submit the order to JLCPCB for a price quotation. Afterwards, submit the 18500 Purchase Request form (sharing the password to the account).

Posted on

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.

Posted on

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

 

Posted on

Roshni’s Status Report for 09/20/2026

This week I built out the software validation layer for our beamforming pipeline before committing anything to RTL. The goal was to get a working, testable reference model of the full delay-sum beamforming chain in Python first, so the algorithm itself is verified before I start writing SystemVerilog.

I built the full beamforming pipeline in software, piece by piece. First, a tool that calculates, for every possible direction and every microphone, exactly how much to delay that mic’s signal — split into a whole-number part (easy to apply) and a small leftover fraction (which needs a bit more work to apply accurately). Second, a filter that keeps only the specific pitch range our leak’s ultrasonic sound lives in. Third, a way to apply that small leftover fractional delay accurately, using a standard interpolation technique, this matches how real published FPGA-based beamformers are built, which I confirmed by checking the research literature before building it myself. Fourth, the part that actually tests each candidate direction: it applies the delays, adds all the microphones together, and does this for every direction in turn, keeping track of which direction produced the loudest combined result. Finally, I ran a test where I deliberately rounded all the numbers down to a lower-precision format similar to what the actual chip will use, just to get an early sense of whether that lower precision would hurt accuracy, before committing to that precision level in real hardware.

To check that all of this actually works, I built a test setup: a simulated ultrasonic sound placed at a few different known angles, “heard” by each simulated microphone with a very precise, trustworthy timing calculation, then run through the whole pipeline above to see if it could figure out the correct angle on its own. The detected angles came out accurate to within the smallest measurable step of our current setup (2 degrees), across every angle tested. Also, the lower-precision version (the one using the rounded-down numbers meant to mimic real hardware) gave results just as accurate as the full-precision version, meaning that, at least so far, using lower-precision numbers on the actual chip likely won’t hurt accuracy.

For later reference, here’s what I used/researched this week:

  • NumPy / SciPy for the signal-processing simulation environment
  • scipy.signal.firwin for FIR bandpass filter design
  • Lagrange interpolation for the fractional (fine) delay stage
  • The coarse-delay + fine-delay (Lagrange/Farrow-style) beamforming architecture used in FPGA-based ultrasound and array-signal-processing literature
  • Fixed-point quantization emulation for an early resource/precision tradeoff check

I am scheduled on track relative to our project roadmap.

For next week, I plan to:

  1. Replace the placeholder ultrasonic passband with the actual measured frequency signature of a real leak recording, once we have one
  2. Update the mic spacing and count in the model to match Wes’s finalized PCB geometry
  3. Begin RTL implementation of the FIR filter module, verified stage by stage against the Python reference model
  4. Coordinate with Wes to confirm the final array geometry matches the assumptions baked into the delay-table math