• Welcome to the new NAXJA Forum! If your password does not work, please use "Forgot your password?" link on the log-in page. Please feel free to reach out to [email protected] if we can provide any assistance.

Everything you ever wanted to know about the AW4

How much total tranny fluid does it take if you don't have a optional cooler?

I'm trying to calculate what percentage of old fluid I am removing with each drain and fill. I'm getting about 3 quarts out each time, but I don't know the total volume. So far I've only done two drain and fills.
 
I've recently aquired a 96XJ. With over 200k on the clock, I've been putting off the transmission fluid just because I'm scared of breaking anything loose. I plan on starting a weekly drain and fill this weekend. I only put 50-100 miles on it a week.

That being said, my son was driving it and put it in Reverse at 45mph. He said there was a loud thump before it kicked itself back into OD. He immediatly pulled over and called me. I told him to start it up, cycle it through the gears individually and see what happens. It shifts fine. There is a noticible thump when you go form N to OD while stopped but other than that, it runs.

Damage estimates???? Could he have broken anything???
 
How much total tranny fluid does it take if you don't have a optional cooler?

I'm trying to calculate what percentage of old fluid I am removing with each drain and fill. I'm getting about 3 quarts out each time, but I don't know the total volume. So far I've only done two drain and fills.
OK after a bit more research it appears to be around 8.5 quarts. So taking out about 3 quarts is about only 35% of the capacity. I'll have to do a few more drain/fills.
 
My understanding is the drain and fills over time are the best chance you have aside from just draining, removing, and cleaning, and re-installing the VB.
 
Has anyone attempted to get the transmission to shift sooner at WOT? I would like to do this as I really do not need/want/desire the high engine speed...

Looks to me like one would have to massage the Input Speed signal to the TCM at the very least.
 
I believe (but cannot guarantee) that if you wanted to do that, you could set up a circuit that would decrease the ISS signal frequency when it saw the TPS signal at WOT and the torque converter solenoid unlocked. Decrease because the actual input signal would be higher than the signal you'd need to feed it, and TCC solenoid inactive to prevent the TCU from freaking out about your transmission gear ratios being wrong.

Frequency scaling factor you'd want: actual shift RPM for the shift desired at WOT / desired shift RPM (for example, to force a 1-2 shift with the shifter in 1-2 to delay until 5100rpm at WOT, you'd want to scale the ISS frequency by 0.88 so that when the ISS actually sees 5100rpm, your converter would be outputting the 4500rpm that the TCU normally does an upshift in 1-2 at)

You'd need to read the TPS signal, the TCC solenoid output, keep track of ISS frequency, switch the TCU input between real and fake ISS signals, and produce a fake ISS signal capable of triggering the TCU ISS input filtering/conditioning circuitry. Most of that should be fairly trivial to do with an AVR microcontroller and some basic mixed-signal logic.

There is also the possibility of reflashing the TCU's configuration EEPROM but I haven't decoded its format yet, or even tried. Need to extract and reverse engineer the (mask ROM - not modifiable, sadly) TCU MCU's firmware before it'll really be possible to decode the EEPROM with anything but trial and error based methods.
 
It may be simpler. After digging in a bit more, it is the OSS that is the prime determiner in the upshift. The VSS is used only to set a diagnostic flag. To wit: once the Heep hits 6mph, there must be an OSS signal or the TCM sets the XJ into "limp home" mode.

I suspect that there is frequency comparators in the TCM so any attempt to modify the OSS signal must be also made to the ISS signal so as to avoid setting a fault. This is only a guess, but it makes sense from a diagnostic failure analysis view point. One would think that the TCM would want to know...

Per my FSM and my AW4 Powertrain Diagnostic Manual, the speed sensors send sine waves to the TCM where it gets chopped into a square wave. Frequency counters are then employed to determine the speed of each sensor. Upshifts then occur based upon the data tables contained in the EEPROM.

Note for those that do not know:
EEPROM = Electrically Erasable Programmable Read Only Memory.

What a mouthful...

Both Sensors are inductive in nature with the ISS being 4 pulse per revolution and the OSS being, I believe, 16 pulses per revolution.

I am thinking that, perhaps, if one were to use a pair of frequency to voltage converters tied to a pair of VCOs (voltage controlled oscillator) the signals could be manipulated with some level of finesse. What would be desired is to replicate the sine wave.

My purpose is to drop the maximum upshift down to around 4,500 rpm. With boost on board, really do not need/want/desire the high rpm shift points.

As far as I can find, so far, the AW4 control is primitive to say the least.

I do have a question for those in the know, would an Arduino platform be appropriate as a starting point? I have zero experience with this so do not know...

Looks like it is time to hit the yard for a spare TCM...

Given that I recently received some good news, for a change, I will have the time available to me to look into this.

As a side note here, spoke with Transgo Technical Support yesterday about installing their 340-HD2 shift kit. They recommend that the "truck" version be utilized, not the"Hot Rod" as it is their opinion the shifts, under boost will be a tad too harsh.

An interesting project in any event...
 
I'm not sure what the hell I was thinking about with my yap about the torque converter lockup, that won't affect the ISS vs OSS pulse ratio at all since the ISS is after the torque converter.

That being said - a few things that stuck out to me about what you said.

The ISS is the 16 pulse/rev one. It's got a much larger reluctor ring. The OSS is 1 pulse/rev on 97 down and 4 pulse/rev on 98 up. You are correct that they are sine wave signals, amplitude and frequency both increase as RPMs go up.

I did some basic reverse engineering work on the hardware at one point and found a quad op-amp (as I recall, it was several years ago) that I conjectured was being used to clip and level-shift the OSS and ISS signals. Good to hear that I was mostly on-base with that.

The Arduino platform might be decent for it... I don't know much about it other than that it's AVR based.

You're 100% right about the ISS/OSS signals being used for debugging/troubleshooting. I know for a fact that the TCU will set a code for solenoid malfunction (not the usual short/open fault code, a different one) if it requests one gear and sees ISS/OSS signals that imply a different gear is actually selected. I suspect, but have not verified, that it will also set a code if the ratio of ISS/OSS frequencies does not match reasonably closely to one of the gear ratios the transmission has, as this would indicate slipping clutches or other internal transmission problems.

As such you'd probably need to emulate the ISS/OSS signals to make the TCU think the transmission is OK and modulate the shift points by telling it things different from reality. Feed it a blue pill, if you will.

That being said, it might be easier to modify the values in the EEPROM. I don't know what format they're in, and you'd have to reverse engineer the firmware in the mask ROM section of the MCU, which is a Fujitsu MB89665 as I recall. The good news is that the 89665 only has 16kB of program ROM, which is a maximum of 16384 lines of code, not all that large, and the instruction set and encoding is published in the datasheet, which is available online. The bad news is that I still haven't found a way to get the ROM image out of the chip - if anyone can find that, I'm all ears and would love to spend a weekend reverse engineering the controller to see how it could be fooled or at least how the EEPROM can be changed to tweak shift points etc.

Also... glad to hear about the good news. Hang in there!
 
Kastein,
Thanks man. You are one of the few that actually knows what is going on with me... Now if my health will hold up a little longer, I may actually be able to finish at least some of the open projects.

After thinking about this, it make a great deal of sense that the ISS would have the greater number of pulses per revolution as one would need/want the resolution for gear control.

I suppose that the sensor itself could be classified as a "reluctor". That being the case, the amplitude will top out rather quickly. Unfortunately, my AW4 diagnostic Manual is a tad shy about giving the particulars insofar as voltage and frequency. One would have to put a meter on it and see what it is doing.

Another supposition. Chrysler does not want their Techs to be that immersed into the operation of the device. Just how to diagnose it and toss it out... Hence the lack of available Technical Data on the TCM operation. Forget about getting a schematic...

Glad to hear my guess was correct about the ISS/OSS relationship. It is for this very reason I am thinking both signals will have to be spoofed. The Blue Pill, if you will please... In fact, I'll take two, they are small after all.

The details on how the TPS is involved are sketchy. I am fairly convinced that it is the TV cable that calls for the downshift.

Logic:
When I fitted the 68mm TB, the transmission started shifting differently. Now, it is obvious that both the TPS signal and the TV cable position have been altered changing what both the PCM and the transmission are seeing. The addition of the 64mm Compressor pulley caused yet again a change in the shifting characteristics. Again for the same reason. Both the TPS and the TV cable are at a lower potential (if a cable can have a potential...).

The change? The transmission upshifts earlier under partial throttle conditions. Owing, I believe to the transmission believing that it is not under load. Lower TPS and TV cable values from stock.

At this pint in time, under easy throttle application the transmission will shift into OD and lock the TC by 40 mph. Downshifts happen quickly with the TC unlocking first followed by the gear change. The TV cable plays the biggest part here and that can be demonstrated by knocking it out of align. Go far enough and the transmission will never downshift...

Another player in this is my overall final gearing. With P285/75R16 tires and 4.56:1 gears, the Heep is geared 10.9% lower than stock. This mechanical torque multiplier reduces, yet again, the amount of throttle required to get the thing down the road.

One step at a time, eh?
 
Last edited by a moderator:
As far as I know - the TV cable only adjusts line pressure inside the transmission. That controls shift firmness and MIGHT control shift timing (since it could control how fast the accumulators will fill - but automatics are unicorn farts and magic pixie dust to me hydraulically, so I may be all wrong here) but I don't think it does.

I believe you're right on the reluctor thing - they're very close in design to an old RENIX CPS, internally. It's just a big coil of magnet wire on a core, may or may not have a magnet stuck to the tip, I think it does, and the slots in the ferrous gear/ring in front of the sensor tip increase or decrease the permeability of the airgap in the sensor core as the ring spins, which induces a voltage in the coil. IIRC lawsoncl (who designed that nifty signal conversion circuit for putting a 98+ coil sensor/4 pulse rotor tranny into a 97- reed switch jeep) found that the voltage peaked at something like 30 volts peak to peak. So a couple zener diodes and a resistor or two (which is exactly what he used) works perfectly as a clipper, then you just use capacitors and possibly an op-amp comparator and some resistor dividers to recenter the signal and clean it up into a perfect square wave for the microcontroller.

I have a diagnostic cable I built at one point that breaks out the ISS and OSS signals onto a 4 terminal barrier strip inside the cab... need to put that on the jeep and take it for a spin with the o-scope attached I guess.

I found the manufacturer of the programming adapter for the 89665 microcontroller and emailed them again; hopefully they reply and will sell me one. If they will, I'll dig in ASAP and see what I can come up with. It's been a few years since I wrote my own assembler/disassembler, but it isn't that complicated. Understanding the disassembled code on the other hand... :attom:

Sounds like your gearing is pretty good - my DD XJ has 3.55s and an auto with no forced induction... but I've only got 25" (12.5" rolling radius) rubber on it. It scoots pretty good for a 250k motor and a clapped out AW4. 3.07s would be closer to factory gearing with this tire size.
 
Last edited:
Gearing wise, being around 10% lower than stock helps to handle the larger tires. I must admit though, it was a tough choice for me. 4.11 gears would have been the break even "back to stock" choice and, of course, 4.88 gears would have been the better Off Road choice. Given the two factors of Forced Induction (pull power? and the fact that I am loath to run a pinion gear that small, the 4.56 set made sense.

Meanwhile, back at the Ranch...
I agree that short of putting a scope on the signals, we will have no idea of what they are. Good news is that that can be done in the garage. Jack Stands are such a wonderful invention. A speed sensor signal voltage reading would be delightful indeed.

Kastein, if you locate the programmer adapter, let me know and I will chip in on the purchase price. Only fair after all.

I thought it would be appropriate, at this juncture, to post up a system level drawing for the TCM. This is copied out of my Diagnostic Manual.

98XJTCMSystemPrint_zpsbcf67cc1.jpeg
[/URL][/IMG]

As can be seen here, the TPS is monitored and the Speed Sensors are documented as to tooth counts. Determining the count could be an easy task but, I feel that is is not required. If the thought is that we can lie to the TCM about the actual speed of the transmission, then all that would be required would be to massage the signals.

The AEM F/IC8 that I run does the exact same thing with both the Crankshaft and the Camshaft Position Sensors. By digitally delaying those signals, the ignition is retarded under boost. As both signals are offset by the same amount, no error codes are generated.

My concerns here are:
1) Speed Sensor voltage levels.
2) Interplay of the TPS.

IMO, as soon as we can determine the TPS involvement, we will be home free. As I see it, this is the impediment. Offsetting the speed sensors would not be that difficult. These parts may fit the bill. The choice could be made via a simple switch for the new circuit to be active or no. Sort of a Street/Trail selector switch.

Frequency to voltage converters, Texas Instruments LM2907 and LM2917
Voltage to frequency converter, Texas Instruments LM231N/NOPB

It has been a very long time since I attempted any sort of new design so am open to meaningful suggestions...
 
Last edited:
Actually, that's a very interesting point.

I bet you could delay a shift by simply massaging the TPS signal (to only the TCU - the ECU still needs the unmodified signal) so it doesn't see WOT until you want the shift to occur.

Also, I'd probably use the onboard timers and an interrupt handler routine with an interrupt-on-change input pin on the microcontroller to compute the frequency of the input signals and produce the new output signals - no need for an analog (and imprecise/requiring adjustment) solution that adds more parts to the board.

I've got a lead on the programming adapter but no price yet... manufacturer responded yesterday and told me who to buy it from, but the distributor hasn't responded yet.
 
Must be nice. Nice to have so many customers that the Distributor can afford to not respond to a request. Do you have the part number handy? I have lots of time to go rooting around the net...

I gave thought to the TPS signal. One would need to isolate the feed to the TCM. So as not to adversely impact the PCM input. Looking at the prints involved, the TPS signal is paralleled out to both devices.

This idea has been rattling around my little pea brain ever since the supercharger was installed.

Given the practical results of the changes made so far (i.e. new TB and smaller pulley) the TPS signal for any given road speed is now considerably less than stock.

Lets discuss the implications of WOT. As I understand it, the PCM goes into open loop as soon as the vehicle starts accelerating. WOT is not required to go open loop. This I have verified on mine via my OBDII software on the laptop.

So the question is does WOT TB play any role in the TCM decision path. It is possible that the TPS calls for the TC to unlock. We know that the TV cable plays heavily in this transmission. The '98, when I got it, had the worst shifting you can imagine. The TC barely would lock, and even if you stomped the pedal through the floor, it would not downshift...

Performing the very complicated (remove sarcasm) TV cable adjustment removed this behavior completely. To my thinking, this validates the importance of the TV cable as more than just setting the operating pressure of the transmission.

Here is what is in the Diagnostic Manual about the TPS signal:
"The TCM uses the throttle position sensor to determine shift points. The circuit is hard wired to the TCM."

Pretty illuminating that.

It does state that if the TPS signal is "out of range" for 7 seconds or the sensor ground circuit is open or shorted to voltage for 7 seconds a TPS fault (MIL) will be set.

I know from experience, that if the TPS voltage exceeds 4.8VDc, the fault will be set.
 
They are in Japan - I'm betting they just haven't gotten the message. Plus, I only want one, and they probably normally deal in 100 quantities :spin1:

The TPS signal should be pretty easy to isolate - just put an interposer between the TCU and the harness. Or if you don't mind hacking on the harness (I like to keep the factory harnesses unmodified, personally) just cut and splice the wire for it.

Let me dig up the specs on the microcontroller and EEPROM again real quick...

edit: the EEPROM is a 24C02, 2kbit I2C EEPROM. That's only 256 bytes. Once the MCU firmware ROM image is available it shouldn't be too hard to decode what the EEPROM stores.
 
Last edited:
That will work if combined with a DIP8 to SOIC8 adapter, but you'll need to solder the SOIC8 (it's about 1/4" square and has 8 leads) to the adapter to plug it in.

You can do roughly the same thing with Linux, some I2C bus tools, a few 74LSxx series logic chips and resistors/diodes, and a parallel port plug, which is how I was planning on pulling the data out of the 24C02. The only problem is that you won't be able to interpret the data in that EEPROM without looking at the code that references it to figure out what each parameter does.
 
Back
Top