Posted on

Ankita’s Status Report for 10/17

Accomplish

This week, I focused on the firmware portions of the Design Review Report. I outlined how camera frames and microphone samples will be timestamped, queued, and written to the microSD card while capture continues. I also worked through the rolling-buffer and clip-preservation design, including how overlapping saves can share stored segments. For testing and validation, I helped define checks for capture continuity, audiovisual synchronization, trigger timing, and clip integrity.

Progress/Schedule

Firmware implementation is slightly behind schedule, with more progress made on defining the design than testing it on hardware. My priority is to establish a reliable capture-to-storage pipeline before adding preservation and transfer functionality. Testing this foundation early will help identify whether our estimated frame sizes, storage rates, and queue capacity are realistic. Right now, I am still waiting on being able to use the ESP32 to test out the firmware plans.

Deliverables

Next week, I plan to test camera capture and microSD writing on the ESP32-S3, measuring frame sizes, capture timing, and write latency. I will use these measurements to refine the staging queue and segment-writing logic, then begin implementing the rolling buffer and save-button handling. The immediate goal is to produce timestamped recordings that can serve as a baseline for testing retrospective capture.

 

Posted on

Jayden’s Status Report for 10/17

Accomplish

This week I focused on the Design Review Report, specifically narrowing our specifications as we have decided to focus on making the Capsure device used by pool players. The most important piece I worked on was the Design Requirements since I needed to balance feasibility with sufficiency, while also making sure that it was well defended. I assisted Clarence with soldering the battery for the ESP32.

Progress/Schedule

In terms of the software component, we are still slightly ahead of schedule. However the more time-variant portion will be to establish a reliable connection between the ESP32 with the device. Now that our use case has narrowed and the design is flushed out, the application integration should be easier to debug when problems arise.

Deliverables

This week I want to test out the ESP32 camera parameters which include resolution, frame rate, compression rates and power consumption. These matter a lot because in the design requirements the numbers were calculated using optimistic values and estimates from online, but it is likely that the measured ones will deviate slightly so we will need to adjust our calculations accordingly.

 

Posted on

Team Status Report for 10/17

Team Progress

This week our team worked together to complete the Design Review Report. After discussing with the course staff, we narrowed our use case to be primarily for billiard players. This way, our use-case requirements and report could be more specific in defending in what we presented.

Risk Mitigation

Now that the ESP32 has arrived some risks shift from theoretical to physical. Soldering errors and damaged components during assembly are a concern, since short circuits and weak connections could cause further damage later on and become difficult to diagnose. To mitigate this we have spare components for most hardware pieces, so that we are able to isolate errors to components and switch them out if necessary. Another risk is that the software transfer protocol in the current version of the application doesn’t work with the ESP32, and we can mitigating this risk by adapting the firmware and software to the hardware based on our testing this upcoming week.

Changes

Narrowed our primary use case to billiard players. However, we still noted that CapSure has many other applications but aren’t directly supported by our requirements.

Weekly Prompt

Part A: CapSure is designed to help billiard players capture and review shots without having to record an entire practice session. This need is not limited to one location or type of player. Billiards is played recreationally and competitively in many countries, so the system should be simple enough to use without requiring advanced technical knowledge or expensive equipment.  The recordings can be transferred directly to a phone over Wi-Fi, which avoids relying on cloud services or a constant internet connection. This makes the product more practical in pool halls, homes, or other environments where internet access may be unreliable. Keeping the system lightweight and built around a standard baseball cap also helps make it portable and usable across different settings.

Part B: CapSure addresses the desire to preserve memorable shots while respecting social expectations of shared playing spaces. Players may have different attitudes towards being recorded, and our intended use therefore involves informing participants as they are recording and making footage easily able to be discarded. The outward-facing indicator makes active capture readily visible, while local storage and user-controlled export give the wearer control over whether footage is shared. CapSure’s accessible physical controls allow players to save a shot without handling a phone, limiting interruptions to the pace of play, which is important for etiquette during a billiards game.

Part C: CapSure’s environmental footprint is small but not zero, since it is adds a battery powered electronic device to a customer’s tech ecosystem which will eventually result in e-waste. The housing will also be a plastic filament which is not biodegradable and will end up in landfill. However, the low resolution and low frame rate capture keeps power draw minimal and extends battery health, and since we are not using cloud storage, there is no ongoing energy cost of remote data centers. Option of local battery disposal and recycling will reduce the impact even more, depending on the user’s region.

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

Posted on

Clarence’s Status Report for 10/17

Accomplish

This week (mainly the week before Fall Break), I worked a lot on our Design Review Report which we’ll talk more about in our Team Status Report. Personally, I picked up all of our ordered components from the ECE Receiving office and began soldering together our ESP32 with a pin header and our LiPo battery chargers to their cables so we could begin testing. I confirmed that our ESP32-S3 is functional with some simple Arduino Example code and was able to confirm that our ESP model has the OV3660 and not the OV2440.

 

Progress/Schedule

I think we may be a little behind due to our lack of progress during this Fall Break.  However, all our components are set to be put back onto schedule with a little extra work next week. In regards to the 3D CAD, I might save that for later in the semester and focus on prioritizing ESP and firmware. However, I will start gauging rough measurements for the 3D enclosure.

Deliverables

Next week, I hope to assist Jayden and Ankita with the firmware and experimentation. In addition, I want to also start planning what we want the 3D enclosure to look like and how it’ll be attached to the hat. I also want to place orders for some caps for us to work with.

Posted on

Team Status Report for 10/03

Team Progress

After the Design Review presentation on Monday, our team worked on the Design Report and on preparing for the hardware’s arrival. Ankita planned the firmware implementation and explained how our firmware choices support continuous recording, clip preservation, and transfer to the phone. Clarence sourced the remaining parts we need for integration, including connectors, switches, buttons, and breadboards. He also arranged access to a 3D printer for the enclosure and began learning CAD. Jayden made the phone app more robust against failures the real board could cause. Interrupted downloads now resume, each clip is checked before the device is allowed to delete it, and the app now validates the network being used.

Risk Mitigation

The main risk is still the arrival of the ESP32-S3, since sustained recording and recording during a transfer can only be measured on the real board. To prepare, Ankita is reviewing the camera, microphone, PSRAM, and SD card interfaces and writing initialization code so testing can start immediately. Her first goals are to confirm memory and storage, capture a JPEG, and check the microphone before building the full recording pipeline. Dropped frames from SD card write delays or Wi-Fi activity remain a concern, and we plan to address them with buffering and by batching SD writes. On the app side, we updated our mock device to behave like the ESP32, so connection problems surface during development instead of at integration.

Changes

There were no changes to our requirements or hardware this week. The app now downloads each clip as a series of small chunks, so an interrupted transfer only has to redo the chunk it was on. This fits within our existing communication protocol, but the firmware will need to handle many small requests reliably. We also plan to replace the shared development Wi-Fi password with a separate password for each device, so one user cannot connect to another user’s hat.

Posted on

Jayden’s Status Report for 10/03

Accomplish

This week, while we wait for the ESP32 to arrive, I focused on making the phone software robust against failures the real board could cause.

The device client now sends one request at a time, retries when the device reports it is busy, and pauses status updates during transfers.
Downloads now resume where they left off, and each clip is checked for size and parsed before the app tells the device it can free the space.
The app now gives the user clear instructions, such as turning on the Wi-Fi switch, instead of generic errors.
I also added security checks to validate clip IDs coming from the device, accepting only local network addresses. Finally, I updated the mock device so it behaves more like the ESP32 and can simulate dropped transfers. That way these cases are tested before the hardware arrives.

Progress/Schedule

We are still slightly ahead of schedule on software. The hardware hasn’t blocked progress, because the work moved to edge cases and reliability that would otherwise have been found during integration.

Deliverables

The next deliverable is still an end-to-end Wi-Fi transfer from a real ESP32 to the Expo Go app, now tested against the single-client and interrupted-transfer cases. After that, I’ll connect the settings screen to real device readings (battery percentage, temperature, and storage remaining), and work with Ankita on per-device Wi-Fi credentials.

Posted on

Ankita’s Status Report for 10/3

Accomplish

Following our Design Review presentation on Monday, I shifted my focus toward the written Design Report and planning the firmware implementation. I worked on explaining how our firmware choices support the project’s requirements, particularly continuous recording, reliable clip preservation, and transfer to the phone. I also developed more of the discussion of public health, safety, and welfare, connecting the design to reduced user distraction, recording awareness, and clear feedback about whether footage was saved. For risk management, I identified SD write delays and Wi-Fi activity as potential causes of dropped frames and outlined buffering, write batching, and other transfer risk mitigation strategies.

Progress/Schedule

Firmware work remains on schedule at the design stage, with hardware testing pending the ESP32’s arrival. the next step is translating the architecture into preliminary code and resolving some storage allocation details. However, actual sustained recording performance and the details of recording during transfers remain the main unknowns as we can only figure those out once we are able to test on the board.

Deliverables

Next week, I will finish my contributions to the Design Review Written Report and begin setting up the firmware project in our repository. I plan to review the camera, microphone, PSRAM, and SD interfaces and prepare initialization code so we can begin testing promptly when the board arrives. My first hardware goals will be confirming memory and storage operation, capturing a JPEG, and checking microphone input before combining them into the recording pipeline.

Posted on

Clarence’s Status Report for 10/3

Accomplish

After preparing for and presenting our Design Review Presentation on Monday, I researched the smaller/cheaper hardware components that our project may need. Since last week we decided on our project’s main stars (ESP32, 2000mAh LiPo battery, microSD), this week I needed to make sure we had all the components necessary in order to fully integrate in the end. This includes connectors, switches, buttons, breadboards, and other electrical parts for testing/integration. In addition, I reached out to TechSpark and a backup option for 3D printer access so I could be sure we had printing capabilities for our eventual CAD enclosure designs. I’ve begun learning basic 3D CAD in TinkerCad and digging into the optimal ways to attach modules onto the physical hat.

Progress/Schedule

Progress is on schedule. All major components will arrive soon to begin hands-on development. Then I can also begin soldering our LiPo chargers together and the pin header to ESP and measure dimensions for enclosures.

Deliverables

We have started on the Design Report and will have it complete by next week (because it is due). Also hope to deliver simple CAD designs and circuit diagrams.

Posted on

Ankita’s Status Report for 9/26

Accomplish

This week, I focused on defining CapSure’s firmware architecture and preparing those portions of our design review presentation. I developed the design flow covering initialization, continuous recording, and the transition from filling the initial buffer to maintaining a rolling 60 seconds of footage. I also refined the different signals triggered to transition from one stage to another in the flow, as well as refined the specification user-button interaction so that one button press preserves footage and stores it on the device and a separate button press triggers Wi-Fi enabling and the transfer to the user’s phone, all while recording continues in the background. I worked through overlapping saves, interrupted downloads, and deleting saved clips only after the phone verifies that it has received the footage. Additionally, I outlined the recovery behavior for component failures and contributed quantitative testing plans for video quality, A/V synchronization, buffer preservation, and recording during transfers.

Progress/Schedule

The firmware is currently on progress with the schedule, and in the design stage, with hardware implementation pending on the ESP32’s arrival. The main recording and saving behaviors have been defined, but storage allocation still needs to be worked through a bit more. My immediate focus will continue to be refining the firmware structure, identifying more edge case scenarios to think through, and resolving these design details before our materials come.

Deliverables

Next week, I will flesh out the firmware flowcharts more and contribute the architecture and testing sections of the Design Review Written Report. I will also set up the firmware project in our GitHub and begin defining the capture, buffering, and saved-clip management interfaces. Once the board is available, my first hardware milestones will be confirming PSRAM and SD operation, capturing a valid camera frame, and transferring a preview over Wi-Fi for integration with Jayden’s mobile app.

Posted on

Jayden’s Status Report for 9/26

Accomplish

This week I focused on the scaffolding of the phone side of CapSure, to set up the development environment and transfer over a video wirelessly on a mock application. The app successfully renders and is able to download videos, and I also locked the open transfer architecture questions to using WiFi gated by a physical switch, after reasoning about the user flow within the application.

Progress/Schedule

In terms of software, we are slightly ahead of schedule as I have shown that the current software stack is likely to work, however we will have to wait until the ESP32 arrives before I can adjust the transfer protocol to match the device.

Deliverables

The next main deliverable on my end is a fully flushed out connection over a real board over Wifi, even without the camera it would be an accomplishment to be able to transfer data from an ESP to an ExpoGo app. Additionally, functionality to change the app from a mock to real displays including battery percentage, temperature and memory remaining.