Playing with Tuner Pro and 1202 Ecu

[cosmic_splatter]

Rhinoview has been helping me get setup on tuner pro with a 1202 ecu.

Here is a screen shot of the output on a 95 tracker. I'm working to resolve some of the reading issues. RPM reports 200 in error. Also, closed loop status indicator is not working properly. Lastly, I changed the values from Celsius to Fahrenheit and I think I may have caused an issue with these readings.

[fixkick]

nice
a shame CL is dead, its like super important check.
odd thing is its just one bit.
does the software allow , raw mode?
see the 32 addresses raw, ?

if yes, we can look at it that way.
pid address 11? 00h or ff hex, or 0 and 1? when you race engine this bit fill flip to false. each time.

---

RPM is PID 1,
address 1.

its 0-9999 RPM,
but the byte is 0 to 512.
so is scaled. the 9999 rule in the fsm , implies, 20x scale here( my theory on limited facts)
but if true then 800 div. by 20 is 40. or 28hex. so in raw mode got 28hex at hot idle, and dash shows 800?
if way low the software is reading the wrong address.
if the raw is correct then the meter scaling is wrong.

ive never run this software,

---

air temp is dead

---

keyon , before first start
IAT and ECT (air and water ) temps must read same (close)
this is the first thing i do then wiggle throttle engine off key on, and TPS follow my right foot.

[cosmic_splatter]

Fixkick,

I believe the rpm issue is related to his post processing calculations. I see that he takes the value from the ecu and divides it by 4.096 for display. I think if I took that out, it would work properly. He has a lot of post processing on each variable. I'll have to add that to my definitions.

I was able to back engineer what he built on tuner pro. Here is what I have.....

Do you have any of the address mappings? If so, some of this should correlate.


1202 ECU Definitions
Request computer id: 0x10 0x03
Get the computer id: 0x10 0x05

Requesting Variables: 0x13 0x0B
RPM: 0x04 0x05
MAF : 0x10 0x11
IGN : 0x0D
INJPW : 0x0E 0x0F
VE: 0x19
VSS: 0x07
WTS: 0x08
EGRT: 0x09
TPS Angle: 0x0A
TPS Volts: 0x0B
STFT: 0x14
AFT: 0x16
O2 Sensor: 0x0C
LTFT: 0x15
Batt Volts: 0x17
IAC Flow: 0x12
Target Idle: 0x06
IAC Adj Mon: 0x13
EGR Temp: 0x09
Unknown: 0x18 0x1D

Requesting Status Flags 8 bytes: 0x13 0x09
Status1: 0x1A

[fixkick]

my 8v maps differently
thanks for sharing that map, very interesting all that./

must be post processing errors. I'd bet the addresses are all good. (they worked hard to find them all , i do know that)

[cosmic_splatter]

Interesting....I published my work on the 1202 ecu above on Rhinomans forum and he said he would update tuner pro for me since he wasn't permitted to share the suzuki protocol. I wonder who isn't permitting him to share this info?

[fixkick]

it's proprietary
Suzuki never published it ever. (old tech1's , are the exception and rare as hens teeth or long ago DEAD)
they SUZ, sells it, but just who will pay $ 1000s to do that, no tool maker , supports it for this reason. none.
(it's a big up front fee and like $4000 every year fee)

So any wonder Suzuki is chapter 11 here and in Canada? could it be, crap support, my guess is yes, IMO.

there is only one hacker doing this. and like 54 markets of PCM , potentially, just in usa there are 50 ECU/PCM/TCM and world wide, way more.
that 1202 is the ( topology , mapping) for your ecu.

you can capture the serial line data off the tools
even the teck1 one, you can do that. see all outgoing commands and responses. and check sum, methods.
this is how it was done, and code dis-assembly too.

all this is hacking, and will have rough edges.
and is far better than what suzuki offers.. no lie.

the protocal is super simple, i have it on my hack page.
eg
0x13 0x04 cmd , CS [CheckSum) ( line command syntax)
Checksum is calculated by this math: 100 - ( 13 + 04 + cmd) (hex math !) Rule: the CS must add to Zero , not including the CS itself.
Below are all CS values in column 2.

the trick, is the add to zero calc. making that happen.

the mapping is insane complex.
you must know the actual memory index code that maps a specific PID.
this is super hard to get , with no TECH one to capture this.
may be over 50 mappings world wide.. even JDM ecus' etc.

---

a Tech1, hacking 101
you tap into the single serial line with the special scan cable for chevy, (you have one)
then you run a dumb terminal programm, set to the correct BAUD rate
then give commands with the tool and and see all response or your terminal. RX screen "RealTerm(

[cosmic_splatter]

Fixkick,

I did find that two of the flags I'm watching only activate while out driving the car. I believe one maybe the Vacuum system for the EGR. And, the other one for the Canister purge valve. Does this sound like the two that are triggering while driving?

There seemed to be two flags that tracked identically to the fuel lean/rich settings. Not sure if one is a slave of the other or they just are storing the info in two places. They seem to go high and low in synch. It's just strange they would put it in two places.

I don't see any flag that is off when cold and turns on after a bit. Just not seeing one yet. There are a couple that seem to be going on and off. My car is getting 28.5 mpg, so I'm pretty certain that the closed loop is working normally. I'm just not seeing it in the datastream yet. What is the normal function of the closed loop flag? Will it be off until the ecu takes over and then stay on? Or, will it bounce back and forth from on to off?

John

[fixkick]

that is correct EGR is DEAD , not moving (ECU programming (and the ported vacuum is dead, so double dead , it idle) and if moving and not at idle it goes ACTIVE.
it is that simple, but wait, it cuts out WOT. too.
The Canister is dead at idle, so it dont mess up idle , then when the idle switch goes, off idle it goes active.
by design and ECU programming.
im not sure on those, other bits flipping, after all SUZUKI never once disclosed the MAPPING details. (just to Tech1 ,long long ago....)
There is no publish spec, none at all, it's all a big secret.

not all status flags are presented in the human data stream. not even close. it just SOME PIDs, not all. this is true on all OBD1 cars., hell even OBD2.

The newer the ECU the more complex. ever study how LTFT is stored at many engine load factors, in a matrix, read the old V8 Engines, OBD1, they documented this. a great read.

closed Loop means, the 02 sensor, is now active and ALL AFR is control by IT. (the LOOP) think of autopilot in an air craft, it too is a closed loop servo system. (same is ISC)
it's a servo, a loop. the ECU is reading 02 and adjusts all AFR at all times Closed loop
when not in closed loop the MAF runs the show (air + fuel = injection rates)

closed loop takes that same equation and adds 02 trim. that is it.
but can be very complex on newer cars, newer cars store a 16 wide matrix of LTFT (LTFT on one axis and load the other, or 3D matrix with RPM)

when you change speeds, the ECU may first try old LTFT data. (stored in LTFT x) then correct as it happens. it just a starting point. (GM OBD1 does that)
what this MITSUBISHI ECU does it , i've not the foggiest notion. I've never disassembled the code,


CL does not bounce. (well normally if somethings wrong, sure, like vacuum leaks?)
CL is active WHEN:
above a certain coolant temp, my guess 150f.?
and when 02 is fully hot. (my 1996 would do this is 10second, from cold start and was an EPA mandate to do so...)
and at cruise only. (and hot idle too.)
and at steady right foot.
and it steady maf readings, Cruise is that.
then it goes CL.
if you move the right foot fast, bam CL = FALSE. and MAF runs the show. In fact , the fast right foot , trips the ENRICH bit. (you cant see that either)
if you go WOT< the CL goes false, and MAF runs the show. The ecu has a WOT bit too. unseen by you.
when you finally get back to cruise and Enrich end, , CL = TRUE. 14.7:1 AFR, and looping and the o2 is cross-counting like 6 times a second.

if you have a OBD2 car of any kind, you can watch this and log it. all day. ($9 tool, and $25 relic lap top, all day)
it's the best way to learn, using a real system that works, no bugs.

good luck. with your tool , sounds like lots of fun.

---

also the older ECU can not steam data fast enough (slug slow processor) to see the 02 swing.
what you see is jerks and fits. (do to , slow scans)
the ECU does see ever swing of the ECU, (toggles) and trims full time by what it sees.
think of that is process 2 ,just behind process1 , make spark happen on time.

spark 1
inject 2
trim 3
id bet those are processor priorities

you can read the open source code on some custom ECUs.

many engineers at school , publish their projects. for making a working ECU.
you can see the whole thing.