adds a constant metric stream for BLE devices to fix some connectivity issues
This commit is contained in:
parent
2210c46162
commit
2ccd54a65d
|
|
@ -13,7 +13,7 @@ const log = loglevel.getLogger('RowingEngine')
|
|||
|
||||
function createRowingStatistics (config) {
|
||||
const numOfDataPointsForAveraging = config.numOfPhasesForAveragingScreenData
|
||||
const screenUpdateInterval = config.screenUpdateInterval
|
||||
const webUpdateInterval = config.webUpdateInterval
|
||||
const minimumStrokeTime = config.rowerSettings.minimumRecoveryTime + config.rowerSettings.minimumDriveTime
|
||||
const maximumStrokeTime = config.maximumStrokeTime
|
||||
const timeBetweenStrokesBeforePause = maximumStrokeTime * 1000
|
||||
|
|
@ -38,18 +38,26 @@ function createRowingStatistics (config) {
|
|||
let lastStrokeDistance = 0.0
|
||||
let lastStrokeSpeed = 0.0
|
||||
let lastStrokeState = 'RECOVERY'
|
||||
let lastMetrics = {}
|
||||
let lastWebMetrics = {}
|
||||
|
||||
// send metrics to the clients periodically, if the data has changed
|
||||
setInterval(emitMetrics, screenUpdateInterval)
|
||||
function emitMetrics () {
|
||||
const currentMetrics = getMetrics()
|
||||
if (Object.entries(currentMetrics).toString() !== Object.entries(lastMetrics).toString()) {
|
||||
emitter.emit('metricsUpdate', currentMetrics)
|
||||
lastMetrics = currentMetrics
|
||||
// send metrics to the web clients periodically (but only if the data has changed)
|
||||
setInterval(emitWebMetrics, webUpdateInterval)
|
||||
function emitWebMetrics () {
|
||||
const currentWebMetrics = getMetrics()
|
||||
if (Object.entries(currentWebMetrics).toString() !== Object.entries(lastWebMetrics).toString()) {
|
||||
emitter.emit('webMetricsUpdate', currentWebMetrics)
|
||||
lastWebMetrics = currentWebMetrics
|
||||
}
|
||||
}
|
||||
|
||||
// notify bluetooth peripherall each second (even if data did not change)
|
||||
// todo: the FTMS protocol also supports that peripherals deliver a preferred update interval
|
||||
// we could respect this and set the update rate accordingly
|
||||
setInterval(emitPeripheralMetrics, 1000)
|
||||
function emitPeripheralMetrics () {
|
||||
emitter.emit('peripheralMetricsUpdate', getMetrics())
|
||||
}
|
||||
|
||||
function handleDriveEnd (stroke) {
|
||||
// if we do not get a drive for timeBetweenStrokesBeforePause milliseconds we treat this as a rowing pause
|
||||
if (rowingPausedTimer)clearInterval(rowingPausedTimer)
|
||||
|
|
|
|||
|
|
@ -95,8 +95,11 @@ rowingStatistics.on('recoveryFinished', (metrics) => {
|
|||
}
|
||||
})
|
||||
|
||||
rowingStatistics.on('metricsUpdate', (metrics) => {
|
||||
rowingStatistics.on('webMetricsUpdate', (metrics) => {
|
||||
webServer.notifyClients(metrics)
|
||||
})
|
||||
|
||||
rowingStatistics.on('peripheralMetricsUpdate', (metrics) => {
|
||||
peripheralManager.notifyMetrics('metricsUpdate', metrics)
|
||||
})
|
||||
|
||||
|
|
|
|||
|
|
@ -66,11 +66,11 @@ export default {
|
|||
// Most bike training applications are fine with any device name
|
||||
ftmsBikePeripheralName: 'OpenRowingBike',
|
||||
|
||||
// The interval for updating all your screens (i.e. the monitor, but also bluetooth devices) in ms.
|
||||
// The interval for updating all web clients (i.e. the monitor) in ms.
|
||||
// Advised is to update at least once per second, to make sure the timer moves nice and smoothly.
|
||||
// Around 100 ms results in a very smooth experience that the distance display also updates smoothly
|
||||
// Please note that using a 100ms or less will result in more work for your Raspberry Pi
|
||||
screenUpdateInterval: 1000,
|
||||
// Around 100 ms results in a very smooth update experience
|
||||
// Please note that a smaller value will use more network and cpu ressources
|
||||
webUpdateInterval: 1000,
|
||||
|
||||
// The number of stroke phases (i.e. Drive or Recovery) used to smoothen the data displayed on your
|
||||
// screens (i.e. the monitor, but also bluetooth devices, etc.). A nice smooth experience is found at 6
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Some people want it all, and we're happy to give to you when your rower and your
|
|||
|
||||
* **maximumImpulseTimeBeforePause** determines the maximum time between impulses before the rowing engine considers it a pause.
|
||||
* **magicConstant** is a constant that is commonly used to convert flywheel revolutions to a rowed distance and speed (see [the physics of ergometers](http://eodg.atm.ox.ac.uk/user/dudhia/rowing/physics/ergometer.html#section9)). Concept2 seems to use 2.8, which they admit is an arbitrary number which came close to their expectations of a competetion boat. As this setting only affects speed/distance, this setting typically is used to change the power needed to row a certain distance or reach a certain speed. So changing this can make your rower's metrics act as sluggish as an oil tanker (much power needed for little speed), or more like a smooth eight (less power needed for more speed). So for your rower, you could set your own plausible distance for the effort you put in. Please note that the rowed distance also depends on **flywheelInertia**, so please calibrate that before changing this constant. Another note: increasing this number decreases your rowed meters, but not in a linear fashion.
|
||||
* **screenUpdateInterval**: normally set at 1000 milliseconds, but for a more smoother experience on your monitor you can go as low as 100 ms. This makes the transition of the distance and time quite smooth, but at the price of some more CPU-load.
|
||||
* **webUpdateInterval**: normally set at 1000 milliseconds, but for a more smoother experience on your monitor you can go as low as 100 ms. This makes the transition of the distance and time quite smooth, but at the price of some more network and CPU-load.
|
||||
* **numOfPhasesForAveragingScreenData**: we average the data from several stroke phases to prevent the monitor and Bluetooth devices to become fidgety. Typically, we set this value to 6, which means 3 strokes (there are two phases in each stroke). However, some Bluetooth devices do their own calculations. And sometimes you really want the feedback on your individual strokes without any punches hold back. Setting this to 1 will result in a very volatile, but direct feedback mechanism on your stroke.
|
||||
* **dampingConstantSmoothing** determines the smoothing of the dragfactor across strokes (if autoAdjustDragFactor is set to true). Normally set at 5 strokes, which prevents wild values to throw off all your measurements. If you have rower that produces very little noise in the data, then it could be an option to reduce. If your machine produces noisy data, this is the one to increase before anything else.
|
||||
* **dampingConstantMaxChange** determines the maximum change between a currently determined dragfactor and the current average of the previous dampingConstantSmoothing strokes (if autoAdjustDragFactor is set to true). This filter reduces spikes in the calculation and thus makes the dragfactor less responsive to changes. The default value of 0.10 implies that the maximum upward/downward change is an increase of the drag with 10%. Please note that this filter still allows changes, it just limits their impact to this percentage. Most rower's dragfactor is relatively constant, however certain hyrid rower's dragfactor changes when the speed changes. To allow for bigger changes within a stroke, increase this setting. When the expected changes are small, set this setting small. When your rower is a hybrid or when you have one configuration for all your damper settings, this should be a bit wider.
|
||||
|
|
|
|||
Loading…
Reference in New Issue