69 Ghost

iTrader: (1)

Yes Grumpy agreed. I am thinking LT1 bins again. It appears that it just runs on MAF code unless it fails then the MAP takes over as a backup. The code does allow the MAF to be turned off with a switch to just run the MAP.

1981TTA

I'd agree a MAP+MAF bin is a little far reaching. However, given the way this thread started, I think it's a good idea to brainstorm a bit. Some code modifications/enhancements have been successfully made by individuals to various bins (WB logging, VE table expansion, MAF support for TBI ECMs, etc). And, there's appears to be a lot of cooperation on the "Super AUJP" calibration by a number of people. If this effort starts with a few people making individual changes, giving them to everyone to test and integrating that change with the next change, I think something of a "community" would end up being formed even though it starts with "individuals".

Maybe this is overly optimistic. But, you can tell there are a number of knowledgeable people on this board with a very wide skillset. It's kind of fun imagining the things that can be done if we were moving in the same direction. Even if things move a little slowly at first.....

junkcltr

iTrader: (1)

There was a thread posted a while ago by MonteCarSlow that I think most 730 ECM users have overlooked. It is a great module that can buffer all kinds of info that can be sent via the ALDL when required. You can see what the ECM is up to in more detail.
It can do real-time updates. Yes, it is an emulator for $50 and a solid design in theory. It should be more reliable than the external emulators currently out there.

As for faster ALDL, why not drop in a different RS-232 device on the 730 PCB in place of the SXR device? Set the CPU for a faster baud rate.
Some relocatable 730 source could would be very nice.

J

tail

I think faster ALDL would be good, but there are other things that could be done in the meantime. It's fast enough that we should be concentrating on what happend in the ECM not what is sent to the logger. IMO

JPrevost

That's what makes lockers not just a datalogger. It looks at the ram locations... all of them. You just sample it at 17Hz and you can see how the ecm is working the numbers. It really opens your eyes as too why some code might not be working when you can see how the ecm is using it's ram . Kind of like reading one's mind only for a computer.
I must say that the $8D would be a great all around work-horse if people got the trans controls working and then did the source code. Once that is done somebody could look at the code, remove all of the speed density fueling and replace it with MAF code.

JP86SS

iTrader: (1)

I'm going to go back and begin on that.
It would help in so many areas.
My biggest concern is the naming convention I use. I'll try to keep with what has been done with the $58 as far as the common items are but when it comes down to getting it done I'll probly just make them whatever seems reasonable (to me anyway)
Can always go back and do a find/replace if I go too far into left field.
Q:
Are there any addresses indexed from the stack that may not be where a previous push/pull left them?
That has me a bit worried. I'll probably find out soon enough but if anyone has delt with these parts just let me know in what functions to look for them.

RBob

iTrader: (1)

I wouldn't worry about renaming all of the calibration tables and terms. That is a lot of work. If you start with the ANHT hac it uses labels that contain the address. That is OK when starting out. Over time more informative labels can be added.

Such as this:

The addresses referenced here are relocatable as they are labels. Convert the ANHT pdf to text and assemble it. Fix any errors until it assembles. Then compare the built bin it to the AUJP bin. Change the source until they match.

As for the Q: there should not be any issues with indexing, addresses, and the stack. The key to making the source work is to not have any hard coded addresses. This statement is the same as above but with the table address hard coded:

That would make the code easy to break.

RBob.

JP86SS

iTrader: (1)

Tried that a year ago and drove myself nuts!
I did already comment the AUJP using the ANHT as a guide and it fully assembles with no problems.
Making all of the locations "named" shouldn't be so hard if I make a control file with all of them in there and do an assembly to confirm everything lines up. Go back and then do a search/replace on the commented file. Reassemble that and compare.

JP86SS

iTrader: (1)

I found in the assembler info that lables can be up to 79 chars long. I don't think that is wise to go so large.
I see the other hacs have lables limited to 8. (feel like DOS days)
I would like to have a little more space for descriptions but don't want to kill the file for use with other assemblers. do most assemblers have large lable compatibility?
What are common lable lengths for other assemblers?

Z69

I caught that as a potential problem. But if we leave the cal area as is. And add on at the bottom so the xdf is unaffected.
That shouldn't be problem. Not that it would take too terribly long to fix.

Also, tables in the code area didn't receive labels. Will have to do that.

Been screwing around all this time........
I figured this out months ago but never posted.
Just thought I had to be missing something simple.....

Other assemblers use slightly different syntax.
*Lxxxx and 0x$$$$ are a few examples of things I had to change when switching to other than m6811.

JP86SS

iTrader: (1)

1981TTA

I would think this would be possible if we took advantage of the approach MonteCarSlow did with the NVRAM upgrade. In this case, rather than put "memory" into that address space, a piece of addressable I/O could be substituted. That I/O could be anything from the old 8255 PPI chip to a more modern microcontroller........

Z69

Ok, fixed the hard coded address problem-works on the bench.
Now I need a running test bed to verify. Everyone I know has their car in various stages of disassembly.

JP86SS

iTrader: (1)

Excellent!
Was it the last 3 #L that were killing it?

Just broke it down last Saturday
Might put it back together tonight though, weathers going to be nice tommorrow. Was figuring it to be down till spring but this would be worth the effort.
Can't check my mail from here so send one over if you havn't already.

-=Jeff=-

I have a Program I wrote in LabVIEW for Smoothing the VE tables.. it seems to work pretty good, but I never really understood the BLM CELLS and how they affect the tables.. so the BLM CELLS area is where my program is lacking.

I thought the cells had specific RPM and MAP limits/areas.. if this is incorrect please point me int he right direction.

With the VE program I worte I have my BLMs at Part Throttle pretty close to 128.. Now I know that could be built into something more powerful if I understood the ECM a bit better.

vernw

iTrader: (2)

Hey Scott - I can do some testing for you if it will help out. I'll be leaving sunny CA for Dallas tomorrow and don't have to leave town until next Wednesday. Any chance you can have the WB stuff in it for me? Provided you can work with a manula car instead of a 700R4 based one. What broadcast coed did you use for this?

Z69

AUJP

I'll see what I can find on the diff with axyc.

I got the 8k rpm calc done. Need to test it still.

Z69

The BLM is just an adder or multiplier to the PW. I forget which.
I'd just use the blm, rpm,map for that sample and use it to point to a cell of the VE table. Get x samples for that cell and update....
or something. Then smooth the lumps. rinse repeat
Need to be careful which samples are used.

69 Ghost

iTrader: (1)

The blm cells just tell the ECM where to go based on RPM and MAP. If you have a radical cam then you may want to edit the boundaries to get good cell transversal. Look at the PCM tutorial good info.

http://para.noid.org/~lj/PCM%20Tutorial/PCMtutorial.htm

-=Jeff=-

That is what I am doing.. but I smooth the data on from 20-100kPA for each RPM line, I have it only updating between changed cells, not the whole map.

If I have time this weekend I will post some screen shots


[QUOTE]Originally posted by 69 Ghost
The blm cells just tell the ECM where to go based on RPM and MAP. If you have a radical cam then you may want to edit the boundaries to get good cell transversal. Look at the PCM tutorial good info.


http://para.noid.org/~lj/PCM%20Tutorial/PCMtutorial.htm


Thanks for the link

JP86SS

iTrader: (1)

One of your LDD was still a decimal value
Assembled good after fixing that.
Put everything back together to try it out but had such a bad miss that I couldn't get it to run decent enough to try the bin on the AP.
Tore it all down now, heads off in less than 4 hrs. Made good time. Think I roached a lobe or a lifter on #3 Ex, the head gasket was ok so I'll be pulling the cam.
No more testing for me for a bit

RednGold86Z

iTrader: (1)

That winter summer fuel thing should be added to the "great $8D" list. Along with some form of MAP switch (1, 2, 3 bar), or perhaps some melding of $58 and $8D would be in order.

The way to tell if the thing likely has winter fuel is probably just a starting ctemp running average temp as long as it's below typical max ambient temps. Maybe check for minimum start temp for the last X starts, and use that. I dunno even which tables would be affected seriously enough, but should aim for some more Open Loop improvements for those that prefer OL.

Or perhaps some FMU support in the $8D code.

Here's another - Injector Constant vs MAP - then could run with no vacuum reference to the fuel pressure regulator (xcept it'll make idle that much harder without sequential or single fire mode).

Did Open Loop Idle get mentioned yet? How about closed loop idle for X time, then open loop +/- Y%.

What problems do people have that run Manual Trans with NO VSS?? Maybe some supporting algorithms and some calibration switch to use them?

JP86SS

iTrader: (1)

Found another idea from another thread
Safety shutoff if loss of oil pressure
would need to use an input, maybe 2nd fan request or something for an on/off indication. Should be able to use the oil switch signal from the fuel pump relay.

RednGold'
What would an FMU need?
I was under the impression they pretty much worked on their own to boost fuel psi as boost rises.
Lower the inj constant as boost rises?

89 Iroc Z

The corvette has a oil temperature sensor connected to the ECM at pin C14, no idea what that is equivalent to on the 730, so that input could be used instead. The 2'nd fan monitor is useful and should be left.

69 Ghost

iTrader: (1)

The oil pressure switch is to keep the car from stalling when your relay goes out. All $8d's have this. The Vette's $8d have an temp sensor that is mixed into the code for timing, etc. I would be careful about any switch turning off the car.

JPrevost

Yeah, just give me a bright warning of low oil pressure. Even when oil pressure is gone an engine can run for a few seconds to get you to the side of the road without any bearing damage.

JP86SS

iTrader: (1)

Sure, and also create a blink out error to indicate the fault if it occurrs. Would need a bypass timer for startup so you don't get any long crank time.
The AUJP does not use an oil input so to speak, only an input if the fuel pump is powered. Could be by the DRP outputting to engage the FP relay or directly from the oil switch.
Really no way to tell if oil pressure is present currently.

JP86SS

iTrader: (1)

TTT,

I had a neat thought today to use an on/off input (or whatever is open) to be N02 switched.
Create secondary adder or multiplier table to VE for using a dry shot.
Could be tuned as needed to match the combo.
Enables can be setup for MAP, TPS, Speed or whatever else needed. Should be used only with WB running so if it goes too lean it could have a multiplier as a safety. Fuel switch input would be nice to shut it all down if FP is lost.

Was dreaming of future 10's this morning

3.8TransAM

Would we be doing this project using $8D as a starting point aws an assemble(able) bin or a user defineable format(asin picking options x,y and z)?

I'm not by far the code guru here:-) lol

But in my warped logic, everyone in their right mind running port v8s and a few of the 6's are running a version of $8D or $58 code if they are a boosted app. (not sticking it to MAf guys here so dont take offense).

If such a project were to move forward wouldnt basing it off of a $8D/$58 code blend be best?

We would all be on the same page and could make the Map Bar selectable for 1,2,3 bar like was suggested earlier. Also have the larger extended tables and take the strengths of each to make one uniform type SD code. than running boost would be as simple as flagging the 2 or 3 bar map and flaggin the adder tables for when under boost.

I could see where this would bring many issues to the table such as actually writing the code and then assembling it, let alone getting it to the point where it functions on a car.

Like I said, I'm not the code guy, just a few ideas I had.

later
Jeremy

Z69

There is always the code versus bin publishing issue....

If such a project were to move forward wouldnt basing it off of a $8D/$58 code blend be best?
I was wondering when this would get brought up.
Not having a list of all the boost related tables (yet)
It might be feasible to do. I know of one person who said the will give me/post some of their $58 hac stuff when they finish. It has been brought up in the past that it would be better to start with the $58. Which is true from a work stand point. 1/2/3 bar WBCL is already available.
But for whatever reason there is resistance to using it.
I suspect if the table naming between 8D and the $58 were conventionalized. And some of the differences in code were dealt with. Then most of the 8D tuning knowledge would be applicable and more people might be willing to use it. People with little code knowledge could work on some of this portion.

Would we be doing this project using $8D as a starting point aws an assemble(able) bin or a user defineable format(asin picking options x,y and z)?
The smog stuff will probably have to go. Currently the stock code isn't modularized or linear enough to make this easy. I think it would need to be to allow for the xyz option.
The way I envision it with my blurry vision would be to have a control file for the assembler to include modules yxz to make a bin. Then just set the base bin up to allow for the modules to be stuck in with defaults to set any missing adders/mulplrs to 0/1. Bruce was able to "cut and paste" the $60 together so it's doable. Most of the desired code is available already.
Just a matter of melding it togethor.

I'm suprised no one has brought up any tuning issues.
Or delete this because most zero it out any way.

Some of the guys running aujp with a MT need to chime in with what they had to fix.

Keep the ideas coming. Big or small

I need to stop looking at that 2240 thread......I think I'm getting A D D as I get older.

69 Ghost

iTrader: (1)

I think that people are only stuck on one code or another for somewhat trival reasons. I have this ECM or I have a TPI not a TBI or I went to a supercharger for added power. Again if the direction was in line for most of the guys out there that are doing tuning and they can easily convert then going forward is not an issue as long as it is the majority that moves forward as a group. The rest will follow. The result would be a effort that could be used by all.

JP86SS

iTrader: (1)

It would be nice but will take people who have good working knowledge of both boosted $58/60 and N/A $8D.
Anyone who runs boost doesn't look at $8D unless they have to and vice versa. I'm kinda up on $8D and still have more to learn. Dropped out of the $60 loop because lack of knowledge on my behalf. Not understanding the interactions of the basic spark/fuel requirements as you transition from vac to boost leaves me with tons of questions that get me going in circles.
Maybe someone who has made the transition with code knowledge at both extremes can give EXACT relationships of how the functions need to be changed can chime in.
I don't see it as being "just flip the pressure scale" type of thing.
Until then, I'm still sucking air

1981TTA

I'm probably 180 degrees from you, JP86SS, regarding $8D vs. $58 knowledge for the exact reason you mentioned. So, my assumptions of what's in $8D and the value of what's in there might be off. But, poor assumptions have never stopped me before.....

From what I (think I) know about $58's boost related functionality, I think transplanting the boost related code in $8D would be pretty straightforward. There really aren't all that many boost related tables/calibrations that would have to be changed to support MAP > 100kPa. I think a $58-ported-to-$8D would be a preferred solution. This would eliminate the need for people to repin their harnesses. And, where applicable, emissions equipment control could be maintained. The bigger question is whether or not there's room on the PROM for the additions....?

junkcltr

iTrader: (1)

From memory, I think there is 12K bytes of unused space in the $8D 32K bin. That would be more than enough to fit the $58 boost stuff in the $8D without removing anything.

JP86SS

iTrader: (1)

Sounds like something to work on then
Now that I've got 4K to play with

1981TTA

Looks like I need to start diving into the $8D world.... Reconfiguring my poor ECM bench isn't usually something I look forward to. But, I think the results are going to be worth it!

3.8TransAM

Well Red n Gold started it, I just added to what he said.

What works best in both bins would be the ideal.

From what I know of the $8D hac I prefer it as well as neat things like actual IC(no fudging numbers) etc and so forth.

EGR stuff in $58 looks strange compared to the $8D code.

From all looks of the hacs and tdf's, the $8D is the most developed of the two for all NA stuff in my eyes(again im not the best at code so maybe im smoking something)

The $58 stuff does boost very well if we can blend it in with the extended VE tables on the $8d code and the like

Hmmm what about the MAT sensor stuff in $58 code? Is it more developed for a boosted application vs the NA $8D stuff.


We would need a 1,2,3 bar flag.

Flag for wastegate actuator(solenoid)

VE table extended with resolution of the $8D would work

Boost multiplier factors could be used to cover it after that like the $8d

Main timing table could just be extended like the $58 code in regards to MAP and possibly lengthened like the VE table for ruther resolution

later
Jeremy

Z69

I haven't looked at the $58 much. But the WG control
might be difficult to move.
Also, 8D AE has some pw limiters built in that I don't know enough to follow in the code. Might be problem.

junkcltr

iTrader: (1)

I wouldn't worry about the wastegate stuff. It would be the last thing to insert into the $8D. Most people use the vaccuum actuators with a mechanically adjustable valve for the boost setting. I think only the hardcore people use the ECM to control it to limit boost off the line (traction control), boost spike on initial boost, and over-boost in general.
The $8D used a MAT and I think the $58 used an IAT. Correct? if so, that may take some tweaking. Anyone one ever see a factory Syclone/Typhoon and know where the temp. sensor was located?

J

Z69

In the manifold as I was politely told by Grumpy.

I haven't looked, but a SA vs MAT is the desired
code. If it's not in the $58, it should be added.
There may be some WG/MAT stuff in there.
A 550hp motor may not need electronic boost control.
The motor I'm planning could use some boost limiting
at lower speeds.

3.8TransAM

Believe Sy/Ty sensor is in the plenum.

I noticed a lot of the wastegate stuff in the $58 is strange especially to what I can figure out in the T31 code for the 148 intercooled buicks.

I dont see why it wouldnt be possible to make it a more simple system, which i think the 148 is for wastegate acutation than the $58. 3 and 4th gear scalars should work fine.

No one I know uses it for traction contorl, they usually do some type of vss vs rate of change and use it to pull timing to lessen eng power.

$58 code I cant say on, but the 148, lots of boost scalar tables especially for 3 and 4th gear in use to this day, even with all th new stuff out there for them.

Would be a nice feature to keep intact, especially to people who would end up using it NA and Boosted.

later
Jeremy

junkcltr

iTrader: (1)

That is good that it a MAT on the $58. I thought the $58 had a boost limit table for acceleration/first gear (traction control)? Not sure, pretty tired right now. Maybe it is just something I had in my head that I wanted.

J

1981TTA

I can't speak to what's in the 148 ECM. But, the $58 logic has a lot of generic wastegate logic mixed in with logic that will adjust boost based on vehicle speeds, spark knock and desired boost levels. To be honest, it does seem rather complicated. But, I really haven't tried this to see if there's merit to implementing all the calibrations. I'd be curious if Sy/Ty owners routinely "disconnect" ECM control of the wastegate in favor of some other aftermarket system or "tweak" the existing algorithm...? There is a separate set of logic for the 1st boost seen after the ECM powers up. But, I don't think this is related to the gear state.

Also, I only have access to the Turbo Sunbird schematics. So, this may be different on the V6 apps. There aren't any gear inputs to the ECM outside of Park/Neutral. Even the TCC logic doesn't differentiate between 3rd and 4th gears. I don't know if the 730/$8D logic has this capability?

junkcltr

iTrader: (1)

The Syclone doesn't have a low gear input. I meant low MPH limiting of boost. I am also curious how the SyTy guys play with it or if they just go to a mechanical valve adjustment.
It seems like a nice feature to me. I use regular radial street tires and the boost comes in early makes them spin real easy. I would be nice to have the boost hold off longer at low mph. Or I could learn to control myself.

JP86SS

iTrader: (1)

730 has a 4th gear input that is run from a pressure switch in the autos. With a manual trans?

Anybody look if there is WG control in $60 ? The complexity may already have been reduced.

junkcltr

iTrader: (1)

From what I have seen, the $60 code went to closed source. I would rather base this work all on open source code. I was told the $60 is a dead project. No need to bring it back from the dead.
The $58 WG control can be figured out and installed in the $8D. It would be the last thing to insert in the $8D code.

Someone mentioned that the $8D isn't "source code" yet?
What do you mean by this? What do mean by "source code"? Some people think C is source, some think assembly, some think Pascal. What do you think source is?

J

Grumpy

More correctly the 60 never made the light of day, due to a total lack of participation. It was to be a group project, but the active *group* was me.

Lots of things can be done, but so far, all that's been *done* has been talk.

Source code, is having a text type document that you can assemble, and get a valid .bin file from. Without having Source code all you'll ever be able to do is patches, and never fully inderstand what the code is doing.

As far as boost control, once you have the proper code, then cutting boost as a function of what gear your in deminishes. OK, I've only played up to 28 PSI, so maybe if you're running more then that, you might need a more sophisticated answer. My Wastegate Controller is a $39 mechanical item. Once you start using VSS corrections, it all makes alot more sense....

As far as boost goes, reworking the 8D would be a better starting point. At least then, everyone would have some common ground. And again, what needs done is developing cource code, and then stripping that down to the basics, and then building from there.

Yes, the Syclones had the MAT sensor, in the Manifold.

Yes, most anything can be done in code, but someone (or group) needs to do the work. I think I've said that before.

RBob

iTrader: (1)

With a manual trans? Use N/V ratio, ECM will then know which gear the transmission is in.

RBob.

JP86SS

iTrader: (1)

Thanks Grumpy, you hit it on the head. I was very enthusiastic on the $60 that it had been done and was waiting for others to improve on and make suggestions. Being the noob to code and DIS at that time I shy'd away from it due to nothing more than ignorance on the subject. After all the time spent going over $8D it is becoming a bit less foggy now. Must make time to go back and review what was in front of my face from the beginning.

The part that helps the most is GROUP work.

I've made progress and with allot of additional help from Scott (Z69) pushing the effort along. When I get stuck he pushes, when he gets slowed I've gone back at it and he picked up the ball . It has worked but only together the goals get easier.
Without help, none of this is possible. One person would have to be a total code junkie to get this far alone!!!!
(I'd have to say GET A LIFE) there's better things to do with that much time.
$8D relocatable source will be release VERY SOON. It's on the hook right now.
Need a bit more feedback to be sure it does relocate properly from users.
The work has been done and we believe it is done. Fully labled and includes expanded High VE table and WB support, a nice 31.25 RPM scale to take you to 7,969 RPM if you want it.
(credit due to RBob, 1981TTA, & Z69 respectively on those additions)
It does assemble and compare but still testing is needed to be sure it does not become problematic in real use. Can't test myself or this would already be out there (wish I could go to 7900 without looking for rod parts )

Going the boosted route and combining the code can be done but needs additional help to push the though process.
I don't plan on running boost anytime soon but the prospect of making universal code thrills the S#*t out of me personally.
We've already investigated the possibility of switching code WITHOUT repinning.
The differences are not that great from what has been revealed. That is a nice goal to shoot for.
I'm also for trimming the code to remove emmision stuff and optimize for fun. Lots of things can go away once the cat and the smog pump are gone, outputs are also gained.
Just letting some cats slightly out of the bag for now

1981TTA has already stepped up to give input to what he knows on the boosted side of things, others are needed to fill in the gaps.
Put up some info on how YOU see things working and together we can come to a conclusion as to the best way to handle the code. I feel the code part will be easy once the COMPLETE theory of operation is set.
Ok, done rambling for now anyway.

Thanks RBob, Duh I should remembered that!

69 Ghost

iTrader: (1)

Ah so that is what Z69 wanted me to test on the bin... Seems Grumpy is doing some arm chair directing as the 2240 caddy stuff is taking off. Sounds like the next step is to combine the 2 after the caddy guys get the SEFI working. Having a 8d with that and trolled tranny along with any power adders sets up a future for a lot of people.