[diagnostic_dog]

So I measured the temp gauge input pin voltage on the MR2 ECU last night at 5,10,20,30,50,70,90,100,110,120 degrees C. Then I've tweaked an ax2+bx+c curve to line up best as I can.

Then I have done some algebra to make the a formula solved for T from V instead, thus will convert measured voltage into temperature. But math/algebra etc isn't my thing - I have no further/higher education etc. If anyone points out better ways etc I'd be grateful for the school lesson.

 

[MerryFrankster]

In general, the resistance of the sensor versus temperature follows a standard formula for a thermistor. The voltage is derived from that and it depends on the characteristics of the measurement circuit. If you wanted maximum accuracy you would take the voltage, derive the resistance, and from that derive the temperature. There is a decent description of a temperature measurement circuit in this link:

How to Measure Temperature with an NTC Thermistor

This project goes over the basics of thermistors and shows you how to program an Arduino to measure its data.

www.digikey.com

You can also refer to the factory service manual characterization of the temperature measurement circuit (attached).

If I understand correctly what you are doing, you are wanting to take the voltage from the ECT sensor circuit, feed that into the Arduino, so it can calculate a temperature, and send data over BEAN to the cluster to operate the temperature gauge in the cluster. Is this correct?

We don't know what the ECU is sending to the cluster at a given temperature. And we don't know the response characteristics of the gauge in the cluster, i.e. what does it display for a given input.

I would say that the curve that you have temperature versus voltage is accurate enough for operating the temperature gauge in the cluster, which is not a precision device. However if you want the gauge to function as expected, you need to figure out what is the cluster taking as an input proxy for temperature, and how does that gauge respond to that.

 

[diagnostic_dog]

Yes you have hit the nail on the head. This is just for the gauge. Pulling direct from the temp sensor input pin on the ecu.
I've read all the factory PDF's etc. There is nice graphs for two other thermistors (intake air and aircon) but not the one for the coolant.

The proper way to do it is with the Steinhart-Hart formula which describes the thermistor curve but it is alot of maths and calibration for just a wonky gauge.

I have been studying the gauge It lies, and it lies a hell of a lot!

It comes off the floor and points to the bottom marker at 50'c
Then it comes up to the half way point in a linear fashion till 85'c
Then it stays at half way all the way to 109'c
Then at 110'c it shoots up to the max point.

It ain't no "temperature gauge", it's a cold / normal / boiling over indicator with a needle.

The BEAN is basically an 8 bit hex value for temperature. It goes from 57-255 (39 - FF) so i covers 198 steps, 1 degree per step. -39' to 159'

The arduino has 5v analogue input that it converts to 0-1023 thus 0.00488 steps

So if we forget volts, and forget centigrade.... what I really need is arduino ADC steps to BEAN hex value super simple crude fomula, or maybe an array/table.

After all, my short term goal right now is a Corolla ECU, running the MR2, with a working "temp gauge", charge light and oil pressure light.

 

[diagnostic_dog]

So after some spreadsheet fun, I've come up with a very simple conversion from Volts to BEAN temp value.
Its not perfect by a far stretch. It under reads upto about 80'c, then it over reads a bit.
But the wonky Toyota gauge of lies won't show any difference.
It'll appear like the car takes marginally longer to warm up.
But it'll zing up to the top if you overheat. just like it does.

BEAN = 72000 / (ADC + 350)

Volts​	Temp ‘C​	Arduino ADC​	BEAN Value Accurate​	Crude BEAN Value​
3.1​	6​	634​	99​	77​
3​	8​	613​	101​	78​
2.9​	10​	593​	103​	80​
2.8​	12​	572​	105​	82​
2.7​	14​	552​	107​	84​
2.6​	16​	531​	109​	86​
2.5​	19​	511​	112​	88​
2.4​	21​	491​	114​	91​
2.3​	23​	470​	116​	93​
2.2​	26​	450​	119​	95​
2.1​	28​	429​	121​	98​
2​	31​	409​	124​	101​
1.9​	33​	388​	126​	104​
1.8​	36​	368​	129​	107​
1.7​	39​	347​	132​	110​
1.6​	42​	327​	135​	114​
1.5​	45​	306​	138​	118​
1.4​	48​	286​	141​	122​
1.3​	51​	265​	144​	126​
1.2​	54​	245​	147​	131​
1.1​	58​	224​	151​	136​
1​	61​	204​	154​	142​
0.9​	65​	183​	158​	147​
0.8​	70​	163​	163​	154​
0.7​	74​	142​	167​	161​
0.6​	79​	122​	172​	169​
0.5​	85​	101​	178​	177​
0.4​	92​	81​	185​	187​
0.3​	100​	60​	193​	197​
0.2​	114​	40​	207​	209​

 

[MerryFrankster]

It ain't no "temperature gauge", it's a cold / normal / boiling over indicator with a needle.

Yes, exactly. This is true of every cluster temperature gauge on every car. This is what I meant by the response of the gauge to the ECU input.

 

[rmeller]

It comes off the floor and points to the bottom marker at 50'c
Then it comes up to the half way point in a linear fashion till 85'c
Then it stays at half way all the way to 109'c
Then at 110'c it shoots up to the max point.

It ain't no "temperature gauge", it's a cold / normal / boiling over indicator with a needle.

Yes! The gauge has a deadband covering normal operating temperatures. All temp gauges from Toyota do this. With a digital controller this is simple to do. When the gauges were analog, I imagine that there was some fancy mechanical engineering involved. I am assuming that it is done this way because a fluctuating temperature gauge tended to generate anxiety in the consumer.

 

[MerryFrankster]

Here's a potential issue: If you split the ECT sensor signal, by routing it to the Arduino, you will change the voltage being detected at the ECU, and the temperature measurement will be off. Usually in situations where people are adding a standalone ECU, this is managed by adding a second temperature sensor. I would take a look at how the Corolla ECU communicates its temperature reading to the Corolla cluster. If it's an anolog circuit then maybe there is a possibility of getting a temperature signal from there to send to the Arduino, leaving the engine coolant temperature sensor circuit unmolested.

 

[diagnostic_dog]

I have already thought about this. With the arduino there is no pull up or pull down resistors on the analogue input pins. They are very very very high impedance, they draw next to zero current.

I took the corolla ECU apart and examined its input circuitry, they use a 2.7k ohm pull up resistor to 5v.

Adding the arduino will not effect the voltage from the factory temp sensor... well it will really buy only by like 0.000001v

If you try doing this with an aftermarket ECU tagged onto the same temp sensor as the factory ECU, the pull up / pull down resistors inside the ECU's will fight with each other.

 

[rmeller]

...I took the corolla ECU apart and examined its input circuitry, they use a 2.7k ohm pull up resistor to 5v....If you try doing this with an aftermarket ECU tagged onto the same temp sensor as the factory ECU, the pull up / pull down resistors inside the ECU's will fight with each other.

The 2.7k resistor sets the scale of the sensor. It creates a voltage divider along with the thermistor. So, indeed, you only want one of those resistors in the circuit.

 

[diagnostic_dog]

This is how wonkey the temp gauge really is....

 

[MerryFrankster]

I would have expected to go past mid-point before it hit 220. There is possibly a lag in the function of the needle. Anyway this is more or less normal if you have ever compared a cluster gauge display with a real temp gauge or with the OBD2 temp readings. Nice work with the BEAN and gauge side by side video, pretty cool to see that.

 

[diagnostic_dog]

I've bought a spare cluster with connectors/pigtails, then I've made a little test harness with that BEAN Arduino board I made last week sticky padded on the back. All with a handy DC jack on it for a 12v plug in the wall power supply. Thus I can sit here in the house experimenting with how the cluster functions. For example, if you do not update the temp gauge, after about 7 seconds the needle drops to cold. And you have to update the warning light status about every 20 seconds. My C++ is getting semi functional with practice. I can't seem to get any aircon packets out of this cluster, maybe it needs the engine ECU to say the engine is running before it will broadcast the "aircon demand on" packets.

 

[MerryFrankster]

You are earning your "mad sceintist" badge. LOL.

 

[diagnostic_dog]

It probably would have been cheaper and far easier to just buy an after mark ECU, but whats the fun in that!

 

[diagnostic_dog]

I've added the 2 wire Knock sensor in.
UK MR2 does not have the vapour pressure sensor on the fuel tank, I've just put a couple of resisters to trick into measuring atmospheric pressure.
And I have been lent a Manual gearbox ecu.
So now, even after a 20 minute "spirited" and relaxed drive I get this:-

No engine warning light
And when I scan it I get.....

So 100 million percent, the MR2 can run on this re-programmable Corolla ECU.

And since I no longer get the Knock Sensor fault codes, I now get full MR2 style power as the ignition timing is back to life (goes fully retarded on a knock fault code).

Although the party is strong and proper, it is an early finish party, as the rev limiter is very much 6500rpm, thus the first thing we need to fix is those rev limiter values in this flash, the manual flash, the ground zero of MR2 1zz-fe tuning on OEM hardware....

 

[evilthorne]

I’ve sent off the 03-04 matrix 1zz manual ECM and a bonus 04 matrix xrs 2zz manual ECM for you to add to your massive collection.

 

[MerryFrankster]

I am not familiar with this particular generation of code. However, from later generations, the rev limiter takes the form

N1 N1

Where N1 is an integer repeated. Viewed as decimal in 16-bit, a rev limiter of 6500 (for example, 2gr-fe camry) would look like

08320 08320

So there is a scaling factor of 0.78125 ie 100/128 that makes this

6500 6500

I did not find this sequence in the Corolla code HOWEVER on quick inspection I did find

08224 08224 (16-bit decimal)
6425 6425 (scaled by 0.78125)

at several different locations in the code This is consistent with 2GR versions where the rev limiter appears repeated in several locations but only one of them is the actual operative rev limiter.

How you determine which one is you change each in turn and flash it in and test it until the rev limit changes on test.

So where we have this sequence is
0x00498
0x01C24 (maybe not this one, it looks like it might be in the middle of another map)
0x042B0 (maybe not this one, it looks like it might be in the middle of another map)
0x042C0 (maybe not this one, it looks like it might be in the middle of another map)
0x04308
0x0545E
0x3FFF8

Hope this helps. If all else fiels buy the definition from bitedit - if still available.

 

[MerryFrankster]

Ha! I see that you found my other thread comments on flashing the ECU.

 

[diagnostic_dog]

Yeah, as always when you start searching it turns out there is always the same usernames who have any correct factual information!

In 25 years of these Toyota ECU being around, it seems strange no one every cracked this platform wide open a decade ago.

Especially as Blitz/MInes managed it with the daughter boards, which I suspect was given backdoor help from TRD or Denso developers.

0x0545E looks likely

Seems a no brainer at this point to spend the $250 on Bitedit dongle + Toyota Denso Petrol Module 1

 

[MerryFrankster]

Blitz/Mines did it with Motorola based ECU's. The microcontroller came cracked from factory. Ha ha.