updates some references and some dependencies

Author: laberning

docs/README.md

@@ -1,7 +1,7 @@
 # Open Rowing Monitor
 
 <!-- markdownlint-disable-next-line no-inline-html -->
-<img width="200" height="200" align="left" src="./img/openrowingmonitor_icon.png" class="dropcap">
+<img width="200" height="200" align="left" src="img/openrowingmonitor_icon.png" class="dropcap">
 
 A free and open source performance monitor for rowing machines. It upgrades a rowing machine into a smart trainer that can be used with training applications and games.
 
@@ -12,7 +12,7 @@ We suspect it works well with DIY rowing machines like the [Openergo](https://op
 
 ## Features
 
-The following items describe most of the current features, more functionality will be added in the future, check the [Development Roadmap](./backlog.md) if you are curious.
+The following items describe most of the current features, more functionality will be added in the future, check the [Development Roadmap](backlog.md) if you are curious.
 
 ### Rowing Metrics
 
@@ -33,7 +33,7 @@ The web interface visualizes the rowing metrics on any device that can run a web
 If you connect a screen to the Raspberry Pi, then this interface can also be directly shown on the device. The installation script can set up a web browser in kiosk mode that runs on the Raspberry Pi.
 
 <!-- markdownlint-disable-next-line no-inline-html -->
-<img src="./img/openrowingmonitor_frontend.png" width="700"><br clear="left">
+<img src="img/openrowingmonitor_frontend.png" width="700"><br clear="left">
 
 ### Bluetooth Low Energy (BLE)
 
@@ -63,7 +63,7 @@ You will need a Raspberry Pi Zero W, Raspberry Pi Zero 2 W, Raspberry Pi 3 or a
 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/laberning/openrowingmonitor/HEAD/install/install.sh)"
 ```
 
-Also have a look at the [Detailed Installation Instructions](./installation.md) for more information on the software installation and for instructions on how to connect the rowing machine.
+Also have a look at the [Detailed Installation Instructions](installation.md) for more information on the software installation and for instructions on how to connect the rowing machine.
 
 ## How it all started
 
@@ -77,8 +77,8 @@ This project is already in a very usable stage, but some things are still a bit
 
 Feel free to leave a message in the [GitHub Discussions](https://github.com/laberning/openrowingmonitor/discussions) if you have any questions or ideas related to this project.
 
-Check the advanced information on the [Physics behind Open Rowing Monitor](./physics_openrowingmonitor.md).
+Check the advanced information on the [Physics behind Open Rowing Monitor](physics_openrowingmonitor.md).
 
-We plan to add more features, here is the [Development Roadmap](./backlog.md).
+We plan to add more features, here is the [Development Roadmap](backlog.md).
 
-This project uses some great work by others, see the [Attribution here](./attribution.md).
+This project uses some great work by others, see the [Attribution here](attribution.md).

docs/backlog.md

@@ -6,7 +6,6 @@ This is the very minimalistic Backlog for further development of this project.
 
 * validate FTMS with more training applications and harden implementation (i.e. Holofit and Coxswain)
 * add an option to select the damper setting in the Web UI
-* clean up of documentation
 * add some more test cases to the rowing engine
 
 ## Later

docs/hardware_setup_WRX700.md

@@ -21,4 +21,7 @@ How to connect this to your rowing machine is specific to your device. You need
 ![Connecting the reed sensor](img/raspberrypi_reedsensor_wiring.jpg)
 *Connecting the reed sensor*
 
-You should now adjust the rower specific parameters in `config/config.js` to suit your rowing machine. Have a look at [config/default.config.js](../config/default.config.js) to see what config parameters are available.
+## Rower Settings
+
+You should now adjust the rower specific parameters in `config/config.js` to suit your rowing machine. Have a look at `config/default.config.js` to see what config parameters are available.
+Also check the [Guide for rower specific settings](rower_settings.md).

docs/installation.md

@@ -94,5 +94,5 @@ If your machine isn't listed and does not have something like this or if the sen
 
 ## Rower Settings
 
-You should now adjust the rower specific parameters in `config/config.js` to suit your rowing machine. Have a look at [config/default.config.js](../config/default.config.js) to see what config parameters are available.
+You should now adjust the rower specific parameters in `config/config.js` to suit your rowing machine. Have a look at `config/default.config.js` to see what config parameters are available.
 Also check the [Guide for rower specific settings](rower_settings.md).

docs/physics_openrowingmonitor.md

@@ -63,14 +63,14 @@ Here, we plot the *currentDt* (time between impulses) against its sequence numbe
 
 * The **Recovery Phase**, where the rower returns to his starting position
 
-As the rowing cycle always follows this fixed schema, Open Rowing Monitor models it as a finite state machine (implemented in [RowingEngine's handleRotationImpulse](https://github.com/laberning/openrowingmonitor/blob/main/app/engine/RowingEngine.js)):
+As the rowing cycle always follows this fixed schema, Open Rowing Monitor models it as a finite state machine (implemented in `handleRotationImpulse` in `engine/RowingEngine.js`).
 
 ![Finite state machine of rowing cycle](img/physics/finitestatemachine.png)
 *Finite state machine of rowing cycle*
 
 ### Basic stroke detection
 
-Given that the *Angular Displacement* between impulses is fixed, we can deduct some things simply from looking at the subsequent *time between impulses*, *currentDt*. When the *currentDt* shortens, *Angular Velocity* is increasing, and thus the flywheel is accelerating (i.e. we are in the drive phase of the rowing cycle). When times between subsequent impulses become longer, the *Angular Velocity* is decreasing and thus the flywheel is decelerating (i.e. we are the recovery phase of the rowing cycle). This is the robust implementation of a stroke (implemented in [MovingFlankDetector's implementation of isFlywheelPowered and isFlywheelUnpowered for naturalDeceleration = 0](https://github.com/laberning/openrowingmonitor/blob/main/app/engine/MovingFlankDetector.js)), which is similar to the implementation used by industry leaders like Concept2. Concept2 are generally considered the golden standard when it comes to metrics, and they state (see [this Concept2 FAQ](https://www.concept2.com/service/software/ergdata/faqs): 'Drive time is measured by the amount of time the flywheel is accelerating. Note: It is possible that the athlete may pull on the handle and not accelerate the flywheel due to no energy being put into it and therefore no effective effort. This portion of the handle pull is not measured.')
+Given that the *Angular Displacement* between impulses is fixed, we can deduct some things simply from looking at the subsequent *time between impulses*, *currentDt*. When the *currentDt* shortens, *Angular Velocity* is increasing, and thus the flywheel is accelerating (i.e. we are in the drive phase of the rowing cycle). When times between subsequent impulses become longer, the *Angular Velocity* is decreasing and thus the flywheel is decelerating (i.e. we are the recovery phase of the rowing cycle). This is the robust implementation of a stroke (implemented in MovingFlankDetector's implementation of isFlywheelPowered and isFlywheelUnpowered for naturalDeceleration = 0 in `engine/MovingFlankDetector.js`), which is similar to the implementation used by industry leaders like Concept2. Concept2 are generally considered the golden standard when it comes to metrics, and they state (see [this Concept2 FAQ](https://www.concept2.com/service/software/ergdata/faqs): 'Drive time is measured by the amount of time the flywheel is accelerating. Note: It is possible that the athlete may pull on the handle and not accelerate the flywheel due to no energy being put into it and therefore no effective effort. This portion of the handle pull is not measured.')
 
 ### Advanced stroke detection
 
@@ -83,7 +83,7 @@ In this graph, we plot *currentDt* against the time in the stroke, averaged over
 
 However, from the acceleration/deceleration curve it is also clear that despite the deceleration, there is still a force present: the deceleration-curve hasn't reached its stable minimum despite crossing 0. This is due to the pull still continuing through the arms: the net force is negative due to a part drive-phase (the arm-movement) delivering weaker forces than the drag-forces of the flywheel. Despite being weaker than the other forces on the flywheel, the rower is still working. In this specific example, at around 0.52 sec the rower's force was weaker than all drag-forces combined. However, only at 0,67 seconds (thus approx. 150 ms later) the net force reaches its stable bottom: the only force present is the drag from the flywheel. Getting closer to this moment is a goal.
 
-By specifying the expected natural deceleration of the flywheel (naturalDeceleration, which in this case is around 8 Rad/S^2) in the configuration of the rower, the stroke starts earlier and ends later (implemented in [MovingFlankDetector's implementation of isFlywheelPowered and isFlywheelUnpowered for naturalDeceleration < 0](../app/engine/MovingFlankDetector.js)). Please note: as several derived metrics depend on the length of the drive phase or the exact timing of that moment (like the drag factor when calculated dynamically), these are likely to change when this setting is changed. For a more in-depth explanation, see [here for more details](physics_openrowingmonitor.md#a-closer-look-at-the-effects-of-the-various-drive-and-recovery-phase-detection).
+By specifying the expected natural deceleration of the flywheel (naturalDeceleration, which in this case is around 8 Rad/S^2) in the configuration of the rower, the stroke starts earlier and ends later (implemented in MovingFlankDetector's implementation of isFlywheelPowered and isFlywheelUnpowered for naturalDeceleration < 0 in `engine/MovingFlankDetector.js`). Please note: as several derived metrics depend on the length of the drive phase or the exact timing of that moment (like the drag factor when calculated dynamically), these are likely to change when this setting is changed. For a more in-depth explanation, see [here for more details](physics_openrowingmonitor.md#a-closer-look-at-the-effects-of-the-various-drive-and-recovery-phase-detection).
 
 Testing shows that setting a value close to the natural deceleration provides more accurate results very reliably. However, some rowers might contain a lot of noise in their data, making this approach infeasible (hence the fallback option of naturalDeceleration = 0)
 
@@ -227,7 +227,7 @@ There are some additional options for the frequency of metric calculations:
 
 * To allow for a very frequent update of the monitor, and allow for testing for typical end-criteria for trainings that change quite quickly (i.e. absolute distance, elapsed time), we calculate these for each new *currentDt*;
 
-* As we can only calculate the drag factor at the end of the recovery phase, we can only (retrospectively) apply it to the realized linear distance of that same recovery phase. Therefore, we we need to report absolute time and distance from the [RowingEngine](../app/engine/RowingEngine.js));
+* As we can only calculate the drag factor at the end of the recovery phase, we can only (retrospectively) apply it to the realized linear distance of that same recovery phase. Therefore, we we need to report absolute time and distance from the `RowingEngine` in `engine/RowingEngine.js`);
 
 ## A closer look at the effects of the various Drive and Recovery phase detection