Instructions to change fuel maps on 14CUX Griffith, Chimaera

[stevesprint]

blitzracing said:

Dont touch that unit, its only 2d mapping and completely unsuitable for a road car, as it has no vacuum take off for light load ignition timing, so it hits the fuel economy badly- very much a backward step from even the mechanical system you currently have. The Aldon Amethysist is the one you need for £200. From what I read on its spec' sheet it should interface with the Lucas ignition amp without problem.

http://www.aldonamethyst.co.uk/

Agreed, sounds much better as it takes its input from a standard 12v distributor output including ours. Plus it can switch between two stored maps so you can switch between unleaded and super unleaded without a laptop. Would you go for the Vacuum or throttle pot version????

Edited by stevesprint on Saturday 9th November 22:11

[stevesprint]

blitzracing said:

spitfire4v8 said:

The only thing I can't work out at the moment is the rapidly richening mixture right at the end of the rpm scale .. no amount of playing with scalars and fuel map would alter the basic trend there. An extra mapping point for 6500rpm would be fabulous!

Ive got a feeling the extra fuel is added from the throttle pot input but I dont know how. Heres MA bit on his chip.

"Where appropriate the map is extended to 6000-6500 RPM as determined by the application"

Mark
That's an interesting thought. You can see from Dan's notes below their are three throttle opening rows in the throttle table and that you only have to alter the second column on each row for a warm engine. I guess throttle table changes would affect the throttle response across the whole rev range.

danbourassa said:

The top row is always the coolant sensor count value and this tells the software what column of data to use. Only one column is in play at any given engine temperature. For example, if the coolant temp count reads 0x23 (approx 190 deg F),
only the second column would be in play (the next column to the right of this value).
So, using the example below, if you want to tune a fully warmed engine, you are now down to just 5 values to be concerned about.

; this 6 x 10 table is used to calc the throttle pot direction & rate (the 1st derivative)
; the resultant value is offset by adding 1024, stored at 0x005D/5E and ultimately used
; to dynamically adjust the fueling

New New
Map2 Map5
3FB 731 : 18 31 5A 73 89 99 B3 CC DD EA ; <-- coolant temp reading (low is hot, high is cold)
405 73B : 05 06 08 0A 10 1C 23 28 30 30 ; <-- throttle opening (compare value or limit)
40F 745 : 04 06 07 08 08 00 00 00 00 00 ; <-- throttle closing (compare value or limit)
419 74F : 2D 32 3C 50 64 FF FF FF FF FF ; <-- throttle opening (multiplier)
423 759 : 1C 18 10 0C 0B 14 14 19 19 19 ; <-- throttle opening (multiplier)
42D 763 : 24 18 10 0C 0B 1E 1E 1E 1E 1E ; <-- throttle closing (multiplier)

[stevesprint]

danbourassa said:

It may be possible to extend the fuel map yourself. If you look at the very beginning of the code section,..........

DAN, YOUR AN ABSOLUTE GEM!!!!

[stevesprint]

karlspena said:

Maybe there is a way to synchronize the TimeStampLogger with RoverGauge so the stamps match. I think PLX's software does logging as well, but I bet it would not be as easy to sync. Don't feel bad if I get a DM-6, I've been thinking to do it for a while. It's really neat since you can have several different sensors display on just one gauge. And it's really thin! Fits anywhere. Yes, by combo I mean dm-6 + sm-afr. It costs about 190 dls shipped. Quite a deal for a gauge that allows virtually infinite expansion options AND PC output for logging

Mark & Karls
I’ve successfully modified my Time Stamp Logger program to work with both the AEM AFR Gauge and the Plx SM-AFR sensor. There is no installation so just unzip and run with the following command line options:
timelogger loggertype comport
The first example below is for Mark
timelogger timelog 8
timelogger plx-afr 1
The com port at the end is optional but when used it will automatically connect and start receiving data as I’ve pre-configured the serial setting for the different loggers.

I’ve tested it the best I can with a serial loop back plug and included my test input and output files for both sensors.

Please do hesitate to email me with any issues & Good Luck, Steve
http://www.stevesprint.com/remap-14cux/TimeLogger....

karlspena said:

Is there a way to combine the output of this with RoverGauge's to have a precise measurement of AFR on each cell of the map? (I know there are other factors in play, but this would be awesome).

Karls – Yes, I’ll try modifying my time logger, as discussed, before the spring to match & merge the RoverGauge log with the timed AFR log, ready to import into an excel 8x16 pivot table. I’m sure we could create an excel macro to automate the excel import.

I really must now work on my Griff's winter projects but at least I've proved I can time stamp log the AEM AFR Gauge and Plx SM-AFR ready for merging.

Edited by stevesprint on Wednesday 1st January 22:01

[stevesprint]

When I saw Dan’s first post regarding extending the rpm range I soon worked out the following formula to convert from rpm to hex for columns 1 & 2.

5502 rpm divided 60 seconds equals 91.7 revs per second
Then dividing 1 sec by 91.7 rps equals 0.010905sec (the time for 1 rev in sec)
and divide by 8 for time between sparks in second. 0.001363
Convert 1363 (now usec) into hex at any site like
http://www.statman.info/conversions/hexadecimal.ht...

I then decided on 6000, 5250, 4500rpm for my top three rows and used the formula above to calculate the hex for columns 1 and 2 as below.

C800 : 04 E2 40 00 ; 6000 RPM
C804 : 05 94 00 13 ; 5250 RPM
C808 : 06 82 00 10 ; 4500 RPM

I've now noticed from Dan’s second post my 3 rpm rows are the same as the aftermarket chip and Dan’s graphs show how important it is getting the 3rd and 4th column correct. Therefore, Dan a big thanks for putting so much effort into demonstration the important of columns 3 & 4.

[stevesprint]

danbourassa said:

Steve, you keep forgetting the magic number. Just divide 7,500,000 by RPM and then convert to hex.

LOL!!!! - Thanks for making me smile after a busy day at work. Must be the only straight forward thing with the 14CUX.

[stevesprint]

Dan, Thanks for the RpmTable source code, I soon managed to compile it with my prehistoric c compiler and run it.

I can now see myself having hours of fun experimenting with extended rpm ranges. Anyone fancy a smooth 6000 rpm table???

Dan, I did laugh again when I spotted this line of code with the magic number "period = (UINT16)(7500000.0/rpm);"
Thanks again, Steve

[stevesprint]

danbourassa said:

I have mentioned earlier that some time ago Mark introduced me to a man who has developer information on the 14CUX. He prefers to remain anonymous for the present time (our Stig?)

The STIG, lol. – Its great to know we have a tamed guardian angel watching over us from above.

Some people say he lives on low/high nibbles, bits and bytes. Other say he is secretly installing a Rover V8 in the new TVR ..... All we know is, he is called THE STIG!!!.

Seriously Stig, we are all very grateful, Thanks.

[stevesprint]

Dan - I’m pleased to hear your road speed sensor rant as I had a huge amount of fun with road speed sensors when I changed from a Rover LT77 gearbox to a TVR Tuscan T5.

Early Precat Griffs with LT77 box do NOT have the TVR ‘speedo interface box’ part no: MO559 to stop the road speed limit. Instead Precats have a special version of the Land Rover LT77 road speed sensor that only produces 4 pulses per prop rev instead of the standard Land Rover one that produces 8 pulses per prop revolution.

On the later T5 gearbox cars TVR changed to a very basic coil/magnet sensors on the diff input with a 16 teeth-chopping wheel, the same chopping wheel in one of my pictures in an earlier posts. This arrangement produced a much higher frequency and very weak sign wave that required amplifying and transforming into a square wave. I therefore believed the road speed interface was introduced to amplify, square off, and remove the road speed limit for the 14CUX.

After changing my gearbox 4 years ago I first ran with all 16 teeth and the TVR weak sign wave signal sensor, strangely the engine appeared to run faultlessly. This was the days before RoverGauge so I don’t know if there were any fault codes but I suspect their was. Interestingly my programmable speedo didn’t wake up below 15 mph and wouldn’t read past 100mph on a track day.

As I don’t have a TVR ‘Speedo Interface’ part no: MO559 I bought a Caerbont 12v sensor EMP34-1 sensor (http://www.caigauge.com/page18.html) as it produces a full 12V square wave as required by the 14cux. At the same time I also removed half the chopping wheels teeth, from 16 down to 8 and immediately I couldn’t drive above 80mph on a track. I therefore assumed I was hitting the road speed limit of the ECU (R2422) of 80mph x 2. The limiter was smooth like a miss fire and not a sudden full on / full off. After further testing I realised it also happened in 4th gear at a slower speed but still at about 4,000 rpm. Fascinating a road speed limit that varies depending on the gear you are in but I could rev past 4,000rpm in 1,2,3 gears. I had no idea what was going on but all I knew was that I had to reduce the number of teeth down to 4 pulses per prop revolution to match the LT77 speed sensor.

Once I removed another 4 teeth leaving only 4 pulses per prop rev the engine finally run faultlessly again and my speedo worked a treat.

danbourassa said:

High RPM is coupled to high road speed and since there is a road speed limit in the software, it needs to be measured more often under high RPM conditions. It hogs an increasing percentage of the timeline. This should be especially annoying for TVR owners since the road speed limit is disabled, but the price of all those measurements continues to be paid.

Maybe my 8 teeth chopping wheel doubling the road speed was just hogging too much processing time?

danbourassa said:

Also, I'm not sure yet whether the 14CUX can operate properly at the RPM limits being discussed in this thread.

I will have fun finding out next year as my engine sings all the way to 6800rpm but I do realise that doesn’t mean it is operating properly.

danbourassa said:

The road speed input is, in fact, a "square" wave but the ADC reads it directly as either high or low. There is no FVC.

What does FVC stand for.

danbourassa said:

Thanks for listening. I feel better.

Pleasure, Its fascinating to understand the 2 vertical daughter boards and how the road speed is actually calculated.

danbourassa said:

The actual limit is in the code section of the PROM, not the data section. Look at the value at $EA41. If it's $C4, this is the limit in KPH (196 KPH or 122 MPH). This section of code sets a bit which normally causes fueling to be cut off. This fuel cutoff code is missing in TVR code, but a lot of clock cycles are wasted measuring road speed anyway.

How are the clock cycles being spent if the code is removed in the TVR prom, is the code and limit together at address EA41 ? Is that 6A41 on the prom if so you can see the following values.

Griff 500      80 128 kph    80 mph
Griff Precat   DD 221 kph   138 mph
Land Rover     C3 195 kph   121 mph

Colin - Thanks for the new RoverGauge version, The new column headings will be a huge help while re-mapping.

Edited by stevesprint on Sunday 17th November 14:35

[stevesprint]

danbourassa said:

As far as hitting the speed limit "softly" (like a misfire), that's by design. If you look at the flowchart I did, you will see that only one bank is shut off. This is unlike the rev limit, which kills both banks.

If the Caerbont sensor is directly outputting a square wave, it's probably a Hall effect sensor, similar to the internal LT77 sensor and the external LR sensor. These work down to zero Hz. This is the type that TVR should have used and not the passive type (which I think is called variable reluctance) that needs external signal processing. Mark alerted me to this shortcoming which was timely because Colin and I recently did an LT77 to T5 on our 94 Griff 500 (one of maybe 3 in the US). We used a Hamlin sensor

Yes, it did feel like running on one bank, so maybe I was hitting the road speed limit, it just seemed strange it kicked in at a slower speed in 4th gear. I only purchased the Caerbont sensor as their techies looked up the 14CUX requirements and recommended the EMP34-1 and yes it does work down to zero Hz.

Can you remember what Hamlin sensor you used and do you ever get a road speed sensor fault code. I ask as occasionally I do but you wouldn’t know without RoverGauge, hence my questions.

You kept your Griffith quiet, now you'll have to show us a picture. What map does it run and is it what started this project?

danbourassa said:

Only the final check of road speed (where the fuel is shut off) has been removed from TVR code. All of the measurements are still being done. Which brings me to my final point.

Arrr I see and sounds like it’s not removed in the Precat R2422 prom as I was hitting it. Good job I now run R2967 with my complete data structure.

danbourassa said:

Colin and I have been able to build the code ourselves for several months now. This was not easy to set up since disassembled code uses hard memory references and we had to convert them to relocatable references. We'll be putting together a "roll your own" software kit soon. We hope to have road speed options in the kit such as shutting off road speed measurements above a certain RPM. Maybe eventually an option for a 20AM MAF. Reassigning unused ADC inputs should be easy. There will be no reason to rant anymore. We can just fix it.

Impressive very impressive, can I be the chief tester? Are you going to use the same map data structure so we can use our existing fuel tables?

[stevesprint]

danbourassa said:

For those interested in extending the RPM table (why do I get the feeling Steve is one of them?), I posted the source code for a simple program that models the 14CUX. This allows scanning through the entire RPM range and creating an output file. The file is easily graphed with Excel (or similar) and validates your changes. The ideal curve must be (as math geeks would call it) a monotonic function which simply means a curve that changes smoothly and in one direction. If there is an abrupt step or discontinuity, you can see it and correct it. There is also a Word doc with graph images. I've found that google doesn't render the images online as well as when you download the file.

Dan - Thanks for the source code. I've been enjoying getting back into coding again and modified your RpmTable program to read the Rpm Table data from a text file to save recompiling it every time and to allow other to join in the fun. Mark or anyone else, if you are interested in running Dan's program you can download an executable version from
http://www.stevesprint.com/remap-14cux/RpmTable.zi... . The zip file also contains an example input file called RpmTableInput.txt. Please note their is no validation so please keep the data in the correct columns. If you run it from the command line it displays the data it is using.

Should you have any issues please do not hesitate to contact me as it's more likely to be my dodgy mod than Dan's excellent code.

Dan - I hope you don't mind.

Edited by stevesprint on Wednesday 1st January 22:12

[stevesprint]

danbourassa said:

Hamlin 55075.
http://www.hamlin.com/product-detail.cfm?productid...
We're just finishing the job and don't have a lot of road time yet, so I don't know about fault codes.

Thanks for the link. The T5 is one of the best mods I’ve done to my Griff. Did you use a T5 with the external gear linkage??

danbourassa said:

Colin and I, between us, have four 14CUX vehicles so we got started on this as a matter of necessity. Conveniently for me, the Griffith's previous owner still has a picture on his website:
http://www.toadhallcars.com/TVR.asp

I'm impressed and it sounds like you have a wonderful father & son relationship.

danbourassa said:

It also runs R2967, but beware. Not all R2967s are alike. The tune number should be unique to the tune but, in this case, someone got lazy. The 95 R2967 differs from the 94 R2967 both in base idle and fuel maps (95 is leaner).

I’ve also noticed 400 & 450 Chimmaera and Griffith 500’s all run R2967, interestingly the code is identical and only the data is different.

danbourassa said:

We now use the checksum byte all well as the tune number to keep track.

Brilliant idea, it would therefore make sense to display the checksum in RoverGauge next to the revision number especially with all those different TVR R2967.

danbourassa said:

Not a bit. I should have done it that way to start.

I’m glad you didn’t as I'm slowly getting back into coding again.

danbourassa said:

The fuel maps won't fundamentally change. We will be using the new fuel map layout (about 1992 on) which most use anyway. There will be a configuration file, where options can be set. Right now we can build R3526 and R2967 (1994)

Do you mean the fuel maps won’t change location and structure. Seriously you can already re-assemble R3526 and R2967, amazing. So you really do stand a chance of reusing an unused ADC input for a lambda sensor. No Pressure.

danbourassa said:

Colin has taken over support of CRASM which is the open source assembler tool we'll be using. CRASM has been packaged with Linux for years and works under Windows also. The output of the tool chain will be a 32K binary ready to burn to PROM or download to emulator. Even if you don't go that far with it, the source files have years worth of annotations that may be useful for understanding how things work.

Do you mean the assembly source code for the 14cux code?? That’s unheard of in 20 years. I don’t understand assemble code but I’ll look forward to learning about CRASM and your configure file.

danbourassa said:

Yes. We need you, Dave and others involved. I think anyone who's still reading this thread is a potential tester and even developer.

Sounds very exciting and it would be an honour to help you and Colin. I hope it can wait until next year as our cars are now all tucked away for our winter projects. I’ve been married to the Rover V8 for 25 years so don’t panic if I’m not around so much during the next few months, but be assured I'll certainly be up for some testing next year.
Bye for now.
Steve

Edited by stevesprint on Sunday 17th November 23:34

[stevesprint]

spitfire4v8 said:

But the one which is causing issue right now is I cannot save the .bin file from tunerpro.

Jools
I'll call you later, but don't panic as the map is safe on the Ostrich

[stevesprint]

danbourassa said:

This is a little off topic but it's an interesting story, and since Steve asked... (and after all, he started the thread!)

Dan – I’ll consider myself told off, but as least I’m relieved to hear you are using the later style T5 as the Griffith 500 T5s don’t fit the Precat chassis without cutting out the top cross member. Certainly sounds like you know what you are doing and you are also in touch with the suppliers I would use. The only supplier you missed of my list is http://www.racetechdirect.co.uk/

Now we know the 14CUX masters (you and Colin) have a Griffith we can’t be told off for this thread being in the wrong place.

Edited by stevesprint on Tuesday 19th November 00:03

[stevesprint]

karlspena said:

Steve, I could finally deal with the issue of the graphs showing incorrectly in tunerpro. Seems like they show wrong only when the values are displayed as hex. I changed the display values to integrers and fixed a few minor notes on the definitions. Here is a copy of the file:

https://www.dropbox.com/s/9ftns5im4lzz03z/14cux-Ka...

Also, added scalars for the idle adjustment factors (AC, neutral and heater), for anyone planning to use the heater input to bump up the idle when a big fan comes on like Mark did (I have a taurus fan which pulls a LOT of amps).

On a different note, for some reason the checksum plugin in tuner pro is not calculating or setting the checksum correctly, for the time being I'm just using Workshop15's 14cux toolkit before burning the eprom. Is there something I should do for TunerPro to set the checksum whenever I save the BIN file?

Thanks again to everyone here for all the great work and help on this.

Karls
Well spotted, changing to integer also fixes the graph for me in TunerPro RT, it's just strange it works fine in the basic TunerPro in hex.

Thanks for the .xdf file I’ll update my version.

No, it automatically recalculates the checksum each time you save the bin. Make sure 14CUX_CHECKSUM2.0.dll is in “C:\Program Files\TunerPro RT” you could try having it in the current directory as well. Arr Robert did release to versions so check you have the latest version with the 2.0 on the end and dated 19/09/2013 plus delete the old version. Also, another thought, it only corrects the one checksum at 7FEB which is the important one.
Good Luck

Edited by stevesprint on Monday 18th November 22:58

[stevesprint]

spitfire4v8 said:

There's a couple of things I can't get working in tunerpro .. the increase/descrease/fill all cells doesn't work, I have to fill each cell manually but thats no biggie as i have to map each cel individually anyway. But the one which is causing issue right now is I cannot save the .bin file from tunerpro. I've not actaully had to save a file for burning yet as I've not finished my mapping . but I was going to save the 16k image through rovergauge, but would be nice to save it direct from tunerpro. It just doesn't work for me for some reason.

A Triumph Spitfire Mk4 with a Rover V8 would be fun especially if it has a 14CUX!!

I’ve been playing with TunerPro as you do and realised you can’t increase/decrease cells in raw hex mode. Therefore right click on the table in the parameter tree and select Edit Parameter XDF Info and change output type to integer. Re open the fuel table and highlight the cells to increase/decrease and click execute. To quickly switch the table view between hex and integer right click anywhere on the table and select Show Raw Hex or Show Calculated Values. Let me know how you get on as it might behave differently while you are emulating

With regards to ‘save as’, it might not work because TunerPro can’t find Roberts 14CUX_CHECKSUM2.0.dll, so please read my post above to Karls. You can download the TunerPro .xdf config file and the checksum dll from http://www.stevesprint.com/remap-14cux . If that doesn’t work as you rightly say you could save the Prom via RoverGauge and then run Matts 14CUX Toolkit to duplicate the map by selecting copy rom1 to rom2 and click fix checksum 1 & 2.

Edited by stevesprint on Thursday 21st November 18:21

[stevesprint]

karlspena said:

Is it difficult to program the ecu in real time using ostrich? are there any mods required or it just works as it comes out of the box with tunerpro rt?

I'll let Jools answer the first part.
No mods requred, it just worked once you have installed the usb driver. The Ostrich was very reliable in my Griffith, to the point you could forget it was there expect it caused interferance on my radio which my daughter complained about.

[stevesprint]

spitfire4v8 said:

excellent news and many thanks for doing this. I know you're doing this for free and for the good of the RV8 world .. but let us know if you ever set up a donations page or similar .. I think it's amazing what you are doing and would very happily make a donation to say thankyou. In the meantime ... Thankyou!

Jools, I couldn't agree more and I would certainly donate Colin and Dan some beer money if I could. I have leant a lifetimes worth of knowledge from them in just two months, not only 14cux knowledge. Plus they have been very patience with me when I have my blonde moments, I really appreciate it. Colin & Dan, if you ever need any parts posted from the UK please do not hesitate to ask.

[stevesprint]

UPDATE AND OVERVIEW FOR NON GEEKS

Ribol said:

For those of us that wouldn't know an Ostrich from an Eprom could some kind soul who speaks both Geek and English please give those of us who are interested and trying to follow this a quick sum up of where we are with this today?

In other words, assuming it can now be done(?) what would be the simplest way of someone who isn't clueless about cars altering their own 14CUX fuel map?

Chuffmeister said:

I wanted to ask that, but thought I was the only one that hadn't a Scooby Doo of what they were talking about…
So when, how, and how much...

Here’s an update for non geeks in plain old English that even Scooby Doo might understand. As I’m only a part time geek I know how you feel especially when I’m trying to keep up with the masters in America.

WHEN
Our American friends have cracked the 14CUX and published everything we need to know to completely remap the 14CUX. Jools has now successfully fully remapped a Griffith 500 on his rolling road using all of the available gadgets to streamline the whole process. Without doubt this proves the 14CUX can NOW be fully remapped by anyone on a rolling road with the correct gadgets.

MINIMUM GADGETS REQUIRED
I’ve personally had a quick session on the local rolling road armed only with my laptop, a few chips for £8 each and a chip programmer for £30 and successfully proved that’s all you need to remap the 14CUX. Unfortunately, I could of spent the whole day their copying and swapping chips while remapping every rpm point under different loads but that would of cost hours of rolling road time. Jools uses a Moates Ostrich as it allows him to change the amount of fuel while on full throttle and you instantly see the change take effect on the gas analysers and on the rolling road bhp readout. How cool is that!!

HOME TUNER
The home tuner doesn’t need to buy a Moates Ostrich that allows remapping in mid flight as that would be dangerous while driving but ideal on the rolling road, however it would save pulling out the chip for each test.
I’ve proved you can capture data on a laptop while driving and then use the captured data at home to remap the chip from the comfort of your armchair. I haven’t actually tested the whole process as I don’t have a gas analyser and therefore I’m waiting for a volunteer to email me a gas analyser computer file so I can complete the testing.

I’m sure everyone realises you cannot tune an engine without a gas analyser, Therefore to home tune you’ll have buy one of the following gas analyser and preferable weld the sensor into the exhaust system as near to the engine as possible. I don’t recommend clamping the sensor to the tail pipe while driving.

http://www.ebay.co.uk/itm/AEM-GAUGE-6-in-1-TYPE-WI...

http://www.ebay.co.uk/itm/PLX-DM-6-AFR-Multi-Gauge...

I suggest these two gas analysers, as I’ve checked we can use the computer data they generate.

HOW MUCH
With either approach you’ll need a laptop running Windows XP or Windows 7 with 2 spare usb port, plus at a minimum you'll also require the following three items:

1.Chip programmer for £30, my TOP853 has been faultless and is excellent value for money.
http://www.ebay.co.uk/itm/USB-universal-programmer...

2. A few reusable chips for £8.00 each like these (28C256)
http://www.ebay.co.uk/itm/AT28C256-15PU-Atmel-EEPR...

3. RoverGauge cable for £35 from
http://www.pistonheads.com/classifieds/parts-and-p...

HOW
With either approach you need to install and run the following free software:

RoverGauge
To check your fuel map updates are as expected.

TunerPro (no Ostrich support) or TunerProRT (with Ostrich support)
This is a user friendly graphical interface you use to make changes to the fuel information. Your changes are either saved to hard disk and then copy onto a chip using a chip programmer, or with a Moates Ostrich instantly updated on the ECU in mid flight.

TunerPro definition
Configuration information that TunerPro(RT) uses to know where the fuel tables are on the chip.

Chip programmer software
Used to copy your updated fuel maps, created in TunerPro, onto a chip.

TimeLogger
This is for the home tuner to captures exhaust gas information onto a computer while driving. Although it is a work in progress it will eventually merge the exhaust gas information with RoveGauge information to produce an exhaust gas results table that can be cross referenced with the main fuel table. You can then make the necessary fuel corrections in TunerPro. As mentioned above I currently don’t have a gas analyser so I would be grateful if anyone can please email me a gas analyser computer log file so I can finish the merge function and testing.

The above programs can be downloaded via www.stevesprint.com/remap-14cux

Should you have any issue with the software links or have further questions please do not hesitate to contact me but please go easy on me as I’m doing this for fun plus I’m only half geek.
Cheers, SteveSprint

Edited by stevesprint on Thursday 21st November 11:06

[stevesprint]

danbourassa said:

stevesprint said:

Colin & Dan, if you ever need any parts posted from the UK please do not hesitate to ask.

One Cerbera please, lightweight, Red Rose, 4.5, old style headlights, color unimportant.

Nice, only if you promise to run it on a 14CUX