For those of you that are still burning proms in the earlier cars. There is a new tuning tool out there called GMPCM. Their website is:

www.gmpcm.com

However beware if you use this tool there are lots of errors in their tools. I tried it and compared it to other editing tools such as Winbin, Tuner Cat and the popular GMEDIT tool. I know these forementioned tools are accurate and work as I have used them personally. When I open a bin file and compare what I see with a known good tool to that of GMPCM, I find many descrepancies with their tool. Another Vette forum member and I questioned the author(s) of this tool and while I did get a few friendly replies communications have stopped.

There was some rather heated discussions on the Thirdgen forum over this and here are the links:

http://www.thirdgen.org/techbb2/show...hreadid=215831


http://www.thirdgen.org/techbb2/show...hreadid=216119

Just a warning about their software there are lots of deficiencies with it and personally I wouldn't trust it with my proms. In fact me and my Vette Forum friend are locked out of the GMPCM website! If any of you are interested in seeing this tool you can visit them at their website above.

 

We get about 10 emails a month from those that think posing as someone "thinkin about changing from TC to GMPCM" is likely to impress us into holding their own pissing match beauty contest for software. Its quite predictable, and we have little time for such nonsense. Our website illustrates the software’s features quite nicely. The results of your dishonesty are obvious, we no longer desire you to use our software or our website.

For those that want to find the real truth as to why the numbers are not the same between GMPCM and various other software packages, we challenge you to a little test.
Since the $42 definition is available in demos offered by other software, it would obviously be a good choice so that everyone can participate.

We have recently unlocked relative premium capability in our software's evaluation edition, so you can get a better idea of exactly how it performs in this test, but you will need the latest version of both the software and PCM file.

You can download our latest evaluation edition along with our 42.pcm definition that has over 400 areas mapped from the GMPCM website , but you will have to obtain the $42 binary files for this test here:

ftp://ftp.diy-efi.org/pub/gmecm/bin_lib/AMUR.BIN

ftp://ftp.diy-efi.org/pub/gmecm/bin_lib/AKUN.BIN

as our 500 file binary download database is no longer being offered free to the public.

"Import" the first binary file into the 42.pcm definition that you have opened with the software, and note the values in the "Main Spark Advance" table located in the "EST" section, particularly at low rpms as that is quite sufficient for this test.
Then load the second file and note that the values are approximately equal, just as one would expect.

Now do the same with the other software and note that there is at least a 4 degree difference in these low rpm areas alone!

The reason for this is that your highly proclaimed software is incapable of even calculating main spark table values correctly.
In fact, GMPCM is the only software on the market right now that can do this, as it does not rely on "static" values for its calculations. The PCM code does not, so why would any tuning software have a stupid limitation such as that.

And in the future, when we tell you that it is simply the fact that some features are disabled in the evaluation edition to protect our endeavors, I suggest you take it as fact rather than trying to bad mouth something you have not even paid for to find out exactly what the truths really are.
You are doing everyone here a disservice when you do this, and all because you are incapable of understanding a simple concept : It is not our software's values that are incorrect, it’s yours....

You may have even achieved some degree of tuning success with this other software, after all, a thousand monkeys on a thousand keyboards could probably produce decent results, but that still does not change the fact that the software you are using is defective.

We have numerous accounts of folks encountering detonation problems due to exactly this issue. The hilarious attempts by some "experts" to explain why the max spark advance constant value does not correlate with the table data in this "other" software are also quite enjoyable..

 

Someone is here encouraging people to visit your site and check out your product, even though he has had bad experiences with it and the customer service offered by your company, and you feel the need to come on here and slam him?
I don't think I'll be visiting your site or inquiring about your software.
Does TunerCat know that his software is garbage?

 

Oh please.. if that was how someone encourages visits to a site, then we can surely do without. The fact is he was disgruntled by the end result of his scrupulous activity, and is now trying to cause problems, as people of such morals typically do. He was also completely unreceptive to any explanation whatsoever, and he had obviously made his choice for tuning software long ago. Just another trouble maker, and we certainly do not need to waste our time dealing with that. But, we WILL set the record straight for the rest of you, and I believe we have every right to do so.

His post on the Corvette forum were quite a bit more obvious, but this is surely still something that anyone with average intelligence can see for exactly what it is.

I really do not know if other software vendors are aware of these issues, as that is really none of our business. There is a variety of software out there that exhibits failures with table calculation, as it all relys on the limitations of a static linear formula and in most cases they use nothing more than a factor conversion.

 

You're trying to tell me that Tunercat's software can't correctly calculate the main spark advance? Uh, just curious, but how much crack do you smoke every day? Anyone with a data logging program such as Freescan or DataMaster can easily verify the spark advance with just one data log. Guess what? It's exactly what it says in the Main Spark Advance tables of Tunercat for RPM and MAP readings. If you want my opinion (and I could care less if you want it or not, making claims that Tunercat is wrong is about as stupid as you can get), the reason why the files read different in Tunercat and not in your program is because there is a problem with your software, not his. I'm willing to bet a simple data log would prove this as well.

 

Fine, try asking anyone that actually knows GM binary code at the level we do, and I am sure they will be happy to tell you that there is much more to a spark advance table than a simple factor conversion.. There is also a big difference between telling somone about a flaw, and allowing them to prove it for themselves.

There are plenty of very intelligent folks that have questioned why the max spark advance setting does not correlate with the table values, as in many cases the stock table values will actually exceed this when they are calculated incorrectly.

GMPCM does not exhibit these problems, as it uses correct calculation methods, so a stock setting for the max advance constant value correlates with the stock advance table values quite nicely.

A scanner reading is really not a very relevant argument here. The values typically include other parameters such as spark retard, and readings from many ALDL scan devices are skewed by factors such as electrical interference and data acquisition speeds.

 

Explain how comparing these two calibrations would mean anything. For one the AMUR calibration in a $42 ECM is for a 350 CID G and R series truck with a automatic transmission while the AKUN calibration is for a CK series truck with a 454 CID engine and a automatic.

It would be like comparing apples and pears, while its the same ECM hardware the calibration for a 350 and 454 are considerably different, especially in the timing and VE maps between the two engines let alone most of the ECM constants. I would expect to see a totally different timing and VE maps between the two calibrations.

I use many tools for calibration not just TC but also several sharewares and some that costs thousands of dollars. Whatever tool suites the job best is what I use. I supose the next thing you will tell us is that the GM specified scan tools and service programming systems are worthless as well?

I found what appears to be errors in your software and as a developer that would want people to use your software you should be receptive to people telling you of errors or possible errors as many in this business are. Even the people that developed LT1 Edit and LS1 Edit whom I have spent thousands with are very receptive to problems that users find during their usage of their product. If it were not for the users of the later products their software would not have evolved to what it is now.

I work on process control projects that run into the hundreds of millions of dollars and beleive me when the end users finds faults in either firmware or software in these systems the vendors listen and listen well.

 

I thought most people figured this out a long time ago (at least common knowledge around here has been stating it for years). When you go to WOT, extra spark advance is added based on RPM. It can be 1 to 4 extra degrees. Again, this shows up on any data logging software. If your software shows this, great, just means you wrote it to include the extra spark advance added by WOT. Not really seeing how either way is correct or incorrect.

Not to mention the fact that this is not even what you originally claimed. Read your post, you claimed that the main spark advance in the lower RPM tables is incorrect. I can prove this isn't true, again with a data logger. Now you change it to max spark advance, which is explained by the very simple and accurate explaination above. Just curious, which is it?

[QUOTE]Originally posted by Mechanic
A scanner reading is really not a very relevant argument here. The values typically include other parameters such as spark retard, and readings from many ALDL scan devices are skewed by factors such as electrical interference and data acquisition speeds.
[QUOTE]

Sorry, but this is complete garbage in and of itself. A data logging program or hardware device is NOT going to be altered by any such factors. I can prove this on a dyno. And I already wonder why tjwong would give such a warning about your software.

[QUOTE]Originally posted by Mechanic
Fine, try asking anyone that actually knows GM binary code at the level we do, and I am sure they will be happy to tell you that there is much more to a spark advance table than a simple factor conversion.
[QUOTE]

You really don't sound like you know it all that well. I think I'll ask someone like Tunercat and see what he thinks. I'm willing to bet I'll get a much better and more accurate answer.

 

The point of illustration is, TC does use the correct formula for "certain" $42 binary files, but since they use a static "entry" rather than the result of a calculation based on a changing address value, it is NOT accurate for ALL $42 binary code.

TC does this out of necessity rather than choice, as their software does not have the ability to "precalculate" a segment of the formula used in calculating these values.
This results in inaccuracies of a magnitude that could cause engine damage in some of the situations encountered in tuning.

There are absolutely no disclaimers by TC that their 42.tdf file only applies to "certain" $42 applications. And the fact is, GMPCM correctly calculates the tables values for ALL $42 binary files.

This is just one example to prove that your so called observation was totally invalid, and yet you still don’t quite get it... right. There is obviously a lot more to your motives than you would like folks here to believe, but luckily I am sure they are more than capable of determining the truth for themselves.

 

Doom (or whatever your ego blanket screen name is), it is unlikely that you even own a 7.4 L V8 controlled by $42 code for you to "put a scanner on", so your points were obviously invalid and rather worthless right from the start.
Reading your posts a bit closer leaves much doubt that you could even comprehend what we are talking about here.

 

Curious as to why no one really bothers with your software. You insult people who try to point out problems with your software (tjwong would be first on the list), then you come on here with your pathetic attitude and insult other, respected software designers (such as Tunercat). My "ego blanket screen name" isn't really relevant here, but the fact that I'm a computer engineer who probably understands computer systems far better than you ever will leads me to believe that you know nothing. You are correct, I don't own a 7.4L V8 that uses the $42 code. If you look at my signature (you seem to lack the capabilities to read very well, or to properly form your thoughts into words), you'd see that I own a 94 Z28 with the 350 LT1. But since I do tuning on many different cars and trucks at a dyno shop, I already know what you have to say is incorrect. Really not a surprise there. You've already contradicted yourself more than once in this little contest, I don't think I need to say any more. Next time, try not insulting other people's work and knowledge and actually know who you are talking to before you start would be a good idea too. I can guarantee that the board members who are reading this and not joining in already know what to think about you and your vaunted software. It's people like you don't need to be bothering with this business. Like tjwong, I use the equipment and software that is best suited for the job. I doubt your software will EVER even come close to that catagory. Mr. Mechanic No wonder you are currently "On Probation" over at the Third Gen forum, you look like a lazy SOB that has minimal knowledge about things and likes to make claims for a lot of stuff you can't do. I'm not going to accuse you of anything else, because the last thing I need to is deal with your ignorance and cause more trouble for myself than I need. However, I will certainly be bringing you to the attention of the board administrators here, as the last thing we need is someone like you on this site.

 

I am going to lock this thread, but I'd like to say a piece first.

I just looked over your GMPCM web site, and just by reading about the features, it does look like a nice software package.

I agree with what Mechanic states above - sometimes spark advance in the table doesn't match what appears on the scan tool (seen this with my own LT1), and scan tools / ALDL *always* lags the data (a snapshot is never 100% dead nuts accurate - the ECM has to grab the data, register by register, packetize it, and transmit it down the wire at 8192 baud - it's not a "instantaneous" snapshot of all sensors at one exact moment in time, but a sequential snapshot of a near-moment, and then store-and-foreward - if that makes sense ).

But, what I don't appreciate is Mechanic's hyper-paranoid attitude. No, the world is not out to get you. Thomas came on here, expressed his opinion, and let folks here know about your site. I for one have never heard of your tuner before. Tho I'm not involved in the world of GMECM's as much as I used to be, that honestly did surprise me a little.

If your comments were more constructive, and not so condescending, then this post would not be locked. Don't come on here and thrash around like a rabid paranoid dog, lobbing insults at anyone who posts. You'll gain a lot more respect if you reply in a more reasonable manner. Your technical answers to Thomas' concerns were good, but your attitude, frankly, stinks. Be a little more open (remember, this is a public forum, and your 'business face' is what you write), and you may just gain some customers here. Every editor has to go through its growing pain stages.

Edit... I notice your web site is based out of UT, and I know that Terry Kelley was out of UT... is this software an extension of GMEpro? Just wondering...

Regards,

Andrew