RBob

iTrader: (1)

The patches to extend the upper VE table to 6,400 RPM has been uploaded to Moates site: www.moates.net/fileman

It is named: 8D_VE.ZIP

Includes a patch for each AXCN and AUJP. I also threw in the s19_pat utility so you don't have to search that out. The difference between the two patches is the code location that gets hooked into.

Don't forget that the new extended VE table is in a different location. So change your ecu or tdf file so that you edit the correct table. And add the additional rows. The VE values in the patch are the stock AXCN values.

RBob.

TRAXION

Wow. Cool!

Curious though ... why stop at 6400rpms? Why not take it out to 7000????

Tim

TRAXION

1) Would it be OK to incorporate this into the S_AUJP file?
2) Do you overwrite addresses currently used by Mike Davis' wideband hac (yes, I can check myself but I just wanted to ask in case you have a quick answer).

Tim

RBob

iTrader: (1)

Going beyond 6,400 RPM would entail creating another RPM term. Using the current RPM/25 term only allows up to 6,400 RPM.

The next step would be to create something like a RPM/37.5 term (good to 9,600 RPM), or maybe a RPM/30 term (good to 7,700 RPM). Depending upon the math it may be easier to use some other multiplier (RPM/33, RPM/32. . . ) .

Then again, might be best to create an offset RPM/25 term. IOW, it starts at 6,400 RPM (term value of 0), and goes to 12,800 RPM (term value of 255). Then can make a VE3 table that starts at 6,400 RPM and continues to say 8,000 - 9,000 RPM or so.

Can then use that same offset RPM term for any other additional tables. . .

RBob.

RBob

iTrader: (1)

1) Yes, just move the credit/copyright with it.

2) I don't know. If he used the open area starting at $9000 then yes. Look for were the new table goes.

RBob.

TRAXION

1) The RPM/25 explains a lot. More than what you just said ... it made some other stuff hit home. Thanks!

2) Understood on the credit thing. I wouldn't have it any other way. I'll do this when time allows.

3) I just did a full binary compare of an AUJP with the extended VE Mod vs. an AUJP plus Mike's WB Mod. The mods do NOT interfere. That's awesome news!

Thanks again!

Tim

Grumpy

Hmm, so you seem to be saying here that at least to you it's worth the work to have resolution out to 6,400 for some applications.
Hmmm, and the easy way here would have been just using a VE adder table, that continued out that far.

Guess there is an advantage to getting to be able to modify code.

A WB option, expanded resolution, the mind she boggles......

RBob

iTrader: (1)

As for an adder table, it actually is more work. This is because two lookups need to be done and then the results added together. In the case of $8D it is a simple matter of just extending the table.

I've always felt that the code is where it is at. The ability to add/remove functionality is paramount. I know that Grumpy knows this, so I state it for the others that may be on the fence.

I look at the ECM software (really firmware as it is in a non-volatile device) as a means to an end. I make changes to it as required to get the best in drivability and tuning.

As it is some code changes are easy, others difficult. A test bench allows one to test and play with the changes first (and no smoke filled garages. . .).

I've made so many changes to the original code that it isn't even close to being the same. I'll even borrow code from other masks if they provide functionality that can be used. All in all being able to change the code opens up an whole new experience in the ability to get an engine to run.

RBob.

1bad91Z

iTrader: (1)

Forgive my ignorance, but what is the point of making a VE table that goes to such a high rpm?

Shouldn't you be in PE when the r's are that high?

Is the purpose of doing this to eliminate PE fueling and just run off the VE tables?

RBob

iTrader: (1)

It all comes down to engine requirements. In one case I have an engine that typically goes to 6,000 - 6,100 RPM. The VE really starts to drop off starting at 5,800 RPM. It is nice to be able to control the fueling.

Someone else I know runs their engine to 7,300 - 7,400 RPM before shifting.

In the past I have brought up the same point of how much does the VE change between 5,600 RPM and 6,400 RPM. Based on that can one make a decision as to whether extended tables are needed.

I don't like to rely on PE to get the fueling correct as the engine may not be in PE at that RPM. In lower gears it is easy to run the r's up without entering PE. It really comes down to tuner preference.

Would I do this for a stock L98 or LG4, not really. Just isn't required.

RBob.

funstick

rbob i had started an idea just before diy efi went down. I geuss il bring it up here. Im not the worlds best coder. no secret there. but i did have an idea and id like to share it. I think its about time that we started from scratch and wrote fresh code or gm based code that did everything. i mean everything. theres no reaso it cant be done. hell im not even sure anymore that i wouldnt be able to do it with enough time. If somebody is willing to step up and coach me ill start pulling all the good snipets for stuff like boost etc. i think it would be awesome to have an all purpose code that could run every odb1 car out there. Think of the possiabilitys of that. !

dimented24x7

iTrader: (2)

One question I had is can the ecm physically resolve to any degree of accuracy out to those rpms? The distributer reference pulse counts look as though they get kinda Asymptotic (is taht the word?) past around 4k or so. It seems like any biases or errors that are inherent to the system will tend to skew things a bit. Ive put together some proto-code to extend the base VE/ timing table(s) out past the limit to 6400 rpm but could I get any degree of accuracy for an engine that actually needed to rev that high? Not that I plan on doing anything that will go much past 5500 rpm or so but non the less Im still curious.

TRAXION

No offense but ... we couldn't even get people to do code for the Super AUJP thread. No way you're going to get people to participate in writing an entire ECM operating system.

Tim

RBob

iTrader: (1)

Interesting question, I was reluctant to touch it the last time it was asked. However, new data arrives daily. I too have wondered about how good are these ECMs at higher RPMs. Looking at data logs the RPM will jump up & down even as the engine is gaining RPM. Kinda of makes one wonder.

Recently had a setup in the shop to scope out some distributor/ECM ignition system signals. One test I made was to check the timing jitter at 6,000 RPM. Using a function generator to provide the DRP pulse I found that the EST signal would bounce around by a tad more then 30 usec. And it was a step change, it would be +15 usec, or 0 usec, or -15 usec. Huh, thats strange.

Then the light bulb lite up. The internal counters have a single bit timing of 15.26 usecs. There it is, +- one bit time. Not too shabby. So, now why is it the data logs show such large variations in RPM? The RPM is calculated from the same signal (DRP) as above.

My guess is that it is all mechnical variation. Timing chain motion, cam twist, basklash in the distributor/cam gears, even maybe the reluctor pickup.

There are also rounding errors in the RPM calculation math. The RPM math is 16 bit with the RPM terms stored as 8 bit values. A single bit change in the RPM/25 term is 25 RPM. So +- 1 bit is +- 25 RPM, or a 50 RPM varience. If extending the VE/SA tables to 6,400 or 7,700 RPM, a +- 50 RPM error compared to a change of 800 or 2,100 RPM (added length of extended tables) is 6.25% to 2.4%.

In closing I am of the thought that by putting as much functionality into the code the tuner is not constrained. I'd rather have a table that goes beyond the required bounds then be constrained by a table that is too limited.

RBob.

Grumpy

You were by no means the first with that idea. I'd been brought up many times before, and the *best* way seemed to hint at making it modular, so only the sections one needed would be patched together.

I've been pushing for years on just getting commented source code, and you want an entire system?. Don't hold you breath, on either.

Heck can't even get folks to agree on what to even look at. The 58 is the answer for generating a *united* front, but folks won't even agree on that. <sigh>

RBob

iTrader: (1)

Did you know that if you resize the window while at the post preview screen all the good stuff you typed in goes away? Well, now I know that too. . .

As they say, 'Watch This Space'.

RBob.

SATURN5

I can't fathom the hours you've put in..

BW (watching this space)

RBob

iTrader: (1)

Part 2 (second attempt. .). Please note that the tests described within were done on a 7747/8746 C3 ECM.

Back in the shop I used the ECM bench with the function generator providing the DRP. This gave a solid time base in order to analyze the internal ECM accuracy. I used a hardware device to capture the ECM RAM at a rate of 17 times a second. This provided the RPM/25 term as calculated by the ECM.

With the RPM set to 2950, the ECM reported 2950 RPM. It was solid as a rock at that RPM.

At 6000 RPM from time to time the reported RPM would be 6025. A +25 RPM error.

When set to 6225 RPM from time to time the RPM would report at 6250. A + 25 RPM error. The RPM/25 term was also reported as 6175 RPM, a -50 RPM error. This only occurred a couple of times.

This test was done to prove out the ECM hardware. That there isn't more then the expected +- one bit of inaccuracy. Even at low engine speeds data logs will show a bouncing RPM. I attribute this to mechanical noise as I previously posted.

The ECM counter resolution is 15.26 usec per bit and is a sixteen bit counter. The RPM is calculated by counting the number of 15.26 usec counts between DRP pulses. For an 8 cylinder the math becomes: RPM = 983040 / counts.

At 3006 RPM there are 327 counts between pulses.
One less count for 326 counts is 3015.5 RPM. A difference of 9.5 RPM. So even a +- one bit change won't affect the RPM/25 term.

Lets try this at ca. 6106 RPM. This is 161 counts (6105.84 RPM). One less count (160) is 6144 RPM. A difference of 38 RPM. In this case +- one counter bit will change the RPM/25 term.

So the RPM jitter seen in the data logs at 6225 RPM is not surprising.

159 counts is 6182.6 RPM
158 counts is 6221.8 RPM
157 counts is 6261.4 RPM

With a ca 40 RPM change per bit As shown a +- count of one bit will show up in the RPM/25 term.

And at ca. 7000 RPM:

139 counts is 7072.2 RPM
138 counts is 7123.5 RPM

A difference of 51 RPM.

Back to the original question of whether the ECM can accurately resolve the RPM in order to be useful, it also depends upon the data.

If the data from 6400 RPM through 7000 RPM looks like a cliff, then no maybe not. There would be too much of a change in the result between lookups due to the +- one bit time jitter.

If the data is gently sloped then yes I believe that the accuracy of the RPM is good enough.

As for extending tables such as the VE & SA out to higher RPMs. . . Once done it is then up to the tuner to decide what data to load into the tables. I am of the thought that it is better to have more then needed so not to be constrained by a limited table size.

Here is something interesting. Directly from a live data log at a steady engine speed:

At a low RPM of 1550 there is a +- variation of 25 RPM. From the bench test I did today I would state that varience is from mechanical noise. Maybe a good reason to go with a crank trigger.

RBob.

dimented24x7

iTrader: (2)

Hmmm... The resolution of the ecm is better then I thought it would be. +/- one bit is pretty good resolution in my book. Its interesting to see that the mechanical noise in the system seems to be more of a limiting factor at most rpms then that from the ecm.

RBob

iTrader: (1)

A short part 3. While out working on the Elky I thought that it would be good to log the actual DRP counter value. This eliminates the actual RPM calculation & resultant rounding errors in the math. So after running the ECM and function generator for over an hour to warm them up for good stability I did just that.

It was as good as it can get. The maximum error was +- 1 count. When set to 122 counts (8057.7 RPM) the DRP counts varied by no more then +- 1 count. If the function generator frequency is set just right the DRP counter will bounce between 122 & 121 counts.

I found this to be true for whatever speed it was set to (at least up to 15,000 RPM, ~65 counts). So it looks like the ECM hardware is actually decent in it's ability to accurately measure RPM. And a lowly C3 at that.

RBob.

dimented24x7

iTrader: (2)

Well, there it is. Ive seen all these people wanting to spin out to 7000 rpm and ive always wondered how bad the resolution would be. Theres a little bit error, but not nearly as much as I would have thought.

Grumpy

Available at a junkyard near you, for $50.

Is anyone else as awe stuck like me about what a deal the GM ecms are?. Millions and millions in research, and so many were/are being used that we can get them for next to nothing.

IRACE87

I want to thank RBob for making this patch available, there is no way I can do things like that on my own.

But sorry for my lack of knowledge I don't know how to apply the patch to my bin, from what I see the S19_pat program need to be use but I have no idea what I'm suppose to do with it.

Sorry if it's basic stuff but I need someone to show me the way to do it.

Thanks

PAT

RBob

iTrader: (1)

See the 8D_VE.TXT file included with the patches. Run the s19_pat program under DOS or in a DOS window with the command line as shown in the txt file. Just be sure to use the correct patch, AND patch a copy of the original bin.

RBob.

nape

iTrader: (1)

RBob: I wouldn't want to spin my motor to 6400 with the stock TPI, but I applied the patch to a bin to see what it did.

After I applied the patch, the 6000 row in my VE upper table is low values starting with 0.00 at 20kPa and going up in small increments from there. Is this normal? I just wanted to make sure I applied the patch correctly just incase I build a motor that will rev that high.

TIA.

IRACE87

Quote:

See the 8D_VE.TXT file included with the patches. Run the s19_pat program under DOS or in a DOS window with the command line as shown in the txt file. Just be sure to use the correct patch, AND patch a copy of the original bin.

I'm sure I'm doing something wrong...

1. I opened your Zip file and double clicked on s19_pat.

2. From there I put (s19_pat axcn_ve.s19 0x8000 File2Patch.bin) in the command line space in place of what is already there.

3. The other lines under command line I'm not sure what I'm suppose to do with them. (can't tell you the exact title of those line because my computer programs are in french) something like working repertory and command files.

4. Anyway whatever I do the only thing I managed to get is a short cut that appears in the Zip file for MS-DOS with no link ???

5. And if I ever managed to get it to work will I see the extended table with tunercat ?

Again sorry for all those basic questions

Thanks

PAT

PLANT PROTECTION

iTrader: (6)

All the values from 5600 - 6400 should be the same, keep in mind the table has moved.

RBob

iTrader: (1)

In the command line portion the entry 'File2Patch.bin' needs to be changed to the name of the bin file you want to patch.

Can you open a DOS window in the OS you are using? If so do that and then cd into the directory with the bin file that you want to patch in it.

Then type in the command line: s19_pat axcn_ve.s19 0x8000 BinFile2Patch.bin

In order to use the new table the tdf file will need to be edited. This is because the new larger VE table is in a different area of the bin, and it is larger.

RBob.