The gear indicator feature was to be implemented in Ver 8, if I recall
I also tried to do it through the CAN bus, but it never worked for me...... Hoping to see the gear indicator feature (from the RaceChrono app itself) so everybody can use it more easily.
Gear is not a consistent PID from car to car. This is very unlikely since your feature request would require a database of all gear PIDs for all (popular) makes & models.
I think brake pressure is similar, which is another common request of mobile lap timer apps.
Gear is a OBD2 PID (0xA4) from 2020! But it´s not an obligatory value, which not every modern car supports. And even if, the implementation differs a lot.
Yes, good story. That's exactly my point - it's all nonstandard for gear, brake pressure and various other need-to-have type telemetry metrics.
Remember that the only reason the OBD port exists is the State of California mandated it for smog/emissions testing. So the only data that is really consistent on OBD is required by the smog station's computer system. Gear and brake pressure aren't relevant to emissions testing AFAIK. But regardless that port is not really there for data acquisition. Some auto makers have made lemonade out of lemons by developing scan / programming functionality on those ports but it's hit or miss and varies wildly from make to make and model to model.
For my 718 Cayman I started like you did with the "standard" OBD PID and got zilch. Later on started CAN hacking. For my PDK transmission the PID turns out to be 258 and its 4 bits with "8" = reverse and "0" = neutral.
But then I helped out @webkris with his manual Cayman and turns out the gear PID for that car is 129, completely different even though "same" car. For manual the field is also 4 bit but the format is totally different (0 stopped; 1-6 gear; 13 reverse; 14 not engaged).
So this goes to the overall issue - for data channels that are not mandatory for emissions testing it's virtually impossible to have a one-size-fits-all approach. That's why companies like VBox that charge $5K - $10K per system have their proprietary DBCs where they've gone and figured all this out for specific platforms. I don't think it's realistic for a mobile app developer to whom we pay a few $100 dollars to have that type of database. As it is - coming up with the database of tracks is infinitely more important and I'm amazed that tools like RaceChrono have pretty complete such DBs with well defined start/stop points.
Ahhh, now that is a useful idea for folks who have no other solution. Have fields for say up to 8 gears. If value is blank or zero then car does not have that gear.
Of course this approach often yields wrong results. I don't know what the overall error rate is but it's above 10%. I know because I played with this very approach before I started CAN hacking. Went out and did test drives recording RPM and speed from the OBD port on multiple freeway runs, and then charted the scatterplots against calculated drive ratio sawtooth curves. Though the vast majority of datapoints did "cluster" on a gear line (but not exactly - there is definitely pretty good variance) there were many many many datapoints that were nowhere near any of the gear lines.
But so long as such a feature is caveated as an estimate that will not always be correct it's probably a decent approach for bulk of people.
That´s easier in theory then in reality. Attempted that with my second bike, which has no gear indicator and I also took the ratio between speed and rpm. Worked okay but not great. Clutching, using the engine break or rolling out will show crap. And the best solution is to show the last gear...
Following up on @TriB comment about unreliability of the method. I looked at the code and it's smart to have "bands" of validity per gear ratio because the data turns out to be incredibly noisy.
Here's a link to a PDF where I plotted the freeway road tests captured in my 718 Cayman that I mentioned a back in April. Data is directly from Porsche's onboard PCM system and includes actual gear value. Charts have dashed line overlays for each gear ratio plotted in unique colors, and then the RPM vs. Speed scatterplot is color coded to match according to the gear reported by the car.
There are three charts because the car has three driving modes - Normal, Sport, and Sport Plus which affect the up/downshift points among other things.
First thing to notice is how messy / noisy the data is, especially in Normal mode. Dots in scatterplot of RPM vs. Speed rarely appear directly on the exact gear ratio line.
Second thing to notice is miscategorization of gear # due to what must be reporting latency in the various channels. You can see lots of examples where the color for gear X appears on the line for Gears Y or Z. Since each of these values (RPM, speed, gear) is coming on the CAN bus at different update rates, this says to me that the 3 values are not always reported in sync. Probably not an issue if you don't have gear anyway and are trying to impute it, but it underscores that even RPM and Speed values may not correspond to same micro/millisecond of time thereby creating noise / blur in the data.
Take speed and RPM for instance. Let's say both are reported at 25 Hz, they are still different PIDs and therefore not reported concurrently on either CAN or OBD. So they can never be from the same moment in time. If the two values are reported at different update rates - say speed is at 10 Hz but RPM is at 25 Hz this will only magnify. Of course this will vary wildly by ECU make/model.
Third thing to notice is that while disambiguation via the "band" method looks pretty feasible at higher RPMs say above 2000 due to the gear ratio lines diverging, at low RPMs the opposite is true because the gear ratio lines are now *converging*. Look at the "Normal" mode plot for the best example of this. Data points at low RPM are all over the place and even having the car's actual gear value doesn't do much to make it make sense.
That might be the source of @TriB comment that it "worked OK but not great".
At end of day I'm skeptical this calculated option is going to yield super meaningful data.
It was rock solid in my M2, never glitched. Decently set thresholds for each gear filters out the noise. And no need for super fast updates. And also using two request/replies (with callbacks) right after each other, not listening to broadcasts.
This really depends on the frequency, you can read those two values. On my motorbike, only providing KWP2000 as a protocol, I receive 7 Messages per second. That´s much too slow as I already mentioned. But with CAN-Bus, having 10 and 25 Hz, I´d really expect to receive much more reliable results, as Magnus states out. I´m quite sure, you can archive better results on that Cayman!
Comments
In Porsches at least gear is not available via OBD. I tracked it down for my Cayman on the CAN bus with quite a bit of work.
I am using unmodified RaceChrono to monitor and export track data including gear captured this way.
I also tried to do it through the CAN bus, but it never worked for me......
Hoping to see the gear indicator feature (from the RaceChrono app itself) so everybody can use it more easily.
I think brake pressure is similar, which is another common request of mobile lap timer apps.
But it´s not an obligatory value, which not every modern car supports. And even if, the implementation differs a lot.
I described my personal journey to support it for my motorbikes here:
https://racechrono.com/forum/discussion/2150/pid-a4-transmission-actual-gear
But the other way around...
Remember that the only reason the OBD port exists is the State of California mandated it for smog/emissions testing. So the only data that is really consistent on OBD is required by the smog station's computer system. Gear and brake pressure aren't relevant to emissions testing AFAIK. But regardless that port is not really there for data acquisition. Some auto makers have made lemonade out of lemons by developing scan / programming functionality on those ports but it's hit or miss and varies wildly from make to make and model to model.
For my 718 Cayman I started like you did with the "standard" OBD PID and got zilch. Later on started CAN hacking. For my PDK transmission the PID turns out to be 258 and its 4 bits with "8" = reverse and "0" = neutral.
But then I helped out @webkris with his manual Cayman and turns out the gear PID for that car is 129, completely different even though "same" car. For manual the field is also 4 bit but the format is totally different (0 stopped; 1-6 gear; 13 reverse; 14 not engaged).
So this goes to the overall issue - for data channels that are not mandatory for emissions testing it's virtually impossible to have a one-size-fits-all approach. That's why companies like VBox that charge $5K - $10K per system have their proprietary DBCs where they've gone and figured all this out for specific platforms. I don't think it's realistic for a mobile app developer to whom we pay a few $100 dollars to have that type of database. As it is - coming up with the database of tracks is infinitely more important and I'm amazed that tools like RaceChrono have pretty complete such DBs with well defined start/stop points.
Like you said that will be too much work.
It would be nice if there is a (input) page where we can insert own
• gear and drive ratios
ex:
1st gear: 3.91
2nd gear: 2.32
3rd gear: 1.61
4th gear: 1.28
5th gear: 1.08
6th gear: 0.88
Drive ratio: 3.44
&
• tire size
ex:
245 18 40
Most cases the app can figure out the gear you are in
with (speed,gear, drive ratios & tire size)
Of course this approach often yields wrong results. I don't know what the overall error rate is but it's above 10%. I know because I played with this very approach before I started CAN hacking. Went out and did test drives recording RPM and speed from the OBD port on multiple freeway runs, and then charted the scatterplots against calculated drive ratio sawtooth curves. Though the vast majority of datapoints did "cluster" on a gear line (but not exactly - there is definitely pretty good variance) there were many many many datapoints that were nowhere near any of the gear lines.
But so long as such a feature is caveated as an estimate that will not always be correct it's probably a decent approach for bulk of people.
like this
https://youtube.com/shorts/PNmr70gA9Nk
Attempted that with my second bike, which has no gear indicator and I also took the ratio between speed and rpm.
Worked okay but not great.
Clutching, using the engine break or rolling out will show crap. And the best solution is to show the last gear...
That´s my latest, best shot:
https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Bike_Diagnostic_System/Gear.ino
Thanks for sharing your knowledge
It seems like it is not easy, but it is possible
This code worked extremely well in my DCT BMW https://github.com/MagnusThome/BMW-M2-DCT-Gear-indicator
Very effective!
I intended to make it self learning, not that complicated, but never bought another car where I needed that HUD again. So I never came around to it.
Here's a link to a PDF where I plotted the freeway road tests captured in my 718 Cayman that I mentioned a back in April. Data is directly from Porsche's onboard PCM system and includes actual gear value. Charts have dashed line overlays for each gear ratio plotted in unique colors, and then the RPM vs. Speed scatterplot is color coded to match according to the gear reported by the car.
There are three charts because the car has three driving modes - Normal, Sport, and Sport Plus which affect the up/downshift points among other things.
First thing to notice is how messy / noisy the data is, especially in Normal mode. Dots in scatterplot of RPM vs. Speed rarely appear directly on the exact gear ratio line.
Second thing to notice is miscategorization of gear # due to what must be reporting latency in the various channels. You can see lots of examples where the color for gear X appears on the line for Gears Y or Z. Since each of these values (RPM, speed, gear) is coming on the CAN bus at different update rates, this says to me that the 3 values are not always reported in sync. Probably not an issue if you don't have gear anyway and are trying to impute it, but it underscores that even RPM and Speed values may not correspond to same micro/millisecond of time thereby creating noise / blur in the data.
Take speed and RPM for instance. Let's say both are reported at 25 Hz, they are still different PIDs and therefore not reported concurrently on either CAN or OBD. So they can never be from the same moment in time. If the two values are reported at different update rates - say speed is at 10 Hz but RPM is at 25 Hz this will only magnify. Of course this will vary wildly by ECU make/model.
Third thing to notice is that while disambiguation via the "band" method looks pretty feasible at higher RPMs say above 2000 due to the gear ratio lines diverging, at low RPMs the opposite is true because the gear ratio lines are now *converging*. Look at the "Normal" mode plot for the best example of this. Data points at low RPM are all over the place and even having the car's actual gear value doesn't do much to make it make sense.
That might be the source of @TriB comment that it "worked OK but not great".
At end of day I'm skeptical this calculated option is going to yield super meaningful data.
https://www.dropbox.com/scl/fi/z2wicn43jyafu720c769y/2024.01-Cayman-GTS-Measured-Speed-vs-RPM-vs-Gear-Curves-for-3-modes.pdf?rlkey=2i5ws772svyohmc1fhf2tf1dp&st=6lnlfdu3&dl=0
It was rock solid in my M2, never glitched. Decently set thresholds for each gear filters out the noise. And no need for super fast updates. And also using two request/replies (with callbacks) right after each other, not listening to broadcasts.
On my motorbike, only providing KWP2000 as a protocol, I receive 7 Messages per second.
That´s much too slow as I already mentioned.
But with CAN-Bus, having 10 and 25 Hz, I´d really expect to receive much more reliable results, as Magnus states out.
I´m quite sure, you can archive better results on that Cayman!