Posted on

Matthew Kwee – Status Report for 9/26

This week, I started coding the webapp (GitHub link), as per our ideal schedule. Brainstorming the site specifications took longer than I expected, but I was able to make decent progress in setting up the relevant architecture/libraries and building the UI.

This project is intended to provide a low-cost, low-config web and telemetry application that ingests positioning and inertial data from swimmer wearables and poolside compute, extracts biomechanical and split metrics in real time, and presents actionable data to coaches standing on a wet pool deck via standard consumer tablets.

When considering how the site should function, I took into account:

 

  • Wet-Deck Ergonomics and Water Splashes:

Water droplets, wet hands, and poolside humidity can cause unexpected inputs on mobile touchscreens. To mitigate this issue, I constructed a mobile-friendly UI with large, easy-to-find buttons. Additionally, I implemented a “lock” function that disables all screen inputs while keeping data live, unlocked only by a deliberate 2-second press-and-hold gesture.

 

  • Direct Sunlight and Outdoor Visibility:

Standard dark interfaces or subtle gray text are completely washed out by glare and midday sun at outdoor pools. I added an alternate Outdoor High-Contrast Mode with a monochrome light palette and thick solid black borders to maximize visibility, while allowing users to choose between it and a lower-contrast Indoor Mode.

 

Display Sleeping after inactivity:

Many tablets will automatically sleep after a few minutes of inactivity – coaches cannot be expected to repeatedly tap the screen to keep it awake. Fortunately, modern browsers provide a Screen Wake-Lock API that keeps tablet displays awake indefinitely while active – I added a toggle that enables/disables this API.

 

Wireless Jitter and Out-of-Order Sensor Packets:

RF signals around water tend to reflect or scatter, causing packets to arrive out of chronological order or duplicate unpredictably. While the physical poolside central compute unit will deal with the interference when receiving data from the wearable devices, we cannot guarantee that the packets it broadcasts for the web-app will not also be distorted. As such, a stream-level Jitter Buffer was added to the ingestion pipeline to reorder packets by sequence ID, discard duplicates, and smoothly flush packets to the analytics engine.

 

  • Inaccurate Splits on “Soft-Touch” Finishes:

When tired, swimmers may finish a set with a gentle glide rather than a violent slap against the wall – as such, the wearable device may not be able to determine when the swimmer completes the lap. To address this, I implemented a Timestamp Backtracking Algorithm to scan through recent position and velocity history once a wall dwell is verified, finding when speed drops below 0.2m/s (value subject to change).

 

Rapid Staging and Hardware Swaps:

Coaches will only have a few minutes before practice to assign wearable devices to their swimmers, and must have the ability to switch out tags for any reason (malfunctioning, low battery, swimmer leaving practice early, etc.) so a 3-Tap Pairing Workflow (tag -> swimmer -> lane) and a 1-Tap Swap Tag Menu were implemented, allowing a coach to quickly assign a name to a tag, or re-assign a tag mid-session.

 

(Apologies for the poor image quality; WordPress has a 2MB file size limit)

AI was consulted for the site’s frontend, especially the stylesheet and UI, since I have little experience in UI design.

While the website still needs more work, I plan to take a break from software development next week to focus on the wearable device; we need to finish a prototype wearable and start gathering real data before we can test the compute unit and webapp.

 

 

 

 

Posted on

Jeffrey’s Status Report for 9/26/2026

This week, most of my effort went into researching, specifying, and validating our design details. Prior to this week, our design and implementation still had a lot of details up in the air, such as how our wearable device would be implemented and what components we were going to use. I conducted extensive research this week to determine specific parts, communication protocols, and organization of our system down to the component level to get a much better understanding of the specifics of our implementation. I also tried to make sure all the different parts were mutually compatible. Details I researched/validated include:

  • Decision to develop both a prototype wearable using off-the-shelf modules and a custom PCB for our final project. 
  • Choice to use a Raspberry Pico for prototype wearable versus Arduino due to better specifications (buffer storage, RAM) for our use case.
  • Choice of Pimoroni MCP73831 to handle power to prototype device
  • Choice of 3.7V 400mAh JST-PH LiPo battery to power prototype device.
  • Choice of Seeed XIAO RP2040 Plus as compute on PCB final product.
  • Choice to use 502025/502030 3.7V LiFePo battery on final product.
  • Worked with Haowen to advise about networking component choice regarding compatibility with Pico/FPGA.

For all these design choices, I researched the tradeoffs of the exact components, considered alternatives, made sure they could integrate well with the rest of the components, and found in-stock listings.

With all these design choices further considered, I now feel I have a much better understanding of the direction of our project. That was further solidified by my work on the content of our design review, including with the rough-sketch diagrams that are adapted for our slides. In preparing for the design review, I was led to really think through our complete design and do further research where necessary to confirm the soundness of our design decisions.

My progress on the schedule is not behind per se, but my role for the short term I feel is adapted a bit. Upon further research, the FPGA element may be better left for later while the implementation of the wearable prototype is taking more precedence. I took receipt of the physical FPGA, but the power supply is not in yet, so I can’t do much work in that department. That is why I took on work in researching the wearable prototype design, while Matthew is going to begin development on the wearable PCB.

In the next week, I hope to have all the parts I’m responsible for 100% confirmed and ordered. I am most of the way now, but some final compatibility/organizational checks with the rest of the team are in order before committing to the purchases. Depending on how soon parts arrive, I hope to be able to test a rudimentary communication between the FPGA and the networking module attached to the Pico. 

Posted on

Haowen’s Weekly Status Report (Week 4)

Accomplishments

  • Reviewed the finalized NRF24L01+ wireless module datasheet and documentation to identify power, RF, and integration requirements.
  • Researched antenna placement and enclosure thickness guidelines to inform the wireless enclosure design.
  • Identified key power and RF considerations, including the 3.3V supply requirement, power stabilization, RF channel matching, and Wi-Fi interference avoidance.

Progress / Next Steps

  • Finalized the wireless module selection and established baseline electrical/RF requirements.
  • Use the identified antenna and enclosure constraints to evaluate candidate enclosure materials and dimensions.
  • Next, prototype the wireless module in the proposed enclosure and validate communication reliability and range.

Deliverables

  • Documented NRF24L01+ module specifications and integration requirements.
  • Compiled preliminary antenna placement and enclosure design guidelines.
  • Established initial wireless design constraints:
    • Supply voltage: 3.3V
    • Power stabilization: 10 µF capacitor across VCC and GND
    • RF configuration: Matching channels between transmitter and receiver
    • Interference: Avoid RF channels 2–4 due to overlap with common Wi-Fi bands
Posted on

Team Status Report for 9/19/2026

At this point, the most significant risks we foresee pertain to how quickly we can finalize some of the additional choices in our design, such as whether the wearable will utilize a microcontroller vs PCB and the components on the wearable such as the IMU, the voltage the devices will operate at, and the exact frequency band.

To manage these risks, we have assigned different areas of further research into the commercially available microcontrollers and components, and the optimal frequency to transmit at. In case our microcontroller/PCB decision ends up needing to be changed, we will still be able to test out components such as the radio transmitter on off the shelf components we have (Arduino).

We have not made any changes to the design of our system yet, as we are still working to finalize some of the final pieces of our initial design. No changes to our schedule have occurred.

 

Posted on

Jeffrey’s Status Report for 9/19/2026

Accomplishments:

My accomplishments this week were in the preparation of our proposal slides, as well as individual research into the FPGA aspects of our project. Prior to Monday, I worked on synthesizing the details and feedback we received on our abstract, identifying potential gaps in our abstract, and researching further specifics to build on and quantify our use case/requirements/implementation. That enabled my contributions towards my sections of the slide deck. After Monday, I continued doing research and gathering data to finalize the FPGA selection. I did extensive research into FPGA options; particularly the options provided by the 18-500 parts inventory. Based on factors like the included FPGA, large onboard memory, and support with AMD Vivado, I decided on the Ultra96-V2 as the best FPGA for our purpose, and I have finalized that decision by submitting the order form. Since we have a top candidate for the wireless transmitter, I also have done further research into the packet structure and have a preliminary plan. Some of the finer details such as bit endianness can change later on, but in general I have a plan for the components of the packet, given the 32 byte constraint of the transmitter.

 

Progress:

My progress is mostly on schedule, as my main focus for this week was researching the FPGA design tradeoffs and finalizing the FPGA selection as well as finalizing the packet format. Both are mostly completed (the packet format may change to adapt to technical challenges later on, but we have a plan for now). 

 

Deliverables: 

My task for the next week is to establish a data link from the radio module to the FPGA. The goal is just a simple data link to show that the flow of data is being recognized, without any complicated packet handling yet. I will need to work with Haowen on that part, as the wireless transmitter falls under her scope too. In doing so, I will also see some of the technical challenges we might face later on, which will help guide further research as well as help adjust the timeline if needed.

Posted on

Matthew Kwee – Status Report for 9/19

This week, I worked on the project proposal presentation slides with my teammates and began drafting the specifications for the web-app: historical data, the dashboard, and other insights. The web-app must be optimized for a mobile device (tablet/smartphone) since a swim coach can’t be expected to carry a PC while monitoring swimmers. Because the coach’s attention will be focused primarily on the team, the website’s UI should be simple to understand and use, allowing easy navigation and handling for minimal distraction.

In the coming week, I will be implementing the base web-app and determining the wearable device’s ideal dimensions. Our initial concept is a watch-like device that can be worn around the wrist – like all other aspects of this project, we want to design it such that its users can forget about it and focus on their primary goal: training. Additionally, I plan on researching and comparing the necessary components for the wearable with my team as we settle on a design for the prototypes.