separate cadence sensor pairing

[TClin76]

some smart trainers have no build-in cadence sensor.
Is it possible to add separated cadence sensor in system pairing page?
Thanks

[dvmarinoff]

Oh …, yes, that is right. I checked now and even the Wahoo Snap doesn’t have cadence. Will definitely add this then.

The thing is I’ll need to implement the bluetooth speed and cadence spec as well, but maybe a basic version will be possible in a couple of days. I’ll push a development version and notify you here. If you can help with testing it, this will speed time to production.

[TClin76]

Sure. I can test it. Thank you so much

[TClin76]

@dvmarinoff The cadence sensor display as below video.
https://user-images.githubusercontent.com/96434118/147675148-2074da49-99d8-4b3c-824d-e50a2f0441a2.mov

[dvmarinoff]

Hi @TClin76, just letting you know I pushed a new development version 0.1.2. Having some data logs from a real cadence sensor would really help me find the error. Here are some instructions if you can help with that. I haven't gotten yet to implementing a proper logger so the approach is a bit crude:

• open the development version of the app
• open up the browser developer console by pressing F12,
• connect a cadence sensor
• switch to cadence readings from the sensor by tap/click on the grey value (cadence --)
• cycle for like a minute, 40 to 60 seconds of data would do,
• disconnect the sensor
• select the contents of the developer console, and copy paste them into a text file
• drag and drop the text file in here

Here is an example of how it looks:

This is with my test data:

I don't have a dedicated cadence sensor, and I am using the cadence from a power meter service on my trainer, by spec it works the exact same way and your log should be more like this one, but connected to a proper cadence sensor:

And maybe you can drag select it, like this:

[TClin76]

Hi @dvmarinoff ,

Please find below log for your reference.
(I only connect cadence sensor)
It seems that it measures multiple duplicated CAD values within the same TIME.

cadence-sensor.txt

EDIT: allowed my self to edit the comment in order to put the log inside a file to make it easy for future readers.

[dvmarinoff]

Thanks, that helped a lot, now I might have an idea on how to solve this.

[dvmarinoff]

It turns out cadence sensors are implemented in slightly different ways. For example yours is repeating the the same message 3 times and below certain wattages its 4 times, while my trainer is often sending messages with just 1 ms difference. Main keeps the time event counter running all the time for cadence, but not speed, and yours updates time events only when revolutions update.
This makes catching the difference between coasting, stoping and simple update a bit tricky.

Just pushed a new version 0.1.22. Hope this one works for you.

[TClin76]

Thank you for the update version. However it still occasionally appears "0", but much less frequently. (refer to the video)

2021-12-31.4.04.03.mov

[dvmarinoff]

Thanks for the feedback!
One other idea I could try is to use a timestamp to filter the repeated messages. Also I'll try to source a physical cadence sensor from one of my friends. The thing is they are all travelling the country for the holidays, but for next week they should be back. Can you share the brand and model of yours?

[TClin76]

Magene GEMINI 200

[TClin76]

According to the log, can we simply make an assumption that if there is a continuous "0" received more than 4 times, then that is a real case of Cad=0? (As a temporary workaround)

[dvmarinoff]

Since the count starts from 0 and not 1 we have room for up to 4 repeated messages. The count will also reset after every legit update.
It validates with the data log. In the test data I replaced all of wrong 0 cadence values with the previous cadence value, so this:

{revs: 41768, time: 1673, cad: 92},
{revs: 41768, time: 1673, cad: 0},
{revs: 41769, time: 2347, cad: 91},
{revs: 41769, time: 2347, cad: 0},
{revs: 41769, time: 2347, cad: 0},

would become:

{revs: 41768, time: 1673, cad: 92},
{revs: 41768, time: 1673, cad: 92},
{revs: 41769, time: 2347, cad: 91},
{revs: 41769, time: 2347, cad: 91},
{revs: 41769, time: 2347, cad: 91},

Since there is a trade off between speed of updates especially time to show 0, and this repeated message filter, the plan is to keep the 4 counts for the general code, they should be enough, GoldenCheetah is using just 2 counts and instead try and detect the magene gemini sensor and put the counts at 10 or 12 max just for this device.

[dvmarinoff]

This test shows how the code is supposed to work when receiving a different count of the same message:

https://github.com/dvmarinoff/Flux/blob/321f60ec51e6d8f0d542e2c3a8686f376f91839a/test/ble/cscs.test.js#L184

And here is the test and data for the log that recreates the Magene Gemini sensor:

https://github.com/dvmarinoff/Flux/blob/321f60ec51e6d8f0d542e2c3a8686f376f91839a/test/ble/cscs.test.js#L369

The data log:
https://github.com/dvmarinoff/Flux/blob/321f60ec51e6d8f0d542e2c3a8686f376f91839a/test/ble/cscs.test.js#L486

[TClin76]

Understand! Thanks for sharing the detail information.

[TClin76]

I test Cadence with latest develop version.
For cad < 60, still randomly get "0"
For cad between 60~80, less chance to get "0"
For cad > 80, almost no "0"
It seems that the frequency of "0" displayed in cadence field is highly related to the cadence value itself.
The lower cadence value, the higher chance to see "0".

Does that mean the max counts should be dynamic adjusted? when cad is low, the max counts need to be higher?

[mjunkmyjunk]

This link - Flux/test/ble/cscs.test.js Is where I finally found your cadence code.

[dvmarinoff]

Just leaving a link to GoldenCheetah's implementation. Will examine their approach later.
https://github.com/GoldenCheetah/GoldenCheetah/blob/8aa6818f2d00c2603a78f21e99c4c0c7ae6b1627/src/Train/BT40Device.cpp#L864

[mjunkmyjunk]

this code for CrankStaleness is to determine if there are signal drop offs from the sensor.

[dvmarinoff]

Latest version 0.1.23 attempts to detect if the Cadence sensor is Magene Gemini and if so, it sets the max allowed repeated messages to 10 which has room for 11 messages, but the expected tradeoff is really slow time to show 0 when stop pedaling.

If it still doesn't work I'd have to ask for another log from the browser console and also the device name that is shown on the Settings page for connected Speed and Cadence sensor:

I have a meeting with my Running/Tri group tomorrow hope they are back already (from the long holidays) and somebody has a cadence sensor available.

[dvmarinoff]

Yes, this is true, cadence sensor implementations differ in behaviour, and this makes the task a bit tricky to achieve.

Here are a couple of logs from the trainer:
cadence-trainer-1.txt
cadence-trainer-2.txt

[TClin76]

Here is the log from Magene.
Flux_csc_log.txt
The maximum number of repeating events within same revolution in this log is 11. (r: 5504, t: 52757)
Another issue is that when the RPM is too low (< 40), the behaviors are not so consistent.
I also test in Zwift and Rouvy, and both APPs are also showing occasional "0 RPM" or "Not a Value" when RPM is under 40.
Besides, the latency for showing "0 RPM" after stop pedaling is around 3~4 seconds in Zwift, which is even longer than your app.
So I think we don't have to put too much effort on solving this problem when pairing with a Magene S&C sensor.

[dvmarinoff]

In theory cadence under 60 rpm will need over a full second to register one full revolution. At the same time the sensor is transmitting at about 300ms but tries to average 4 message per second. In the log the average difference between timestamps is 249ms, but there is a very regular pattern of 300 ms repeating i groups of 3, 4, 5, or 6 with an occasional 0 ms to average the rate at 4 per second.

Under low rpm this gets a little bit disrupted:

But in general the sensor is keeping good rhythm.

[TClin76]

It is clear now!
Just ignore the behavior for low RPMs.

Your trainer transmits in every 1008ms (avg.) and Magene in every 300ms.
That also explains why Magene needs max. count set to 10, but 3 in your trainer.

[dvmarinoff]

Went trough the bluetooth Cycling Speed and Cadence Service and Profile specifications and the only thing that mentions transmission rate is this:

Meaning 1 second is recommended but not required. Meanwhile the ANT+ corresponding specification defines 250 ms as the default rate (the way the Magine Gemini sensor transmits).

And also the bluetooth spec doesn't define a way to read the transmission rate from the Sensor.

So maybe a more general approach would be to measure the transmission rate in the first seconds after connection, take the average value and set the rate so that it allows at least 3 seconds room for measurement of a crank revolution, which by my calculations would cover cadence values down to 20 rpm, and below that it would start reading zeros.

[TClin76]

As I calculated before, I thought setting max counts to 10 can cover the cases for RPM > 24 in Magene's sensor.
However, there still exists occasional "0" when RPM is around 40.
So I examine the log again, and found a non-expected behavior, shown as follows,

[Revolution 5506]

measurement.js:257 {ts: 1641391440576, r: 5505, t: 54177, c: 43}
measurement.js:257 {ts: 1641391440876, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441176, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441477, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441777, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441777, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442076, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442376, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442677, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442976, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443276, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443277, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443577, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391443877, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444177, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444477, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444776, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444777, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445076, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445377, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445677, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445977, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445977, r: 5507, t: 57187, c: 40}

There are 20 repeating messages for the revolution 5506, and the timestamp difference is 5.1 sec.
Although long-term avg. transmission rate still keeps roughly 255ms (same as the beginning transmission rate after first connection), but among those messages, there are so many events with only d=0 or d=1. That makes our max counts not enough to cover all those messages.
Since short-term transmission rate is not quite stable, the message repeating counts may still have chance to exceed your max counts set by the 1 second measurement after connection.
So I am afraid that this method can not cover cadence value down to 20. It may still get "0" when above case happened.

Anyway, self-adjusting max counts setting is indeed a good idea.
With this method, it should work for the most cases with all other brands of CSC sensors.

[dvmarinoff]

At 42 rpm the crank needs about 1.4 seconds to make a full revolution, so in this case the crank did about 3.5 revolutions of which the sensor detected 1. I'll keep that case in mind, maybe I'll think of some sort of solution, but I am not sure if this can be improved.

Thanks for the data!

[mjunkmyjunk]

I viewed your code, from this
https://github.com/dvmarinoff/Flux/blob/69a119e22a048781fc6df49f6374bc0c9ea1b405/src/ble/cscs/measurement.js#L121

but perhaps this is no the correct link for the 0.1.2 version? I also checked on

https://github.com/dvmarinoff/Flux/blob/91c4b830b563a1d7d0ea3388c5792d1ef4f046ff/src/ble/common.js

but again, most likely I do not know how to properly decipher npm code. How are you handling the time rollover?

Cumulative Crank Revolution value will occasionally roll over (i.e. as frequently as every 12 hours if ridden at 80 rpm). As such, the Collector shall take into account that the Cumulative Crank Revolution value can roll over during a ride. See Section 4.7.2.1 for information on how to set this value.

This is my swift code to handle rollover and to get cadence.

  let cumCrankRev   = Int(byteArray[1])<<8 + Int(byteArray[0])
  let lastCrankTime = Int(byteArray[3])<<8 + Int(byteArray[2])

this is how I call it

getCadence(pCumCrankRev: cumCrankRev, pLastCrankTime: lastCrankTime, pPrevCumCrankRev: prevFECwCumCrankRev, pPrevCrankTime: prevFECwCrankTime ))

p = passed

  func getCadence( pCumCrankRev: Int, pLastCrankTime: Int, pPrevCumCrankRev: Int, pPrevCrankTime: Int ) -> Double {
    let cumCrankRev = pCumCrankRev
    let lastCrankTime = pLastCrankTime
    let prevCumCrankRev = pPrevCumCrankRev
    let prevCrankTime = pPrevCrankTime
    var rpm: Double = 0.0
    
    var deltaRotations = cumCrankRev - prevCumCrankRev
    if deltaRotations < 0 { deltaRotations += 65535 }
    
    var timeDelta = lastCrankTime - prevCrankTime
    if (timeDelta < 0) { timeDelta += 65535 }
    
    if (timeDelta != 0) {
      let timeMins =  Double(timeDelta) / 1024.0 / 60
      rpm = Double(deltaRotations) / timeMins
    }
    
//     print("getCad Cad:\(rpm) deltaRotations:\(deltaRotations)[\(cumCrankRev) - \(prevCumCrankRev)] timeD:\(timeDelta) [\(lastCrankTime) - \(prevCrankTime)] ")
    
    // During initial (re)connect, the RPM is inflated due to prolonged timeDelta (due to Rollover at 65535)
    return rpm > 200 ? 0 : rpm
  }

[dvmarinoff]

Thanks for sharing your code! I was looking all over GitHub for alternative solutions.
I am not super sure what is happening in the lines:

if deltaRotations < 0 { deltaRotations += 65535 }
if (timeDelta < 0) { timeDelta += 65535 }

The 65535 leads me to think it is a roll over thing maybe?

Else I am calculating speed and cadence in the State function module (something similar to a Struct in Swift) located in common.js:
https://github.com/dvmarinoff/Flux/blob/69a119e22a048781fc6df49f6374bc0c9ea1b405/src/ble/common.js#L37

Since the general algorithm for speed and cadence is the same, it is abstracted in this State module. By configuring the transform() function you can get out of it cadence or speed, or any other similar value that is stateful. The main steps of the algorithm are in defaultCalculate() here: https://github.com/dvmarinoff/Flux/blob/69a119e22a048781fc6df49f6374bc0c9ea1b405/src/ble/common.js#L155

It takes care of rollovers for comulative time and events in rollOverTime() and rollOverEvents(). The staleness counter from Golden Cheetah is also present, by the name rateCount and is capped by maxRateCount which means the max allowed consecutive messages with the same value before concluding that the sensor is actually sending zero rpm and not just struggling to detect them. For example the combination of high transmission rate and low cadence may result in unwanted 0 readings and they need to be filtered out.

[mjunkmyjunk]

ah.... your maxRevs: 2**16, is the 65535 rollover

if deltaRotations < 0 { deltaRotations += 65535 }
if (timeDelta < 0) { timeDelta += 65535 }

these 2 lines handles the rollover.

 var deltaRotations = cumCrankRev - prevCumCrankRev

It handles situations where the deltaRotations from above equation becomes < 0.

I too handle the staleness (but in a separate code from that function. So it seems that you're handling all the things.

[dvmarinoff]

Well except for the big differences in transmission rate between devices. My trainer sends messages about 1 second on average, while some speed and cadence sensors send them every 250ms on average, which results in the trainer at 1s needing 4 times lower staleness value than the sensor at 250ms.

I am thinking something in the lines of a self adjusting staleness value based on the current transmission rate, as calculated from timestamped last 30 or 60 messages, might help.

[mjunkmyjunk]

My test on implementing CSC was basically using a Wahoo RPM so a staleness of like 2 was adequate for me.
Just recently I found my Magene Gemini 100 which I thought I lost so I might play around w/ that just to take a look at the interval.

[dvmarinoff]

Thanks, that would be valuable!

[dvmarinoff]

First version of the self adjusting max rate count (staleness counter) is available on development version 0.1.24.
It collects the first 20 messages, gets the average time difference between them and from there it set the max counter, so that 1 message per second would result in value of 2 (3 counts), and 4 messages per second in value of 11 (12 counts). And the console log will look like this:

[mjunkmyjunk]

sorry for the late reply.. Just found my Magene Gemini 200 after digging around for something else.
I tried to collect the data for you but seems like the development branch you're using for this is no longer logging the timestamp and the relevant messages for R and T.

However, It does seems like the new code works, I don't see dropouts on the Web-App.
the console also shows a max rate of 10 and 285ms timeStamp avg difference.

However, In my own testing, seems like the data that's coming out from the sensor is much difference from this of this post #82 (comment)

[Revolution 5506]

measurement.js:257 {ts: 1641391440576, r: 5505, t: 54177, c: 43}
measurement.js:257 {ts: 1641391440876, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441176, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441477, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441777, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391441777, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442076, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442376, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442677, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391442976, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443276, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443277, r: 5506, t: 55641, c: 42}
measurement.js:257 {ts: 1641391443577, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391443877, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444177, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444477, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444776, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391444777, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445076, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445377, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445677, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445977, r: 5506, t: 55641, c: 0}
measurement.js:257 {ts: 1641391445977, r: 5507, t: 57187, c: 40}

Here you see it's c:42 (is that raw data from the sensor or the resultant cad after accounting for max rate?)
in my case, I see something like this

{ts: 1641391445076, r: 5506, t: 55641, c: 100}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}
{ts: 1641391445076, r: 5506, t: 55641, c: 0}

where only the 1st data would have a cadence and the other messages would be 0

[dvmarinoff]

c: 42 is the calculated cadence from revolutions and time. The sensor is sending a lot of messages with the same timestamp, same revolutions and time. This results in a 0, but the staleness param should fix that for the UI, unless cadence is really low like below 30-20 rpm it will start to break and show a parasitic 0.