Please tell us what exactly is stopping you from using the gearbox strategy.
I wanted to wait until I actually had a config dialed in before commenting on this. It’s also likely that my approach is wrong, but here are some of the problems I’ve run into. As a reminder I’m using CANTCU and a BMW DCT.
- I don’t have explicit upshift/downshift messages
- I don’t want the built in protections (max RPM, can’t downshift/upshift out of the “wrong” gear, rearm time, etc)
- It doesn’t help with my pseudo-torque model
In the end all I really want is “cut/retard when I say to” and “exit overrun when I say to”, which I am now accomplishing with the vehicle speed limiter for cut, 4d ignition table for retard, and H-pattern downshift to exit overrun (so then my blips are handled by the normal DBW table).
In more detail:
“I don’t have explicit upshift/downshift messages.”
CANTCU sends a bunch of messages, including shift-in-progress, blip, cut, delta tq, gear, and target RPM. I believe (but I don’t know for certain) that the blip, cut, and target RPM messages are completely fabricated by CANTCU, while the transmission truth is delta tq and gear.
For performance reasons, I generate my own target RPM messages to avoid the round trip latency from ECU → CANTCU → ECU. Afterall, the target RPM is based on wheel speeds which the ECU has, so why bother waiting for the update from CANTCU, esp when CAN transmission can be delayed with the 500Hz main loop.
At one point I was predicting upshift/downshift based on change of gear while shift-in-progress is true, but it’s a little hacky especially if the driver makes another change mid-shift.
I also get weird behavior from the transmission if, for example, I request a downshift while at low part-throttle. CANTCU won’t send a blip at all (but I think the transmission sends a small delta-torque). Instead it seems to wait for the driver to give it more power before eventually a cut comes in once the RPMs match.
Or if I shift into gear from neutral on the dyno while the wheels are rolling. I get a blip (and want to blip), but it’s not technically a downshift.
I think the right answer is to only follow the delta-torque messages from the transmission, regardless of upshift or downshift.
I don’t want the built in protections (max RPM, can’t downshift/upshift out of the “wrong” gear, rearm time, etc)
The H-pattern strategy has protections built in to prevent driver stupidity or misprogramming, but they can get in the way of a “smart” transmission that is going to do whatever it wants. It’s also an artifact of wedging blip/cut into downshift/upshift regardless of what gear change is actually happening. I can work around max RPM by simply increasing it to a ridiculous value; I can work around wrong gear by always telling the ECU I’m in 3rd gear (but that’s a hack); I lowered rearm time to 50ms. But I have to hope I covered all the corner cases correctly and I’m left wondering if the car will misbehave at some point on track. It seemed safer to just work around the H-pattern strategy as I didn’t think there was a difference how I requested a cut.
It doesn’t help with my pseudo-torque model
In order to make it easier to alter power on the dyno (I race in a power-to-weight class with a dynojet present at every event), I have a series of tables in project tree emulating a pedal to torque request system, while the final DBW table maps load/rpm to throttle position.
One way I used this recently was having a notion of how much load is needed to maintain a given RPM. I can compare this to driver request to decide how much to cut. I can take the max of the two to decide what to request of the throttle. This (along with some other functions) allowed for easier blip/cut decisions regardless of altitude or pedal position, without having to tune a bunch of high dimension tables.
As a result of this, though, the blip table in the H-pattern strategy is basically useless to me. I’m doing all the dbw load request calculations in project tree and sending it to the DBW strategy regardless of whether its a shift or not. The only problem I ran into was that during overrun, the DBW request was ignored, so I have a dummy H-pattern downshift strategy that is active during ANY shift, has a “Blip level” scalar value of 3%, and has checked the “Blip level is DBW target min” option so that the project tree value is used instead.
Sorry for the long post, but the TLDR:
- I’m doing things in an unconventional way. It may be by the time I’m done I’ll come back to the conventional way. What I have is not working well (yet) and I keep refining it race to race. I think other people have gotten it working well so maybe this is just a “me” problem.
- I assumed that it didn’t matter where I requested blips or cuts, so I didn’t see a reason to try to use the H-pattern strategy.
- I do believe that ideally there would be either a DCT or a CANTCU specific shift strategy. I’m kind of hoping that you’ll run into similar issues developing the 8HP protocol and maybe I can piggy back on the work you’re doing there once it’s released, but it’s also probable that all that logic will be only be accessible if you actually have an 8HP.
