Instructions to change fuel maps on 14CUX Griffith, Chimaera

It's probably a good idea to borrow Mark's data logger and check the waveform. If the waveform is 0V/12V which is what my old LT77 produced, then the ECU should be happy (not sure about the speedometer). I use the Hamlin 00 part (digital output) and I generally like the idea of the Hall effect technology because the signal doesn't fade as the wheel slows down. However, if your Caerbont's signal is internally processed and outputs a square wave, I think it should work.

Here's one other thing to think about. The VSS comparator threshold is set to $C8 (in roadSpeed.asm). This level will not work if the waveform is degraded and you may have to reduce the value. My bench setup uses a TTL level VSS (0V/4V) which would not initially work. I had to reduce the threshold to somewhere between $35 and $4C to get it to trigger. In code version 3, this threshold is no longer hard-coded but is defined in the data file as follows:

 vssStateThreshold = $C8     ; normally $C8 (reduce for bench testing, 1.0V = $35, 1.5V = $4C)

Mark,
That's the best offer I've had all year especially if you mean your logger you developed that piggy backs straight onto the 14CUX as it must be very precious.

Although my RG speedo is now working I would still appreciated the opportunity to borrow a logger. I would be to scared to borrow your piggy back one so I've made the road speed signal cables easily accessible though an air vent.

If you make it to the TVR Berkshire pub met this Tuesday we could have a quick logging session down the dual carriageway opposite the pub, any excuse for a blast, lol. I'm keen to learn, test and compare my steering speed sensor with my speedo sensor as my steering sensor is halls effect, but doesn't work with RG unless its output is simultaneously connected to the steering ECU.

There is no pressure to meet at the pub as my RoverGauge speedo now works and its now purely self-indulgence.

Thanks for the offer
Steve

It’s not often you see a homemade 14CUX data logger in a pub car park, only at a TVR meeting. Mark, it’s mine now and you’re not getting it back.

Dan, Please tell your wife you’re only working on the 14CUX for her benefit because you both might be invited to stay with us if you ever visit the UK, but only if you’re allowed to continue.

Dan, It would be useful one day to learn how to recalibrate the 14CUX road speed but seriously it can wait until the winter as I can easily do it in excel. I guess Colin could even add a recalibration feature to RoverGauge.

The line between madness and genius is a thin one- pity Ive fallen on the wrong side in a pub car park!

The scan rate of the logger is relatively slow, so you dont get a true reading of the signal as speeds up- it tends to put a spike on the leading edge as the pulse rises- in the case of the speedo sensor simply make sure you get a good clean 12v square wave (or what ever the mark space ratio is for your sensor)- you can do this as slow as the car can move to keep the frequency low.

I think it's safe to recommend it. It's not expensive, so if, for some reason, it doesn't work for him, it won't be a disaster. The output waveform looks very much like a square wave (similar to the LT77 except for frequency).

This brings me to a question about the graphs. Why do they show spikes rather than a square wave? If the ECU is seeing spikes, they could be easy to miss by the sampling code. The Hall effect sensor seems to electrically duplicate the profile of the crown wheel, which, it seems to me, is what you would want. A square wave close to 50/50 duty cycle gives the best chance for capturing each state transition.

Just in case anyone finds it interesting or useful, here's some info about what we did to deal with the road speed signal while doing the T5 swap on Dan's Griffith:

I think the LT77's output shaft sensor was producing 5 pulses per every 4 rotations, but the new tone wheel with the T5 installation would produce something like 17 pulses/rotation. I decided to build a small programmable 12V frequency divider so that the new high-frequency pulse train could be stepped down to the equivalent LT77 rate. I went with a TI MSP430 micro because that made it easy to change the software for different behavior if required. (And buying MSP430s doesn't exactly break the bank.)

Note that this is very much a prototype. I can't guarantee that it'll work for everyone, but it's certainly a starting point for those that want to adapt the fast waveform of the multi-tooth tone wheel to the instruments in a car originally fitted with the LT77.

Here's the schematic:


and here's the MSP430 code:
http://pastebin.com/5FGMtAmB

Id grab one of the trace .bmp image files the logger records and compare it with the text logged outputs I assume you are using- it will tell you loads more than just the numbers.

Dave, you may be correct about this. As far as I can tell, even if something as essential as the MAF sensor fails, it does not force the limp home map. Instead, the ECU substitutes a value based on TPS position and coolant temperature and continues with the current fuel map (and you get a MAF related fault code, of course). Then why have the limp home map at all? There is still a lot I don't understand about this. Map 0 is considered a closed loop map by the ECU and the code path is the same as maps 4 and 5. But what if you don't have O2 sensors? Does this mean that fault code 21 is soon followed by fault codes for the O2 sensors? It seems to me that map 0 is unnecessary and if code just defaulted to an existing closed loop map (out of concern for the possible presence of catalytic converters) it would be just fine.

If only the tune resistor can force limp home mode, then its fault code 21 is one that most NAS vehicles can never see. Since at least 1992, and possibly earlier, NAS vehicles have the fuel map locked to map 5 and the resistor is ignored. There must have been enough sales volume in North America by then that a number of things regarding the 14CUX became unique for NAS. Although the blue 2-way tune resistor connector was still in the wiring harness (at least initially) the terminal was missing from the 40-pin connector. This, I imagine, had to make the wiring harness NAS specific. Also, even though the ECU software still treated the map locking as a settable option in the data portion of the code, a fixed mask value disables code 21. Again, this points to NAS specific code.

You have probably figured this out already but the fuel map number is stored in three separate places in RAM.

fuelMapNumber (X202C) -       This is the main working value. It's used to make code path decisions (for example open vs. closed loop)
                              and used to set the address pointer when loading data from the fuel map data structure.

fuelMapNumberBackup (X0050) - This is in the RAM area that is preserved by the battery. It exists mostly to complicate your life. This
                              value is compared with the above 'fuelMapNumber' and you get DTC 21 if they don't match. This is why you
                              can't change maps on the fly without getting the fault code. This is easy to defeat, by the way.

(mirrored value X0050)-       All the battery preserved values are also saved in a second area in RAM. They are periodically compared
                              and, if there is a mismatch, the main values are set back to defaults. I think this mirroring was done as
                              a sort of fail safe but, I'm convinced, it just makes matters worse.

I think this should work just fine. Version 3 has a fuel map force option built in.

The top two lines are in the data file and remainder is at the top of tuneResistor.asm. Instead of checking the lock value, the code loads the defined force value over the just measured tune resistor (in register A) and continues normally. This should never fail since the measured resistor value is now irrelevant.

FORCE_FUEL_MAP = 0  ; set to 1 to activate fuel map override
FUEL_MAP_VALUE  EQU  $70 ; $70 forces map 3 (change this as required)


IF FORCE_FUEL_MAP

adcRoutine10    ldaa    #FUEL_MAP_VALUE
                bra     .LD552

ELSE
adcRoutine10    ldab    fuelMapLock             ; load fuel map lock value
                beq     .LD552                  ; branch ahead if zero
ENDC

Code checks from the lowest value up, as follows:
Less than $0A = fault (map 0)
Less than $3D = map 1
Less than $63 = map 2
Less than $80 = map 3
Less than $B9 = map 4
Less than $F6 = map 5
Else fault (map 0)