14cux hardware and software
Discussion
Does anyone have access to, or used to the setup software used on a laptop (Lucas or aftermarket ?) and hardware (as in serial interface "dongle"
for the 14cux fueling tables? I would like to know technically whats involved in tweeking the map before reprogramming it into a blank Eprom.
Thanks
for the 14cux fueling tables? I would like to know technically whats involved in tweeking the map before reprogramming it into a blank Eprom. Thanks
Id would think there was a good market for someone to try and duplicate the Lucas programming setup, After all £400 per after market chip is lot of money for slightly modifying Rovers standard ECU code and putting it into a £3 chip. (yes I know it takes time to set up on the rollers, but thats a one off, per map) It must be half the cost of a fully mappable system methinks. I hoped the chap who sells the Fault code readers might have some ideas on the system used to program the ECU, but no luck.
blitzracing said:
Id would think there was a good market for someone to try and duplicate the Lucas programming setup, After all £400 per after market chip is lot of money for slightly modifying Rovers standard ECU code and putting it into a £3 chip.
There is a good market, it's worth £400 a time at the moment, but in order to get into the market I think you will have to demonstrate that you can do it and do it well. Mark Adams has a huge amount of experience and an established reputation which is why he can charge this sort of money. Bliz,
What is it you are after.
Do you just want a copy of the Eprom contents or do you want to alter the software to suit
your engine mods.
If you want a copy that is quite straight forward and I do have the technology at work.
But to alter it you will need software to emulate the Eprom contents and run the car on a rolling road and alter various parameters to improve combustion etc and then turn the emulation back to data that can then be loaded back to the Eprom........ if that makes sense?
If you need a copy, I can down load it and store to a floppy or even an email attachment if that would help, and then you might be able to make some sense of the lookup tables in your own time but it would be difficult.
Paul
What is it you are after.
Do you just want a copy of the Eprom contents or do you want to alter the software to suit
your engine mods.
If you want a copy that is quite straight forward and I do have the technology at work.
But to alter it you will need software to emulate the Eprom contents and run the car on a rolling road and alter various parameters to improve combustion etc and then turn the emulation back to data that can then be loaded back to the Eprom........ if that makes sense?
If you need a copy, I can down load it and store to a floppy or even an email attachment if that would help, and then you might be able to make some sense of the lookup tables in your own time but it would be difficult.
Paul
blitzracing said:
Id would think there was a good market for someone to try and duplicate the Lucas programming setup, After all £400 per after market chip is lot of money for slightly modifying Rovers standard ECU code and putting it into a £3 chip. (yes I know it takes time to set up on the rollers, but thats a one off, per map) It must be half the cost of a fully mappable system methinks. I hoped the chap who sells the Fault code readers might have some ideas on the system used to program the ECU, but no luck.
The other often forgotten advantage of an aftermarket ECU is the fact that they offer mapped ignition and other mapping options that allow you to throw away the AFM and so on. The 14CUX is 1980's technology and while it works, it isn't that good and there are better alternatives out there. Having used MBE and DTA systems, going back to a 14CUX is like returning to the age of a crystal set after listening to DAB.
Ah, the old 14CUX v aftermarket ECU chestnut again. If the former is fitted with an EPROM chip for the fueling and an independent ECU is taking care of the ignition, are there any advantages to be had in going in the direction of a single box for both tricks? Sure, there's the added clutter and untidyness of two boxes. The aftermarket single box option now available is certainly cheaper. But in terms of function/performance, is there advantage to be had? Is it solely down to the fact that the 14CUX uses an AFM which is considered restrictive that makes it so unideal? This can largely be overcome with larger bodied items. The AFM is there for a reason and they're still being fitted today.
Don't misunderstand me, I'm in neither camp and not looking for a fight over this one. . . . and yea I know there have been previous threads.
Don't misunderstand me, I'm in neither camp and not looking for a fight over this one. . . . and yea I know there have been previous threads.
I've used both and it all depends on what you want to do or to be more exact are you falling down the slippery slope.
My Griff 500 has been chipped by MA after it had been relatively tweaked - 300 bhp, runs on plain unleaded and yes that was a more cost effective solution.
However, as soon as the I started on the 520SE developments, I was persuaded(told) to ditch the Lucas. I have a DTA system on there and it has been superb and coped with all the mods I have thrown at it, including TBs, race cams and supercharging. To be honest... I would have spent a lot more money and not got the benefit of the other mods if I had stayed with the Lucas box.
It is not a question of being tidy but more one of capability and options that are available to further fine tune the mapping and setup. The algorithms and level of control available are radically more advanced and also offer diagnostics and software to allow very easy fault finding. Something that is not available on the 14CUX. It makes life so much easier. Also the cost of an ignition module starts to get close to a full ECU and costs can be kept low by selling the old unwanted bits.
With the system I can test and check sensors, fire injectors and spark plugs without turning over the engine. I get data engine parameters and a lot of other data. It makes fault finding a real doddle.
Which way to go? It does depend on budget but they have this habit of stretching/expanding and it is easy to spend more money by not changing. If you are not falling down the slippery power slope then the 14CUX is fine. If you are then ditch it asap. It will be more cost effective in the long run.
My Griff 500 has been chipped by MA after it had been relatively tweaked - 300 bhp, runs on plain unleaded and yes that was a more cost effective solution.
However, as soon as the I started on the 520SE developments, I was persuaded(told) to ditch the Lucas. I have a DTA system on there and it has been superb and coped with all the mods I have thrown at it, including TBs, race cams and supercharging. To be honest... I would have spent a lot more money and not got the benefit of the other mods if I had stayed with the Lucas box.
It is not a question of being tidy but more one of capability and options that are available to further fine tune the mapping and setup. The algorithms and level of control available are radically more advanced and also offer diagnostics and software to allow very easy fault finding. Something that is not available on the 14CUX. It makes life so much easier. Also the cost of an ignition module starts to get close to a full ECU and costs can be kept low by selling the old unwanted bits.
With the system I can test and check sensors, fire injectors and spark plugs without turning over the engine. I get data engine parameters and a lot of other data. It makes fault finding a real doddle.
Which way to go? It does depend on budget but they have this habit of stretching/expanding and it is easy to spend more money by not changing. If you are not falling down the slippery power slope then the 14CUX is fine. If you are then ditch it asap. It will be more cost effective in the long run.
I had my engine remapped by JE engineering some years ago, and Ive since modified my engine and would like to be able to tweek the map to suit (currently it runs a tad rich at 2500 rpm). The original remap set up was a laptop running the lucas software, plugged into the ECU comms port in the wiring loom (with an adaptor I think) . With the results from the lambda probes, the map is altered on the fly on the laptop (from the passenger seat- JE dont have a rolling road !!), and once happy with the results, and Eprom is then blown from the "live" map on the latop. I think the setup was sold by Lucas to only a privileged few all those years ago. I dont know how the mapping software works, but Id love to see it in action. Its old technology, and I bet the software would fit on a floppy or two! I have full time fuel / air monitoring already, so I can see exactly what the map is doing at any point. Much more acurate than "it feels much better with my new chip". The 14cux may be old, but its works, can be modified and is man enough for my 3.9. As I said, Im suprised no ones looked into writing a sutible program with all those ECU's out there.
Ah, those were the day....
In 1985 I was programming Stock Exchange stuff using an 8-bit Hitachi CPU (Z80 clone) and EPROMs. Imagine my surpise in peeking inside the ECU in my shiny 'new' Chimaera last year and finding the exact same setup.
Now if only I could figure out the electrical connections on the serial interface....
In 1985 I was programming Stock Exchange stuff using an 8-bit Hitachi CPU (Z80 clone) and EPROMs. Imagine my surpise in peeking inside the ECU in my shiny 'new' Chimaera last year and finding the exact same setup.
Now if only I could figure out the electrical connections on the serial interface....
In sure its the same serial interface that the fault code reader uses, so you need to know the baud rate and if its a standard RS232 interface. Ive got a 'scope, Ill have a poke around and see what the fault codes look like electrically speaking to get some idea. You may laugh at the age of it all, but if your PC is only 2-3 years old, its bound still to have the interface needed , due to the need to talk crusty old serial modems, pre broadband and everything on USB. If theres enough of the various skills around and interest Ill keep digging.
Mark
Mark
Not wanting to sound too dispondent, but I would hate for you to waste valuable time. If you believe that the serial i/f (which allows access to fault codes) will help you with mapping a r/o eprom I think it only prudent to warn you.
I think you will have to read the eprom, try to decipher the hex maps (which will unlikely have any free text hints) then change a few values ~ erase/burn eprom ~ test. I believe MA has some kind of emulator for the eprom which he can adjust in real time, and subsequently burn a new chip when he is happy with the maps.
IIRC several folks have tried to decipher the maps before and nothing came from it?
Dave
I think you will have to read the eprom, try to decipher the hex maps (which will unlikely have any free text hints) then change a few values ~ erase/burn eprom ~ test. I believe MA has some kind of emulator for the eprom which he can adjust in real time, and subsequently burn a new chip when he is happy with the maps.
IIRC several folks have tried to decipher the maps before and nothing came from it?
Dave
Fuel maps can be edited manually on a trial and error basis - I do this.
It takes longer but can make a difference to the car.
The map is just a look up table which alters pulsing of the injector banks - you can just look at the pattern and read it that way.
I reckon this is almost what TVR did if you eyeball the address hex values between the standard Landrover map and the TVR ones.
Fault code reader access point on the ecu is not a serial interface and can't be used for live remapping. The readers are simple binary display modules that are sent a hex value stored in the error logging chip.
It takes longer but can make a difference to the car.
The map is just a look up table which alters pulsing of the injector banks - you can just look at the pattern and read it that way.
I reckon this is almost what TVR did if you eyeball the address hex values between the standard Landrover map and the TVR ones.
Fault code reader access point on the ecu is not a serial interface and can't be used for live remapping. The readers are simple binary display modules that are sent a hex value stored in the error logging chip.
Yes there are hex to decimal converters around but that is the least of the problems here.
Unless you are fluent in hex it is going to be very difficult to work out what is going on as the processors's op codes are defined in hex. Program offsets and addresses are in hex. In addition, you don't know whether a byte is actually a byte. It might be part of a number that takes two or three bytes to represent that. It might be data it might be an instruction. If it is an instruction, what processor code is it? Reverse engineering system software from a straight hex dump is extremely difficult.
The added issue is that a trial and error method involves running on an engine which could go bang if a wrong value is put in. A lot of micros from this time had "crash and burn" op codes that either put the micro into a test mode or similar. A classic one would be to switch all the pins. Great for testing, disasterous for a system. Normally the code would not be executed as the compilers and assemblers wouldn't know about them but all it would take would be someone patching a hex map and either get things wrong or not understand what was being changed. Run code, system would crash and often burn out hardware. With an engine, this could mean that all the injectors come on and flood the engine and potentially hydraulic it. Whoops.
To be honest what they achieved with that design is impressive.
How do I know? I used to manage the application team that supported the Lucas guys on the generation that replaced it.
Unless you are fluent in hex it is going to be very difficult to work out what is going on as the processors's op codes are defined in hex. Program offsets and addresses are in hex. In addition, you don't know whether a byte is actually a byte. It might be part of a number that takes two or three bytes to represent that. It might be data it might be an instruction. If it is an instruction, what processor code is it? Reverse engineering system software from a straight hex dump is extremely difficult.
The added issue is that a trial and error method involves running on an engine which could go bang if a wrong value is put in. A lot of micros from this time had "crash and burn" op codes that either put the micro into a test mode or similar. A classic one would be to switch all the pins. Great for testing, disasterous for a system. Normally the code would not be executed as the compilers and assemblers wouldn't know about them but all it would take would be someone patching a hex map and either get things wrong or not understand what was being changed. Run code, system would crash and often burn out hardware. With an engine, this could mean that all the injectors come on and flood the engine and potentially hydraulic it. Whoops.
To be honest what they achieved with that design is impressive.
How do I know? I used to manage the application team that supported the Lucas guys on the generation that replaced it.
trackcar said:
dave : is there an easy way to decipher teh hex back into an 8bit (?) number out of 255, that'd be much easier than starting at lots of letters and numbers, ive never understood hex stuf
I'll explain later, got to nip into town so I'll pop round. Its simply base 16 where 10-15 are represented by a-f, but I remember trying to tell you it was simple a few years ago
Lots of FFs coming on If it is embedded in mapping s/w then you would have to ask the suppliers to provide a decimal display. It might be possible to get some Winny person to do a screenscrape or OLE type thingy that they kind of do, so that you can reformat the display.
Dave
It turns out that Lucas produced a "developement" ECU with the ability to do the map in real time, so you plugged this in inplace of the standard unit, plug in your PC with a bit of interface hardware between it and the serial port to program it. The software was also dongle protected on the PC. Once the map was sorted you copied the map into a new Eprom and popped it into the standard ECU. So no easy sofware route to access to the fuel map on a standard unit unfortately. Personally I would not be happy changing the hex / binary values in the lookup tables unless I knew exactly how they converted into real world injector pulse timings. Maybe Ill just buy a £40 fuel pressure regulator.....
Gassing Station | Chimaera | Top of Page | What's New | My Stuff