Just in case any of you guys use TC and GM/TunerPro as alternate bin editors, I just discovered a bug between the two. I have attached a .jpg showing the same bin in both programs. GMECM takes the change made in TC and forces it into the spaces it has allocated. Makes it difficult to know where the change really is. Depends on which program you are using to view the bin information. I have found the discrepancy to be in the $42 def involving the PE enable TPS% table. Haven't seen this type discrepancy anywhere else between the 2 programs.

Sorry if this is old territory.

Here's a further update. looking at the bin file in the EMP-10 bin editor, it appears that TunerCat is the application with the wrong data.

 

Can't seem to post 2 images in the same response, so here is the orginal comparison between TunerCat and GMECM.

 

Looks like one of the definitions has an error in the rpm scaling..
The hac that I have matches the tunerpro .ecu that you have.... but that doesn't mean its correct..
Ben.

 

Ben,

Looking at the bin thru a bin editor says that its TunerCat that is incorrect.

 

You'll probably have to consult a hack for that mask to figure out which axis breakdown to use. One is available on Moates's site.

If we are also talking about the .02 difference, thats a rounding error, and has to do with the fact that TunerPro shows 2 decimal places while TunerCat shows 1. Though 2 decimal places is technically more accurate, it comes out in the wash as bin items can only be incremented on the BYTE level, meaning 255 steps minimum.

Additionally, its not a bug in either piece of software, its a difference (read: bug) in the definition being used to edit the bin. The software just interprets the bin using the definition provided.

 

Mark,
Compare the rpm columns.....

 

Mangus - look at the RPM values....

 

vern/ben, reread my post (I actually edited it before either of you posted). =)

 

That's why you're so good!!!!!


By the way, I'm sending you a PM on a separate issue (private)....

 

Mark,

Sorry. Perhaps I am not understanding. I didn't discuss anything with the rounding error. The issue has to do with the same value that is in the 1600rpm bucket for TunerPro is in the 3200rpm bucket in TC. Maybe I should have used values that were much more disparate, but I made the change in TC to the 3200rpm slot and it showed up in the 1600rpm slot in TPro. When I checked using a hex editor, that value was indeed in the 1600rpm bucket, demonstrating that TunerCat was reading the bin incorrectly.

 

Hi Dominic -

I was just being complete. Yes, I see the issue with the axis labels. As far as determining which definition is correct (TunerPro or TunerCat), you'll have to consult the hack for that application and correct whichever is incorrect (depending on which is most important to you).

Mark

 

I just consulted the hac, and if this is the table found at $47D, then TunerCat is indeed using the wrong axis breakdown (TunerPro is correct). You may, however, have an outdated 42.TDF file. Contact TunerCat and see if there is a more recent one.

M

 

Mark,

Thanks for that further clarification. Indeed, it is the table located at $47D. I went directly to the hex information and determined that the value represented there was concsistent to what was being displayed in TunerPro. I happened to stumble onto the problem because I was settting my PE TPS% for tuning purposes. Some tables I find easier to modify in TC and TunerPro has many more table and constants not available in the standard $42 TDF.
So I'll swing from one to the other when doing a new bin. At first I thought I may have had too much to drink the night before , but then I checked them side by side. In any case, my professional career involves product management for enterprise software, so I wanted to make others aware of the discrepancy between the 2 applications in case they encountered the same problem. I will go to TC and download the latest TDF and see if that's fixed. Thanks again.

 

Good deal.

BTW - TunerPro has a nice built-in Hex Editor. Hit Ctrl-H. That should keep you out of the early 90's era DOS windows. :-D

 

Actually, both definition files are incorrect. Here are the proper RPM terms for each row (TPS% for WOT vs. RPM):

0
400
600
800
1600
2000
2400
3200
4000

These RPM terms are also the proper values for about a half-dozen other tables. The WOT AFR vs. RPM is another. Any table that uses the routine at LFDDA as the lookup uses these values (as a note: stock '7747 code).

RBob.

 

RBob -

Though I'm never in a position to doubt you, I should point out that both hacs that are available (that I could find anyway) publically show the axis breakdown found in the TunerPro screen above.

The zip file here contains two hack PDFs:

http://www.moates.net/files/5)%20Source%20Code%20and%20Hacks/42.zip

 

Mark,

Excellent. Thanks for the little tip!

 

Have to be careful of hacs. Many of them have errors. Even the ones I've done are not perfect.

Knowing that the scaling for the WOT AFR and TPS tables is a little strange, I edited a stock bin with some values that can not be misconstrued. I then ran up & down through the RPM range and noted the results.

One thing to watch for is that the RPM term in L001A is scaled. There is a break point where the scaling changes. This stuff drives me crazy. It becomes difficult to figure out what the actual table range is.

Here is the RPM scaling:

L001A: rpm / 12.5 & 25, brk @ 2400, start 400 rpm, limited to 4775

So what I did was to edit a stock '747 bin placing distinct AFR values in the WOT AFR vs. RPM table. Then benched it and recorded the results. Here are the AFR values I used:

The AFR values range from 5.0 to 13.0. On the bench the commanded AFR value while in PE was:

(hope I copied those over correctly ) I checked higher then 4000 RPM with no further change in AFR.

RBob.

{edit: too funny, my previous post has the RPM terms off, looking at the results again I have this:

400
600
800
1200
1600
2000
2400
3200
4000

Anybody agree? Didn't I say that scaling gets looney??}

 

Looks like it should be:

400
600
800
1200
1500 <--- (not 1600)
2000
2400
3200
4000

 

Benchs are nice like that aren't they .
Cool beans, so the hack is wrong, wow, you mean a human made a mistake .
I'm suprised the 7747 went that long with a mistake. That's a lot of human errors if nobody picked it up...
As for tunercat being wrong, it doesn't suprise me. He's been off on a bunch of stuff but he's offset it with releasing support for SO many masks. He isn't exactly a large group of generosity, it's one guy trying to do it all. He's got one of the best interface feelings but TunerPro is getting better. Looking forward to the all new release Mark.

 

Almost all of these tdfs and ecus probably have bugs in them. Nobodys perfect. The one for my 8063 had some bugs in it as well. This is where a good commented hac and bench come in handy.

 

RBob,

Are you saying the AFR vs RPM WOT table has a problem with it also?
Like any software, there's always some bugs you'll find.Nobody faults TC or anyone else for that. I just happened to find this one and thought I should let everyone else know. But that brings up a bigger issue. We have a large community here on TGO. Perhaps there should be some sort of consolidated reporting on known bugs for the software that we use. With the effort requiring for tuning, its pretty maddening to be making adjustments to the bin and not getting the results expected. And all the while it may be a software bug rather than something incorrect in the calibration.
Maybe there's a need for a "Sticky" on this forum for that listing and the status of those bugs?

 

Humans don't make mistakes. Computers do. :-D

Just kidding. Yes, plenty of errors in TDFs, ECUs, TunerPro, TunerCat, etc.

 

Good catch. It is 1600 rpm as I entered my data incorrectly. My post has been edited to reflect the real data.

RBob.

 

Yes, here is a list of tables that use that RPM scaling:

RBob.