Haowen’s Weekly Status Report for Week 7

Accomplishments

This week, I focused on setting up the development environment and checking the ANT-B10. I installed the nRF Connect SDK (v2.6+) and the required toolchain dependencies. I also spent time fixing local path and driver issues to get the environment working properly.

After receiving the u-blox ANT-B10 antenna array, I checked the board for any visible damage and powered it on through USB to make sure it was working. I also reviewed the datasheet to locate the SWD and UART pins for future connections. Finally, I ran basic checks to confirm that the development tools could compile and flash test programs successfully. I spent around 12 hours on SDK setup, troubleshooting, reading documentation, and initial hardware checks.

Schedule Status

On schedule. Since the material hasn’t arrived yet, this week was mainly spent getting the development environment ready and checking the board. This should make it easier to move on to wiring and communication tests next week.

Next Week’s Deliverables

  1. Connect the external SWD programmer and USB-to-TTL adapter to the ANT-B10 board and check whether it produces stable serial output.
  2. Establish UART communication at 115200 baud and test basic AT commands to confirm that the ANT-B10 responds correctly.
  3. Set up the nRF-based tag to broadcast BLE packets at 20 Hz with Constant Tone Extension (CTE).
  4. Configure the ANT-B10 to scan for and receive CTE packets from the tag.

Haowen’s Weekly Status Report for Week 6

Accomplishment

Focused on getting our basic development environment set up and making sure the physical boards work. Installed VS Code, nRF Connect SDK (v2.6+), and toolchain dependencies, spending a good chunk of time troubleshooting local path issues and drivers. Unboxed the u-blox ANT-B10 antenna array and RPi Pico WH, checked the boards for any physical defects, and powered them up via USB to confirm power LEDs were solid. Cross-referenced the ANT-B10 datasheet to identify the SWD and UART pin headers for future wiring. Ended the week by running a basic LED blink / Hello World sanity check on the boards to ensure neither came dead-on-arrival (DOA) and our local toolchains can compile binaries properly. Spent around 12 hours total across SDK setup, troubleshooting environment paths, reading datasheets, and initial board verification.

Schedule Status

On schedule. Materials arrived mid-week, so keeping this week focused on environment setup and basic check sets us up smoothly without rushing into complex wiring.

Next week’s deliverables

  1. Wire up the external SWD programmer and USB-TTL adapter to the ANT-B10 bare board and confirm stable serial log output.

  2. Set up the RPi Pico WH to broadcast 20 Hz BLE packets with CTE (Constant Tone Extension).

  3. Flash the Nordic direction_finding RX sample to the ANT-B10 and check for raw angle output over UART.

Team Status Report for Week 5

Executive Summary

This week, we locked down our hardware choices, set up the web dashboard UI, and validated our BLE 5.1 Angle of Arrival (AoA) pipeline. Offloading RF processing to Nordic silicon avoids complex FPGA timing work. Next week, we’ll focus on assembling the wearable prototype to collect real telemetry data.

Key Progress

  • Signal (Haowen): Confirmed the nRF5340 Network Core handles BLE CTE sampling in hardware, outputting clean angle scalars over UART (115200 baud). Designed a 2-stage filter (Median + Moving Average) to handle water surface multipath. Unboxed the nRF5340-DK, ANT-B10, and Pico WH, and prepped the nRF SDK in VS Code.
  • Software (Matthew): Set up the web app repo and built a poolside-friendly UI featuring an Outdoor High-Contrast mode, a 2-second touch-lock screen, and Wake-Lock API integration. Added a stream-level Jitter Buffer for out-of-order packets and built a 3-tap tag pairing menu.
  • Hardware (Jeffrey): Established a two-phase wearable strategy (off-the-shelf prototype -> custom PCB). Selected Raspberry Pi Pico + Pimoroni MCP73831 for the prototype and XIAO RP2040 Plus + LiFePO4 battery for the final PCB. Created architecture diagrams for the design review.

Risks & Mitigations

  • Shipping & Power Supply Delays: FPGA power supply is delayed -> Mitigated by using off-the-shelf Pico WH and nRF5340-DK boards to assemble the wearable prototype first.
  • Water Surface Reflections: Splashes cause signal jitter -> Mitigated via Median filtering on compute and a Jitter Buffer on the web app.

Considerations

Part A was written by Jeffrey Liu:

We don’t expect our product to have too much of a direct impact on public health, safety, and welfare. One could make the argument that since exercise is good for health, by making a device that improves the swimming experience and improves coaches’ ability to train swimmers, that there will be a broad benefit to public health by encouraging more people to exercise and stay healthy. Swimming is also an important survival skill in certain areas, so encouraging swimming may help public health in that regard. With regards to safety, our main concern with our project is that there is no safety hazard to the users. In our case, the primary safety consideration would be that the wearable device needs to have a battery. With that in mind, our battery choice of a LiFePo battery is among the safest lithium-ion battery chemistries that is available and we will keep battery safety in mind when designing the surround circuitry. Additionally, the material we will make sure is skin-safe in water, as it will be worn for prolonged times. Our project is probably least applicable to welfare, as swimming training/guidance is not a basic provision that people need to survive.

Part B is written by Matthew Kwee:

Our platform addresses technological and socioeconomic disparities across competitive swimming. Swimming has a well-documented resource divide: elite collegiate programs and affluent private clubs can afford multi-thousand-dollar camera rigs, underwater timing gates, and dedicated biomechanics staff, while municipal clubs and public high schools rely solely on hand-held stopwatches and visual estimates. By delivering accessible, low-cost tracking, our project democratizes sports analytics. This lowers the barrier to data-driven coaching for underfunded teams, fostering greater competitive equity across different socioeconomic communities.

Our system also meaningfully alters coach-athlete dynamics. In a typical practice with 20 to 30 swimmers circling in crowded lanes, a coach can realistically only focus their stopwatch and feedback on one or two athletes at a time. This naturally leads to unintentional disparities in attention and may result in perceived bias. By providing simultaneous, automated metrics across all lanes, coaches can distribute attention and constructive feedback much more equitably, building a fairer and more supportive team training environment.

We must also consider the social and psychological impact of continuous performance surveillance on young athletes. In high-pressure sports environments, constant metric tracking and public leaderboards can sometimes foster unhealthy peer comparison, burnout, or anxiety. To protect team culture and swimmer well-being, we will design the software around configurable privacy controls. Coaches can decide whether performance data is shared openly on a team board to foster healthy camaraderie, or kept private between the individual swimmer and the coaches to focus purely on personal development.

Part C is written by Haowen Huang:

For our project, economic considerations directly shaped our choice of hardware, aiming to deliver high-precision tracking without the prohibitive price tag of existing solutions. By using commercial off-the-shelf components (Nordic nRF5340, u-blox ANT-B10 array, and Raspberry Pi Pico), we avoided the heavy development and production costs of custom ASICs or sub-nanosecond FPGA hardware. This keeps both our prototyping expenses and eventual unit manufacturing costs low. Our system also fills a major cost gap in sports analytics. Existing swimmer-tracking tech usually relies on optical camera rigs or underwater timing systems that cost thousands of dollars, putting them out of reach for most high school programs or local swim clubs. Using BLE 5.1/5.2 Angle of Arrival lets us deliver real-time spatial data at a fraction of the hardware cost, making data-driven coaching accessible to smaller teams with tighter budgets. Finally, long-term maintenance costs are kept low through a modular design. The wearable tag uses an energy-efficient microcontroller and a rechargeable battery to extend hardware lifespan. Because individual tags are cheap and easy to swap out, a damaged or depleted tag can be replaced on the spot without replacing or reconfiguring the poolside base station.

Next Week’s Goals

  1. Signal (Haowen): Flash the nRF5340 SDK Rx sample, verify raw angle output over UART, and wire it to the Pico WH.
  2. Software (Matthew): Pause web development temporarily to assist Jeffrey with physical wearable assembly and data logging setup.
  3. Hardware (Jeffrey): Place orders for verified prototype/PCB parts and assemble the initial wearable prototype once parts arrive.

Haowen’s Weekly Status Report (Week 5)

Executive Summary

This week, I conducted in-depth feasibility research on our BLE 5.1/5.2 Angle of Arrival (AoA) tracking pipeline, clarified the system data flow across team roles, and validated the hardware stack integration plan for our incoming components.

By offloading raw microwave-frequency switching and phase demodulation directly to dedicated silicon, we confirmed a low-complexity architecture that avoids sub-nanosecond FPGA timing constraints while delivering reliable angle metrics.

Key Accomplishments This Week

1. Architecture Research & Technical Feasibility

  • Silicon-Level AoA Offloading: Researched the Nordic nRF5340 + u-blox ANT-B10 hardware pipeline. Confirmed that the nRF5340 Network Core executes CTE (Constant Tone Extension) I/Q sampling natively in silicon via Nordic’s direction_finding_connectionless_rx SDK module, outputting processed scalar angles over UART rather than raw high-frequency RF vectors.
  • Comparative Trade-off Analysis: Evaluated alternative approaches (e.g., direct FPGA RF sampling and UWB). Concluded that 2.4 GHz BLE AoA using our off-the-shelf kit provides the optimal balance of power, cost, and reduced timing complexity for a water/poolside environment.

2. System Data Flow & Team Alignment

  • Wearable vs. Base Station Setup: Clarified the hardware topology across Signal, Hardware, and Software sub-teams:
    • Wearable Tag (Swimmer): A lightweight transmitter (Pico + BLE radio emitting standard CTE frames) with no heavy compute overhead.
    • Base Station (Poolside): Fixed u-blox ANT-B10 8-antenna array connected to the nRF5340-DK, streaming angle scalars over a 3-wire hardware UART link (TX, RX, GND) at 115200 baud to the processing core.
  • Multipath Noise Strategy: Designed a two-stage embedded filtering pipeline (Median Filter for splash outlier removal + Moving Average for trajectory smoothing) to mitigate surface water reflections.

3. Development Setup Preparation

  • Unboxed arriving hardware components (nRF5340-DK, u-blox ANT-B10, Pico WH) and prepped the nRF Connect SDK environment for VS Code.

Next Week’s Goals (Planned Tasks)

  1. Hardware Benchmarking & “Hello World” Test: Assemble the ANT-B10 board onto the nRF5340-DK, flash the official SDK sample code, and verify raw Azimuth/Elevation scalar outputs via a serial terminal during walking tests.
  2. UART Pipeline Integration: Wire the nRF5340-DK to the Pico WH over hardware UART and establish basic packet receiving logic.
  3. Draft UART Packet Protocol: Define the binary/JSON payload structure for streaming filtered coordinates downstream to the Software team’s dashboard.

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