Any way we can do a simple calculated gear display? When logging both RPM and Speed, a simple ratio of the two would provide the gear..... The user could enter the number of gears and the ratio for each. The user would have to go log some rpm and speed values for each gear and compute the ratio, then the code would test if the ratio was close to one of the gear ratios....
This would be a really cool feature!
Comments
I might use the teensy to do some other things too....
Another approach would be a screen that lets you Calibrate 1st, 2nd, 3rd, etc. gears. Because the RPM/Speed ratio is a constant at all times in a particular gear, the user could drive in 1st gear, hit the 'Calibrate 1st Gear' button, then stay in 1st gear for a few seconds until a 'beep' is heard. Then shift to 2nd gear, press 'Cal. 2nd Gear' etc. Rinse and repeat for all other gears.
Thanks for the amazing work.
Now that v5 is released is this feature back on your radar?
I get about 2hz on rpm and speed
There are (at least) two problems:
- You once need the ratio (maybe by a "learning meachanism")
- Without Clutch information, you´ll always have wrong values
For my motorbike it looks like the following (simplified):
uint8_t GetCurrentGear() {
uint8_t ratio = rpm / speed;
if (ratio >= 130 && ratio <= 180)
return 1;
if (ratio >= 88 && ratio <= 120)
return 2;
if (ratio >= 70 && ratio <= 80)
return 3;
if (ratio >= 60 && ratio <= 69)
return 4;
if (ratio >= 55 && ratio <= 59)
return 5;
if (ratio >= 48 && ratio <= 54)
return 6;
return 0;
}
It works good enough, after two testrides and a tiny bit of shifting the ratio-ranges.
But during a shift or pulling the clutch when rolling out, the gear sometimes get crazy.
Instead of returning 0, I think it would be better to return the last known value.
On top of that, there is an accuracy parameter.
Not sure whether it uses OBD/CAN speed or GPS speed (with/without correction factor).
To prevent them from storing wrong ratios during a gear change, they´d have a period of time, this ratio must be present.
Additional to that, there will be a tolerance.
This mode will be started once and then you have to shift through all gears for storing.
I´ve also started my coding like that. A sortable array with a fixed tolerance and a method to check a bit of logic validity.
The idea behind that was to measure the gears on every startup, without any stored/fixed ratios. If a gear was skipped, it will sort the array right, during the next cycle.
But it began with clutching in on startup, which made bad values.
Or double-clutch on a downshift. I guess the reverse on a car will also let the values went crazy.
Neutral gear, rolling onto the trafficlights.
My slow bike ECU, with just ~7 values per second.
And measured ratios, too close to each other. On my bike 5. gear between 55 - 59.
If you store 57 as a ratio, and a tolerance of 2 for that gear (it will differ off course from transmission to transmission). Next time, storing 56 with the same tolerance will make you jump between 4. and 5. gear.
For those reasons, I decided to take my datalog, a video and approximated the ratios.
- Just to tell my journey and prevent you from doing it the same way
@TriB I think on car, or at least mine, would be easier due to the clutch switch accessible via CAN-bus. My car also has a switch checking if the car is in gear or neutral, I think these switches are needed on all manual transmission cars with cruise control or ready to mount cruise control.
The thing is that usually the speed and the engine rpm are broadcasted on very fast channels (in my case 100 Hz, and they are also broadcasted on the same ID), while the clutch switch is sent on slower channel and with different time stamp.
I think the gear indicator should be a math channel all managed by RaceChrono (sorry @aol more work for you ) and not by the device, without clutch input (that may be not available/may be too slow), in this way you may also add a gear indicator on past sessions!
@mmrizio I would use ECU speed, since it is mechanically linked to rpm via transmission, while GPS may be subject to variation... I plotted RPM vs Speed both ECU and GPS and using the ECU you get nice straight line, especially on low speed, while with GPS it's not that neat and also you may lose connection.
Some idea:
- Do not calculate for speed < 10 km/h (who cares!!) or rpm below a certain threshold (i.e. 1000 rpm?)
- I think you can take 2 subsequent points in time, speed and rpm, and calculate the slope and X intercept of the line. If you are in gear the line is going to intercept X axis at 0 (with tolerance), while if you upshift you'll have a nearly vertical drop during clutch time, and a spike in downshift when rev-matching. Whatever action you are doing when you press the clutch the subsequent RPM-vs-speed points are describing a line that is not going to intercept X at 0... Maybe this is enough to discard clutch time values, without involving averages. If subsequent values are the same you fall back on previous slope and intercept calculation.
- I think just checking the RPM-vs-speed slope, with some tolerance, you can identify the different ratios, than is just a matter on where start to count this may be a manual input, for each session you can indicate the minimum or maximum gear you have used (i.e. I never use my sixth gear, in some track I hardly use the fifth... I think it's easy to remember this things at the end of a session)
I calculated the ratios and use dashware to do the math and display it in the dash area of the overlay. See example here.
https://youtu.be/WUiFD1Xes5E
On a track with my Gsx-R600 I can just rely on the gear from my ECU data. Independent which change on the transmission I did. It even knows the gear on the dash, in the exact moment I put in 1st.
My Kawasaki went crazy, since I changed the rear sprocket. That´s why I must calculate it on my own.
@aol you were right! I was testing a lot on the road, and it´s common to just shift 2 gears at once, after accelerating quite hard
But on a track (where racechrono belongs) it´s rubbish