-
more measurable variables > more assumed/estimated variables.
a good example being barometric pressure.... especially with boosted applications, instead of having a single MAP sensor that is only allowed to update barometric readings when known to not be in boost(or in the case of stuff like 8F, only before cranking the engine), you can run a 1BAR MAP solely for baro updates while you have a 2/3 BAR for manifold pressure (or a MAF, if you don't like speed-density).
want to have the ECM calculate the compressor and intercooler efficiency and have desired boost get dialed back if temps get too high? need a couple of temperature and pressure sensors for that alone.
track things that normally wouldn't be connected to the ECM, like oil pressure, fuel pressure, transmission line pressure(instead of assuming the main PCS table is 100% perfect, you can use it to verify/calibrate it even more accurately), fuel level, maybe even go so far as tilt sensors to compensate shift points for driving angle, etc.... the sky is the limit with inputs and it's hard to have too much information.
outputs are also precious... they're always the first thing i run out of. intelligent control of everything is something i like.
while you can reasonably control an engine with nothing more than coolant and air temp, engine speed/position, TPS, manifold pressure(or MAF), injectors, spark output.... it just won't be the same as something that can measure and calculate anything that could effect how the engine will react to any given situation.
-
"And those who are prideful and refuse to bow down shall be laid low and made unto dust"
-Prior
-
1 Attachment(s)
-
-
4 channels, works up to 350MHz?
that could be quite the buy, assuming it's all still functional.
-
Ouch! $107.47 shipping? Ahh.. I see why he chances stuff so cheap...
-
There's an edge connector available in the ecm that was used with the GM HUD and needed better comms than ALDL. I can probably dig out info on "lockers" which is the basis for the Dynamic EFI What's Up Display and uses that connector.
Too much info and too little time to service provides a false sense of security and complicates control. Additional outputs don't necessarily improve results. Early TBI ecm's such as Crossfire (pre C3) suck. Period. Driveability sucks. Tuning sucks. Fixing sucks. You need a complete package with supporting hardware.
Don't get me wrong... I am in complete agreement as to more = better. Why not use comparative wheel speed to indicate loss of traction and decrease boost? Why not use predictive algorithms to head off overboost? Fuel temp should be measured as not only does density change but combustion efficiency as well, which could allow reduced spark timing. There is plenty to play with.
Many programs for the 68000 processors are written in C. Its like another language, si? Rather than learn the high level language, the best way to get familiar with the architecture might be trying to port existing hc11 code.
-
Pyrolysis: The thermochemical decomposition of organic material at elevated temperatures without the participation of oxygen.
"Proof of concept" occurred successfully this weekend with methanol recovery tank left over from biodiesel production done back in '04 and '05. Looking forward to implementing reactor / collection facility.
-
considering the code to jump to subroutines on the HUD still existed in most code, i'd say it's a possibility. how to use to to communicate between multiple modules though, that's where i'm drawing a blank.
considering how much stuff i've been able to slip into the 80Hz routines without running into issues, i'm not so concerned about lack of processing time(especially since there will now be 3 times as much processing power)... i run out of outputs, RAM and program space before anything else.
the use of comparative wheel speed came up on 60V6 already... problem we ran into was that the 6811s don't have enough inputs that can measure pulse length with any good degree of accuracy at the speeds needed. so then the fix of frequency to voltage converters came up, that would only need 4 A/D channels at most and would allow pretty good results. then the final remaining problem was that there weren't enough free A/D channels to impliment it and still have the normal functions.... multiple modules solves that.
problem with the 68000 and higher level languages is the higher level languages... i can't wrap my head around them. pretty much my entire programming experience is in BASIC and 6800 assembly, little bit of arduino. beyond that, i seem to have a mental block with C, C#, C++, Java... pretty much anything i've touched has been beyond confusing. then again, the 6800 stuff was like that at one time too.
-
In the Sunbird I used delta rpm to assign wheel spin. I just dumped boost if the engine increased speed too quickly and the vehicle moving bit was set. It worked but what I really wanted to make was a closed loop system that would pull boost and slowly add it back in. I never spent any time creating a real algorithm though.
I have no quick answer about communicating between modules. I'd have to look at the Lockers info to see what is available there. The 7727 in the Vette was constantly communicating with a Central Control Module which also worked with ABS, HVAC, BCM, Theft, etc. Riviera / Toronado was very chatty with plenty of data sent between modules. Both of those cars had bi-directional communications with on-board systems and with the right tricks you could command tests to run, look at scan data, clear codes, and more.
I'm not sure how to help with the programming. I always have a goal when learning... with assembly and GM computers it was as simple as making the check engine light blink on and off. "Hello, world." Turns out you have to know more than just how to modify existing code to make that happen.
-
my idea on controlling wheel spin and to an extent, torque in general, was D-VSS. accelerate too fast and spark gets dialed down until under a threshold, then it gets added back in until it either comes out of it or too much power gets sent through again.
all of those used the ALDL line and pretty much made the vehicle useless without it... i really don't want to go that route, since i want datalogging to be a fast, smooth process between multiple modules, just have to load the correct ADX and go on with business.
-
d VSS is a great option with the advantage that you could use a lookup table vs current gear ratio. Downside is you can't run up against tire traction limit as easily. That's where the comparison comes into play.
With existing inputs you could rectify the a/c signal from a non-driven wheel to provide a speed dependent voltage. Clip at 5V to prevent damage to ecm, use resistor network if necessary to extend speed range before 5V limit is reached, and use existing rpm / VSS signal for comparison. Not true frequency based solution but a binary condition slip / no slip that's accurate could be a big improvement. Reducing timing works even on boost application. 2nd stage reduce boost if vehicle is so equipped.
How many variables do you think are necessary on the ALDL for effective tuning?
-
i was actually planning on a 2D table vs MPH per gear of allowable D-VSS before spark limiting came into play.... it was the best compromise i could come up with at the time.
that rectification method... i was considering something like it, but IIRC, it looked like it was going to be pretty non-linear at lower speeds?
necessary for tuning? well, i actually reorganized the datastream specifically for necessity... i have 30 bytes that i have listed as absolute necessity, 21 nice-but-not-really-required and 12 that can be swapped out for anything someone might be curious about(dwell, async PW, spare A/D channels...)
-
isn't that torque management?? on another note while taking cummins engine classes for a license I found out what an algorithm was finally. damn step by step. thought yall might find that funny. but to me its learning.
-
some say torque management.... i would call it traction management.