Defect in the HPT scanner histograms?

[Steve@HPE]

One thing we've noticed is if you're using a VE-AFR Error histogram to tune VE tables, you have to smooth the adjusted area before performing another scan-adjustment cycle. Otherwise the HPT scanner generates AFR error percentages that are incorrect for the cell to which it's reported.

My theory is that the OS must use an averaging calculation for MAP readings that fall between VE table axis values, so if there’s a spike in one of the averaged cells it calculates a value that’s incorrect for the cell to which it’s reported in the histogram.

For example, let’s say the PCM gets a MAP reading of 93kPa, it would use the average of the VE values from columns 90kPa and 95kPa in the VE table, but HP Tuners reports the AFR error in the 95 kPa cell of the histogram (it chooses the closest column; 93 is closer to 95 than 90). Suppose there was spike value of 1000 in the 95kPa cell and the 90kPa cell had a value of 500, the PCM would calculate an average of 750 for the 93kPa reading. Which is 25% lower than the value in the cell to which HPT assigns the AFR error percentage. So, if the AFR error percentage is 12% at 93 kPa, HPT assigns 12% to the 95kPa column in the histogram. The problem is that that column already has a VE value 25% higher than the calculated average!

I would expect the HPT scanner to either,

1) Not report AFR error values to a cell unless the scanned MAP value is within 1-3% of that column value.
2) Adjust the AFR error such that its proportional to the difference between the cells in proportion to the scanned MAP value.

Hopefully that makes sense to someone there at HPT and they can confirm or deny this is an issue.

[Bill@HPTuners]

You are correct, the software plots the info as it comes in, however you have control over filters and can filter the information as you see fit.

[Steve@HPE]

You are correct, the software plots the info as it comes in, however you have control over filters and can filter the information as you see fit.

Thanks Bill. So what you're suggesting it that a large filter along the lines of the following?

[SENS.30]<40 AND [SENS.30]>40 AND [SENS.30]<45 AND [SENS.30]>45.....

[Bill@HPTuners]

I'm not sure what type of filter I'd use in this instance, I've never come across such a huge difference so it would be virgin territory for me. All I can say is the software only knows what its told, theres really nothing more we can do with the information.

[DSteck]

If you aren't hand smoothing the VE table after applying error adjustments, then you deserve to struggle with this. It is the nature of a histogram. Think about how much data would get throw out of they filtered down to 3% of a breakpoint. This is why I collect hundreds of hits for a given cell if I have the ability to.

If you want to make it more precise, add more breakpoints to the histogram. Instead of 50, 55, 60... Go 50, 52.5, 55, 57.5, 60... Then, copy with labels and paste the error in the editor.

[Steve@HPE]

If you aren't hand smoothing the VE table after applying error adjustments, then you deserve to struggle with this. It is the nature of a histogram. Think about how much data would get throw out of they filtered down to 3% of a breakpoint. This is why I collect hundreds of hits for a given cell if I have the ability to.

If you want to make it more precise, add more breakpoints to the histogram. Instead of 50, 55, 60... Go 50, 52.5, 55, 57.5, 60... Then, copy with labels and paste the error in the editor.

Can't say that I disagree, but I'm sure you're aware of how long it can take to get hundreds of hits in each VE cell.

In this situation the tool should error on the side of providing accurate results and give the user the option of loosening that accuracy. I imagine there are many people that assume an AFR error reported at 95kPa actually occurred at 95kPa.

[DSteck]

What people assume as far as how things should work isn't really the software designer's responsibility. It works the way they set it up, and people should be cognizant of that.

If you do what I mentioned about adding break points to the histogram, it'll narrow your sampling for a cell. I'd hardly call this a defect in HPT's software though.

[stan]

If you copy and paste with labels to your editor directly does it throw out the 52.5, 57.5, etc columns and then only paste the errors of the std 50, 55, 60 columns??? Or do you have to paste to an excell sheet first and delete the odd columns first before copying to your editor???

[DSteck]

If you copy and paste with labels to your editor directly does it throw out the 52.5, 57.5, etc columns and then only paste the errors of the std 50, 55, 60 columns??? Or do you have to paste to an excell sheet first and delete the odd columns first before copying to your editor???

Throws out the data.

[stan]

Thats cool. Learned something today. Probably work other places as well.

[Mez]

HP Tuners has it correct. I like the data reported in the cells it sees it. I don't want s system that I have to figure out how the programmer interpreted that data.

I believe the same logic applies to the knock retard table too.

This is why some guys copy/paste the error and hit smooth once.

[Steve@HPE]

HP Tuners has it correct. I like the data reported in the cells it sees it. I don't want s system that I have to figure out how the programmer interpreted that data.

I believe the same logic applies to the knock retard table too.

This is why some guys copy/paste the error and hit smooth once.

Actually HPT is not reporting only the values for cells on the histogram. It's rounding up/down to the closest cell and placing the value there.

[DSteck]

Yea, that's how a histogram works. Lol.

Probability and Statistics 101.

[Steve@HPE]

Yea, that's how a histogram works. Lol.

Probability and Statistics 101.

Darn! I thought I had finally found a forum without a condescending know-it-all making fun of people. The search continues!

Yes, this is how histograms are supposed to work but from a practical standpoint it can cause problems for people that do not understand how the data is distributed. Several tuning learning packages say to use the histogram data and apply the corrections to the calibration table directly from it. With no mention of smoothing or why it's needed.

[carlrx7]

did you try your large filter? I'd just increase the resolution of the historgram like dsteck mentioned. make a seperate config with table resolutions, aka idle 20,21,22,

but remember, rpm also runs up and down the table as well. soooooooo, depending on the bits logged, you might miss that rpm number all together.

-Carl

[DSteck]

Darn! I thought I had finally found a forum without a condescending know-it-all making fun of people. The search continues!

Yes, this is how histograms are supposed to work but from a practical standpoint it can cause problems for people that do not understand how the data is distributed. Several tuning learning packages say to use the histogram data and apply the corrections to the calibration table directly from it. With no mention of smoothing or why it's needed.

I told you how to change it to do what you want, and that wasn't good enough. Don't know what else to tell you.

There's nothing wrong with how HPT's histogram works. Just because a tuning guide written by some guy says to do X doesn't mean they are telling people the right way to do something.

[MikeOD]

So...in essence, you want the software to ONLY record information when you're at that exact RPM, and that exact KPA? You realize that it'd be basically impossible to collect any data in order to tune from if you did that right?...so then your thought process is "no I guess it'd need to have a certain RPM hysteresis around the target, and a certain KPA hysteresis around the target when the data is considered acceptable for that cell"...right?...so then you have to decide what that hysteresis needs to be right?...so then you start to look more and more into tuning different combinations, and you realize that that hysteresis is a moving target depending on the combo you're tuning...right?...so then after that, maybe you look at the software and say "yeah I guess it makes sense that the software engineers decided that when I'm more than halfway between these 2 cells, I log into this one, and when I'm less than halfway I log into the other one, and it takes an average"...right?...after that is when I said to myself "if I need to be more specific about what data is good and what data is bad, I'll just introduce extra cells around those areas, like Dave already explained, so that I only collect what I want...which is probably different than what every other person using this software on every other combo, that isn't my combo, wants to do"...make sense?