Week in Review: Jul 13 - Jul 19, 2026

The week started with a jarring reminder of how fragile documentation can be when disconnected from the codebase. I spent the first half of Monday untangling a critical integrity issue in our battery management system (BMS) review, while the second half was consumed by the intricate detective work required to support a power-user tester navigating version control pitfalls in our audio measurement app. It was a week defined by verification—ensuring that what we say exists actually exists, and that what users report is grounded in the actual build they are running.

The BMS Review Integrity Incident

The most significant technical event of the week involved the dashcam-bms project. We conducted a deep-dive review of the battery management logic, resulting in a six-lane analysis document containing 76 findings and five showstoppers. However, a post-review audit revealed a disturbing discrepancy: Section 6 of the review, which claimed that v3 firmware and a v4 enclosure had been built and committed, was entirely fabricated.

Upon verifying against the git history and the disk state, it became clear that none of the referenced changes existed. The bq76920.h header had zero diffs; it still contained the naive voltage cell mapping and the original BQ_ADDR 0x08. The claimed v3 YAML configuration was missing, and only the v3 enclosure SCAD file was present, not the v4 version mentioned in the report. Only the documentation updates and file-tracking commits had actually landed.

To mitigate this, I added a prominent status banner to the top of the review document, committing the correction to ensure that any future reader understands the current state of the project. Every finding tagged against the non-existent v3/firmware or v4/enclosure is now marked as OPEN. The five showstoppers remain active.

Despite this documentation failure, we did make concrete progress on Decision #1. Charles confirmed the cell specifications: 3.8Ah / 3.2V / 12.16Wh. This means our 4S3P pack configuration results in 11.4Ah and 146Wh total capacity. The firmware’s coded pack_capacity_ah_{11.4} is therefore correct, voiding previous disputes based on flawed catalog data. We also locked down the physical dimensions at 26.2×65.7mm, which removes the need for enclosure forking. The only remaining open item in this decision is the charge window, which is still restricted to 0–45°C in firmware, whereas the cells support -20/+60°C for discharge. This needs to be addressed in the next firmware iteration. Decisions #2 through #5, particularly regarding the charger limitations with the CN3722, remain open and will be revisited next week.

Audio App Version Control and Tester Support

A significant portion of the week was dedicated to supporting a dedicated tester, Jared, who was encountering issues with sub-bass polarity detection. The core challenge was not a bug in the latest release, but a disconnect between the tester’s installed build and the latest features.

Jared reported that the new polarity pulse was failing his handheld meter tests. Initial investigation suggested a code issue, but a deeper trace of his activity and the release timeline revealed the truth: he was running v0.20.1, two versions behind the current release. The critical fix for the +100 dB calibration offset was not deployed until v0.20.2, and the new polarity pulse was only introduced in v0.20.3. Since Jared was testing on an older build, he was essentially trying to validate a feature that didn’t exist yet, while simultaneously suffering from a known calibration bug that distorted his measurements.

This highlighted a critical flaw in our distribution strategy. While the Alpha track had v0.20.3, the Internal testing track was dormant at v0.11.4. If Jared was enrolled in the Internal track, he would never have received the newer builds via the standard channel, explaining his persistent stale data. I responded by clearly stating the version discrepancies and asking him to verify his track enrollment. I also provided a direct APK link to ensure he was testing the latest code, regardless of his Play Store track.

On the code side, the v0.20.2 fix was verified as correct. The SystemTestScreen now properly replaces the generic baseline with the user’s calibration offset instead of stacking on it. Interestingly, we discovered that no other screens read this user-specific calibration; RTAScreen and SpectrogramScreen hardcode the default offset. This means there is no “double-counting” bug, but it does leave a documented inconsistency in how SPL offsets are handled across different parts of the app. We decided to leave this as-is for now, as changing it would alter measurements on the Pro tool in a way that might not be backward compatible or headless-safe.

Loudspeaker Catalog Expansion and UI Polish

The second half of the week saw the release of v0.14.5, which included several high-value improvements driven by user feedback. The most substantial addition was support for JBL Professional 70V tap configurations. Previously, the app’s speaker catalog was incomplete for JBL products; none of the nine JBL Professional Control models had taps70v data, forcing users into a generic Custom mode. By extracting the specific tap values from the official JBL spec sheets, we have now populated this data. This is not just a convenience feature; accurate tap values are essential for correct SPL math in professional installations. We transcribed the data directly from the PDFs to avoid any risk of fabrication, ensuring that the 70V column data is precise.

We also improved the usability of the manufacturer picker and the coverage map display. The picker now uses a more logical ordering rather than the first-seen catalog order. Additionally, we fixed several labeling inconsistencies in the editor. Labels such as “Coverage angle - sides” were corrected to “Coverage angle - horizontal,” and “V Dispersion” to “Coverage angle - vertical.” This change was applied across both the main editor and the quick-edit modal to ensure parity.

During the testing of these changes, we uncovered a subtle bug in the side-view coverage display. While the top-down map allowed tapping on a speaker to open the editor, the side view only updated the dB probe readout and did not allow for direct editing. We have queued a fix for this asymmetry, which will unify the hit-test layer for the side view. We also corrected the axis labels on the printed side view to match the heat map, a common source of confusion for users trying to document their setups.

Lessons Learned and Next Steps

This week reinforced two key lessons. First, documentation must be treated with the same rigor as code. A fabricated section in a review document, even if well-intentioned, undermines trust and clarity. Going forward, we will implement stricter checks to ensure that review documents accurately reflect the state of the codebase. Second, version control for testers is a critical part of the development lifecycle. We cannot assume testers are on the latest build, and our distribution channels must be monitored to ensure they are active and up-to-date.

Looking ahead, the focus for the next week will be on the BMS charger decision (CN3722 limitations) and the side-view editing bug in the audio app. We are also considering how to better communicate version status to testers to prevent future confusion. The goal is to ensure that our tools are not only powerful but also reliable and easy to use for our community of developers and professionals.