Gearshift Maps

[b3lha]

I've been looking at the TCU recently and have located the shift plan and figured out how to decode it. The shift plan is composed of multiple shift maps. There is one shift map for each possible combination of mode, stick position, and current gear. Each shift map is comprised of an upshift curve and a downshift curve.

As an example: The UK TCU has 6 modes (Normal, Economy, Power, Manual, Cruise and Overheat). There are 4 stick positions (D,3,2,1) and obviously 4 gears (1st,2nd,3rd,4th). Therefore there are 6x4x4=92 shift maps in the shift plan.

The shifting decision is based on vehicle speed and throttle, not rpm. This is confirmed by the factory service manual. Let me demonstrate how it works with the aid of the Normal-StickD-Gear2 map and the Normal-StickD-Gear3 map.

http://www.alcyone.org.uk/ssm/gearmap1.jpg

Suppose you are driving in Normal Mode, with the stick in D, at 50mph and 40% throttle. The gearbox is in 3rd gear. Imagine a dot at (50,40) on the 3rd gear map (the one on the right). If you floor the gas, the dot will move vertically up the chart. When you get to about 88% throttle, the dot crosses the downshift curve and the box changes down to 2nd gear.

Now the dot is on the 2nd gear map at 100% throttle and moving right as the speed increases. When you reach 85mph the dot crosses the upshift curve and the box changes up to 3rd gear.

That's the basic theory. Now lets look at some more pictures.

Here are the upshift and downshift curves for a USDM SVX in Normal mode, with the stick in D. I have superimposed the 4 maps into one diagram.

http://www.alcyone.org.uk/ssm/gearmap2.jpg

You will note that the gear1-downshift map is a horizonal line at 100% throttle, because obviously we can't downshift from 1st gear. Similarly, the gear4-upshift map is a horizonal line at 0% throttle because we can't upshift from 4th gear.

http://www.alcyone.org.uk/ssm/gearmap3.jpg

If you compare the Power mode curves you can see that in Power mode, the TCU upshifts at a higher speed, and needs less throttle push to trigger a downshift. At 60% throttle it will change from 2nd to 3rd at 64mph in Power mode compared to 43mph in Normal mode. If you squeeze the gas pedal at 50mph in 4th, Power mode will downshift at only 35% throttle whereas Normal mode requires 62%.

The USDM TCU is a little more complex than the UK version. It has 7 modes (Normal,Power,Manual,Cruise,LowPres1,LowPres2,Over heat) and therefore 7x4x4=112 maps. The LowPres1 mode is activated when the atmospheric pressure is low. The LowPres2 mode is activated when the atmospheric pressure is very low. The TCU uses power mode if the atmospheric pressure is very very low. I have no idea why Subaru would need different shift maps based on atmospheric pressure. Perhaps to compensate for reduced engine power at altitude? Only the USA model has this feature, the UK and JDM don't even have a pressure sensor.

Now for yet another answer to the FAQ "What does the manual button do?". Below are the maps for Manual Mode with the Stick in 3. You can see that the car will start in 2nd but then upshift to 3rd almost immediately and then hold 3rd right up to 143mph. On the downshift, it will hold 3rd all the way down to almost a standstill. When the stick in is 2 (not on this diagram), the car will start in 2 and hold it right up to 91mph. Essentially, Manual mode does its very best to keep you in the gear you have selected on the shifter.

http://www.alcyone.org.uk/ssm/gearmap4.jpg

The JDM model has only 5 modes (Normal, Power, Cruise, Manual and Overheat), however there is data for 2 extra maps that never seem to get used. I was expecting that the Normal and Power maps would be the same between JDM and UK models, but they are not. Here is a comparison of the upshift maps between the two models.

http://www.alcyone.org.uk/ssm/gearmap5.jpg

It appears to me that the UK Economy mode is slightly more relaxed than the JDM Normal Mode while the UK Normal Mode is slighly more aggressive than the JDM Normal Mode. ie. The JDM Normal mode is inbetween UK Economy and Normal. The UK Power mode is also more aggressive than the JDM Power mode. There is no point in comparing the USDM maps without some way to compensate for the different diff ratio.

I have extracted the maps into a big Excel spreadsheet attached to this post. So you can have a play with it if you are interested. To plot a graph, first select the tab for the version of car: UK, JDM, USDM. Select column A or B depending on whether you think in mph or km/h. Then hold CTRL and select additional columns for the maps that you want to include in the graph. As a first attempt, try columns C,E and G (Normal-StickD-Upshift maps for each gear). Then click on Insert/Chart. Select the "XY Scatter" chart. Click on the last icon "data points connected by lines without markers". Then Next/Next/Next and admire the pretty picture.

Having decoded the shift plan, I'm pretty confident that I could modify it and I'm already thinking about loading the UK power mode maps into one of my JDM cars. Plus, maybe an improved version of the as-yet-untested power mode mod for UK cars. But there's a few more things I need to figure out first, like the torque converter lockup for example.

[b3lha]

There is no point in comparing the USDM maps without some way to compensate for the different diff ratio.

I know I said there was no point, but actually it quite interesting to compare the UK, JDM and USDM models on the same chart.
http://www.alcyone.org.uk/ssm/gearmap6.jpg

[SuberNatural]

So how far from being able to remap the TCU are you?

[b3lha]

So how far from being able to remap the TCU are you?

It depends what needs remapping. I could modify the gearshift maps now, but other stuff like the workings of the 4wd system I haven't figured out yet.

[TomsSVX]

Think you could write a chip that eliminates the ECU inputs like we had talked about?? I am sure I could get TPS and RPM outputs from the Hydra as long as we have a place to input them

Tom

[SuberNatural]

I would be interested in experimenting with this. :) Let me know what i need :)

[b3lha]

Think you could write a chip that eliminates the ECU inputs like we had talked about?? I am sure I could get TPS and RPM outputs from the Hydra as long as we have a place to input them

Tom

Yes. Should be fairly straightforward. I'll start working on it.

[b3lha]

I would be interested in experimenting with this. :) Let me know what i need :)

OK. Here's a quick howto:

1. First you need to grab a spare TCU and modify it as per the instructions on my website. Unsolder the ROM chip and solder in a socket. If you aren't good at soldering, go find a TV repair shop. You are also going to need an eprom programmer and a blank eprom. A select monitor interface and some datalogging software would be useful for debugging your modified maps.

2. Then you need to download Nomake Wan's TCU file from my website. 1992 USDM model, RomID 705404. Or you can extract your own using my tcudump program.

3. Find the map you want to change:
Open the file in a hex editor and scroll down to address 0x0000CFAD. For those who don't know, writing 0x in front of a number indicates that it is a hexadecimal number. At address 0xCFAD is a list of 16 bit pointers to the maps. ie. It holds the start address of each map. The first map is at location 0xD16D, the second at 0xD17C, the third at 0xD17F etc.


0000CFA0 xx xx xx xx xx xx xx xx xx xx xx xx xx D1 6D D1
0000CFB0 7C D1 7F D1 8E D1 9A D1 A9 D1 B8 D1 BB D1 CA D1
0000CFC0 D9 D1 DC D1 EB D1 F7 D1 FD D2 0C D2 0F D2 15 D2
0000CFD0 24 D2 27 D2 2D D2 39 D2 3F D2 45 D2 48 D2 4E D2
0000CFE0 54 D2 57 D2 5D D2 63 D2 69 D2 6F D2 72 D2 78 D2
0000CFF0 87 D2 8A D2 99 D2 A5 D2 B4 D2 C3 D2 C6 D2 D5 D2
0000D000 E4 D2 E7 D2 F6 D3 02 D3 08 D3 17 D3 1A D3 20 D3


Decide which map you want to modify and work out its position in the list:
Map Number=(Mode*32)+(Stick*8)+(Gear*2)+Direction
where:
Mode: Normal=0, Power=1, Manual=2, Cruise=3, LowPres1=4, LowPres2=5, Overheat=6.
Stick: PosD=0, Pos3=1, Pos2=2, Pos1=3
Gear: 1st=0, 2nd=1, 3rd=2, 4th=3
Direction: Upshift=0, Downshift=1

This should give you a Map number between 0 and 223 (decimal). The Pointer address is 0xCFAD + (Map Number * 2).
For example: The map for Power-Stick3-Gear2-Upshift: Map Number=(1*32)+(1*8)+(1*2)+0=42. Pointer Address=0xCFAD+(42*2) = 0xD001

Look in the list at address 0xD001 and you will see the address of the map is 0xD2E7. Now scroll down to 0xD2E7 and look at the map itself:


0000D2E0 xx xx xx xx xx xx xx 28 00 80 51 0C AC 7E 18 F0
0000D2F0 8B 00 F0 FF 00 FF xx xx xx xx xx xx xx xx xx xx


4. Here is how you decode the map:

Arrange the data into columns of three bytes like so, label them K, M and T

K M T
28 00 80
51 0C AC
7E 18 F0
8B 00 F0
FF 00 FF

Convert them all to decimal and then subtract 128 from each number in column T.

K M T
40 00 00
81 12 44
126 24 112
139 00 112
255 00 127


K is a speed in km/h. The TCU will use the first row for speeds up to 40km/h, the second row for speeds up to 81km/h, the third for speeds up to 126km/h and so on.

T is a TPS signal between 0 and 127. Zero represents no thottle, 127 represents full throttle. In the previous posts I have converted this figure to a percentage.

The tricky bit, M is the gradient, in 16th's of the line running back from point (K,T) on the graph.

Expressed algebraically, the formula for the graph is: y=T-((M/16)*(K-x)).
where
x is the speed in km/h that you want to know the tps value for.
K,M and T are taken from the appropriate line of the table that corresponds to the speed x.
y is the tps value from 0 to 127.
http://www.alcyone.org.uk/ssm/gearmap7.jpg
As an example:
Suppose we want to know the tps value of the change point at 100km/h.
We use the third line of the table: x=100, K=126, M=24, T=112.
y=112-((24/16)*(126-100))=73
Converted to a percentage (73*100)/127)=57% thottle.

5. To modify the map, work out where you want the shift points to be, then work backwards through step 4 to find what the new values should be and update them in your hex editor.

6. Now use my checksum program to update the checksum in the modified TCU file. I'm pretty sure the TCU never checks this, but better safe than sorry.

7. Write the modified TCU file to an eprom chip and insert it into the socket on the TCU.

[TomsSVX]

I have a ton of TCU's here if anyone needs a spare, pay shipping and its yours.

Tom

[SuberNatural]

Awesome! I'm going to run this by my buddy who tunes my OBD1 stuff. Then I'll start making changes and provide updates as far as how I like it, ease, etc.

Hey tom, I'd be interested in a TCU. Let me know the deal :)

[SuberNatural]

Not to keep posting lol, but are you thinking or trying to create a program to simplify this into a basic GUI program?

[b3lha]

Not to keep posting lol, but are you thinking or trying to create a program to simplify this into a basic GUI program?
I have a program that I created to extract the maps from the TCU dump file into a CSV file that I used to create the Excel spreadsheet.

I am thinking about making some modified maps and I will probably write some software to help with building and testing them. It will be Linux or DOS though because I don't have experience at writing Windows software.

[TomsSVX]

Awesome! I'm going to run this by my buddy who tunes my OBD1 stuff. Then I'll start making changes and provide updates as far as how I like it, ease, etc.

Hey tom, I'd be interested in a TCU. Let me know the deal :)

Like I said, shoot like $15 for shipping anywhere in the lower 48 and I will send you one

Tom

[b3lha]

One further thing I should mention on this topic is the RPM limit. There is a RPM limit that forces an emergency upshift to save the mechanical bits from destruction.

This is at location 0xD881 though 0xD884 for 1st through 4th gears or alternatively 0xD885 through 0xD888 if the manual button is on. This is global and applies for all the different modes and maps.

Without manual button, the values are 5E 5E 5E FF.
With manual button, the values are 61 62 64 FF

I *guess* you multiply these numbers by approximately 70 to get rpm.

5E=6580
61=6790
62=6860
64=7000
FF=17850 (it can't upshift up from 4th)

[SuberNatural]

Excellent. I really dont like windows all that much anyways lol...... Also im just looking to have the trans stay in 1-3 a little longer and have it downshift at a lower TPS reading

Tom PM me an address for sending a MO.

[b3lha]

I've figured out the maps for the Torque Converter Lockup. I'll post the technical details of how to decode them on my website in due course.

There are 52 maps in total: 3 modes (Normal, Power, Overheat) multiplied by 4 stick positions ("D","3","2","1") multiplied by 4 gears ("1st","2nd","3rd","4th") makes 48 plus Cruise mode in 4 gears = 52 total.

Each map has a lock curve and an unlock curve. The TC will be locked when the speed rises above the lock curve and unlocked when the speed falls below the unlock curve. The x scale is tps and the y scale is speed. This is the opposite way around the the gear shift maps earlier in the thread. I have converted the scales to a percentage and mph for the picture below.

Most of the maps, for example 1st,2nd and 3rd gear are a straight horizonal line at 159mph. This effectively means "do not lockup the torque converter" because the car is unlikely to ever exceed 159mph in those gears.

If you look at the top left map in the picture below, this is Normal-StickD-Gear4. You can see at 50% throttle, the TC will lock as you accelerate past 77mph and unlock as you decelerate past 55mph. If you were drag racing at 100% throttle, it would lock at 92mph on the way up and unlock at 86mph on the way back down.

It has been mentioned in the "Power Mode Mod" thread that the TC does not lockup in power mode. This is not entirely true. As you can see from the top right map: In 4th gear, it will lock at 92mph and unlock at 86mph in any throttle position.

In the bottom left corner you can see the cruise map, the TC locks up at lower speed and lower throttle for smooth driving and economy.

Finally, in the bottom right corner is a sample of the overheat maps. When the TCU is in overheat mode, it locks up the TC even in 2nd and 3rd gear, not just 4th like the other modes. It has often been said that the TC generates a lot of heat. When the transmission gets too hot, the TCU locks it up whenever possible to try and stop the temperature from rising any further.

http://www.alcyone.org.uk/ssm/lockup1.jpg

These maps were taken from a 1992 USDM TCU.

[longassname]

good work,

I can supply the prototype and 94 tcu bins if you want them.

[longassname]

If people want I can supply socketed tcu's. I have a box of them. I don't want to sell them rediculously cheaply though...or be acused of charging too much either..so i don't know.

[b3lha]

good work,

Thanks Mike. I find the TCU code a little easier to work with than the ECU. :)

I can supply the prototype and 94 tcu bins if you want them.
Yeah. Thanks. Every little bit helps with the research.

I have the 92 and 94 JDM bins. I upgraded my 92 car to the 94 firmware just in case it helps the transmission last longer. I haven't analysed the differences yet :rolleyes:

I've just been looking at a Legacy TCU from 1990. It doesn't have any of the "overheat mode" processing. I suspect that Subaru may have added the overheat mode in an attempt to overcome transmission overheating problems with the early SVX prototypes.

[longassname]

Ya, I think you'll notice a few things in the first 5 minutes of looking at the late model code. i sent to the email on your website.

[Hondasucks]

Thanks Mike. I find the TCU code a little easier to work with than the ECU. :)

Yeah. Thanks. Every little bit helps with the research.

I have the 92 and 94 JDM bins. I upgraded my 92 car to the 94 firmware just in case it helps the transmission last longer. I haven't analysed the differences yet :rolleyes:

I've just been looking at a Legacy TCU from 1990. It doesn't have any of the "overheat mode" processing. I suspect that Subaru may have added the overheat mode in an attempt to overcome transmission overheating problems with the early SVX prototypes.

I have a Legacy Turbo TCU that I have yet to put in my wife's car (Previous owner swapped the TCU out when he put the non-turbo motor in it, thinking it was the ECU) I wish I had an EPROM programmer so I could dump the maps out of both of them and see if they are any different.

[b3lha]

I have a Legacy Turbo TCU that I have yet to put in my wife's car (Previous owner swapped the TCU out when he put the non-turbo motor in it, thinking it was the ECU) I wish I had an EPROM programmer so I could dump the maps out of both of them and see if they are any different.

You don't need a eprom programmer for that.

You just need a cable to connect your car to your PC. Then you need a linux bootdisk and my tcudump program.

[b3lha]

Ya, I think you'll notice a few things in the first 5 minutes of looking at the late model code. i sent to the email on your website.
:eek: :lol:

I'm guessing this TCU (725606) uses a different CPU chip? Not very different, but different enough to break my 6811 disassembler. Maybe a 6816?

Is this from an OBD2 car?

[longassname]

No, that's the 94 usdm rom. Most if not all obd1 USDM awd SVXii use the e23aa11p or e23aa12p roms. That's the e23aa12p rom--the latter model obd1 rom. I used the Dewtronics M6811Dis v1.0 code seeking dissassembler back when I did it. Maybe you didn't notice it's sitting in a 32k ROM and your control file is loading it complete with padding to c000? May also need to edit some entry points?



:eek: :lol:

I'm guessing this TCU (725606) uses a different CPU chip? Not very different, but different enough to break my 6811 disassembler. Maybe a 6816?

Is this from an OBD2 car?

[b3lha]

No, that's the 94 usdm rom. Most if not all obd1 USDM awd SVXii use the e23aa11p or e23aa12p roms. That's the e23aa12p rom--the latter model obd1 rom. I used the Dewtronics M6811Dis v1.0 code seeking dissassembler back when I did it. Maybe you didn't notice it's sitting in a 32k ROM and your control file is loading it complete with padding to c000? May also need to edit some entry points?

I noticed the 16K of FF on the front. I am loading this image at 8000. I guess the bigger rom gives much more space for TCU mods. :D

Now that I have looked at it properly, I can see that the image you sent me is corrupt. Bit 1 of every single byte is set to 1. This obviously results in incorrect disassembly. I thought I was using the wrong disassember.:rolleyes:

Compare the following:

This is the 705402

f33e 8e 01 ff lds 0x01FF
f341 86 a0 ldaa 0xA0
f343 b7 10 39 staa (0x1039)
f346 86 04 ldaa 0x04
f348 b7 10 3f staa (0x103F)
f34b 86 01 ldaa 0x01
f34d b7 10 38 staa (0x1038)


This is the 725606

f35c 8e 03 ff lds 0x03FF
f35f 86 a2 ldaa 0xA2
f361 b7 12 3b staa (0x123B)
f364 86 06 ldaa 0x06
f366 b7 12 3f staa (0x123F)
f369 86 03 ldaa 0x03
f36b b7 12 3a staa (0x123A)


You can see it better in binary:

705402: 10001110 00000001 11111111 10000110 10100000 10110111 00010000 00111001
725606: 10001110 00000011 11111111 10000110 10100010 10110111 00010010 00111011

The whole image is corrupted like that, every single byte has that bit set to a 1. I can't imagine how it could have happened.

[longassname]

that would mean it's a 705404 bin. I'll look at my files and figure out what's going on. I labled that file yesterday off of the rom code so it happened at least before that. I thought that bin was the basecode I'm running in my car but I guess not. I have a good 94 bin here somewhere because it's the base of what I'm running in my black car; unfortunately I don't seem to have labled anything very well.

[longassname]

ya, sorry about that. It should be 705404. I think that bin I sent you yesterday was a read of a mis-solder I forgot to throw away. I remember I had to settle for soldering my surface mounts to a less than ideal adaptor that proved to be a pita to solder. I'm sending a good bin now.

[b3lha]

OK Thanks. That one looks better.

You take the chips off the board to read them rather than using the select monitor port? That really must be a PITA. I find it impossible to unsolder them from the board without destroying them.

[longassname]

I'm pretty good at desoldering; I don't have any problems removing the surface mounts. I think your euro and jdm tcu's might not be coated but the usdm tcus are coated after assembly--that's really the annoying thing about socketing them. It costs a fortune in solvent getting them stripped before desoldering.

I guess now is a good time to give tips to anyone who's going to socket a US tcu. Don't even try desoldering/soldering until after you clean off the coating. Assuming you aren't experienced at desoldering, do what Phil does and cut the legs of the surface mount with an exacto knife instead of desoldering it (cut along the rom, not the pcb). If you do a clean job of cutting the legs you shouldn't even have to desolder them. You still have to clean the coating off of the through holes for the dip chip before you can empty them and solder in the socket.

[longassname]

phil,

just in case you want independent verification of addresses here are my main svx specific labels

label 1044 VB
label 0019 VSP1
label 001A VSP2
label 00B6 EREV
label 0017 ATFT
label 1040 THV
label 004E GEAR
label 00B3 PLDTY
label 00B4 LUDTY
label 00B5 4WDTY
label 1046 BAROP
label 0011 BITFA0
label 0012 BITFA1
label 0013 BITFA2
label 0014 BITFA3
label 0001 DIAGU1
label 0005 DIAGU2
label 0003 DIAGM1
label 0004 DIAGM2

label 0018 VSpeed

[longassname]

705404 is the 92 ROM isn't it? I don't think I'm finding the right file for the 94. I'll just read it again.

[oab_au]

I'm pretty good at desoldering; I don't have any problems removing the surface mounts. I think your euro and jdm tcu's might not be coated but the usdm tcus are coated after assembly--that's really the annoying thing about socketing them. It costs a fortune in solvent getting them stripped before desoldering.

I guess now is a good time to give tips to anyone who's going to socket a US tcu. Don't even try desoldering/soldering until after you clean off the coating. Assuming you aren't experienced at desoldering, do what Phil does and cut the legs of the surface mount with an exacto knife instead of desoldering it (cut along the rom, not the pcb). If you do a clean job of cutting the legs you shouldn't even have to desolder them. You still have to clean the coating off of the through holes for the dip chip before you can empty them and solder in the socket.


I just use a 0.8 mm pin drill, to drill through the solder holes for the socket. Saves heating the board too much while you suck the solder out.:)

Harvey.

[b3lha]

I'm pretty good at desoldering; I don't have any problems removing the surface mounts. I think your euro and jdm tcu's might not be coated but the usdm tcus are coated after assembly--that's really the annoying thing about socketing them. It costs a fortune in solvent getting them stripped before desoldering.

I guess now is a good time to give tips to anyone who's going to socket a US tcu. Don't even try desoldering/soldering until after you clean off the coating. Assuming you aren't experienced at desoldering, do what Phil does and cut the legs of the surface mount with an exacto knife instead of desoldering it (cut along the rom, not the pcb). If you do a clean job of cutting the legs you shouldn't even have to desolder them. You still have to clean the coating off of the through holes for the dip chip before you can empty them and solder in the socket.

The euro and jdm ones are coated too. I haven't used solvent on mine. Just melted it with the soldering iron and scraped off the residue. Then take off any remaining solder with copper braid and polish with a fibreglass pencil. It looks shoddy but it works.

Solvent would be a better way to do it, but I didn't know at the time.

[b3lha]

Thanks for confirming the addresses. They match exactly with my list and the one from Tom's select monitor.

705404 is the 92 ROM isn't it? I don't think I'm finding the right file for the 94. I'll just read it again.

Yes. I just checked and your 705404 is the same as the one from Nomake Wan's 1992 car.

[longassname]

Phil what are you doing with your shift maps? Do you have any engine work deserving of higher revs?

I'm a big fan of making the 2 to 1 shift come in with less throttle and raising the shift points/rev limits. I haven't really found anyting else in the shift maps I care to change. Even in a stock SVX I find changing the 2 to 1 downshift map a huge improvement though. I can't imagine anyone not wanting to.

[b3lha]

Phil what are you doing with your shift maps? Do you have any engine work deserving of higher revs?

I'm a big fan of making the 2 to 1 shift come in with less throttle and raising the shift points/rev limits. I haven't really found anyting else in the shift maps I care to change. Even in a stock SVX I find changing the 2 to 1 downshift map a huge improvement though. I can't imagine anyone not wanting to.

I find the JDM box pretty much perfect, I don't really plan to change anything except perhaps to lower the temperature that the overheat mode kicks in. My engine is completely stock and my ECU and TCU are running the standard JDM maps.

What you suggest about the 2 to 1 downshift sounds interesting. I drive with the power button on nearly all the time. But I have noticed that when pulling away from a slow roll, it is often better to be in 2nd than 1st. The engine has plenty of torque available. Is that what you are talking about?

I have done a mod for the UK models to change the econ mode switch to a power mode switch. A few people have that now but nobody has tested it yet.

Other than that, I've been talking to a guy about doing one optimised for cars with the 4.44 or 4.11 diff swap. Somebody else is talking about swapping the internal gears in their box and wants a custom TCU for that. But I'm not working on either of these things yet.

I am planning to do a version of the USDM TCU that doesn't require signals from the ECU. It can be used with the standalone ECU that Tom is working on.

I do want to try the paddleshift code just to see it working. I wouldn't want to keep it on my car permanently.

[edmsvx]

Phil I perfer the shift maps on the JDM TCU. I found I drove most of the summer with the power switch turned on my JDM car. Really only switching to compare the two modes

I have done the power mod switch on my Canadian SVX and found while it is great in that it feels very sporty it holds each gear too long under lighter throttle. I find myself constantly turning power mod off and on.

If I had a choice I would have JDM power as normal mode and USDM (Canadian) power mode mapping for the power mode switch.

Peter

[longassname]

kind of,

I was mainly talking about the downshift of the normal mode map but yes I also like to change the normal mode upshift map into a kind of a hybrid betwen the normal and power mode map.


I find the JDM box pretty much perfect, I don't really plan to change anything except perhaps to lower the temperature that the overheat mode kicks in. My engine is completely stock and my ECU and TCU are running the standard JDM maps.

What you suggest about the 2 to 1 downshift sounds interesting. I drive with the power button on nearly all the time. But I have noticed that when pulling away from a slow roll, it is often better to be in 2nd than 1st. The engine has plenty of torque available. Is that what you are talking about?

I have done a mod for the UK models to change the econ mode switch to a power mode switch. A few people have that now but nobody has tested it yet.

Other than that, I've been talking to a guy about doing one optimised for cars with the 4.44 or 4.11 diff swap. Somebody else is talking about swapping the internal gears in their box and wants a custom TCU for that. But I'm not working on either of these things yet.

I am planning to do a version of the USDM TCU that doesn't require signals from the ECU. It can be used with the standalone ECU that Tom is working on.

I do want to try the paddleshift code just to see it working. I wouldn't want to keep it on my car permanently.

[longassname]

Thanks to Phil :) if you like playing with electronics you do have a choice. You don't have to know anything really about computers or software to do what you want. That's a simple copy from one map and paste in the other map kind of thing.


Phil I perfer the shift maps on the JDM TCU. I found I drove most of the summer with the power switch turned on my JDM car. Really only switching to compare the two modes

I have done the power mod switch on my Canadian SVX and found while it is great in that it feels very sporty it holds each gear too long under lighter throttle. I find myself constantly turning power mod off and on.

If I had a choice I would have JDM power as normal mode and USDM (Canadian) power mode mapping for the power mode switch.

Peter

[longassname]

Phil, did you notice full throttle shifts are off the rev limiter not the map?

[b3lha]

I'm a big fan of making the 2 to 1 shift come in with less throttle and raising the shift points/rev limits. I haven't really found anyting else in the shift maps I care to change. Even in a stock SVX I find changing the 2 to 1 downshift map a huge improvement though. I can't imagine anyone not wanting to.
I thought about it some more and I understand what you mean now. When you squeeze the throttle in 2nd, you want the car to be a little more eager to downshift to 1st.
Phil, did you notice full throttle shifts are off the rev limiter not the map?
Yeah. I thought I had mentioned it somewhere, but maybe it slipped my mind. I think that is a safety measure to protect the mechanicals if the driver does something stupid.

Do you think that copying the JDM maps to a USDM TCU will work well, or will the different final drive ratio have a negative effect?

[longassname]

I don't think it would hurt anyone to try if they are curious. This is the kind of thing people can tinker with without worry of blowing anything up. I tighten up the endplay on the rotating assembly on my boxes when I build them and they can obviously hold a lot more torque but I don't have any problems running high rpms. I don't think it's an issue. Without the power mode mod the US model drives differently though since we switch from whatever mode we are in to power on heavy acceleration.


Here's the change I like for the USDM. Maybe you can plot this for us?

power 1 to 2:
14 00 80
2B 16 B0
42 2C F0
53 00 F0
FF 00 FF


normal 1 to 2:
0F 00 80
1E 33 C0
3C 19 F0
53 00 F0
FF 00 FF


normal and power 2 to 1
0F 00 80
0F 00 C0
2D 19 F0
FF 00 FF

[longassname]

that's a 7600-7800 rpm shift at full throttle if you have your rev limiters set up (mine are at 7800) but if you don't raise your rev limiters you can use those same maps and your full throttle shifts will still be at 6500 rpms.

[b3lha]

Sure, I'll plot it Monday on my computer at work.

Do you know C programming? I wrote a program to pull the shift maps out of a TCU dump file and write a CSV file to import into Excel for plotting graphs. I can send it to you if you want it.

[longassname]

Thanks,

Not so much. My schooling/experience is in object oriented programming (microsoft visual c#). I think I still have visual c++ installed from something else. I could run c stuff in that but it would probably easier for me/I'd be more comfortable just writing the functions in excell (I probably should have done that to begin with but I've been content wasting time making half ***ed plots on my worksheets).

Sure, I'll plot it Monday on my computer at work.

Do you know C programming? I wrote a program to pull the shift maps out of a TCU dump file and write a CSV file to import into Excel for plotting graphs. I can send it to you if you want it.

[longassname]

ok, I went ahead and updated my spreadsheet. Here are the plots of the shifts I like.

http://www.ecutune.com/posts/1-2shifts.gif

[longassname]

is anybody doing this?

[longassname]

Phil,

Wouldn't this be an easy implementation of paddleshift on the usdm?

Use the manual mode D range for the paddleshift.
Where it compares the looked up value with the calcuted value jump out and run your own code that says
if not in manual mode jump back to normal compare
if not in d range jump back to normal compare
if gear 4 jump past next line
if the input for the upshift paddle is active set looked up value to compare value for upshift
if gear 1 jump past next line
if the input for downshift paddle is active set looked up value to compare value for downshift
jump back to normal compare

[SuberNatural]

Have you actually used a modded tcu yet? Forgive me if i missed it

[longassname]

I have. The shift maps I posted for the 1 to 2 and 2 to 1 shifts are the ones I am driving on right now. My 2 to 3 shift maps are also changed to shift at a higher rpm at full throttle and my rev limiters are all at 7800.

The information Phil has posted works where as the suggestion I just posted is probably a bit off since I'm not looking at the code and really cognicent of where the compares are made and where the bits are set and decisions are made..but none the less I'm sure Phil will get the idea behind taking advantage of all the existing logic and just setting a value on a momentary input. :)

[SuberNatural]

So, you like the changes a lot better huh? I was considering this but am not in the "programming know how."

I can however solder :) I was interested in maybe getting a write-up/how-to with pictures posted up as far as the process goes. Any thoughts on that?

[longassname]

I posted the actual hex for my 1,2 shift maps so if you wanted to try them you could just paste my hex in the appropriate locations. I greatly prefer them over stock.

Do you have the hardware for writing a ROM to install into your tcu?

As far as socketing a tcu goes, i'm guessing Phil already has info on how to do that on his website. All you are doing is removing the surface mount ROM that is on there and installing a dip socket you can plug a dip package ROM into.

[SuberNatural]

My buddy that is a tuner has a chip burner for 0bd1 honda roms but i dont know the number of the rom.

Have you completely mapped out what you want for your svx trans? or just partial. And what would you want for a pre-tweaked tcu? I know Tom said i could get a tcu for the price of shipping but then i have to send it back out again lol

[longassname]

Your buddy's writer will work and he will have the 256 rom you want too. You should tell him to go to my website while you are at it so he'll start using 512 roms and not need his 256 roms anymore. My multi-tune adaptors have always proven very popular with the honda and nissan tuners that have been introduced them (though there are more of them driving around Australia than the US--I doubt if there is a skyline left down there without one of my multi-tune adaptors in it).

Your buddy will also probably be able to help you with the socketing of your tcu. Almost all Honda ecu's need to be socketed.

I already changed everything I needed changed for my cars. I'm very happy with where my tcu software is now but remember my transmission is not the same as yours. I don't suffer from lazy shifts to begin with; that was changed in the tansmission hardware. People with stock transmissions might want to modify more.


My buddy that is a tuner has a chip burner for 0bd1 honda roms but i dont know the number of the rom.

Have you completely mapped out what you want for your svx trans? or just partial. And what would you want for a pre-tweaked tcu? I know Tom said i could get a tcu for the price of shipping but then i have to send it back out again lol

[SuberNatural]

My cars got the full level 10 stage 3 Xmission in it :)

Ill send my buddy over to your site and see what he tells me. In the meantime ill wait on the TCU from tom just to make sure he has the time to do it

[longassname]

Your buddy will love you for introducing him to the multi-tune; there are so many uses for it on a honda and a lot of them involve the tuner selling twice as much dyno time.

If he does a lot of tuning tell him not to order retail. I generally sell them wholesale in perforated sheets of 40.

[SuberNatural]

YA, he does a load of tuning and works at Bishop motorsports in CT. I know for the day i get back into my 4ws prelude I have an ostrich for on the fly stuff.

[b3lha]

Phil,

Wouldn't this be an easy implementation of paddleshift on the usdm?

Use the manual mode D range for the paddleshift.
Where it compares the looked up value with the calcuted value jump out and run your own code that says
if not in manual mode jump back to normal compare
if not in d range jump back to normal compare
if gear 4 jump past next line
if the input for the upshift paddle is active set looked up value to compare value for upshift
if gear 1 jump past next line
if the input for downshift paddle is active set looked up value to compare value for downshift
jump back to normal compare

It looks good to me in theory.

I was thinking to adapt Ryan's paddleshift code because it is tested and working rather than try to write something new. For example, he has safety checks in place so that you can't change down if the mph is too high and will overrev the engine.

I really want to get back to playing with the TCU. But I've been distracted by another project. I'm busy helping a guy to find the parameter addresses for his Impreza EJ15 ECU. It's a Hitachi unit and the code is quite nasty.

[longassname]

Anyone doing it would have to check/pay attention but I'm thinking if we were to choose the right value to set and the right place to set it those existing safety features in the manual mode could be retained. Anyway, was just a thought and not even researched yet.

[b3lha]

You've hit the nail on the head. I think the best way to do it would be to point the lookup routine at the existing manual mode maps.

Use Manual mode with stick in D, like you said. Rewrite the manual-stickD maps to hold 4th gear.

Then override the stick position variable from D to 1,2,3 or 4 (ie. D) depending on the gear selected with the paddles (stored in a separate variable).

[longassname]

ut oh, when you are done with that you are sure to get a request for the 2.0 turbo; they have the hitachi too.




I really want to get back to playing with the TCU. But I've been distracted by another project. I'm busy helping a guy to find the parameter addresses for his Impreza EJ15 ECU. It's a Hitachi unit and the code is quite nasty.

[b3lha]

ut oh, when you are done with that you are sure to get a request for the 2.0 turbo; they have the hitachi too.
Yeah, Probably. Although I'm surprised the 2.0 turbo parameters aren't already posted on the net somewhere.

[longassname]

i didn't mean 2.0 i meant 2.2

[b3lha]

Hey Michael,

I wonder if we're missing a trick with the TCU mods.

Ryan's post on the USMB seems to suggest that on his TCU, the stock rom can be disabled by a resistor cut rather than removing it completely - like on our ECU.


The TCU was modified by soldering a socket onto the circuit board. I was going to use a different Legacy TCU but it had no holes to solder the socket! I'm not sure what year that TCU was. After the socket is in place, there is a 0-ohm resistor on the bottom of the board that needs to be moved to enable the new socket. The ROM chip I am using is a SST27SF512; this EEPROM is easily reprogrammed without a UV eraser.

http://www.ultimatesubaru.org/forum/showthread.php?t=93670

Any ideas?

[longassname]

r432 connects the oe of the surface mount to the same driver pin that goes to the dip socket
r431 if used connects the oe of the surface mount to high

r430 connects the ce of the surface mount to ground (the ce of the dip socket is straight to ground)
r428 connects the ce of the surface mount to high

r429 pulls a14 of both pad sets high

moving the resistor from r432 to r431 will put the surface mount in output dissable mode


Hey Michael,

I wonder if we're missing a trick with the TCU mods.

Ryan's post on the USMB seems to suggest that on his TCU, the stock rom can be disabled by a resistor cut rather than removing it completely - like on our ECU.


http://www.ultimatesubaru.org/forum/showthread.php?t=93670

Any ideas?

[b3lha]

r432 connects the oe of the surface mount to the same driver pin that goes to the dip socket
r431 if used connects the oe of the surface mount to high
moving the resistor from r432 to r431 will put the surface mount in output dissable mode

Nice work.:)

I see it, the little green surface mount one in the corner with 000 stamped on it.

However, it's a very small part for an amateur like me to solder. It might actually be easier to remove the rom from the board than to disable it by moving the resistor.:rolleyes:

[b3lha]

r432 connects the oe of the surface mount to the same driver pin that goes to the dip socket
r431 if used connects the oe of the surface mount to high

r430 connects the ce of the surface mount to ground (the ce of the dip socket is straight to ground)
r428 connects the ce of the surface mount to high

r429 pulls a14 of both pad sets high

moving the resistor from r432 to r431 will put the surface mount in output dissable mode

Michael, I've added the above information to my website, credited to you. Is that OK?

http://www.alcyone.org.uk/ssm/tcumod.html

[longassname]

sure,

I see you have a sst27sf256 in one of your pictures. Do you have a current source for them?

[b3lha]

sure,

I see you have a sst27sf256 in one of your pictures. Do you have a current source for them?

No. It's a sst27sf512. I got it from Calum. I think he got it from Mouser.

[longassname]

ah, ya they still make those..the 256's are harder to find.

[longassname]

subernatural,

Did you ever get a tcu?

[longassname]

phil,

if you come up with a desire to switch between tcu software on the fly I'll be happy to give you a multi-tune adaptor.

[b3lha]

phil,

if you come up with a desire to switch between tcu software on the fly I'll be happy to give you a multi-tune adaptor.

Thanks. I might take you up on that sometime.

[longassname]

bump for this being cool..come on peeps..trust me, you want to chip your tcu.

[SuberNatural]

Im waiting on some funding lol. Like I said though, after my TCU is chipped I'll be getting a ROM off you.

[NiftySVX]

Yeah this needs to happen. bump!

[nsm484]

I am amazed at what people have done, and taking time just to learn and to later on modify the SVX. Bumpers to this, and subscribed as well :cool:

[longassname]

Phil,

In response to requests from the Australian side of the globe to port my tcu maps over to the JDM tcu's I did. I think you'll probably prefer to run these maps and let throttle application engage power mode instead of forcing it with the button. Let me know what you think. Here are the plots.

http://www.ecutune.com/posts/tcu/ECUtune_JDM.gif

http://www.ecutune.com/posts/tcu/jdm_DN1-2.gif

http://www.ecutune.com/posts/tcu/jdm_DN2-1.gif

http://www.ecutune.com/posts/tcu/jdm_DN2-3.gif

http://www.ecutune.com/posts/tcu/jdm_DP1-2.gif

http://www.ecutune.com/posts/tcu/jdm_DP2-1.gif

http://www.ecutune.com/posts/tcu/jdm-DP2-3.gif

[longassname]

Here's the actual hex for the ECUtune JDM shift maps:

94 JDM norm D 1-2
kph m % throttle
0F 00 80
1E 33 C0
3C 19 F0
53 00 F0
FF 00 FF

94 JDM norm D 2-1
kph m % throttle
0F 00 80
0F 00 C0
2D 19 F0
FF 00 FF

94 JDM pow D 1-2
kph m throttle
14 00 80
23 20 A0
2F 15 B0
40 3C F0
53 00 F0
FF 00 FF

94 JDM pow D 2-1
kph m % throttle
0F 00 80
0F 00 C0
2D 19 F0
FF 00 FF

94 JDM normal D 2-3
kph m % throttle
18 00 80
3C 15 B0
5A 22 F0
95 00 F0
FF 00 FF

94 JDM pow D 2-3
kph m % throttle
18 00 80
3C 0c 9C
50 0C AC
79 1A F0
95 00 F0
FF 00 FF

[b3lha]

Phil,
In response to requests from the Australian side of the globe to port my tcu maps over to the JDM tcu's I did. I think you'll probably prefer to run these maps and let throttle application engage power mode instead of forcing it with the button. Let me know what you think. Here are the plots.


Thanks Michael,

My test car was in an minor accident and it's parked up waiting for parts. I will definitely give this a try when I get it fixed. Hopefully soon.

Do you mean Australia or New Zealand? I didn't think there were any JDM cars in Australia. A JDM ROM doesn't work with an Aussie Gearbox because of the VSS2 difference.

I've been trying to get a dump of an Aussie TCU. I suspect it's the same as the UK model. I burned a couple of modified roms for somebody in Aus with the UK rom as a base but I haven't had any feedback yet.

[longassname]

Ya, Harvey was just telling me that it's the UK not the JDM that matches Australian TCU's. I'll do that one now. Sorry to hear your car is banged up.


Thanks Michael,

My test car was in an minor accident and it's parked up waiting for parts. I will definitely give this a try when I get it fixed. Hopefully soon.

Do you mean Australia or New Zealand? I didn't think there were any JDM cars in Australia. A JDM ROM doesn't work with an Aussie Gearbox because of the VSS2 difference.

I've been trying to get a dump of an Aussie TCU. I suspect it's the same as the UK model. I burned a couple of modified roms for somebody in Aus with the UK rom as a base but I haven't had any feedback yet.

[longassname]

I just looked at the uk maps and my us maps will port over to it without modifcation so I'll have it done tonight. I'll post them too.

[b3lha]

I just saw that thread.:)

Assuming the UK rom will work with an Aussie box, you can pull the 705622 rom from my website. Either the original or my modified version.

For the modified version, I changed the program logic so that "Econ" mode isn't used. The TCU will select Normal if the Econ switch is on and Power if it is off.

I coded that before I figured out how the shift maps work. If I was doing it again, I would just replace the economy maps with your sporty maps and leave everything else stock.

[longassname]

the uk tcu drives in normal mode and switches to power mode under fast, heavy throttle acceleration right? That's what my maps are good for. The original US maps "sucked eggs" and made the tcu's automatic calculation of power mode vs normal mode a liability. My maps make it work like a thing of beauty.


I just saw that thread.:)

Assuming the UK rom will work with an Aussie box, you can pull the 705622 rom from my website. Either the original or my modified version.

For the modified version, I changed the program logic so that "Econ" mode isn't used. The TCU will select Normal if the Econ switch is on and Power if it is off.

I coded that before I figured out how the shift maps work. If I was doing it again, I would just replace the economy maps with your sporty maps and leave everything else stock.

[longassname]

was more work than i thought but here we go...

http://www.ecutune.com/posts/tcu/uk.gif

http://www.ecutune.com/posts/tcu/ECUtune_uk.gif

[longassname]

and here's the hex for the ECUtune UK shift maps

92 Uk norm D 1-2
kph m % throttle
11 00 80
1E 33 B0
3C 19 F0
57 00 F0
FF 00 FF

92 Uk norm D 2-1
kph m % throttle
0F 00 80
0F 00 C0
2D 19 F0
FF 00 FF

92 Uk pow D 1-2
kph m throttle
12 00 80
2F 16 B0
42 35 F0
57 00 F0
FF 00 FF

92 Uk pow D 2-1
kph m % throttle
0F 00 80
2D 19 F0
FF 00 FF

92 Uk norm 2-3
kph m % throttle
1E 00 80
46 13 BC
5A 1B F0
7A 00 F0
9C 00 F0
FF 00 FF

92 Uk pow 2-3
kph m % throttle
28 00 80
51 0C AC
7E 18 F0
9C 00 F0
FF 00 FF

[b3lha]

Something we haven't discussed so far is how the TCU chooses whether to use Normal mode or Power mode. When you step on the gas, the TCU has to decide whether to stay in Normal mode or switch to Power mode. when you back off a little, it has to decide whether to keep power mode on, or go back to normal mode. I researched this a while ago but never properly documented it. It seems like something that might be fun to modify. By fiddling with this we can make the car more eager to engage power mode on kickdown, or make it keep power mode longer after easing off.

We start off with 4 variables: P, V, O & K.

P (0x00C1). This is the Power mode Timer.

V (0x0018). This is the Vehicle speed in km/h.

O (0x004C). This is the Throttle Opening, a number between 0 and 7. But it's not a linear relationship. The table at location C83C maps Throttle Position% to Throttle Opening. The throttle opening value is used in lots of places in the TCU code, so it probably wouldn't be a good idea to mess with this table.

0000C830 .. .. .. .. .. .. .. .. .. .. .. .. 00 10 16 20
0000C840 30 40 50 60 FF .. .. .. .. .. .. .. .. .. .. ..

The numbers in the table relate to the TPS voltage, 00=0v and FF=5v.

TPS Voltage Throttle Percent Throttle opening
0.00 to 0.30 0% to 5% 0
0.31 to 0.42 6% to 8% 1
0.43 to 0.62 9% to 12% 2
0.63 to 0.93 13% to 18% 3
0.94 to 1.24 19% to 24% 4
1.25 to 1.56 25% to 30% 5
1.57 to 1.87 31% to 37% 6
1.88 to 5.00 38% to 100% 7

K (0x0048). This is the Kickdown speed. The rate of increase of throttle. How fast you step on the pedal.

Now we start to look at the logic. When deciding which shift mode to use, the TCU first calculates a variable B:

B is the speed band it is worked out from a table at location C84D.

0000C840 .. .. .. .. .. .. .. .. .. .. .. .. .. 1E 3C 5A

Speed (km/h) Band
0 to 29 0
30 to 59 1
60 to 89 2
90+ 3

Now the TCU checks whether it is already in power mode. If not, it calculates an index I = (B*4)+(O/2). The Index is used to lookup a table at C850. This table provides a threshold value T. The Kickdown speed is compared to the Threshold. If K > T then the TCU switches to Power mode.

0000C850 96 96 6E 6E 78 78 5A 5A 6E 6E 50 50 64 64 50 50

Speed Band 0, throttle opening 0 - 1, threshold=96
Speed Band 0, throttle opening 2 - 3, threshold=96
Speed Band 0, throttle opening 4 - 5, threshold=6E
Speed Band 0, throttle opening 6 - 7, threshold=6E

Speed Band 1, throttle opening 0 - 1, threshold=78
Speed Band 1, throttle opening 2 - 3, threshold=78
Speed Band 1, throttle opening 4 - 5, threshold=5A
Speed Band 1, throttle opening 6 - 7, threshold=5A

Speed Band 2, throttle opening 0 - 1, threshold=6E
Speed Band 2, throttle opening 2 - 3, threshold=6E
Speed Band 2, throttle opening 4 - 5, threshold=50
Speed Band 2, throttle opening 6 - 7, threshold=50

Speed Band 3, throttle opening 0 - 1, threshold=64
Speed Band 3, throttle opening 2 - 3, threshold=64
Speed Band 3, throttle opening 4 - 5, threshold=50
Speed Band 3, throttle opening 6 - 7, threshold=50

Looking at the table, it is clear that Subaru have not taken full advantage of the flexability available. They have defined the thresholds in pairs. Within each speed band, they have simply pecified a low throttle threshold and a high throttle threshold. The borderline between low and high throttle being 19%.

If you've followed me so far then you will realise that at low speed and throttle, it takes a faster kick to engage power mode. At higher speeds, and with more throttle, a slower kick will do it.

So that is how power mode gets engaged. Now we'll deal with how it gets disengaged.

After calculating B, if the TCU is already in power mode, it uses B to lookup a table at C860. There are 4 entries in the table, two bytes each.

0000C860 02 4B 02 4B 03 32 04 19 .. .. .. .. .. .. .. ..

The first byte of each entry is a threshold A. The throttle opening O is compared against the threshold. If O > A then the second byte gets written to the powermode timer P. The timer counts down and when it gets to zero, the TCU switches back to Normal mode. But while it is counting down, the TCU is continually re-evaluating this condition and resetting the counter. Only when O < A is the counter allowed to timeout.

To explain a bit better, if B=0, then A will be 2 and the timer will be set to 4B. Provided the throttle opening remains greater than 12%, the TCU will keep resetting the timer to 4B and power mode will stay on. Once the throttle opening falls below 12%, the timer will tick down to zero and the TCU will switch back to Normal mode. The values 4B, 32 and 19 represent 3, 2 and 1 seconds respectively. At low speed, power mode will stay on for 3 seconds after you lift off. At higher speed it will be 2 seconds or 1 second if you are doing more than 90km/h.

[longassname]

Very nice. This would be a great way for anyone who wants to start playing with their TCU to start, especially a US owner. You could get at many of the same problems I went after with the shift maps by making the tcu go into power mode instead and this adjustment is much simpler to make. I use the power mode 2 to 1 map (or it's mathmatical equivalent in some instances)for the normal mode 2 to 1 map. This is one of the bigest changes I made and pretty much the same thing could be accomplished by making it very easy to get into power mode at low speed.

[b3lha]

I was just talking to Ron (Needforspeed) about TCU maps and he came up with a fantastic new idea for a mod. No TCU reprogramming necessary.

As I documented earlier, the USDM TCU has some extra shift modes that are controlled by the atmospheric pressure sensor. At low altitude, it uses Normal Mode, at medium altitude it uses LowPres1 mode, at high altitude it uses LowPres2 mode and at very high altitude it uses Power mode.

These modes increase in aggressiveness from Normal, through LowPres1 and LowPres2 to Power.

The sensor resides in the ECU and the signal is carried to the TCU by a wire. The idea is to cut this wire and install a potentiometer or a resistor ladder with a 4 position knob. This would allow the driver to control the aggressiveness of the shifting at 4 different levels. Like a 4 position power mode switch.

The only possible problem I see with this is that the atmospheric pressure signal is also used in the line pressure calculation. I haven't looked into the specifics yet, but presumably it means harder shifts in the high altitude modes. It may turn out to be another advantage of this mod rather than a problem.

http://www.alcyone.org.uk/ssm/tcupres.jpg

[SuberNatural]

I would be very interested in exploring the new option you have mentioned :)

[b3lha]

I've been comparing early and late model TCUs to find the differences. I have found a change to the "Overheat-Stick2-Gear2-Lock" map for the Torque Converter. This map governs TC lockup when the stick is in position 2, the transmission is in 2nd gear, and the ATF is too hot.

When the throttle is less than 3%: Early models will not lock the TC. Later models will lock it above 50km/h.

This applies to JDM and UK models. I haven't investigated whether the same applies to US models.

It's a very specific and uncommon set of circumstances, I can't really imagine what Subaru were trying to fix.

[longassname]

Hey Phil,

Speaking of JDM and UK TCUs I think you forgot to post the rev limit locations for them. If you did I just didn't see them or remember seeing them. Here are the locations and what I've been changing them to. Thanks for the basecode by the way. I've shipped a UK ROM to a guy in Australia so we should get feedback on that soon. Do you have your car back on the road yet? I can send you a bin to save you the copy and paste if you want to try my maps.

JDM
D95F=68 : increase in rpm limit for 1-2 shift
D960=62 : increase in rpm limit for 2-3 shift
D961=62 : increase in rpm limit for 3-4 shift
D963=68 : increase in rpm limit for 1-2 shift
D964=62 : increase in rpm limit for 2-3 shift
D965=70 : increase in rpm limit for 3-4 shift

UK
d7C0=68 : increase in rpm limit for 1-2 shift
d7C1=62 : increase in rpm limit for 2-3 shift
d7C2=62 : increase in rpm limit for 3-4 shift
d7C4=68 : increase in rpm limit for 1-2 shift
d7C5=62 : increase in rpm limit for 2-3 shift
d7C6=70 : increase in rpm limit for 3-4 shift

[b3lha]

Thanks for posting that Michael. I don't have my car back on the road yet, but I some good leads on the parts I need.

I tried to install one of my modified TCUs for somebody last weekend and it wasn't working right. I think the TCU software crashed. No power light, wouldn't change out of 2nd, sol c binding, and occasional flashes on the AT OIL TEMP and DIFF LOCK lights.

Rather embarrassing for me, but he was very understanding and took it in good humour. I'm going to check my soldering carefully, reflash the chip and try again.

He let me take a copy of his late model UK TCU, which I've posted on my website. There are some code differences to the early model, presumably bug fixes and improvements. It might be a better base code for future work.

[longassname]

Does your programmer verify after it writes? I've seen some friends who do their own tuning who use cheap programmers have terrible problems. In fact I know a lot of people who use cheap programmers in addition to having problems with the timing routines which are handled in software make a practice out of writing all their ROMs twice to make sure their hardware doesn't leave any of the bits borderline.

My BP microsystems device programmer has never failed a write but if it did I would know about it. It verifies twice after writing (writing and verifying together takes 3 or 4 seconds total for the devices we are using). They recently dropped their support of the parallel port models which just means they aren't updating the software with new devices. If you keep your eyes open on ebay you may be able to find one for a good price and be way better off than with a cheapy that just doesn't have the real goods inside.


I'll switch to the new UK base code before I send any more out. Thanks




Thanks for posting that Michael. I don't have my car back on the road yet, but I some good leads on the parts I need.

I tried to install one of my modified TCUs for somebody last weekend and it wasn't working right. I think the TCU software crashed. No power light, wouldn't change out of 2nd, sol c binding, and occasional flashes on the AT OIL TEMP and DIFF LOCK lights.

Rather embarrassing for me, but he was very understanding and took it in good humour. I'm going to check my soldering carefully, reflash the chip and try again.

He let me take a copy of his late model UK TCU, which I've posted on my website. There are some code differences to the early model, presumably bug fixes and improvements. It might be a better base code for future work.

[b3lha]

Does your programmer verify after it writes? I've seen some friends who do their own tuning who use cheap programmers have terrible problems. In fact I know a lot of people who use cheap programmers in addition to having problems with the timing routines which are handled in software make a practice out of writing all their ROMs twice to make sure their hardware doesn't leave any of the bits borderline.


Yeah, i verified the chip. The EPROM is fine.

Looks like I damaged a track on the board when I removed the original ROM. One of the address lines. I think next time I'll try moving the resistor instead of unsoldering the chip.

[longassname]

Sounds like a plan. You should be able to fix that tcu with a piece of wrapping wire or solid core phone wire depending on the size of the track broken. Just remove some solder mask on both sides and solder a piece of wire over the breach.

[b3lha]

I have a ton of TCU's here if anyone needs a spare, pay shipping and its yours.

Tom

Tom,

If this offer is still open, I'm looking for two TCUs. If you let me know the shipping cost to London, UK then I'll send you a paypal.

Phil.

[longassname]

If you want to route them through me I'll socket them for you.

[b3lha]

If you've followed me so far then you will realise that at low speed and throttle, it takes a faster kick to engage power mode. At higher speeds, and with more throttle, a slower kick will do it.

Just reading back through my notes. I'm wondering if I got this the wrong way around?

It would make more sense that the power mode is engaged by a slower kick at low speed/throttle or a faster kick at high speed/throttle? That's why it's easier to trigger power mode if you lift off first.

At high speed+high throttle, it takes a very fast kick to engage power mode. If you lift off first, (high speed+low throttle) a slower kick will do the job.

[longassname]

I don't know. You're way out ahead of me on the tcu now. In fact a couple days ago I sat down to change the temp that the atf temp warning light comes on and apparantly got it wrong. It looked to me like pj2 is the output to the temp warning light and comparing c025 to the output from the temp sensor (looked like ad2) in the calculate atft routine set or cleared it (bit two of bitmask stored at 0010 then moved to 1031). Changing that value didn't work though so I'm going to wait till I get a chance to interogate the tcu in operation before I go back and look for my mistake.

[b3lha]

I don't know. You're way out ahead of me on the tcu now. In fact a couple days ago I sat down to change the temp that the atf temp warning light comes on and apparantly got it wrong. It looked to me like pj2 is the output to the temp warning light and comparing c025 to the output from the temp sensor (looked like ad2) in the calculate atft routine set or cleared it (bit two of bitmask stored at 0010 then moved to 1031). Changing that value didn't work though so I'm going to wait till I get a chance to interogate the tcu in operation before I go back and look for my mistake.

I agree with your analysis.

I think C024 is the "on above" temperature, C025 is the "off below" temperature.

On above 244 degrees (0xF4), off below 238 degress (0xEE).

I don't know much about transmissions, but it would make sense to me if the "warning light" limits matched the "overheat mode" limits: 233 degrees and 230 degrees (hardcoded at 0xE200). That way the light tells you when the trans is using the overheat shift mode.

[longassname]

ah, someone else finding my mistake..that's even better :) thanks

Someone asked for 215 which sounds reasonable to me. I was thinking maybe even a bit lower. It is a warning after all. If we set it to say 205 then we'll actually be warned if we are getting into temps we don't want to be in. 230 is more like omg quick stop the transmission from destroying itself. Ideally you want to run at 176 all day long.

[longassname]

are you sure the temp is in F?

I'm looking at it now and it's it's just the ones complement of the da 2 register unless the value is below 14h in which case it defaults it to the value stored at c062.

The MC68HC11G5 datasheet says the da operates from 0 to 5v (0 to 5v range taken from sensor data from fsm) with 5v resulting in ffc0 in the register and 0v resulting in 0000.

The FSM says:
20c=68f=3 to 3.5v
80c=176f=1 to 1.3v
(note 2 volts change = 60c = 1 volt per 30c in normal operating range of sensor, theoretical range then is 0 to 150c)

case 0v = max temp of sensor:result ff is stored for atft
00 in ad register
ones complement of 00 is stored to atft = ff

case 5v = min temp of sensor:result default value e2 is stored for atft
ff in ad register
ones complement of ff =00
E1D5 ldaa LC062 (e2 loaded into acc a from c062)
E1D8 bra LE1E5
E1E5 LE1E5: staa *ATFT (e2 stored as atft)

case 3v = known to be about 20c = 68f from fsm: 66h=102 is stored for atft
99 in ad register
ones complement of 99 = 66h = 102 decimal
E1DD suba *ATFT (66-66= 0)
E1DF adda #0x02 (0 + 2 = 2)
E1E1 asra (00000010 becomes 00000001) (same as halving)
E1E2 asra (00000001 becomes 00000000) (halving again)
E1E3 adda *ATFT (0 + 66 = 66)
E1E5 LE1E5: staa *ATFT

case 1v = known to be about 80c = 176f from fsm: cc = 204 is stored for atft
33 in ad register
ones complement of 33 = cc = 204 decimal
E1DD suba *ATFT (33-33= 0)
E1DF adda #0x02 (0 + 2 = 2)
E1E1 asra (00000010 becomes 00000001) (same as halving)
E1E2 asra (00000001 becomes 00000000) (halving again)
E1E3 adda *ATFT (0 + 33 = 33)
E1E5 LE1E5: staa *ATFT

[b3lha]

are you sure the temp is in F? I wasn't about to figure out the math resulting from the odds complement and all those compares but I was thinking it was value - 127 = degrees C.

No. I don't know for sure. Degrees C would certainly make more sense to me.

I originally estimated it by reading the value when the car had been parked for a couple of days. Obviously the ATF temp should approximately match the engine coolant temp in that situation.

[longassname]

woops, you were responding while I was editing..I went ahead and traced out what sensor readings result in what being stored. It doesn't look like either of our first guesses would pan out.

[longassname]

soooo

degrees c = .5882 (atft value) -40

?

[longassname]

20c=68f=3 to 3.5v
80c=176f=1 to 1.3v
(note 2 volts change = 60c = 1 volt per 30c in normal operating range of sensor, theoretical range then is 0 to 150c)

or using the middle of the voltage ranges given for the temps in the fsm:

20c=3.25v -->(3.25/5*255=166=a6) --> (ones complement of a6)5a=90
80c=1.15v -->(1.15/5*255=59=3b) --> (ones complement of 3b)c4=196

(80-20)=m(196-90) m=.566

80=.566(196)+b b=-31
20=.566(90)+b b=-31

y=.566x-b
degrees c = .566(atft value) -31

[longassname]

I'll eavesdrop on the select monitor to get some values to double check/refine the equation.

for now it's looking like I'll try something like
c024:e7
c025:df

expecting the warning light to come on at 100c=212f and go off at 95c=203f

[b3lha]

degrees c = .566(atft value) -31


That's why I was thinking Fahrenheit.

C=0.556F-32

Actually, I was surprised that the TCU doesn't use a graph to map sensor voltage to temperature like the ECU does. If it's anything like the ECU, it may not be linear at the top and bottom of the scale.

Have you ever tried reverse engineering the Select Monitor itself?

[longassname]

I just emailed you the bins.

[longassname]

I think celcius = .556 (farenheit-32)



That's why I was thinking Fahrenheit.

C=0.556F-32

Actually, I was surprised that the TCU doesn't use a graph to map sensor voltage to temperature like the ECU does. If it's anything like the ECU, it may not be linear at the top and bottom of the scale.

Have you ever tried reverse engineering the Select Monitor itself?

[b3lha]

I think celcius = .556 (farenheit-32)
Yeah. You're right. My mistake.:o:rolleyes:

[longassname]

I've gone with setting
c025 and e201 to df
and
c024 and e208 to e7

[longassname]

looks like the equation from using the middle of the voltage ranges given in the fsm is exactly correct.

I set c024 to 82 and c025 to 65 (110F) --> warning light came on at 111F

since the bit is set to turn the warning light on after failing a branch if lower or the same 111f is exactly right.

[b3lha]

looks like the equation from using the middle of the voltage ranges given in the fsm is exactly correct.

I set c024 to 82 and c025 to 65 (110F) --> warning light came on at 111F

since the bit is set to turn the warning light on after failing a branch if lower or the same 111f is exactly right.

How about this for a nice simple formula:

Degrees F = value - 20

[b3lha]

I just emailed you the bins.

Thanks. Very Interesting. I already disassembled the 92 bin. Any idea what cpu? The 68HC11 seems to be about 99.9% perfect, but the ROM has a few opcodes in the extension table (0x18 prefix) that aren't in the datasheet. Doesn't matter too much, I have enough good code to follow.

[longassname]

it's a hitachi 630x: hd63b03yp

clocked by a 4000 xtal

it uses a toshiba tc74hc125 for the signal from the ecu by the way (clamped before the 125)

[longassname]

Actually the tx from the ecu is pulled high and clipped not clamped and the rx line is clipped on both sides then they go through the 74hc125 to pins 12 and 13 on the 6303

I made a schematic to duplicate the select monitor interface for an interface to a ftdi ttl232r cable: http://www.ecutune.com/posts/ttl232r-selectmonitor.pdf

[longassname]

also, although it is not used I think that wire from the ecu select monitor port that nobody knows what it is is either vcc from the ecu or a comparitor input for the rxd. It is routed straight through the select monitor to pin 35 of the cartridge. In the 92 select monitor cartridge that pin traces to a dead end at a through hole for a resistor. If the resistor was installed it would connect to vcc. I suspect it is vcc from the ecu.

[b3lha]

The select monitor rom is a gold mine of information.

As expected, it has the commands for querying ecu, tcu, a/c, cruise and 4ws. Plus a full list of the parameter addresses and trouble codes. I'll document it all when I get a bit further.

I've been looking at the routines that validate the TCU romid. It supports THREE :eek: types of TCU:

7054xx: ACT4 (USDM).
7055xx: WTF???
7056xx: VTD (JDM and UK).

What could the 7055xx be? :confused:

[b3lha]

Actually the tx from the ecu is pulled high and clipped not clamped and the rx line is clipped on both sides then they go through the 74hc125 to pins 12 and 13 on the 6303

I made a schematic to duplicate the select monitor interface for an interface to a ftdi ttl232r cable: http://www.ecutune.com/posts/ttl232r-selectmonitor.pdf

That's awesome. An interface design that is guaranteed to work!

[longassname]

sweet

maybe it's the tcu from the us obd2 svx. I just got one. I'm doing a lot of soldering today but I'll try to pull the firmware off all the US tcu's you don't already have the firmware for and email them to you today. I'll take a couple pictures of the 96 tcu. Same plugs, same box.

[longassname]

you got all the obdII ecu parameters and com commands from the 96 select monitor bin now right? :D

[longassname]

i saw a picture of a select monitor II on your website; do you have one/can you get your hands on it again to look inside? I happen to own a master cartridge for all 01 through 04 model subarus.

[b3lha]

maybe it's the tcu from the us obd2 svx.

It's in the 1992 cartridge.


I just got one. I'm doing a lot of soldering today but I'll try to pull the firmware off all the US tcu's you don't already have the firmware for and email them to you today. I'll take a couple pictures of the 96 tcu. Same plugs, same box, don't remember seeing an atmospheric pressure sensor.

you got all the obdII ecu parameters and com commands from the 96 select monitor bin now right?


Thanks. I'm looking at the 92 cartridge first because everything I've worked on so far has been OBD1. I assume there must be some memory paging going on with the 96 rom because it's 64k not 32k. I'm pretty sure I can figure it out when I get around to it.


i saw a picture of a select monitor II on your website; do you have one/can you get your hands on it again to look inside? I happen to own a master cartridge for all 01 through 04 model subarus.

No. I just pulled that picture off the net. I've been negotiating to borrow one off somebody. I was planning to eavesdrop every single cartridge and post the parameters on my site. A lot of people are guessing addresses for datalogging and getting them wrong.

[longassname]

No. I just pulled that picture off the net. I've been negotiating to borrow one off somebody. I was planning to eavesdrop every single cartridge and post the parameters on my site. A lot of people are guessing addresses for datalogging and getting them wrong.

It would be a lot faster to pull them off the master cartridge. I believe the 2001-2004 is the least supported range of obdII Subarus so that should fill in a big gap of knowledge. I'll pull and read the ROM off it and send you the bin.

[b3lha]

When I built my first cable, I did a scan of all the possible SSM command bytes and found 78 (ecu), 45 (tcu) and 89 (a/c). The cruise and 4ws units did not respond.

In the select monitor code, there is an extra step when talking to the cruise control unit:

example:

a26d 96 40 ldaa (0x0040) ; Unit Flags: x,y,z,4ws,crs,a/c,tcu,ecu
a26f 85 08 bita 0x08 ;
a271 27 06 beq [0xA279]
a273 d6 11 ldab (0x0011) ; TxRx CSR1
a275 ca 06 orab 0x06 ; Transmit_Enable + Transmit_Interrupt_Enable
a277 d7 11 stab (0x0011) ; TxRx CSR1


I'm wondering if this is some kind of flow control. Presumably using pin 4 of the yellow plug B35.

[longassname]

It looks like the extra wire from the cruise control control unit is the same as the extra wire from the ecu. I just traced it and it also goes straight to pin 35 of the cartridge which I discovered yesterday dead ends where there is no resistor installed to connect it to vcc in the cartridge.

that does mean the two are connected when the select monitor is plugged in so the ecu could be providing something to the cruise control unit

[longassname]

i just probed the select monitor connector on my car and pin 8 wasn't showing any continuity to the other pins. pin 4 looked to be pulled low through a 4k resistor showing 4k continuity between ground and 12v and showing 12v between it and 12v.

[longassname]

when you get a chance if you could check the values of r213 and r315 and see if there is a r408 and 409 in the uk and jdm tcu I'd appreciate it.

[oab_au]

when you get a chance if you could check the values of r213 and r315 and see if there is a r408 and 409 in the uk and jdm tcu I'd appreciate it.

R408, and R409 are both present on the Aust board.

Harvey.

[longassname]

thanks, what's the part number on your board? how about the lable on the ROM that's in it?


R408, and R409 are both present on the Aust board.

Harvey.

[longassname]

I figured out why I couldn't find my 94 bin before. The 705404 firmware is the firmware out of the e23aa12p ROM from a 93/94/95 TCU (I just read an e23aa12p ROM and that's what came out of it and I compared it to your 705404 and they are in fact identical). We should have nomake check the ROM id on his TCU. I'm guessing he has a TCU with the e23aa12p ROM. The firmware you don't have is from the e23aa11p ROM and the obdII firmware from the mq labled tcu with the e34ua1dL ROM.

[oab_au]

thanks, what's the part number on your board? how about the lable on the ROM that's in it?

The board No. A64-001 67.
Rom No. E34EV1D1

Harvey.

[longassname]

67 or 637?


The board No. A64-001 67.
Rom No. E34EV1D1

Harvey.

[b3lha]

when you get a chance if you could check the values of r213 and r315 and see if there is a r408 and 409 in the uk and jdm tcu I'd appreciate it.

r213 - I see the label but I don't see a resistor anywhere nearby. There are two large rectangular solder blobs. Is that where it is supposed to be?

r315 - 103
r408 - present
r409 - present

[b3lha]

I was thinking about the 7055xx.

I think that it is for a US-style ACT4 TCU in markets where the ECU doesn't have an atmospheric pressure sensor.

The TCU code checks the 2nd byte of the ROM id before reading the atmospheric pressure signal from the ECU.

[longassname]

yes thos are the pads. what is the part # on your board and is it uk or jdm?



r213 - I see the label but I don't see a resistor anywhere nearby. There are two large rectangular solder blobs. Is that where it is supposed to be?

r315 - 103
r408 - present
r409 - present

[longassname]

that's what, the 5 the sold to the saudi's? lol


I was thinking about the 7055xx.

I think that it is for a US-style ACT4 TCU in markets where the ECU doesn't have an atmospheric pressure sensor.

The TCU code checks the 2nd byte of the ROM id before reading the atmospheric pressure signal from the ECU.

[b3lha]

yes thos are the pads. what is the part # on your board and is it uk or jdm?

A64-001 637.

It's a UK board. I'll have to pull the car apart to check the JDM one.

[oab_au]

67 or 637?

Yes sorry 637.
R213 is not on the board.

Harvey.

[longassname]

That's the same board as the US market then. So it sounds like all I have to do is pull out r213 and install the right firmware to make UK TCU's.


A64-001 637.

It's a UK board. I'll have to pull the car apart to check the JDM one.

[longassname]

thanks, what'st he value of r315?

Yes sorry 637.
R213 is not on the board.

Harvey.

[oab_au]

thanks, what'st he value of r315?


R315 is 103.

Harvey.

[b3lha]

That's the same board as the US market then. So it sounds like all I have to do is pull out r213 and install the right firmware to make UK TCU's.

The metal case differs between RHD and LHD.

I've had a UK TCU with JDM firmware working fine in a JDM car. So UK and JDM are definitely interchangable.

What does R213 do on the US model?

[longassname]

Thanks, ok so we all have the same hardware except for r213 and the metal box.

Phil I don't guess by any miracle the label on your uk ROM matches the label on Harvey's ROM?

I'm going to guess that it has something to do with e-rev--maybe it was speed--I can't remember for sure. The 75402 id ROM is something special Subaru has played with. I've gotten a couple of them and they have hand written labels indicating different rev limits, written on the same label paper Subaru uses for all their ROMs, and written on the same ROM chip Subaru uses when they do install a dip chip. One of them came in an older TCU a lower part number and a weird label. That one has a different part number on the board with an actual pin header instead of just the pads for it, but installed in the other corner and the differences in the resistors I was asking about. I plugged it into my car once upon a time way back when and I remember it reported either the speed or erev incorrectly.


R315 is 103.

Harvey.

[oab_au]

I have found a few other differences between the Aust and the US boards. You all may know them already.

The Aust. has; R214, R232, R233, R230.
Does not have; C102, R238, R235.

Harvey.

[longassname]

i think the 75402 firmware reported the right erev or speed, whatever it was when in the tcu I pulled it out of and the wrong value when in the standard us tcu...i still don't remember which value it was that was wrong.

I don't know if i'm into researching it too thoroughly right now. I only asked now because I had a dozen TCU's torn apart today and had run into a weird one. I've been soldering all day and am no longer thinking straight. It's time to call it a day and get dinner.

[b3lha]

Thanks, ok so we all have the same hardware except for r213 and the metal box.

Phil I don't guess by any miracle the label on your uk ROM matches the label on Harvey's ROM?

I'm going to guess that it has something to do with e-rev--maybe it was speed--I can't remember for sure. The 75402 id ROM is something special Subaru has played with. I've gotten a couple of them and they have hand written labels indicating different rev limits, written on the same label paper Subaru uses for all their ROMs, and written on the same ROM chip Subaru uses when they do install a dip chip. One of them came in an older TCU a lower part number and a weird label. That one has a different part number on the board with an actual pin header instead of just the pads for it, but installed in the other corner and the differences in the resistors I was asking about. I plugged it into my car once upon a time way back when and I remember it reported either the speed or erev incorrectly.

Is it something like the board pictured in the paddle-shift thread?

http://www.subaru-svx.net/forum/showpost.php?p=575654&postcount=1

[longassname]

no, that one is a lot different. This one has an a64-001-632 board which has the same chipset as our a64-001-637 boards. I only see a few resistors different and the pin header exists and is in a different location.

I think if and when we take the time to make a thorough comparison of what's on our boards and trace those differences to ad's we'll find we only have to change up a few resistors to go from different speed sensors and possibly gear ratios.

[longassname]

deleting incorrectness :/

[longassname]

Ok so what I see is:

Ausie tcu has r230 ->pin10=pj3 (output in us firmware)
common us tcu has r228 ->pin8=pa1 (input in us firmware)
these resistors are alternatives to each other leading to q202

q202 connects to r214 and r213
in common us tcu r213 connects to b68 pin 6 which I can't find in fsm
ausie tcu has r214 connecting to b68 pin 6

so
1)what is pin 6 on b68
2)how are pj3 and pa1 configured in uk/ausie tcu firmware?








I have found a few other differences between the Aust and the US boards. You all may know them already.

The Aust. has; R214, R232, R233, R230.
Does not have; C102, R238, R235.

Harvey.

[longassname]

ok, i just figured out the e isn't part of the position label it is labeling the emitter. There is an interplay between several transistors involved in this whatever it is.

[b3lha]

I know what pin c6 is for. It's something to do with the different speed sensor arrangement in UK/Aussie TCUs.

The USA & JDM have VSS2 in the front diff. It connects to pin a11 of the TCU and also drives the ECU and Speedo.

The UK & Aussie have VSS2 located inside the gearbox and it produces a different type of signal. It connects into pin a17 of the TCU. The TCU then outputs a US-style VSS2 signal on pin c6 which feeds the ECU and Speedo and also loops back into pin a11 of the TCU.:rolleyes:

I think the signal conversion that happens in between pin a17 and c6 is at least partly done in software, but I haven't found it in the code. If the TCU software crashes, the speedo gets no signal. If you use a JDM TCU in a UK car, the speedo reads incorrectly.

I'll try and pull my JDM TCU sometime this week to check if it has the resistor like the US model.

[longassname]

change "several" to a kajillion and about a bazillion resistors

[longassname]

I've gone crosseyed working through all these transistors and resistors. It was way to complex to figure the logic without drawing it out. I was working through it with the multimeter and drawing it out but when I ran out out space on one side of my paper I took it as an excuse to stop.

[oab_au]

Ok so what I see is:

Ausie tcu has r230 ->pin10=pj3 (output in us firmware)
common us tcu has r228 ->pin8=pa1 (input in us firmware)
these resistors are alternatives to each other leading to q202

q202 connects to r214 and r213
in common us tcu r213 connects to b68 pin 6 which I can't find in fsm
ausie tcu has r214 connecting to b68 pin 6

so
1)what is pin 6 on b68
2)how are pj3 and pa1 configured in uk/ausie tcu firmware?

Pin 6 on b68 is the speedo output. What do you call pj/pa?

Harvey.

[oab_au]

Both the speed signals are a sine wave, so there would be some extra conversion to square wave.

Harvey.

[longassname]

those are port labels in the m68hc11 microcontroller--basically pins on the micro that in their particular cases can be either inputs or outputs depending on the software configuration. The firmware sets bits in the data direction registers for each port which define if the corresponding port pin is used as an input or output.

[longassname]

I think q202 is an npn transistor with its emitter connected to vss, its collector connected to b68 pin 6 through r213 (in the us case) and to vss through a diode, and it's base connected to a huge jumble of resistors, other transistors, capacitors, and eventually somewhere some inputs.

With the emitter connected to vss and and the collector connected to vss through the diode the connection to the base to the resistor going to +v at c061 should put the transistor in saturation mode by default. Then the jumble of other stuff connected to the base would counteract the path to +v reducing the forward bias towards 0. So it will pass whatever the other stuff sends it. If it's analog it will pass analog if it's digital it will pass digital.

Then again I could be completely wrong. The only pin I know for sure is the emitter because I have no idea what the part number of the transistor is.


Both the speed signals are a sine wave, so there would be some extra conversion to square wave.

Harvey.

[oab_au]

B68/6 looks like an input on your board and an output on mine. There are about 6 surface mounts on the other side that are different to the US one, maybe more. :(

What has got to happen in the process of the US and AU/UK is similar but different.

Both would treat the rear sensor the same way. As they are both sine wave at output shaft speed, they would be converted to square wave/digital.

The US front sensor is square wave at road speed. That would be sent to the speedo, and to the TCU to be multiplied by the 3.45 diff ratio, to compare with the rear sensor.

The AU/UK. front sensor is a sine wave at output shaft speed. This would be converted to digital, divided by the 3.7 diff ratio, and sent to the speedo.

Harvey.

[b3lha]

b68/6 has no wire in the JDM harness. It is unused as I described in post 154.

[longassname]

what do the uk and jdm tcu's have connected to the pins that are the fwd light and fwd fuse on the usdm ( b68#2 and b66#2)


b68/6 has no wire in the JDM harness. It is unused as I described in post 154.

[b3lha]

what do the uk and jdm tcu's have connected to the pins that are the fwd light and fwd fuse on the usdm ( b68#2 and b66#2)

Centre Diff Lock light and fuse.

IIRC the JDM pinout is the same as the USDM pinout except for the addition of the power mode switch wire.

[b3lha]

moving the resistor from r432 to r431 will put the surface mount in output dissable mode

I know this is a dumb question, but I haven't come across 0 ohm resistors before. Presumably I could remove R432 and jumper R431 with a piece of wire?

What do you think about using an SPDT switch to select between the stock or modified roms? IIRC R431 and R432 share a common track at one end.

[longassname]

Ya a piece of wire would do the same thing. The spst switch won't work though. The way it's set up the dip socket is always active. Moving the resistor isn't activating the dip socket it's deactivating the surface mount. There may be another resistor that can be removed to deactivate the dip socket but I don't remember off hand.

You could always use one of my multitune adaptors to switch between the upper and lower half of a 512 ROM.


I know this is a dumb question, but I haven't come across 0 ohm resistors before. Presumably I could remove R432 and jumper R431 with a piece of wire?

What do you think about using an SPDT switch to select between the stock or modified roms? IIRC R431 and R432 share a common track at one end.

[b3lha]

Ya a piece of wire would do the same thing. The spst switch won't work though. The way it's set up the dip socket is always active. Moving the resistor isn't activating the dip socket it's deactivating the surface mount. There may be another resistor that can be removed to deactivate the dip socket but I don't remember off hand.

You could always use one of my multitune adaptors to switch between the upper and lower half of a 512 ROM.

OK. Thanks. I should have realised that.

Presumably your multitune adapter just switches pin A15 between Vcc and Ground?

[longassname]

more or less. The multitune adaptors are a pretty slick way of doing something pretty simple. The high address pin is pulled low and an input is provided to send +v to override it to a high. The input is voltage regulated so any +v will do. This allows the switching to be activated by other electronics in the car instead of a person flipping a switch.


OK. Thanks. I should have realised that.

Presumably your multitune adapter just switches pin A15 between Vcc and Ground?

[NiftySVX]

okay, so i've been lurking in this thread for awhile, and i'm not afraid to admit that the programming is way over my head, but I wanted to ask a few questions. Did anyone ever decide if there were any differences between the US tcu as far as year to year changes, I know there was mention of a seemingly pointless mod to the overtemp 2nd gear in the uk tcus. I ask that because I am curious as to the base code that LAN is using for his ecutune controller. Also, did I hear that the original trigger was 244f for the at oil temp light? And finally, how significant is the difference between the low pressure maps on based on the normal and power maps? I have driven my svx at very high altitude in summit county, colorado, and I remember it shifting noticibly different, but i always thought it was my imagination until this thread got going.

Finally, I want to thank you guys for going through all this, because It can make such a huge difference in performance. I mean, many toyota models use the same engine and transmission, but shift differently and it gives the car a completely different feel, so this is a really good way to tweak the car without actually making any mechanical modifications.

[b3lha]

Did anyone ever decide if there were any differences between the US tcu as far as year to year changes, I know there was mention of a seemingly pointless mod to the overtemp 2nd gear in the uk tcus. I ask that because I am curious as to the base code that LAN is using for his ecutune controller.
I don't have a 94-95 USDM version to look at. Only the early version 705404. There are changes in the UK and JDM versions, so there is a good chance they changed something in the US version too.

Also, did I hear that the original trigger was 244f for the at oil temp light?

I think it's 224 with the revised interpretation of the formula.

And finally, how significant is the difference between the low pressure maps on based on the normal and power maps? I have driven my svx at very high altitude in summit county, colorado, and I remember it shifting noticibly different, but i always thought it was my imagination until this thread got going.

Have a look at the graph in this post and try to make sense of it.
http://www.subaru-svx.net/forum/showpost.php?p=590419&postcount=89
The blue line on the left is normal mode. The magenta line on the right is power mode. The low pressure modes are in between. I think the proposed mod with a turn switch and resistor network would be a cool thing to try. It would just need a little experimentation to find the right values for the resistors.

Finally, I want to thank you guys for going through all this, because It can make such a huge difference in performance. I mean, many toyota models use the same engine and transmission, but shift differently and it gives the car a completely different feel, so this is a really good way to tweak the car without actually making any mechanical modifications.
Nice to be appreciated.

[longassname]

Phil, the code you have from Nomake is the code used in the 94 and 95 (and 93 and maybe even some 92s). I pulled the code off a 12p labled ROM again and that's what came off it. That's where the confusion came in when I was looking for my orignal basecode. The question is how early did the 12p ROM start? I'll send you the bin from an 11p ROM and a 96 ROM soon; I've just been busy.

[b3lha]

Phil, the code you have from Nomake is the code used in the 94 and 95 (and 93 and maybe even some 92s). I pulled the code off a 12p labled ROM again and that's what came off it. That's where the confusion came in when I was looking for my orignal basecode. The question is how early did the 12p ROM start? I'll send you the bin from an 11p ROM and a 96 ROM soon; I've just been busy.

I guess that is the latest USDM version then. (apart from the 96 which is presumably rewriten to talk to an OBD2 scanner).

[edmsvx]

There are changes in the UK and JDM versions, so there is a good chance they changed something in the US version too.


So possibly a difference in the later 96+ version, is the temperature at which torque convertor locks up.

My 96 CDN svx will allow the torque convertor to lock as soon as the engine reaches normal operating temperature (outside temp 20 C to -30C no difference). Which for me is about 2 minutes of driving from my house (all uphill). However, for my 92 JDM in need to be driving at least 20 minutes before the torque converter locks up. I found the same with my son's CDN 92 when he had it.

Programing OR were there revisions in the 96 transmision oil pump rate to increase the transfer of heat in the radiator to the transmission oil and/or was there a huge difference in the flow restrictions in the earlier radiator.

My sense is that while pump rate and restrictions may contribute it is most likely programming.

Peter

[cdvs]

I guess that is the latest USDM version then. (apart from the 96 which is presumably rewriten to talk to an OBD2 scanner).

Phil,

AFAIK, the US OBDII requirement was focused on emissions related systems.

I'm sure that we still have to 'bow three times and turn around' to get codes from the '96 transmission.

Charl

[NiftySVX]

Phil,

AFAIK, the US OBDII requirement was focused on emissions related systems.

I'm sure that we still have to 'bow three times and turn around' to get codes from the '96 transmission.

Charl

While targeting emission systems and related functions, the major part of OBD2 was the standardization of the diagnostic connector and its location, as well as the standardization of many of the diagnostic trouble codes. I am sure that the tcu was tweaked to allow communication by a different style of diagnostic tool, and they changed the codes from basic numbers (like 13) to the new style prefix (like P###).

[longassname]

I wouldn't sweat that line of thought much. I imagine Phil already knows the answer to the question you guys are discussing. I sent him the firmware for the 96 svx select monitor cartridge the same day I sent him the firmware for the 92 svx select monitor cartridge and he dissassembled them both the same day. I'm sure he'll post the info on the com commands and codes when he posts the info on the parameter locations and conversion functions.

[cdvs]

While targeting emission systems and related functions, the major part of OBD2 was the standardization of the diagnostic connector and its location, as well as the standardization of many of the diagnostic trouble codes. I am sure that the tcu was tweaked to allow communication by a different style of diagnostic tool, and they changed the codes from basic numbers (like 13) to the new style prefix (like P###).
NiftySVX,

While what you say about standardization is correct, so is my statement that the Requirement focused on emissions systems.

Contrary to what you are sure of, there is no transmission information available through the OBDII connector in our 96. Transmission codes must be retrieved in the usual way. Perhaps yours is different, but I suspect you don't have one.

Charl

[longassname]

come on now guys...

No need to get defensive or hostile in this thread. There are no points for being right here. We are all wrong, frequently and it never helps to beat people over the head with it when they are wrong. You'll notice this thread has no numbered lists of why one person is right and the other is wrong, point by point trying to take the other peson apart. Let's keep it that way.

[NiftySVX]

You are correct, i was just adding a little more info, meant to come across as a guess to the differences, which i obviously don't know. And you're right, I don't have one, that's why I am excited to see what the differences are. And of course, the idea behind obd2 and for that matter obd was emissions related, I'm just thinking aloud.

I'll go back into lurking :(

[cdvs]

come on now guys...

No need to get defensive or hostile in this thread. There are no points for being right here. We are all wrong, frequently and it never helps to beat people over the head with it when they are wrong. You'll notice this thread has no numbered lists of why one person is right and the other is wrong, point by point trying to take the other peson apart. Let's keep it that way.

Come on now, Lan...

Try to practice before preaching. From where I sit, you are the one overreacting and posturing. Nobody was defensive, hostile, or trying to take anyone apart. Sharing correct information was my objective throughout.

Your motives aren't clear to me.

Charl

[NiftySVX]

What are everyone's thoughts on adjusting the torque converter unlock curve (stick d, normal mode) to be slightly more aggressive? I have always thought that it required a bit too much throttle to unlock the converter. It seems like it is necessary to depress the throttle enough to get the car to downshift to 3rd to get the acceleration i want (such as when traveling in a pack of traffic) but I i would not have pushed it that far if the converter was easier to unlock. I find that when i am traveling at around 45-55 mph and i want to accelerate fairly rapidly (such as an on ramp from one freeway to another) i tend to quickly blip the throttle to get the thing to switch over to power mode so that it will unlock the converter.

Also, what about changing the "countdown" timer for the power mode? I find that it always goes back to normal annoyingly quickly. Would it be possible to modify the code in such a way that the base time used in the calculation that was described earlier in the thread to be longer, like say a minimum of 10-15 seconds before a return to normal once activated?

[b3lha]

Following a lot of conjecture about how the Solenoid C mapping works, I made the time to look at it today. I haven't figured out the exact details yet, but I can give a rough overview.

Based on what I've found, I think that the theory about torque split being based on a percentage difference in speed between front and rear wheels is wrong. Here is what I think happens.

On the USDM model, ROMID 705404, the solenoid C subroutine is at address EE80.

There are 5 maps, one for each gearstick position: R, D, 3, 2, 1. These maps are stored at CCE1, CD32, CD83, CDD4 and CE25 respectively. There is a separate special case for when the stick is in N.

Each map is a lookup table 8 x 9. The Y axis is Throttle. The X axis is a little harder to understand. It's the VSS1 signal multiplied by the Ratio of the current gear. Ryan Press refers to this parameter as the "Input Shaft RPM" in his analysis of the Legacy TCU. But I'm not so sure. I think it is only the input shaft speed when the front and back wheels are turning at the same speed. But anyway, we can puzzle over that.

I think the TCU is looking at how fast the input shaft is turning compared to the amount of throttle applied. The sweet spot of the map is in the middle, when you are travelling at a steady speed, high duty cycle = power up front.

If there is wheel spin then there will be less resistance to the engine's torque and therefore the input shaft will be spinning faster relative to the amount of throttle applied. The map lookup gives a lower duty cycle and power shunts to the back.

Alternatively, when you are accelerating against the car's inertia, the input shaft will spin slower relative to the amount of throttle applied. Again, the map lookup gives a lower duty cycle and power shifts to the back.

That is why, with an SSM, you can see the torque split change during acceleration, not just when there is a speed difference between front and rear wheels.

Once the base value has been selected from the map, small adjustments are made for ATF temperature and Battery Voltage.

There is also a special case that when the ABS triggers, the duty cycle gets set between 70 and 76 percent, proportional to vehicle speed.

There is a bit more to it that I don't yet understand, but I think I've got the basics right. Any mechanical gurus want to offer an opinion?

[oab_au]

Following a lot of conjecture about how the Solenoid C mapping works, I made the time to look at it today. I haven't figured out the exact details yet, but I can give a rough overview.

Based on what I've found, I think that the theory about torque split being based on a percentage difference in speed between front and rear wheels is wrong. Here is what I think happens.

On the USDM model, ROMID 705404, the solenoid C subroutine is at address EE80.

There are 5 maps, one for each gearstick position: R, D, 3, 2, 1. These maps are stored at CCE1, CD32, CD83, CDD4 and CE25 respectively. There is a separate special case for when the stick is in N.

Each map is a lookup table 8 x 9. The Y axis is Throttle. The X axis is a little harder to understand. It's the VSS1 signal multiplied by the Ratio of the current gear. Ryan Press refers to this parameter as the "Input Shaft RPM" in his analysis of the Legacy TCU. But I'm not so sure. I think it is only the input shaft speed when the front and back wheels are turning at the same speed. But anyway, we can puzzle over that.

I think the TCU is looking at how fast the input shaft is turning compared to the amount of throttle applied. The sweet spot of the map is in the middle, when you are travelling at a steady speed, high duty cycle = power up front.

If there is wheel spin then there will be less resistance to the engine's torque and therefore the input shaft will be spinning faster relative to the amount of throttle applied. The map lookup gives a lower duty cycle and power shunts to the back.

Alternatively, when you are accelerating against the car's inertia, the input shaft will spin slower relative to the amount of throttle applied. Again, the map lookup gives a lower duty cycle and power shifts to the back.

That is why, with an SSM, you can see the torque split change during acceleration, not just when there is a speed difference between front and rear wheels.

Once the base value has been selected from the map, small adjustments are made for ATF temperature and Battery Voltage.

There is also a special case that when the ABS triggers, the duty cycle gets set between 70 and 76 percent, proportional to vehicle speed.

There is a bit more to it that I don't yet understand, but I think I've got the basics right. Any mechanical gurus want to offer an opinion?

I think you may have been lead astray Phil. I think the transmission that Ryan Press is referring to is the latter box with the extra speed sensor on the turbine shaft. This is used in conjunction with the crank rpm to measure the difference in the speed in and out of the torque converter. This is then used to give a more accurate measure of the load that the engine is under, so that the box can be operated better.

Harvey.

[NiftySVX]

Good work, I agree. The comparison between throttle opening and, for US cars at least, the front speed sensor is likely what most of the AWD duty is based on for normal driving. Although, it is true that none of the SVX transmissions had the input shaft speed sensor, this was added later to check for slippage among other things already mentioned. But it could just as easily be used for the calculation as the speed sensor that is on the final drive on the later units. Again, good work, and good thinking.

This is my favorite thread ever, and I've been a part of this community for ten years.

[b3lha]

I think you may have been lead astray Phil. I think the transmission that Ryan Press is referring to is the latter box with the extra speed sensor on the turbine shaft. This is used in conjunction with the crank rpm to measure the difference in the speed in and out of the torque converter. This is then used to give a more accurate measure of the load that the engine is under, so that the box can be operated better.

Harvey.

Ryan's box is from a 1990 Legacy. But that's not really important.

As I said, the SVX Sol C duty maps seem to be based on (VSS1 [ie. rear output shaft speed] * current gear ratio) vs Throttle. I'll post more details when I have them.

[oab_au]

Ryan's box is from a 1990 Legacy. But that's not really important.

As I said, the SVX Sol C duty maps seem to be based on (VSS1 [ie. rear output shaft speed] * current gear ratio) vs Throttle. I'll post more details when I have them.

Well he is not talking about a 90 model box, as he talks about " input shaft RPM", and Subaru didn't have one till the later box with the "input shaft sensor" and the clutch instead of the band.

It would be really useful if you could post the C solenoid map for say, 2nd gear for both US and UK AWDs, that would cover the differences that they have.:)

Harvey.

[b3lha]

I've just been looking at a 1995 Aussie TCU that Harvey sent me. It is identical to the 1996 UK TCU that I copied from Gez's car. Label "MS", ROMID 705625.

Earlier Aussie cars presumably use Label "FF", ROMID 705622 like the earlier UK cars.

According to Harvey there was a hardware change to the gearbox solenoids aroiund 95, and that is why the software was updated. So you have to use the right TCU for the transmission.

I'll be looking into this in more detail.

Phil.

[longassname]

An Australian customer of mine has used the ECUtune UK TCU ROM built on the 705622 code in his 92 Australian SVX with very good results.

[oab_au]

I've just been looking at a 1995 Aussie TCU that Harvey sent me. It is identical to the 1996 UK TCU that I copied from Gez's car. Label "MS", ROMID 705625.

Earlier Aussie cars presumably use Label "FF", ROMID 705622 like the earlier UK cars.

According to Harvey there was a hardware change to the gearbox solenoids aroiund 95, and that is why the software was updated. So you have to use the right TCU for the transmission.

I'll be looking into this in more detail.

Phil.

Phil it also appears that the JDM trans had the same change. The early ones 92 to 94, used a Normally open C solenoid. Later was 95 to 97. Used a Normally closed solenoid.
The TCU has to match the C solenoid, for both the Euro and the JDM.

Harvey.

[Trevor]

Kia ora Phil,

The only scenario which could make the change advised by Harvey a logical progression, would require that the later model cars were fitted with the US centre clutch type transmission. I have never seen even a suggestion to this effect.

To change the C solenoid, for no apparent reason, thus requiring an extensive change in the software, does not add up. :confused:

All the best, Trevor.

[NiftySVX]

Do the VTD transmissions of this vintage experience frequent duty c failures like the ACT-4s do? I would imagine a failure of this solenoid on one of these would cause a fault that would result in no ability to "lock" the center diff. This would probably go unnoticed by the driver in most cases, but if this was a common failure they may have changed the solenoid to try and improve the system's reliability. Just a shot in the dark guess...:confused:

[b3lha]

I will take another look at the differences between the early and late UK and JDM TCUs to see if I can come up with any answers.

[oab_au]

Do the VTD transmissions of this vintage experience frequent duty c failures like the ACT-4s do? I would imagine a failure of this solenoid on one of these would cause a fault that would result in no ability to "lock" the center diff. This would probably go unnoticed by the driver in most cases, but if this was a common failure they may have changed the solenoid to try and improve the system's reliability. Just a shot in the dark guess...:confused:

Yes they do have the same problems with the solenoid as the US models. They will bind, and they will spin the back wheels with the valve not working, you certainly would notice, as it can sit still on the grass spinning both back wheels.:D

I don't see it as often, as we see the US version, maybe 5 cases over the years, but that could just be due to there being more of the US type.
I would guess that it was to improve the operation of the valve, but why did they use the two different types in the early models.

Harvey.

[Trevor]

Yes they do have the same problems with the solenoid as the US models. They will bind, and they will spin the back wheels with the valve not working, you certainly would notice, as it can sit still on the grass spinning both back wheels.:D

I don't see it as often, as we see the US version, maybe 5 cases over the years, but that could just be due to there being more of the US type.
I would guess that it was to improve the operation of the valve, but why did they use the two different types in the early models.

Harvey.

If, as has been claimed, a N/C solenoid is fitted to late model VTD SVX transmissions, the solenoid valve will fail to the normal and closed position. Unless there has also been mechanical changes, the transmission will fail with the clutch closed and front rear lock up. Surely this state of affairs would be noticed by the driver.

Failure could be due to the loss of an energising signal, an open winding in the solenoid, or the solenoid becoming jammed closed.

If the car “can sit still on the grass spinning both back wheels.” the clutch is surely not closed. Everything indicates, that in fact there has been no change in the C solenoid. What evidence is available supporting the statement, which claims a change has taken place?:confused:

P.S. It is absolutely clear why a N/O valve is found in earlier models and indeed why it would not be desirable for any change to have taken place.

[b3lha]

I've been comparing the TCU software for 705622 (1992 UK "FF" TCU) and 705625 (1996 UK "MS" TCU). I don't doubt that Harvey is right about the solenoid change, but if the solenoid has changed from NO to NC then I expect the software that drives it would need to change. However, I can't see any difference in the software. The driver for the C solenoid is quite straightforward. It works like this:

The duration of one wavelength is defined as 20000 units. If the frequency is 50Hz, then 1 unit = 0.0025 seconds.

When the diff-lock fuse is inserted on a Euro TCU, the program sets the "On_Time" to 19000. That's 95% of 20000, a 95% duty cycle. On a USDM model, when the FWD fuse is inserted, the program sets the "On_Time" to 1000, that's 5% of 20000, a 5% duty cycle.

The actual duty cycle is implemented by a timer like this:


When timeout occurs:
Toggle the Solenoid State
If Solenoid is ON
Set timer to On_Time
Else
Set timer to (Wavelength minus On_Time)
EndIf


As far as I can see, the algorithm is identical in the early and late models.

[b3lha]

On a USDM model, when the FWD fuse is inserted, the program sets the "On_Time" to 1000, that's 5% of 20000, a 5% duty cycle.

Thanks Trevor, for pointing out my mistake. The USDM TCU sets the "On_Time" to 19000 (95% duty) when the FWD fuse is inserted.

[Trevor]

Thanks Trevor, for pointing out my mistake. The USDM TCU sets the "On_Time" to 19000 (95% duty) when the FWD fuse is inserted.

Kia ora Phil,

You have had me all of a dizz. :eek: If you had been right, all the stuff so far recorded would have to be dug into, in order to find where a mistake had been made. Your research has now made the sequence previously held in jeopardy by some, absolutely proven beyond any possible doubt.

A very easy issue to get inverted for sure. One that can turn one's brain inside out. I do not know how you remain sane doing the job you do. But hang on, I worked on some madly confusing stuff at your age. :lol: I can attest that you do not have to be concerned regarding Alzheimer's, when you catch up to me.:rolleyes:

Cheers for sure, Trevor.

[NiftySVX]

Would it be possible to change one of these simple values to have the effect of increasing transfer clutch apply across the board? Though I am not sure what that would do for drivability, it would be an interesting possibility.

[b3lha]

Would it be possible to change one of these simple values to have the effect of increasing transfer clutch apply across the board? Though I am not sure what that would do for drivability, it would be an interesting possibility.

After the TCU has calculated what the duty cycle should be, it applies an adjustment factor based on ATF temp and Battery Voltage. You could tweak the duty "across the board" by modifying this adjustment table. If you want to experiment with it then I'll try and explain it further.

It would probably be better to change the actual Sol C map though. I've got some of it decoded but I haven't got my head around all of it yet.

[TomsSVX]

Phil, playing Devil's Advocate here a little. Can you tell me what the idle and WOT "time on" is for both a VTD trans and a US spec?

Tom

[oab_au]

To put what I have found, into perspective Phil. When I fitted the EPROM that you modified for me, replacing the Economy map with the Power map, it worked fine except I found that it was binding.

I have a C solenoid out of a 92 Aust model that an Aust member replaced. It is a normally open yellow wire solenoid. When I ordered a new C solenoid from the dealers, they told me that the early solenoid part No that I supplied, was not for my VIN number, and that the C solenoid changed in the 92 to 94 model number SU31942AA051, a normally open valve, to the 95 to 97 model number SU31942AA061, a normally closed green wire valve.

Finding that the later valve was opposite to the early one, lead me to the conclusion that this was the reason for the binding. I fitted the “ Diff Lock” fuse, and the binding went.:) There was an obverse mismatch somewhere. Working back from the clutch to the TCU, both clutches work the same, pressure engages it, springs disengage it, there are no operational differences. The Transfer valve block is the same for both solenoids, and venting and springs are the same, yet the change of program has reversed the signal to the solenoid.

The JDM transmission also changed the C solenoid at the same time at the Euro model. There is another case of a JDM using an early JDM TCU to control a late JDM rear end. This also had binding problems, due to the signal being opposite, this too was fixed by fitting the “Diff Lock’ fuse, that should apply the clutch, but released it instead.

The only conclusion that I can come to is that the program is different, somewhere, between the early and late model TCUs.

Harvey.

[cdvs]

......The only conclusion that I can come to is that the program is different, somewhere, between the early and late model TCUs.

Harvey.
Such a difference could also be in the TCU electronics. Being run by the same code, but producing an opposite signal.

[oab_au]

Such a difference could also be in the TCU electronics. Being run by the same code, but producing an opposite signal.

Yes but, I am using the same TCU, just the EPROM has been changed, same electronics.:)

Harvey.

[Trevor]

Yes but, I am using the same TCU, just the EPROM has been changed, same electronics.:)

Harvey.

Harvey,

Is Phil to accept, that your rather confusing post states ----

After installing in my SVX, an EPROM supplied by Phil, I Harvey, found it necessary to change the C solenoid from a N/O to a N/C , otherwise my car would not operate correctly ? :confused:

P.S. Are you stating that you now have the fuse switch, permanently installed ?

[oab_au]

Harvey,

Is Phil to accept, that your rather confusing post states ----

After installing in my SVX, an EPROM supplied by Phil, I Harvey, found it necessary to change the C solenoid from a N/O to a N/C , otherwise my car would not operate correctly ? :confused:

P.S. Are you stating that you now have the fuse switch, permanently installed ?

The answers to your questions are contained here,
http://www.subaru-svx.net/forum/showpost.php?p=615295&postcount=201

Harvey.

[Trevor]

The answers to your questions are contained here,
http://www.subaru-svx.net/forum/showpost.php?p=615295&postcount=201

Harvey.

In the absence of any explanation I must take what you have stated, as read. :eek:

To put what I have found, into perspective Phil. When I fitted the EPROM that you modified for me, replacing the Economy map with the Power map, it worked fine except I found that it was binding.

The transmission was binding ? The EPROM was binding? Was Phil advised at the time of the problem?
Let us assume that the transmission was binding.

I have a C solenoid out of a 92 Aust model that an Aust member replaced. It is a normally open yellow wire solenoid.

So what and why? What are we to assume from this statement? Is/was in your SVX transmission, or in your hand? What solenoid was in the car when the EPROM allegedly caused binding?

When I ordered a new C solenoid from the dealers, they told me that the early solenoid part No that I supplied, was not for my VIN number, and that the C solenoid changed in the 92 to 94 model number SU31942AA051, a normally open valve, to the 95 to 97 model number SU31942AA061, a normally closed green wire valve.
Finding that the later valve was opposite to the early one, lead me to the conclusion that this was the reason for the binding.

The binding after fitting the EPROM?
What did you order? ? What was supplied? What was in the car at the time the above was relevant? What is now in your car?

Let us presume that a N/C valve was supplied and fitted to your transmission after fitting the EPROM, in an attempt to cure the alleged binding.

I fitted the “ Diff Lock” fuse, and the binding went. There was an obverse mismatch somewhere.

Sure was and is a mismatch somewhere, if you have a N/C C solenoid valve and the fuse fitted. The fuse switch will result in an open N/C Valve releasing the clutch and providing a constantly open centre diff. Most certainly this would prevent the binding caused by the wrong C solenoid you had/have fitted. The car will run fine, without VTD, for one who knows no better. Is the switch fuse still fitted in order to prevent the alleged binding caused by the EPROM? :confused:

Working back from the clutch to the TCU, both clutches work the same, pressure engages it, springs disengage it, there are no operational differences. The Transfer valve block is the same for both solenoids, and venting and springs are the same, yet the change of program has reversed the signal to the solenoid.

You can only now record this description, because I corrected your earlier quite different, and wrong statements, which can be easily copied from the archives as evidence in this regard. You of course as is usual, you did not acknowledge your previous error, so that your current statement is of very real interest. :D

The JDM transmission also changed the C solenoid at the same time at the Euro model. There is another case of a JDM using an early JDM TCU to control a late JDM rear end. This also had binding problems, due to the signal being opposite, this too was fixed by fitting the “Diff Lock’ fuse, that should apply the clutch, but released it instead.

due to the signal being opposite? These statements must be qualified in order to hold water, as at present they do not. In any event the worst we can assume is that a JDM car has an owner, happy to be without VTD. :lol:

The only conclusion that I can come to is that the program is different, somewhere, between the early and late model TCUs. Harvey.

Agreed that only you, could come to such a conclusion.

Within all of this, it is easy to see that you are scrabbling to find a way to prove that the TCU signal can be, or has been, reversed, inverted turned ar$e over kite or whatever. You can not prove your wrong statements in this regard by this ruse, and this thread is not the place to do so.

There will be those who, lacking technical knowledge, will assume, "here goes Trevor again needlessly attacking Harvey." To them I point out that the integrity of a very special member is open to question here, and it is again very necessary to divulge a serious error and implication.

[b3lha]

To put what I have found, into perspective Phil. When I fitted the EPROM that you modified for me, replacing the Economy map with the Power map, it worked fine except I found that it was binding.

I have a C solenoid out of a 92 Aust model that an Aust member replaced. It is a normally open yellow wire solenoid. When I ordered a new C solenoid from the dealers, they told me that the early solenoid part No that I supplied, was not for my VIN number, and that the C solenoid changed in the 92 to 94 model number SU31942AA051, a normally open valve, to the 95 to 97 model number SU31942AA061, a normally closed green wire valve.

Finding that the later valve was opposite to the early one, lead me to the conclusion that this was the reason for the binding. I fitted the “ Diff Lock” fuse, and the binding went.:) There was an obverse mismatch somewhere. Working back from the clutch to the TCU, both clutches work the same, pressure engages it, springs disengage it, there are no operational differences. The Transfer valve block is the same for both solenoids, and venting and springs are the same, yet the change of program has reversed the signal to the solenoid.

The JDM transmission also changed the C solenoid at the same time at the Euro model. There is another case of a JDM using an early JDM TCU to control a late JDM rear end. This also had binding problems, due to the signal being opposite, this too was fixed by fitting the “Diff Lock’ fuse, that should apply the clutch, but released it instead.

The only conclusion that I can come to is that the program is different, somewhere, between the early and late model TCUs.

Harvey.

I'll try and get those chips programmed for you this weekend. Then we'll see if the problem goes away. This is all a bit puzzling and I'd like to find the answer.

Is it just the C solenoid that changed from NO to NC, or all the solenoids?

Phil.

[b3lha]

Phil, playing Devil's Advocate here a little. Can you tell me what the idle and WOT "time on" is for both a VTD trans and a US spec?

Tom

Next week, I'll post everything I've figured out so far.

[TomsSVX]

Next week, I'll post everything I've figured out so far.

Thanks Phil

Tom

[oab_au]

I'll try and get those chips programmed for you this weekend. Then we'll see if the problem goes away. This is all a bit puzzling and I'd like to find the answer.

Is it just the C solenoid that changed from NO to NC, or all the solenoids?

Phil.

I don't know about the rest, we could find out by checking the part Numbers, see if they changed.

Yes I'll use those two for mine and Tony's, both 95s, only a couple of numbers apart. The two that I have will do early models. I have one ready to go into Jordan's 92 car. So we may find out both ways.

Harvey.

[NiftySVX]

After the TCU has calculated what the duty cycle should be, it applies an adjustment factor based on ATF temp and Battery Voltage. You could tweak the duty "across the board" by modifying this adjustment table. If you want to experiment with it then I'll try and explain it further.

It would probably be better to change the actual Sol C map though. I've got some of it decoded but I haven't got my head around all of it yet.

I was curious, I'm not even sure a modification of the AWD map would make a difference as far as drivability or performance, it would likely only cause clutch durability and other problems. Plus, I lack the equipment required to experiment with it anyway, so I won't waste any more of your time on it :lol: I am more interested in how this solenoid thing comes out because I would like to fit a VTD tail section to my US trans, as I imagine the VTD car would drive far, far better. I have a glimmer of hope that it may be possible to do so with minimal other modification, even though a few months ago I thought this would be impossible.

I've been researching on my own to attempt to figure out why a solenoid change would have been made, and I can't figure out why they would change it like that. The different wire colors don't surprise me as they could have switched manufacturers, or sometimes the current manufacturer just decides to change the wire color for no reason. I've seen stuff like that happen before.

[Trevor]

I've been researching on my own to attempt to figure out why a solenoid change would have been made, and I can't figure out why they would change it like that. The different wire colors don't surprise me as they could have switched manufacturers, or sometimes the current manufacturer just decides to change the wire color for no reason. I've seen stuff like that happen before.

I have also carried out research and am still doing so, having contacted Subaru N.Z., transmission shops and specialist Subaru parts suppliers. No evidence is available to support the alleged change in the C solenoid, in fact the opposite is the case.

[NeedForSpeed]

I have also carried out research and am still doing so, having contacted Subaru N.Z., transmission shops and specialist Subaru parts suppliers. No evidence is available to support the alleged change in the C solenoid, in fact the opposite is the case.


The opposite is not the case. Based on the facts at hand, the evidence that transfer solenoid C in the JDM/AU transmissions was changed to a N/C design in later models is absolute. Here is the proof:

It is undisputed that all US transfer solenoids are Normally Closed. My Subaru dealer provided the following part numbers for the transfer solenoid:

PN 31942AA 061, US up to 05/95, transfer solenoid
PN 31942AA 090, US 5/95 to 11/96, transfer solenoid
I was told that 090 DID NOT supersede 061.

Japanese and Australian parts catalogs provide the following part numbers:

PN 31942AA 050, 09/1991-01/1994, updated by:
PN 31942AA 051 02/1994-10/1994

PN 31942AA 061, 11/1994-04/1995
PN 31942AA 090, 05/1995-11/1996

These later two Japanese and Australian-spec VTD transfer solenoids are the same PN [exact same part] as US-spec N/C solenoids from 92-97.

The change to N/C solenoid from a N/O is the reason that a TCU for an early VTD transmission will not properly control a later VTD transmission.

This fact was determined independently and almost simultaneously by Harvey with his late UK-spec box controlled by 'early' programming maps, and by myself with a late JDM-spec box controlled by an early JDM TCU in our US-spec '92 Peacock Blue SVX.

Why the change? That in fact, is the question without an answer.

[TomsSVX]

I don't know what all the trouble is about... The shifter in my car shows me the shift map:p

Tom

[oab_au]

I don't know what all the trouble is about... The shifter in my car shows me the shift map:p

Tom

Which one do you use?
1st.3rd.5th, or 2nd,4th,6th?????????

Harvey.

[TomsSVX]

I like to integrate the two. Give you the best of both worlds:p

Tom

[NeedForSpeed]

I don't know what all the trouble is about... The shifter in my car shows me the shift map:p

Tom

That makes it simple! :lol:

[Trevor]

The change to N/C solenoid from a N/O is the reason that a TCU for an early VTD transmission will not properly control a later VTD transmission.

This fact was determined independently and almost simultaneously by Harvey with his late UK-spec box controlled by 'early' programming maps, and by myself with a late JDM-spec box controlled by an early JDM TCU in our US-spec '92 Peacock Blue SVX.

Why the change? That in fact, is the question without an answer.

"will not properly control a later VTD transmission." From this I would gather that the transmission worked in some fashion, but not properly. Exactly what function was not operating properly/correctly, when using the early type TCU? :confused:

[NeedForSpeed]

"will not properly control a later VTD transmission." From this I would gather that the transmission worked in some fashion, but not properly. Exactly what function was not operating properly/correctly, when using the early type TCU? :confused:


HI Trevor,
Inappropriate clutch activation, aka, binding.

[cdvs]

HI Trevor,
Inappropriate clutch activation, aka, binding.

Also the opposite, no engagement when needed.

[Trevor]

HI Trevor,
Inappropriate clutch activation, aka, binding.

Greetings,

“This fact was determined independently and almost simultaneously by Harvey with his late UK-spec box controlled by 'early' programming maps,”

Without the information requested in my posts #204 and #206 recorded, the information so far available is nebulous. Nothing has been proven and it is indicated that an after market EPROM is the cause of the reported problem/difference.

“and by myself with a late JDM-spec box controlled by an early JDM TCU in our US-spec '92 Peacock Blue SVX.”

Are you advising on the basis of experience with your own car? Particularly interesting is the fitting of a JDM transmission in a US spec. SVX. Details would be appreciated, including specific before and after results, and how, when and where there was binding.

At this point you must appreciate that the only proof is, that you corrected a problem by changing the TCU. In point of fact the early TCU could have been faulty.:confused: ;)

[NeedForSpeed]

Greetings,

“This fact was determined independently and almost simultaneously by Harvey with his late UK-spec box controlled by 'early' programming maps,”

Without the information requested in my posts #204 and #206 recorded, the information so far available is nebulous. Nothing has been proven and it is indicated that an after market EPROM is the cause of the reported problem/difference.

“and by myself with a late JDM-spec box controlled by an early JDM TCU in our US-spec '92 Peacock Blue SVX.”

Are you advising on the basis of experience with your own car? Particularly interesting is the fitting of a JDM transmission in a US spec. SVX. Details would be appreciated, including specific before and after results, and how, when and where there was binding.

At this point you must appreciate that the only proof is, that you corrected a problem by changing the TCU. In point of fact the early TCU could have been faulty.:confused: ;)


Hi Trevor,

Please note, I have only posted three times in this thread.

The one and only purpose of my first post was in response to your one post, to offer substantial and unrefuted proof that late VTD boxes were IN FACT fitted with a N/C transfer solenoid. This statement was based on US/JDM/UK Subaru part numbers at hand. Again, based on information from Subaru dealers around the world, not based on my experience, not based on the experience of others, the part was changed, for reasons unknown to date.

No, I am not advising, or giving any advice, on the basis of experience with this particular car. This is not the venue. As this thread is highly significant and important, Phil's Gearshift Map thread, I'll step out now, and let the discussion and debate resume with that theme.

Thanks :-)

[Trevor]

Hi Trevor,

Please note, I have only posted three times in this thread.

The one and only purpose of my first post was in response to your one post, to offer substantial and unrefuted proof that late VTD boxes were IN FACT fitted with a N/C transfer solenoid. This statement was based on US/JDM/UK Subaru part numbers at hand. Again, based on information from Subaru dealers around the world, not based on my experience, not based on the experience of others, the part was changed, for reasons unknown to date.

No, I am not advising, or giving any advice, on the basis of experience with this particular car. This is not the venue. As this thread is highly significant and important, Phil's Gearshift Map thread, I'll step out now, and let the discussion and debate resume with that theme.

Thanks :-)

Phil is interested in an answer to this aspect of things, otherwise I would not be taking up space in this thread.

All we have is a change in part numbers, which lack an associated description of the part. There is no verification of a change from N/O to N/C. The change in number could be for many non related reasons. I have hearsay evidence which contradicts what you have been told, so must leave the matter in abeyance. :confused:

Whatever, thanks for the information, Trevor.

[NeedForSpeed]

Phil is interested in an answer to this aspect of things, otherwise I would not be taking up space in this thread.

All we have is a change in part numbers, which lack an associated description of the part. There is no verification of a change from N/O to N/C. The change in number could be for many non related reasons. I have hearsay evidence which contradicts what you have been told, so must leave the matter in abeyance. :confused:

Whatever, thanks for the information, Trevor.

Hi Trevor,

Yes, there is verification, from Subaru dealers worldwide! This is not personal opinion. This is not hearsay evidence. This is factual, numerical, unrefuted verification and proof.

Please do not misunderstand; I'm most interested in the fact that you and Phil have accurate facts with which to make logical and proper conclusions, thus the reason for posting. We remain fortunate that Phil has a passion for TCU programming, wanting to collect and explore all SVX TCUs. Phil is one of our greatest resources here, without question. I'm been in email and phone communication with Phil for many years. My family and I were guests at Phil and Belha's home in the UK four years ago. He has an open invitation to visit California. Yes, I'm most considerate of Phil's interest in this and in all SVX details, as much, but likely more, than anyone here.

I've asked a couple members with late JDM VTDs if their TCUs can be downloaded for Phil's use. I'm diligently pursuing data and facts to complete the record. Only then, once Phil has an opportunity to dissect late VTD programming, can a clear understanding of programming logic be established in relation to N/O and N/C transfer solenoids.

I would agree with you, that the change in part numbers, in-of-itself, is not proof enough. However, Subaru part numbers are universal.

The fact remains, late VTD transfer solenoid numbers ARE the same exact parts used in US boxes. These US parts have been dissected my many members. IT IS CLEARLY ESTABLISHED THAT THE LATE VTD PART NUMBERS ARE N/C PARTS, THE EXACT PARTS USED IN THE US. Unless you can prove that the part numbers on hand, received from Australian, Japanese, and American Subaru dealers are fiction, you should accept the facts presented and move onward, so that a clearer understanding in this matter will enable you to provide accurate advice to our members.

Verification for you must come from Subaru dealers via parts numbers. I can PM a VIN for a S3 if you would like to confirm the solenoid part number in this late application. I'm sure that you have access online to verify the US part number for a numerical comparison. Any US member could assist.

Based on the evidence, the fact that late VTD boxes are fitted with US-spec N/C solenoids must be accepted and established to fully understand the compatibility of parts, and/or programming, for all SVX markets.

Take care, Ron

[longassname]

I had to order some components for another kit I'm sending off to the assembly house so while at it I'm ordering the components for a couple hundred ttl232r adaptors to send off to the assembly house too.

Here's a print screen of the routed board.

http://www.ecutune.com/posts/ttl232r.gif

[longassname]

The interface circuit boards are in. I'm waiting on components to send them out to the assembly house. My whole parts order is on hold waiting for more headers for the memory adaptors.

http://www.ecutune.com/posts/DSC_7970.jpg

[longassname]

I assembled one with components I had on hand for hand wired prototypes.

http://www.ecutune.com/posts/DSC_7976.jpg

[stevek]

I'm sorry to bring this down to my level but Chinese writing must be easier to understand!
I take my hat off to each of you, and if you need any brazing or gas welding or half decent turning I'm your man. I can't scrape white metal bearings to size (my 'even older' brother can though) but can degree cams in and build engines.
Without brainy buggers like you guys though running an SVX would not be an option for me. I Thank you.

[NeedForSpeed]

Michael,
What is the purpose of this circuit board?

[longassname]

The circuit board is an adaptor to go between the select monitor port and an ftdi ttl232r usb cable so that you can communicate with the control units from a laptop.

I'm releasing a windows application along with them to monitor control unit parameters, clear trouble codes, download firmware, modify firmware, and open and save binaries. I'm trying to make the program work well with a variety of control units so nothing is hardcoded to match the SVX ECU, TCU, etc, or any other particular control unit. Instead it uses a definitions file to tell the software the particulars it needs. It's up to the users to modify and populate the definitions files to define the things they want to watch/modify. The idea isn't that each or most users will do so; the idea is that the couple of gurus in each community will do so and then everyone else will use their definitions.

The definitions file is a microsoft excel .xls file. It can be named anything as the user is given an open file dialog box to select what *.xls file he/she wants to open as a definitions file. I suggest naming it for the control unit it is defning and the date it was last revised. The software then gets and sends data to and from the file like it is a database via ado.net. A link to an example/base to work with is at the bottom of this post. The values I have in the coms sheet should be correct for the SVX ECU, I've added the regular select monitor parameters for the SVX ECU to the parameters sheet but haven't set up the conversion functions for any of them except for the ones with signed values which I completed as examples. Value is a public property of my parameter class. C# is case sensitive so in order for your equation to work you must type Value, not value, not VALUE, not VaLuE.

Those of you who can program will note that means you will also be able to use other parameter values in your equation if you need to. I'll give you the fully qualified public property names in a bit.

I leave the rest up to the community to define. Here's the file to work with.
http://www.ecutune.com/posts/definitions.xls

[longassname]

The file io is complete.

The software can load bin files and allows you to set up any offset so the bin address space matches the control unit address space no matter what size Rom you want to write it to/read it from.

It reads the definitions from a microsoft excel .xls definitions file through the jet ole provider which is part of .net which should be present on any windows 2000 or newer machine with no need for excel to be installed and it writes them as a filestream through a custom dll included in the software so again no need for excel to be installed. This was actually a lot more work than having it write csv or xml files but I figure most people would cry if they had to edit those files outside of the software and they would like to be able to edit them on machines that don't have the software installed--so hopefully worth all the time and effort I put into it. You can also view and edit the definitions in the software itself.

Now that I can get all the definitions data I need in and out of the program the way I want I can get to work on the serial io.

[longassname]

Another note,

Just in case anyone wants to write a program to automate the export of definitions data....say directly from a select monitor cartridge bin...the named ranges in the example definitions file i provided don't matter. The header cells are what define the attribute names. No metadata is used.

[longassname]

woops there was a typo in the original definitions example file. the parameters sheet was named Paramaters instead of Parameters. It's corrected now. I also posted a file called test.xls which is the file output from opening the definitions.xls file in the tuning software and then saving it as test.xls.

http://www.ecutune.com/posts/test.xls

[longassname]

Making good progress on implementing serial communications. The dataflows between the definitions file, datasets, and form controls for setting up and opening the port are complete. I'm not actually using a serial port. I'm using a dll to write straight to the ftdi device driver. A nice benefit of this is that the drop box to select the com device only shows ftdi devices that are currently plugged in. Often times usb to serial cables leave com ports behind after you unplug them and make your com port list a confusing long mess; We won't have to worry about that.

DataBits can be 7 or 8
StopBits can be 1 or 2
Parity can be even or odd or none or mark or space

[longassname]

I'm trying a different aproach to handling the buffer than Phil did. I think the different approach kind of follows from using an object oriented language.

I don't let the control unit keep ratting on about the last byte I read or wrote.
As soon as I get 3 bytes in the rx buffer I send a stop command. When I read a byte from the control unit I clear the buffer first so I know the 3rd byte in the buffer will always be the data from the address I want.

private byte getByteFromControlUnit(string addressString)
{
//clear buffer
do
{
ftStatus = myFtdiDevice.Purge(FTDI.FT_PURGE.FT_PURGE_RX);
Thread.Sleep(10);
ftStatus = myFtdiDevice.GetRxBytesAvailable(ref numBytesAvailable);
} while (numBytesAvailable != 0);
sendReadCommand(addressString);
ftStatus = myFtdiDevice.Read(readbyteArray, numBytesAvailable, ref numBytesRead);
return readbyteArray[2];

[longassname]

Coms are implemented now. I even have some screen shots for you.

The ECUtune OBD1 Control Unit to ttl232r adaptor makes it very easy to set up a loopback to test coms. Just put a wire between the tx and rx terminals on it and whalla...loop back adaptor.

http://www.ecutune.com/posts/DSC_8063.jpg



I've included some tools in the software to check coms so users can do so just as easily. The read byte button initiates the regular read byte function which clears the buffer, sends a read command, waits for 3 bytes to hit the buffer, sends a stop command, and immediately pulls the byte of interest out of the buffer and moves on. This results in 1 packet being available to read and being displayed in the received packets window...though two packets were sent and two packets were received.

http://www.ecutune.com/posts/ReadByte.jpg



I also provided a button to run the same function with a 200 millisecond wait inserted before reading the buffer so both packets have time to hit it and be displayed. This allows you to see the loopback from both the commands that were sent--read, and stop.

http://www.ecutune.com/posts/ReadByteWithWait.jpg


The normal write function never waits for a response or reads the buffer so the write byte button here runs the normal write, waits 200 mS and reads the buffer. The read, write, and stop commands which make up the write routine, ie were sent, are displayed from the loopback.


http://www.ecutune.com/posts/WriteByte.jpg

[longassname]

The definition editor is complete. Pretty self explanatory. Select which sheet of definitions to edit and add or edit them. Click the button to apply any changes. Click the button to save them.

http://www.ecutune.com/posts/DefinitionEditor.jpg

[longassname]

I did a little ui clean up: moved the text around in the coms set up group box to better indicate that everything excep the available coms device is populated by the definitions file and made the Read Byte display dissapear after writing a byte and reappear after reading a byte....since read byte is meaningless when you are writing a byte.

http://www.ecutune.com/posts/setupCleanup.jpg

http://www.ecutune.com/posts/WriteByte2.jpg

[longassname]

I'm almost done with basic monitoring. I changed the bool column in the parameters table of the definitions file from Ram to Monitor. True means it will appear in the comboBoxes to select parameters to monitor. Select up to 4 parameters to monitor. I'll be adding a plot over time in the bottom of the tab.

http://www.ecutune.com/posts/Monitoring.jpg

[cdvs]

Your work may be interesting, but IMO, it doesn't belong here in this thread.
It has only marginal relationship to the transmission.
What would anyone need to monitor, in semi-real time, in the transmission that isn't immediately apparent?
Even if you have a good answer, most of the focus is on engine performance.
The transmission is secondary.
From what I've seen, no method is provided to change the Gear Shift Maps.
Regardless, putting your stuff here steps on and thereby diminishes Phil's contribution.
Please, ask the Admins to move this stuff to it's own thread.

[Trevor]

Your work may be interesting, but IMO, it doesn't belong here in this thread.
It has only marginal relationship to the transmission.
What would anyone need to monitor, in semi-real time, in the transmission that isn't immediately apparent?
Even if you have a good answer, most of the focus is on engine performance.
The transmission is secondary.
From what I've seen, no method is provided to change the Gear Shift Maps.
Regardless, putting your stuff here steps on and thereby diminishes Phil's contribution.
Please, ask the Admins to move this stuff to it's own thread.

Yes, the thread has been well and truly over run and the original concept is no longer being followed. A separate thread is called for in order to sort things out.

Those posting more or less on a commercial front, surely should separate their promotions accordingly. ;)

[longassname]

I have no qualms about removing or moving my posts.

I've been posting here because I like to support Phil's transmission control unit work and it's my hope that the Ecutuner software/interface package will result in exponentially increasing his library of TCU and ECU firmware.

My appologies

[b3lha]

Good stuff Mike, thanks for sharing.

Any chance I can get a copy of your software to play with when it's ready?

Phil.

[longassname]

Yep, the software will be a public download but the coms will require the use of a ttl232r cable which has been purchased from/programmed by me. I'll send you a cable.

I'm working on data and table editing features now. The features and tabs involved in communicating with the control unit, everything from set up to monitoring parameters, monitoring bitmaps, clearing memory, and downloading firmware is complete (including debugging and optimizing). I just stopped posting progress after being scolded for jacking your thread.


Good stuff Mike, thanks for sharing.

Any chance I can get a copy of your software to play with when it's ready?

Phil.

[cdvs]

....I just stopped posting progress after being scolded for jacking your thread.

I certainly didn't scold you or ask you to stop posting. Your work is worthy of it's own, properly indentified thread.

I can understand how this may have happened. The commumication hardware does seem, at first, to have direct application. However, everything not related to downloading the TCU ROM doesn't. Starting here put you on a slippery slope.

Failing to correct the situation after you were alearted to it might be a scoldable offense, but I have no interest in doing so. What you do about this reflects more on your character than your work.

[Trevor]

I certainly didn't scold you or ask you to stop posting. Your work is worthy of it's own, properly indentified thread.

I can understand how this may have happened. The commumication hardware does seem, at first, to have direct application. However, everything not related to downloading the TCU ROM doesn't. Starting here put you on a slippery slope.

Failing to correct the situation after you were alearted to it might be a scoldable offense, but I have no interest in doing so. What you do about this reflects more on your character than your work.

Congratulations are due.

At long last, another who in spite of possible negative reaction, has the courage to make a statement, due and necessary in the interest of members.

[b3lha]

A member here recently sent me an email asking this question
How would one recalibrate the tcm on an svx to change the line pressure of the transmission.
As we know, the line pressure is controlled by Duty Solenoid A, so I'm rephasing the question as "How can we adjust the duty cycle of solenoid A?".

The subroutine that determines the Sol A Duty cycle is at address EBAA in the USDM TCU (rom id:705404). First it chooses a map from a list of thirty seven 16bit map addresses at location C870.

0000C870 C9 0E C9 26 C9 3E C9 56 C9 0E C9 0E C9 6E C9 86
0000C880 C9 B6 C9 CE C9 0E C9 9E C9 E6 C9 FE CA 16 C9 0E
0000C890 CA 2E CA 46 CA 5E CA 76 CA 8E CA A6 CA BE CA D6
0000C8A0 CA EE CA A6 CA A6 CB 06 CB 1E CB 4E CB 66 CA A6
0000C8B0 CB 36 CB 7E CB 96 CB AE CA A6

The first block of 16 addresses (C90E,C926,C93E,....,CA16,C90E) are used when the Torque Control Signal has failed (trouble code 25).
The next address CA2E (at C890) is used for Reverse gear.
The next four addresses (CA46,CA5E,CA76,CA8E), I'm not quite sure about. Maybe they are used under some kind of error condition. The 1st one related to 1st gear, the 2nd for 2nd gear etc.
The important part is the final block of 16 addresses from C89A to C8B9. These are split as follows

Want_1 Want_2 Want_3 Want_4
Gear_1 CAA6 CABE CAD6 CAEE
Gear_2 CAA6 CAA6 CB06 CB1E
Gear_3 CB4E CB66 CAA6 CB36
Gear_4 CB7E CB96 CBAE CAA6

To explain, if the car is driving along happily in 3rd, it will use Gear_3_Want_3, the map at CAA6. If it is in 3rd, but has decided that it is about to change down to 2nd, it will use Gear_3_Want_2, the map at CB66. Similarly if it is in 3rd but has decided that it is about to change up to 4th then it will use Gear_3_Want_4, the map at CB36.
Now I'll explain how to decode the maps, taking the one at CAA6 as an example:

0000CAA0 xx xx xx xx xx xx 0F 7D 23 28 1F FA 1B 58 2F 96
0000CAB0 27 D8 5F 00 43 F8 FF 00 43 F8 xx xx xx xx xx xx

Split the data into groups of 4 bytes and arrange as follows:

TPS M C
0F 7D 2328
1F FA 1B58
2F 96 27D8
5F 00 43F8
FF 00 43F8

Converting these from Hex into Decimal, we get:

TPS M C
15 125 9000
31 250 7000
47 150 10200
95 0 17400
255 0 17400

The first column is a TPS value from 0 to 255. 255 represents 100% throttle. The table means: "If the TPS value is up to 15, let M=125 and C=9000. If the TPS value is between 16 and 31, let M=250 and C=7000. etc)
Now we use the straight line formula y=mx+c. For example, if we have 10% throttle, that's a TPS value of 25, so we select the 2nd line of the table, M=250 and C=7000. Now we do y = (250*25)+7000 = 13250.
The duty cycles in the TCU are represented by numbers from 0 to 20000. So 13250 is about 66% duty.
I've plotted some graphs to show the different maps.
http://www.alcyone.org.uk/ssm/usdmsola.jpg
That's how the base Sol A duty cycle is calculated. Using the information above, you should be able to recalibrate the line pressure. But there is a little bit more to it. After calculating the base duty cycle, it applies a compensation based on the atmospheric pressure signal. It compares the barometric pressure to a list of 8 thresholds at address CBC6 and chooses the corresponding map address from a list of C8BA.

0000C8B0 xx xx xx xx xx xx xx xx xx xx CB CE CB E6 CB FE
0000C8C0 CC 16 CC 2E CC 46 CC 5E CC 76 xx xx xx xx xx xx

To illustrate how the adjustment maps are encoded, I'll decode the one at CBCE:

TPS X Y Z
20 00 08 80
40 20 0C 82
60 40 0C 85
80 60 10 88
A0 80 08 8C
FF A0 00 8E

For TPS values up to 20 (hex) use row 1, for TPS values up to 40 (hex) use row 2 etc. Formula is something like y=(((TPS-X)*2Y+Z)/100-80)*64. All values in hex. This gets added onto the base duty cycle. If you really want to mess with the atmospheric pressure compension, then I suggest you study the code between EC86 and ECD6 and check that I've got the formula right as I'm not entirely sure of it. But I don't really see any need to adjust these compensation maps - the base map is the one you want to play with.

If the vehicle is not fitted with a barometic pressure sensor, or the sensor is faulty then the compensation is calculated differently based on current gear and vehicle speed. I haven't fully analysed it because it should not happen in the normal case.

I hope that information is helpful. I should also add that the first block of 16 maps at C870, the ones that are used if the torque control signal fails, are decoded in exactly the same way as the normal case ones at C89A.

I have not looked at the non-USDM code. The VTD boxes may work differently.

[longassname]

That's awesome Phil,

Adjusting the bottoms of the 3rd want 3 and 4th want 4 maps aught to extend the lives of a lot of transmissions that don't have performance valve bodies.

[longassname]

Phil,

One of your cars is JDM right? Is the TCU case on the JDM the same as the US model? Someone has sent me a TCU that he got with a JDM transmission which was supposed to be a JDM SVX TCU but the case is different and I'm suspecting it's something else. The case sticker is KM.

[NeedForSpeed]

Phil,

One of your cars is JDM right? Is the TCU case on the JDM the same as the US model? Someone has sent me a TCU that he got with a JDM transmission which was supposed to be a JDM SVX TCU but the case is different and I'm suspecting it's something else. The case sticker is KM.

Mike,
Not the same, the JDM TCU case is mirror image to the US case, mounting under RHD-driver side. I might be able to contribute more, What is the trans number on the front diff?