Any general discussion around the firmware, what is does, how it does it etc.
#39344
I have full tested board, used with 722.6 gearbox. I can design opensource PCB for Gearcontroll firmware based on Mega2560 or Teensy 3.5 board.
Buzzliteyear wrote: Tue Sep 10, 2019 10:45 am Great.....is there any info that would help you Dazq from here
https://github.com/mkovero/7226ctrl
I was designed PCB for this project.
#53057
ryan_pajero-io wrote: Thu Aug 29, 2019 8:51 am
dazq wrote: Wed Aug 28, 2019 6:40 pm Choosing and designing suitable fully automatic strategy is difficult , and is more complicated when the controller needs to be capable of running multiple types of gearboxes from numerous manufacturers.
The flexibility makes for much complication.
That's true, it's really really complicated. So, I hope I can provide any little help for this project, I am very happy.
I think it isn't actually that complicated, but what's critical is to know when and where abstractions need to be made for features.

Like global solenoid outputs, shift inputs, rpm inputs, and TPS inputs. Global. Not global are going to be all the features in-between like your torque prediction algorithms, the signals for torque prediction, and outputs that you may need.

That's where it gets tricky and I feel DX Gears, for example, is totally stuck. If you want to control more advanced transmissions with "blind" timings you can, but you're absolutely better off writing an Arduino script to manually, and directly offset your shift timings.



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? 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...

Thoughts would be appreciated. New to this, have ideas, would love some direction.
#53201
The GM '427 computer with $0D code has been disassembled and commented fairly well(if you can wrap your head around assembly). It will operate all the GM transmissions in use up to 1995 which includes 4l60E and 4l80E's. You can use Tuner Pro (free) to view ALL the tables and various settings.
I would think this would be enough example info to guide somebody through writing a really good universal trans controller.
If I was a better programmer i'd tackle it, but its a bit beyond my skills.
#53245
punisher454 wrote: Wed Sep 22, 2021 7:22 am The GM '427 computer with $0D code has been disassembled and commented fairly well(if you can wrap your head around assembly). It will operate all the GM transmissions in use up to 1995 which includes 4l60E and 4l80E's. You can use Tuner Pro (free) to view ALL the tables and various settings.
I would think this would be enough example info to guide somebody through writing a really good universal trans controller.
If I was a better programmer i'd tackle it, but its a bit beyond my skills.
Unfortunately I doubt it will work for the full electronic 6l, 8l, 10l families. And whatever ZF versions correspond. 6r80, 10r80 what have you. And those are the transmissions I'm interested in platforming.

As it stands, getting a decent 4l80 is not what it used to be. Same with a th400. Where as an electronic 6 speed in decent condition can be had almost everywhere (in the US), and they can be fully capable of extreme applications, with many more benefits on the table. The biggest issue is the factory integrated mechatronic controller.
#53252
blackbird wrote: Mon Sep 13, 2021 1: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? 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...
Looking to provide feedback, I'll take a stab at it from an application project planning viewpoint, which is likely very different from a coding project. I suppose first steps are to make a requirements sheet. What are the project goals and objectives? What does the controller have to do (specific tasks to perform)?

This list may be very different if it is for specific application or "universal", based on the previous goals and objectives. I would use caution is this area, as the coding and programming structure would be very different, and the urge to "make it for one and go from there" would be counter-productive for universal application. Conversely, very wide universal application can bury the project in function requirements.

A logic tree from that, of required inputs and outputs, leading to signal types and hardware solutions. At that point you have your rough physical controller plan-form. It may or may not be covered with existing layouts.

From there it is a question of how it processes the available inputs to create the required outputs on the available hardware, e.g., your shift algorithms and other functions. Programming structure addresses this last question, based on previous logic tree outline. For universal goals, modular code blocks seem to be popular, allowing multiple similar functions to be "dropped-in", e.g., we need 2 more timed PWM shift solenoid outputs or another VSS input.

Coding is not my wheelhouse, and I focus on requirements and implementation, so I'm not of much help in that area. I can tell you what it needs, effectively what the function should do and parameters for it (inputs, tables, dependencies, etc), while others do the magic to create the outputs. Then I resolve the best way to implement those functions to the results required, based on the goals and objectives previously listed. A process such as PDCA (plan, do, check, and act/assess/adjust) would be implemented throughout.

To make coding not only possible by any unfamiliar coder, but effective in results, the descriptive functions in the logic tree must be very specific. The coder should be able to provide guidelines or worksheets for them to follow, in order to create the functions you require. Does that help at all? Perhaps it throws a wrench in the spokes. :lol:
#53254
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.
#53257
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.
#53259
A pr is just a way to collaborate with existing work by offering a modified version to the original author who can review then merge your work in as they see fit.

Teensy, fine for me I like them, in fact all my modules in my project build use some sort of teensy from 3.2 through to 4.1

Pm sent
#53263
PSIG wrote: Sun Sep 26, 2021 1:23 pm
blackbird wrote: Mon Sep 13, 2021 1: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? 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...
Looking to provide feedback, I'll take a stab at it from an application project planning viewpoint, which is likely very different from a coding project. I suppose first steps are to make a requirements sheet. What are the project goals and objectives? What does the controller have to do (specific tasks to perform)?

This list may be very different if it is for specific application or "universal", based on the previous goals and objectives. I would use caution is this area, as the coding and programming structure would be very different, and the urge to "make it for one and go from there" would be counter-productive for universal application. Conversely, very wide universal application can bury the project in function requirements.

A logic tree from that, of required inputs and outputs, leading to signal types and hardware solutions. At that point you have your rough physical controller plan-form. It may or may not be covered with existing layouts.

From there it is a question of how it processes the available inputs to create the required outputs on the available hardware, e.g., your shift algorithms and other functions. Programming structure addresses this last question, based on previous logic tree outline. For universal goals, modular code blocks seem to be popular, allowing multiple similar functions to be "dropped-in", e.g., we need 2 more timed PWM shift solenoid outputs or another VSS input.

Coding is not my wheelhouse, and I focus on requirements and implementation, so I'm not of much help in that area. I can tell you what it needs, effectively what the function should do and parameters for it (inputs, tables, dependencies, etc), while others do the magic to create the outputs. Then I resolve the best way to implement those functions to the results required, based on the goals and objectives previously listed. A process such as PDCA (plan, do, check, and act/assess/adjust) would be implemented throughout.

To make coding not only possible by any unfamiliar coder, but effective in results, the descriptive functions in the logic tree must be very specific. The coder should be able to provide guidelines or worksheets for them to follow, in order to create the functions you require. Does that help at all? Perhaps it throws a wrench in the spokes. :lol:
I think it helps! I think I need to remind myself to be more organized. I was able to design a bunch of parts, and figure stuff out my way, but when it comes to collaboration my methods of disorganization won't work.

I think I have an idea of a list so to speak. And was thinking along those same lines. I need to truncate it. I came on here thinking aloud mostly, but I wasn't sure how it would be received. So I appreciate you saying it.

I think I can create basically a workflow logic flow so to speak.

Hi, I am trying to assign Signed values to the x-a[…]

Vr Conditioner Noise when cranking

New version 202305 don't fix the issue. Now after[…]

blitzbox

I've finally figured out why MAP and Lambda weren'[…]

Hello, I bring news!! Let me tell you that after […]

Still can't find what you're looking for?