Discussion about gear calculator data format for graph

Good ideas. I'd also add another one: 2 separate fields for the front and rear gear (or number of cogs?)

The 1st thing is to decide how it will be used. By human by looking at the graph? Or is this just a way to save it and some app will use it? 

The 2nd thing: how does it make more sense? Is there a usual way? If not, then for you what is more useful?

3rd: it might make sense to give the user a setting where they could choose

I would use it to check afterwards what gear I was in, e.g. on a hill or during a normal workout. For me, the best way to do this is to see the front and rear cog/gear numbers. However, if I were to process it later, the gear ratio would be more informative.

The other dilemma – see my topic on wheel circumference calculation – is that with overlapping gear ratios, the inaccurate circumference can jump due to the current pedal rotation or speed, which means huge jumps in the chainring data (completely different front and rear) while the gear ratio may have changed by only a fraction. For this reason, it is preferable to link it to the gear ratio, but this is not very informative to the human eye.
A solution to this could be a combined gear ratio (see 1-24 instead of 2x12), but if it is not adjusted to the gear ratio, there will still be large jumps.

These are the reasons for my dilemma. For now, the most appealing option is perhaps the gear ratio multiplied by in the round part, and the combined gear ratio in the decimal part. This way, the graph will not jump around too much due to "noise", but the gear ratio is still relatively readable. The only drawback, which the AI pointed out to me, is that there may be a problem with too many digits due to 32-bit storage. If, for example, I want the ratio  to be 3 decimal places, that's 4 digits + 3 digits for the gear cogs, which is already 7. The solution to this could be to use double, but the question is how large the FIT file will be.

And of course, someone might have a better idea :)

I would have 3 fields:

gear ratio (btw maybe also include the wheel size?) as a float

front gear as byte

rear gear as byte

This would mean 6 bytes all together

I think 2 field for the two gearset is not informative, but maybe separate the ratio from some version of the gears combination would be working. If you need after computing there is the ratio, for humans there is a gears.

Yes, but the way you can represent the gears with 1 number is also confusing if you have more than 1 front gear.

Yes, but I use the combinated gear number, like I wrote:

bunny.hu said:

Combinated chainring&cassette position in one number. What I mean, the 101 means 1. chainring 1 cassette. 309 means 3. chainring 9. cassette. etc.

Or, ATM I store in float and use the integer part is the speed index (1-24) and the decimal is that combinated cog number.

So for example my front is 46/30 and rear is 11-34 12s.

The first speed is 30-34 and i store like 1.3034. 

The last (fastest) speed is 46/11 so it is 24.4611

You got the speed index and the cogs in the same number, plus the graph is smooth if I using the ratio to the speed index order and not simple cog1+cassette, cog2+cassette

OK, that makes sense, the value will more or less give the gear, and the decimal will have some more precise information. But if I had a 3x8 bike, then I'm not sure that the way you and the app count the gears is the way I'd count them. But I guess there's not much you can do about that anyway.

Yep, you can order it based the chaingring cog number or the ratio. Because the overlapped ration ( on a 3x system there is more ) the calculation is sometime jumping. If I using a simple chainring+cassette ordering like 1-8 chainring1, 9-17 chainring2 ... when the calculation jumping you got a huge jumping in the speed number. If it is ordered by ratio, its moving only +-1 speed. Anyway I fighting atm the float problem that I said store 1.3034 and stored like 1.30334543234 etc :D So maybe the float number is not the best.

If you'd only want the data, then you could use a string, but then you wouldn't be able to see it on the graph.
So you can either have 2 bytes for front, rear chainring number, or use fixed point integers.

It's going to be a bit strange, but if you look at the graph only, then it'd look pretty much the same regardless of having numbers like:

1.xxx - 24.yyy or 1xxx - 24xxx (i.e: 13034 - 244611) 

because Garmin Connect will stretch the graph to max available size

Good point, yes. I thinking about the graph because thats the way to see information on a specific point of the trip. So, not really the graph like graph, more like graph the way to bond the information into the map position. Or am I wrong?