Clarence’s Status Report for 9/26

Accomplish

This week I nailed down the specific components for CapSure’s build. I put together a Bill of Materials in a Google Sheet, cataloging suppliers, part links, and unit costs, and worked through the associated Purchase Forms. While researching the Seeed Studio XIAO ESP32-S3, I confirmed the Sense variant integrates an OV3660 camera module and a digital MEMS microphone on-board, which saves us from sourcing and wiring separate peripherals. For storage, I settled on a High Endurance microSD card, since standard consumer cards aren’t rated for the sustained write cycles that continuous video/audio recording demands and tend to degrade quickly under that kind of load. I also ran rough power budget calculations, estimating roughly 400mA average current draw for the system, which is what led me to spec out 2000mAh rechargeable LiPo cells to hit a reasonable runtime target. Separately, I realized our original use-case requirements were functioning more like design requirements, so I restructured them accordingly. For instance, the video/audio quality requirement shifted from a hardware-specific spec (“480p 15fps”) to a functional one (“identify a person at X distance and understand speech at X distance”), with the original spec repurposed as the design requirement it was actually describing.

Progress/Schedule

We’re mostly tracking on schedule, though the ESP32 order is a mild risk. Amazon’s had the shipping at an estimated arrival in early-to-mid October and that was if the order was placed today. To use that dead time productively, I’m planning to get ahead on firmware architecture and wiring diagrams, and start sourcing smaller components (buttons, switches, wire, breadboards) so we’re not blocked once the ESP32 lands.

Deliverables

This week’s goals: finish placing the remaining parts orders, track down where to get the smaller components on campus, and start ramping up on basic CAD tools so I can get familiar with TechSpark’s 3D printing workflow for the enclosure. We’re also aiming to have the Design Review Written Report ready to submit.

Team Status Report for 9/26

Team Progress

This week our team made lots of progress on flushing out all the details of our hardware and communication protocol between the CapSure module and mobile app.

Risk Mitigation

Right now the most significant risk is probably the delivery time of the ESP32-S3 which is the most essential piece of hardware we need to begin testing and development. To mitigate this, we will read the documentation and begin writing preliminary firmware so that we instantly have code ready to program once it arrives. Another risk to figure out is the transfer of the footage from the SD card to the phone, as write delays or Wi-Fi transfers could cause dropped frames or gaps in the rolling buffer, which would compromise the footage that we intend to preserve. To manage this, we updated testing requirements to test simultaneous saving and downloading; if these tests fail, we will adjust buffer allocation and SD write batching.

Changes

We took the feedback from the professors and agreed to update our use-case and matching design requirement for the battery life of our system. CapSure will now aim to support over 5 hours of continuous use to better suit the wide range of use-cases our intended audiences will have. We also updated our system such that Wi-Fi is a separate switch from the button to preserve the last 60 seconds; this allows the user to use CapSure in situations where they do not have their phone.

Additionally, we updated our Gantt Chart for our Design Presentation to include Division of Labor as well as important deadlines.

 

Weekly Prompt

Part A) CapSure addresses public health, safety, and welfare by allowing users to preserve a preceding minute of what just occurred in front of them without need to anticipate an event or immediately take out their phone. While some use-case scenarios are more fun (ex: capturing a missed moment at a sports game), CapSure also promotes welfare by accommodating cases where a person may be alone and want to record their surroundings for safety. Since CapSure is hands-free and records without needing a human trigger, this can  reduce the distraction of actively filming and help users document unexpected incidents. To support physical well-being, our design targets a module weighing less than 100g and contact-surfaces below 43°C, to liit the added weight and heat exposure for the user during wear. Retrospective recording can also support psychological well-being by giving users a way to revisit important events. To address the safety of bystanders and avoid CapSure being used as a hidden camera, a visible recording indicator on an LED will be on whenever the camera is on. The user is also able to delete footage on the app easily after it is saved, in the case that a bystander requests so. Wi-Fi only activates when the user presses a separate button, and saved clips remain protected until the phone verifies receipt. By keeping recording and retrieval local rather than requiring internet access or a cloud subscription, CapSure supports users’ access to personal records while limiting ongoing costs and dependence on external services.

Part B) CapSure is designed to meet the need for capturing unexpected moments after they occur while also considering the privacy concerns created by wearable cameras. A user may want a record of an incident, conversation, or event, but the people around them may not expect or feel comfortable being recorded. Attitudes toward recording in public can also vary between communities and social settings. To make recording more visible, CapSure includes an LED that remains on whenever the camera is actively capturing, giving nearby people a clear indication that the device is in use.

CapSure also limits how much footage is retained. The system continuously maintains only the most recent 60 seconds of footage, and a clip is permanently saved only when the wearer presses the physical trigger. This avoids creating an all-day archive of everyone the wearer encounters. Saved clips are stored locally rather than automatically uploaded to a cloud account, and transferring a clip requires the user to deliberately enable Wi-Fi and initiate the transfer. These design choices allow CapSure to provide retrospective recording while reducing unnecessary collection and sharing of footage involving bystanders.

Part C) Market alternatives like action cameras ($500+), smart camera glasses ($300+), and standard dashcams ($300+) carry high financial barriers for everyday use. CapSure addresses these economic factors by streamlining the product life cycle across production, distribution, and consumption. In production, using low-cost, modular commodity hardware like an ESP32-S3, 3D-printed mounts and simple switches keeps the initial manufacturing bill of materials under $50 while allowing flexible design iterations to easily swap components such as larger SD cards or better microphones to match evolving consumer demands. For distribution, CapSure fits directly into the user’s existing tech ecosystem by mounting on hats they already own and offloading clips directly to the smartphone they already carry, eliminating the need for redundant displays or extra peripherals. Finally, for consumption, CapSure operates on a buy-once, zero-subscription model since no cloud storage is necessary, delivering a low-cost and accessible way to capture and store personal moments.

Part A was written by Ankita, Part B was written by Clarence, and Part C was written by Jayden.

Team Status Report for 9/19

Team Progress

After our Proposal Presentation where students and professors brought up good questions during the Q&A, we finalized our use-case scenarios and with that the quantitative requirements we want our project to achieve. We are now moving forward with the design phase where we are doing deeper research into hardware components, specifications, and software architecture.

Risk Mitigation

The most significant risk to our project is lack of research into parts leading to us ordering hardware that won’t be used or turns out to be insufficient to our project demands. To mitigate this, we are flushing out the design which will be presented in our Design Review deliverables next week.

Changes

No changes to the project plan or schedule were made.

Jayden’s Status Report for 9/19

Accomplish

Did more extensive research on the software constraints for the project. The ESP32 will use Bluetooth Low Energy (BLE) but we should still have Wi-Fi for transfers fast enough to meet our requirements. For development I have chosen to use ESP-IDF in cursor for AI assistance, which will hold an http server and wifi endpoint. I am also choosing to use Swift with Xcode since I have had experience there.

Progress/Schedule

So far, everything is on schedule and we are stretching tasks forward from the gantt chart to frontload work and increase parallelization.

Deliverables

Next week I’ll set up the software stack and design a MVP software architecture with transfer protocols in the Design Review, and also determine how the phone should join the device’s Wi-fi/connection, because a new potential issue is that user’s don’t want the friction of switching Wifis.

Ankita’s Status Report for 9/19

Accomplish

I spent this week refining the embedded side of the design and figuring out how data should move through the system once recording starts. In particular, I looked into how to use PSRAM as a short-term queue for the incoming microphone and camera data before it is written the MicroSD cards. I also looked at how both streams can share timestamps so that the 480p/15 FPS video recording and the 16 kHz audio recording can stay synchronized during the continuous recording and produce a synchronized video when transferred to the mobile app.

Progress/Schedule

We are still on track with the planned schedule. At this point, the buffering and storage flow is better defined, which makes the next implementation steps clearer. The plan is still for the ESP32-S3 to handle A/V timestamping, PSRAM queues, trigger logic, and segmented MicroSD storage for the rolling 60-second buffer .

Deliverables

For next week, I plan to turn this design into a more concrete firmware plan for the Design Review. I plan to focus on the capture pipeline, the rolling buffer logic, and how the button press will lock the correct segments so they do not get overwritten. I also want to define how asynchronous SD writes should be organized so temporary write delays don’t cause any dropped video frames or desynchronization between the audio and video clips.

Clarence’s Status Report for 9/19

Accomplish

This week, I did deeper research into the exact components we need and ensuring their compatibility with each other and our use-case requirements. I’ve created a Bill of Materials Google Sheet where I am brainstorming components and sourcing their links and prices to eventually submit through the Parts Order Form. Our main SoC will be a ESP32-S3 module where I’m currently looking at the Seeed Studio XIAO ESP32-S3 Sense because it already houses a camera and microphone.

Progress/Schedule

Our progress is on schedule.

Deliverables

Goal is to have a great amount of the Design Review deliverables finished within the next week.