funstick

i ran some code simulation with the help of a few friends. it looks like the code stops going up from 255grams/sec why is this happening. well the code itself has a single bit error alowance in the airflow error chart and it has a resolution of 1gram/sec at high flow rates. well this all works out to a magical max airflow of 255grams/sec as calculated by the code. a 427 ci engine with a 42pph injector at 255grams/sec needs a 7msec PW.

so i think the solution is to rewrite the code to work in 16bit. either that or do away with the air mass calcs and use a BPC.

Grumpy

Without Source Code, your idea, might be limited to just a patch to get around that.

However, since you mentioned a specific engine, I spent some time looking at things.

427=~ 868cc/cyl
42s

Using a stock AUJP and just changing those 2 values, the PWs were 6-7 msec at ~4,100 and then started leaning out.
No other changes, but setting the VEs at 90-100 K/Pa to 100, and got into the 7s and no leaning out.

TRAX, and JON alert, please ignore the following,

I also spent some more time on the bench this morning, running various 8D .bins. As I had mentioned yesterday, I was having to use a scope to try and read the PWs, also as I had mentioned, it's an LCD display, so I qualified my statements with the word, *seems*. This am found what I'd been doing wrong, corrected that, and then reran the .bins from yesterday. Using TurboLink as the scanner, the PWs do vary, for PE AFR, 100 K/Pa values, Inj size, and cylinder vol., changes. So while the code may not be perfect, it seems to run just fine, as far as the TurboLink display goes.

Now, if there is a airflow calculation limit error, then the short sweet and simple answer might be just cutting the cylinder volume, and injector sizes in half. I spun the same .bin for the engine FS discribed using the 1/2 and 1/2 numbers and the PWs were a few hundreds of a msec., different, but I doubt at 4K, being at 6.96 vs 7.00 is going to make for much of an effective difference. If there's something, else the airflow is used for, then other scaling maybe needed.

Merry Christmas........

RBob

iTrader: (1)

The airflow term is not used for the PW calculation. There is a 16-bit term that is the mass of air per cylinder that is used.

RBob.

AlexJH

I've been looking through the 8D code, and I find it weird that the battery correction is added right before it's written to the 3FF2 register, but they never check for overflow at that point.

Is it handled elsewhere in the code?

Is the 3FF2 reigster the right one to be looking at?

funstick

i knew the PW's varied. but there has to be a mximum that the code can calculator for mass of air. its all 8bit stuff. you got a copy of the anht or ajup hacs ?? ill pass it on to the programer and see what he can do with fixing this. so what you saying is though that at the proper cylinder size and injector flow that the code is in fact stopping short of the maximum PW. but the PW's can be varied just not past a certian point.

my thought is that the code stops counting up for the PW calculation when you hit and airflow of 255grams/sec as calculated byt the cylinder size and VE tables. becuase it only maskes sense. the injector size is figured into the PW. but if the quantity of air is limited it would explian the PW.

Since you have a bench try an experiment. try making the injectors bigger and see what happens ?

funstick

Rbob from the little i read of the anht hac before a worm ate my Hdd on my home computer i cant see that being true. the first thing the ECM does is figure out the air volume comming in now. then it uses the injector size to with the air mass to determine PW. i cant see how the derived GRAMS/SEC of air entering isnt used in the PW calculation. thats the whole point of using the ideal gas law.

RBob

iTrader: (1)

What I said is true. The air flow value is not used in the PW calculation. There is another calculation which is the mass of air per cylinder in grams. That value is used in the PW calculation. As the injectors are fired in sync with the engine cycles, flow doesn't matter. Only the mass of air that fills a cylinder matters.

In order to derive the air flow, the RPM needs to be taken into account. With the injectors firing in sync with the RPm, the flow would need to be converted back to an RPM-less value.

GM skips all that and does a direct calculation of the mass of air that fills a cylinder per intake stroke cycle. Boom, that , the injector flow, and the desired FA ratio, out comes a PW.

Notice the injector constant is in seconds per gram of fuel. A direct term to the grams of air in the cylinder.

RBob.

funstick

what im saying rbob is that is there a maximum constant or perhaps a deficency in these calcs. obviously if we have 14.7grams of air per second comming in we need 1 gram of fuel. if an injetor flows 5.26 institaneous grams/sec then we know that
is equal to 5260 msec. then is quite simply to figure out that we need 1/14 of that total flow. which would be 0.35 msec.so if we have 14.7 grams of air we need 0.35 msec of fuel on a injector of 42pph hr.

so my questions is what is the maximum ability of the $8d code that it can calculate for airflow or injector size. and it is most likely a locked constant or a hardcoded value to keep people from dicking with big engines and injectors.


obviously the injectors dont get used until the last bit of PW calculation. so this is most likely and airflow issue. if it was an injector sizing issue the we code sim the code with say a 60pph injector on a 350ci dpslacment model and get the same result.

RBob

iTrader: (1)

The ECU location 3FF2 is for the async PW (AE and crank fuel). It is limited elsewhere and the battery correction can't overflow it.

ECU location 3FD0 is the sync fueling.

RBob.

RednGold86Z

iTrader: (1)

Yeah, if it were an "airflow" problem, the PW at low RPMS could still be bigger than at high RPM. This is a PW calc problem that limits the Max PW, which is, as you say, independant of airflow, only cylinder fill based.

funstick

actuall if there is a limit to the maximum airflow then the pw will be limited. if it was an injector size issue the 383 cars ive tunned in the past would have much larger problems.

TRAXION

funstick,

Did you ever read the original thread I posted? This 255g/s has already been covered there. You are repeating what has already been covered. Please read that post. We covered other stuff there too.

https://www.thirdgen.org/techbb2/sho...hreadid=256693

Here is a quote from that thread ...

Tim

funstick

if you look at the actuall limit it is a 16bit msb.lsb but its set up at the 8bit value of 255grm/sec. also its cant be turned up. becuse its already at ffff,so need to workbackwards thru the code from this point and firgure out where the scalar for that value is plus id imagine that it can only work to 255grs/sec.

again a 42pph injector on a 427ci engine at 255grs/sec is 7msec pw.

RednGold86Z

iTrader: (1)

Funstick, your calculation must be missing RPM, as there is no direct Airflow in g/s to PW equation without RPM (and A/F for that matter). That is why I said the problem isn't airflow calculation, it's PW calculation. At low RPMS, and at i.e. 255 g/s airflow, the PW would be much bigger (inversely proportional to RPM) than at high RPM and 255 g/s in order to achieve the same air fuel ratio. I have several spreadsheets that I could email to you if you want to see what I'm talking about (but this Chinese internet would take an hour for it to finish sending).

funstick

total flow if it was the same at 2000rpm as 6000rpm would require the same pw. in an synchronos firing scheme only the injectors would fire more often. RPM itself does not create a greater need for fueling. the PW would in the pw would in fact be the same. again i have yet to observe the problem on a 350 with 60pph injectors but only on a 427ci engine with 42pph injectors. the issue is not the PW calc. its the preceding cylinder filling calc being limited to x amount.

TheGreatJ

How? The injectors are firing 3 times as often at 6K, which means 3 times the fuel flow for a given PW.


Think about it. Total airflow is not RPM based. Synchronous injector firing is. The 6K RPM engine fires the injectors 3 times as often as the 2K RPM engine. If they have the same airflow, then they need the same amount of fuel, right? But if the PW is the same, and the injectors fire 3 times as often, then the 6K engine gets 3 times as much fuel....therefore the 6K engine needs 1/3 the PW to get the same amount of fuel as the 2K.

Cylinder filling, however, is a different story. If you go by the volume of the cyl., and the VE (which boils down to how much of that volume is efffectively used,) then you know how much air goes into the cyl. on each revolution. Since the injectors are also firing by the rev, you can say X grams of air in the cylinder requires Y grams of fuel. Then you factor in that the injectors flow Z grams of fuel per mSec, divide to find how many mSec it takes to get Y grams of fuel, and you can throw total airflow and RPMs both right out the window because they aren't necessary.

funstick

sort of but in a synchronos firing mode if each cylinder is filled with the same amount of air at 2000rpm as it is at 600rpm then geuss what. the pw will stay the same it will just fire the same pw at a faster rate.

TheGreatJ

That's what I just said. A given mass of air in the cylinder will always require the same PW (assuming a constant AFR.)



This, however, is a totally different statement, and not at all true.



Cylinder filling and total airflow are not the same thing.

funstick

yeah we can get nit picky over terminology i geuss. that is deffinately my error.

yes if the total volume of cylinder fill remains the same from say 1000rpm to say 5000rpm then the pw needed to fill it will again stay the same. thats why im sure the problem with 8d is in fact in the airflow calcs. if it was an injector sizing issue then it would vary the pw. this seems to hit a wall entirely. and like i siad with a 255grs/sec total volume of air the pw required per cylinder would be odly enough 7msec with a 42pph injector.

so heres what im doing in the mean time.

ive cut the ve in half. ive cut the cylinder size in half. ive cut the injector size by 88%. this has allowed me to get plenty of PW overhead. its crude its brute force but its working

Z69

From ANHT:
Could you just get rid of the ROLB/A?

Grumpy

Yes, you *could*, but you'd create another problem, or *two*.

Grumpy

Does anyone really even care about this?.

Oh well, a couple clues for the willing, the area shown is close to where one might want to develope a JMP to go do something, and the return back from that something.

I'm not sure which address it is, but if you shift the code, while it will reassemble, it won't run correctly. So for anything you do you'll want to JMP out before whatever it is you want to eliminate, and then jump back afterwards.

For an ecm bench to work this out, means a 555 to run an ignition module, and a few resistors, to give the ecm enough inputs to run, and a scan tool. A *bench* to run this is like $20, and that would include an ignition module that could double for a spare for your car. And, some *junk* modules that fail to drive a coil properly will work for bench use, so if you could find one of those you bench cost would be like $5.

funstick

bruce thanx for the help. instead of screwing around with $8d and $60. it has been decided that it would simply be alot easier to go ahead and develop scratch code for the p4 730/727/749 . if you have any data on the timmers and i/o other then what is avaiable at ludis's site plus the stuff in the hacs it would be most appreciated.

AlexJH

I've got some data on my wiki site:

http://wasabi.dynu.com:8080/wiki/index.php/Main_Page

I'd really like to get it filled out more though, so feel free to add to it where you can. I think there's a lot more info in the ANHT hac to be learned, I just haven't had the time.

EDIT: There are a lot of subroutines and startup code that you could use, like 2d, 3d lookups, rather than starting from *scratch*.

Alex

Grumpy

Oh, come on, let 'em go, it'll be interesting to see how far they get. Not to mention that, it'll give them a chance to contribute so completely and fully, like they expect others to. It'll be nice to see how freely they share what they have.

funstick

im sure we will get it done. how soon ???? wed like to be in beta before febuary. but instead of pissing and moaning about the inadequacies of the stock code at least we are doing something about it.,

Grumpy

No, you not doing anything about it, your going off on a tangent, with doing your own. The alledged problems, have simple fixes, from what I've seen so far.

Make it simple enough, and it should only take short time to get it running, the trick is finding out what level of sophistication it takes to make it really drivible, and friendly to use. And depending on what standard you use, even a Gen VI is considered good by some.

There's only a limited few (1-2, or is it 3?), are moaning about the airflow problem.
Not to mention I already posted an answer.

funstick

the answer you posted is only a bandaid.the simple fixs are again band aids fo code designed to work with stock engines and the code was engineered speciafically for emission friendlyness etc.

At this point consideing the amount known about the actuall engine control unit itself its stupid to keep playing with the stock code.

so if anybody would like to put in some input it would be nice if there were a comprehensive list of features that would be in siad code. obviously we are not going to be using any emissions stuff.

but if there is constructive input and i mean constructive it would be much appreciated.

RBob

iTrader: (1)

Since you are writing all of the code from scratch, how about a better ALDL stream. Make it 56kb with 128 or 256 bytes of data.

Beta before Feb, less then 4 weeks away, that is a lot of code to define, document, create, and test . . .

RBob.

Grim Reaper

Sean, I was an old assembly language programmer back in the 70s & 80s. What you are undertaking is extremely ambitious.

I am NOT going to tell you which way you should go. But I will offer some "old programmer" hints.

1) Sometimes it IS easier to rewrite code from scratch than modify existing code...especially poorly documented code. As we are dealing with "hacs", I would classify the $8D code as "poorly documented" as none of us were privy to the internal discussions and meetings when the original code was developed.

2) Unless you FULLY understand the applications (which I think none of us really do), your best learning point is the existing application program. Make sure you understand how the low-order memory works (hex address 0000-7FFF which is NOT documented).

3) Once you fully undertand the application, reconsider #1. You will no longer have "poorly documented" code because you now SHOULD fully know the existing code and you may see ways of improving/fixing the original code.

4) Good luck.

funstick

i am not the only person involved. thanx fo the input. yes as fo the data stream we figure 19k wont cuase to many headaches.

code is being written in C. i have a goup of people involved. we also have tons of routines thanx to other resources in our area.

low order memory. we are going to experiment. but since most of the othe memory is documented then it shouldnt be so bad. also we have sone speicifc gm variant info . i think it will be ok. to me it would make alot more sense to just stat from sctatch and build all new code that is fully understood. just seems like its time.

ecm bench is an undestatment.

1981TTA

You know, you might have better luck looking at this from another angle.... Instead of re-creating everything from "scratch", just start by methodically removing the things you think are unnecessary. I'd imagine a few existing main routines like spark advance, knock, open loop (VE calculation for SD, LV8 calculation for MAF) and closed loop (BLM, INT) fueling would initially remain pretty much the same. Code for idle (spark stabilizer, AC transitions, P/N transitions, etc) and IAC (throttle follower, ??) would seem to be candidates for removal/reduction. After you have a core set of algorithms that keep the engine running, you can then concentrate on improving those and/or adding others (closed loop WB support, NOS, etc).

Regardless of what you decide, I encourage you to dig into this! I know there are things I believe I fully understand within the code. That is, until I try to make some "simple" changes to them. Then, the *real* understanding comes.....

Grumpy

Gee, what an idea.

Not to mention doing things your way, you can leave all the self-diagnostics in place.

funstick

the diagnostic routines are actuall fiarly simple to create.

ill get into more detial as to teh nuts and bolts of the code later on but as for featues what do you think it would be nice to have with some of the unused outputs. ?? rpm switchs, nos control ???? these are examples.

JP86SS

iTrader: (1)

I would think items like full shift light setups for Manual and TCC control with bit select would be a good addition.
I do have a 90% cal section on the AUJP that I've been commenting for a while now. You could chop it as needed to get better documented section than ANHT was. Send me a mail if you want it anyway.

Haven't gotten deep enought into the code workings yet to help out otherwise.
Jp

AlexJH

There's room to do this in the $60 right now.

My plan is to write some code that does a couple of things:

- rpm window where the following things occur:
- 2d lut of rpm vs increased BPW
- 2d lut of rpm vs spark retard
- an unsed output goes high

Once I get a test bench set up things are going a bit faster, right now I'm just documenting a bunch of stuff... which reminds me, I need to send off an email to Grumpy in a couple of days.

junkcltr

iTrader: (1)

You might want to look into the Megasquirt with the Megasquirt 2 adapter. I think it is running Motorola 16 bit code that is compiled with GCC (written in C). It is a good open source compiler. I started looking into the Megasquirt for a two-stroke one cylinder engine......but got sidetracked with another LT1 intake build w/730 code.
I think the Megasquirt would be best for your application where you want to start from scratch.......open hardware & open software. It promotes a good learing environment. You could probably cut the 4 week beta time down to 2 weeks because many functions are already available for the Megasquirt. You will probably only have about 1 year of testing after that before you get 'release' code.
I don't see the point in starting software from scratch on hardware for the 80's and early 90's.
Overall, I think Grumpy's solution is the best. It fixes old hardware & software (good stuff to me) with a minimal amount of effort.
J

junkcltr

iTrader: (1)

The UltraMegasquirt is worth taking a look at. Good features....but not available yet. It shows that it is an active project.

J

Grumpy

How's it going?.

JP86SS

iTrader: (1)

Just wanted to point out that just increasing the data rate will not change the data you get out.
the variables are sampled at the loop rate and then spit out during the comm routine.
By just increasing the speed of the readout you will get the same data many times but STILL at the change rate of the loop that is changing the memory location. Total execution time would have to be reduced to see faster changes.
Seeing this may then allow you to then add resample or rerun the A/D routines several times within different loops to update the locations and give actual faster data.
Timing issues of doubling up the A/D routine could (or probably) will cause issues that will take time and testing to resolve.

IMHO You must plan for this and make the appropriate changes in the begining of your development to get the desired results.
I'm hopeful this can be done.
Jp

vernw

iTrader: (2)

How about providing for WB input and reporting in the ALDL stream? Use a lookup table for the AFR from the WB input voltages so both linear and non-linear WB's could be used....

Grim Reaper

Here is a post by Z69 on how to resolve the max injector PW on a large displacement/large injector engine.

https://www.thirdgen.org/techbb2/sho...hreadid=276420

funstick

sweet. thats a good fix. ill have to resort to that in the mean time. we are still wotrking towards our goal. weve gotta beta running in sims and its headed to the bench. itll probolay be like 2-3 months before its 100% tested and solid.