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

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

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.