Description:
Currently when the athlete goes to the record run page, after selecting athlete and event for new run they are taken to the timer page with the Start button on it. When start button is pressed this is when BLE connection starts, then as soon as the connection starts, the timer starts. This is incorrect as it would mean a runner would have to start running as soon as the connection starts.
Instead the connection should begin as soon as the user is navigated to the Page with the timer, but not before they have pressed start. The start button should not be able to be pressed until the device is connected.
Include a connected status, and a tooltip with info that losing connection is expected and the runner just must come back into range to reconnect.
This means that we will not only have the truncate the end of the state, but additionally the beginning of the data as well.
Once a run is stop and then saved, redirect to that runs visualization page. Make sure that the run list page is updated with the run as soon as it is saved.
Test full workflow with mock_ble_client.
Tasks:
- frontend/src/hooks/useBle.hooks.ts — The buffer accumulates from connection onwards. Add a way
to mark where the run actually started so only post-start rows are used when saving. The existing
bleDataBuffer() and bleClearBuffer() are the relevant functions.
- frontend/src/pages/RecordRunPage.tsx — Several changes:
- BLE connection should kick off when the recording screen appears, not inside startTimer().
Consider the cleanup path too — "Change Event" currently just calls setScreen("setup") without
disconnecting.
- The Start button (disabled={isConnecting || bleIsScanning}) needs to also account for whether
the device is actually connected.
- The BLE status indicator currently only renders while isRunning. It should be visible as soon
as the recording screen is shown, in all states (connecting, connected, disconnected). The tooltip
should explain that mid-run disconnection is expected and the sensor will reconnect automatically
when back in range.
- startTimer() should mark the start position in the buffer instead of initiating the BLE
connection.
- After a successful save, the response from POST /csv/upload-run includes a run_id. Use it to
navigate to /athletes/:athleteId/runs/:runId (see App.tsx line 35) instead of resetting to the
setup screen. The queryClient.invalidateQueries call for ["runs"] is already there and handles the
list refresh.
Deliverables:
Full BLE connection demonstration during meeting
Description:
Currently when the athlete goes to the record run page, after selecting athlete and event for new run they are taken to the timer page with the Start button on it. When start button is pressed this is when BLE connection starts, then as soon as the connection starts, the timer starts. This is incorrect as it would mean a runner would have to start running as soon as the connection starts.
Instead the connection should begin as soon as the user is navigated to the Page with the timer, but not before they have pressed start. The start button should not be able to be pressed until the device is connected.
Include a connected status, and a tooltip with info that losing connection is expected and the runner just must come back into range to reconnect.
This means that we will not only have the truncate the end of the state, but additionally the beginning of the data as well.
Once a run is stop and then saved, redirect to that runs visualization page. Make sure that the run list page is updated with the run as soon as it is saved.
Test full workflow with mock_ble_client.
Tasks:
to mark where the run actually started so only post-start rows are used when saving. The existing
bleDataBuffer() and bleClearBuffer() are the relevant functions.
Consider the cleanup path too — "Change Event" currently just calls setScreen("setup") without
disconnecting.
the device is actually connected.
as the recording screen is shown, in all states (connecting, connected, disconnected). The tooltip
should explain that mid-run disconnection is expected and the sensor will reconnect automatically
when back in range.
connection.
navigate to /athletes/:athleteId/runs/:runId (see App.tsx line 35) instead of resetting to the
setup screen. The queryClient.invalidateQueries call for ["runs"] is already there and handles the
list refresh.
Deliverables:
Full BLE connection demonstration during meeting