TS AFR Gauge off

[Silverback]

I've tried a few different AFR gauages in TS (different gauge types as well as AFR 1 and AFR target) and I noticed that a readout doesn't match the gauge:

AFR_Gauge.PNG

This is one that I'm using in one of my TS dashes right now, with the AFR target in the middle gauge and the actual reading on the outside, and since the middle gauge covers the value of the outside gauge I also have a third, just readout on the bottom, and all of the readouts are consistently half a point lower than the needle: on the target gauge the needle reads 15.2 and the reading reads 14.7, on the AFR gauge the needle reads 12.5 and the readout reads 12. I have a second similar gauge that I made separately that I use with the autotune and it is also half a point off of what the readout says.

Is there a way to celebrate TS gauges???

[Silverback]

FWIW, I've been assuming that the readout and not the gauge is wrong (since I get the same readout on the value in one of the gauges as I get if I make a simple readout gauge) but if the readout was wrong and the gauge was right that would move in the direction that I'm seeing the error relative to the AEM gauge that I'm using that I posted in this thread:
http://www.msextra.com/forums/viewtopic ... 11#p405411
(but _I think_ the error is not as great as the difference, that is really hard to tell).

Secondly, I noticed that my gauge in TS seems to move significantly slower than the physical gauge when the physical gauge is changing quickly, like the physical gauge might show:
12.0, 12.1, 12.0, 12.2, 12.1, 12.0, 12.1
while TS shows:
12.0----------------------12.1---------------
(the TS gauge might move once while the physical one is swinging up and down a half a dozen times), though I'm wondering if this might be an averaging or lag setting somewhere...

[gruff511]

ive had the same issue. I have the mtx-l and my ts gauge has always been 1 whole point leaner then my actual gauge. ive tried changing volt signal and all but always seems to still read 1 point off

[Silverback]

I have another thread about it being off against the actual physical gauge. In this case if you look at my pic the TS gauge is different then the TS readout by .5

[LT401Vette]

This is one that I'm using in one of my TS dashes right now, with the AFR target in the middle gauge and the actual reading on the outside, and since the middle gauge covers the value of the outside gauge I also have a third, just readout on the bottom, and all of the readouts are consistently half a point lower than the needle: on the target gauge the needle reads 15.2 and the reading reads 14.7, on the AFR gauge the needle reads 12.5 and the readout reads 12

Sorry for the delayed response, I was away last week.

What do you mean by Actual reading? What OutputChannel's are you using for the gauge that reads different?

[Silverback]

Phil,

I mean that when I have my physical gauge reading and my AFR table calibration set so a simple readout matches, the needle on a gauge is .5 off.

Actually, don't even worry about my physical gauge (since I have another thread about my issues with the AEM UGEO which I will update soon)- look at the screen shot that I posted in my first post. Even the readout that is part of the gauge using the AFR 1 and AFR target gauges is .5 different then where the needle is pointing. I just used the default gauges from the pulldown, didn't mess with the output channel or anything.

Checking it, all the AFR gauges and readouts are using afr1 (I have a gauge, readout and graph on my main dash, a gauge and readout on my autotune dash), and the afr target gauges are using afrtrgt1 (I have one on my main dash and one in my autotune dash). All the readouts for both types of gauges are .5 off of where the needle points.

[Silverback]

again, look at the screenshot, the afr target readout shows 14.7 and the needle is pointing at 15.2 and the afr gauge readout is showing 12 and the needle on the gauge is showing 12.5

[Silverback]

Hello???

[jsmcortina]

I see what you are saying. The needle and numbers don't match up.

James

[LT401Vette]

Was it online here?

Can you post the dash?

[LT401Vette]

(the TS gauge might move once while the physical one is swinging up and down a half a dozen times), though I'm wondering if this might be an averaging or lag setting somewhere...

There is a smoothing on the needle, that does cause lag. The number is real time.
So if the screen shot was taken while there was a rapid change occurring to the gauge values the needle can lag behind.

You can turn of the smoothing in Designer Mode:
- Right Click on selected Gauges
- Select: Properties --> Needle Movement Smoothing --> None

[jsmcortina]

Was it online here?

Post #1.

James

[Silverback]

It was online, but the car wasn't running so the needle wasn't moving.

I've also tried just setting it in designer mode and giving them all the same value and I get the same results.

what do you mean by posting the dash, my .dash file? I attached the dash that i'm using during autotune that does the same thing...

[LT401Vette]

Yep, that is what I was looking for and it does demonstrate a problem.
Where you have the min on the gauge set to 10.5, TS seems to be using that as the start value when calculating the angle, however the number scale rounded that to 11. It is throwing off the angle to the proper reading.

If you change the Gauge min to the displayed 11, it reads as it should.

I'm very surprised this hasn't been noticed before. I guess there aren't that many gauges that start at a non-zero value and have such coarse numbering..

[nathanhardy]

Could this also be why my gauge reads delayed / off or doesnt match movement of my aem wb on ts

[LT401Vette]

This would only be responsible for the needle position relative to the actual displayed value.

If the min is set to a non-integer value, The Needle position is calculated from the integer position. The decimal places are lost on the gauge minimum when calculating the needle angle using an analog gauge.

The displayed number value is simply what it is, so that drift would be something else.