How to get wheel rpm or circumference from speed sensor?

The head unit calculates the circumference using GPS.

flowstate said:

You're not alone. There were so many design decisions which made me scratch my head - like, could they not see this would be issue down the road (or immediately).

The issue here has nothing to do with the SDK. He wants a number from a sensor it doesn’t have and doesn’t need.

(The rest of your post is way off topic.)

mcinner1 said:

Yes, there is an “Automatic Wheel Circumference” mode on Edge devices – however, this works with GPS distance measurement, which is far too inaccurate for your purposes – and, what's more, it varies constantly because it is recalculated at specific intervals.

You can have the unit calculate this number or you can enter it.

www8.garmin.com/.../GUID-DB7E720A-4CA0-4C30-AA2A-28DEC5060416-3977.html

I think it calculates it early after it’s turned on. I don’t think it keeps recalculating it during the ride.

Is this number that different from that determined from a roll-out?

I guess the goal is to determine what gear the rider is in.

bunny.hu said:

Its true, but if you using a long enough distance and you have a revolution number, you can count a good enough C for the wheel.

This is what the head unit does. But it does it once at the beginning of the ride. It assumes the number doesn’t change.

IQ doesn’t provide access to this number, unfortunately. @mcinner1 said this number was “way too inaccurate”. If that’s true, your number isn’t likely to be better.

dpawlyk said:

I don’t think it keeps recalculating it during the ride.

Just try it. Ride with „automatic wheel circumference“ and observe the current size from time to time in the sensor‘s settings.

I did some test today, 71km ride. The garmin speed sensor "wheel circumference" changing so fast and so much. I think they recalculate from the last small distance like 1km or something like that. It is stupid, if I did this calculation, I recalculate from the whole activity, so as the ride longer as my calculation better.

It is almost 100% certain that you will not change tires during a tour, so we can assume that you will ride on the same tires, and thus we can safely look at the total distance. And if I know the total number of wheel revolutions and the distance, the longer the distance, the more accurate the number will be, and the less significant the occasional miscalculations will be.

In my opinion, Garmin is once again on the wrong track in this regard.

Ah, the test. My 32/622 Vittoria tire on 3.5bar. Whole distance at this time is around ~60km 2.5 hour ride more or less.
timestamp hh:mm:ss Wheel C mm

16:10:33  2141
16:10:45  2136
16:11:01  2143
16:11:18  2141
16:41:34  2132
16:41:49  2138
16:42:50  2137

In most of my data fields, I have the gear index for manual shift systems, and I have done a lot of testing to find out what works best.
The simplest is the best:
Make a mark on the floor with chalk. Sit on the bike with the valve of the wheel at the mark. Move 5 wheel revolutions while seated until the valve is at the bottom. Make a second mark and measure the distance. Use the calculated wheel circumference and check whether the gears are displayed correctly. If necessary, make small corrections to the circumference until the gear display is correct.

BTW: you can measure the wheel rotations for an entire activity: mount a cadence sensor to the spokes of the wheel. In Garmin Connect you can read the sum of crank revolutions - which are now wheel revolutions.

bunny.hu said:

About the gear index, how you actually calculate? Simple cog order or ratio or any other idea?

My gear display is for electric shift systems front and rear.
For mechanical systems I offer only rear (one chainring). One can chose index or number of teeths. The calculation is performed using cadence and speed. This works fine for one chainring only. Two or even three chainrings cannot lead to clear results, because the overlapping zones do not allow for clear assignment - they often have (nearly) the same ratio and speed and cadence measurment is not stable enough. And I do not want users to complain about wrong results (and I‘m doing MTB only with one chainring). I also added some algorithms so the shift display doesn't show zero when you're not pedaling but stays at the current gear, and short miscalculations are not displayed. In addition, the user can fine-tune the wheel circumference while riding (see previous page).

But I can see - for road biking you want to see front and rear. But I don't see any possibility of a satisfactory solution for mechanical gear shifters.