Jonohhh
True Classic
So, over Thanksgiving break, having a little bit of time resulted in my usual habit of being entirely unable to leave things alone, so here it is: manual transmission auto rev matching implementation.
Two linear potentiometers - one on each shift cable, measures the current left to right and front to back position of the shift lever. The output of those sensors is read by my Arduino, which then determines the currently selected gear based on the known values for each shifter position, before sending a message over the cars C CAN network to my standalone ECU, which corresponds to the selected gear.
When the clutch is pressed, the ECU will enable the rev match mode and match engine speed to the currently selected gear (by either blipping the throttle, or cutting ignition/fuel, depending on whether it's an up or down shift), eliminating the need to blip on downshifts, and assisting in completely seamless upshifts with absolutely zero effort or attention required. Even better, upshifts can be rev matched by ignition/fuel cut alone - meaning the throttle plate can stay open, and boost is maintained throughout the gear change.
Which is fine and dandy... except once I got the above working, I quickly realized that the parts in bold weren't gonna work for what I wanted, because EMU Blacks rev match feature:
a) never left the alpha development stage
b) sucks
c) works only by selecting "calculated" current gear, and simply revs to the rpm of one gear lower if you press the clutch while braking. Not good enough for me.
So I made my own.
Instead of simply sending the currently selected gear over CAN, I had to take a different approach: requesting throttle blips and ignition cuts directly from the Arduino!
So in reality, it ended up being that my Arduino would:
Read the shift position potentiometers, and determine the currently selected gear.
Read vehicle speed, engine speed, and clutch pedal position from the ECU over CAN.
Calculate the speed of the clutch plate based on the average of the front axle wheel speeds, and the ratio of the currently selected gear.
Compare engine speed to clutch plate speed (rpm error, which represents the slip rpm at the clutch interface)
And, if a handful of conditions are met (the most obvious of which is if the clutch pedal has reached the floor limit switch), and the engine speed is a certain amount slower than the clutch plate, it'll send a a gearbox blip request over CAN to my ECU.
The ECU reads this as if it's a sequential gearbox, and uses a few of its internal tables to clamp the maximum blip duration, the throttle percent during blip, and the conditions required for it to do it. The check for clutch pedal position happens both on my Arduino, and on my ECU, for redundancy, to lower the chances that there is an accidental blip while in gear.
This redundancy isn't as good as it could be because it relies on a single switch, but the good news is that these events are so short that essentially no acceleration of the car happens if it were to go off while in gear.
It works well, but it's certainly not perfect. In the future I'm going to emulate a VW DQ250 DCT (which the ECU supports) so that I can have finer control over the blip and cut intensity, hopefully resulting in it feeling as good as an OEM implementation.
That's pretty much all for now. I truthfully don't even want this feature but it's fun to mess around with things like this so, there it is. I'll probably never use it again once I finish perfecting it.
photos.app.goo.gl
photos.app.goo.gl
Two linear potentiometers - one on each shift cable, measures the current left to right and front to back position of the shift lever. The output of those sensors is read by my Arduino, which then determines the currently selected gear based on the known values for each shifter position, before sending a message over the cars C CAN network to my standalone ECU, which corresponds to the selected gear.
When the clutch is pressed, the ECU will enable the rev match mode and match engine speed to the currently selected gear (by either blipping the throttle, or cutting ignition/fuel, depending on whether it's an up or down shift), eliminating the need to blip on downshifts, and assisting in completely seamless upshifts with absolutely zero effort or attention required. Even better, upshifts can be rev matched by ignition/fuel cut alone - meaning the throttle plate can stay open, and boost is maintained throughout the gear change.
Which is fine and dandy... except once I got the above working, I quickly realized that the parts in bold weren't gonna work for what I wanted, because EMU Blacks rev match feature:
a) never left the alpha development stage
b) sucks
c) works only by selecting "calculated" current gear, and simply revs to the rpm of one gear lower if you press the clutch while braking. Not good enough for me.
So I made my own.
Instead of simply sending the currently selected gear over CAN, I had to take a different approach: requesting throttle blips and ignition cuts directly from the Arduino!
So in reality, it ended up being that my Arduino would:
Read the shift position potentiometers, and determine the currently selected gear.
Read vehicle speed, engine speed, and clutch pedal position from the ECU over CAN.
Calculate the speed of the clutch plate based on the average of the front axle wheel speeds, and the ratio of the currently selected gear.
Compare engine speed to clutch plate speed (rpm error, which represents the slip rpm at the clutch interface)
And, if a handful of conditions are met (the most obvious of which is if the clutch pedal has reached the floor limit switch), and the engine speed is a certain amount slower than the clutch plate, it'll send a a gearbox blip request over CAN to my ECU.
The ECU reads this as if it's a sequential gearbox, and uses a few of its internal tables to clamp the maximum blip duration, the throttle percent during blip, and the conditions required for it to do it. The check for clutch pedal position happens both on my Arduino, and on my ECU, for redundancy, to lower the chances that there is an accidental blip while in gear.
This redundancy isn't as good as it could be because it relies on a single switch, but the good news is that these events are so short that essentially no acceleration of the car happens if it were to go off while in gear.
It works well, but it's certainly not perfect. In the future I'm going to emulate a VW DQ250 DCT (which the ECU supports) so that I can have finer control over the blip and cut intensity, hopefully resulting in it feeling as good as an OEM implementation.
That's pretty much all for now. I truthfully don't even want this feature but it's fun to mess around with things like this so, there it is. I'll probably never use it again once I finish perfecting it.
New video by Jon Olaivar
photos.app.goo.gl
New video by Jon Olaivar
photos.app.goo.gl
Last edited:
