Instructions to change fuel maps on 14CUX Griffith, Chimaera

[haaren]

CGCobra said:

I've found that if you connect RG then start the engine you will get the figure in the default settings (5500 IIRC) but if you start the engine then connect RG you will get the value associated with the map in effect.

I've tested this today: connected before start shows 5400rpm, connect with running engine will show 6250rpm.
As I've been informed last weekend my chip is a standard land rover file, do not expect 6250rpm on a standard land rover except for a bowler maybe

[CGCobra]

haaren said:

I've tested this today: connected before start shows 5400rpm, connect with running engine will show 6250rpm.
As I've been informed last weekend my chip is a standard land rover file, do not expect 6250rpm on a standard land rover except for a bowler maybe

The chip could really be anything if it's been modified and I notice that of the BIN files I have there are several with the R2967 code which all show ident code 1A17 so presumably the same is true for R2422.

In my opinion the best way forwad is to get to a known quantity with one of the new chips and take it from there.

Edited by CGCobra on Thursday 21st August 13:18

[blitzracing]

haaren said:

I've tested this today: connected before start shows 5400rpm, connect with running engine will show 6250rpm.
As I've been informed last weekend my chip is a standard land rover file, do not expect 6250rpm on a standard land rover except for a bowler maybe

Thats not a standard map- it has an extended RPM table. Your best bet is to open the ECU and have a look at the chip for its markings. Stock maps are soldered in on early ECUs and the Eprom has no window and is black with just a sticker with the tune revision number on it. Later ECUs have a socket, but the chip is covered in a black plastic cover that can prove awkward to remove. After market may be marked Tornado systems, or TVR ones are just engine size and cat or non cat marking.

[AllanWorms]

CGCobra said:

Thanks Allan.
With your base idle set to 500 and presumably your ECU value set to 900 (or possibly 800) what %age do you find you stepper possition to be at?

I do have a feeling that there is still "something else not quite right" and I am currently looking to get the car smoke tested for a vac' leak.

Mine is in a Auto Disco, so it's different. Normally, I beleive the standard Disco tune is 600RPM in D/R and 700 is P/N. I've changed to to 625 and 675 though.

The original Land Rover "Base Idle" spec is 525 RPM +/- 25 RPM - it's not related to the MAP base idle, as it doesn't change for auto vs manual - I think it's entirely as a base to have the Stepper add onto. I assume, that it should be set the same, regardless of the MAP idle speed - to probably even the TVRs should be set as closeto 500 as possible.

Honestly, I can't recall my stepper amount... but I think it's somewhere near 30%??? (Edit: That would be in gear, so with the load of the auto trans...)

My understanding, is if the stepper % is too low, the resolution per step is too high, because it can close too much for each step... where further open, it doesn't make quite the same difference to the RPM, per step.

Edited by AllanWorms on Thursday 28th August 08:47

[AllanWorms]

CGCobra said:

That may not be your ECU causing that though, hydraulic lifters have a pump up facility which will hold the valves open at high RPM (can't remember the setting but around 6k rings a bell) as a rough and ready rev limiter. Not sure if later, ECU controlled engines, still had this behaviour as the ECU should have taken over this job and of course TVR may have used different ones.

The Rover V8 is really good at eating the cam lobes too, which can cause a sudden lack of breathing, resulting a lack of power and even gentle missfires, as the RPM gets high.

[CGCobra]

Hi all

I know it's gone a bit quiet here these days and I'm in two minds whether I should start another topic but in the hope that anyone is still monitoring this subject I have a couple of questions.

I'm currently trying to help out a gent who is struggling with poor running on a setup he has purchased and been left in the lurch with, issue discussed here https://www.v8forum.co.uk/forum/viewtopic.php?t=16... if further information required (better than me trying to give it here second hand).

He has recently created an RG log and, although it's probably not ideal as he's new to RG, I believe it does reveal relevant data.

The most obvious issue in the log is the data series labeled "Lambda Trim Odd" and "...Even", these are swinging between +255/-256 for the Odd bank and +227/-249 for the even. I'm sure this can go quite deep but let's start with some basics due to my limited understanding of the closed-loop systems.

Q1 - Are the values in these streams trim values (as the header suggests) or Lambda readings? - Pretty sure trim but want to be sure.
Q2 - I'm convinced that this swinging between (more or less) maximum and minimum values is not correct, can anyone confirm or deny?
Q3 - I'm assuming this reports whichever trim type (short or long) was selected in the RG interface is this correct and is there any way to capture both in the same log? I'm guessing not.

As always any help greatly appreciated.

[CGCobra]

Possibly also worth mentioning that I got a copy of the Battery Backed RAM from the owner.


Seems strange to me that the trim values are all $8000, surely that's the m id-point value, effectively zero?
If so that would only happen if the unit had been completely powered down (unit unplugged), the engine was running perfectly wouldn't it?
The ownder tells me he didn't unplug it so I'm wondering if the permanent live is missing.

[Bilf]

I have a 1985 Landrover 90, with a 3.5V8 Efi from a 1992 Discovery I, and Autobox ZF4HP22 from 1989 Range Rover 3.5V8. No cat.

I'm not a mechanic but am a software engineer. Reading this thread and remap-14cux site has got me excited.

I have the relevant kit and can easily socket the 14CUX and flash some roms.

I've asked our new AI insect overlords to suggest the top 3 roms for my engine.

It vomited out the following

‐---------
Top 3 Recommended .bin Files for Your 3.5L Rover V8 (No Cat, Discovery 1 Auto)
These are the best performance-oriented free bins from remap-14cux website.

All three are TVR precat-derived merges on Land Rover's final R3652 code base, making them suitable for your low-compression 3.5L because:
The 14CUX hardware and injectors/AFM are identical across 3.5L/3.9L/4.xL Rover V8s.
Precat fueling is richer and ignition advance more aggressive than stock Land Rover maps – this gives safe, noticeable gains (sharper throttle, better mid-range torque) on low-comp 3.5L engines without risking detonation (especially on no-cat exhausts).
R3652 base fixes common Disco issues (idle stability, hot starts, overrun shunting in autos).
Proven interchangeable across displacements by the community – richer TVR maps "wake up" the conservative factory 3.5L tune without needing other mods.

1. R3652_430_6250_LowBaseIdle.bin (Top recommendation – most aggressive)
Why suitable & key changes vs your stock map:
Aggressive TVR Griffith 430 Precat fueling + Chimaera 450 elements – richest and most advanced timing for maximum "faster" feel on your 3.5L.
Extended fuel table to 6250 RPM (prevents lean-out/safer if you rev higher).
Hot start fix + lower base idle option + overrun pops/bangs (fun exhaust note with no cats, smooth low-RPM decel).
Overall: Biggest throttle response and torque gains; smoothest drivability fixes.

2. R3652_400_6250_LowBaseIdle.bin (Strong balanced alternative)
Why suitable & key changes vs your stock map:
TVR Griffith 400 Precat fueling/timing – solid performance increase but slightly milder than the 430.
Same 6250 RPM extension, hot start fix, and lower base idle option (no full pops/bangs).
Overall: Excellent daily drivability upgrade with noticeable punch; cleaner overrun than the 430 variant – great if you want gains without extra exhaust character.

3. R3652_430.bin (Simpler core aggressive option)
Why suitable & key changes vs your stock map:
Pure TVR Griffith 430 Precat fueling/timing on R3652 – strong performance without the full extras.
Standard RPM table with minor overrun tweak (some pops but not optimized).
Overall: Good torque/response boost and idle improvements; removes speed limiter cleanly – ideal if you prefer simplicity over extended RPM or idle tweaks.
Start with #1 for the most noticeable upgrade. All will make your 3.5L feel sportier than stock; use good fuel and minor AFM CO trim (~1.4V) if idle needs fine-tuning after install.

---

Ok, sounds great.

Is it talking rubbish, or, are these 3 roms actually going to work without blowing up the v8?

Im a tight git, so while a Tornado chip is appealing, for £400, if I find one of these 3 roms makes a difference, it will have cost me £4.

Will these roms work on the 3.5l v8?
Am I likely to cause mechanical damage?
Anyone else do similar?
Should I just pay the £400 for a Tornado?

Thank you for your input

[CGCobra]

Hi Bilf, great to see a new contributor along.

I'm not convinced the output is that foolproof, I don't have time to read in detail at the moment but straight away I noteced some comments about aggressive ignition advance which is a bit odd as 14CUX does not control ignition. Not a good start!


Personally I don't see any point in going for a tune aimed at a larger engine such as 4.3. This is a MAF based system using a matrix of 8 row x16 columns values to control fuelling value, the 8 rows are related to air flow, it is basically the reading from the MAF which selects the row. All things being equal this is going to be proportional to the swept volumne so, if the table is configured for a 4.3L, the airflow for a 3.5 will probably not get it to the upper (or lower depending on your point of view) rows,

I'd suggest starting with a chip for the 3.9L engine (not sure what tunes are available directly for the 3.5) and I think going for the R3652 is definitely adviseable as this has the 'latest, greatest' program built in and I don't think there are any downsides to that.

Personally I'd steer clear of the Tornado chip, I had one of these in mine. Never saw any benefit and have since moved to the tunes your 'bot has mentioned and found these a much better starting point.
Even when I bought my Tornado tune I was confused how the supposed guru of RV8 tuning, Mark Adams, was telling all and sundry that a 'one size fits all' 'off the shelf tune' was a good idea. RPI were also in the mix and I wouldn't trust anything which came from that source!

Obviously I now have a copy of that tune downloaded via Rover Gauge but I really don't think there is any value in it.

I can't imagine how any tune is going to blow up the engine, that would only really be possible if someone added some random value to the fuelling matrix or irresponsibly tweaked some program code on the chip.

At its basic level the 14CUX is simply measuring air into the engine and matching it with fuel with slight variations in the fuel to give different AFR values for different conditions, this is mostly load conditions although RPM is also catered for.

In my opinion running any of these tunes should be relatively low risk and definitely worth a try. I'm also a tight git but I'd strongly suggest fitting a wideband AFR gauge with the capability to log the output. I have an AEM unit which displays the value but, more importantly for me, also pumps serial data out to my laptop, the program running on there timestamps it and allows me to merge that with RG logs.

Although this thread has gone a bit quiet now I'm planning an sticking around for a while and always willing to help.

[Bilf]

CGCobra said:

I'm not convinced the output is that foolproof

Wise words, they're convincing but often wrong.

Really appreciate you taking the time to respond and share your experience / advice.

Got some chips coming from our favourite communist trading partner, building a rover gauge ttl cable (the ecu plug has a printable model on thingiverse). Ill keep an eye out for any reasonably priced AFR gauge on fleabay

Ill be back when I have my stuff together and update the chat for the next poor soul to think this is a good idea.

Thanks again

Edited by Bilf on Friday 26th December 14:42

[CGCobra]

Bilf said:

Wise words, they're convincing but often wrong.

Don't know what 'bot you used but I've tried ChatGPT & CoPilot (paid for versions too) and caught them out many times particularly with anything outside of the mainstream. I found many faults with the command structure of the Motorola chip used by the 14CUX and also while trying to set up a post-processor.

Seems to me that what these 'bots do is dredge the Internet for 'information' and trot it out to the user, fine for well-established subjects but anything a bit more obscure and they are out of their comfort zone.

Makes sense really. If you trawl through the Internet looking for information on a subject you will find many conflicting opinions, how do you work out which are right and which wrong?
Taking the principle of might is right doesn't work as quite often you get a large number of hits for an "opinion" which is actually just regurgitated miss-information typically lead by a supposed subject matter expert.

Take the 14CUX as an example, I ve seen so much garbage talked on the Internet which can be easily disproved by taking the time to debug the code but how many people can be bothered with that?
Even when you do that they will still argue their opinion . It s as bad as talking to god botherers most of the time.

[Bilf]

CGCobra said:

Seems to me that what these 'bots do is dredge the Internet for 'information' and trot it out to the user, fine for well-established subjects but anything a bit more obscure and they are out of their comfort zone.

That's it. They're keen to answer, and to fill in the closest blanks it can, and are prone to being lazy.

I have had to use / assess them for work and found a few ways to get use from them, depending on the use case and the quality of your prompt.

Not to turn this into an AI rant though but why not...

My general rule of thumb is never get it to do something you cannot do, and aren't a subject matter expert in. You become the reviewer and orchestrator. Recent success is uploading CRA legislation and internal technical docs, and asking for a blow by low review of each point if legislature and how its met (or not met) by a product desgin, citing each document for each assertion.

My role was to then review and understand its output. I had to run the process a few times, either from scratch with different AI models, or getting one to check the others work.

Ended up with something that took less time for me to do by hand, with less effort. However, buck stops with me. I still need to stand by every point made (or not made), its veracity etc.

Other paths to success: do your work first, fall on your sword and tell it the work was written by an idiot and tear it apart.

The key is: dont rely on it.

You'd never palm of the work of a junior as your own. The output of AI is the same. Think if it as an infinite army of super fast, super keen idiots. Orchestrate them well and your output increases.

Flip side: had it review a different development platform's documenation, and at swore a certain thing was not possible on this platform.

However, it was, as I had done it! If someone had just trusted it, a project would have been diverted the wrong way, with significant financial and time implications.

This method is what led me to this thread. Ive zero experience remapping an ECU, so took its output here for an expert to review.

And, as expected, it made up details (e.g. 14cux controlling ignition timing).

I fed your feedback to it, it agreed it was wrong and then suggested these maps

[QUOTE]

First, I apologize for my previous errors. You're right—I incorrectly stated that the 14CUX controls ignition timing/advance (it doesn't; it's fueling-only, as the distributor handles ignition). I also initially recommended more aggressive 430-level TVR maps without strong evidence for 3.5L suitability, relying too much on general community assumptions about interchangeability rather than specific 3.5L experiences. I've reevaluated based on reliable sources: the remap-14cux.uk site descriptions (browsed directly), forum posts showing ECU/map compatibility across similar displacements, and technical notes on 14CUX fueling. I used tools to search for user experiences, but direct reports on these exact bins for 3.5L engines are rare (mostly indirect evidence from 3.5/3.9L swaps). If there's no clear evidence, I've noted it honestly—no guessing.
The 14CUX fueling matrix (8 rows x 16 columns) is MAF-based, with rows tied to airflow (proportional to displacement). A 3.9L/4.0L map is closest/safest for your 3.5L low-compression engine (per the user quote you shared and site notes on scaling). TVR maps are richer overall than stock Land Rover tunes for better response, but milder 400-level ones avoid potential row underutilization on smaller engines. Precat versions suit no-cat setups like yours (richer fueling, CO trim ~1.4V for ~13.5:1 AFR at idle). Rev limits: These bins extend the fuel table (values for higher RPM to prevent lean-out if revving past stock ~5500 RPM cutoff), but the 14CUX doesn't enforce a hard rev limit—actual limiting is by the distributor (stock ~5500-5800 RPM max safe revs on 3.5L). No change to your engine's physical limits; just supports fueling if you rev higher with mods.

1. R3652_400_6250_LowBaseIdle.bin (Top mild performance pick)
Evidence & suitability: TVR Griffith 400 Precat merge (~4.0L) on R3652—closest airflow to 3.5L/3.9L (avoids aggressive 430 scaling issues). Site feedback: "much smoother... what I’ve always been looking for" on R3652 precat. Precat richness suits no-cats. Differences vs stock: Richer fueling (CO trim ~1.4V for ~13.5:1 AFR idle); extended table to 6250 RPM (high-rev support); hot-start/low-idle fixes + smoother overrun. Expected feel: Noticeable throttle sharpness/mid-torque; reduced auto shunting; stable idle. Best balance for 3.5L.

2. R3652_400.bin (Simpler mild option)
Evidence & suitability: Same 400 precat fueling on R3652—mild richness proven interchangeable on close sizes (aulro.com ECU swaps "run fine"). Differences vs stock: Richer precat (same trim/AFR); standard table (~5500 RPM); R3652 idle refinements. Expected feel: Subtle response boost; smoother daily driving. No extras/pops.

3. LR_R3652_3.9_HighCR_OpPride.BIN (Safest OEM-style baseline)
Evidence & suitability: Land Rover 3.9L "Operation Pride" on R3652—direct displacement match recommendation. Site/commercial chips (e.g., Rocky Mountain) use similar with added fuel for low-comp. Differences vs stock: Optimized 3.9L fueling (milder than TVR); R3652 fixes; trim ~1.4V for no-cats. Expected feel: Primarily smoother operation/idle; minor response gains. Least risk if doubting richness.

Curious to hear your thoughts on its latest slop?

Or even top 5 maps to load on the 14cux for the 3.5l v8?

I say 5, as the 5 rom chips arrived while I typed this. Not looking forward to socketing the board... fragile old kit

[CGCobra]

In a way it seems to have simply re-worded what I said.

I did pick up on this comment:

", but the 14CUX doesn't enforce a hard rev limit—"

That is not true, or at least not completely. Certainly in the 3652 incarnation (I've not debugged any others) there is a rev' limit. If RPM goes above a specified value the fuelling to one bank (can't remember if right or left) is suspended which is fairly obviously going to drop power and, presumably, prevent further RPM increase. Only a small point but does demonstrate the fallibility of these systems.

The overall advice has improved however and I'd agree with it.
1) Choose a map for a vehicle close to your engine size - Gives you best chance of hitting the upper row. This can be tweaked with row scalar value.
2) Choose the latest base program, R3652. This had a bit of tidying up and later features.
3) The MAF based nature of the system means airflow in equates to fuel flow.
4) The figures in the matix for given RPM-vs-MAF will dictate the AFR.

I'm not sure what vehicles came with 14CUX on a 3.5L engine. I originally thought none but seem to recall someone saying just recently of at least one vehicle that came with this combination, seem to recall it was a 4x4 type. Don't know if any tunes for these are "out in the wild" and if they are what program revision they'd be (suspect old) but it may be interesting to see the data.

Some of the modified tunes will give 'advantages' such as fuelling to a higher RPM but this is probably less important when used in a heavier 4x4 than a light sports oriented vehicle.

[Bilf]

My donor engine and ecu came from a 1992 Disco 1, and is in a 1985 land rover defender. Autobox ZF4HP22 from 1989 Range Rover 3.5V8.

Edited by Bilf on Wednesday 31st December 13:48

[CGCobra]

Bilf said:

My donor engine and ecu came from a 1992 Disco 1, and is in a 1985 land rover defender. Autobox ZF4HP22 from 1989 Range Rover 3.5V8.

Edited by Bilf on Wednesday 31st December 13:48

OK, so your engine and ECU are from the same vehicle so that is an example of a 3.5 running 14CUX. I did think it was one of the 4x4 type vehicles which I'd heard of with this combination. Was the original vehicle running cat's and hence closed loop or catless and open loop (Green map #2)? I think '93 in the UK was when cat's had to be run.

Have you checked whether your ECU is socketed or soldered? I think it was early which were soldered and late which were socketed but don't remember what the threshold is, I've had some of each, I'd say socketed was probably more common but maybe I just got lucky. I have modified a couple.

Given that your engine and ECU are from the same vehicle they should work in combination so presumably you are looking to modify/improve some area.
What exactly are your aims?

[Bilf]

The original vehicle was catless / open loop.

In terms of aims: I'm just playing. Flashing / swapping Eproms is an easy. Already have the tools. 5 blank rom chips cost a few £.

I've knocked up a rover guage cable from the parts bin, and am 3d printing the diag socket. Put ubuntu touch on an old tablet and will compile rover gauge for it and just... play.

Next will be camshaft upgrade.

Again, just to play

[CGCobra]

Bilf said:

The original vehicle was catless / open loop.
Put ubuntu touch on an old tablet and will compile rover gauge for it and just... play.

Next will be camshaft upgrade.

Ah, that's interesting. I've toyed with the idea of running RG on Linux myself would be easier running it on a small device when I'm logging as there's not much room in my car. I was thinking of something like a Rasberry Pi with a small-ish screen, don't know if they have sufficient power though.

It is very interesting to play with, Rovergauge is very useful just to check the readings from the sensors are viable and realisticbut getting into the mapping and also the program code can be useful. Apart from modifying my mapping I've added a couple of other mod's and have a couple more planned.

What are you doing cam wise? I've just 'downgraded' mine from a wild-ish cam (believed to be a Viper Typhoon) as I wasn't too happy with the manners in the low range. The top end was impressive but, being honest with myself, I don't really drive in that area too often. I'm hoping this was causing the issues as it's a lot of work (and cost) to go through if I don't get the improvement I'm looking for.
Not quite complete yet, hoping to get it finished and cam bedded in over the next couple of days.

Edited by CGCobra on Friday 2nd January 18:22

[CGCobra]

Hi all

I'm currently looking at a project to create an electronic dashboard for my car which will closely replicate my analogue gauges but allow them to be reconfigured when desired.
Many of the parameters I would need are already available to the 14CUX (RPM, road speed, coolant temperature) along with some I'd like to have (Battery voltage, throttle position, possibly others).

It's obvious that these can be extracted via the 14CUX diagnostic port as this is what RG is doing. I'm not sure if I've understood this correctly but what I believe happens is that the "diagnostic plug-in" sends a message requesting a specific data item from the 14CUX and the 14CUX sends the data back.
Does anyone have any information on the format of these messages and/or the protocal used?

I guess I could have a look at the RG code and work it out from that but I'm partly being lazy and partly don't like to re-invent the wheel if the capability is already out there.


Is anyone else thinking along similar lines? I'm happy to colloborate or at least "idea share" if so.
My intention (at the moment at least) is to create a CAN bus for the gauge system, use microcontrollers (ESP32, Arduino or similar) to take data from external systems, such as the 14CUX and present this on the "Gauge Cluster CAN" to be available for that system.
This should allow good flexibility and allow the sysetm to be used on different vehicles, other data sources could be easily integrated in a similar manner.
My current plan is to integrate my lambda output, GPS reciever and a module to collect data from stand-alone sensors such as oil pressure/temperature, ambient temperature ans so on.
Current plan is for output to be on a couple of 4"/100mm circular OLED touch screen displays and possibly 3 or 4 smaller (2") displays as this is what I currently have in my car.
However I may simplify this and build some intelligence into the system to show monitored parameters in the main screens automatically if their readings go out of spec'. Just thinking ahead on that at the moment though.

[CGCobra]

Well it seems to have been a while since I first started planning this although I see now that it was actually only a month ago, seems like more.

It's been a bit of an uphill struggle as there are some aspects of this which I'm not too familiar with but eventually today I started teasing data out of the 14CUX. I'm a bit annoyed with myself because the answers to some of the things I've struggled with are hiding in plain sight, mainly on Colin B's github area. I initially had troubles talking to the 14CUX and then I had troubles listening. Now I look back at what I've had to do much of it hinged around inverting the data both for transmit and receive.
Colin does mention this (for receiving from the 14CUX) but I didn't know it this was meaningful as I thought it was specific to the FTDI interface which I'm not using.

I'm using an ESP to perform the data transfer wtih the intention of putting the resulting data, after a bit of a massage, onto a CAN bus which can be read by other elements.
I don't know whether to crack on with the CAN side of things first or nail a few more things onto this ESP (SD card for logging, GPS, input for wide-band lambda, LCD display). While the CAN bus is more in line with what I want to do with it having the ability to datalog at this stage would probably be helpful for debugging. Time for a thinking/planning session I think.