dazq wrote: ↑Sun Sep 26, 2021 4:00 pm
blackbird wrote: ↑
Mon Sep 13, 2021 2:48 am
... The real reason I'm willing to bump this old thread is to see if anyone might have any ideas on the best way to implement shift algorithms?
As David has said above the ability to offer a device that covers many possible boxes is /has always been the tricky part. A core with modular add-ons does seem the best route imo and is how gears and gpio have been going this far.
Would it be better to start with DX Gears, or DX Control? OR Try to basically husk out speeduino firmware to give all those inputs and change your outputs...
Gears and gpio are descended from speedy already, I took the spark and fuel stuff out , added io handling , kept the TS interface and there we got to here.
Speedy core code has grown since then and there is quite a few things I would like to change .
With both I had always hoped others may chip in a pr or two to help move things along.
I wrote out a really long lol and thorough response, got logged out (laptop went to sleep when I moved rooms) and continued to add to it... Hit post and lost it all because I wasn't logged FML.
So I just learned what PR stands for. But I don't really understand who does what in a PR or what it specifically does. I'm not a coder so I have no REAL experience with GitHub stuff. I've learned to use it, and understand a bit of C but yeah.
Working through DX Gears I found that utils.ino allows you to setup both what solenoids or outputs are in use, but also the sort of shift logic in a two dimensional fashion.
The controller I was planning on using is very similar, however instead of the cases containing different transmissions or solenoid logic combinations, it would be different gears.
For example:
gear 1:
If (RACE == 1){
analogWrite(line, 55);
analogWrite(s1, 255);
analogWrite(s2, 255);
analogWrite(s3, 55);
analogWrite(s4, 55);
analogWrite(s5, 255);
analogWrite(s6, 255);
}
else {
analogWrite(line, 175);
analogWrite(s1, 255);
analogWrite(s2, 255);
analogWrite(s3, 55);
analogWrite(s4, 55);
analogWrite(s5 255);
analogWrite(s6, 255)}
digitalWrite last = gear 1
break;
gear 2
If (RACE == 1) {
analogWrite(line, 55)
analogWrite(s1, 5)
analogWrite(s2, 255)
analogWrite(s3, 255)
analogWrite(s4, 255)
analogWrite(s5, 255)
analogWrite(s6, 255)
analogWrite(dump, 255)
}
else {
analogWrite(line, 255)
analogWrite(s1, 5)
analogWrite(s2, 55)
analogWrite(s3, 255)
analogWrite(s4, 125)
analogWrite(s5, 255)
analogWrite(s6, 255)
delay (50) //imagine this but with a millis()function to prevent the draw backs of delay
analogWrite(s2, 175)
delay (125) //imagine this just with a millis() function
analogWrite(s2, 255)
}
digitalWrite(last = gear 2)
break;
The difference being a more dynamic logic. With the use of "race" here, we are going to create a conditional. And we can stack these conditional statements, and get quite convoluted with nesting IF statements. And this can work, especially with something like a teensy 4.1 (which is what I staunchly intend to use).
But this has quite a few limitations. And we cannot dial in or set up an open loop controller as quickly, efficiently, and easily as we can a closed loop controller.
I would say a state machine based system could be made semi closed loop, but unless you involve a truly dynamic, 3d map it won't ever be properly executed.
For racing only, drag racing especially open loop is fine. But for any kind of drivability, closed loop is essential. I mean pro mod drag cars run open loop controllers on their air shifted 6 speed's and what have you. They do it either by RPM or Time, alternating depending on conditions. Those controllers are actually quite expensive too (ironically lol).
My idea was closer to using the fuel map, as a solenoid output map. That way you can adjust pre fill on clutch packs to enhance the drivability without having to resort to mechanical tricks that would compromise the power holding capacity or other drivability of the trans. As there are many tricks even to just one family of transmissions.
The idea is to retain RPM, boost, TPS, etc as core inputs, as those are going to be most predictive of the conditions the engine is in. Then, use that to determine if the trans needs to be pre-filled by pulsing the solenoids, or spreading out the apply (like I did above), or whatever. That way you can actually setup up shifts, and down shifts. Then the internal pressure sensors can be used as well; as inputs to the 3d map.
The big trick here is that these newer transmissions are stacked. They have multiple clutch packs inside each other, alongside having clutch braking (instead of a band like the 4l60 that we talked about in the other thread). So as that braking clutch releases, it is a non rotating piston. So it never experiences any centrifugal apply. (Just an example)... But it is releasing that hub shaft, to a rotating clutch. As in, it shares a driving hub. Which means 2 things that make dynamic mapping critical. 1) That rotating clutch pack will have a centrifugal apply portion, that needs to be compensated for in the timing of the apply... faster rpm, less pre fill, potentially even changes to the line pressure solenoid. Lower rpm, more pre-fill. 2) if the timing is spread out, and the clutches can't get the right amount of overlap, this can cause a severe bind (one clutch won't let the hub spin, the other clutch wants to spin the same hub). This will either break hard parts (most likely) or burn up clutches. For my trans, I know these clutches will not slip if they're locked up (these are the same clutches used in pro mods currently, where just 1 can hold 4000hp, let alone 6-7 of them). Or if you spread out that transition from one to another, you will lock up the rear end, as first gear will be engaged.
So, yeah. I have some software here that is being used on a transmission controller that's being sold. You can take a look through it (pm me), and see how they do it. They have a lot of features, but it isn't anything that speeduino can't do/tuner studio. Just a matter of getting there. I don't really want to advertise them.